From idea to reality

Quick introduction:

The article written in this blog was originally drafted when I had a couple of students tossing around ideas with Undefined Games. Writing it made me realize how fundamental this type of understanding is not just to game development, but user experience- and software design in general. Which is why I highly recommend you give this one a read no matter where you plan on making your entrance into the industry - even audio design.

Speaking of audio, I'm just going to toss today's reading-track right in there. You know the drill; listen while reading to drown out the world. Or don't. Your choice.

If you're at all acquainted with the process of trying to get your ideas from paper into a real, tangible game, you have probably encountered this feeling: No matter how awesome your idea felt when you came up with it, if you kept working on it, it started feeling really rough. Eventually it got to the point where your brain went - "look at all these other great ideas I've had in the meantime! I should just make one of those instead."

At that stage you quit what you were doing, enthusiastically going head-first into your new idea. The previous idea has now been filed in your brain-cabinet under "learning experience." And with what you've learned from that, this new idea is going to succeed without a doubt! Right?

Unfortunately, that's probably not going to happen. The reality for many people who go through this rigorous "rinse and repeat" process, without examining why their ideas collapse, is that they'll eventually get completely stuck and loose motivation to work. We all want to see our ideas come to life, but it requires more than just the inspiration to see that through.

"Many things can be learned through trial and error! Some things, however, are better off learned through theory. Or you might end up making mustard gas, thinking that you're making fancy-pansy salt crystals (yes, this actually happened somewhere on the internet)."

That is why we here at Undefined Games, have decided to create this guide, where we will talk about the actual process of going from paper to product. By the end of reading this, you'll hopefully feel inspired to go do something awesome.

Getting an idea:

We're going to start from the absolute beginning: the creative process. Now I'm going to go straight out of the way and begin by clarifying; creativity is a skill, it is not about being "born" with it. Imagine what a terrible world that would be if some people simply couldn't express themselves because they weren't "born that way." Let's all be happy that the world is a much better place than "haves" and "have-nots."

But I'm still a musical genius!

This means it all comes down to hard work. But I'm sure you've heard about that before. We all know that one talented bastard from somewhere in our lives, who claims that "practice makes pudding" or some such. That's just a friendly way of saying "lazy people can't have nice things." Harsh.

Luckily for us all, however, it's not all about hard work. Hard work in itself hinges on having the mentality for hard work. If you don't have that, then you can't just go do it! If someone tells you all there is to it is hard work, it's because they assume that you are already able to think like them. That's really what we need -  the right mentality.

Let's get to the practical stuff, though - how to hack your brain and force yourself to be creative!

Boil it down and this "hack" is very simple: Know what questions to ask yourself and you'll be farting out ideas like you had innovation-beans for breakfast.

When it comes down to it, designing something is about overcoming an obstacle, solving a problem. These obstacles can always be refined into questions that need to be answered. It is very important to note that these questions are for your team as well as yourself. I'll come around to why asking these questions openly, is an important part of the process.

Here's a few sample questions, to give you an idea of how you have to think. These kinds bulletpoints will also be what you present to your colleagues:

• How can I make E.T. for the Atari 2600, an actually playable experience?
• How do I make a drama about the migration of birds?
• How do I make a boardgame to teach the users about quantum physics?

If you look closely at the problem-sets above, you'll notice that they are isolated instances: I have not listed possible solutions to any of them. This is for a very good reason! When you think of a question, you will quite possibly, immediately, have some ideas as to how to tackle them. But when you present the questions to you colleagues, they should be isolated at first, before you present your answers later. This is deliberate:

If you present someone with possible solutions, alongside their first encounter with the questions, then people will commonly lock into your answers. This means that you may unconsciously limit the imagination of everyone else, by presenting an easy way out, before the brainstorming has even begun.

Writer's block is no joke. I'm having one right now.

So you put your questions out, let people mull over them - either on their own or in groups, whatever they prefer themselves - then meet again and go through the answers. By this point, you might run into a situation where conflicting answers both seem great. That's good! File one for later and focus on the most realistic option for now. There are no bad ideas, just bad contexts for ideas, so saving weird stuff might help you later - maybe even in a different project.

"I solemnly swear that I will ask the stupidest questions, as they are only as dumb as the person who reads them."

It's all a matter of interpretation. We do this process to kickstart our braincells, not to write poetry, so ask away (although if you can ask your question with poetry, I'm sure you'll get some street-cred). You might also realize that you aren't asking the right questions to begin with, which commonly happens. Maybe the questions weren't wide enough, as being too specific is also limiting. Another brainstorming session, focused on getting better questions, should remedy this problem.

How to not make a game:

Now we're past the idea phase. This is where most people are when they jump into game development: "This sounds awesome, I'm going to make it a game!" Not so fast! This is where a lot of new developers take their first misstep into oblivion. If you have an idea it's very important that you begin by asking yourself this question:

• "Is this really a game idea, or is it a narrative idea?"

If you want to be a designer/game director (same thing, different levels of control, mostly), your career quite literally depends on you being able to tell these things apart. And that goes not just for your own ideas, but for any ideas that might potentially be part of the final product. But how do we tell these apart?And even more importantly - how do we transform a narrative idea into a game idea?

The key difference between an idea for a game and an idea for a narrative, is that a narrative idea is not limited by the constraints of production. Whoops!

But this is still perfectly logical, by most user standards.

To make a long story short (no pun intended), a purely narrative idea is a story with all the bells and whistles that go with it. This is awesome if you're writing a book, but an absolute nightmare if you're making a game. You can paint great, borderline insane sceneries and worlds in a book, because the brain just conjures them right out of thin air when reading about them. If we could just conjure games out of thin air the same way, that would be great - but we can't do that.

If we don't consider whether or not we can realistically produce an idea, we'll dig ourselves into a hole. Even worse - we'll get started on the idea and well into production, before we realize it can't be done. And that, ladies and gentlemen, is when projects end up as "learning experiences" and companies fall apart. Maybe you realized that the technology to simulate millions of units on screen, simply wasn't there yet. Or perhaps your art team couldn't draw a dead weasel even if their lives depended on it. You have to know all your strengths and weaknesses, both skill-wise, economically and in terms of current technologies, before you can really be confident about producing a game within your "comfort zone."

Loop-de-loops:

Welcome to my world. Here is the one thing I use to smash ideas into shape, until I can extrude them into some playable form. I call it reiterative risk mitigation. It's awesome, it's brutal, it's the secret sauce to not having your games implode.

• Iteration; "the act of repeating a process, with the aim of approaching a desired goal."

To rephrase; you're going to throw out a lot of content, boiling down your ideas until only the best bits remains. But that's good, because nothing is ever thrown out for no reason. For every piece you remove, you come one step closer to the essence of the experience you aim to create.

Reiterating is repeating something while gradually changing it, based on what you learned from the previous repetition. This is what game design is, at its core.

You obviously have to think about alternate possibilities, if your ideas are not up to the test. If it broke or was boring, we go back into the thinking-box. If we can't think of any good solutions, we remove it from the game. BAM! Sean Bean-style.

Filled with arrows, thrown off a cliff, shot in the face, 
head chopped off and quartered by horses. Will he ever play a role without dying?

But before you throw something into the pit to be drawn and quartered, it's important that you analyze what went wrong. Where did it fall apart? Why did it happen? Is there some way it can be tweaked to meet the same level of quality as the rest of the product? This data is invaluable, even if you throw out the content in question, as you may still use it to improve your next iteration. The more you know, the better.

Once you become capable of following this test/re-test process as if it's second-hand nature, you can really start going crazy with experimentation.  Some of the most original games are made from the craziest ideas, after being cooked down to contain only the best parts of said ideas. You never really know where you end up, right when you start. It's like Cliff Bleszinski once said: "Designing a game is really like playing with an ouija-board."

"Except, maybe, for the fact that game design doesn't rely on
dyslexic ghosts in order to work."

Different levels of prototyping and risk-mitigation:

Prototyping is the very core of iterative design in games. Each iteration is, in essence, a prototype. Prototypes are individual segments of your game, simulated individually to gauge the functionality of each part, before putting them together.

 But here's a little surprise; it doesn't have to be a piece of program.

A prototype can just as easily be bits of dialogue, concept art, individual mechanics that can be simulated in board game-esque fashion. Whatever isn't constricted by ones and zeroes, might just as well be prototyped outside of the digital space (if it takes less time than making the digital prototype, that is). You'll also have cases where it's feasible to emulate it outside of the digital space, but reiterations would be quicker if you make it digital immediately. It's all up to you as a designer/project manager/responsible person, to figure this out for yourself.

If we're to summarize the definition of a prototype, we can cook it down to the following sentence:

• A prototype is an attempted answer to your risk-mitigation questions.

To clarify, a risk-mitigation question is simply to ask yourself "under our current circumstances, or in general, will this even work?" To give you an idea, here's a few risk-mitigation questions that might make a good foundation for developing prototypes. These are just random examples:

• Will people even like our characters?
• Can the current, most wide-spread technology, handle our program properly?
• Does the storyline make sense(eg. no plotholes, sensible progression etc.)?
• We want a high risk/reward turn-based combat system, does our current model satisfy this term well enough?

Note how only one of these questions would actually require you to write a program, in order to answer the question. Many prototypes are written on paper, and most programs are as absolutely barebones as they can get. When making a prototype, only create the absolute baseline necessities required to answer your question. This saves many a valuable hour in production time, saving you money in turn and increasing the quality of the product(more money = more time to spend on stuff that works for sure).

Right until you run the hell out of money.

Also try to prioritize your questions, as much as you can. The answer to one question might invalidate even asking the other question. Try to find out what's most fundamental and figure that out first.

Rounding off:

I hope reading this article, especially for newcomers to the industry, has given you a more solid view into what's going on when making games in a more professional context (when money is involved). Just always remember that time is money, so the more time you can cut off doing unnecessary stuff, the more time you'll have available for stuff that matters.