@’S DIE – Postmortem
This is my first time participating in the 7 Day Roguelike Challenge. I’ve never made a roguelike before, so I decided to attempt at making one to push my boundaries.
The end result was @’S DIE, a not-so-traditional roguelike.
You can play it here: https://akirassasin.itch.io/as-die-rl
In @’S DIE, all enemies and the player are dice. The premise is simple: if you roll a higher number than the opponent, your attack hits. However, enemies will have special modifiers that affect gameplay. For example, the Aquamarine modifier gives enemies a higher chance to roll 3s and 4s.
It’s the journey, not the destination
- Day 1 – shader work
- Day 2 – map generation, pathfinding and field-of-view
- Day 3 – upgrading shaders, basic enemy actions
- Day 4 – combat, item UI, screen-shake
- Day 5 – item buff/debuffs, stats UI
- Day 6 – dungeon themes and colours
- Day 7 – difficulty scaling, registration
@’S DIE is made in Unity, and throughout the 7-day journey I learnt a lot of tips and tricks I didn’t knew before. Now I know how to use custom shaders, save batches, reduce Update calls and animation controllers.
It was also my first experience constructing a roguelike system. Pathfinding, item systems, and the turn-based system with different speed stats… With these new-found knowledge, I can spend more time on implementing interesting mechanics in the future.
What went right
- Using the Profiler – Every time something new was added, the game experiences a significant FPS drop. The Unity Profiler pinpoints the exact part of the code that is causing the problem, and I can deal with it quickly instead of searching for the root cause.
- Playtester(s) – I was lucky to have a programmer (and an avid roguelike player) playtest my game. Watching someone exploit and break your game saves you from looking for bugs and glitches.
- Rest – Working on a game jam project can bring about a lot of physical and mental stress, which can result in long-term health problems. I installed an application called TimeOut to distrupt this cycle of pain, and remind me to get away and rest for a few minutes. Plenty of sleep also helped in dissipating stress.
What went wrong
- No version control – On Day 7, I modified something and certain items stopped working. But there was no backup to fall back on, nor any systematic method to find out what went wrong. I had no choice but to remove those items from the game.
- Losing focus in class – I had to attend school in 5 days of 7DRL. I would jam in between lessons, but I couldn’t focus in those lessons because I was busy thinking about @’S DIE, and what I will do when the class ends. In future jams, a notebook should be handy in taking down those thoughts so I can focus on the present.
- To-do list – I had a detailed to-do list on a piece of paper. Needless to say, I lost the list on Day 3 (and lost my second list on Day 6). Next time, a Google Sheets list should work better.
- Poor theme – There was no narrative, and the items could have benefited from having a more solid theme. These are very crucial components in a typical roguelike’s experience. With a streamlined development process in future jams, I may have more time to work on this.
This post-mortem concludes my 7DRL voyage. I wish everyone great fun in the process of attempting 7DRL 2017! It is time for me to return back to the present… and deal with an enormous backlog of school assignments.
– akirassasin, @akirassasin_dev