Slimey
Project specification
Date: December 2019
Team Size: 4
Language and External tools: Unity, C#
My contribution:
Game play mechanics
Slime movement system
Audio system
UI menu system
Game description:
Slimy is a 2D side scrolling puzzle game where player play as a slime revenging for its village by traversing through dangerous environment, solving puzzles and eventually killing the adventurers that slayed its family.
Game Systems
Launching and Sticking
At launching state, the slime will not be affected by gravity and launch in a straight line. To achieve this, simply change the gravity scale to zero and add an impulse force to the slime. With zero gravity, it creates a feeling of launching. The slime will also rotate its sprite into direction that it's facing.
At sticking state, the slime will rotate it's facing direction based on the normal of the collision. Unity has built in function that calculates the normal vector upon contacts. Given the normal, it is easy to adjust the collider and sprite into correct angle.
At launching state, the slime will not be affected by gravity and launch in a straight line. To achieve this, simply change the gravity scale to zero and add an impulse force to the slime. With zero gravity, it creates a feeling of launching. The slime will also rotate its sprite into direction that it's facing.
Grow and Split
Grow and split mechanic turns out to be the most complex part after all other mechanic is polished. Growth will cause the slime to change size in both sprite and collider.
However, a pre calculation is needed for growth so that the slime will not be stuck inside the wall.
UI System
Main Menu
Tutorial Pop-up
Level Select
Pause Menu
Function Decomposition
The game separates its functions and mechanics from specific input from devices it's running on. The character has script that exposes launch function and grow/split function.
Thus, instead of detecting the input from the character the game system uses a script called control scheme. The control scheme script is used to decide what kind of control will trigger slime movement and mechanics functions. This kind of setup adapt well on rapid development as it allows me to experiment with different control schemes to trigger the same slime functions.
As you can see in the inspector, I can allow different kind of control from either PC or tablet. The player input also decides what kind of player input method trigger the launch. One way was to drag and release. I can change the control method by simply check which scheme I want.
Postmortem
What went well:
Great communication between each track. Every one was paying attention to each other‘s working progress.
Group is reactive to feedback given about the game and came up decisions for it efficiently.
Iterate on the process, not just the game. Team is able to learn and grow during each milestone after retrospective self-reflecting on the scrum process. Identify issues in the production process and come up with solutions to avoid the same errors happen again.
Great team dynamic and atmosphere.
Pretty accurate task cost estimation.
From the outset the team was able to describe and implement a unified vision for what the game was and, when disagreements arose, were able to resolve them very quickly and without long-lasting effects.
Red X was quickly able to open up and share ideas with one another in a comfortable and judgement free area where new ideas were fostered and built upon as well as a turning point in the middle of the project where ideas were not longer viewed as a binary yes/no decision, but as potential additions to existing ideas or could be tweaked in ways not thought of by the person giving the original pitch.
Delegation and scope: for the most part Red X was able to distribute work appropriately and keep the game at a reasonable scope for the time allotted and team available. This came down to modular design that eased the workload off the artist and allowed more time for other assets. It also allowed our programmer to refine an polish more and more instead of always generating new code.
Iterating was fast and fixing elements within the level design or visual aspects was also fast. The pipeline that we had worked very well and adding new elements did not take much time.
There was almost no conflict within the group tasks and when discussing ideas, it was done in a very civilized way.
Tasks where distributed very effectively and when someone needed help from another teammate it was not an issue to discuss and get something working.
What went wrong:
Polish wasn’t done on time during the beta stage. Led to frustrating gameplay which wasn’t fixed until the deadline.
Standard of pull and push process was made clear to the group until mid development. Forgot to add in perforce/ unity
Did not apply RACI properly until mid-late development.
No asset import standard
Cross-disciplinary misunderstandings, there were a few times that lack of understanding between disciplines, particularly from the LDs, led to overloading of others work in art, programming and production. This became better in later milestones as better understandings were reached.
Underestimation of certain task times. There were multiple occasions of tasks taking far longer than estimated and adjustments were made too late to compensate for the lost time.
Letting go of ideas. Some ideas throughout development ended up being clung to for far longer than they should have or did not have proper implementation early enough along to ensure that design decisions were being made with them in mind. By the time we got back around to the extra ideas, too much progress had been made in other directions to reasonably implement them.
There were unbalanced workload distribution at some stages of the production.
Team sometimes overlooked details about production pipelines and caused issues at the art asset import at the beginning stage.
Some tasks weren’t prioritized correctly at an early stage of the development process.
Some tasks were underestimated in the time and effort they were supposed to take, some others where solved faster than expected. It was not uncommon to have tasks that were planned to take a certain amount of time and ended up taking more or less time
Many aspects of the game felt unfair to the player, mainly because of some lack of feedback, and we would often iterate to try to fix them and would either feel like a marginal improvement to the player or would not change the player’s perception of the game
There were times when fixing one element of the game would break something else. There was a point where the stakeholder felt that we had taken a step back on the game and it was a pretty demoralizing point for us. Eventually we solved it but at that time we were not entirely sure how to improve the game
What we learned (Even Better If):
Taking the time to get to know your team, what their strengths and weaknesses are and how they enjoy working on and contributing to the project is one of the greatest things you can do for the team, yourself and the game.
Address minor concerns when they impact the whole of the core of your game. While little changed from our movement system early on besides the polish that ended up surrounding it, the impact that small issues had on later milestones were much greater in comparison.
Bouncing around ideas can be the best way to blow off steam and come up with fun new concepts. There were multiple times in the hear of development that just riffing on ideas ad absurdum helped the team to come up with fun and new concepts, even if new to none were ever implemented, and release some of the tension and stress that can build up on a team that small.
Scrum is a process of group self-improving production efficiency. A group need to look back at the process from time to time to identify issues with the team and come up with an improvement method. This process will eventually have a team that works at maximum efficiency with as little as possible communication errors or production process errors.
Be aware of each person’s workload while planning.
Plan production pipeline with more details
We learned to work with multidisciplinary teams that come from different backgrounds and figure out how to organize ourselves
We learned to work using a repository and how to work in the same project at the same time. We developed a pretty good and efficient workflow, especially towards the last milestones
We learnt how to make smart cuts pretty early on in the development process to allow us to invest more time and effort on the core aspects of the game
Address issues that can potentially affect the whole game early on.