RicoChef is a 2D mobile, ricochet based puzzle game on Android Tablet. Help Grandma prepare all the pesky tomatoes to finish her soup!
Role & Responsibility
I am the sole programmer of the team. This project gives me an opportunity to work in a team and also to apply my programmer skills in a mobile game development environment. As the only programmer, there are a lot of responsibilities and pressures on me. I proudly kept the project going and finished the game on time.
Feature
There are many different obstacles in the game. There are the normal, static platforms, the horizontal moving platform, and the rotation platform. All of those can easily modify their speed, direction, and position. Aside from those, there is also a breakable block and lock block which are special objects that interact with the player’s bullets. The breakable block, as the name suggests, breaks down after collides with the knife. The lock block will prevent any movement of the pieces it connects to until it is destroyed.
The knife will bounce through the wall and platform 7 times before it died.
And since the ricochet is our core loop, its physics is carefully designed. In order to make the knife bounces naturally and does not slow down, I calculate its rotation and give its force through code.
​
There are also a lot of juicy elements for the knife. There are sound effects for both firing the fire and colliding with walls and platforms. There is a particle system with a cartoon words when the knife collides with the wall. There are also different screen shake when shooting the knife, knife colliding and knife destroy.
The screen of the game is divided into three main sections. On the top part of the screen, it is the aim screen where the player can tap to change their aim position. On the bottom part of the screen, it is the moving area. The player can drag on that area to move the character. The character will also flip into the direction of movement. And the last portion is the bottom UI part. There is a big fire button in the middle of that area. The player can tap on that button to fire the knife.
In order to better help the player to plan their shoot, there was a reflected aim line. I used line render and ray cast. However, inside of the stop once the ray cast hit the platform, I went on and manually calculate the location of its reflected line. After the calculation, I set the line renderer vertex and ray cast again from there.
Due to design change, this feature is cut from the final game.
Post Mortem
As a Team
What went well?
-
Displayed adaptability throughout
-
Managed to bounce back from setbacks well
-
When tasks fell behind, someone was always there to pick it up
-
Great team lunches – always ate at nice places with delicious food and learned more about each other
-
Learned how to communicate better with other personality types and different tracks
-
Learned the importance of speaking up and not letting problems fester
-
Face the problem not the person
-
Efficient in creating documentation – by dividing up tasks
-
Learned the value of onboarding someone, through the project
-
It was not an easy process, especially Perforce
-
But the onboard member became an invaluable member
-
​
What went wrong?
-
The scope was too large in the initial concept and then it was too small after it got revised.
-
Perforce problems – version control was not used, instead, incremented file names which added a lot of work
-
Issues with communication early on – disconnect between people – ideas and plans were made but not communicated to people who had to make them into reality.
-
Art assets – not knowing what the parameters for those in terms of game design made it difficult for artists to create with the right properties
-
Failed to organize the structure (i.e. naming convention), with the new onboard team member, it got hairy quick
-
Did not playtest enough – it was never ready to playtest.
-
Did not meet milestones – due to catch up game
-
It’s better to under scope than over scope
-
-
Importance in communicating with stakeholder especially
-
Especially in the concept stage
-
Take in the feedback from the stakeholder to avoid painful times
-
-
We did not take the time to openly communicate about elephant in the room, and it showed up in unhealthy ways.
-
When there was conflict, it never felt resolved. Make sure you resolve the conflict.
-
Lost one team member – level design, GDD document was difficult without the GD to provide information
What we learned
-
The plan is not ironclad – you can make changes on the fly if it feels right
-
Keeping constant communications with other disciplines was helpful to confirm
-
Perforce – make sure to speak up before touching any files
-
Maintaining openness and flexibility is important especially when you are told on the fly to make changes on an asset
-
Announce when something is uploaded to Perforce is important
-
Carefully plan the folder structure
-
Use subfolders to help organize (especially art)
-
Try to get rid of older files so they don’t clutter
-
-
Understanding interdisciplinary jargon
-
Put yourself in other people’s shoes.
-
Project files – plan carefully especially when merged from an old project – start from scratch to avoid old files disrupting the new project.
-
Streamline the pipeline to improve speed – Don’t be afraid to directly interact with assets in Unity if they can be tested in Zoo scene.
As an Individual
What went well?​
-
Made a game under so much pressure
-
I am happy that as the sole programmer, 1 finally make a game as we went through game idea change and re-pitch, internal team conflicts, and team members joined and left. A lot of pressure was there in terms of technology as the time limit is very short and our game is officially started after pitch.
-
Work with other tracks
-
I successfully work with LD and artists without breaking each other’s works. And we managed to do it efficiently so there was not much waiting time.
-
Rapid prototype and change
-
During the production, I was asked to make a lot of functions and then we separately tested if they suit the games or not. Although some functions finally get cut like reflected aim line, I did well by providing those functions in a short amount of time so that there is enough time for LD to find out whether it is a good idea.
​
What went wrong?
-
The maintenance of an organized workspace.
-
I failed to maintain the workspace on Perforce organized because of all those game changes and team member changes. Because of team members change, we did not follow the designed naming convention closely. In the end, I realize a messy workspace is formed yet has no time or courage to organize it. It costs some extra time for the teammates to communicate which asserts should be used for which purposes and where they are.
-
team communication and formation
-
As a member of the group which had a lot of heated arguments and even conflict, I certainly did not do well in team communication and formation. Although I did not directly participate in most of the arguments, I failed to calm down both parties and stop the situation become worse.
-
Fail to test enough
​
What I learned
-
The most important thing is to face the issues and address them.
-
The importance of stay organized under stress
-
The importance of communication and discussion both within the team and with stakeholders.