Yonder
Overview
-
Role: Programmer
-
Genre: 2D Platformer
-
Engine: Unity
-
Team Size: 6 People
-
Development Time: 3 months
High Concept
Yonder is a 2D platformer set in a futuristic landscape on a deadly alien planet. Yonder follows the young PhD candidate, Sully, as he sets out to collect artifacts in order to get his dissertation approved. Sully quickly discovers why the university tried to dissuade him from venturing to Yonder after collecting his first few artifacts. Whomever made the artifacts initially is willing to go to great lengths to stop overeager adventurers like Sully from escaping Yonder. Through running, double jumping, climbing vines, and more, Sully must weave his way through elaborate traps and return to Earth safely with the artifacts in tow. Can Sully gather enough artifacts to prove to his dissertation review board that his research is worth it?
Responsibilities
-
Implemented the on-screen control: character movements and jumps.
-
Implemented the character animation state machine and worked closely with the artist to design animations.
-
Implemented the menu UI and in-game UI.
-
Implemented core mechanic of collecting artifacts.
Core Mechanics
On-Screen Controls
Even though Yonder is my first group project in Guildhall, I already had an experience of mobile game development. At the early stage, the team had conflicts of which joystick we should use in the game. While I believed we should use the fixed joystick, other people thought it would be nice to not put joystick on a fixed position so that other people with bigger fingers can still play the game. As the result, I implemented three different joysticks to playtest: fixed, dynamic, and dynmiac fixed. After the vertical slice stage, we eventually chose the fixed joystick as the final on-screen control. Although other two joystick types were discarded, I learned how to implement those control systems and how to solve team conflicts.
​
The image on the right side shows the on-screen controls of the game. The joystick on the bottom left side controls the character's movements and jump directions. Tapping the right half side of the screen allows the character to jump.
​
The images on the bottom demonstrate the joystick class that I implemented. It can calculate player's input direction and magnitude based on the screen size and joystick movement distance.
​
Hazards
The hazard events in the game happen whenever the players activate the relic door. The image on the right side illustrates all three different hazards in the game. Each level has its unique hazard.
​
While implementing those hazards are fairly easy, when to trigger the hazard is actually a challenge. The system needs to check if players have collected all three relics and also saves player's current information. Also, since the relic door opens slowly, and players cannot walk through it until the door completely opens. The hazard even trigger time needs to be precise. I worked closely with the level designers to determine the trigger time so that the players can feel the danger is coming while they still have enough time to escape.
​
Relic
The relic system is a system that contains three different collectible relics and a relic door that blocks the player until all three relics are collected. This system is the core game system that determines the goals in the game: successfully collecting all three relics.
The image on the right side illustrates how the relic system works in the game. All three relics are placed in specific places in each level. Whenever the players collect one relic, the relic UI on the top right will show the collected relic while the relic door will also show it.
Dynamic Backgrounds
In the game, the level backgrounds are constantly moving with the players and also changing after players finishing one level. The image on the right side shows how it works in the game. The parallax background contains multiple layers, and each layer has a different parralax offset so it will move faster/slower based on its current layer position, which provides a nice visual effect of moving background.
After level completion, the loading scene will play background animations indicates time changes. It will switch from daylight in level1 to dusk in level2 and eventually night in level3, which indicates passing of the times as players moving deep into the planet.
Post Mortem
What Went Well
• Ended up with a polished product.
• Shared a very clear vision of the game.
• Rallied together in the time of crisis.
• Never hung up on a feature or reached an impasse.
• Shot down unfeasible ideas quickly.
• Always keeping track of what we needed to do with good communication.
• We were all apprised of what other team members were working on.
• Always looked for feedback from the team and those outside the team.
What Went Wrong
• Did not prioritize issues during the vertical slide milestone and took a long-term approach when we needed to take a short-term mentality.
• Scoping issues (overscoped during the early stages).
• Spent too much time on the planning phase at the beginning.
• Misinterpretation of deliverable (how long and detailed the game should be).
• Took days out of production to nail down the high-level concepts and core mechanics for the game.
• Inadvertently reached chokepoints in production where one discipline was waiting on assets from another discipline before beginning their work.
What Needs Work
• Did not use Perforce/Helix efficiently and caused the issue of everyone waiting for me to submit his checked-out scripts.
• I learned to submit my work frequently and inform the team which assets I would use in that workday.
• Did not get enough feedbacks about control in the early stage.
• I learned to show every team member and stakeholders about my control changes .
• Show my work to the team and stakeholders to get immediate feedbacks.
• Communicate with the team and provide my own thoughts from programmer standpoint.
• Do not be afraid to kill my baby.
• I learned to remove my work if my work did not work well.
• How to cooperate with people from different disciplines in one team.