Voyage

I made a game!

Recently I’ve been doing short personal game jams, because getting something finished quickly does not come naturally to me. 

For the first one I made Voyage, a roguelike about assembling a caravan of medieval fantasy voyagers with various traits and then deciding how to navigate a series of threats en route to a destination. I love the concept of caravans generally, something about preparing meticulously for unknown threats and then having to survive in the unknown with nothing but what you brought is deeply intriguing to me. Building a game to capture that has been on my mind for some time, and while I don’t think Voyage is that game, it’s a step.

For each game in this series of jams, I am trying to stick to a time budget of 3 afternoons worth of work. Voyage ended up taking 4 or 5 afternoons. On one hand, I’m trying to learn efficiency and planning in order to fit the whole development process into a set time budget even if it is very short, and so I intend to hit the 3 afternoon mark on my next game. On the other hand, about 20 hours of work is well within the standard 48 or 72 hours weekend jam, so I feel good about being able to complete one of those in the future.

Most importantly, I learned a lot from the process that I don’t think I would have learned from a months-long project.

The biggest learning was iterative design. I have a penchant for up front planning, which causes me problems and excessive anxiety when trying to nail the perfect design on paper under time pressure. For this project I jumped right into implementation with a loose plan, and just tried to get to something playable as fast as possible. Once I got it into a playable state, I was shocked at how glaringly obvious the next steps were. Obviously you needed to be able to run away from encounters sometimes, otherwise the game feels unfair. Obviously voyagers with mixed abilities are more interesting than specialists who are only good at one thing, I should lean into that. Obviously the most important sound effects were selecting cards and passing encounters, that’s where I missed sound the most when I was playing it. The list goes on, and I couldn’t see any of those from just the design doc. Making something bad and playing with it until it’s good led to a much more fun game.

It exists, with lots of room for polish

The restricted timeline also forced me to practice a ruthless efficiency that I hope I can apply to larger projects. For example, each voyager had a number of stats with integer values one to five. I spent a few hours building a system that would take any set of stats and dynamically layout icons for all of the stats. It only took an hour or two to get working right and I’m pretty happy with the results, but generating a text box with a number would have taken two minutes and gotten me to something playable much faster. I might have ended up making the same icon generator in the end anyway, but I locked myself into that choice way too early. The flip side of that was a tool to export voyager and encounter stats from a Google Sheet into the game (mostly) automatically. That was time surprisingly well spent. Being able to iterate on game values comfortably made me much more inclined to spend time tuning the game, which made the game much better.

There were countless other lessons in the visual design, the code structure, Unity setup, etc. etc. It was also a lot of fun. I plan on building more games quickly, and hopefully the lessons from the early ones will show in the future developments.

Download here: https://regoradin.itch.io/voyage