18 May, 2016
In a recent comment, Tyrannodorkus (who plays in my weekend tabletop group!) asked: “I’m curious how you do your mock ups? Do you make a working model program, or create a pen and paper version to play around with?”
So, let me talk a bit about prototyping a new game mechanic.
Not that prototyping an individual mechanic is a little different than prototyping an entire game. When prototyping a mechanic, you can explore it from multiple angles. Prototyping a whole game, however, usually requires you to pick a smaller slice of the game. Game developers often call this a “vertical slice”, where you prototype a bit of every mechanic in the game and see how they work individually and together. I’m focusing on the individual mechanic in this post.
The first step is, of course, the concept. The motivation for the concept can influence the concept. For example, if you’re motivated to solve an existing problem in a live game you’ll have different motivations than solving a problem that is merely anticipated. An existing problem has a problem state you can observe, which will shape the concept.
So, my initial concept concept for the goal of replacing hit points was to develop a new combat system that better modeled the flow of actual combat. Instead of treating each weapon blow or spell landed as damage to a large pool of health, I wanted to simulate the back-and-forth nature of finding advantages and putting your opponent at a disadvantage. I also wanted to have fighting multiple enemies take more attention, as with fighting in the offline world. Note that the goal wasn’t to create a perfect simulation of melee fights in the offline world, more to draw inspiration from for a new approach.
The mental work
Okay, you have a general concept and goals, so now comes some thinking. I think this tends to be different for each designer, so take this description as how I approach it rather than as a dictum about how it shalt be done. Depending on how you prefer to work, you might just skip to the next step, but I prefer to separate out the feasible ideas from the infeasible.
For me, I imagine the system in an idealized sense. How do I use the system? What inputs are available? What information and feedback do I get? What situations would I get into? What variations would be in the system? What problems do I anticipate? These aren’t intended to be exhaustive or detailed. If anything, it’s to do a “sniff test” to see if the idea is remotely feasible and worth pursuing. I might do a few sketches of potential UI or graphs to measure related things.
So, for replacing hit points, I might consider: what would it be like to fight one enemy? What input would I give? How would I measure the flow of the fight? Now, what happens when I add 1.. or 2 more opponents? Well, the information might get a bit crowded, but we can worry about UI stuff later, right? :)
The paper prototype
It’s called a “paper prototype”, but it doesn’t have to be just paper. Some designers have a kit they keep around for prototyping ideas. You don’t have to get that fancy, a bunch of post-it notes and a whiteboard will generally suffice if you’re not feeling artsy and craftsy.
The goal here is to get a bit more specific with your idea after you’ve done the mental work. That UI might all seem to work fine in your head, but trying to place all the different elements down on paper can show the flaws in your thinking. Or maybe show that you have a lot more room than you first thought. It’s also a chance for you to actually start working out the mechanics. What elements do you need? What happens when you make a decision?
At this stage you’ll be executing the game rules by hand, which can be a bit tedious, particularly for computer games. You’ll probably want to simplify some elements of how a computer game will work, but realize that doing so means you are glossing over some important elements. You also need to keep in mind that your prototype is not the real thing; for example, you will lose the tactile elements of a prototype once it gets translated to a computer. But, this prototype helps you flesh things out a bit more.
So, back to our goal of replacing hit points. I don’t remember the specific system, as the prototype I made was on an old computer I’d need to drag out. But, let’s come up with a simple example: I might decide that I measure advantage as a number from -100 to 100 (with higher numbers being more favorable to the player), and I have stamina that ranges from 0 to 100. A target might have three wounds that can be scored when at a disadvantage. Abilities can have four parts: advantage value required (e.g. can only be used if advantage is positive), advantage gained/lost, stamina gained/lost, chance to inflict a wound. I might create a few simple abilities and see what happens when they’re used. I might try to create the full full system with abilities, or I might do just enough to understand what happens in order to code the thing.
The actual prototype
So, we’ve gotten some basic elements defined, we’ve worked out the mechanics, now time to make the prototype. For a computer game, this involves coding and often programmer art! The goal is to get a better idea for how the thing will work in the medium it’s intended to be in. For a computer game, this means letting the computer take care of some of that tedious math instead of working it out by hand, especially if you’re using things like logarithmic scales or exponential functions.
After you make a successful prototype, there’s the eternal question: Use this code or discard it? Using the code means you have a head start on developing the game. Instead of taking time to re-write what you’ve already done, you fix the code up as a foundation for the work. The reality however, as any programmer will tell you, is that prototype code is often bad code. You’re more interested in trying things out and making rapid changes, ignoring things like efficiency and maintainability. That code might become more of a liability than an asset to getting things done quickly. Sometimes it’s better to throw that old code away, take the lessons learned, and start fresh and make entirely new mistakes.
For the hit point prototype, I got some simple art and defined five abilities. At the time, I was talking with someone who “wanted to help program games”, so I gave them this prototype as an exercise to see how they would do. (Let’s just say I had to finish the prototype myself. I find a lot of people who think they want to do games quickly get scared off when they find out it can be fairly hard work.) But, once I got the thing working, I just didn’t find it very fun. It felt like the back and forth was a bit too back-and-forth with no resolution. I didn’t build in enough things to adjust so to fine tune the feeling. Changing some of the values to try to force a resolution faster made it feel like all-or-nothing. Adding more complication to the system felt like I was losing sight of the original goal, and replacing it with something a lot harder to “read” than hit points.
After you finish the prototype, time to analyze it and do a little post-mortem. What went right? What went wrong? What could be improved? What lessons were learned? Is it worth doing another prototype? Is it worth implementing the concept? You may choose to iterate more, you may think it’s time to throw in the towel.
For the hit point replacement system, well… as I said, not really. The system had a bunch of flaws I needed to work out, particularly in conveying information to the player. But, it really is hard to do better than the simplicity of the single hit point bar. But, as I said, some years later (and possibly wiser) it may be worthwhile to revisiting the system anew.
A customizable system
As I hinted in the second section, different people work different ways. A programmer working a more technical design may dive straight into code, drawing in libraries and snippets collected over the years. Groups may spend more time on the concept, brainstorming ideas, recording them, winnowing them, and picking the things that make the most sense to try out. The mental work might be in the form of vigorous design debates where some people pick the idea apart while others defend it; both sides may be done by a single person, even! :D The “paper prototype” might be rather involved with wooden dowels and wood glue being involved, particularly if the finished form is going to be a physical game instead of a computer game.
If you’re a new designer, my recommendation is to go through each of these steps as a discrete process. Figure out what works and doesn’t work for you, and improve the process for the next time. As I like to say, know the rules before you start breaking the rules. :)
What do you think? Have you prototyped a game concept before? What worked or didn’t work for you? Also, feel free to ask questions in the comments, or via email if comments don’t work.