An update from yet another Blogger-slumber!

I am so good with these unplanned blogging hiatuses ( plural = hiati?). Hello again everyone, I am still very much alive and well. I've been super busy with a few things, mainly working on my big sci-fi writing project called the Simultinuum universe. It was a mess for quite a while but a very useful and inspiring mess to me. Imagine like a huge box of really awesome Lego-pieces and a semi-finished instruction manual. It might sound far from done but I assure you the most important foundation is very much finished.

However, it takes time and money to create a full-length novel. Both are resources that aren't exactly overflowing in my direction. So I've taken the more accessible road for now, which is to write these pieces as short stories. That's not to say I've taken the core narrative and piecemealed it into chunks - it rather means I'm writing what I feel comfortable calling an "expanded universe". Not only is this approach good for the people who find an interest in my works, providing a much higher frequency of releases, but it is an excellent practice for me as a writer to flesh out my own works. I often feel like I find all the missing bits and pieces when I go through these short stories. They help me get more in touch with the characters I create and realize narrative potentials otherwise stowed away in my messy notes. Here's a bit that makes no god damn sense out of context:

“Sunken void between the realms, an ancient evil hides,

and if you look too closely friend, it twists around and bites.

It sings to you, seduces you, talk whispers to your ear,

its jaws will wretch you from this world, to drown your soul in fear.

It has no name, it has no face, it has no solid form,

but you can hear it deep inside, the chanting of the storm.”

~ Excerpt from Interdiction

Still, it'll be a little while yet before I publish anything here. I have a bunch of friends who are helping me through thorough scrutiny of every syllable coming out of my head, which is awesome. But I feel like I need to have some time going through that process, before I really dare putting it forward anywhere public. Of course not everyone is going to like a piece of literature, we all feel differently in one way or another about the texts we consume. Yet even with that knowledge, I feel like I have a personal standard I must uphold or I will have failed the readers, providing a sub-par experience in relation to my own expertise. I can only do my best, and "my best" is defined by my personal efforts to strive for the better - you get the point.

Here's my new favorite track:

The whole concept is - at its heart - purebred science fiction. There are elements of horror, comedy and plenty of exploration. Every single one of the stories feed into the same universe, forging the path for the eventual grand finale that is to become the proper novel(s).

I'm really looking forward to showing off some of the settings and characters from the boiler, so stay tuned. If everything goes according to plan, I can start churning out bits before you can say "Simultinuum."

Now I wish all of you a good night's sleep!

Writing a book (and random artwork by random artists)!

As some of you might know, I've been hard at work (for a couple of years now), working on a science-fiction universe and a handful of narrative arcs, that I feel appeals to both newcomers to the genre, as well as hardcore fans and science enthusiasts. It's been a lot of messing around, researching, interviewing scientists and trying to figure out how to even write a book in the first place. I've found much inspiration in all kinds of media, from Doctor Who to Dune to Deus Ex, Mass Effect and Star Wars (just to name a few). But now I'm approaching the point at which everything moves from being just the skeleton of a story, to actual, self-contained narratives. The characters begin to talk and interact with one another, and I'm starting to flesh out the environments, so that they make sense in the minds of the readers.

As I got started, however, I felt like an important element was missing, something very common in interactive media, but not so much in books - additional lore. But lucky as I am, Dune came to the rescue with an excellent solution: Prefacing each chapter with a small piece of literature, written by someone from the fictional universe I'm creating. And so I wrote a draft for the very first thing you'll see, in the very first book, which I now want to share with you all:

“It’s always interesting to compare the real post-AI Earth, to what we imagined it to be like in fiction. We often pictured the dark metropolis, or the weirdly low-tech spacefaring civilizations, who seemed to have forgotten the full ramifications of their own technology. But the truth is, our minds are bleeding into reality, and we are now aesthetically closer to what was pictured in fantasy, than we ever were to the cyberpunk dystopia. Yet the corporate culture remains.”

Excerpt from ‘The World in Retrospect.’

The plan for the books (which are currently laid out as a trilogy, but that may be subject to change, of course) is to create a technological and societal odyssey. We start in our near future, then move forward, propelled into the unknown to explore the potential mysteries and wonders we might ourselves encounter one day. It's a blast to write, I can tell you that. I hope one day you'll feel the same way when reading it - when I'm done writing in, say, probably 500 years.

Also here's a few random pictures from my inspiration folder, alongside one of my favorite soundtracks. All rights to the original creators of the pieces (sorry, authors, I'll add credits whenever I track you down), thanks for letting me stare at your work when I have my writer's blocks:

These are just a tiny portion of the artwork I use to get my head into gear. As you might have noticed though, it's all environmental art. So here's a few art-pieces I like to refer to for a bit of inspiration on the character design. Note that I very rarely just describe a character as-is from another piece of work that I've seen. I like to look at all the substituent elements that make up the character as a whole, then take each of those elements individually and see how I can stitch them together, to more accurately reflect the persona I need it to portray. Because of this, the following pieces are a bit more of a mish-mash than the environmental art, but hopefully it'll give you a small idea of what I'm trying to do. Just take these with a (heavy) grain of salt:

In case you are wondering about the bear, I'm introducing the concept of AI-enhanced animals. If we can improve our own intelligence with the help of technology, we're only one step away from doing the same thing to our pets, sometimes to hilarious effect.

Introductory semantics in game design and writing.

When you've been working both with game design and writing, you'll notice a pattern repeating itself. It's the "principle of procedural semantic introduction to unknown elements." A convoluted term (which I just made up) for a complex problem, but I'll cook it down to something digestible. At the core, it is about introducing an unknown element, through something that is already familiar to the user. Whether the unknown element is a strange new character in a written narrative, or a new mechanic in a game, the way they must be introduced - in the mind of the user - is actually the same.

And here's today's listen-while-reading:

What game mechanics and stories have in common, is that we must always begin with what is familiar. To understand is to perceive patterns, and introduction of unfamiliar elements, which root in the familiar, is a way to allow these patterns to emerge in the mind of the users. I'll begin with a theoretical example from my experience as a writer, to give you a better understanding:

Semantics in storytelling:

If we are to start with the familiar in a fictional place, we often start with the self, the narrator - our perspective into the story. W are self-aware by nature, so we will automatically relate to the perspective of the narrator, being our new "self" in the context of the story. I'll elaborate:

We typically have a main character whom we make understandable through their observations about the world around them, and their own emotional state in relation to what they think about. These are observations we can carry out on ourselves as well, so we quickly get a baseline to stand on in the narrative.

Next we must concern ourselves with the immediate environment, or other characters. Whether we prioritize one thing or the other (what character/part of the environment we start with), depends on what is the "least strange." Strange is really the keyword here, because it is a subjective measurement - and so it depends on the reader's initial worldview. If the environment is based on aesthetics that are commonly understood, it will be very easy to reference its visual and emotional (as observed by the narrator) foundation.

Obligatory breakup of article goes here.

When it comes to characters in fiction, we must evaluate them much in the same way: Observe which character is the closest to the classical image of "homo sapiens," then start with that. If you begin by describing the strangest characters (or the strangest of its attributes), your readers might get confused or misinterpret how they are supposed to feel about the character in question. This happens if you do not preface something weird with something relatable.

It is also very important to consider what you want to give the most weight in your story. If your environment is wildly different from anything you've seen before, and it plays a big role in your story, it is important that you introduce it as early as possible, when it is present for the first time (you might start someplace that isn't said environment). First impressions become our mental plateau, from which we must move out into the world.

Semantics in game design:

But how does all of this apply to games? The key differences between the two formats are: Games are visual, have audio and can be interacted with. However, they have one really important thing in common: The user!

Perception is everything, it is how we make sense of the world. Both in narrative writing and in video game design, we are handling the perception of the users - new information must be treated the same way, regardless of format.

If we are to translate that into something tangible, in relation to game design, it all comes down to interactions. A game mechanic is simply a way for the user to interact with the system in a certain way. Each time a new type of interaction comes into play, it is vital that we consider how it comes into play. There are a handful of steps that you need to consider, before you start throwing new mechanics at people, to prevent them from giving up in frustration:

This could be your users!

Does the game exist in an already well-established genre?

This is the first question we'll have to ask ourselves. If we aren't reinventing the wheel, we can always assume that the most basic interactions are already easily tangible to most of your users. We all know what "tower defense" implies at its base-level. You should still have some form of general introduction to this baseline - where to find the towers, how to build them etc. but breeze through these parts as fast as possible.

What mechanics are in play?

Here we'll begin to isolate what mechanics come into play. Remember what I said about mechanics being methods of interaction! It is very important that a new mechanic is introduced on its own, and that it is the mechanic most commonly used, which you introduce first. Every time you introduce a new mechanic, it should always be an isolated instance at first. 

What does the user already know?

To round that back into storytelling, the most optimal way you can introduce new mechanics, is to make the new mechanic play off of an old one. Consider what the user already knows, through what you've told them. Once you are aware of what they know, use that knowledge to understand what new mechanic is the closest related to the user's current understanding, to find out what they will have an easiest time understanding next. Note that this approach should be used carefully, it works best in very complex systems (where everything is introduced very rapidly), but it might not be fun to sit through in simpler environments!

Does any of your mechanics synergize?

Sometimes you have mechanics that synergize, interact with one another in an emergent fashion. If you have two mechanics that work on their own, but also can dynamically work with each other, you have three interactions - functionally, there are actually three mechanics. You will also have to teach about this interaction in an isolated environment, preferably by extension of the introduction of the other, new mechanic. So first you'll introduce the new mechanic - and then right after, you'll introduce how it synergizes with an already known mechanic.

How to even do this in real life:

After this mouthful the question beckons: How do I make sure my design adheres to these principles, during production?

I personally like to make a big map of all of the system's mechanics - every interaction that exists - and make arrows from one element to another, that each represents a semantic relation, which these two elements have in common. Do it as early as possible to keep it simple. This map will help you understand what mechanics make up the foundation of possible interactions within your system, which are the ones you should prioritize first.

But what's the use of this method?

If you map semantic relations in your system, you can begin to design new mechanics to deliberately exhibit more relations to current elements, than you would perhaps otherwise have considered. The map will allow you to see how the minds of the users unfold into your system. This, in turn, will allow you to gauge the best possible time to introduce something new, based on the current knowledge of the user.

Think of each element in the map as an "understood mechanic." When a mechanic is understood, all of its arrows pointing out to other mechanics, are effectively "activated" or "lit up." The more arrows that point to a yet-unknown mechanic, the easier it will be for the user to understand this mechanic, when you introduce it.

Leveraging this knowledge can allow you to build very complex systems, which is especially prevalent in simulators and advanced strategic games. Designing for these types of products can be a big challenge, but using this method should really help you get a long way. 

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

Risk and reward in game design

We've all been there before; committing to choice. These are the moments we remember as being the big decisions we took. Whether its in real life or in a game, risk and reward is about gauging good and bad outcomes against one another, killing you with worry and excitement at the same time.

Judging from the emotional roller-coaster I've just described this phenomenon as, you can imagine how powerful a tool it is, to anyone working with game design. From the designer's perspective, it's all about understanding what's important to the user at each moment, then using that knowledge to present an opportunity:

• Win and we'll reward you with important stuff. 

• Fail and we'll hit you where it hurts - because we know what matters and we'll take that away from you.

Arnold knows so, too

What's important about risk/reward in this sense, is that taking the risk is optional. It is in having the choice, that the choice lies. It might sound silly, but if there is no choice to not partake in a risk/reward event, then it is not about risk anymore, but an inevitable, random event, that might have a negative outcome.

Doing anything like the above paragraph, is bad for the experience: In removing the choice to participate, we restrict the freedom of the users, which overshadows the value of a potential reward.

But as you can probably tell, knowing about risk and reward isn't worth much, if you don't know how to emulate value in your product. A reward as well as a failure, should have an impact on the experience. The bigger the positive impact, the more value and vice versa for failure. But what's valuable, per definition? 

Today's tune:
Before we get to that, here's the usual music that you can choose to have playing in the background as you read. I chose this one because it's still winter, but we've hardly gotten any snow where I live. That makes me a little sad, it's almost like I'm not living in a Nordic country. Had none during Christmas either. Oh well, there's always another year:

Risk and value:

As a rule of thumb, there are two factors that determine value in a fictive environment: Scarcity and usability. We commonly apply both of these factors when dealing with currencies, but mostly only usability if we're dealing with new mechanics, that changes how the users can interact with the environment. However, scarcity may also be applied to mechanics in a multiplayer environment. For example: In Elder Scrolls Online, vampirism and lycanthropy (two new skill-lines that the users can acquire), have a high usability, but thanks to the way you acquire them, also a measure of scarcity. They're not easy to attain, and so therefore that has some inherent value.

But what about risk? What's interesting about risk, is that the possible failure it implies, is the polar opposite of reward. Instead of gaining potential, you loose it. We can use our measurement of "what is valuable," to determine what we can impact as designers, to make the users feel it negatively.

For example; in a game where you don't heal automatically, it suddenly becomes a much higher risk if you loose health upon failure. This wouldn't have nearly the same impact in most modern games, where you simply recover after a short period of time.

Always remember to ingest your regenerative nanite-paste, kids!

What you should be really careful with, when dealing with loss, is the loss of mechanics. The reason for this, is that it moves the users into a mental space of disempowerment, which may lead to frustration: Taking away control, is bad. This can be accommodated for, by making it a recoverable loss. However, it's very important that the recovery depends on actions performed by the user, rather than time. Using time as a recovery factor, instead of actions, would make the loss as inconsequential as loss of health with auto-heal on.

Another big problem with time, is the pacing of the experience. If you make time a factor, you punish the users who have a faster progression rate, than the ones who wait. This adds a measure of artificial lengthening to the experience, which can be felt and will most likely put off the users. If you base recovery on actions - such as paying ingame currency for your recovery (very simple example, not a good go-to solution) - you accommodate for different paces of progression and skill.

The pitfall of imbalance:

While working with risk and reward, it is extremely important that your reward makes it worth to consider, in light of the risk you take to attain it. If your experience ends up being about "normal progression or failure" rather than "significant progression or failure", then the users get what I like to call the "every-god-damn-time"-syndrome.

If a tester makes this face after failing, back off two paces before asking questions.

This syndrome owes its existence to how our brains deal with memorability. We've dealt with novelty in user experience design before, but the memories that stick are not filtered for what's good and what's bad.

What that means, is that if your risk/reward scenario ever cooks down to "regular progression or failure", it's the failure that becomes the novelty in your design. If we don't fail in such an encounter, we won't pay any mind to it, because the result doesn't stick out. Unfortunately, the opposite is true if we fail. Which means that since we only notice the encounter when we fail, we'll feel like we fail it every god damn time, even if we've only failed a few times.

Risk and reward as a narrative tool:

Risk/reward is an extremely common element in any game that is aware of its users' basic psychological urges. A good roleplaying game is about being presented with choices, that aid to reinforce your feeling of being "in character" throughout the narrative. All users have some kind of ideal personae they want to enact in the game-world, and having choices that support the fundamental personality-traits of said personae, helps heighten the immersion.

Therefore, the best roleplaying games are riddled with choices. But a choice is basically a commitment and an exclusion: Pick this and you can't pick that. Anything that you can take apart and fit into those two boxes, can be twisted into some format of a risk/reward decision.

That means risk/reward is not always about statistics and difficulty. Sometimes it's just about making a decision in a narrative, and the risk lies in getting an undesired narrative outcome. The reward is, as follows, getting the desired narrative outcome. Of course, the biggest impact comes from when the user is the most immersed in your narrative. At that point, their heightened empathy means that they evaluate the choices as if they occurred in real life - making for some very tense moments, if done right. Which is why using story elements (if done right) is just as effective as tweaking numbers and mechanics as the outcome.

Rounding off:

Let's summarize:

• Risk and reward gives weight to optional choices.
• Reward only means something, if you can emulate value properly.
• Value is a subjective measurement, it is not inherent in mechanics and coin, but can be about story too!

If you want some more hands-on examples, keep on reading!

__________________________________________

Risk and Reward in games today:

Now we know what risk/reward is. But how is it commonly applied in games today? Interestingly enough, it is mostly present in a genre that has been resurrected over the past few years, after being "dead" for ages: Roguelikes.

I'll summarize what a roguelike is, to those of you who don't already know it: A "roguelike" game, per its original definition, contains procedural level generation, permanent death, turn-based gameplay and tile-based graphics. Today, however, it's a bit broader than that, as modern roguelikes tend to be more about the "permadeath" in the context of modern mechanics, instead of only being tile- and/or turnbased.

Imagine a board game about punching each other.

The core of roguelikes is, when isolated, about the random elements and the permanence of failure. Typical in modern roguelikes, there is an element of persistence across each attempt. In other words; the more attempts you've made, even if failing, the further you've likely made it into the game. It rewards you with a permanent bonus, if you make it far enough, that persists even if you "die" and start over. This is done to appeal to a wider audience, who prefer to feel that their every attempt matters.

"FTL: Faster Than Light":

A roguelike that comes to mind when talking risk/reward, is a game called FTL. This game is so full of both choices and random elements, that the odds of you getting two identical playthroughs, is almost nothing. But the risk/reward choices are what's important here.

FTL is all about traversing an area; or travelling a branching path if you will. Along each segment of this path, lies an encounter. An encounter is essentially a small board on its own, that contains an event. Sometimes you are forced to fight, but you are often given a choice:

Something obviously risky is happening!

• Partake for the potential benefit, facing the massive risk? 
• Or skip out and let go of any rewards that could have been?

What's so brilliant about these choices, in the context of FTL, is that the game forces you to move forwards all the time. Unlike common roleplaying games where you can stay in an area until you feel powerful enough to move on, here you will be killed if you do not move forward.

This setup forces you to consider both the risk of partaking in the event, as well as the risk of not doing so, as not having the potential upgrades from a successful encounter, will make the game incredibly hard later on.

That causes the game to have an absolutely brutal difficulty spike, as the pacing of the user has to be fast enough to not fail. Yet the luck in the randomization is enough to keep most people going, as "maybe next time I'll get lucky!"

Even though I have no idea what I'm doing.

Homework:

This is something I'll start doing from now on, which is to give you - the readers - something to do, in order to try to apply some of the theory you've learned here. It's not something you'll have send, as it's for the sake of your own learning. But if you feel like you need some feedback on it, feel free to comment on the article that the question relates to.

The assignment this time:

It's quite simple. I want you to find a roguelike and try to analyze it: Identify when you are set in front of a risk/reward choice. The reason I want it to be a roguelike specifically, is because the risk/reward choices are often inherent to games in this genre. However, if you know of any games you know displays a similar nature in choices (believe me, there are many), by all means; go ahead and analyze that as well.

Here's a bit of inspiration, if you have no idea where to start (don't worry, they're not all ASCII-based:

Once you've found a few examples, and feel comfortable enough in remembering the theory from this article, try looking at games that are lacking a risk/reward choice system. Then think about how such a system could be implemented. I recommend you really take a close look at what elements of the game matters most to the players, then consider how said elements could be rearranged to create some risk/reward choices.

Have fun!

~ Dave