Tower of Ash is a roguelite metroidvania created for IAT 410 - Advanced Game Design at Simon Fraser University. In Tower of Ash, you take control of the Kindling, a being born from fire, with the goal of ascending the titular Tower of Ash in order to claim the Eternal Flame. This project took three months to conceptualize, develop, and complete, and as the director my goal was to create a game that built upon the knowledge gained developing past jam projects into a much larger scale game than I had previously worked on.
The beginning of development started with the concept. I had the idea floating around in my head that I wanted to create a small metroidvania game, as I had become inspired by games in that genre lately. I had also become fond of roguelikes, so when I pitched my game idea to the team, I told them wanted to create a metroidvania game with roguelike elements. While there were other pitches, eventually that was the concept we landed on, and we began fleshing it out.
The concept was a time-sensitive interconnected world where the player would have to progress as far as they could before time ran out, after which they would use the resources they collected during their run in order to get stronger and progress through even more sections of the map the next time. The concept was built upon two pillars: exploration and learning through death.
From there, we fleshed out the concept further, coming up with the player controls and abilities, enemies, and world, while also fleshing out the learning through death mechanic by linking the player's health with the timer. I designed most of the abilities to provide the player with additional movement utility, as they would be the main way to unlock new paths throughout the map. This movement utility would also aid the player with combat scenarios, giving them more opportunities to maneuver around enemies. The mastery of movement and combat simultaneously leading up to the boss fight was something I wanted to emphasize with the player's toolkit.
We also went and developed the core loop of our game, to make sure any features we implemented did not stray from the main experience we wanted to give to players.
he world we came up with was a dark fantasy world, in a world where everything is created from fire and ash, inspired heavily by Dark Souls. From that concept, I began sketching out the player and the final boss in order to capture the artistic direction of our world.
After designing the final boss, I also went and designed the final boss' moveset. Even though I knew I would not develop the boss until the foundation was implemented, I still designed the boss early so that the other team members could create enemies that followed it thematically and mechanically, as I wanted the enemies to be able to teach the player how to approach the boss fight.
All of this conceptual design work was fleshed out in a GDD so we could all go back and reference it and continue adding to it if we wanted to make any changes.
The first thing I did when designing the gameplay systems for the player was to create a finite state machine diagram. This way, I knew how to make the gameplay states flow through each other, and I could reference it while I was developing. With this state machine chart, I could also apply it to enemy AI, albeit much simpler.
After that, I built out the logic for each state in individual classes and called the state switching logic from a central state machine class. Each individual state inherited from one main state so the logic would function all the same. Because of the amount of states the player would have, I didn't do all the finite state machine logic within a single script because then the code would have become a lot messier and harder to read, and it would have made it more difficult to add other states to the player if they were needed (they were.) These states were then linked to animations that would stop and play whenever states switched.
For efficiency, I reused the state machine logic for enemies and the boss too, which made the process of creating enemies very simple. Some enemies also had very similar or identical logic, which let me reuse even more code. I designed the enemies and the boss to have very readable movesets, adjusting animations Herman gave me to have lots of anticipation time. It's a quick way to make combat scenarios readable and attacks have more impact while having limited time and resources.
More minor gameplay elements I worked on were the HUD, implementing the timer counting down and the resources the player has, as well as the upgrade system. I used Unity's scriptable objects to store player data and it was serialized in every scene so that data transfer between scenes was more simple so the upgrade system relied on updating the values in these scriptable objects.
Being the biggest project I'd done so far, I was pretty proud of the result. There were some technical issues, such as saving and loading, and level loading that weren't able to be patched out by the time of our deadline, and we had to cut corners in terms of assets and level design to make the deadline. If we had more time to work, and it wasn't for a class so we weren't burdened by the responsibilities of other classes, I'm sure we would have been able to produce a more polished experience. But, the core concept was received very positively, as a lot of the people who played our game were motivated to try to complete it, which I consider a success. This is one concept I would like to take further given more time.
In addition to creating a very ambitious project in a small amount of time, this project also granted me Simon Fraser University's Cody Sawatsky Award in Gaming, which recognizes the top student in each year who has completed courses in game design or game development. This is an honour I am very proud to have achieved and has made me even more passionate about the work I am doing.