Here is a little post-mortem of the process of creating Rogue Sails, my entry for the 7DRL Challenge 2020, for my memory and hopefully to help others in the future.

Project Goals

My goal was to have a complete game with a reasonable amount of content, so I purposely decided to not focus on experimentation and innovation. I still wanted to do something exciting though, not a Yet Another Fantasy Dungeon-crawler. Therefore, after giving it some thought, I went with an Age of Sails setting and focused mainly on exploration.

Highlights

Planning. So much this! I started thinking about it a free weeks in advance, taking notes about what would have been the core gameplay, what assets I would have needed and think about the general architecture of the game. Separately I noted any “stretch goals”, making sure that all of them could be completed singularly as much as possible. When I started working on the 29th I knew exactly what I needed to do and in which order. Maybe even more importantly I didn’t need to stop thinking about how I wanted to implement this or that element.

Remember to have a few spare hours for publishing before the deadline.

Time & Schedule. It may be a given, but setting aside the right amount of time really helped. Due to a change in my job, lately I have been working some sane hours, this means that I was well rested when I started and I had time to work on the project during the week after work, spending 37 hours in total on the project. During planning phase I expected to finish the core game in 24 hours and use the rest for polishing and additional features. Knowing that I was on time and keeping track of how I was progressing and how much more I had to do, I was able to work at the right pace and without building tension.

Godot. This is more of a shout-out, but still I wanted to mention that Godot is a great open source engine. As my goal was to have a product, not only a tech-demo, using an engine was imperative and Godot 3.2 delivered on all accounts.

Lessons Learned

Thanks to all the planning (if there is just one thing to remember about this post i this: plan ahead!) I didn’t experience major conceptual problems, but I had to contend with a couple technical issues that others may experience.

Freeing objects takes a lot of time. I experienced this issue with the procedural map generation algorithm. Every time you go from one map to another (especially from the overworld to a dungeon), the game froze for several seconds. I didn’t want to put a loading screen in between stages and, honestly, I didn’t understand why it was taking so long. After a bit of profiling, it turned out that the game was taking 5-10 seconds to delete the tiles (around 4 thousands on a 64 by 64 grid) from the previous map before generating the new level. I tried a few solutions and at the end I solved by not deleting the map in between but instead resetting the tiles’ variables and overwriting them. This worked like a charm at the cost of some added complexity during refresh and setting up some safeguards to ensure that smaller maps wouldn’t overflow into the larger residue objects from the previous ones.

Animation in turn-based roguelikes are way messier than you would think. My naive implementation of the game loop (and I mean from a software perspective) works like this: every frame check is the current actor is idle (not moving, not attacking, etc.) and if so then have it perform its round and recalculate initiative for the next frame.

Here is, I believe, the problem. Say we work at 60 FPS, then a full cycle of 12 actors takes 200 milliseconds. If movement takes 400 milliseconds then the whole turn, assuming that every actor acts immediately, is 600 milliseconds. For my human player it means that my movement will be delayed by 200 milliseconds each turn, which is definitely noticeable.

I wasn’t able to solve this problem in time, so expect some stuttering while playing the 7DRL version, I have a couple of possible solutions though. A deceitfully easy one is to have all actors have their turn during the same frame, but this creates a bunch of headaches if your actors changes (e.g. someone dies or is summoned). A simpler but partial one is to not animate creatures not in Line of Sight, this would probably be acceptable even when there are a lot of enemies of screen...

Test your game final settings as you go. I discovered the two issues above when I moved from my test configuration (very small maps, few enemies) to the final one, i.e. not many hours before the deadline, so I had little time to fix them. Next time I will make sure to plan for some tests with the final configuration since the beginning.

I hope that this has been informative to you, thanks for reading.