View RSS Feed

Slothy

Prototyping for dummies

Rate this Entry
So last post I mentioned having six general rules I planned to follow for designing the strategy game I'm making. So of course I had to break at least half of them with the first prototype.

The basic structure of the game in the very first version was two opposing teams square off with the objective of destroying the others base. Each team got money at the start of each round that they could use to either buy more units, or research higher level units. Each player could make a certain number of actions per turn (movement, attacks or both though the number each had escapes me now) The map was, and still is a straight forward square grid, and unit stats consisted of five fairly straight forward values:
1)movement
2)health
3)range
4)number of attacks per turn
5)damage
And finally, attacking was handled by each player rolling two d6 with the high roll winning and ties going to the attacker, for each attack the unit could make that turn. When the attacker wins a roll damage is dealt, and when the defender wins a roll they evade the attack.

So first things first, I broke the simplicity rule already. Attacking was too complicated with most units having two or more attacks per turn, which meant a lot of rolling. Except that this didn't even occur to me when making the first prototype, and I was still in the dark after the first playtest for reasons I'll get into in a bit. More importantly though, at this point, each unit was represented as a small circle of paper and a card listing it's stats and health with damage tracked by placing pennies (or any other kind of marker) on the card. Now I can see how I might miss the fact that the method for attacking was more convoluted than I thought, but imagine a board filled with little circles of paper, and then having to reference their team colour, class, and number to a card to know what the hell they can do and how hurt they are. It took all of one turn to realize that a system I had designed to allow for easy modification of the units completely neglected the fact that the game needed to be easy to play.

On top of that, we could throw the idea of a broad variety of strategies and anything resembling depth out the window. I had only designed the human units so far, and only six of them (there are eight now), and in retrospect only four of them were even balanced well enough to be useful or interesting (bye bye rule six). But we're getting ahead of ourselves again because I didn't even figure that out in the first play test, and to be honest it wasn't something that was going to shake out in the first pass at the game anyway.

In fact, the first playtest only lasted ten minutes and taught me two valuable lessons. The first was that the units and their cards sucked because you couldn't look at the board and immediately know what was happening. The second was a little worse though. When I was deciding unit and research costs and how much money to give at the start of each turn I played it safe. I didn't want games to last too long because there was too much money floating around, so I tried to work out costs and income so that you couldn't have too many units being bought each turn. And lo and behold in my efforts to play it safe I failed miserably and there was still too much money floating around, and to compound the problem the distance between bases was too wide. After three turns my wife and I called the first game quits because there was literally too much money for the game to ever end. By the time you made it half way across the board both sides had such large enemies that were so incapable of killing everything in play or even moving past the other force effectively that the game never would have ended.

So my first prototype was of a game that was un-winnable, needlessly convoluted and not even remotely fun. But had I not made this horrible mess of a game I never would have figured out that the units needed to convey more information on the board, how I needed to rework the economy to make the game winnable. In fact, if there's one lesson to take from this for anyone thinking about making a game it's prototype early and playtest often. My game looked great to me on paper, but no matter how good you think the design is, your first prototype is likely going to suck and it's only through constant revision you'll get something playable. I'll go into some of the revisions I made and how they played out next time, but suffice it to say that even as the game kept getting more fun, it still took about two months before a game actually ended without myself or my opponent deciding to call it a night.

Point is, had I waited until we had a game engine and sound effects and art work, we'd still have a crappy game, even if it did look nicer than the circles of paper I'm still using to this day.

Updated 09-23-2010 at 11:55 AM by Slothy

Tags: game design Add / Edit Tags
Categories
Uncategorized

Comments

  1. Peegee's Avatar
    :D
    wow... :D
  2. Slothy's Avatar
    Hmm, is it just me or can I not find an edit button. Anyway, where I said "attacking was handled by each player rolling two d6 with the high roll going to the attacker, for each attack the unit could make that turn," it should actually read more along the lines of each player rolling two dice with the high roll winning and ties going to the attacker.

    I guess that's what happens when I make a post late at night while also very angry at my wife and trying to suck down a late night plate of spaghetti. Makes it a little hard to concentrate on what I'm doing.
  3. Shlup's Avatar
    Hover over the title, and the little "edit" pencil should appear.
  4. Slothy's Avatar
    Much obliged Shlup. My blog post is now more coherent than ever.