Expedition Revival - Trash the Complexity

From my blog at racingspidergames.com/devblog I figured I'd throw this here as well. It is a bit long - but gets into a little bit of the details of my development and some of the hurdles that we throw in front of ourselves.

Expedition Revival – Trash the Complexity

So, I’ve learned a ton of things about game design in the previous months. Expedition:Beyond the Walls was a project that I had high hopes for, lots of extra quests and new loot and a cool unfolding story – all adding to the previous stuff, gaining a virtual mountain of grand adventure!

The game itself is fun – but with a steep learning curve as well as entirely too many effects (each with their own image) – they were set on “dice” but the player never got to choose which dice he would throw. So, I set out to make a revised version of the “roll to move” concept and I ended up with 4 different types of dice that are rolled depending on the number of dice you chose. Some of the results were repeated through the dice – and ‘encounters’ could be drawn if one of the dice showed the proper icon.

I thought I had something great going on there and I talked to my good friend about it. He’s pretty ace at game design and he said “Why not have the crew AS the dice instead of a bunch of attributes?”. We brainstormed for about two hours, and afterwards, three different game ideas that I had were boiled down into two game mechanics.

Just like that a new game, based on Expedition (the dice game) and based on two other ideas I was wrestling with combined in a beautiful, elegant game design. The rules are simple, flexible and screaming for additional expansions.

We’re making a ‘board game’ version of it, with real dice and cards for the initial prototypes, and hopefully we’ll eventually find a publisher for it. In the meantime, I’ll be testing the ideas in a multiplayer version of the game for iPad.

While it won’t be precisely Expedition:Beyond the Walls II, the game mechanics will definitely support any story we choose to put in front of it.

I had previously torpedoed myself with increasing the complexity of a game system simply because I didn’t think long enough on how a simple solution would encapsulate the idea. I’ve tried simply making simulations of the effects I wanted with an eye to realism first.

This blew the crap out of many of my ideas as I added complexity as I designed. A terrible habit and a real game killer. Now the that core mechanic is nailed down, we’ll explore some advanced ideas.

I’ll post pics and details of the physical game when we get the prototype dice and cards finished. I’m terribly excited about a project that boils down a pile of cool ideas I’ve had and distills them into some fun, quick, exciting and epic all at the same time.

On the Failure of Expedition:Beyond the Walls

As far as iOS games go, E:BTW isn’t an outright failure. It’s still in the App store, selling a few copies here and there – the lite version is also out there getting downloaded daily. It certainly failed my hopes – and it did not, by far, approach break-even as far as my commitment in time.

Not a grandiose vision of a game, E:BTW’s core mechanic was a series of dice rolls. The number of dice you choose determines the “base number of days” for that series of dice. Add in re-rolls taking an extra day and you had a solid system of tracking time.

How it Failed

First off, the player had no clue, when he selected 3 or 4 dice that there WAS a difference in days. He didn’t know that re-rolling was ADDING a day as well.

Secondly, it was not immediately obvious how much food would be consumed in the series of dice rolling. One food per day, per crewman. Great – the mechanic was there – but if he didn’t know how many days his rolls were taking then he wouldn’t know how much food was being eaten until it was eaten!

29 different icons for different effects. They were chosen from “normal”, “uncommon”, “rare”, “very rare” and “encounter” dice. However, if you rerolled a “rare” die, it could be replaced with an uncommon or normal die – this game mechanic made no sense since the die choosing was completely out of the hands of the player – in it, he had no way to manage risk/reward.

Other issues, such as the near-total black-box nature of the encounters conspired to keep the player at a distance from the game. For instance, when the ‘beastman’ encounter was resolved, the player only saw the general effects of the battle – whether anyone died and whether they trashed the enemy or not.

To attempt to resolve that, I put in a verbose combat log for the encounters at Irrik Ek – and while it increased immersion, it was too little too late.

All-in-all, developing an iOS game was a wonderful learning experience, I’ve learned a great deal about what makes a game. It’s something we all know, but sometimes forget when we get into it and delve into all of the “what-ifs” and “wouldn’t it be cool to…”.

Grab those ideas and boil them down, or mark them for later and go with what’s simple but yet conveys the message. There will be time in the future to expand the system. This is the lesson I’m fighting to keep in mind for the next game. If you keep it in mind too while working on your next project, you’ll only benefit from it.

Keep it simple, expand later.