Strange Design

Considering: FTL

FTL has been in the gaming press the past few weeks, and for good reason - it is excellent. At the core, FTL is a really tight ship simulator. On that framework there is combat, economy, and a few canned events. It's a very limited package, but the laser-like focus and the wonderful interaction between the game's systems make it much more compelling than most spaceship games.

If there are any shortcomings, they have to do with the economic model. The game requires you to buy items / crew / repairs from "stores" scattered throughout the systems. But these stores have only a limited inventory - and therein lies the problem. If you are depending on a particular resource - more missiles, for example, or more drones, or more crew - you can get totally screwed by a poor store selection. This is exacerbated because each store carries only one kind of resource - so if you want drones the drone-store is a goldmine for you, but useless to most other ships. Eventually, most ships have an interest in most items. But initially the scatter of the items for purchase is too wide.

Integrated design elements

The ship simulation is accomplished through tight-knit simulation of seven systems:

• Ships are modeled as a series of rooms connected by doors.
• Crew occupy one space in a room, move at some set speed, and their actions are determined by the room they occupy.  (A crew member in the cockpit is a pilot, etc.)
• Some rooms have a "system" within them, and some do not.
• Each room has an Oxygen level, displayed visually by the color of the room.
• Weapon hits affect a single room - dividing their damage between the hull, systems, and crew.
• Each ship has some number of "power" cells, which may be allocated between systems.
• Some systems (shields, weapons, drones) have sub-elements which divide up the power provided to their parent system.

When you fight another ship (fighting other ships is about 90% of what you'll do in the game) they fire weapons at you - these weapons might hit your shields, or they might hit a room in your ship.  If they hit a room they damage your hull, systems in that room, and any folks in that room.  Some weapons can even cause a breach - creating a hole in the room which quickly sucks out all the oxygen.

If you have a breach it is important to close all the doors around that room, so that most of your ship still has oxygen.  Then again, if a fire is started on your ship you might find that venting all the oxygen out of the room is the fastest & easiest way to put it out.  Now imagine what happens if your "Door" system is damaged such that you can no longer remotely open & close doors - you might be in a situation where you are frantically trying to repair the door system as the oxygen drains out of the room.

And all the meanwhile that enemy ship continues to fire on you, and you continue to fire on it.  If your oxygen system breaks it's not too bad - assuming that you aren't fighting breaches or fires!

The best defense

Initially players of FTL will focus on keeping their own ship alive.  But eventually you realize that you can use your knowledge of the simulation elements to defeat your enemies more rapidly.  You can upgrade your surveillance systems (or use psychic crew members) to see where the crew is working on your opponent's ship - a few firebombs in those systems might send them scrambling, unable to man the weapons.  Boarding actions are very exciting - you can send a crack team into the enemy ship to wreak havoc on their systems even without punching through their shields.  But do they have upgraded security doors that will slow down your assault?

Engine upgrades, pilot skill, and engineering skill all contribute to your ship's evasion chance - by focusing on engine power you can dodge a lot of attacks!  But without a pilot your evasion drops to 0.  This makes attacks on the enemy pilot quite attractive, especially against faster ships.

Power Overwhelming

The final piece of the sim is your power allocation.  This is pretty much the same allocation problem we used in Tie Fighter (or Cybercon III!).  Put all your power into the engines to boost your evasion rate.  Power up shields to prevent damage.  Allocate more power to weapons to keep more turrets firing.  Don't forget to keep power running to your oxygen and med bay!

The really interesting, sensible twist here is that you cannot simply put an arbitrary amount of power into any system - each system is limited by a power cell ranking, which you have to increase as an upgrade.  So you purchase increases to each system's power limit separately from simply increasing the maximum number of power cells you can deploy.  The pricing scheme really encourages you to purchase increased limits before purchasing more power - which ensures that you always have interesting decisions to make regarding power allocation.

These power cell units are ALSO your systems HP - so adding more power capacity to weapon means it is harder for opponents to take out your weapon systems.  It is a wonderfully elegant system.  This also means that when a system is temporarily damaged, you gain unallocated power which can be put elsewhere.  I'll often increase my engine power when my shields or weapons are down.

All in All

Is FTL a great game?  Maybe not.  It has a pretty limited scope, which gives it a very niche appeal.  But it fills that niche very well.  It's a great example of making a compelling game for a limited audience, and not charging an arm and a leg for it.  I think that's exactly the direction developers should be moving in, especially for premium games.

Good breaks, Bad breaks, Bathroom breaks

Good Breaks

Ten years ago "mini-games" was an inescapable term in the industry.  Every major proposal had to include some number of non-standard gameplay elements sprinkled throughout your AAA game design.  Training mini-games in Fight Night, rail-shooter levels in Turok, gambling in Shenmue - mini-games were everywhere.

This always seemed like a poor mandate to me - as if we developers needed to pace out the main game experience because our players were too single-minded to vary their experience on their own.  When playing a game I prefer to set my own pace - and switch to other activities periodically if my attention wanes.  Pausing my latest exploration in FTL to peruse new messages on some forums lets me return to my experience refreshed.

But forcing breaks within the game means that the experience almost always suffers.  If the mandatory break comes when I'm ready for a break then the game has effectively done nothing.  If the mandatory break comes when I still want to focus on the primary activity - then I feel frustration.  This can be mitigated somewhat by ensuring that the breaks are as "good" as possible - that they make sense within the context of the game, that I have some control (or at least warning) about when they will come up (and end!) and that they reinforce the main game rather than detract from it.

Bad Breaks

"Bad" breaks, on the other hand, are always failures regardless of when they come into view.  A bad break makes it difficult for me to return to the main game, because it broke my interest.  Network television commercials are often bad breaks - watching the same shows via internet streaming services has demonstrated that the shows work better without those breaks.  Saturday Night Live was an early innovator in reducing the negative impact of commercial breaks - because some of the commercials were actually just pre-recorded segments of the show.  That keeps the regular commercials more in tune with the show - turns some of the bad breaks into good breaks.

But there is another type of break - it is possible to provide players with a break when they wouldn't take one on their own, but after taking the break they appreciate the respite.  These are very hard to gauge because they often focus on physical factors like fatigue or eye-strain, which don't reliably occur at specific points in the game experience.  But when done well, these breaks provide the "bathroom break effect."

Bathroom Breaks

The great thing about a "bathroom break" is that it is all about removing you from your primary context, and providing you with a secondary, temporary context.  You're not just avoiding one activity - you are actively focused on another, essential, activity.

The trick here is the word "essential".  Inventory tetris isn't essential - neither are Diablo town-trips.  (As evidenced by the amazing "dog" mechanic in Torchlight!)  Perhaps the best example I've seen of a consistently essential activity was in the brutally hard DS game Henry Hatsworth in the puzzling adventure.  This comes close to the dreaded "pat your head & rub your tummy" problem evident in games like The World Ends with You, but it manages to just barely skirt by on charm and integration.

The concept of breaks has faded in the past 3 years, largely because the market has become more focused on bite-sized games instead of huge epic time-sinks.  But I think the lessons of good break design still hold - let your players manage their breaks as much as possible, by providing them with a variety of meaningful break options.

Considering: Monster Ate My Condo! - A study in design tension

The Free App of the Week this week is Monsters Ate My Condo! - I picked it up, and was immediately impressed with the clever use of design in the game.  I thought this would be a good opportunity to talk about tension maps again (from my article of last year) because they so clearly explain what makes this game so excellent.

Systems in Monsters Ate My Condo

1. Remove colored floors to get matches of like-colored floors.
2. Removed floors go either right or left, and are eaten by the giant monster on that side.
3. If the removed floor matches the color of the monster, the monster is happy.  If it differs, the monster becomes upset.
4. Monsters which become too upset get angry and begin destroying random floors.
5. If you match a series of floors of the same color as a monster, the monster is replaced with a new monster.
6. Matched floors turn into bronze floors.   Bronze floors turn silver, then gold, then diamond.
7. Discarding a metallic floor does not anger a monster - instead it activates their super power!
8. Discarding any floor shifts the tower slightly in that direction - if the tower shifts too far in one direction it topples - ending the game!
9. As you earn points, you increase your character level - which increases the maximum number of floors which can exist at any time.

That's a pretty good set of systems.  Let's try to group them a bit.

Grouping the Systems

#3,4,5,7 deal with the monsters and how they interact with the player.  This is group A.

#1,2,6,9 deal with floor-matching.  We'll call that group B.

#8 is about toppling the tower.  This is "group" C.

Imagine a game with just B and C - you match floors, discarding whatever you don't want.  Your only limit is that you need to keep the tower relatively stable.  That would probably be fun by itself - though there isn't much room for variety.  There also wouldn't really be any reason to favor one color over another.

Imagine a game with just A and C - you appease the monsters, and try to not topple the tower.  That works well on its own, though there isn't much point-scoring opportunity.  If you don't have floor colors which match either of your monsters, you don't have any choice other than angering them.  It also seems to lack a really strong end-game condition, but that could be addressed.

How about A and B together?  This is pretty much identical to the existing game, though it lacks an end condition.  There are other ways to lose the game however - they just aren't as visceral.  But the first few minutes you play, you don't even know about group C, so there is certainly potential there.

This shows a really strong interplay between systems - none of them completely depend on any other system, though they connect to every other system at least peripherally.  This gives a good "spiderweb" - style tension map, as opposed to a "mobile" map where some sub-systems completely hang off of others.

Topple, Match, Feed

Not only are the system groups nicely separated - they compliment one another mechanically as well.  "Don't topple the tower" is a long-term limit to play, not something that comes up in moment-to-moment decision making.  "Match 3" is an immediate call to action, but doesn't really provide much strategic depth.  "Feed the monsters appropriately" is a lovely mid-level strategic consideration.  So the system groups are delineated by time and brain-space as well as orthogonal interaction.

This means that learning the game is a fun process - you give players an immediate goal (match 3), then tell them about the strategic color considerations (feeding the monsters), and let them play.  Eventually the tower will topple, and the player will realize that they could have been optimizing for that as they handled the other two objectives.  That provides an "oh, I get it - now I could do better!" realization, which probably gets them to play the game again immediately.  That's pretty much the gold standard in a mobile game.

Aesthetic Identity

Design isn't everything, and the game has some very cohesive visuals which helps to sell its identity.  The aesthetic isn't much to my liking, actually - but it's so flavorful that I have a hard time faulting the developers.

Considering: Cravings

Cravings are a bit unintuiative, from an evolutionary advantage standpoint.  Why should our brains sometimes fixate on something we don't have, and drive us to distraction trying to obtain it?  Even worse, why are these cravings sometimes about things which we cannot obtain - things which may not even exist?

This question is not just idle speculation - understanding cravings is a critical element to designing a product that people will want.

Anticipation

A key element to dissecting cravings is to first understand the role anticipation plays.  We don't crave something unfamiliar - we crave something that we can bring to mind in its absence.  An earmark of a craving is that it persists for a significant amount of time - as opposed to a fleeting curio.  That time spent in anticipation directly impacts the strength of the craving.  Building anticipation generates stronger feelings.

Irrational Investment

I have young children, and one of the more endearing/frustrating attitudes young children exhibit is a passionate defense of seemingly random statements.  Children behave irrationally, but they don't comprehend how easily adults can distinguish between their truths and their lies.  So children vigorously defend their lies - (probably aping bad behavior they see modeled by their parents) - even when caught red-handed in their deception.

I see this same behavior when people defend their cravings - say in anticipation of a film sequel.  People will extoll the virtues of the unseen film, and defend attacks against it with a crazed vigor which you never see used to defend a film post release.  (Barring some especially controversial film?  Perhaps?)

Impermanance

The trait of craving which probably makes it the most vulnerable to ridicule is the fact that cravings, whether fulfilled or unfulfilled, tend to just stop at some point.  Unlike needs or other desires, a craving which has passed doesn't make sense any more.  This is perhaps the most dangerous element of cravings - because it allows unscrupulous manipulators to cause craving after craving, without fear of negative backlash.

Considering: Rune Raiders

Rune Raiders is an iOS game by the group retro64.  I love the game, but not because it's especially good.  I love it because it has three or four really unique, elegant elements which I haven't seen before.  Unfortunately, these are a bit hard to see behind several layers of poorly-designed systems.

Rune Raiders is the first game I've ever played which made me immediately want to create a clone game of my own, to tinker with.  But since I might not get the time, I thought it would be a useful exercise for others to discuss the game's shortcomings, and describe how they could best be improved.

The Marketing Story

Rune Raiders has a classic premise - assemble a team of heros, and kill monsters in a dungeon, collecting loot and leveling-up as you go.  The twist is that your characters are little boxes, and the dungeons are linear strips of stone which go in only one direction.  You "move" all your characters at once, and have no direct interaction with them other than selecting their location.  I love everything about this marketing story - it is simple, sounds interesting, and gives me a perfect idea of how much mental investment the game takes to play (very little.)

The Economic Models

Rune Raiders has two economic models - both of them deeply flawed.  The first is the "gold" economy.  Recruiting heroes costs a certain amount of gold.  Resurrecting them in-game costs even more gold.  Killing monsters earns set gold rewards per kill, and finishing a dungeon level earns you a set gold reward.  The idea is that you pick heroes such that the gold you earn for completing the dungeon is greater than the gold you invested to finish it.

But the gold values are set to such ridiculously high levels that there is absolutely no economic pressure in the game at all.  The most expensive team possible costs about $5,000, but I earn 7-10,000 for each level.  Without an economy in place I just pick the strongest characters, every time, and ignore several of the cheap characters.

The second broken economy is the leveling-up system.  About 1/3rd of the upgrades are boring (+20% attack!) but useful.  About 1/3rd of the upgrades are thematic (die instead of your ally!) but useless.  About 1/3rd of the upgrades are AMAZINGLY POWERFUL and transform the game experience dramatically.  You will NOT be playing the same game after you've unlocked a few of these.  I really like the idea of dramatic power-shifting upgrades, but since they persist forever, I feel like I've turned on some cheat codes and can't turn them off again.  For example, the Ninja is a sweet character who can basically 1-shot any enemy he can get behind - but can't take damage well in return.  Once you unlock the ability for him to dodge most attacks, kill 2 enemies instead of 1, and hit targets to the side and in a swath around him, and NOT CONTRIBUTE TO THE MOVE COUNT(!) I basically can use the Ninja to kill 80% of everything in most levels.  Without even spending any moves.

The Treant gets the ability to kill stone walls, and heal 33HP to the entire party when he kills an enemy.  With those two abilities I stopped ever moving side-to-side in my games - I just put him top center, and drill my way through every level.  Killing the walls also heals my entire team, which transforms the minor navigation challenges which really make some levels interesting into a double-whammy of triviality.

The Fixes

So how would we fix these two problems?  Let's remember that a good system must generate strategic tension for players.  Permanent upgrades are the opposite of strategic tension, so let's change them to be something you earn each adventure, like Crimsonland (or Monster Hunter, for a more topical analogy).  Perhaps you select 1 starting upgrade for each member of your party, and then earn some additional upgrades during each level.  That would normalize the experience and give more strategic tension.

The gold economy is harder to fix, because it doesn't put any acceptable tension on the player even if we were to fix the numbers.  Consider this - what if players sometimes earned less money than they spent?  Well, the consequence would be that players have less ability to play the game.  That's clearly a down-spiral that we can't actually allow.  But without that negative consequence, what is the money system even for?

I believe the money system should be used to purchase new characters, new levels, and new available upgrades in-between dungeons.  Award money on completion of each level (monster-kill funds can stay), but don't charge per party member.  Just let money build up, so that players will be motivated to select new content and re-play levels to earn the right to that content.

Since the money arrow in this system points only one direction, it is a fine gating mechanic for content.  And allowing people to actively add content (instead of just giving it to them) helps to build player engagement with that content.

Build a Railing, not an Escalator

My latest game, Sun Stones, is out for iOS and Android/Amazon/etc.  I've spent a few exciting days tracking my analytics, viewing order history, etc.  I also now have tens of thousands of play-session data points, which allows me to look at user behavior in some very nice specificity.

I want to talk about one specific feature path in Sun Stones - they way you play/win/finish a puzzle.  Sun Stones is a puzzle game, which means that you solve a sequence of puzzles.  I followed my "Two Curves of Engagement" strategy, and built a nice aesthetic layer on top of the sequencing, so players who start the game can be pulled in by the aesthetics long enough to start to enjoy the puzzles on an abstract level.  In Sun Stones I use a Hopi Glyph series, which plays like this:

1 - Upon starting the game, players are presented with a glowing stone, and a sun.

2 - Players move the stone by touching and dragging on the screen - they place it on the sun.

3 - Intro animation starts, logo, sound effects - nice reward for figuring out the first puzzle (which was "move the stone onto the sun to start the game.")  This sets players up for the presentation style - no words, no explanation, but a simple, logical building upon past knowledge.

4 - Players are now presented with a "Glyph Wall" - which acts like a level select screen.  There is a cave-painting-style sketch on the screen - faded and incomplete.  One glyph is pulsing.  Touching that glyph enters that first puzzle.  Eventually all of the glyphs on the wall will appear, and the picture will be completed - allowing players to scroll the wall to find more glyphs to play.

5 - Players are brought to a closed eye, a puzzle name "Sunrise" and the first bit of text they have seen: "Open your eyes, your journey begins when you see the rising sun."

6 - Players must touch the screen, and drag open the eyelid.  This starts the first puzzle.  The top of the eyelid remains on screen at all times - players may drag the eye closed again to check hint text, and other useful data.

7 - In the puzzle proper, players must move stones onto black squares.  This is mechanically trivial, but it might take them a few seconds to understand what to do.

8 - We now play the victory sequence - which closes the eye and brings up some brief information - how many moves did the player use to match all of the stones to the pattern?  How did that number of moves compare to the bronze, silver, and gold rankings?

9 - Players are now returned to the glyph wall - and a new glyph is pulsing.

Too Complex?

Now, that was a rather verbose description of something which generally takes about 30-40 seconds for players to experience.  And in my face-to-face playtests players often have questions or comments to the effect of "That was pretty tricky" or "I think a lot of people would have trouble with that" or "It wasn't clear what I was supposed to do."

So what does the data say?  I can't actually track "player understood how to play the game" but I can track the number of new users each day, and the number of unique players who get a gold rank on at least one puzzle.  I think it's safe to say that a player who gets a gold rank on at least one puzzle has successfully navigated into a puzzle.  With 4 days of data reported, here is what I can say:

Day 1 - 91%

Day 2 - 87%

Day 3 - 93%

Day 4 - 92%

So at the very worst 90%+ of users are earning gold stars on puzzles, which lets me say with some authority that people are absolutely getting into the game without significant difficulty.

This actually sounds just about perfect to me - I WANT the game to seem tricky, to give people a sense of accomplishment.  An ideal game is one where a player is able to beat a section just barely - and feels as if most other people could not have replicated the accomplishment.  (Of course, if everyone feels that way it's obviously not true.  But it's still nice for players to feel that they have made a significant leap by performing the task.)

Falling into the Canyon

Imagine that you are giving tours of the Grand Canyon.  People are lining up and paying you to walk them along a path at the bottom of the canyon to an exit point.  (Perhaps a raft is better, since the Grand Canyon ends in a river - but let's just run with it.)

But there is a problem - a significant number of people are getting to the bottom of the canyon, then realizing that they've left their camera, or medicine, or some other critical thing back at the top.  It's very inconvenient for everyone to wait for them to walk all the way back up, get their item, and then come back down.  Folks suggest that the park pay to build an escalator from the bottom of the canyon, to speed up these incidents.

This is a terrible idea.

It's terrible because the problem is NOT the fact that it takes forever for someone to climb back out of the canyon.  The difficulty of access is a huge part of appeal of the canyon!  The problem which needs to be addressed is the fact that some significant number of people are entering the canyon unprepared.  Building an escalator does nothing to help make people more prepared - in fact it will quite likely increase the number of unprepared passengers, because the penalty for forgetting something has now been reduced!

The proper fix to the situation is to help people double-check their supplies before they come down the canyon in the first place.  This might just be a sign which reads "Do you have everything you need?" or perhaps better would be a warning sign like "WARNING: Once you go down, you will not be able to come back up for lost or misplaced items."

Build a Railing, not an Escalator

I call this principle "Build a Railing, not an Escalator", because it is almost always the case that preventing an error is better than facilitating people who have made an error.  In early version of Sun Stones our testers complained that when they entered the wrong puzzle by accident (touching the wrong glyph on the wall) there was no easy way to leave the puzzle.  Our solution?  When you touch a puzzle you have already played, a box pops up showing your record, earned stars, and asks if you want to re-play that puzzle.  We tried an "exit" button within the game, but it make puzzles seem not very important - like we were always pushing you to just quit the puzzle without solving it.  It reduced engagement for players when they entered a puzzle, and led to shorter overall game sessions (3-5 puzzles, instead of 8-10).

Getting Into the Game - How your mechanics might be unintentionally keeping players out

Cosmic Wimpout is a classic dice game - classic because of the groovy symbols, the catchy name, and the simple rules.  Cosmic Wimpout claims to have only 3 rules, though it stretches that point with one basic premise and two clauses.  The basic premise is that you roll dice, and set some of them aside as points.  You may continue to roll as long as you like, but should you ever fail to add points with a roll then all the points earned during that turn are lost.  It's the classic "Press Your Luck" mechanic.  

The three rules are:

1 - You must earn 35 points to get into the game.

2 - You May Not Want To But You Must: if you score on all 5 dice, you must roll again.

3 - You must roll again after rolling a flash.

The two clauses are:

1 - Re-roll clause. (or, Flashes Must Be Cleared)  If your roll after a flash contains the symbol just flashed, you must re-roll all dice.

2 - The Flaming Sun Clause.  If you roll doubles and the flaming sun, you must use the flaming sun to make a flash.

Cosmic Wimpout, as everyone thinks of it, is all about a single choice : Do I keep rolling or stay?  Every rule and both clauses are about instances where you must continue to roll.  The first rule is an introduction to the game - forcing you to make dangerous decisions.  You literally cannot begin a game of Cosmic Wimpout (that is, you cannot earn 35 or more points) without taking some risk or other.  It is often a successful strategy for players who have earned their initial 35 points to claim small rolls of 20 or 25 points for the rest of the game.  It is also not unheard of for players to spend an entire game failing to reach the initial 35 points.

I've found that most games I enjoy follow this same precept: you take your chances at the beginning.  It's terrible to play a game for hours, or months, and then be faced with a difficult choice which potentially causes you to lose the game.  It makes sense to take big risks early, because a game which goes sour right at the start can just be re-started.  That's how it works among friends in any case - a lot of designers go through great pains to ensure that players fear re-starting a game.  But when I play a game with my friends and get a terrible deal, or fall impossibly behind on the second or third turn, everyone is generally amenable to just re-starting the game.  It's often fun to play a few turns of a new game, and then re-start just because you all understand the game now, in a way you couldn't before you actually had to play it, and see the rules in action.

But this system carries the same potential downside that I've seen in Cosmic Wimpout - some people just can't get into the game.  They are unlucky, or they won't take the necessary risks, or (worst of all) they CAN'T take the necessary risks because they haven't understood the rules well enough.
There are also the stubborn, or the unwilling.  Some people whould rather not play, and demanding thate they take a risk - to invest in the game - gives them an easy way for them to guarntee their failure.  That's unfortunate but I don't think of it as a flaw in the game - because everyone can tell that the fault lies with the player, not the mechanics.

Fear of the Future

The great thing abouth risk is that the tension associated with risk dissipates almost immediately once the moment is past.  If you can just get your players to experiment a little bit - they won't be disappointed.  Players only fear the future, not the past.

But fear is a powerful deterrent, so one good technique you can use is to hide your difficult decisions from players until the last moment.  It's like giving players a random selection of potential skills each time they gain a level in an RPG - rather than a known skill tree that they could peruse ahead of time.  A known, fixed skill tree means opportunities for min-maxing.  It means that some choices are of more benefit depending on your playstyle.  It means that other people have faced the same choices, and maybe did a better job planning than you did.  Conversely, a random selection means pot luck - you get a choice, but it wasn't something you could have planned for.  Your personal judgement is the only guide.

Choice Chains

The worst offenders in pre-determined choice options are the moral choice systems present in so many current-gen games such as Bioshock, Infamous, Mass Effect, etc.  In these systems players are given dozens of choices throughout the game which sway them toward good or evil.  If players were to make random choices, they would almost always end up in the neutral "normal" ending, so players are trying to either achieve 100% good or 100% bad ratings.  This is actually a single choice, generally made at the beginning of the game, but that one choice is spread out over the whole game.  That absolutely kills any sort of anticipation - the reward from the choice happens (by definition!) at the very end of the game, so even though the choice happens early on the consequences occur very late. 

Our Three Rules

So, in the spirit of Cosmic Encounter, I'd like to offer 3 rules which we can use to determine how much effort is required of our players to make their first difficult choice - which gets them on the path to investing in the game.

1 - The first choice should occur very early on, to acclimate players to making choices within the game.

2 - The consequences of the choice must occur very quickly - immediately in most cases.

3 - Each choice should be atomic - independent of other choices the player makes.

 

How do these work for you?  Has anyone successfully used an approach which was way outside these parameters?

Goal-Based Design: What it is, and why you should be applying it

Goal-Based Design is a term of my own construction - a description of the design process I have been using in my professional life for more than ten years.  It is a top-down process, primarily focused on putting effort and attention onto the most important elements first, and then filling in around them.  It stands distinct from other popular game design paradigms, such as Modular Design, Holistic Design, Milestone Schedules, or Distributed Design Practices.

A Popular Focus

It has become very popular, in an online world of attention-getting headlines, to declare one element or another to be "the most essential" feature of any project.  In the 90's we had vague declarations that "graphics" or "processing power" or "gameplay" was the most important feature of any game.  By 2000 we had added "interface" and "camera system" and "licensed engine" as possible contenders.  These days concepts like "user retention" and "analytics" are getting serious attention as the most essential feature.

Obviously only 1 thing can actually be "the most important" - that's just math and/or basic syntax.  And I think any calm person would probably admit after just a moment's thought that what, exactly, is "most important" is probably different for different types of projects.  But simply saying "it depends" is a pretty unsatisfactory way to leave things - humans crave answers!  So is there something useful (and by that I mean actionable) we can say about games in general?  I have an answer in the form of two statements.

The two statements which drive Goal-Based Design:

1 - Your goals determine which elements of the project are essential and which are not.

2 - Therefore, every discussion should begin with an agreement on goals.

It's likely that these statements seem a bit simplistic at first glance.  Aren't goals obvious?  Doesn't everyone agree that just making a good game is the goal?  In my experience, the answer to both questions is no.

Let me give you some real-world examples of how people can spend days or even months working without a goal:

Goal-less Example #1 - task tracking gone awry

Three designers sit down to have a start-up meeting for a new project.  Ideas and concepts fly around the room without any sort of organization, but everyone has a good time.  After an hour or two, one of the designers says something to the effect of "we've got some good ideas here, let's write them down."  All three then work to painstakingly remember their best ideas, any maybe a few other things that struck their fancy during the brainstorming session.

The next day, the designers meet with the producers, to go over the ideas from the list.  The producers break the list into chunks, so each producer can come up with a plan & budget for each concept.  Senior management then meets to discuss the feasibility of each plan, and eventually votes on one to move forward with, along with a preliminary budget.

This budget then comes back to one or more of the designers, who is asked to make a feature and asset list that fits within the pre-production budget... and from that point on the paperwork tracking things has become so distributed that nobody in the entire company has enough authority to ask questions like "Why are we doing this?" or "Is this the best use of our time?"  Bureaucracy breeds bureaucracy.

Goal-less Example #2 - synecdoche

A designer, fed up with her lack of recent success, looks to a recent hit game.  She tries to distill down the essential components of that game, and declares that they are so simple that anyone with some real design skills could build a hit game around them.

The team gets to work building prototypes of these essential systems, one or two of which really hit and produce some fun interactions.  This early success galvanizes the team, and new features start to roll in at a breakneck speed.  Eventually some elements will fail to gell, and the design team will go back to the inspirational game, picking it apart to see how it solved the problem at hand.

For the entire life of the project, the reference game will be an authoritative guide to mediate disputes.  In some cases the inspiration is not a single game but a blend of 2 games - that doesn't change the fact that it is the desire to mimic the success (commercial and/or critical) of the source game which drives production.

These two examples won't necessarily produce bad games - but they are at least as likely to produce a bad game as they are a good one.

What makes games Different

The really exciting thing about games - the attribute which makes them difficult and interesting as a professional interest - is the fact that they are both technically complex, and creatively complex.  This means that not only are the goal which drive game development hard to perceive - there are usually two or more competing goals at any one time!  Trying to make a "good" or "high quality" game is not specific enough - because engineering something in a high-quality fashion is totally different from creating something which is satisfying from a user perspective.  The technical and aesthetic goals compete with one another.

Because there are usually two or more reasonable goals driving every decision, having a transparent discussion ahead of time about which goals are driving each step of the process is essential.  It is essential not only to make sure that everyone on the team has a clear objective - it is essential because mechanics and aesthetics each need to take the driver's seat at different times during the project - you can't simply choose aesthetics and then use that to drive every decision in the game.

It is the complex systems which make games what they are which demands complex solutions, and shifting goals.  Recognizing the importance of shift during development is what makes Goal-Based Design the only reasonable way to move forward with a complex game.

What Consequences does this bring?

So if using Goal-Based design is essential, the next question becomes: how is Goal-Based design different from what successful teams are already doing?

Every successful team I have been a part of, or had intimate familiarity with, has been successful because some members of the team were decidedly goal-based, and had enough authority to keep the project on track.  The advantage of formally declaring that your project is goal-based is that it allows any member of the team to ask reasonable questions, and have a good chance at understanding the answers.  It is very difficult, without open and transparent communication between team members, to distinguish between Goal-Based design and Despotism.  Understanding the why of decisions is an important way to keep every specialist on your team moving forward, because a good why allows them to focus on their work.

Multi-Dimensional Decision Making

Today I listened to a really great podcast from three moves ahead featuring Brian Reynolds and Soren Johnson - talking about Sid Meier's Alpha Centauri.  I consider SMAC and Civ 4 to be two of the very best video games ever created, so it was sort of a thrill to have the two lead designers of those games discussing the mechanical differences and design inspirations for the games.

The best part of SMAC, they both agreed, was the way that all of your strategic choices were contextualized within the game fiction.  Interestingly for me, this contextualization was actually a fairly late addition to the game - it started as a very dry numbers-crunching economy & warfare sim.  Strategy games are generally economically focused, so it's interesting that the more that fact is obscured the better the games seem to be...

SMAC had 7 really strong "Faction Leaders" who each had a very strong agenda.  This agenda naturally pits some leaders against one another:

Gaians - Ecologically focused.

Morgans - Industry focused.

Believers - Faith focused.

University - Science focused.

Spartans - Military & Police focused.

Hive - Industry focused.  (Also focused on population increase, but with a pro-slavery flavor)

Peacekeepers - Human Rights focused.

Each leader had certain advantages, represented by game bonuses and penalties.  The believers get +25% attack, for example, while the Hive get +10% Industry.  These unique attributes naturally led each faction into certain dominant strategies - the Peacekeepers really wanted to get the Council voting regularly, so their double votes could come into play.  The Spartans really wanted to find a neighbor to dominate with their military.  The University wanted to isolate themselves and research in peace.

On top of all of this, there was the really great "build your government" layer, in which players could select various economic, social, and governmental systems to mix and match.  Each faction had a certain appreciation or disdain for each policy - for example Morgan loved "Free Economy" while the Spartans loved "Power" as a diplomatic policy.  If you wanted to keep friendly with a particular faction, you needed to adjust your social programs to please them.

Getting to the point...

And now I can finally get to the point of all this - which is that what really made all of these systems so excellent was the fact that each decision you made had several significant decisions which were in competition with one another.  For example, if you were near Miriam and needed to appease her, you had to turn down your research systems.  That meant you weren't getting much research done - which forced you to actually play the game more the way Miriam played the game.  If you ran Free Market to please Morgan, that actually put your society into a different trajectory, which had real consequences down the line for your development.

So your government policy choice was influenced by at least 4 important considerations:

1 - What you wanted to achieve.

2 - What would increase your power in the game (economy, military, political, research)

3 - What would your neighbors think of your choices.

4 - How well you could afford to adopt a different strategy, if necessary.

This last point is especially important - since policy choices were so significant, you were motivated to change them fairly often.  It simply wasn't viable to set your economy to Free Market and just leave it there for the entire game.  You needed to adapt to a changing situation, and so you needed a Whole Game Strategy which allowed for variation.  It wasn't so much a decision about IF you would run a particular social engineering choice as WHEN you would run it.  This creates a positive feedback loop with your choices - each choice is difficult, but needs to be re-evaluated frequently.

Binary Decisions

Many games talk about "decision points" when they talk about a splitting path, or a small handful of options available to a player.  These sort of choices often don't really matter to players, because after you make them you can just forget about them.  Even games which claim that your choices matter (Deus Ex, Infamous) really just alter a few cutscenes or repackage some abilities to suit the game fiction of choice.  These choices are just random decisions to make - you can pretty much flip a coin for all the significance they have.

But SMAC gave you decisions which constantly begged for re-evaluation.  The University would call up and say "We've got laser tanks here, and we're not sure if we should drive them towards you or the Spartans.  What's your current policy on the freedom of information, hm?"  But you're building some expensive unit prototypes, and you need to keep up your current economic policy for a few more turns to get them out at your full discount - so your military, research, diplomatic, and industrial concerns are all at odds with one another.

Failure is a big part of most games, but in many cases failure seems arbitrary.  Giving players multi-dimensional choices allows them to create user-stories about why they failed (it doesn't matter if these stories are accurate or not) which gives them a greater sense of involvement & control in the play of their game.

What's a Beta For?

My company Sunstone Games (www.sunstone.co) has recently started a beta test for our first mobile game: Sun Stones.

Shameless plug - if you'd like to play and give feedback, just send mail to test@sunstone.co

/end plug.

This has given me an opportunity to explain to my co-workers what, exactly, an open Beta is for.  I thought it might be interesting to the world at large as well, so I've collected my thoughts here.

What a Beta is NOT

1 - A Beta is not "game testing"

Testing is a very important, ongoing need for professional developers.  A good test plan puts the whole game through a simple or deep stress test every day or two, looking for broken bits.  A professional testing team will hammer on all parts of the game, looking for broken system & features.  Testers can find missing or bad textures, geometry problems, spelling errors, etc.  But that's not what a Beta is for.

2 - A Beta is not content complete

In console development, at least here in Eugene, "beta" is used internally to mean that all of the content in a game has been created.  ("alpha" means all the systems have been created.)  But because of the technical limitations of console work, only people on-site can ever see the game before it is released.  That's not what a Beta is for.

3 - A Beta is not an early launch

Marketing people sometimes focus way too much on the "launch window" - and want to do everything in their power to ensure that the maximum number of units are moved in that period.  For these people a Beta can serve as a way to get units out ahead of the actual window - allowing them to artificially inflate their launch-window sales later.  That's not what a Beta is for.  (Nor is that what marketing folks should be doing!)

What a Beta IS

A beta is about user reactions - specifically how their reactions validate or invalidate the assumptions you made about your potential customers during the development cycle.

Most of that definition hinges on a particular business-style reading of the word "assumptions," so let's drill down on that word just a bit by giving an example.

Let's say you are sick of buying ugly-looking carrots, so you genetically create a strain of carrots which are bright orange and perfectly formed every time.  They cost a bit more to grow, because they can only survive in hydroponic gardens.  Your first batch are pretty good, but they don't taste quite as good as normal carrots.  You think to yourself "nobody will buy a prettier, more expensive carrot if it doesn't taste great!"  So you spend more time, money, and research adjusting your carrots until they taste just like normal carrots.

So you release your carrots, and get them into a few dozen grocery stores to start.  But it turns out that your carrots are so bright and beautiful that they look fake - and very few customers are willing to pay more money for a carrot which looks phoney.

The assumption you made, initially, was that people wanted their carrots to be prettier.  You based your entire company on this assumption.  Since this assumption turned out to be false, all of the other work, effort, and assumptions you made (it should taste good, etc.) were all invalid.

Sometimes people think that a Beta will prove the quality of a product - but quality only matters if your baseline assumptions are valid.  A Beta is all about validating your assumptions.

In the case of Sun Stones, our assumptions are something like this:

1 - Players will enjoy the process of discovery.

2 - Players prefer a sense of accomplishment over easy answers.

3 - Players will appreciate a strong unifying theme which is unbroken during play.

4 - By not making assumptions about our players (gender, race, nationality, age, familiarity with games) we will be able to appeal to many non-traditional gamers.