Fairy Bomb post-mortem
I’ve neglected the blog once again, so to make up for it I’ll try to write not one, but hopefully three postmortems over the next week explaining what I’ve been doing these past months besides gaming.
I’ll start with the most recent: Fairy Bomb, my entry for last week’s #7DRL challenge.
Play it here
In case you don’t know, the challenge involves creating a roguelike game in seven days, with completeness being the main objective.
You may remember Rob-like, my first foray into roguelike development, which has been canned for quite a while now (I keep fooling myself saying I might resume it, but then I say the same about most of my game jam projects and...ahem). Then, late last year I went for a second attempt with Sacrifice-like. That would have been my entry for the 43th Ludum Dare if I’d managed to submit it. Unfortunately, I both miscalculated the scope and burnt out from yet another game jam that had taken place the week before. Since that will hopefully be the second post-mortem I will not spoil more.
Back to Fairy Bomb, I went for a relatively straightforward idea for a game, with some twists: The map would be hexagonal rather than a square-based grid, and the combat would be fully based in bombing like in classic Bomberman (At first I’d considered that monsters could also use melee andI even implemented a basic pass or projectile-based ranged combat, but cut it out because it didn’t feel right at the time).
Last, I decided to make the bombs paint the ground conferring side effects to entities occupying those tiles.Those side effects would range from status changes to healing or other crazier stuff, and could even become the game objective in itself if I had decided to pivot to territory control instead of your usual “escape a dungeon” goal.
I’m pretty happy with the idea and somewhat satisfied with the result.
What went well
Code reuse. This time I was able to benefit from some bits of code from past projects.For example, I ported the BSP generator from a procedural generation demo I’d done a couple of years ago (and before that I’d used a similar implementation I did for Rob-like, but had to scrap it). Other areas where I could use existing code were the battle logic, back when I was thinking of using normal combat for the AI and the “play contexts”, which determine the context the player interacts with the game under certain circumstances (normal interactions, multiple-input interactions, etc).
Learned new things. In particular, I had to do some research about hex maps. Unity’s Tilemap functionality already helps a lot, and for the missing bit I can’t help but recommending strongly Red Blob Games’ Hexagonal Grids article.
Code architecture ideas + Data driven game logic. If/when I develop the game a bit further and can clean it up, I might share some tech design docs or code. If you’re masochistic, though, you can check the repo on Github.
Feature scoping and adaptations. As time crept in, I decided to scrap several of the features listed on the backlog. For example, instead of adding normal consumable items, like potions, I decided to exploit the terrain paint’s side effects. Also, doing without melee combat resulted in more symmetric gameplay, which would make easier to playtest the core bombing mechanic and reduce the number of interactions available.
What went wrong
No art. I could only rush some tile and bomb art and ended up using the character graphics I’d used during development. I have a very clear idea for the main character and some hints for the enemies, and I would like to try to take this a bit further.
Barebones content design => Bland experience. I did have a number of systems in place that I believe are really promising, but in its current state I think I’m not exploiting them to their full potential. Map generation, monster spawning and loot rules are there, but they don’t offer anything interesting right now, and the terrain painting is not super useful at the moment. I need to rebalance everything, create more content and try to structure everything into a fun whole.
Juggling a game jam with a work week is exhausting. While this time I did manage to submit my days reduced to work-jam-work-jam, except for Friday, when I took some time off for the IWD. Needless to say, this is not healthy and I should not do this again (especially when my last LD failed for similar reasons -although not exclusively)
Code architecture misuse. Because of the rush some good ideas I had about how to structure the code ended up twisted. Also, I probably overcomplicated things in some areas.
In the end, I overscoped once again.
Learnings
Simple can be better. Reduce scope as much as you can, and then try to reduce a bit more.
REST.
Make a strong commitment to avoiding programmer bias. In Spanish we use “la cabra tira al monte”, meaning something like “the leopard never changes its spots”, and a constant in most, if not all my game jams, is the fact that I spend most of the time coding instead of doing art of some low level game design. I need to step out of my comfort zone and try to develop those areas if I want to improve my games.