Candy Slam
Game Trailer Overview
About Candy Slam
Candy Slam is a 3rd-Person Local-multiplayer bumper car game.
"Living on a candy island, the candy creatures are going to celebrate a new candy year coming. The celebrating ceremony requires them to drive a sugar kart and bump with others. You are one of them. To win the game, you need to collect powerful items in the scene, accelerate by using slippery road, and BUMP!" —— Background Story
Project Overview
-
Role: Generalist Programmer
-
Engine: Unreal Engine 4.26.0
-
Language: Unreal Blueprint
-
Development Team: 14 Developers
-
3 programmers, including programming lead
-
8 artists, including art lead
-
2 level designers, including level design lead
-
1 game designer
-
-
Development Time: 3 months
Roles and Responsibilities
-
Planned and scripted a component-based blueprint architecture
-
Designed a customized physics system allowing designer to define special effect, such as smashing and bouncing
-
Implemented local multi-player HUD using viewport scaling and translation
-
Developed an entity respawn system to handle the construction/deconstruction of cars correctly
Postmortem
What Went Well
-
Successful proof of bumper kart gameplay.
-
Rapid prototype and follow the Agile development methodology.
-
Physics system performs well and better than expectation.
-
Effective scrum planning for each milestone.
What Went Wrong
-
Crunching ruined the team schedule and made everyone felt frustrated during the mid-term.
-
Miscommunication between tracks leads to distrust of co-workers, and even quarrel.
-
Vague instruction from leaders make developers confused.
-
Difficulty in creating props with different game mechanics.
What I learned
-
Avoiding the crunch by limiting the scope of project.
-
Leaders should filled with energy and have a clear goal.
-
Scrum meeting helps team members to understand the current priority of works.
Customized Physics System
Speed Recalculation
The physics systems for Candy Slam were designed with one of the intent to handle the speed recalculation after bumping correctly. We use the Conservation of momentum as the speed recalculation rule. However, the calling order of collision event in Unreal 4 is randomly, which means the car speed would be modified before accessed. Here's an image to illustrate this case.
To resolve this issue, we designed two frameworks and implemented the second one. The first one is creating a global collision manager, and transfer collision events into a working queue. After handling one pair of cars, we set a flag to ignore the next same pair. And the second one is assign the host identity to one of them, and only the host would process the recalculation for both cars.
Below is the recalculation and host logic in the KartPhysicsComponent:
Hamster Ball Model
In order to achieve the exaggerated bumping effect, the team abandon the traditional vehicle physics by creating a simplified physics model, which I called it "Hamster Ball" based on floating pawn movement component. To implement this, we set a sphere collision as the root component, and bind mesh component, camera component and other required components under that. Here's the preview of car model.
When player start moving, the outer collision sphere, so called hamster ball, would translate the position, which would affect every child nodes. However, the rotation of player only happens in mesh component, like the hamster turn around inside the ball.
This control scheme is correct on flatten surface, but incorrect on slope. Here's an example of wrong case.
To resolve this problem, we implement a slope gripping method to correct the rotation in every frame. Below is the gripping logic in the KartPhysicsComponent.
Here's a video to show how this method works:
Local Multi-Player UI and HUD
The Candy Slam has a local multi-player mode based on steam remote play. The split-screen UI systems for Candy Slam were designed to support at most 4 players in the game. Below gif is an example of the local multi-player UI and HUD.
Each player has its own HUD in split-screen, including rank, health bar and energy bar. There're also some HUD, like countdown and minimap, are not split. Furthermore, when another player kart entering the camera view, the current player is supposed to see the health bar and energy bar UI on the kart top, and all kart icons are moving in the minimap relatively.
To achieve this, we decided to implement a HUD blueprint for calculating the screen positions and scales of split-screen UI. The minimap and countdown are attached to the Player 0. Below blueprint shows the setup logic of multi-player HUD.
Here's the image shows the different screen layouts with local multi-player.
Player checks every frame whether other karts are visible or not. Blueprint below implemented a checking logic using camera FOV degree.
If other karts visible, then current player would calculate the new position and scale of the bar widgets.
Here's an example of updating the position and scale of bar widgets.
Entity Respawn System
One of the challenges of Candy Slam was to handle the entity death and respawn logic correctly. The gif below shows the death process.
Since the kart would still keep alive in the scene for a while after the HP bar reach to zero, it would cause one or more unexpectable bounces and invalid damage during this period. For example, player's kart was already killed, but it also bumped with another alive kart. To fix this problem, the team decided to develop a death and respawn pipeline.
Below is the blueprint interface implemented for the kart death.
By deactivating all components attached to the dead car actor, bumping physics and damage are no response to other actors. Dead flag is to notify ignoring symbols of current car. In the end, the GameMode received the gc request and processed the respawn logic. In addition, none of the player pawns will be destroyed during the game. In other words, DestroyActor() is forbidden due to the safety concerns.
Here's the respawn logic in the GameMode: