Good plan is half done

Idea

It has been 10 years of 7DRLs for me now and, probably for the first time in these 10 years, I finished a project that I started out to do.

Songs of Heroes and Rogues was quite well planned. I got the idea of making a game like Heroes of Might and Magic / Songs of Conquest (and because it is a little roguelikey, that is where the name came from), but instead of it being about building a castle and conquering the map, it would be about defending a castle. It would need some time limit to force the player to move forward and FTL-like doom clock where the enemy is advancing toward the castle seemed like a good fit.

Preparation

I wanted to keep the game really simple.  My 2024 project Chase through Blytheware had very flexible systems, but making any kind of content for that was always a longer process. What I basically needed for this was just attributes and state flags, no triggers or responses, so I didn't even consider re-using the same rule engine this time.

I wrote a simple design document and started looking through my collection of game assets for what I could use. Then I started noting down algorithms that I would need to implement the whole thing.

The jam

Having a clear list of what needs to be done helps a lot in keeping the focus on right things. A design document is good for this, but in my case there were perhaps too many details on the list.

On day 6 I noticed I didn't have winning condition at all yet, no end fight and the castle didn't even show up on the map. The castle was made already, as well as all the needed units and fighting was possible as well as the danger zone fight, but there was no final fight and no winning condition.

I probably wouldn't have even noticed that if I hadn't stopped implementing stuff and started to write a priority list of what was left. Maybe it would make more sense to write a design document from this priority perspective, what is the bare minimum for MVP.

One thing I didn't have in the design document at all was naming of things.  One recurring time sink in all my jam games so far has been writing. More user visible text there is, more difficult it is. 2024 almost failed completely due to the amount of text I needed. This time I was wise enough to not make any texts if I could avoid it. Except I had items in game, and those item had to have names. There are 30+ items in game and it felt like it took hours just to figure out names for them. Looking at it now, I probably could have just made nameless items and saved a lot of time.

Final day was packed, first I did some polishing to the UI (yes, it is possible it was even worse then), then played a bit and tried to balance it a bit, but finally ended up using the remaining time to make some features.

Result

Maybe I expected to need more time for polishing and balancing (and yes, it really would need that too, but it was enough for a release) so that I though I would need whole day to do it.  Problem was that I had this final day in wrong a order and made features at the end, but didn't actually properly try those changes afterwards. There was a bug introduced in exactly the final 3 lines of code that I wrote that ended up breaking the game if 2 specific random numbers were generated.

A simple fix and a new build out, but the week was quite intensive so I took a little break after the jam and didn't play the release version at all. Sorry everyone who played it and got stuck because of that.

There are some good lessons here. Aim for the MVP first, then everything else. Test before release and from that item naming nonsense, if you really don't need something, maybe you just don't need it.