Prototyping

IMG_8383 No, we're not making a card game. At least, that wasn't the intention, but frankly, we might as well.

When you're making a game, it's really hard to fight the urge to "just start making the game". You have some idea in your head of what you want, and you're sure it's all going to work out & be awesome & work just the way it does in your head.

The problem is that your head is a damned dirty liar.

It's really easy to underestimate the amount of "handwaving" your brain does when you're trying to think through a concept. (Yes, I'm aware brains don't have hands.) If X, then Y! Clearly! But realistically, it's not that - it's If X (and Z, and B, and D all line up just right, and the player isn't G, Q, and B), then (maybe maybe maybe there's a miniscule chance of) Y!

The big problem here is that it's very, very difficult to anticipate where you're handwaving and where you've thought things through in an actually effective way, because until you can see the experience from a different perspective, you'll effortlessly handwave the same problems away over and over again without realizing that's what you're doing. So rather than trying to minimize the handwaving, which you can't, you have to try to gain additional perspective, which you can.

Many times, that means people want to just start building. After all, the only way you'll see the finished game is to finish the game! And a lot of times, you really want your handwaving to not be an issue, so you'll be happy to ignore it until the game is done. After all, it's not a failure that needs fixing until you see it, right? That's certainly one (very, very expensive and slow) way to approach things, and I'll tell you - having described it, and hearing how terrible it sounds, you'd be very surprised by how much of game development is still done this way.

One of the most important things I learned in school, where I was learning to be a mechanical engineer, is how fast the cost of making changes blows up. Consider the following stages of building a product:

  • Have an idea: Changing the idea = $0, no time
  • Write up a plan: Changing the idea = rewriting the plan. $0, an hour or two
  • Talk about the plan with other people: Changing the idea = rewriting the plan, telling everyone else about changes, a day or so.
  • Prototyping: Create new prototype, plus all the crap before this step. Week(s)?
  • Manufacturing: Retooling, communicate with vendors, all of the above. Months. Hugely expensive.
  • Shipped to Consumers: Recall, all of the above, months, if not years of time, probably screwed & costs now likely to exceed everything you've spent to produce it thus far. Good luck!

Basically, the earlier you can make changes the better. Obvious, right? But again, the problem is that this is difficult to do, because you don't necessarily know where problems will occur. And you're right. You will almost always have *some* problems. The key is trying to answer/solve as many of them as possible as early as possible.

So for a game, what does that mean? In some cases, it means you'll have to write some code & try stuff out. But for a surprisingly large amount of stuff, you don't have to write any code.

For us, we're trying to figure out how to create a short gameplay loop where two entities come into some sort of conflict with each other. How can we resolve this under the following circumstances:

  • It has to be quick: <2 minutes per encounter
  • It has to be simple: Anyone should be able to learn the rules in one or two sessions
  • It has to have skill variance: If I am "better" at this game, I should win more.
  • It has to have elements of randomness: Randomness allows for longevity & unpredictability
  • It has to have the ability to evolve over time: I need to be able to play this 100 times & still have something interesting happen the 101st time
  • It has to be fair(ish): Neither player should feel like they're in an unwinnable situation
  • It has to have consumable elements: Certain parts of the game are fixed, but certain parts will evolve based on what the player brings to the table. Those elements are "consumed" through use, and players must go out and get more stuff to bring to the next encounter.

There are a billion different games you can make that will satisfy those requirements. We picked on, and built it out of cards. A deck of standard playing cards (the Pandantè cards aren't quite standard, but they are very nice), a second, blank deck of cards I could write on, and a pair of dice.

Because I had a list of things I wanted to accomplish in this game, after writing down some rules, and trying it out with other people, I could see if things were working, or if they had problems.

The first play session took 20 minutes. That was fine, because the first sub-2-minute rule is for a computer-aided version of the game. So added time accounting for stuff because we didn't have a machine doing the scoring was fine. But it wasn't simple - there were too many things to juggle, and even I was getting confused. Which was surprising, because on paper, the rules were pretty trivial. It was also unclear "how to win". That is, I knew what the victory conditions were, I just couldn't figure out how to play "better" than my opponent.

We played a few more times, just to ensure the problems weren't because we were trying something brand-new, and some of the problems remained.

Back to the drawing board, and because some elements of the game worked (in fact, almost the whole "core" experience was fine), we just needed to address the areas where we were having problems.

The "custom rule" deck was simplified. A single card with a single rule (The "Combo" card in the picture above) was left on the table to remind folks this rule existed. Instead of using part of the deck to create the "encounter", a pair of dice were used, which meant that what was left in the player's decks were more predictable. We cut a whole section of the "long-term evolution" elements of the game, and left those for later. In the process we understood that the evolutionary aspects of it were better handled outside the encounters than inside them, which made the encounters much simpler.

In the course of 2 days, and probably 4 hours total, we did between 3-4 iterations on this element of the game. Doing this involved making some significant changes to how the game worked, which would have meant that prototypes would have needed more than just trivial tweaks per iteration. It cost us a total of $15, for the blank decks of cards, and we have hundreds of additional cards to keep iterating with.

The interesting thing to me is that I talked with a potential investor the other day, and they were curious where in the development process we were, and if we had anything playable yet. Yes, we have something playable. It's just probably not what you think it is.