Vestige Bound

What is it?

Vestige Bound is a procedural narrative RPG focused on travel. You play as a caravan that has to traverse a hex-grid world, survive hunger and cold and fight bandits in turn-based combat.

This was a long project that I and a fellow student worked on in parallel to our studies at University in 2018-2019.

Overview
  • Engine: Unity
  • Language: C#
  • Platform: PC
  • Development Time: 9 months
  • Team Size: 2
  • Role: Programmer/Designer/Artist
Notable Tasks
  • Moddable Game Architecture
  • Serialization System
  • Level Creation System
  • Overworld AI behaviours
  • UI

Postmortem

Introduction

I suppose many game developers carry around stories of the games that never made it to the finish line. For me, one of those stories is of a game I worked on called Vestige Bound. I worked on it together with a fellow game programming student, next to our studies, almost every day for about a year. Why? Because we believed in the idea and we were digging ourselves further and further into a hole.

What I hope to achieve with this postmortem is to reflect on mistakes made as to learn and not make them again.

On Ambitious Games

As a game developer student I have received a multitude of different advice from developers in the industry. And more often than not, most of them are entirely contradicting. One example of this is the “Make something simple.” and “Be ambitious.”. One side means that the important thing is to ship something while the other means that shipping something without vision and ambition is pointless. We decided we would try to do both, of course.

The Concept

The project and the idea was conceived from a feeling. Something I had heard developers do before, and I wanted to imitate them. The feeling I chose; the feeling of travel, of being on the road. I think there are several games that do this incredibly well. Notably 80 Days (2014) by Inkle and the oldie but goldie Oregon Trail (1985) by MECC. I wanted to capture this feeling in a more open game, but one that still did not stray too far from the core concept of travel. Vestige Bound was therefore to capture the harsh caravan life of Oregon Trail and the interesting story events of 80 Days in one Civilization-esque hexagon world.

In the game you had a party of four travelers (one of them being the player). It was also composed of two different game states: the Overworld, for traveling, and the Combat Mode, for fighting any enemies on the road. In the Overworld the player could wander to any place they would like, pick up missions and supplies in towns, and fight off wolves and bandits in the woods. At any time, an event could happen to the player. This was represented as a text screen, very much inspired by similar gameplay elements in 80 Days and Crusader Kings II (Paradox Interactive, 2012).

When actually meeting an enemy, the Overworld would trade places with a zoomed in, much smaller world acting as a type of arena. Here the game suddenly became a turn-based game featuring your four party members, all with their own unique abilities.

In the Overworld one had to think about the hunger and temperature of the party members. The player needed to keep a regular storage of food and adequate clothing, especially when venturing to colder or warmer climates.

The goal of the game was never truly decided. Every other update the game changed from having a specific destination at which point the player would win the game to not having a goal at all and back.

Lessons Learned

The main lesson learned from our time working on Vestige Bound was “testing”. We worked on the game for a very long time before it was even playable and at that time we had really never tested the game either on us or someone else. We developed the game only from an idea without any anchor in reality. And who knows, maybe it is possible to do this successfully. But I doubt it. It was impossible for us to know if the game was fun, or if we were even going in the right direction without having tested it frequently. When the game finally became somewhat playable we realised it was so boring and so far down the wrong track that it was too late to do anything about it.

So why did we not test? As I mentioned in the beginning I think it was a too strong belief in the idea of the game. We even voiced concerns during the project that it hadn’t been tested, but we thought “What the hell, it’s probably going to be fine.” Famous last words.

Ultimately I think having vision and grand ambition is fine as long as one realizes that something in one's head can sound a lot better than it actually is in reality. Now, whenever I have an idea, I ask myself: “Ok, it’s ambitious, that is fine. But can you test it early on? Is it playable within the first few days or week of development?”. If the answer is no, I throw it away. If the answer is yes, the worst thing that could happen is that I’ve wasted a week, not a year.

After this lesson, “testing” is a word echoing in my mind when working on any and every project.