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."
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.
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.
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.
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.
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.
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.
Time for another game design article! This time, I'll talk about a topic that is very relevant in modern society, which is the phenomenon of "non-commitment." It essentially means "when a person never commits themselves to a particular choice, so that every option is perpetually open to them." This time around, I'll be using The Elder Scrolls Online as my prime example for a good solution.
As usual, I'm going to start off the article with a bit of reading-music, for those of you who like a backing track to your studies. As we're doing a bit of an Elder Scrolls special, I thought it fitting to use Jeremy Soule's music this time around:
A few generations back, it used to be that you grew up to take over the job of your parents, but now you have to choose for yourself. The choices (if you live in Denmark, at least) are virtually endless. But what does that do to our minds, when we're suddenly granted such an important responsibility to commitment, yet so many choices?
As you might have guessed from the term "non-commitment", people tend to suspend themselves, never being able truly commit to one thing: Committing themselves to one choice, is synonymous with letting go of another. This is true whether the individual acknowledges it consciously or subconsciously. It is the fear if missing out that keeps them suspended.
Unfortunately, this idea of suspending oneself in the choice of not making a choice, is a really massive flaw in our psychology: Time passes no matter what we do. However, most people grasp time entirely from a subjective standpoint, when they evaluate its passing (see "How to Christmas spirit" for a more in-depth explanation of the subjective passing of time). Yet you'll miss out on everything if you do not commit yourself to something.
Now if only I had a time machine to demonstrate it with.
To turn this in the direction of game design, many games are based around a series of meaningful choices. Whether its a moral choice, picking a character-class or choosing your companions, the choices are there. Mind that the problem only seems to persist in games, where the users are aware that they need to spend a lot of time dealing with the effects of their choices. This is very common in role playing games, particularly MMOs, or any other game where your choices will be reflected in your experience for a long period of time.
More casual titles do not tend to suffer from these issues, as they only require user interaction for a small period of time, or contain no significant choices.
The theoretical stuff:
In a well-designed game, the users quickly commit themselves to their choices. They do this much more confidently than they would ever pick something in real life - like when they have to choose a career path.
Oh god, the red beans are forming a worker's union!
But why is the virtual world so different to people?
The simple answer is: The games that make people behave this way, knows how to treat their users with care. It used to be that games could be extremely complex to boot, yet you'd still find a fair share of users enjoying the process of understanding the whole system. These people still exist, but the size of their audience is dwarfed in comparison to the younger ones, who suffer from having suspended themselves in this "choice limbo" in real life. That forces us to evaluate how we can include the bigger group, without letting go of the complexity that the smaller group has grown to love.
The most common way to tackle this issue, is through tutorials and procedural introduction of content. You can still make advanced systems, if you just introduce their individual elements one at a time; If you give people one piece at a time, they always just have that one new piece of information to reflect upon. If they have more than one new piece to deal with at once, they might overlook the functionality of one of them.
But as long as the users feel competent enough to make projections about what causes what, your design is generally in the safe-zone. When evaluating if your users can grasp this "action/reaction"-relation in your design, think about whether or not all of the game's elements have been presented in an isolated instance, before used alongside something else.
Another way that many games deal with the issue of indecision, is simply by letting the users have it all. Unlike real life, games are often a tangible, limited whole. If you just feed the users one piece at a time, they'll eventually have passed through the entirety of your system, never having had to make a choice in the first place. A lot of people will call this "too much hand-holding," however, and it will make for an very linear experience. What we want to know, is how we can let the users have these complex choices and be able to deal with them as well.
I don't think an explanation is necessary.
Again; to really overcome the problem, you must design your system to segment the experience into separate, tangible pieces. Every interaction that occurs, must first occur on its own, before occurring in tandem with other interactions. Use this as a rule of thumb, if you ever want to introduce something new.
However, even as we take these precautions to make sure that people understand the individual elements, the real danger lies within having too high a density in "the number of impactful choices that occur at the same time, at any one point in the user experience." When ascertaining impactful means, we need to look at it subjectively. Something that has impact, is something that behaves unexpectedly:
When a user is faced with multiple choices, where the outcome of each is relatively unpredictable, we observe two simultaneous negatives occurring within the mind of the user:
I don't know enough about this choice to commit myself to it, as the effects are uncertain.
I don't know enough about the other choices to exclude them from my personal interests.
If the users ever establish this kind of relationship with a set of choices, they are going to fatigue, eventually. Many people, after committing themselves to a choice made with the above points in mind, will also be in a constant state of curiosity and regret that they did not choose the other, thinking "what if." This can arguably be used as a driver for replayability in some games, but it might be bad in very long-term experiences that require commitment for the users to truly experience the game's content properly (namely MMOs).
Hold on to your hats, because here's a theoretical explanation of how you should look at user-progression in your game:
You can ensure the integrity of the flow of the user-experience, by examining it as a chart of occurring instances of choice, as well as weighing the importance of each choice, based on previous exposure to similar choices - or exposure to the possible consequences of said choices, before committing to them (in other words, telling the user that; "doing this may/will cause that to happen"). This enables you as a designer, to see where an overload might occur, where the user doesn't know what to commit themselves to, because they lack information.
The practical stuff:
That got really convoluted, so here's how you should do it in practice:
It can be done very simply, by making a flow-chart of possible user progressions through your system's environment. By listing everything that your users have been exposed to through certain paths, you force yourself to recognize when new elements are introduced. You can even do this with completely non-linear sandbox games, simply by looking at how a character might evolve through its interactions with the environment. Just ask yourself "what can the user possibly do at this stage?" and write the answers down as connected bubbles in a flow-chart. This will help you visualize what elements of play are relevant when.
You can go a long way by examining your game this way, but you will only really know the outcome of your design, once you've tasked a group of users - over time - to gauge their experiences. But an even more effective way to get the information you need, is to data-mine how many "do-overs" each user has: Did they quit without saving? Do they have multiple saves on the same character? How many characters have they made? Did they reset their progress and at what stages did the resets occur? If things like these are happening often, your users might be suffering from non-commitment, and so they might quit half-way through.
And often discover things you weren't even looking for in the first place.
The biggest problem with overcoming non-commitment as a developer, is that time is such a big factor. And to make matters worse, users will often not suffer from this problem if they know that they have to start over anyway, when the game is released. Offering some form of persistence through the testing and into the final release, could help alleviate this issue.
Example-time!
Now we've spent a while talking about the problem and how to approach it, so I believe it's time we take a look at some existing solutions. This time in particular, I am taking a look at The Elder Scrolls Online (I'll refer to this as TESO from now on). While we won't be looking at what design-processes were used to create these systems, we will take a look at how they affect the user experience.
Respeccing:
So what does TESO do, to deal with these issues? Let's begin by looking at a very simple example, which is not uncommon in role playing games: "Respeccing."
If you've never heard of respeccing before, it means resetting your character's progress, while reclaiming the points you've invested. In other words, if you've spent 5 skill-points on skills that you no longer want to use, respeccing gives you those points back to be reinvested elsewhere. This means that the users always have this mental concept of "my choices have consequence but are reversible," granting them the freedom to experiment.
The average user-experience when starting a new game.
However, TESO takes this one step further, by having three stages of point-implementation and respeccing, instead of just one.
You see, while it is typical of role playing games to have two separate types of points for character progression (the second being attribute points, which typically affect certain statistics on your character), TESO introduces something called "skill morphing." A skill morph is an upgrade, that adds extra mechanics to your existing skill. To attain a morph for each skill, it requires an additional skill-point, and the original skill has to have been used for a moderate amount of time. This is brilliant for several reasons:
In terms of respeccing, the system can be broken up into three parts. While some games require you to invest a hefty sum of gold to reset everything, TESO lets you choose whether you want to reset your attribute-points, all of your skill-points, or just reset your skill-morphs for way less gold.
This means that for every step of personal commitment that exists in this system, there is an action to reverse it.
Now I can get my skillpoints back AND afford wizard-college!
The only exceptions to this rule would be when you choose a class (which is irreversible), define the anatomical features of your character, pick an alliance or perform certain moral choices in the story line. But if you consider the fact that people can have several characters on the same account, you'll see many of these issues - if not solved - marginally alleviated.
The second reason while this system is so brilliant, is thanks to the mechanic; that skills have to be used for a certain amount of time, before unlocking the morph. This forces the users to come to terms with how the skill works. Once you've actually reached the point at which you're asked what you want to morph your skill into, you've already come to terms with how you prefer using it. This makes it much clearer what the different morphs can potentially add to your play style, making the choice easier.
Multi-role classes:
Now here is something that I really like about TESO. Although picking a class and a race, locks you down with a certain pool of skills to choose from, the game itself is completely open with what items you can interact with and use. Which in turn means that every class can essentially fulfill any role in a team.
If you're not familiar with the classical roles in role playing games, they are typically sorted like this:
Damage dealer - specializes in dealing as much damage as possible
Tank - tries to take the punches for everyone else, as a buffer
Healer - keeps everyone alive, especially the tank
That's the typical assortment. In most role playing games, picking a class would often lock you into one of these roles. This means that before you choose, you have to already have some idea of what your preferred play-style is. But in TESO, you are allowed to discover your play-style through experimentation. Any combination of existing elements in the trio above, is possible, regardless of your choice of class and race.
Lightning-powers and a giant hammer? Yes sir.
With a system this dynamic, we remove a lot of the pressure and consequences that such an early choice would otherwise carry with it. And by letting the characters become good at everything, if they spend enough time practicing, it shifts the choice from permanence to being a question of investing time. This is something that people can handle much better, because they miss out on much less. While some combinations of classes and roles might fare better than others, the fact alone that the possibilities are there, really helps defeat non-commitment.
The champion system:
This system is not actually in the game yet, but the premise of it is so closely tied into this article's subject, that I just have to include it. I'll start by outlining the system itself:
Originally in TESO, once you reached level 50, any level gained afterwards would count as a "veteran rank." Veteran ranks are essentially like character levels, but harder to gain and give a much more significant boost to your character's attributes. But now veteran ranks are on their way out.
To replace them comes the champion system. Now, when you reach level 50, instead of gaining veteran ranks, you gain champion points. These points are spent in the champion rank system, to advance your character. This is where it gets really interesting:
The champion system consists of a total of nine "pools," each containing passive skills for you to invest your points into. But these nine pools are separated into three major categories, each containing three of these pools each. These categories are thematically reflecting the three major attributes in the game:
Magicka
Health
Stamina
Whenever you gain a point - and this part is very important - it will be dedicated to one of these categories. This happens in a cycle: If the first point you gain is locked into the Magicka category, the next one might be dedicated to the Health category, while the third one would then be dedicated to Stamina, before starting the cycle over.
If only real life skills were colour-coded.
As you can see in the illustration above, there are the three categories. The genius of this structure and the way you have to cycle through it, is that it focuses the decision-making process of the users to the individual categories.
If we look at the categories individually, we have the three pools contained within. Each of these pools are segmented into three tiers - each tier containing a number of passive skills. In order to unlock the next tier in a pool, the user will have to spend a certain amount of points into the previous tier. This segmentation further helps with the decision-making, simply by restricting access to a certain tier early on.
Combine the three primary categories with the tier-progression on the individual pools, and you make a very "easy-to-think-about"-system that entices the users to cut loose and experiment. And you can still preview the later tiers, letting the more advances users plan ahead - you just can't invest in them right away.
To top it all off, points earned in this system are account-wide. However, the points spent are only spent on the individual characters (they are still available for other characters to be used differently). This means that you can invest your points with a complete disregard for whether or not it benefits your other characters, once again leaving you with one less thing to worry about.
Preventing this from happening.
While this system was designed to balance user progress, you can clearly see how this ties into helping against user indecision and non-commitment. But one of the primary reasons that the system is as viable as it is, is the fact that it only becomes active when people have already reached the maximum level.
This way you can describe what the skills do in a very concise way, as we can suddenly rely on the users knowing a great deal about the system already. Concise information is very important when you want to ensure clarity in your communication, so the fact that we can cook the info down to not contain further explanations, helps the decision-making process even further.
Rounding off:
Alright, time to summarize what we've learned:
The world is changing, and these changes affect us. The fear of missing out, causing non-commitment to significant decisions, is a pretty big issue to recent generations in the modern world. But while it is problematic when it comes to real life decisions, we can use it as a force for good in game design.
By knowing what triggers these issues, we can look at what equates the opposite and use that in our design. In this case, segmentation is key. The most important thing to consider, is where the "mental frontier" of a particular user might be, when they perform certain interactions within the system. What this means, is to look at previous interactions, so we can make assumptions about the user's current understanding.
Realizing what the users know, helps us on two different fronts: It helps us cook down the information we deliver to an "as-needed" basis, but also makes us realize from a development standpoint, if there are any potential holes in the knowledge of the users, which might otherwise be required to understand what is happening at specific moments in the user-experience.
If information is missing, we have to present it in an isolated instance, before representing it in a broader context.
When we have ensured that our design adheres to these rules, we must always examine the amount of possible interactions that can occur at the same time. If too many options are presented simultaneously, the indecision kicks in. Information and interaction density are the two primary rules we must look at, to prevent non-commitment-driven user behaviors.
Keep in mind that a very large, complex system can still exist - just as demonstrated by TESO. But then you must present your content in bits and pieces, in a sequence that plays on information that has previously delivered.
Defining user information:
Now I've mentioned "what the users know" on several occasions. Mind that this refers to "what you have previously told the users, through interactions with your systems." Do not confuse this with what we can assume certain cultures to know beforehand. While culture is still important, as long as you design for an audience that has the same cultural background as you do (the western market, in my case), you can inherently make assumptions from your own experiences.
But knowing your target audience is a whole topic in its own right, so we'll leave it at that.
Bonus video:
What's an article without a little extra inspiration. Here's a short video about the fear of missing out, for you extra curious people:
.jpg)
