Postmortem: Shallow Stone Solar

For several years now I've wanted to try the 7 Day Roguelike Challenge. Often when it occurred to me, I already missed it. This year I committed to completing it. I even took a week off which got changed to half-days due to important meetings. Still many people completed it without taking time off I imagined.

I struggled on a game idea for a while. An updated Crush, Crumble, Chomp seemed like a promising idea but I found someone had done that in a previous 7 Day Roguelike Challenge. The game used character graphics but was so well done I didn't feel like my implementation would add much. I continued to think about giant monsters and mecha but nothing inspired me.

Meanwhile I played Deep Rock Galactic with a friend. My wife thought it looked fun but she couldn't join as it doesn't support couch coop. It made me think about a roguelike interpretation of the game. I hadn't done socket networking in a while but figured I could get it working. The scope needed to be very limited to complete in seven days.

What went wrong?

1) Time Spent Badly

I spent a day trying to get the server to start automatically and creating a text input screen. Starting the server automatically was ideal to get players into the game. Unfortunately it took a long time and still doesn't work on Windows. I would have been better off focusing on making the game fun to play. Lots of planned features were cut like reviving fallen companions, loading minerals into a carrying droid, multiple enemies and multiple weapons.

2) Lack of Planning

I wasn't sure what game to make up until very close to the start of the game jam. I thought of using libtcod but couldn't compile it. My big concerns were lighting, pathfinding and map generation. I intergrated third party code for lighting and map generation but pathfinding proved more difficult. My initial attempt didn't work and I couldn't figure out why. I settled on just implementing Dijkstra's algorithm myself. Unfortunately that led to a day of tracking down bugs in the code.

3) Artwork

The title screen was simply black with the menu. There wasn't even a title shown. Every player used the same image. The winning screen consisted of just a text message. More time should have been devoted to this polish. I didn't have eight direction movement for the ant but I should have at least turned it around when it goes the other direction.

What went right?

1) Lighting

I found multiple lighting implementations. The permissive-fov seemed the easiest to integrate. Discussion suggested it might not perform the best but that wasn't likely to matter giving the power of current machines. Initially lighting was simply a 41 by 41 square. This covered everything on the screen. On the last day I decided the pervasive lighting was ruining the combat. In the evening I replaced the lighting and add in glowsticks. It greatly improved the final product.

2) Network Play

I know most people will probably not test network play. It did add significant work to implement but it was the game I wanted to make. The network code was not great. The protocol was designed haphazardly and doesn't attempt to prevent cheating.

3) Good Enough

For my first game jam, I wrote highly maintainable code but didn't finish. This time I kept the minimum viable product in mind. While I did some poor time management, most things were designed for that end goal. I did keep in mind future ideas but I didn't over prepare for them. I also didn't leave tasks to very end. For example combat involved targeting and damaging the opponent but it also needed sound and visual effects to feel complete. I tried to make sure things were in a usable state before moving to the next task.

What can we learn?

Time management was critical to game jam success. I didn't manage it as well I would have liked it but I did complete the game. It was important to keep my goals in mind. I tested the game a lot during the jam. Play times were longer at the end because of how much more fun it was.