Quick And Rough Thoughts on Game Prototyping

Animators use quick rough sketches of key poses. Artists use thumbnails. Successful comedians practice their jokes with a smaller audience first. The equivalent of quickly testing your ideas in games is prototyping. Here are my thoughts on the process.

Forget About Your Game Idea, Start Prototyping First

Recently, I’m discovering new methods of doing things that differ from how I used to do them. I used to worry about having the right idea first, then once I had the idea I’d move onto paper design, before going through the usual process of prototyping it.

These days I jump past the idea and paper design stage and start prototyping right away. I find, I’m able to get results faster because what I’m able to accomplish in the game engine more resembles what the final outcome will be. My paper plans and designs tended to be too ambitious and were difficult to complete in-game.

I find that as I’m building the initial code base and I’m able to actually see and interact with things on screen, I’m able to visualize things better. This often leads to fun little design surprises that emerge as well as additional ideas which I can just tag on and keep as part of my design or keep for later use on different projects.

Lay Down The Foundation

So instead of having one defined idea before prototyping I start with a list of specific questions or challenges that I’d like to see tested. I keep a running list of possible game mechanics I’d like to implement. This list is generated through quick brainstorming sessions, observations based on real-life interactions,  and notes generated by playing games and looking for cool fun challenges to explore. (that’s cool, lets see if I can do that). Then proceed and try to get something similar in the game engine (Unity3D at the moment)

My idea at this time is that if I can prototype a collection of different game mechanics which play and feel good on their own. Add extra variation to it as I’m building it. Then mix, match and combine different game mechanics together. I’ll be able to create something that is fun and a solid starting base I can build on.

Hack It While You Can

I don’t consider myself a natural programmer and anything with programming is pretty much self-taught. So a lot of what I do is hack. It’s not pretty, but it accomplishes few things. It enables me to test mechanics quickly and have others to provide initial feedback soon after starting. I’m aware that as time goes on and the design solidifies I’ll have to come back and improve the code, but its something I deliberately keep rough during the prototyping stage.

Another thing I don’t spend too much time on initially is my art assets. Since using final assets will slow me down. I use basic primitives such as cubes, spheres and cylinders to get me as far as possible in proving or solving a specific problem or challenge. I would never commit to modelling, texturing or animating a full character until I was completely sure how it worked based on initial in-engine tests.

So in that context, a character becomes a box, an environment becomes 4 scaled boxes. Enemy might be a red box and a collectable pickup might be a yellow box. Whatever works to prove or disprove a concept is fine at this stage. I’ve been through the process enough times to trust that the final art with time will improve and if enough time is spend on it, it will reach its visual target. At this stage, the quality of my assets is not important.

Keep The Momentum Going

Keeping things rough does one thing that I think is important, it keeps the momentum going. One thing I try to do is move from one problem to another quite fast during the prototyping session. If there is a problem that I think I’m spending too much time on. I try to leave it behind and move on to another one.

Oftentimes a little time away from a problem could work wonders and a solution often comes when you least expect it. The worst thing for me during prototyping is getting frustrated by getting stuck on one particular problem and loosing the momentum.

One thing to be careful of is to not get too attached to what you’re doing at the prototyping stage. If something doesn’t work. Or you think it will require too many resources to complete, don’t be afraid to drop it and move to another challenge.

Prototyping As An On-Going Process

As I’m moving forward I’m trying not to think of prototyping as a one off thing before a game project but more like an ongoing practice. Building up a collection of game mechanics ranging from very basic to more complex in a rough, quick form I think has value. As I build this collection up I’m thinking more long term, a reservoir of resources which I can tap into in future projects or as needed.

What are your thoughts on game prototyping?


6 Replies to “Quick And Rough Thoughts on Game Prototyping”

  1. My personal opinion as an engineer is, whether “natural” programmer or not, quick hacks should generally not be avoided, as long as they can keep the momentum going. I see seasoned programmers at work start with intuitive and possibly messy implementations first to gather feedbacks from other people / coworkers, while stealthily embracing their stubborn-minded massive refactoring at night, or whenever time is allocated.

    Presumably it’s quite important to see a more or less working result especially for games that likely more than half of participants including artists would want visual feedbacks as some kind of eco-fuels for themselves. :-) I’ve been working on a small iOS side-project for my company for about 2 months and I think hacky tricks work quite well for getting colleagues involved. Refactory can be painful or even drown me in the future, but hopefully we’ll survive to see software’s constantly changing nature conquered this way. :-)

    1. That feedback you mention from other people, co-workers or just from seeing mechanics/interactions on screen for yourself, is so important. Especially in the early exploration stages.
      I’d like to mention that when working on a team project, there are few considerations to keep in mind from a production point of view. It’s now easier to get something “working” on screen. A producer/project manager needs to be aware of what’s underneath the prototype, and make sure he doesn’t underestimate the time it will take to get it done properly during production.

  2. Great post, Tomasz – I’m in a similar boat, as I make my living as a freelance game designer with a specialty in extremely rapid (1/2 builds PER DAY) prototyping. I’m currently working with one of the top-grossing free-to-play iOS & Android developers here in the SF Bay Area. I will work with them to flesh out a concept and iterate on it until we extract that ‘nugget’ of feel, and then it gets passed on as an interactive design doc to the ‘real’ engineers. Which underlines your point – a prototype IS NOT production code. IT IS MEANT to be thrown away. This is something you have to be really clear on with your client / PM up front, and then force yourself as an engineer to stick with. I’m constantly fighting the temptation to refactor things into reusable APIs – which I do, but ONLY when I’m choosing to spend the time that way. It should be kept very distinct from the prototyping task, and that’s harder to do than it sounds. Sometimes you’re just ITCHING to pull things out into a new dll while you’re writing. ;)

    The one takeaway I would emphasize for your readers is implied in your post – find a toolset that lets you write the game code, not the infrastructure. There are tons of engines out there, which are very design-friendly. Unity is a great one for web / PC. If you do mobile stuff, pick one of the ‘native wrappers’ like PhoneGap, AppMobi, Appcelerator Titanium, or even Unity, and make sure you’re spending your time tweaking the gameplay, and not writing infrastructure. You have to be sensitive to whether you’re writing code that is of maximum value to the prototype, or if you’re just ‘building the foundation’.

    1. Hi Aaron, thanks for this very informative comment. One phrase you use which I know exactly what you mean, and have done it myself but never put it to words that way is the “interactive design doc”. It makes so much sense. Traditional documentation can only get you so far before it gets outdated and falls apart.

  3. Just a quibble– this is not the true definition of hacking.

    Hacking is not hackwork. Hacking is also not systems cracking (the other usual misuse). Hacking involves a very deep understanding of hardware internals– something that you do not have if you are not a “natural programmer.”

    There are no natural programmers. But there are people who are really fascinated with what they are doing. In the old “Data General” definition of the term, these people are hackers.

    Then there are people who are not. What these people do is hackwork.

    1. Thanks for pointing that out. In these terms, what I’m referring to is hackwork ( quick, unoptimized, inefficient) code that gets you eighty percent there. Provides enough visual feedback to be able to accept or reject an idea/game mechanic quickly.

      Mind you this is all in the scope of prototyping on a gameplay level. If and how the code will be used will have to be determined post prototyping.

      Having said that there is a lot of software out there running on crappy code.

Leave a Reply

Your email address will not be published. Required fields are marked *