Evaluation and next steps
Over-scoping
Originally I started by planning out what I wanted within my game a week before the University year started, planning out the general concept as well as what assets I would potentially need. I wanted this game to be a prototype of a bigger game that I could work on after University, with that in mind I knew that it would most likely have to only be a level or so with minimal content in it. In the following weeks I slowly got a better idea of what I wanted to make, drawing up concept art and deciding what assets to implement.
I then made day estimates for each element such as art, programming, design and sound, using this information to plan my weeks. I quickly found out that I wouldn’t be able to complete everything as there were too many days planned out for the year, exceeding the days I had available.
As I started to plan before starting my other modules I hadn’t fully considered the time I would need to put into other modules. I also hadn’t anticipated how much lockdown would have affected my work, working in isolation away from the normal University environment which meant that I had to descope multiple times leading further away from what I had originally planned. Having to resolve programming bugs and issues when it isn’t my main area of expertise also affected the total outcome and productivity.
Environment
From the beginning I knew that I wouldn’t be able to do multiple levels and would have to stick to one so I never got to fully explore the different ideas. The concept art I did towards the beginning of the project (Figure 1) shows a few different areas: an overgrown temple section, an upside down mushroom level, areas surrounded by water and some out in the open.
Going forward I would likely start to improve the environment by creating some sort of hub area that connects all of the others and where the player can see their progress in bringing colour back indicated by a statue I sketched previously (Figure 2).
Every time the player unlocks colours they would be reflected on the angel statue (Figure 2), lighting up the feathers, eventually producing a rainbow across them.
Story
To properly build the story within my game in the way I wanted, I would have had to create multiple levels, using the environment and visual storytelling to hint at what happened in the ancient temples. As such the story aspect of my game has all but been forgotten while developing.
Having some short animated cutscenes could help give context to the game and why the player character is where she is.
Enemies (Seed shooter)
While I designed multiple enemies I had to de-scope multiple times and It ended up where I had planned to just implement two enemies; the thistle ball and seed shooter (Figure 3). I decided to implement the thistle ball first as the scripting for it seemed easier and it meant that I would be able to test out combat a lot earlier on.
In the end I only got to implement the one enemy as with the time remaining and multiple things to work on, the coding required for the seed shooter seemed like too big a task so I had to shelve the idea. Coding the enemy attacks would have been one thing, but as it used projectiles it would be hard to make the gameplay feel fun in such a small space where dodging seeds would be difficult.
Staff
The simple staff that is currently being used was intended to be a placeholder so that I could work on attack animations as soon as possible. I explored a few designs, one that incorporated the colour concept and others based around monk staffs with plant/nature elements in the designs (Figure 4). Finalising the staff design to fit in with colour combat more and give Lily a more striking silhouette would be important when moving on.
Multi-direction attacks
When doing the attack animation I realised that due to only having land based enemies it would be possible to play with only a side attack. While I would have liked to have made a down attack, it wasn’t a requirement to finish the game so I decided to focus on more important elements.
More advanced colour combat
Ideally the colour combat wouldn’t come into the game straight away, the player would slowly gain the three colours by activating altars like the one at the end of the level. This way the player could be taught through environmental gameplay rather than fed a tutorial, making it a requirement to progress by using the new colour to defeat a new coloured enemy or clear an environmental hazard.
I would have liked to implement a right click control that brings up a radial menu of all three colours, to quickly swap between them, this would have had to be quite minimal as to not block the view of the player.
One of the main initial concepts was that activating altars added colour to the environment and enemies, unlocking new character abilities but making the game harder as you progress. If I had constructed the environment differently it may have been possible/easier to implement but at the time it would have been very difficult to have done it well and would have likely taken a lot of time.
Special abilities
In addition to improving the colour combat I would have liked to have had more flexible combat with abilities that allow the player to play with different ways such as dash abilities or long range attacks.
Menu and UI
If I had more time I would have implemented the menu and sounds that Natalie made. In addition I would create a UI for the player’s health, something that was explored slightly at the beginning of the project as well as different screens for the menu and when the player dies.
Sound
Unfortunately some of the sounds created by Natalie never made it into the game due to time limitations. Going back to add in those unused sounds and fine tuning them could produce a more polished experience.
One of the major sounds that didn’t get put in were footsteps. I tried to follow a tutorial that used animation events in an animator controller to trigger playing the footstep sounds but despite following it closely it didn’t seem to work and I had to move onto other sounds.