Design Skills: Forethought

Anyone who has been in the trenches as a designer for a while understands that designers have to have a wide-ranging skillset.  In fact, the list of roles that designers commonly have to play in team development efforts is so long that it’s not practical to write them all out.  Mixed in all of that are certain key skills that make the difference between mediocre designers and good ones.

Today, I want to focus on forethought.  Now, you could argue that almost all design work is forethought in some degree or other; after all, designers are usually a few steps ahead of the team, laying down the roadmap so that other team members know how what they’re doing fits into the larger picture.  But, generalizing to that degree loses detail.  There are a handful of key dimensions to forethought that designers (and those who hire and manage designers) need to be aware of.

One dimension is the ability to translate from a paper design to a player experience.  I had the pleasure of working with Brian Upton (co-creator of Rainbow 6 and lead designer of the original Ghost Recon) while I was at Red Storm, and he was an absolute master of this.  Not only could he look at a top-down level map and pick out blind spots, chokepoints, and dead zones, but he could look at a controller layout design and immediately parse what action combinations would be awkward or unintuitive for players.  Translating from a description of a system to being able to play the game in your head is a skill.  It’s not some strange talent or gift that only certain people have; like any skill, it gets better with practice.  Brian had been working on this for years by the time I encountered him, and his critiques of my designs inspired me to develop this skill for myself.  I don’t pretend that I’m as good at it as he is, but it has been an essential part of my toolset ever since.  Particularly when I was on the publishing side and working with designers in multiple genres on a variety of platforms, being able to think ahead about what the actual play experience was for a design helped me to identify problems early and get adjustments made at the design phase, when changes are their cheapest.

A different – but related – dimension of forethought is empathy.  Robin Hunicke gave a great talk at DICE last year about empathy and how important it is when making games that aim to have a real emotional impact on the players.  Regardless of what type of game you’re making, empathy is a key part of forethought.  When you imagine a player experience, you need to be able to imagine not only your experience as a player but also as many of the different types of players you might encounter as you can.  In today’s marketplace, you have to be able to reach hundreds of thousands of people to have a sustainable business.  Odds are, you’re going to get every type of player imaginable.  The more of those people whom you can empathize with, the better you can understand their play experience, the more likely you can make the game accessible, intuitive, and rewarding for them.  As a designer, you’re not designing for yourself (most of the time), you’re not just designing for the team (although that does happen), rather you’re designing for the player.  The more you can understand – not just clinically, analytically but emotionally – that player, the better.  At a minimum, it can help you identify roadbumps, moments in the game that will strike those players as false or even offensive and polish those out of the experience.

Finally, and I may just be making this term up, there is systems forethought.  This is critical when you are making large, complex games like MMO’s that have a variety of interlocking systems, but it is also endemic to most games that have mathematical progressions, whether you’re talking about builders, CCG’s, RTS, life sims, or RPG’s.  Individual systems can be mapped fairly easily, but interlocking systems can quickly turn into chaotic models (in the science sense) where small changes in values at one stage of the game lead to wildly variant outcomes down the road.  As a designer, you have to be able to think through the I/O process of a variety of systems and identify any runaway dynamics, hopefully before implementation.  This is different from translating a design into a player experience or empathizing with your players – although modeling the griefer/exploit type player can help in the process – because you have to look at the system models independent of player interaction.  You can get runaway game dynamics from procedural generation or AI as easily as you can from player inputs.  Like other skills, it takes practice, repetition, and time to develop, but this can save development teams months of work and hundreds of thousands of dollars in development and testing.

As you might imagine, forethought is something that junior designers are often lacking, but your senior designers – especially the successful ones – know how to do this along a variety of different axes.  Every detail that gets implemented into a game has some impact (if not, why are you doing it?), but being able to reliably see that impact ahead of time is an invaluable and essential skill that is a part of any good designer’s toolset.

Are there other aspects of forethought that I missed?  If so, feel free to leave a note in the comments.

Out There: Critique & Strategy

Out There is a Rogue-like in space.  It can be a very frustrating experience, but some of that is inherent in the genre.  Rogue-likes are notorious for randomness, which can cause player death/failure with little to no warning.  Repeated failure is a hallmark of the genre, and the difference in growing player skill/mastery is generally not about whether you die or not but how far you get before that happens.

One of the ways that Out There is different is that it offers a discrete ending.  This is a key distinction, because rather than making the condition of success about getting farther than you have before, this puts a clear endpoint and target on the experience for the player.  (Spoiler:  There are actually three endings, each with a different “win” condition that get introduced over the course of the game).  In some ways, this makes it more frustrating when you lose, because it is not the case that every playthrough will end in death.

There are a lot of nice, little touches in the game: interesting scripted events, options that are only available when you have certain types of technology equipped, the different layouts of the ships, a wide variety of random occurrences, etc.  But, there are two critical failings that destroy the game experience for me.

First, there are a number of failure states where the player cannot know that they are at a dead end without putting a fair amount of extra effort in.  For example, as you progress deeper into the star field, the nodes become more distant; to get past a certain stage in the game, you must have picked up a technology that extends the range of your ship.  However, due to the randomness of the tech tree, it is entirely possible to never find any of the three technologies that allow you to do this.  Or, given a particularly bad distribution of one resource (fuel is an easy one) in the early part of the map, it can be literally impossible to reach the area of the map where new ships begin to appear, making it impossible to progress.  Or, being “warped” to a different part of the map (a not-uncommon result of various random events) can put you into a region where you can navigate among a few nodes, but not leave that particular sub-section.

Let me be clear: it’s not the failure that irks me.  It’s the fact that the game allows the player to continue to play the game when they are in a state that is not recoverable.  There are basic, discrete population and spacing tests that can be done algorithmically to avoid these states.  Killing the player due to a random event is not a sin, in itself, especially if the player was already teetering on the verge of dying.  However, giving the player the illusion of agency when every available path leads to death and failure breaks a fundamental contract between the game and the player – a contract that was established when the game gave the player a specific target goal.

This problem is exacerbated by the high cost of routine actions.  I’m not referring to the fuel, oxygen, and hull depletion that happens with almost every action (although tuning down some of those costs could easily make the early game more survivable); rather, I’m talking about the interface/player cost of the actions.  Because you have three resources that you are continually trying to replenish, doing something as simple as exploring the planets in a particular system involves a lot of back-and-forth between various interface screens, as you mine, sort your inventory, maintain your stockpiles, re-arrange your stacks, etc.  In a classic Rogue-like, exploring has little to no cost; your primary resource drain is combat.

In Out There, everything you do has a cost, and every cost ends up requiring player actions sooner or later (often sooner, particularly if you want to stay alive).  So, when you’re stuck in a dead-end path, it takes a fair amount of time and energy to discover that you have no options.  So, not only is the player robbed of the potential win, their agency is wasted.  You are better off quitting and re-starting, except that the game does not tell you that, so you have no choice but to continue to fight for survival, even though it is futile.  And again, with a little cleverness in seeding the map, this is avoidable.  For example, there have been several times where I was so low on resources (or stuck in a dead-end backwater branch) that the only option was to take a new ship; I cannot tell you how many times I have transferred all of my resources and equipment to that ship (again, a serious investment in interface effort), only to discover that the ship cannot make a jump long enough to get out of that particular map sub-section.

To steal a phrase from Ernest Adams: bad game designer, no twinkie.  It would be trivial to do a sub-section analysis and make sure that any ship present in that area can back-track back to the beginning of the game.  You could also seed one of the range-extension technologies on one of the planets as well as the resources needed to build it.  It’s not that the problem isn’t solvable, rather the developers didn’t care, didn’t see the solution, or didn’t have the resources to implement a solution.

The second issue is full of spoilers.

I’ve warned you.

If you want to find out for yourself, skip down a ways.

So, about 40 jumps into the game (as far as I can tell, the game measures time in number of system-to-system transitions that you make), an enemy faction appears.  This event is punitive in the extreme.  You lose a lot of resources (including entire stacks; I’ve lost 40 Helium and 20 Hydrogen before, taking me from well-stocked to dry in one event), you forget two technologies (including the possibility of losing basic abilities like the Interstellar Reactor, Space Folder, Drill, and Hydrogen Probe, essentially making it impossible to re-build any of these if they break and therefore also making it impossible to change ships and make progress), and two technologies that you have equipped are broken.

This one event can entirely cripple your ship.  For example, if you lose the Iron and Omega that you can use to repair your Interstellar Reactor and Space Folder, and those are the two technologies that break, you can be completely dead in the water.  Even in the best of cases, forgetting two technologies and losing multiple resources puts you in a fairly major hole.  In addition, all systems that you visit after this event have a chance to have their planets occupied by the hostile faction, making them completely inaccessible to you as a player (combat is not an option).  It is entirely possible for the hostile faction to have control over every gas giant within reach, again making your death inevitable but painfully slow to verify that there are no outs.

What makes this even worse (more spoilers here) is that if you are trying to complete the first objective (the red one, the one that you start the game with), not only is it impossible to go all the way out there and back to where you need to go before the hostile faction event triggers, but it is possible for the hostile faction event to erase one of the two technologies that are essential for finishing the game, and/or robbing you of the key resources that you need to have to do this.  Plus, it makes all travel harder and less reliable, because the way-points and resources that you used to get to the red objective (which is always separated from the main star field by a linear sequence of highly spaced nodes) are not all accessible as you re-trace your way back.

Again, I have no problem with making the ultimate objective difficult to achieve.  In fact, I like that there are three distinct end goals (so far, there may be a fourth that I haven’t found yet).  But the hardest one should not be the first one you introduce the player to.  And, if you’re going to make that goal difficult in one way (like positioning), throwing the hostile faction event on top of that is just pouring salt in the wounds.  There is no way to prepare for that event.  No matter what you have done in terms of stocking your ship, picking up technology, etc., the random and broadly destructive nature of that event can disable any plan.  And the only way to discover that is to get 40+ systems into the game.

Not only does this devalue player agency; it also devalues player skill.  There are ways that you can get better at this game, no doubt (see the strategy tips below), but the combination of the complexity of the final objective with the broadly random destructive nature of the hostile faction event means that you have to be extremely lucky to have any chance of winning the game.  That’s on top of being highly skilled.  I love slot machines, but don’t make the entire game a slot machine that I have to invest 30+ minutes of tedious, inventory-managing effort into just to find out that I got a lemon.

Okay, end of spoilers.

Seriously, it’s safe to read again.

So, in my final analysis, Out There is an interesting experiment, and I can see why it would be intriguing to people making games with procedurally generated playing fields (cough), but I do not recommend it.  At a basic level, the game fails to value and reward player agency and the development of skills and mastery, and that goes against the core principles of what a game is.  I could pick a lot of other nits with the writing, the events, the language system, but they are all tangential issues.  At its core, this game punishes players for playing, and I don’t see any reason why people should waste their time and money on games like that.

However, if you’re going to ignore everything I’ve just told you, here are some tips for getting farther in the game:

  • The first new ship you can take over does not appear until the fifth “ring” out from the starting position (in this case, starting position = 0).  Don’t waste time exploring in these early nodes.  Get to the fifth ring with as many key resources as you can, then ditch your starting ship.
  • You are going to need a range-extension technology to get to a win condition.  Once you have your new ship, focus on finding one of these.  Technology only becomes available through exchange with alien lifeforms, random events, and landing on rocky planets.  Keep your ship stocked as you move down and right, but take every opportunity to get more technology; if you don’t, you’re destined to fail anyway.
  • The alien language system resets with every playthrough, so it’s always a bit of a crap-shoot.  Always have Iron and Hydrogen in your cargo when looking for technology or Omega on these planets.  Also (not 100% verified), if you get a negative response for one choice with one alien lifeform, do the opposite response the next time you get a choice.
  • If you don’t have the resource an alien wants, leave rather than trying to give them something.  This leaves them open for re-visiting later.  If you have no interesting resources, you can also repeatedly encounter them to pick up more vocabulary.
  • Putting a subordinate technology (like Gravitational Lens) next to a primary technology (Telescope, in this case), gives an extra bonus.  Don’t be afraid to dismantle and reassemble pieces of your ship to get the adjacency bonus.
  • The most slots you can have on a ship is 20 (the biosphere-type).  Since anything can be repaired with Omega, you want to optimize your cargo around survival (fuel, oxygen, iron) rather than building more things.  Of those three, lack of oxygen is the least likely to get you killed (although it can happen).
  • Your Drill (or Hydrogen Probe) never breaks at depth 6.  It can break at depth 7.  So, when drilling, go for 6 or 10 (make sure you have spare Iron to re-build your Drill if you go for 10) depending on how many resources you need.  Using the Hydrogen Probe at depths >6 just depletes the resources faster, so it’s not worth the chance of breaking it.  If you have the Planetary Expansion, drilling deeper than 6 can actually cause you to get less resources because they don’t all fit in the queue on the left.
  • Don’t drill (or probe) more than three times in a row at the same location.  Diminishing returns kick in hard.  If you can’t recoup your investment on half of what you got last time, stop.
  • If you leave a star system, it loses all history of what you mined/probed, but the values for the planets remains the same.  You can bounce back and forth between two star systems with particularly lucrative planets to build up your reserves.  Just keep in mind that if you do this early, the clock is ticking.
  • You can build equipment when in the drilling results menu; use this when you need to shuffle things around to build something without losing other resources.
  • If you have enough space, keep some extra resources around in case you need to switch ships and re-build tech.  My general priority stack (after the four essentials and Omega) is Silicon, Thorium, Platinum, Gold, Tungsten (if I have a lot of resistance tech), Hafnium (only if I have the Subspace Reactor tech).  Rarer elements, like Copper, Cobalt, Carbon, are only useful if you have something specific you need to build.
  • Don’t bother building Cryonics unless you also have Shared Cryonics and plenty of space to work with.  It just doesn’t make that much of an impact.
  • Range-extension tech (Space Folder dependent) is more important than cost-reduction tech (Interstellar Reactor dependent).
  • Black Holes never have planets, but they can have ships and space stations.  Only use them as waypoints if you don’t have other choices or you are completely stocked on key resources.
  • Move as quickly as you can towards your objective.  The more jumps it takes you to get there, the more likely you are going to get screwed.

Okay, that’s enough for now.  You shouldn’t be playing this game anyways.