Postmortem: It always starts simply enough
Last week I mentioned that I would be writing about Wallachia, the game prior to our current one. It’s a longer story than that, actually, as this didn’t involve just one game but a bunch of related prototypes. While I’m uncomfortable with the finality of calling this series a post-mortem, the fact is that project as I was doing it is dead. But the tale is in the telling, and I’m getting ahead of myself.
It all starts around January 2009.
Stick to what you know, is the motto. Some similarly good advice is to build something for yourself. In my case we would have at the top of the list:
AI is something that I can use on anything I’m building. Now, I’m sane enough to realize that a proper rpg (proper being defined as the type I like ) is out-of-the-question insane. It would seem that the next item on the list are board games.
And what is more boardgame-y than hex grids?
Around that time, Thomas, a 3d environment artist with whom I was collaborating on and off, mentioned doing a game based on different heroes racing along a branching path for a rune that would grant them absolute power. We threw some ideas around, geared towards random events and enticing people to take side roads (risk vs reward). There was no gameplay design, but in case it helps give you an idea, when I later encountered Talisman it gave me the impression Thomas had wanted to move along those lines. He offered to create some placeholder hex tiles with road connections on them for me to test, so I started working on randomized board generation. There were some fun experiments, and I’ve already chronicled some of the approach in a past article (which includes a maxim I have to keep re-learning for some reason).
That specific project didn’t get too far. There wasn’t any gameplay defined that I could implement, and Thomas seemed to be a bit fuzzy on where he would want to take it, so we shelved it. I moved back into doing AI contracting for other companies, leaving production and gameplay design in their hands, which was a refreshing change.
A few months later he talked to me about a different project. This time it was a spelling game with a pirate theme, since he said word games did well on the iPhone. I wasn’t really interested in word games or the iPhone, even if we did have some cool features for it, but I liked the idea of working on a game about pirate ships, so we decided to take a stab at writing one for the PC based (once again) on hexagons.
I’d continued experimenting on and off with procedural hex board generation, so bringing those experiments to bear I quickly had a basic terrain generator. The approach could be summarized as:
- Pick a spot on the empty map
- Select a random terrain type to begin filling the area
- Allow that terrain to spread out until its randomness-influenced fall-off rule tells it to stop
- Pick a new tile, repeat for a few iterations
- Do a pass on the tiles bordering the water, giving them a high likelihood of being turned into beaches.
- Leave the unused spaces as water tiles
Side note: I was writing this, it was funny to run into Shamus Young’s posts on his Project Hex , as his approach to creating terrain isn’t that different from the one I was following.
The fact that the game revolved around ships simplified a lot of things – for instance, there was only one tile type that ships could cross (water tiles), and height differences in land were merely decorative (as you couldn’t get off the ship). Everything was basically one flat board.
Once again, it was an engrossing technical experiment, but as we had done no gameplay design at all (other than tossing random concepts around, mostly based around trading), there was no game. Thomas got sidetracked to make a FPS prototype, which is a genre that doesn’t really appeal to me, and I continued working on the board generation and steering code (which would later become UnitySteer ).
It doesn’t really take a Sid Meier to see the common thread on both projects above: they started with a theme, not with gameplay. This was evident even as I was programming the technical tests, but the love I’ve had for procedural generation ever since I saw my first L-system just pulled me to focus on the technical stuff instead.
So our lesson for today is likely obvious, buy very easy to lose sight of: it’s not a game unless there’s gameplay.
This was the first thing that jumped up when evaluating what had gotten those attempts derailed. Neither Thomas nor I are professional designers, nor did we know how to get one involved (even if I would personally have embraced the chance). Both tests were approached with unspoken expectation that the gameplay would present itself, emerging from our experiments, but the gameplay fairy rarely just swoops in to sprinkle magic gameplay dust all over your project files. We also had some differing opinions on where to take things, and the nature of informal collaborations is such that we had no clear mechanism to settle those differences.
Looking back on that original article about the test roads on hex grids, I can’t help but smile and shake my head at the naiveté on display. For instance, the whole reason I was looking into procedural generation for it (other than my infatuation with it) was that:
To keep it fresh, we want to have many different boards available.
Right-o. We didn’t have the gameplay defined, but we knew we wanted to have lots of it. But moving right along…
For the next project I decided that I would attack both issues head on. First, I’d start with the gameplay design – I still wasn’t a game designer, but hell, it wouldn’t be the first thing I taught myself. Second, I decided to fund directly the parts were out of my skill set (for instance, art) to be able to have a clear direction in which things were going to move. I went as far as deciding I wouldn’t even program an approach until I had tried it out on paper, to avoid chasing after shiny procedural tests.
We’ll see next week how that worked out.