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.

The house with no doors

Wooh, spontaneous midnight blog-post!

This post has nothing to do with game design. It is a narrative experiment and a small brain-teaser, to anyone remotely interested in sci-fi and scenario based planning. It's simply a literary exercise that I've decided to document in public.

I was inspired by the idea of life receding into a black hole-like existence, as our computers become ever more compressed. Is that why the universe is so silent? Did everyone who came before us, simply recede into their own little houses of compressed spacetime, then drew the curtains? While the question borders on philosophy, it's fascinates me that we might one day have an answer to it.

I have deliberately mixed up “I”, “you” and “we”, to indicate the “ebb and flow” of the narrator’s existence - sometimes one, sometimes many, sometimes someone else. It is also synonymous with the three components mentioned in the text: Time, presence, increasing complexity. The “I” is the known. The “you” is the unknown approaching. The “we” is coming to terms with the unknown. Literature is fun!

I've even scraped up some fitting music for the read, if you can read with lyrics playing in the background. If not, I recommend trying a double-take: Read first, then listen to the music and skim the text again. You'll get the gist of it. God damn, how I love the way aesthetics can emerge from combining music and a story:

__________________________________________________

Our universe has always intrigued me, for reasons both obvious and obscure. What more breathtaking than the breath itself? The fact that we are here to take it, to perceive it in some way? To use that breath to fuel our continued existence, through which we observe the passing of time?

Time.

We emerge from time. Emerge to be the onlookers, to ask a riddle: If there is none to observe, is there nothing to observe? We cannot be, when there is no passing of time. Yet the passing of time is only there, because we interpret it to be so?

When we look underneath the microscope or up into the stars, we see patterns repeating. Just as we emerge from the passing time, so does something else - something that has defined us through the ages, yet only now does it creep out from the dark.

When we power our computers, we stare it blankly in the face. The ones and zeroes converge and out comes a brilliant picture. The ebb and flow of electricity sparks this beautiful mechanism into existence. On and off, on and off. We know this pattern, we’ve seen it before. What we see in our creation, the machine, has been there since the dawn of time. Now it is collapsing - parts combined, bigger than the sum of their parts. One, zero. One, zero.

On and off. That is the pattern.

We see this pattern when we look into the ocean, the rise of waves, crashing onto the shore. The only evidence of their existence lies in what they leave behind.

Ebb and flow. We’ve seen it before.

We see this pattern when we look down far enough, splitting the atom then splitting the pieces until suddenly; there it is again! Presence, absence.

Being. This concept cannot be without time. It emerges from it, as do we. 

Being, as we are.

But I wonder, will I see this pattern when I look beyond myself, up into the stars? Are we the wave, crashing onto the shore? If so, where is the rest of the ocean?

Our reality has a third component, beyond time. Beyond being and not being.

It vies to always increase in complexity.

This is most evident in our machinery, in the enslaving of the electron. Everything shrinks, yet everything grows at the same time. The smaller the processor, the more powerful it becomes. Is this the future of information? To shrink out of existence, until we can barely observe it anymore? Will it run away from us or will we find a way to keep up?

I think of a window. A window in a house with no doors. Just one window. You live in this house. You used to be people, you became the machine. Then you became so much more. You are everyone that ever was. You are god.

You look out of the window sometimes, but can hardly be bothered - you are god; you make your own existence. So what’s worth looking at, out there in the cold?

No one can look back at you. Your window only exists on the inside of your house. You can look out, but no one can look in.

Your house is a black hole. Your house is the universe. This is the ebb and flow of existence.

Life burns brighter than the brightest stars, until it sets the world on fire. Before the life burns the world, it builds a house: A machine so complex, so compact, that it can only exist within the compressed confines of a black hole. Here we live on, sometimes taking a small peek out of the window, but never more than a glance. For inside the house, we are the creators of our own existence.

In here, we can’t be bothered with our younger kin, who still stumble around outside. To invite them in would be to destroy them. They will live, they may die. They may build their own house one day.

We sit in our house of time. Our house of presence and absence. Our house of infinite complexity. How can the outside ever intrigue us again? Therefore, we are silent. Therefore, you are on your own.

Yet perhaps, if you were to look down far enough. If you were to split the atom, then split those pieces apart, again and again, you should have a glimpse - not of us, but of who came before us.

Of those who lived in a house like ours, before we even existed.

____________________________

EEEEECH, this was fun to write, but now my brain is telling me to catch some Z's. Hope you enjoyed the read.

~ Dave