OVERVIEW
Interstellar Racing League (IRL) is a high-speed racing game set in the distant future. Players race as larger than life personalities for fame, glory, and money across different worlds.
PROJECT INFO
TEAM INFO
RESPONSIBILITIES
GAME: Interstellar Racing League
GENRE: Multiplayer Racing
ENGINE: Unreal Engine 4.17.2
DEVELOPMENT TIME: 16 Weeks
PLATFORM: PC
TEAM SIZE: 56 Developers
PRODUCTION: 4 Producers
DESIGN: 20 Designers
PROGRAM: 16 Programmers
ART: 16 Artists
-
Created and iterated 2 track events using blueprints, particle effects, and post-processing to increase players’ driving pleasure and challenge
-
Collaborated with a multi-disciplinary team to improve tracks’ conveyance using environment kits
TRAILER and SCREENSHOTS
MY WORK
Sandstorm Event
Overview
Sandstorm is a randomly moving particle effect, which will reduce racer’s speed and block their view.
Event Breakdown
Blueprint
It contains:
Set Post Process
Set Particle Systems
Lap Logic
Apply Slow and reset to the car
Particle Systems
Screenshots in the game
Earthquake Power Plant Event Event
Overview
Earthquake Power Plant is a memorable event with strong visual and sound effect, which will shake the players’ screen. After the earthquake finishes a crack will appear in the side of one of the Power Plants that the Environment Team has created and will spew smoke from the crack onto the track.
Event Breakdown
Blueprint
It contains:
Set Camera Shake
Set Particle Systems
Set Decal
Lap Logic
PERSONAL POST MORTEM
What went well
Practice for Unreal
Take myself as an example, at the beginning of this semester; I know little about Blueprint/ Particle/ Material about the unreal engine. The world project is a valuable practice for unreal. And the most important is that it helps us to have a wide vision of what unreal can do and how to solve the problem of unreal development.
Practice for teamwork
For most of us, I believe it’s the first time work with so many people at the same time. Even for me, who has worked in the game company, it’s still a precious practice for teamwork, especially working with people from the different cultural background.
Quick switch among roles
During different phases of the development, I have serval different roles: In the prototype phases, I built the prototype level and temporary particle effects; In the first playable and alpha phases, I worked for Event Sub-team in Blueprints and Particles; Then in the Beta and RTM phase, I worked in conveyance and bug fixed.
What went wrong
Game design idea circles
During the whole process of TGP 2, GD team is struggling with game design ideas. In the prototype phase, they were not satisfied with the idea that making a Mario Kart clone and they really wanted to make a brand-new game. But when they tried to develop the initial idea, they met a lot of difficulties coming from technical and design itself. For example, the idea about “customization through gameplay” is abandoned after POCT. The reason is the complexity of technology and too much workload for artists. Many ideas share the same problem and process: At the very beginning, them looks like good ideas, and GD team believes it can make our game better or solve the problem we have. Then they announced in front of the whole team. But it is against by other teammates or blocked by objective reality (the time, the technical ability, etc.). Then GD team has to change it again. The new change, on the other hand, causes almost the same reaction just like the former. And what makes this circle worse is that the people in the team lost the truth to GD team and the game in some degree.
Finally, what left in the game design or gameplay, is so simple or barren that you hardly find any interaction between players or fun from racing itself. In another word, what if the GD team focuses on refining gameplay from the Mario Kart? Sometimes imitation is so important that you cannot do creation before you finish this step. Also, the idea is cheap; execution is everything. GD team doesn’t know much about what the team can do and what they can’t.
Unconscious design
As for me, the unconscious design’s definition is the design action without much consideration. The most common unconscious design is “Our game should have this feature because all the FPS/RPG/RTS games have this.” In our game, the most obvious example is the initial controlling features: boost, brake, and shift.
This design causes several problems: First, the Chevrons’ placement is always on the side of the arc, which radius is bigger. If not, the player is hard to see the Chevrons from distances. Second, if the Chevrons on the right side, the player always turn to the left side vice versa. But for this reversed arc, you cannot meet these two conditions at the same time. It causes the player has no time to prepare for the turn or inconstant chevrons placement.
The isolation of teams
In the first point “Game Design idea circles,” I mentioned that some people have very strong opinion against GD’s ideas. One of the reasons behind this internal friction is the lack of the sense of “we are one team.” The most people think that they belong to Environment/ Track/ BPACK/ AI/ Physic/ UI/SFX team but not the Guildhall TGP2 team. They ignored the fact that these teams are not isolated but working for the one game. The most terrible word I heard was when Theodore talked with me about retro, he said: “we have bad impression for Track team.” This comment doesn’t help the situation but destroy our team and game. The teammates mean that you not judge other people but help them.
What I learned
Communications
Keep reading documentation and notifications
they help you to keep on the same page with others. And they are highly efficient and precise methods to know the latest design decisions and technical details for level designers. For example, when you need to use some APIs, before asking for help from other programmers, the better way is to read TDD first.
Provide reasons before being asked
It’s a better and easier way to communicate. People needs and should know the reason behind your requirements. It saves time and makes smooth cooperation.
Pay attention to others work in scrum meetings
It helps you understand what is going on in your team and even is a chance to help each other to clear blocks.
Unreal, perforce and Jira
Be careful when using particles
Performance is everyone’s responsibility.
Use level streaming for concurrent development. Check-out and check-in promptly to avoid blocking others
The pipeline between Unreal andandperforcepost processing. Lock of sight (LOS) and LOD are important for performance optimizations
Jira and perforce make development much easier.