On Starting a New Game Project

When starting development on my newest project Havencall, I did a lot of things differently than for games I worked on in the past, learning from my mistakes. In this post, I explain what changes I made, and why.

1. The Simplest Possible Version

Between 2008 and 2010, I worked on Aero Empire (AE), which was a massive project, combining 4 completely different styles of gameplay and an overwhelming amount of content. Our team had many ideas of what we wanted the game to be, and we did not want to give up any one of them. Aero Empire was never completed and is now on indefinite hold.

In comparison, Havencall is a much smaller, more focused project. But that is not because I had less ideas for the project to begin with. In fact, I have notes for it going all the way back to 2009, describing an epic RPG not so much smaller than AE. The first thing I did when designing the final version of Havencall was ask myself what the simplest, most compact version of the game design would be that still had the same feel and "heart" of the original. The answer was to make it a point and click game focused entirely on the protagonist and her adventure through the three worlds, rather than a complex RPG with many characters and storylines. All of the worlds themselves were also cut to their minimal form - the first world was meant to be filled with tons of space-time bubbles, each containing its own little town. Now the first world only has two space time bubbles with towns inside them, including Aura's hometown.

You might think that making all those cuts would ruin the game and its story, but actually the opposite happened. After really thinking about what made the core of the game and cutting everything else, I ended up with something much stronger, more focused and even more exciting. Looking back, a lot of the stuff I cut was actually just detracting from what I really wanted the game to be.

2. A Group of Friends

In today's internet age, it is incredibly easy to recruit strangers to work on your projects. That is exactly what I did with Aero Empire, ending up working mostly with people I had never met or even spoken to before the project. While AE had a lot of talented people involved, the team was not very efficient or focused. We would often lose or gain people, causing loss of unfinished work and requiring time to get new people up to speed on the project. Consistency was also a mess, with almost every asset created by a different team member. And when the project started falling apart, it was only those who I had a strong connection with who stuck with me until the very end. It was also those close team members who really got each other motivated and helped everyone else stay excited. 

To keep Havencall consistent and organized, I decided to make it with a team of three people I am very close with - I do all of the programming work, my wife does all of the artwork, and my sister composes all of the music. Even though our team is small, a lot of the time it seems like we are much more efficient than AE's large team - mainly because there is no lost work, no stepping on each other's toes, and we all trust each other. The bottom line is, a team that feels like a group of friends works much more efficiently and smoothly. And never underestimate the power of being able to meet and talk about a project face to face. More can get communicated in a few minutes of real conversation than you could imagine.

3. Planned From Start To Finish

There is a strong desire to just jump into a project once you have the basic idea down. All the details can just be figured out as you go along right? This is what we did with Aero Empire. The design document was rudimentary at best, and we often added or removed features without ever modifying the design document. This was very bad for two reasons: first, the design of the game was never fully understood - this made it difficult to make the game flow well and be consistent. The stages with their vastly different gameplay styles just seemed slapped together, without much thought about how they interacted with each other. 

We also did not realize how big of an undertaking AE was - we knew it was big, but it turned out much bigger than we imagined. This was largely because there were gaps in the design document that we overlooked because we did not fully understand the design. The other reason to have a strong design document is to keep everyone on the same page, with the same vision. Not everyone working on AE agreed on what the details of the game were, causing confusion, inconsistency and discord. And to make matters worse, when a new team member would join, the design document was not effective at helping them understand the project.

In contrast, Havencall has been designed from start to finish, with no gaps. All of the cutscenes, puzzles, and interactions are fully detailed. This keeps the game's design focused for all team members, and allows us to create something with tightly knit art, music, and gameplay, and a unified vision.