A retrospective on DeliveryRL

Download on itch.io and get the source on github.

I’m finally a few weeks out from the completion of my first real game I’ve ever made and I think I’ve finished processing most of my thoughts on it.

First, one week was a long time! I worked close to 90 hours on the game during this one week, including a final marathon session of about 18 hours. No matter how much I tried to plan for getting done in more reasonable sessions, I really got in the zone on that final night and decided to keep going until I was satisfied.

Second, one week is so little time! I got to the end of the week and was very happy with my result but had tons of unimplemented ideas, things I didn’t get a chance to polish. I was so glad I took two weeks off work for this, because when I got to the end of the first week I felt like like I was about to overflow with creative energy. My original plan was to spend the second week not even looking at a computer, decompressing, but instead I ended up implementing dozens of features and tweaks to my game that I had to put on hold in the interest of shipping. I also ended up spending a whole day learning OpenGL from scratch and writing go bindings to an SDL plugin that don’t currently exist. While that project is not done, it’s getting close. I finally ran out of steam and have had to take a bit of a break!

What went well

One of the most important things I think I did was maintain a stable schedule for working. I got up every morning at about the same time, 10 AM, showered, made myself a fresh and healthy breakfast, and slowly eased into the work day with a nice cup of coffee. I would also use this time to chat with my other participants on the roguelikes discord. It was super motivating to wake up every morning to all of the awesome progress screenshots my international friends were sharing while I was asleep.

I also live streamed several of my programming sessions. I had surprisingly good viewership on several of the days, sustaining an average in the teens and peaking at over 20 viewers during my final marathon session! While it was a bit taxing at times I think streaming really helped me stay focused sometimes. When streaming it’s a lot easier to not get bogged down in minutiae, as you want to keep the stream flowing and entertaining. This same mindset also served me well during the limited game jam time limit, helping to ensure I was focusing on small actionable chunks that would have a real impact.

Having a skeleton engine that I had built out before was a big help as well. While I ended up rewriting and deleting a ton of it it let me hit the ground running and start prototyping ideas without starting from zero. I think what I’ve got now would also put me in a much better situation for a future game that has similar requirements. While there are tons of places I know it needs optimizations, it is pretty decent for a first attempt.

The limited items and abilities were a big hit! The ended up being nice and visual, with fun monster interactions. People seem to really like them and I’m super pleased with how they came out.

What didn’t go well

I went into the game jam with an idea but not a plan. While this is totally fine, and usually expected I think having a better plan up front would have helped a ton. More importantly though, I failed to recognize the real problem with my game until a bit later than I would have liked. I think that’s not too surprising considering my total novice status as a game developer and designer! At the end it started to feel like I had dozens of balancing knobs to turn and everyone screwed up the calibration of the others. I knew it would be difficult to balance a game, but I did not quite expect how difficult! Especially during the game jam timeline there is simply not time to get adequate external play testing unless you arrange for them ahead of time, which I did not.

I didn’t keep a good priority list of things I wanted to do or thought were important. While I did maintain a few markdown files of ideas and glaring todo items I think I would have been much better served by a priority queue in a text file that was a list of everything I thought of doing. At the end I realized I missed several obvious cosmetic things that I could have easily touched up before the initial submission had I maintained a list. For example, I ran forgot to reskin the initial monsters I added to the game! I think they could be much more thematically appropriate. There’s not a single dragon whelp in a dragon cave! Perhaps that decision could be made deliberately, but in my case it was an oversight.

I wish the end result of the game design felt a bit more adventurous. Originally I was hoping this idea would lead me to a game that felt a bit more different from traditional roguelikes than it does while still maintaining the spirit. In the end it ended up a bit closer to classic roguelike gameplay than I would have liked.

I also neglected a few user friendly features due to running out of time. The initial build did not support easy screen resizing (you had to use command line flags) and you had to quit the game after you won or lost to start again. I quickly fixed those later.

My attempts at building the game with a more data-oriented design started to fall apart as the deadline got near. When you’ve got 12 hours left it turns out, much to my disappointment, sometimes it’s best to just check item name strings to implement a feature rather than redesign the entire item system. While you could file a lot of this under going well as a prototype learning project, as an end result the code base has several ways of accomplishing things, several of which I likely would never include in a more typical, production software system. However, everything seems to work quite well so I’m willing to call that a wash right now.

I also realized at the end I had a function in my display library that I called hundreds of times, that returned an error I apparently never cared about because I stopped checking it. Whoops? The error isn’t fatal and is mostly useful for debugging. The error is non fatal and would be a huge nuisance to check for every single call. Perhaps it should just assert during development time but be removed from actual release builds.

Mac builds were also a disaster. I could not get a working osxcross toolchain working for cgo and the go-sdl2 wrapper libraries. I don’t own a Mac so trouble shooting this/hacking around it ended up being a giant pain point near the end. Luckily a fellow participant offered to help and provide some builds at submission time to help the mac users out there. The week following the jam I ended up getting a functional build running on TravisCI. I really wish I had taken the time in advance to make sure I had a functional build strategy for all platforms instead of wasting half of a day in the middle of the week on it.

The result

Now that all that’s out of the way we can talk about the result! I’ve gotten great feedback and positive responses from everyone I’ve talked to that has played it. People love the theme. They love the pizza ascii art. Friends have shouted with joy the first time they throw garlic butter and watch it create a huge, delicious, and greasy oil slick or they get a wolf to take themselves out through self-damage from red pepper flakes! One friend, a completely novice to the genre, played DeliveryRL and was able to get his way to a win in just under an hour of repeated attempts. The mechanics were few and simple enough that he was able to do so all on his own, with zero help from me, he shared a recording of the process, I was not there at all! He learned to play and enjoy a brand new genre of game because of something I made. What an awesome feeling!

A few people have tried to perform up the difficulty via “conducts” such as no-warp and attempt to beat it this way as well. It’s much more difficult, let me know if you pull it off :)