GDC 2012 Transcript: Pursuing Elegance - Simplicity, Complexity, and Finding your Creative Process.

As with last year, I jotted down a transcript of my talk on the flight to San Francisco for GDC.  The conference doesn't record video of tutorials - which our session technically is - so I like posting these for those would want to refer to the talk.

Slides are available at slideshare if you'd like the raw powerpoint - but there are no speaker notes, so I recommend reading this transcript if you'd like to get a more complete impression of the topic.

Thanks for reading, and let me know if you have any comments of questions.

"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction." E.F.Schumacher, 1973

When I was asked what I’d like to talk about at GDC 2012, I mentioned simplicity.  Throughout my career, I've noticed a tendency in developers to over-complicate things.  Whether we’re adding steps to a puzzle, branches to a layout, failsafes to a script, or topics to a conversation, designers always seem to be adding layers of complexity – often before there’s really any demonstrated need to do so.  I'm as guilty as anybody else, and I've found that what’s made me better throughout my career is not having more or better ideas, but being more selective about which ones I choose to pursue.

"The poor architect succumbs to every temptation and the good one resists it." Ludwig Wittgenstein

If there’s a common reason I’ve observed this among game developers, I think it’s that we are, at heart, problem solvers.  Those of us who stay in the industry past that five-year burnout stage do so because we relish the fact that our jobs change constantly.  We appreciate that there is always a new technical or creative hurdle to overcome.  But this can become a self-indulgence.  I think that most designers, if we’re honest with ourselves, can recall toiling away at something because we enjoyed the work -  not necessarily because it's contributing to the overall quality of the player experience.  Developers are classically hard workers, and intelligent.  But the number of hours we put in and how clever we are is irrelevant if it doesn’t impact the game in a positive way.

Since I began work on this talk, Skyrim came out.  If it seems ironic to you that someone who worked on Skyrim wants to discuss simplicity, that’s not lost on me.  Still, I think an embrace of simplicity lies at the core of our success.  Response to the game has been truly beyond our expectations.  The most flattering attention we’ve received, of course, is from other developers.  When other game devs talk to me about Skyrim, they often want to know how we go about making games of such large scope.  There’s no easy answer to that, however, and this talk became, in a way, an attempt.

With that in mind, I'll share some basic stats from the production of Skyrim.  While the game existed in some conceptual form for a number of years, full-scale production didn’t begin until Fallout 3 was finished.  We are a one-project team at Bethesda Game Studios, so most of the content team was still on Fallout 3 DLC throughout 2009.  This means that Skyrim was only in full production for around three years.  We are a large team at just under 100 developers, but we aren't massive, either.  Some other games with similar scope involve literally hundreds of developers spread out across multiple studios worldwide.  Everyone at BGS is based in Maryland and we have tried to espouse an environment where everyone knows and can approach everyone else on the team.  We do use some outsourcing, but it is quite limited.  Mostly we outsourced armor and weapons, which we still did our own concepts and game-specific implementation for.  Speaking to level design specifically, we had a team of eight LDs on Skyrim.  Between us, we were responsible for over 300 locations and events in the game.  These include very large, multi-hour dungeon crawls, smaller experiences, all the way down to one-room affairs and exterior locations.  Level designers also were responsible for areas of the game you may not expect, such as the traps system and combat design for certain creature encounters.

The last data point I’ll share is one I’m especially proud of.  In an industry plagued by delays, where you expect a big game like Skyrim to slip once or twice, we hit our ship date.  We didn’t just hit our date, but we called it to the day over a year in advance, and of course we knew that date internally for months ahead of the announcement.  Furthermore, we didn’t just ship in North America, but finished the game in enough time to cert, localize, print and ship to nearly every territory where the game is available on the same date worldwide. 

The point of all of this is to highlight that while we are a well-backed studio, we aren’t extravagant in our resources.  While we have steadily grown over the past ten years, we’ve avoided explosive growth.  How we are able to do that while continuing to make games known for their massive scale is in large part thanks to our studio culture.

My boss, Todd Howard, has several mottos for the studio.  One of these is:

“We can do anything, but we can’t do everything.”  

Taken skin-deep, this is simply a statement about having to choose your battles.  But looking a little deeper, there are some further implications.  First, it implies a high level of ambition.  Every developer at Bethesda has pet features they’d like to see appear in game, or we wouldn't have to be selective about where we pool our resources.  To that end, we’re very good about seeking compromise.  I think we’re good about recognizing when something isn't quite working and re-thinking if we need to scale back or cut the feature.  The most important thing about this is that it doesn't live in some mission statement or is only held by an inner circle of highly-placed leads.  Every developer in the studio ends up embracing this approach to development.

That’s important because it affects how we approach our work internally, before we ever approach or collaborate with a colleague.  We must be of two minds.  One side of ourselves is the idealist; that inner persona with ambitious, far-reaching ideas, and a strong opinion about the Right Way do to things – whether it’s the best thing for the task at hand or the art form at large.  The Idealist doesn’t worry about how difficult something may be or how long it might take.  Those aren't reasons to kill a good idea in the cradle.  Likewise, our other self is the Realist – that awareness that an end date must be in sight if we ever want anybody outside ourselves to enjoy our work.  We get perspective from our inner Realist.  This is how we can see the big picture and realize that the time we spend grinding away every corner on the feature in front of us is taking away from time available to the next thing down the line, and the thing after that.  We also seek out expedient solutions as the Realist, looking to cut to the heart of things so we can move on.

It would be easy for me to cheerlead the idealist, by the way – but I don’t think many designer need help with that.  I have to emphasize that we must be Idealist and Realist in equal parts.  Some may be tempted into thinking they ought to be an uninhibited auteur at all times, or that your producer is your built-in realist.  I think that attitude is a little irresponsible, and stymies your growth as a creative person, however.  If we have no discipline within ourselves, we will never progress past the infancy of aimless creativity.  Besides, I’m sure your producer would rather fulfill his or her proper role as a facilitator rather than your babysitter.

This is all a bit theoretical, however.  The benefit of having just shipped a game is that I can talk freely about it, however.  So let’s look at some examples from Skyrim.

Example I: Loopback Layouts & Asking "So What?"

Layout is one of those things that universally is the purview of the level designer, anywhere you may go.  While the specifics of the job will vary greatly based on the studio and project, pacing and the sequence are always the concern of a level designer.  When we first approached Skyrim, we knew that there was one big layout problem we hoped to fix.  In our earlier games, players often progressed through a dungeon, only to end up back-tracking through empty space when the boss was killed and the loot all looted.  This was a dead space in the experience that we realized we could mostly banish.  We did this with loopback layouts, which you see a lot in Skyrim.  The basic idea of a loopback is that the player enters a dungeon, goes through whatever progression sequence and climax the level designer has set up, and is deposited quickly near the entrance of the dungeon via a one-way device – usually a physical drop.

Because Skyrim is a mountainous game, we were also able to apply this layout concept in an upwards fashion from time to time.  The player may progress upwards, which is a nice change of pace, and exits somewhere high in the mountain peaks, getting a nice vista of the landscape.  This provides a natural one-way blocker.

Production was marching along, and we were feeling good about this decision – when something unexpected came up.  This really shouldn’t have been a surprise to us, and I suspect nobody who has played one of our games will be shocked, either.  Turns out that players can pretty much get anywhere they want to get, including going up nearly-vertical mountain slopes. 

This wasn’t a problem with a one-size-fits-all solution, and we had to consider each loopback dungeon individually.  The first reaction, of course, was usually to lock the back door to prevent wrong-way access.  We didn’t do this instantly, however.  If you were to come to me and say “The player can get into the back door of my dungeon, take ten steps to kill the boss, and walk right out.”, I am not going to assume this is a problem.

I’ll ask: “So What?” There are several reasons we might assume this is a problem, but upon further analysis they often don’t matter.  When there is no great answer to the question, we’ll tend to leave the back door unlocked.

We prefer to do nothing in these situations for a couple of different reasons.  First, it’s usually the best Idealist solution, because it allows the greatest range of player expression.  Unpickable locked doors are often a contrived, designer-imposed restriction and feel like such to the player.  A door which is unlocked, or can otherwise be bypassed, more naturally fits the rules of the world.  That matters in a simulation-feel game like Skyrim.  Second, and this is hopefully the most painfully obvious point I’ll make – doing nothing is a highly efficient in terms of time usage.  It doesn’t matter how trivial the fix may have been.  If we can determine that no problem exists, we’ve saved time. 

So: while it maybe easy to think of the Idealist and Realist as strictly opposing forces, they are not.  Solutions exist that can satisfy the needs of both.  In the case of leaving a loopback door unlocked, the Idealist is happy because we’ve arguably given the player a better experience, and the Realist is obviously pleased that we saved ourselves the time of administering a fix.

Example II: The Radiant Assassin & Possibility Space

Radiant Story is one of the big features we knew we wanted to pursue right at the beginning with Skyrim.  Radiant Story uses a feature called the Story Manager to feed quests and events into the world based on the player’s experience.  The Story Manager is capable of tracking almost any data you can imagine – it knows everything about the player, how he or she has affected characters in the world, the state of current events, various information about locations, and so on.  The point of this is, of course, to deliver semi-procedural experiences to players.  We may not be able to achieve high-order procedurality in games with the fidelity of Skyrim just yet, but with Radiant Story we’ve begun to scratch the surface.

One application of Radiant Story are what we call Wilderness Encounters.  Late in development we were able to identify areas of the world where not much was going on, and use the Story Manager to send events towards the player based on this.  One of these encounters is the “radiant assassin.”  The event is pretty straightforward: the player is walking along when an assassin from the Dark Brotherhood attacks.  If the player kills and loots the assassin, she may discover an assassination contract with her name on it.

We consider this to be a pretty effective use of Radiant Story, if only because it proved to be thought-provoking for players.  In the weeks following Skyrim’s release, we saw a lot of commentary about this event online.  People would relay what had happened and had various different stories about why this assassin would come after them.  This was especially interesting because the Story Manager is only looking for two conditions in order to be triggered.  The player must have reached level ten, and not begun the Dark Brotherhood quests.  For all the data Story Manager is capable of tracking, that’s all we care about in this case.

Looking a bit deeper, the design implementation of this particular event is pretty small.  We created an assassin NPC, a note that dynamically fills in the player name, and set up the Story Manager event.  That’s not much authored story, but any assassination attempt is a loaded question, rife with inherent mystery.  Players were comparing this blip of authored story we provided against their personal history, and drawing their own conclusions.  Perhaps they had married an NPC another character was interested in, or it was a case of mistaken identity.  Maybe their criminal record or meddling in regional politics had caught up with them – or maybe it was a clear cut case of revenge for somebody the player had wronged.

These and dozens of other possible conclusions make up what we’ll call the “possibility space”.  This is the ripple created by the bit of authored story we created.  As small as it was, the possibility space resulting from this story was quite large.  I mentioned at the beginning of this discussion, however, that tendency of developers to add additional complexity.  And indeed, it would be very common for a designer to see this story, feel encouraged by it and want to add on.  So let’s suppose we provide information that traces the assassination contract back to a Jarl – one of the governers of Skyrim.  There are a few issues that can come up if we do this.

First, and by far the least important – is the fact that we’ll need to add additional conditions to the story manager event, so it only triggers if the player annoys a Jarl.  This will reduce the number of players for whom the event will trigger.  We’re comfortable with players missing content in our games, however, so while we’ll take this sort of thing into consideration, it isn’t a big concern.

More troublesome however, is the fact that by validating one member of the possibility space – we’ve now established the idea that this is a politically-motivated assassination attempt, not romantic, revenge, or otherwise – we instantly invalidate every other member of the original possibility space.  We haven’t necessarily increased the possibility space in a new or more interesting direction, either.  So we’ve arguably put more effort into making a less effective or interesting story.  Further, we’ve started down a slippery slope of implementation.  The moment I attribute the contract to a Jarl, I have to consider reasonable reactions on the part of the player.  Can the player confront the Jarl?  What will be said?  What if the player takes revenge?  When we tack on story for its own sake, without an idea of where we are going, it can be difficult to know where to draw the line and move on.

One interesting sidebar for those who have played Skyrim – many players will be familiar with an NPC named Lydia.  Lydia is assigned to follow the player at a relatively early stage of the game’s Main Quest, and will dutifully tag along on whatever adventures the player undertakes.  Lydia became a surprise hit with players – not long after launch, we began hearing stories about Lydia and the emotions and personality that were projected upon her.  The bittersweet fact about Lydia is that she’s a stock NPC with no unique attributes or dialogue of her own, save her name and face.  She’s just one member of a small group of standardized “housecarl” characters - one per city in the game - who will follow the player as a reward for attaining status with that city.

This simply goes to show that we must never underestimate the power of player imagination.  The fact that the stories and personality players project onto Lydia doesn’t technically exist in the game data is irrelevant.  In fact, it makes those stories all the more important.

Example III: The Headless Horseman & 15-Minute Proofs.

Another Wilderness encounter that can trigger is the Headless Horseman event.  At night, there’s a chance a ghostly figure on horseback will ride past the player.  Should the player pursue the Horseman – not a directed activity – he will ride to a cemetery and de-materialize.  The cemetery has an simple, independent event set up, and some skeletons and loot will be waiting for the player there.  Part of what makes this event interesting is the fact that it very nearly wasn’t in the game at all.

As mentioned earlier, Wilderness encounters are triggered based on where content isn’t in the world.  We couldn’t effectively determine where content gaps existed until fairly late in development because we couldn’t know earlier where all the major roads, dungeons, cities, and Points of Interest would happen to be.  As a result, many of these events went into the game at a late stage, and we were very interested in ideas which were easy to implement but provided a big bang for the buck.

A few of us were standing around the office, chatting about ideas for a level designer involved with this effort.  The idea of a headless horseman came up, but we knew there would be no way to get unique art at this stage, and collectively gave the idea up.  A thought struck me, however, and I told the designer who would be doing the work to give me a few minutes to try something at my desk.  Here’s what I did.

I had dabbled with our outfit system not much earlier, and started looking at an existing set of armor.  Armor in Skyrim uses a slot system.  In the case of the cuirass I was using, it was tagged with the body slot.  This tells the game not to render the character skin below the neck or above the elbows/knees, since the cuirass will cover the body up in those areas anyway.  I simply duplicated the armor and told the game a few lies by tagging the same piece of cuirass art with several other slots related to the head and face.  The result of this is that equipping the armor causes the head to stop rendering, since the game thinks you’re wearing a full-face helmet.

Armed with the results of this experiment, I was able to tell the level designer who implemented the event exactly how to get the desired results, as well as a few warnings and caveats I expect he may run into. 

The moral of this story isn’t to hack, of course.  That can be trouble for a number of reasons, even though it worked out in this case.  The important idea here is the concept of a fifteen minute proof.

When I sat down to prototype the headless NPC, I wasn’t sure what would be possible.  So I gave myself short period of time to experiment.  For most level design problems, I find that fifteen minutes is a good limitation.  It’s not enough time to solve a problem, and that’s the point.  You only want to explore the reality of the idea enough to determine whether it’s tenable and gauge what will be involved. 

This exercise is what I call a 15-minute proof.

I love using 15-minute proofs, because I think we tend to react to spur-of-the-moment ideas in two ways as designers.  We either jump in with both feet, or dismiss it out of hand.  By permitting yourself a 15-minute proof, you can make more informed decisions.  This appeals to our inner idealist, because it gives a risky idea a chance at life, rather than seeing it ignored as an unknown quantity.  They please the realist as well, because we’re saving time in the long run.  Many 15-minute proofs will end with the idea being too difficult or time-consuming to pursue.  It’s far better to have only lost fifteen minutes finding that out, rather than to have allowed ourselves to simply start working on it and only find that out after a week or work.

The 15-minute proof is especially useful when multiple solutions are competing.  If your tools are anything like ours, there’s always more than one way to skin a cat.  With the Creation Kit, in fact, there are often a half dozen ways to approach any given problem.  Thanks to this, it’s a common scene in our office to see one designer who is grappling with an idea or problem, and have two or three other colleagues each proposing very different routes.  When this happens, the designer typically runs with whichever idea was represented the most convincingly.  That designer may only find out a week or a month – or more – down the road that there’s some issue with the resolution that renders it ineffective.  When this happens, you’re at an impasse.  You can cut your losses and move on, or try to recall or re-construct the alternatives that were presented, and choose one of those – potentially repeating the same process again.

By permitting yourself a proof for each solution, you’re still only gambling with an hour or so of your life, and you’re going to make a much more educated decision about how to proceed, without having to try and remember every alternative if one doesn’t pan out.

Example IV: Special Pickaxes & Avoiding Extraneous Nesting

When we want to discuss simplicity and the workflow of a designer, it seems inevitable that we should discuss scripting.  This is one area where simple solutions are almost universally preferable, and especially difficult for designers to identify and implement.

One of the many activities available to players in Skyrim is the ability to gather minerals by mining.  The way it works is straightforward.  Nodes in the environment can be activated by the player, who will play an appropriate animation if in possession of a pickaxe.  After a few seconds the animation completes and the player has gathered some minerals to use in crafting.  Sometime in the later stages of alpha , however, I receive a bug.

One of our QA testers has identified that she cannot mine ore when in possession of a unique pickaxe that I had created.  I asked the designer responsible for the system which scripts to check out and I found this function:

     bool function playerHasTools()
        if Game.GetPlayer().GetItemCount(pickaxe01) > 0
           ; player has a pickaxe.  Return true.
           return TRUE
        Else
           ; player has no pickaxe.  Return false.
           return FALSE
        endIf
     endFunction

This is reasonable stuff – the designer wrote a function to check for the pickaxe in the player inventory, and returns true if it’s found.  Looking for “the” pickaxe was an entirely appropriate thing to do.  He had no way to know I’d have an idea for a one-off variant at a later date.  So my first reaction is simply to add an OR statement to the script.  If the player has “the” pickaxe OR “my” pickaxe, then proceed.

        if Game.GetPlayer().GetItemCount(pickaxe01) > 0 ||
           Game.GetPlayer().GetItemCount(pickaxe02) > 0
I checked, however, and found another unique pickaxe in the game.  My first reaction was still to add an OR check to the script, but it made the script visually ugly on the screen, and I wanted to find a better approach.  What I ended up doing was creating a piece of data which, in our tool, is called a FormList.  This is just a collection of objects, and can be passed into getItemCount just like an explicit object.  Not only did this make my script more readable, and therefore less error-prone, but I just happened to know that a formList is more tolerant of updates than scripts, which is important for future mods, patches or DLC that may wish to also modify things.

Example V: Barred Doors & Deceptively Simple Checks

In the first example I mentioned that we did occasionally need to prevent the player from progressing through a space in the wrong direction.  The quickest and easiest way to do this in our editor is to simply mark the door as locked, requiring a key.  This is easy and effective, but it sends a mixed message.  The door cannot be lockpicked open, and players sometimes assume a key must exist when there often is none.  As a result, we’ve had reports of players searching the area for a key, and sometimes even going all the way back to town to see if they missed a quest step.

To improve upon this, we wanted to have the option of including barred doors.  We felt this was something people would understand – if a door is barred from the other side, you don’t bother looking for a key or hidden lever.  You understand that you must navigate space to get around to the other side.  So we requested a simple piece of art to couple with our standardized door shape.

I sat down to script this all up.  The lockbar was easy – animate up when clicked, animate down when clicked again.  Likewise, the door wasn't too challenging.  If the player tries to open the door while the corresponding bar is engaged, provide a “This door is barred from the other side” feedback message.

Everything compiled, so I hopped in game to test – and found something I didn’t expect.

When players approached the door from the side with the bar, they could still click on the door itself and receive the “barred from the other side” message, which of course is just as mixed a message as what we were trying to fix in the first place.  I think of a few ways to potentially solve the issue, such as scripting triggers in the area to inform the door about whre the player has come from, or working with an artist to come up with tricky art that splits the door up into multiple parts, or includes a fake collision volume in the bar.  The trouble is that none of these are particularly graceful, and are arguably more trouble than they’re worth for the problem I want to solve.

That’s when I happened to notice something – the pivot point (represented by a small, yellow + in the image above) of the doors are always at the bottom/center of the object, and the lockbar art pivot point is directly below the bar.  Because of this, I realize that there will always be a fixed distance between the pivots – so I added a new check to my script - note the second if statement below:

if barred == true && actor == game.getPlayer()
     if actor.getDistance(Door) < actor.getDistance(LockBar)
          ; I cannot be opened from this side!
          barredMSG.show()
     else
          ; player must be on the "right" side
          UnlockMeMSG.show()
     endif
endif

This ended up working out fine, and it’s how the game shipped.  Something I found funny, however – in preparing for GDC, I relayed this story to one of our programmers, and explained that while I thought it was a neat example of a simple fix, but I didn’t know if I should use such a hack as an example at GDC.  The fix seemed too simple, and I had spent the project waiting for bugs to show up, although they never surfaced.  He literally laughed in my face.  He told me that it was just good code I had written.  He’d have done the same if I had requested a code fix.

This underscores the importance of script literacy for designers.  Anybody with programming experience has probably rolled his or her eyes at these examples, because they seem so elementary.  But many designers have learned to script on the job, and we tend to script in a very purpose-driven way.  Most designers script to solve a very specific problem, and can be guilty of a kind of tunnel-vision.  We don’t have the shared knowledge base programmers benefit from.  We aren't always aware of things like code etiquette and best practices.

There’s also a common misconception among non-programmers that code is complicated.  It can be, especially if you’re talking about something like 3D rendering or memory allocation.  Much of the coding involved with games has more to do with logic control, however.  I encourage any designer to learn more about this kind of programming.  Even if you don’t script frequently – or at all – you’ll not only be better equipped to communicate with programmers, but also be able to apply the abstract principles of logical design in ways you may not expect, whether it’s mapping out the flow of conversation, wiring up entities in the editor, or approaching puzzle design.

The real message here is: talk to programmers.  Not just about your scripting issues – though that is wise – but also about the problems they tackle in their work.  Designers may often miss simple solutions simply because it doesn’t occur to us that they can exist in scripting.

Example VI: Disputing Occam & Justifying Butterflies

Hopefully I’ve shown enough simple solutions to convey their merit, but what about complex ones?

When I first pitched this talk, it was really just the germ of an idea – that original observation about designers layering uncalled-for complexity, and the need to resist that temptation.  Because of this, it was quite reasonably suggested to me that I frame the talk around Occam’s Razor.

For those who don’t know, Occam’s Razor is a concept generally summarized thusly: When comparing two theories, if all other things can be taken as equal, the one which can be expressed in the simplest terms tends to be the better of the two. While I like Occam’s as a rule of thumb, I found that I was increasingly uncomfortable using it as the basis of this talk.  I was coming to conclusions I didn’t necessarily agree with, and seeking out very specific kinds of examples to reinforce them.

What I realized was that Occam’s Razor is very often applied – and mis-applied – as a debate tactic.  When debating two opposing ideas, it’s often useful to create a black/white scenario.  If you can classify your argument as simple and the opposite as complex, then it’s just a matter of applying the Razor to cut away the complex one and win the debate.

The language isn’t quite that plain for us.  First of all, simplicity and complexity are really just attributes of the solutions we’ve looked at today.  Better terms may be “Direct” and “Robust” – and those aren’t mutually exclusive, but opposite ends of a spectrum.  When we look at things this way, our examples may bias towards the direct side of the scale, but they aren’t all in the same point.  Some are more robust than others – and that doesn’t make them inherently worse.  The point here is that a complex solution isn’t an incorrect one.

You just have to know what you’re getting into.

With that in mind, I want to discuss critters.  In Skyrim, critters are any form of small life such as insects and fish.  They also happen to be a fully scripted system, as it wouldn't make much sense to impelement these with the full suite of AI an animations given to a human or dragon, for example. 

The features of critters are as follows.  They have a limited awareness of their environment.  Butterflies prefer certain types of flowers.  Dragonflies will dart away from the player.  Fireflies know to come out at night, and fish are aware of each other and will form schools.  Because they know a little bit about the world, we are able to move them procedurally.  There are no traversal animations for critters; we move them completely through script-generated splines.  Critters are also interactive – players can catch them as well as do damage to and "kill" them.

You may think that this seems like a lot of effort for insects.  You wouldn’t be alone in that assessment.  Colleagues within the studio saw what we were doing and wondered why we didn’t consider simpler alternatives.  It’s not as though a feature sheet ever existed for Skyrim that declared the game would feature Dragons, Radiant Story, a Civil War, Shouts and… butterflies.  This was a direct reaction to something we felt was missing in the game – a layer of small life and motion in the environment.

We certainly could have requested art of what would essentially be particle clouds of butterflies moving in a looping path.  Many critters began this way, in fact.  There are a number of reasons that I believe the complexity of critters was justified, however, and why we persisted.

First of all – we introduced a brand new scripting system called Papyrus for Skyrim.  This happened to be the second time in my career where I was working for a studio that threw out one language for a new, better one.  What I had observed was that designers will suddenly have vastly more power at their diposal – and no clue what to do with it.  The trouble is that six months later, you’ll see the designers simply doing the same things, in the same way, with a new syntax that they’ve had to learn.  We wanted a complex scripted system, not just to stress test Papyrus, but also to culturally show the studio what wonderful things were possible now that we could never have done before.  Critters fit that bill perfectly.

Second – and completely subjective – we felt that we were giving players a better value proposition with interactive, dynamic critters.  This is the kind of point you can’t effectively argue, however.  Sometimes you just have to stand behind a belief that something is “worth it”.

The third reason is twofold – critters are a highly repeptive system.  The first layer here is repetition to the player.  As of March 2012, the median playtime of Skyrim among Steam users is around 80 hours.  27% of those players spent upwards of 100 hours with the game.  This is a massive compliment, and we knew that players tend to spend a lot of time in our games.  By taking the extra effort to make this sytem dynamic, we felt that critters would stand a better chance of capturing the imaginations of our players, rather than becoming simple window dressing early on.

The second, and probably more important consideration, is the repetition of workflow.  We knew that we wanted there to be a lot of critters placed in the game.  Because of this, it was important to us that they were dynamic, procedural, and above all – easy to put in.  When you observed the time we spent from the outside looking in, you’d see a programmer, of whom the critters were his brainchild, spending a lot of time prototyping critter features and making sure allt he appropriate scripting hooks were in place, as well as myself putting a lot of time into writing the scripts  and making sure everything was hooked up as we wanted in the editor.  This doesn’t’ even mention the four artists who lended us their time actually creating the critters and responding to our evolving needs for how they were built, animated and exported.

The groundwork for critters consumed as much time as it did in large part because the system was dynamic.  But thanks to this we were able to make a system which was very flexibile, making the addition of new critters relatively simple, but also allowed for drag-and-drop implementation in the game.  This last part was very important because we knew we needed every artist and designer contributing to world-building to be adding critters where possible.  If every critter spawner required technical set-up, then we wouldn’t have seen nearly as many put into the world at all.  It’s important to note here that any given artist or designer on the team is smart enough to tweak the script or perform manual setup if that was required – but when designing a tool or system to be used by creative people, it’s important to stay out of their way as much as possible and permit them to be creative.  While they’re smart enough to be technical, you don’t want them wasting brain cycles on it when creating.  So if we can build more robust systems to permit this in their workflow – all the better.

So – simple solutions are good, and complex ones can be good, too. Where does it come together?  How do we know when to go in which direction?  That’s where process comes into it.

You see – in this spectrum of direct and robust solutions, all answers are good ones.  An infinite constellation of bad solutions exist outside, but let’s assume everything within is good for now.  There’s still a best place to be – in the center.  This is where elegant solutions live.

Elegance is a term most people who work with computers will know – these are solutions that have the ease of understanding that come with direct solutions, but also have the broad focus of a more robust solution, without the tendency for bugs.  Put another way – elegant solutions are always optimal.  You’ll never favor a highly simple or complex solution when an elegant one is on the table.  That’s the trouble with elegance, though – it usually isn’t available.  You almost never find it out in the open.

So – how do we pursue elegance, if it won’t come to us?  Unfortunately, there is no roadmap I can provide.  I won’t lie to you and pretend to share my top ten tips for finding elegance in every situation.  What I can tell you is that it’s often found within a compromise – and compromise is only found as part of the internal discussion we call the creative process.

Writers often talk about sitting down to a draft and writing expansively.  You have an idea of your characters, their goals and where a scene may go, but you aren’t worried about grammar or sentence structure at this phase.  The goal is to get whatever is in your head out onto the page.  If an idea takes you in the moment, you should follow it.  Keep writing.  Get words on the page.  Hold nothing back.

“Write with the door closed, rewrite with the door open.”  - Stephen King, 'On Writing'

Then you walk away, and come back later.  When you come back to that draft, you do so with a different mindset – when you rewrite, you’re sifting through the previous ramblings, panning for gold.  This phase is the lens which identifies and amplifies the best your creativity has to offer.

I think it’s much the same for us.  I think we begin as Idealists, and end in more of a focused, Realist state of mind.  Consider this with the development cycle at large.  In pre-production, it’s important that we leave the doors off and embrace every idea.  You want to build the best possible foundation for your game, so rule nothing out.  But anybody who has been at this phase knows that very quickly you need to begin abandoning ideas – maybe excellent ideas – or you’ll never achieve focus and define a vision for your game.  Likewise, as production marches along, you’ll do this more and more as you polish and refine your game.  When it comes down to shipping and dealing with content lock, the Realist will win many times, as you often don’t have the time to take the risks associated with robust ideas.

This doesn’t just apply to a mutli-year development cycle, however.  Iterating on any given level design, you’ll begin with a blue sky attitude.  Every idea is an option, but you’ll need to do less and less of this as you iterate.  Level designers are often distracted by new ideas while iterating, but this can muddy the waters.  It’s often better to be selective and stick to your original plan, so you can polish your work as you approach your final iteration.

The concept can scale even further, even down to a 15-minute proof.  By definition, we begin a proof with a vague idea, and in the course of that time we begin cutting away to find the best path to take.

This isn’t a linear progression, either.  We can oscillate back and forth between idealist and realist all day long.  It’s through this cycle that we can really hear both sides of our internal conversation.  And that’s how you arrive at compromise.  You’ll never do that unless you’ve heard both sides of an argument – and only when considering both sides will you find those elegant solutions that can make both sides happy.

Consider the improvised Jazz solo.  Young musicians often think that jazz is easy.  The beats are looser, it’s more relatable to modern music, and the idea of a sixteen bar solo where you get to make anything up?  After spending a year or two playing scales and etudes, the idea of an improv solo sounds like a vacation.

Playing jazz sounds like a lot of fun – and it is – but a middle school jazz recital is typically awful.

Swinging the beat as a band is extremely difficult, and an improv solo isn’t just making anything up at all.  This is because great improv artists are masters of their instrument.  They’ve internalized the fundamentals, to the point that their horn is almost literally an extension of their mind and body.  Great jazz soloists aren't just creative geniuses – they’re dedicated technicians, and have played hundreds of jazz standards.  They've heard other soloists and their ideas, and tried a million riffs and licks on stage and in rehearsal over the years.  The great soloists often have a recognizable style, built on those sparks of genius that they keep and refine year after year.  They develop, refine and present their ideas to an audience.  Put another way: they iterate.

We aren’t so unlke them, really.  Game development is still an emerging medium.  We face new challenges every day, and that’s exciting.  There is so much untapped potential in us – so many elegant solutions to find, whether we’re talking about scripting, layout, or more fundamental design problems.  I believe it’s through our personal creative processes that we’ll grow within ourselves and make each other better.   By discovering and refning your own process, you’re going to find elegant solutions - not just for the game you're working on right now, but for every this and every one to follow.  And by finding those, you’ll see the opportunity for them when they arise again – and you’ll get better and better and better as you keep this up.