The origins of Hexpand

My first semi-serious attempt to make a computer game was many years ago, about when I started making a living as a programmer. My job back then was completely unrelated with games and, like most programming jobs out there, it was quite dull to be frank. I wanted to do something more inspiring and challenging. Of course, I made the same mistake every one does: I was overambitious.

I have always been fascinated by strategy games, so when one day I convinced one of my friends that we should give it a try and make one of our own, we chose to go for an RTS game. To be more precise, what we had in mind was something like this:

Here, I dug up some screen-shots showing how far we managed to get:

Image of a rover Image of a rover Image of a rover

Not very impressive, right? Definitely nowhere near what we envisioned.

What I have learned, the hard way, is that trying to make a AAA title all by your self and your buddies as your first game will guarantee your failure. You are about to get overwhelmed by the sheer complexity of the project, discouraged by the slow progress and poor results of your efforts and chances are that you will finally give up before you have anything playable.

Pretty common sense you might say yet people keep making the same mistake again and again because everyone wants to make something awesome! And because they underestimate the task at hand. It doesn’t matter how good your game idea is and how great programmer you are. If you haven’t made a game before it’s better to start with something small first. Let me stress this a bit more:

Start Small!

Hexpand is not exactly a new project either. I came up with the concept almost 3 years ago. Based on my previous experience I was trying to figure out what would constitute the minimum set of game-mechanics that would make a strategy game interesting enough yet simple to implement. I got my inspiration from some of the classic board games, like chess, Risk and stratego with a twist of hexagons instead of squares for the board (yeah, I know, I have a mild obsession with hexes).

The starting point was to define what I was considering interesting for a strategy game.For me it had to be a game that would include a certain set of features:

  1. Units with different roles in the game. Usually those roles derive from the unit’s abilities and/or movement. The easiest way to achieve this is by having more than one types of units.
  2. Basic resource management. Each player has to gather some type of resource and use it to achieve the games objective.
  3. Creation/Deployment of new units. In many games players start with a fixed amount of units that gradually are removed from the board as the game progresses. I wanted the players to be able to introduce new units during the game and replace those that were lost. Also this can be easily combined with the resource gathering feature.
  4. Execution of more than one command per turn. A simple way to introduce more options to the player and make the game a bit more challenging. Especially if there are different types of commands like moving a unit or creating a new one.
  5. Commands that are issued simultaneously by each player. This feature allows to easily convert the game to a Real Time Strategy one without changing the core gameplay. To achieve this each player has to be unaware of the other player’s commands until the end of the turn’s interval which also adds the element of imperfect information to the game.
  6. Emphasis on control over the map. In most strategy games the control of the game-board/map (or specific parts of it) is an important but sometimes implicit objective before achieving a winning condition.  In Hexpand that was made the main objective and there is a new mechanic to determine the relative power of each army on the board and how that affects each unit.

Looking at all the above it might seem like a complicated game, surprisingly though it is possible to achieve all that complexity with merely 3 types of units and the classic paper-rock-scissor mechanic adjusted a bit to take into account the level of control over an area of the map.

Shouldn’t I just be re-building an existing game as my first attempt?

Well, maybe. Re-implementing an existing game is definitely a good approach to dive head-first to game development without having to do any game design yourself. There are so many tutorials out there that show you how to develop yet-another-asteroids-clone (Andre Lamothe’s equivalent of “hello world” in games) and it is the best way to get your head around on a game’s architecture and all the intricacies of it’s development process.

The reason I personally didn’t follow that approach was because I really like to design games! It is something I enjoy doing and I didn’t wanted to exclude that part of the process from my first attempt. I opted for a simpler design instead and chose to work on a development platform that I know quite well to offset the extra effort it takes the development of a computer game.

Besides I already have that design now and it is always so much more motivational to work on something new that you just want to try and play it yourself. Time will tell if that was a good or a bad choice.

This entry was posted in Uncategorized and tagged , . Bookmark the permalink.