Psychochild's Blog

A developer's musings on game development and writing.

18 May, 2016

Making the prototype
Filed under: — Psychochild @ 10:49 PM

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 concept

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.

The analysis

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.


« Previous Post:





5 Comments »

  1. I have a little python library (still under development) that allows me to represent a character as stats + skills. I can then use it to simulate how tweaking a stat affects the average outcome of skill use, etc.

    I haven’t done that part yet, but I intend to build a simple N-person combat simulator on top.

    Either way, by tweaking the numbers for stats, skills, and using different dice mechanics I can compare one set of mechanics with another.

    Statistical information doesn’t quite tell you how a game feels, but it does help with tweaking difficulty or comparing one mechanic option with another.

    Comment by unwesen — 19 May, 2016 @ 12:31 AM

  2. I second the value of fast prototyping.

    One related practical (and only mildly cynical) note on prototypes: never show them to anyone.

    No one else can “see” the Platonic ideal of gameplay inside your head, for which the prototype is only a shadow. They will see the prototype and think it’s the goal. Then you’ll either have to explain how it’s not the goal, but spending the time and money to create it had real value, or you’ll be required (unless it’s a personal project) to ship it as the actual product.

    Never show them the prototype. :D

    Comment by Bart Stewart — 19 May, 2016 @ 10:52 AM

  3. Bart Stewart wrote:
    No one else can “see” the Platonic ideal of gameplay inside your head, for which the prototype is only a shadow.

    True, but this is the primary job of a designer working on a team: to get that ideal of gameplay out of your head and into a form for others to work on. A good designer should be able to describe mechanics well enough. Of course, it helps to work with experienced game developers who can see past the lack of polish to see the gameplay behind it to offer useful suggestions.

    Never show them the prototype. :D

    Depends on the situation. You might have to share your prototype with others if you’re working on a team. But, yeah, then there’s the risk of the prototype code becoming the production code to save time. :)

    Comment by Psychochild — 21 May, 2016 @ 11:19 AM

  4. So I’m actually wondering about even lower level than protyping/mock-ups: What about the actual core game design. Not the universe/story part of it, but the fundamental core of the design. How does one even get started? Are there any good books or resources on game design (eg: how to design the functional core of a game)?

    I have poked around numerous blogs and have read a lot here and there of tips about some small part of design (eg: walking through a level/skill/combat system implementation), but nothing yet so much on the bigger picture (eg: I have an idea for a turn-based sim that combines elements of this and that and the other thing, now what?).

    I realize this question is super-duper generic, but as someone who has a little bit of programming skill (and dreading getting to the coding part!) I am still noodling around with my first game concept (second if you count a board game) and am trying to wrap my head around how to flesh out the game design (system/concepts/function/whatever) more.

    Sorry for the rambles!

    Comment by Erik J — 30 May, 2016 @ 6:41 PM

  5. Erik J wrote:
    What about the actual core game design.

    What you’re talking about is usually referred to as “game mechanics” or “system design”. This is how the game will execute and how players interact with the game.

    I have a page in the upper right-hand side about Breaking into games. One of the link is to advice about game design at http://www.sloperama.com/advice.html

    One page in particular might help: http://www.sloperama.com/advice/specs.html This details what is required for a game design document. Really, the best way to understand what all goes into a game design is to read GDD. Keep in mind that not every project uses a document like this; some companies might use a wiki with cross-linked pages, others might just have a very informal document, and solo (or very poorly run larger) projects may not even have a document.

    Hopefully that helps. If you have further questions, feel free to ask. :)

    Comment by Psychochild — 31 May, 2016 @ 11:32 AM

Leave a comment

I value your comment and think the discussions are the best part of this blog. However, there's this scourge called comment spam, so I choose to moderate comments rather than giving filthy spammers any advantage.

If this is your first comment, it will be held for moderation and therefore will not show up immediately. I will approve your comment when I can, usually within a day. Comments should eventually be approved if not spam. If your comment doesn't show up and it wasn't spam, send me an email as the spam catchers might have caught it by accident.

Line and paragraph breaks automatic, HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Email Subscription

Get posts by email:


Recent Comments

Categories

Search the Blog

Calendar

January 2018
S M T W T F S
« Nov    
 123456
78910111213
14151617181920
21222324252627
28293031  

Meta

Archives

Standard Disclaimer

I speak only for myself, not for any company.

My Book





Information

Around the Internet

Game and Online Developers

Game News Sites

Game Ranters and Discussion

Help for Businesses

Other Fun Stuff

Quiet (aka Dead) Sites

Posts Copyright Brian Green, aka Psychochild. Comments belong to their authors.

Support me and my work on