GAMEPLAY TRAILER
Game Summary
Candy Slam is a 1 to 4 player vehicle-based, combat party game. Players must bump other vehicles using timing, tactics, and abilities to claim victory.
Development Info
-
Role: Game Designer & Artist
-
Engine: Unreal 4
-
Genre: Party Game
-
Team Size: 14 Students
-
Development Time: 14 weeks
Key Features
-
Amazing art and cute environment
-
Gives you a realistic bumper car experience
-
Smack your friends or play against AI
-
Chaos, competitiveness competition, and sabotage
-
Chaos from several score point-scoring modes and select from different creatures with unique abilities can be selected
-
Crush, score points and survive to become victorious
Roles and Responsibilities
-
Owned the vision of game design, gameplay, and user experience of the entire game.
-
Assisted idea generation and prototyping to assess content effectiveness
-
Set and presented all milestone planning and deliverables with team leads.
-
Create one character and one vehicle model in this project.
-
Responsible for VFX.
Design Goals & Game mechanisms
The most appealing part of a party game is how players interact with each other. When designing this game, we always focus on making players compete with each other by putting them in the same area. The picked-up buffs in the arena are designed to create more bumping moments. Players can get different enhancements when they pick up different buffs in the arena. By using these mechanics, when players are trying to get the buffs on the map, they will huddle together in one area. Then, the bumping will happen, and players will score points.
The purpose of creating different skills for each creature is to bring diverse experiences to the player. On one hand, it can bring a non-monotonous experience and make the game have more possibilities. On the other hand, these mechanics can increase the retention of the game
The scoring system is mainly based on the vehicle’s speed and the character’s skill. Even though players still have different methods to score points, bumping or using the skill to attack the opponent is the key feature to get the points but not the only one. Pick up the coins at the periphery of the arena and also can get some score. Besides, crushing the opponent out of the arena can get the highest score as juicy.
Juicy elements are also a key to achieve more fun. I believe it’s important to give players visual or auditory feedback whenever they take any actions. And the BGM can effectively arouse players’ feelings on a certain level. By cooperating with the offsite music team, we have 5 pieces of music. Also, as the developer team, we create both destructible and moveable items in the game which can bring different game experiences to the player. VFX is also the key feature which contains in that, We have 8 VFX created by me.
VFX
Character and Vehicle
Postmortem
What went right?
-
Didn’t make a racing game, but did successfully made a bumper car game. After switching gameplay styles/genres.
-
Worked faster (in later milestones especially).
-
The team stepped up to accommodate for the lack of a producer. Utilized Monday.
-
Improved team communication throughout the project.
-
Audio implementation/creation.
-
Added in clown-box animation (Easter egg).
-
Throughout semester, waste 4 hours due to version control.
-
Respect everyone’s efforts. Finally done!
-
Communication with the leads. Pipeline with the leads.
-
The TAs were present for questions and advice. Also support (speak in Chinese).Good habit: Before pushing to GitHub send screenshot to the group. Programmers can check to ensure nothing will break the build.
-
Daemon – Made a lot of presentations. Tons of practice!
-
Reacting and processing playtest feedback.
-
Animation, UI, models, variety of models!
What went wrong?
-
Lack of a full-time producer to help manage tasks and track scope.
-
Changed from racing to bumper car game (assumed unknown risks and scope).
-
Very high expectations in the beginning when tried to make bumper car game. Realized size of team and ability wouldn’t quite let us achieve what we wanted.
-
Source control problem (Perforce to Git to non-check out Git).
-
Crunch!
-
Missed milestone.
-
Art theme/background story inconsistencies.
What could be better?
-
Use of Monday.com.
-
English to communicate more often.
-
Didn’t make much documentation. Due to lack of time and people. Documents could help reduce communication confusion.
-
Naming conventions. Never put your name in the filename!
-
Better if we can design one more map. Only one if you play several times, can be a bit repetitive.
-
Stakeholder communication.
-
Holding more playtests early and often.
-
Optimization