The Role of Design

It’s been a while since I’ve posted anything to this blog.  Needless to say, I’ve been busy, what with the graduate degree and everything.  Oh, and also the mental breakdowns.

 

In the process of all of this, however, I’ve been finding myself in an uncomfortable position.  Then again, I don’t suppose mental breakdowns would generally feel all that comfortable in the first place.  I suppose you think I’m being facetious about that whole “mental breakdown” thing.  But I digress.

 

I graduated college with what I felt was a firm understanding of what a game designer is and what role a designer fills on the team.  A competent game design program seeks to teach you those sorts of things.  Having successfully filled the role of “game designer” numerous times over my college career, I came to identify myself as a game designer - exactly which subclass of game designer, I was never sure, but I knew I was a design-minded individual.  I had a role to fill, and I knew how to fill it.

 

Every development team I’ve been involved with since then has been another story.

 

Making Design Matter

 

I find myself nowadays working on projects where being a designer is of no real value.  For the first time, I’m working with real, serious, competent programmers, which in and of itself isn’t a problem.  It’s great, in fact.  The issue is that these competent programmers are people who also happen to be bursting with ideas, know the basics of documentation, and are perfectly capable of designing game mechanics.  You know…professionals.  In the process of all of this, I found myself drifting into obscurity.  What good am I as a designer if my colleagues are collectively going to do most of the design work themselves?  As I worked my way through a few tough months of game development, however, I came to understand the answer to that question.  Some of this may sound ridiculously obvious.  Some of it may sound flat-out stupid.  Nonetheless, it’s something I’d like to attempt to express.

 

I’d like to raise an important point first.  I can sometimes come across as having a problem with programmers.  This is absolutely not the case.  I have immense respect and fascination for game programmers.  They are truly amazing people, and I am clearly not one of them.  No, I don’t have an issue with programmers, but I acknowledge that there is a clear difference between thinking like a game designer and thinking like a game programmer.  That’s what I’m here to talk about today.

 

If there’s one thing the past few months have taught me, it’s the importance of a dedicated design role in modern video game production.

 

It’s absolutely true that without the core technology, a game can never get off the ground.  In finally having been involved with the process of what it’s like to build a game engine from scratch, I have a new appreciation for exactly why it takes so long to make a game that’s intricate, polished, and truly entertaining, even when it’s built from an existing toolset.  Furthermore, how we’re able to make games truly stand out from one another is remarkable considering the amount of work it takes to simply make a character reliably move along the ground without hovering over it or falling through it.

 

But even when you consider all of the elements required to make game mechanics work, it’s sad to see those mechanics all go out the window for the sake of time or simplicity.  In extreme cases, the cutback can be so severe that practically none of the original game mechanics are retained in the final product.  Eventually, what you’re left with isn’t a game.  It has no hook, no…panache.  It may have some mechanics, at least, in the most technical sense of the word, but it’s not the kind of thing that demonstrates entertainment.  As a game is being developed, I don’t think the player’s reaction should be, “I can see you’re well on your way to getting this engine ready for a game.  All the basic elements are coming together.”  At the very least, the player’s reaction to an embryonic game should be, “Oh, I get it.  This could potentially be really cool to play.  I’d be interested in seeing this once the bugs have been ironed out.”

 

Or maybe that’s the indie in me still showing through.

 

Contradictory Thinking

 

I’ve observed that if you’re building a game, it should be able to exist as a game, on some level, even before the technology being used to run it is fully functional.  It’s odd to think about, and from a development standpoint, it’s a bit scary.  After all, how can you successfully test platforming mechanics if you can’t reliably jump?  How can you successfully test a shooter when you can run and shoot through walls?

 

These are the sorts of questions we were asking ourselves as we built a game in the spring quarter.  We can’t incorporate player damage correctly until we get collisions working.  Why add in the combat system when we can’t correctly register damage?  The structure of the world doesn’t really matter since we don’t have a combat system.  For that matter, there’s no point in building a final environment until we can actually walk on our terrain correctly.  And actually, since we can’t reliably walk on the terrain, what use is it to develop the mechanics right now?  (To be fair, it was a graphics programming course, so it was easy to place emphasis on programming graphics.)

 

While these are all valid concerns, particularly in a 10-week schedule, the fact remains that at the end of the process, we failed to create a game.  We had a nice enough world with some impressive underlying technology, but any mechanics we had set out to build had been utterly gutted.  Part of that comes down to the nature of the game we were trying to create, but another part comes down to a lack of design-centric thinking.

 

The importance of the design role can be a bit confusing at times, but that’s partly because the game designer must fulfill two contradictory roles simultaneously:

 

1. The designer works to promote an environment of sanity.

2. The designer works to promote an environment of insanity.

 

Perhaps these should be listed in the opposite order for chronological clarity.  More correctly:

 

1. The designer works to promote an environment of insanity.

2. Then, over time, the designer works with that insanity and uses it to increasingly promote an environment of sanity.

 

Yes, gather ‘round everyone.  Mental Breakdown Man is going to tell us stories about insanity.

 

Promoting Insanity

 

In the conceptual stage, it’s the designer’s job to be insane.  Just a little bit, if there is such a thing.

 

DESIGNER: This is what I think we should do.  <Insert clever mechanics>

 

DEV TEAM: We won’t have the resources to do something like that.  Are you crazy?

 

(The designer tears up.)

 

DESIGNER: That may be the nicest thing anyone’s ever said!

 

(The designer begins batting at the invisible monkeys flying overhead.)

 

DESIGNER: How many times have I told you people to keep the windows closed?  These things are going to keep getting in.

 

The designer’s task then comes down to defending and maintaining as much of that idea as possible for as long as possible.  This isn’t for the sake of being revolutionary or being the boss of everyone.  That insane idea is exactly how it sounds – crazy, impractical, and a drain on resources.  It will never work in the real world.  No, the real purpose of preserving that insanity is to prevent devolution into the next forgettable multiplayer-based sci-fi FPS, the next forgettable fantasy-themed free-to-play MMORPG, or the next forgettable…well, any tower defense game, really.

 

Without that spark of insanity flickering away in the heart of the project, it’s extremely easy for a game to be cut down to the point where it no longer exists.  An elaborate first-person action-adventure featuring attacks that are based on altering the laws of physics becomes a world with some things in it that you can shoot at.  It’s simpler, more manageable, and less time-consuming, but far more forgettable.  Keeping the insanity alive won’t typically maintain the original vision, but it might at least let you include one or two physics-bending weapons in the arsenal.  If nothing else, you can market your game as the one with the Friction Gun, which nullifies the frictional coefficient of any targets it hits, causing them to lose all control for five seconds.  For better or worse, you’re now known as “That Game with the Friction Gun”.

 

Note: Should you use a Friction Gun in your game, I expect to be appropriately compensated.

 

…Okay, fine, as long as I get a credit somewhere.

 

…

 

…Okay, fine, forget I ever asked.

 

Promoting Sanity

 

Somewhere along this road is where the designer’s role shifts from promoting insanity to promoting sanity.  In preserving the spirit of a game’s design, a designer must determine exactly where that “spirit” comes from.  What makes this game more than just a world with some things in it that you can shoot at?  What makes it something you could convince someone to play for more than 30 seconds?

 

The designer bears the important responsibility of determining two things:

 

1. Most fundamentally, what makes our game a game?

2. More to the point, and perhaps more importantly, what makes our game OUR GAME?

 

From here, it all comes down to determining the absolute minimum requirements for each and seeing that those requirements are worked towards right from the start.  Sometimes, this may mean that you start developing combat mechanics while your characters are still jumping off of the world into the void that lies beyond your skybox.  That’s okay.  We’re working on it.  At least you can get a sense of how the game mechanics work.  Well, okay…how they WILL work.  But you can at least see the game.  Well, okay, this isn’t “the game”…I mean, we’re not publishing this version, but…you know, you get where we’re going with it.  Right?

 

Keeping that design mentality alive is important for ensuring that the game isn’t lost for the sake of function.  A single bug can break the experience of the entire game – that’s why we perform extensive bug tests, after all – but in focusing entirely on creating a functional engine, there’s no experience to break.  Generally speaking, a toy car that has a wobbly wheel is more fun to play with than a slab of metal with four fully-functioning wheels on it.  The car has a clear purpose and a clear sort of play to be derived from it.  The chassis is just a tool.

 

That’s where maintaining sanity comes into play.  As is well known, no code is completely bug-free.  Hunting for bugs solves some problems, but can create others, and the overall process goes on and on, practically without end.  Thinking in terms of design enables the development of a clearer hierarchy of priorities, allowing development to be focused where it’s the most important for the game.  Developing the gameplay early allows the team to see exactly what problems need to be solved in order to make the game functional for its own purposes.  What is it, exactly, that breaks the experience?  What element of the gameplay does this bug affect?  If this problem isn’t fixed, will the player still understand the game?  If it is, will it improve the player’s understanding further?

 

A Hastily-Conceived Classification System 

 

Thinking in design terms, at least to me, means prioritizing the game’s development in terms of different “tiers” of a player’s experience.  Each tier represents a different degree of depth to which the player is invested in the game.

 

Tier 1: Understanding

 

The “Understanding” phase is the most basic piece of a player’s experience, and it’s the first that should be focused on during development.  During Understanding, the game should demonstrate its purpose to the player.  This is the “kind of game” we’re dealing with.  The player gets to sample the game experience and determine if it’s the kind of thing they’d like to play.  “This is how the game works, this is what you’re trying to do, this is what’s entertaining about it, this is the kind of experience you should take away, and generally, this is why you should play it.  If this doesn’t suit you, you’re clearly just not the game’s target audience.”

 

Now, obviously, there are some things you need to do on the technical side before anything else, like being able to render graphics and interact with them on some level.  This tier, however, is the first piece of a game’s development that enables people to see your game for what it is – an entertainment experience – and not just a tech demo.  There are things to do.  Some of them may not do what you expect at this stage in development, but they’re there.

 

Tier 2: Commitment

 

In the “Commitment” phase, the player has grasped the concept of what the game is and decided to move forward.  Understanding the base concept, the player now needs to see if what seemed like an enjoyable concept begins to pay off.  Does the game live up to the potential the player has envisioned in the “Understanding” phase?  If it does, can it maintain that level of enjoyment for more than a few minutes?  The real test of a successful player commitment is the completion of a standard play session and a subsequent return to continue the game.  This is where the overall execution of the base game engine becomes vitally important.

 

Does the game run smoothly?  Do the mechanics work together effectively?  Does it feel like a prototype, or does it feel like a fully-realized game world?

 

By now, the development team should be pushing the game beyond the point of basic errors in physics and rendering processes, as well as ensuring that player actions in the game generate the appropriate feedback, both functionally and aesthetically.  There aren’t just things to do, but reasons to do them.  You might say the Alpha stage represents the end of this aspect of development (or even still a pre-Alpha).

 

These first two tiers are the only ones truly required for what might be considered a technically “complete” game, but to take it farther, two more levels provide a game with a deeper player connection and keep things more interesting.

 

Tier 3: Exploration

 

A player enters the “Exploration” phase at about the time he or she begins a second play session.  By now, the player accepts the base concept and accepts the execution of that concept within a game world.  Now, the player begins to dive into the world itself and expand upon that initial review.

 

What sorts of elements are present in this world beyond the mechanic I’ve come to enjoy?  What sort of impacts do I have on the world around me?  Are there some other things for me to do that are also enjoyable?  How does this all tie in with the main mechanic?

 

This is where game mechanics start to reassert their importance in the development process, but it’s also the point at which to further consider general functionality and efficiency.  This is where the player’s impact on the world becomes increasingly important, so the game world needs to be able to respond to changing conditions and maybe even surprise the player here and there.  With many of the short-term gameplay concerns coming under control, attention now turns to the larger scope of the game and how everything ties together.  This isn’t just a demonstration – this is a fully realized game experience.  It’s time to show that the game has more depth than simply repeating the base mechanic over and over.  At the same time, it’s an opportunity to show the player that the same mechanic can be used in new ways.

 

Tier 4: Immersion

 

The word “Immersion” gets thrown around here and there all the time.  In this case, I’m using it to represent the deepest level of player involvement and the lowest-priority stage in the development process.  At this stage, the player is intimately familiar with the mechanics and has fully committed to being a part of the game world.  The player is delving deeper and deeper into the experience and moves from the posture of looking for enjoyment to expecting enjoyment.  At this point, it’s less about finding things right with the world than it is about finding things wrong with it.  Keeping the player immersed means ensuring that nothing happens to disrupt the existing experience.

 

Naturally, since the player is so deeply involved with the game at this point, smaller mistakes become more and more noticeable.  This is the point at which thorough bug cleanup can mean the difference between a good time and an unforgettable experience.  It’s also the point at which smaller details can be used to further enhance the game world and generate a more believable space.  In terms of mechanics, thorough refinements of pacing and difficulty can help the game move at a rate that feels natural and satisfying, but every player is a little different, so this process can only go so far.  Essentially, this is the stage of detail and polish.  It’s much less about adding new things and much more about removing any problems.

 

What I’m On About

 

This all makes it sound like the designer is taking over the role of a project manager, but that’s not the issue here at all.  The issue is with ensuring that game design sensibilities are injected into the software development process – ensuring that the software is being developed into a game, not just into a framework for a game.  Thinking in terms of design helps to establish clearer development priorities, shining a light on where the real issues lie and helping to identify the specific tasks that make up the components of each milestone.

 

That little spark of insanity provides a goal to strive towards.  The quest to keep that spark alive helps to identify where priorities lie, providing an additional blueprint for the development process and reinforcing a sense of order.  Thus, that spark of insanity works to promote sanity.

 

As always, how you choose to develop games is your own business (literally, if you have your own development company).  These words of advice come from someone who’s most likely far less experienced than you are, in which case, you have little reason to listen.  That hasn’t stopped me before, though, and it sure as hell isn’t going to stop me now.

 

And if you think I’m crazy, I thank you deeply, and I’ll ask you to close that window.

 

Thank you.  That is all.

Lessons of Rapid Prototyping

I’ve recently found myself back in school again after three years of post-college oblivion.  Due to the compressed nature of the quarter system, I was presented with the challenge of building a unique game prototype every week for several weeks on end.  I’ve been involved in a small amount of this sort of process with 48-hour game jams, but I’ve never truly faced the prospect of repeated rapid prototyping before.  If there’s one thing the experience has shown me, it’s that many of the concepts you can have about the process of designing a full game go out the window when designing a prototype.  In some cases, what seems immensely important in the design of a full game becomes completely trivial in a prototype.  Other elements that seem like trivial additions to a prototype are actually much more important than they seem.  I’d like to share some of what I’ve learned. 

As I sit here reviewing this entry, it all looks incredibly obvious, which makes me feel a bit embarrassed to bother writing about it.  But the deed is done.  Captain Obvious to the rescue! 

The Difference Between Scale and Scope 

One thing we were repeatedly taught in my undergrad program was to limit both the scale and scope of our projects in order keep the workload reasonable.  While I always knew what was meant by this, I never really bothered to figure out the difference between the two terms as I always found them bundled together.  One thing the process of rapid prototyping has shown me is that scope is everything when it comes to keeping your workload acceptable. 

Now, ideally, you want to have a prototype ready to go before you even make a project proposal, thus limiting the time constraints, but there are still instances in which you’ll find yourself rushed to build a working demo of your game.  If you need a prototype and you need it quickly, scale and scope are two vital considerations. 

Scale, as I’ve come to know it, refers to the size of the game.  How expansive of a game space are you going to deal with?  When thinking in terms of scale, a good place to start is thinking of your overall play time.  Is this a three-hour quirky indie adventure, an epic 40-hour RPG, or a pick-up-and-play casual title that someone can get through in ten minutes at a time?  Determining this can serve as a useful guide for how expansive – and how deep – your gameplay experience will be. 

Scope, on the other hand, refers to the sheer amount of material that goes into the game.  Whereas scale (as per its name) represents size, scope represents density.  How many different gameplay elements will you be dealing with?  How many different characters or assets are to be used?  Perhaps most importantly, how many different functions do you need to code?

This last question is key in rapid prototyping.  As is often said, ideas are abundant in the game industry.  In devising a game concept, it doesn’t take long to come up with a wide array of different skills or abilities an avatar can have or an array of challenges and obstacles the player might face.  If you’re making a prototype to demonstrate a game concept, particularly if you’re the one who designed it, you’ll probably want to give a sample of as many of these elements as possible.  That’s all well and good…as long as you’re capable of programming everything in before it comes time to present your game to a publisher.  The trick, as far as I can tell, is to always assume you can’t do this. 

I know, right?  Way to build up the confidence, pal. 

Now I’m not talking about breaking yourself down (or, if you have separate programmers working on the prototype, breaking THEM down).  As with anything in life, the point is to have a plan, and then, failing that, a backup plan, and then, ideally, a backup for your backup plan.  In the case of prototyping, a good plan should have the backup plan already built into it in the form of an incremental increase in scope.  Start ridiculously small and ridiculously simple, then worry about building up from there. 

This means adjusting the entire nature of the project build as you go.  If you’re designing a prototype featuring one level, that level could be designed in multiple ways depending on how many features are going to be implemented. 

Adjusting Scope through a Modular Design   

Let’s say you’re designing a platformer.  It’s got the basic platforming elements of running and jumping, as well as some other fairly standard ones like double-jumping, speed boosting, and wall jumping.  You’d also like to throw in your personal touch with a unique gravity-alteration mechanic.  You’ve designed a prototype level that demonstrates each of these abilities, requiring each one to be used correctly in order to make it through.  Great.  That should give people a good idea of what to expect from your game. 

Next, you work out a plan for building your prototype.  You’re going to start with the basic platforming mechanics to get the basic setup going.  It’s a platformer, so these elements need to be in place before you can move on.  From there, you’re going to implement your gravity-alteration system.  This is the key to your design – this element distinguishes your platformer from the rest of the market. Without this element, you have nothing to show. 

But then, things start to go wrong.  The physics of the existing platformer mechanics are at odds with what you want the gravity system to do.  This is going to take a bit longer than expected.  No problem – you’ll just skip one of the extra features you wanted to implement.  They’re not vital to demonstrate how the game works, after all.  But there’s another problem – the prototype level you’ve designed incorporates all of these elements.  Your gravity-alteration system doesn’t come into play unless you first use your speed boost and wall jump elements to access the appropriate area.  Now you’ll have to go back and redesign the entire structure of the level because you don’t have time to incorporate one of those elements.  This eats up even more time, forcing you to cut out another feature and redesign the level again. 

Of course, you can’t entirely prevent this from happening, but it’s a much easier problem to avoid in the prototyping stage than it is in production.  This is what I’m talking about when I mention having an adjustable scope and a modular design.  I’m a big advocate of building cohesive game experiences, but a prototype isn’t so much about this careful meshing of elements that you would hope to find in a full game – it’s a demonstration of how your game works.  As a result, a prototype can (and I would argue, SHOULD) be built with many of its key mechanics operating independently of each other.   

For instance, you might craft a level segment that specifically demonstrates the speed boost mechanic, another which specifically demonstrates your gravity-alteration mechanic, and so on.  Ideally, you’ll just be building your level sequence as you go.  If you want to mix things up a bit, you can generate each module and then, as you near the end of the prototyping period, put together what you’ve built to generate a full sequence of events.  This latter approach will likely produce a more connected and cohesive prototype, but it requires an additional design stage. 

Visuals are More Important than You Think 

This isn’t to suggest that you should bring in the professionals to give you fancy character models and visual effects for the sake of a ten-minute tech demo, but keep in mind that the term “video games” contains the word “video” for a reason.  The important thing in a prototype is that you prove the viability of your game mechanics, but the whole point of a video game is to translate all of the mind-boggling numbers and symbols of your code into a format that can be understood without years of training.  If the code works, the player needs to see it working on the screen.  If you shoot a gun, you should at least hear a “Bang!” of some kind.  If you’re charging up for your super-mega-special-energy attack, you should see yourself…I don’t know…glowing brighter and brighter or some such thing.  If you use your “drink milk” function, you should see milk disappear before your eyes. 

The word here is feedback.  It seems obvious when you think about it, but in a way, it’s so obvious that it’s easy to forget about it and simply leave it out.  If the player does something, it needs to be witnessed happening in some way.  It’s important in a prototype for the same reasons it’s important in a full game – to demonstrate that the meticulously-written code is actually doing its job.  The code makes your mechanics run, but the player doesn’t know that without the audio-visual element.  And no, a debug screen is not a viable audio-visual feedback mechanism for the typical player. 

In short, don’t ignore feedback elements in your prototype.  While it’s true you may not need a head to explode in a hyper-realistic shower of gore at this stage, your player will still want to know that the afflicted victim isn’t going to be a threat anymore.  Incidentally, a hastily-placed text box reading “Boom! Headshot!”, may technically be a viable feedback mechanism, but if I see this more than once, I’m going to stop playing your game with immediate effect. 

Drawing the Line Between “Engaging” and “Practical” 

After the experience of completely redesigning a game halfway through its production cycle during my undergraduate program, I hoped I wouldn’t have to go through that process again.  But, silly me, I apparently forgot that I was getting into an industry in which this kind of thing happens without warning.  When you make the discovery that a game simply isn’t fun, bad things happen. 

Ultimately, I’m not sure how common the practice of rapid prototyping is within the industry.  I will say this, though – the day before you’re pitching a project to the higher-ups is not the time to make a fundamental change to the design.  Generating a viable prototype in one week is challenging enough.  Doing it in less than 24 hours is just asking for trouble.  Sure, your game might not be accepted if your prototype isn’t fun, but if you change that prototype at the last minute, it’s still not going to be fun. 

Why do I mention this in reference to prototyping?  The prototype is the first stage of the project where you’ll start to see that your concept isn’t enjoyable.  As a result, it’s probably the stage at which you’re most likely to decide that a massive change is called for.  In general, I would say it’s not something to worry about…if your prototype doesn’t sell the concept, you should have the opportunity to make another one in the future. 

I also mention this simply because I just so happen to have been involved with a prototype that was redesigned from the ground up 12 hours before it was due.  Don’t do this, okay? 

Closing Down 

Whatever the situation may be, it’s better to let your mistakes shine BEFORE you start making a full game.  This is the true purpose of the prototype.  A prototype is a test run, allowing you to give your concept a chance before risking the world.  Sometimes, it can hurt to know that your prized design doesn’t work, but it hurts a lot less to discover that before you’ve invested the time to develop the game. 

Incidentally, prototyping also allows you to imagine, however briefly, that a typical crunch period only lasts for a few days.

The Game Experience (Evolving Definition Pt. 2)

Introduction

In my blog, I’ve spent a lot of time on the subject of game theory.  I’ve discussed the process of game design, what games mean to us as individuals and as a society, and some of the qualities that mark a great game.  Recently, however, I took a look at the larger question of just what games are, especially in a time when we see video games further and further blurring the lines of exactly what a game can be.  As I’ve thought about exactly how games can be defined, I’ve reduced the question down to a terrible argument of semantics – defining the “game” as opposed to what I call the “game experience”.

What is the Game Experience?

The concept of the game experience encompasses not just gameplay, but the total package of what the game is and what it affects.  It’s the game itself, its presentation, its style, the interactions within the community, the nature of the community itself, and the way a game impacts your interpretations of other games, other media, and the rest of the world.  The quality of the game experience isn’t something that can be determined and broadcast on release day like a game’s review scores.  The experiences of games from 30 and 40 years ago are still being written today.

This all factors in with another point I recently raised about the evolving definition of games.  We see a lot of video games out there that can’t really be called “games”, but we don’t have any other good way to describe them.  Perhaps this is another way to look at such games – not as “games” per se, but as game experiences.  If nothing else, we can use this expression in the same way we refer to Velveeta as an “American cheese food product”.

In seriousness, though, an “experience” may be the most reliable term for these non-game games.  They possess some level of interactive player control, so they play something like video games, but that may be as far as the connection goes.  The rest is simply a world built around that interactive nature.  It’s an interactive way to experience a story, an interactive way to view art, or an interactive way to sit and mindlessly roam around, forgetting your troubles.  There’s some element of a game in there somewhere, but what you’re really engaged in, more than anything, is a game experience.

Examples – Game vs. Experience

Of course, “game experience” isn’t an entirely fair definition for quasi-games.  Every game system has its own game experience.  I think the key is in placing emphasis on exactly what it is we’re engaged with. 

In this case, what would be the definition of a game?  Think of something like Tetris.  The game is part of a larger game experience, sure, but when you sit down to play Tetris, what keeps you engaged is the game itself.  The process of rotating pieces, carefully placing them, and dropping them down is a gameplay process.  That’s what pushes you forward, and that’s what keeps you coming back.  When you play Tetris, you’re engaging, primarily, in a game.

Then there are the games we might describe more as game experiences.  Something like Heavy Rain qualifies more in this sense.  You play through game events and participate actively in the process, but the primary driving force behind Heavy Rain is its story.  More than likely, you don’t play it primarily to complete tasks or move through the game world.  You play it to see where narrative events are leading.  The story is a big part of the game and is directly connected to the gameplay, but the primary engagement of the player is not with the gameplay itself.  The player is engaging in a game experience, rather than a game.  Proteus, as I’ve discussed previously, only deals with walking from place to place.  Goals are whatever you make of them.  Now, unless you’re immensely intrigued by the process of walking, Proteus isn’t engaged with as a game.  As you walk and create your own motivations, or even if you engage in the process and simply wonder “What in the world is this and why would I waste my time playing it?”, you’re participating in a game experience.

When we look at the concept of “game” and “game experience” in this way, we begin to run into a high degree of subjectivity.  Whether you engage in a game or a game experience depends greatly on how you approach the game.  Look at Metal Gear Solid.  Many people play it as a game.  They have key motivations to improve their skills, master the mechanics, and be the best damn Solid Snake they can be.  I’m the type who plays it when I feel like watching a movie.  The story drives me forward, and that’s the main reason I engage in the interactive portions.  I approach the game as a game experience.  Something similar could be said of Braid.  Many people seem to view Braid as a work of art – an elegant experience that is a combination of gameplay, narrative, visual art, and music.  In this case, Braid is enjoyed as a game experience.  I’m the type that plays it purely to beat those pesky puzzles.

In one of my very first posts, I discussed (at great length) narrative design in video games, but specifically, how it tied into the controversy surrounding Metroid: Other M.  Not to beat a dead horse, but there’s another point I’d like to bring up.  You see, leading up to the game’s release, Nintendo touted Other M as “the ultimate Metroid experience”.  Now, did it prove to be the ultimate Metroid game?  Absolutely not.  By no means.  But the ultimate Metroid experience?  There’s actually room for argument.  (The answer is still no, but it’s at least a much more accurate assessment.)  Looking beyond the gameplay to the sheer spectacle of the presentation offers a new view on the title.  Looking beyond the title itself to the insanely overblown controversy surrounding it which drew a great schism through a devoted fan base – that provides another layer to the mix, for better or for worse.  Simply put, if you were a Metroid fan, it was quite the thing to live through.

Game Experience as Product

By my definition, the game experience is always larger than the game; the game is always contained within the game experience.  But you may have noticed a key term popping up – motivation.  Motivation is the driving force (the motivating force, I suppose) behind progression through a game.  Motivation to progress from one event to another is a key element of gameplay.  Thus, we’re left with an interesting question…if you’re motivated by the game experience more than the game itself, isn’t that game experience now a part of the gameplay?  But then doesn’t that mean you’re more motivated by the game than the experience?  But then doesn’t that just mean the game experience is larger?  But then are you more motivated by the game or this new game experience?  But if you’re more motivated by the new game experience, then y—oh no, I’ve gone cross-eyed.

In this sense, the relationship between the game and the game experience is somewhat cyclical.  If you’re drawn to play a game for the sake of nostalgia, that’s the game experience drawing you along towards the game’s goal.  If you play a popular game in front of people to make yourself look cool, that’s the game experience propelling you along.  It’s also terribly sad.  I’ve never done this, of course.

So how, then, does this help us define games and quasi-games?  While it’s true that a certain part of the game experience takes place outside the software, some of it can be created as an integral piece of the gameplay and included as a part of the package.  When you first begin a playthrough of Amnesia: The Dark Descent, a block of text prompts you not to play the game to win, but to get involved in the story and environment.  Fans will instruct you to play the game not because it’s challenging or fun, but because it’s scary, visceral, and just generally engaging.  In this sense, Amnesia is marketing itself directly (and indirectly) as a game experience, not a game.

Conclusion

Some games are crafted for the gameplay.  Others are crafted to look beyond it.  Neither is necessarily better than the other, and they both contain shared elements.  They share the same heritage and the same developer motivations to engage and entertain the audience.  However, placing these titles in the same category is proving to be a bit inaccurate.  The way I see it, there’s nothing wrong with marketing a fringe game as a game experience, because that’s what it is.  If the “game” aspect of a game isn’t what’s being sold, it probably shouldn’t be called a game.

But really, you can call it what you want.  I’m not in charge here.