Skip to content

MKW: Pushing a Prototype 2

June 30, 2009

Tonight, I played the final push of MKW’s core system (see the article on the second push if you haven’t already), and it worked.

At this stage in the prototype, literally everything could still change. If I change something that blows up all other rules in the game, so be it, provided it’s the right thing to do. Making a game (a good game, let’s hope) means that you sometimes have to do a lot of backtracking. You need to re-write, re-design, re-test stuff that was perfectly functional because the right way to do it came along. It’s just how it goes. Mercy killing is the law in game design. Sometimes, I find people fret about that, thinking they wasted all this hard work. It’s never wasted. It was necessary to get to the center of the game. Besides, you will use it somewhere. Othertimes, people hang on to these crashed systems, and band aid the right way to the old way just to keep it alive. This ends up creating a game that is loved by its designer alone. And their mom.

As I noted after my last prototype push, due to a change in how one resource was distributed, I effectively destroyed the economy of the game during the test. I couldn’t come up with a solution on the fly, so I ended the session and played another game instead.

When I refer to economy, I’m not strictly referring to just the financials in the game. In any system, all stats are controlled by a single controlling figure. It all boils down to that. In FPS’s, it’s HP (bullets = negative HP, med paks = positive HP). In many RPGs, there are two controlling figures, gold and XP.  Every system has a base value, and everything needs a controlling statistic. (This officially fulfills part of my promise to cover RPG system design to Ian Schreiber.)

So, this morning, I woke up with an idea that might fix the problem I had created, and it’s that idea that I wanted to test tonight. In essence, I wanted to release the resource into the game such that no particular player had at advantage when it was released and secondly, I didn’t want to make that release random. If the game is to be one of brain-vs-brain, any random elements needed to affect all players similarly. A die roll, unless that same precise roll affects everyone, doesn’t cut it. For what it’s worth, there are no dice in the game.

We did three rounds of this central gear, and on the second round, I could feel it. It had potential. It had the right dynamic. The surrounding math wasn’t working, so I divided by 2, and that felt better. Take that to heart, by the way. Dividing/multiplying by 2 is the solution to solving your economy problems in games. Really, and I am not even close to the only designer who thinks so. If I feel like I am way off, I divide/multiply by 10.

So, having had that basic design challenge resolved for the time being, I stopped the prototype to get feedback. The next step in my process will be to compile the rules into a formal set (what one would consider a full playable), think through the economy and loose ends some more, and ultimately drop on the second gear. The second gear is another system in the game that overlays the one we tested tonight. If you have played a game like Puerto Rico, you get what I mean by multiple gears. Basically, there are things that happen every turn. There are also things that happen every round. I make sure the first gear is working before layering on the next.

Another note on this prototype – when I said that I woke up this morning with the idea, that’s quite literally true. For many years, I have worked exactly like this, what Ian Schreiber refers to as “black box design.” I stuff as much information about the problem into my head as I can, and eventually, the answer will rise. It’s hip when it happens first thing in the morning.

2 Comments leave one →
  1. Chris Pioli permalink
    July 1, 2009 1:47 pm

    Thanks for the candid reflection on iterative game design. I always hate how – whether in programming, game design, et al – I know I made a mistake and have to undo some of the rules I’ve established in order to see a competent game through. One of the more humorous anecdotes I’ve heard like this is Miyamoto-san’s “upending the tea table”, or literally starting a game’s design over in order to better incorporate new game mechanics and components. It’s similar to remodeling a house – is it worth it to make all these new additions onto the house, or wouldn’t it simply be better to create an entirely new one? Constraints of old architecture can hinder prospects of new additions.

    Come to think of it, there are probably lots of games out there with good premises that were unsuccessful because the developers/designers were too scared to backtrack/start over (then again, it would be hard to do that when there are budget constraints and deadlines).

  2. kayleigholiver permalink
    July 6, 2009 10:17 am

    By developing my own small game I’ve recently understood the importance of developing a prototype and refining the mechanics and formal elements of the game before trying to develop a digital prototype.

    I’ve read and understood how to prototype a FPS, RTS, card game and board games but if I wanted to paper prototype a platform game how would I go about it?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: