The Evolving Definition

As the game industry has grown and formalized into a more systematic structure over the years, there have been numerous efforts to break the process of game making down into its various components.  How do we create games?  What makes a game fun?  What makes the video game different from other media?  At the core of the industry lies a simple question – one so rudimentary to game development that there’s often no need to even ask it: what is a game?

Of course, professional game developers don’t need to ask what a game is.  It’s something that’s understood somewhere back in the recesses of our minds.  We have an underlying knowledge of what makes a game a game, so we don’t typically need to think about it.  The bigger questions we’re faced with are the questions of how to make a game entertaining, how to make it unique, engaging, immersive, beautiful, and functional.  Generally, the question only comes up when we’re teaching the concept to newcomers. 

“Welcome to Freshman year of your Game Design college program.  This will be your first class.  Open the game design textbook to the first page.  We’ll spend a few minutes discussing this first question.  ‘What is a game?’  Well, let’s take a look at the definition.”

That definition usually reads something like this:

“A game is an activity in which one or more participants work to complete a goal (or set of goals) according to the constraints of a predetermined set of rules.”

This basic definition is held to be the common element between every game ever made.  Every game can be described this way.  It is, after all, the very definition.

While it might be nice to cuddle up with that nice, cozy, clean definition, it’s proving to be less and less reliable all the time.  The indie game scene, in particular, seems bent on breaking down the very definition of what makes a game a game.  Experimental prototypes result in games that remove goals, rigid rules, and consequences, and simply allow players to immerse themselves in a digital world.  Players can experience the game as they see fit.

Now, I don’t want to say this.  I really, really don’t want to say this because of the firestorm it always brings up.  But there is an existing term used for media that exist purely for the interpretation of the viewer.  That term is “art”.

(Warning: Personal Opinions ahead.  I would like to stress this point.)

I regret having to use that word.  I’m not describing video games as art.  On the same note, I’m also not saying that video games aren’t, or can’t be, art.  I am, however, saying that games, based on the strict definition of games, are not typically (in my opinion) art.  Likewise, video games that qualify as art (in MY OPINION) are not exactly games per se.  By divorcing themselves from a rule system or pre-defined goals, these experimental projects remove themselves somewhat from the traditional definition of games.  As they do, they provide an experience that has no real purpose beyond the player’s own interpretation. 

What’s the point of playing this game?  What are you supposed to get out of it?  That’s really up to you.  Some people won’t get anything from it, much like staring at a canvas covered with strange geometric figures yields no impact on the average passerby.  Other people find something significant in it; there’s some deep message being conveyed somewhere inside.  Other people might just think it’s pretty.

What does this have to do with the definition of games?  In the standard concept of a game, the player’s focus is on the completion of existing tasks.  In an artistic piece, a player’s focus is on the product itself.  “What am I experiencing?  What IS this thing?”  As soon as focus shifts from the former to the latter, a game becomes art.  Again, this isn’t to say that what can be considered a “game” cannot also be considered “art” within the same product.  You might take time from completing your goals to simply interpret the game space and create a new experience all your own, but you’re no longer playing the game.  I don’t feel these terms can really be experienced simultaneously.  (The concept of “toyplay” lies within that gray area between gameplay and art, but doesn’t greatly overlap either one.  This discussion can be saved for another day.)

There are (seemingly, at least) a growing number of projects that focus less on the traditional aspects of gameplay and more on the artistic side of this spectrum.  Many people don’t consider these projects to be games.  Still, at the same time, we honor them with video game awards and classify them with other works that are, very much, games.  What this seems to demonstrate is that the term “video game” is, somehow, broader than the term “game”.

Perhaps the real question is, what constitutes a “video game”?  Video games are technically defined as a subcategory of games – games controlled via an interactive, computerized interface.  As a result, however, many other activities controlled by the player through a computer interface are placed under the blanket term “video games”, even though they may not necessarily be games.  This is simply because we don’t have a good way to describe them.

For instance, what exactly is Dear Esther?  It’s not a simulator because it isn’t really designed to replicate a real-world experience (maybe an emotional experience, blah, blah, blah).  Many in the game community don’t like to describe it as a game, either, since it has no immediate established goals.  It has an ultimate endpoint, but so do movies, novels, and songs.  However, if described to someone, the clearest, most basic term to use is “video game”.  The player (or maybe “user”) controls the action and the speed of the progression.  Also, it’s played through a computer.

To take it a step further, what is Proteus?  Proteus has no endpoint, no pre-established goals, no formal story, no consequences for failure (indeed, no failure), and extraordinarily rudimentary graphics.  It’s a very bare-bones representation of the process of exploration.  The player can walk around, and by walking to certain points, cycle forward to the next season at will.  This is the extent of the interactivity in Proteus.  Still, what’s the first term you would use to describe it to someone?  Personally, I would still say, “It’s a video game in which…”

Sure, if you’re talking to a fellow game expert, you might say “It’s not so much a game as it is a ______”.  But if you were to describe it to some random person on the street…

YOU: Hey, have you ever tried out Proteus?

INNOCENT BYSTANDER: What’s Proteus?

YOU: Well, it’s sort of a…virtual world…experience for your computer where you walk around through a digital environment.

BYSTANDER: You mean a video game?

YOU: No, no, it’s not really a video game.  It doesn’t have any goals to complete or anything to do.  You just walk around and experience the environment.

BYSTANDER: So, what, it’s just some kind of sport or something?  You walk around outside and try to experience the world?  Is that anything like meditation or yoga?

YOU: Well, maybe it’s like that for some people, but no, it’s not a physical activity or anything.

BYSTANDER: But you said you go walking around.

YOU: Well, yeah, you go walking around on the computer screen.  You control someone who walks around.

BYSTANDER: I thought you said it wasn’t a video game?

YOU: It’s not.

BYSTANDER: Sounds like a video game.  It’s on the computer.

YOU: But it’s not a game.

BYSTANDER: Well, you walk around in the computer screen.  Isn’t that a video game?

You and the bystander then have an equally fruitful discussion regarding who, exactly, is on first base.

When we say “video game”, the first image conjured in someone’s head isn’t a set of rules or the act of striving towards a goal.  Rather, it’s the image of someone controlling something with a computer.  Maybe you envision motion technology, DDR, or Rock Band.  Maybe you envision trading resources with a Facebook friend.  Maybe you envision an avatar running through a richly-designed virtual world.  In the end, what we think of when we hear the term “video game” is something the player controls.  We think of interactivity.  In a way, the term “video game” is more about “video” than it is about “game”.

After all, if it wasn’t for the computer, we wouldn’t really consider such things to be games.  If you were stranded on an island, walking through sparse foliage and old, abandoned buildings, looking at things while someone told you stories about his dead wife, you would be more annoyed than intrigued.  You wouldn’t call that a game.  If you saw a movie of the same thing, you wouldn’t consider it a game.  However, if you control a character on a screen doing the same thing, a video game is born.

So what, exactly, is a video game?  Where are the lines drawn between film, interactive art, toys, games, simulators, and their kin? 

I think the answer is always pretty clear: these lines don’t really exist.  All of this genre-bending doesn’t just skew the definition of what constitutes a video game, but of what constitutes a game itself.  Is a quest to understand something a game?  There’s a goal to complete.  You’re restricted by life’s rules.  You’ll likely obtain enjoyment from the experience.  By that token, going to a museum and interpreting modern art can be seen as a game.  Making that art can be seen as a game.  As the semantics break down, my previous argument becomes meaningless: if art is a game, then a game can be art.

The basic point is that it doesn’t seem all that worthwhile to attempt to classify a concept that is as subjective and situational as a game.  Games are things that can’t be described, but instead have to be experienced.  Is it a game?  Is it art?  Is it a mindless display of graphic violence?  Is it something else altogether?  Our own experiences are all that can answer that question.

Maybe that’s why I get so frustrated when people ask me what my favorite genre is.

Jamming with Purpose

Applying for jobs in game development can be an exhausting and massively frustrating experience. To be considered a viable candidate for any position, you need to keep building your skill set, work on using your existing skills to build a portfolio, and all the while, find the time to support yourself in the absence of game-related employment. As most career advisors will tell you, however, perhaps the most important thing to do when job hunting is to go out into the world and network. As it’s said, it’s sometimes less about what you know than it is about who you know.

As it stands right now, there are a number of great ways to go about networking with fellow game developers. The big conferences allow the opportunity to meet and talk shop face-to-face. Groups like the IGDA allow members to work together to solve problems and explore new possibilities for the industry on a regular basis. Perhaps one of the most useful tools for meeting other developers, however, is the humble and always-exciting game jam.

Game jams are a great way to meet and work with fellow game developers. For a few days, people can see what they can do when they join forces within a tightly-constrained atmosphere. The chief reason game jams serve as a great networking tool is simply that they allow people to make games. A jam isn’t just a discussion about everyone’s latest projects or backgrounds, but a direct vision into the participants’ development philosophies and skills.

The interesting thing about jams, which is perhaps due to their heavy time constraints, is that they almost always seem to be very informal events. This is a good thing. Jams are generally seen as a good way to relax (if “relax” is the right word) and give everyone’s creative skills a quick boost. When it’s all over, people go their separate ways with a hearty, “Well done, and good luck. It was nice working with you.” Some maintain contact, while some fall off the radar. Again, this laid-back atmosphere is a nice feature.

However, I feel a good opportunity is often overlooked in the realm of the game jam. A jam has the ability to fulfill a more formal, professional purpose. What I’d like to see more of (and indeed, I’m not sure if anyone does this at all) is the use of game jams as recruitment tools for game companies.

The Existing Process

A company looking to bring on new employees can examine the skill sets of their applicants all they want. The hiring process tends to follow a similar pattern from studio to studio. Job hunters submit their applications, typically with a cover letter and résumé. Some force, usually an HR associate or a set of computer algorithms, searches through those initial applications for keywords and presentation. Those candidates fitting the bill are sent along to the appropriate department leads, examined in greater detail, and contacted. Through a few stages of interviews, employers learn about the candidates, get a sense of how they operate, and whittle down the list further. In the later stages of the interview process, some present basic tasks for applicants to complete, thus providing a better glimpse into what each candidate may offer the company.

In the end, what’s the main purpose of all of this? Companies want to get a clear idea of which candidates are the best fit for the job. How do these people work? Does their work style fit in with our needs? What are they capable of? What might we expect when we set these people to work on a game project? Essentially, the entire application process is about the company determining whether or not you’ll be able to make games with them.

As far as I see it, there’s a much better way to accomplish this task than simply through this traditional “apply-interview-analyze” process. Frankly, if I wanted to see if potential employees were capable of making games with the team, I’d have them do exactly that – make games with the team.

The value of game jams has been under a bit of examination lately. They’ve always served a purpose in the form of providing a challenge and allowing jammers to network on a basic level, but companies are starting to see a more practical application for game jams, as well. Intra-office game jams are used to loosen up employees, generate some quick new ideas, and re-spark a creative drive. They get team members working together in some new ways, giving a new life to projects that can drag on for years. (One of my college friends, Auston Montville of Tagged, Inc., gave a useful talk on the subject at GDC 2012.)

Studio-run jams generally seem to be limited to existing studio employees. There’s nothing wrong with this, but I feel a great networking opportunity is being overlooked in such a private session. I’d like to see a greater effort for game studios to host public jams that can connect professional game developers to, shall we say, “outsiders”.

Two Approaches

There are several ways in which I can see studios approaching a more open sort of game jam. In my most ideal vision, a studio would arrange a jam open to anyone who takes the time to register (taking into account capacity limitations). Registrants are placed into mixed teams with employees. For a couple of days, the various teams work to complete their projects, just as they would in any other game jam. This not only gives amateurs and newcomers valuable hands-on experience with game professionals (not to mention valuable professional contacts), but it also provides the studio with a glimpse at the newcomers – their work style, their character, and their potential. If nothing else, the outside participants meet another group of people – a very useful group, mind you – who can attest to the quality of their work.

What I like about this approach is that it takes place with no real obligation on either side. Employees can intermingle with non-employees with no real expectation. All everyone is here to do is meet a few new people and make a game. No strings attached.

Perhaps a more purposeful and targeted approach to such a jam, though, would be in the form of a job interview. Such an event would still be specific to the company, just as the intra-office model, but instead of utilizing only employees, the jam would invite along job candidates. This wouldn’t necessarily include everyone who applied for a job. More likely, it would include only callbacks, essentially taking the place of an interview. Just as with the jam above, applicants are grouped together with employees for a quick couple of days of game development. Not only do employers get a good look at how their potential employees operate in a high-pressure development scenario, but candidates get to compete with each other in a professional and fun environment, rather than simply waiting and hoping for the best. Even those who don’t come out of the process with jobs have been through a full development cycle (albeit compressed) with industry professionals. As an added bonus, people on both sides may come out of the experience with new ideas for current or future projects.

Final Thoughts

These scenarios wouldn’t always be viable options, of course. They would be at their most useful at the beginning of a development cycle when large numbers of new hires are taken on at once and employees aren’t yet locked into a firm development schedule. However, studios that make occasional jams a part of their regular operation have numerous opportunities to expand those jams to a more public arena, as well.

I’m also not suggesting that game jams should completely replace the traditional application process. A professional interview and personal presentation are both still important parts of determining a person’s viability as an employee. But jams offer us the opportunity to interact in a unique way, and it’s a style of interaction that says a lot about how we go about our work.

Perhaps these are just the words of someone frustrated with the traditional job application or traditional networking practices. Whatever the case may be, though, I do sincerely believe public company-sponsored game jams have a future. I’m not sure they’ll actually catch on, but I believe they have considerable practical applications. There are elements of this process at play in many places, but not quite on the level I’d like to see. The idea of encouraging professional game developers to work with newcomers in a short, energetic development process holds a great deal of potential for all parties involved.

The "Unplugged" Album

I’ve been doing this for about a year now.  Many of my blog posts are written from the perspective of some lunatic raving about high-level design theory.  What makes a game good?  What can we think about when we’re designing?  What sounds clever and thought-provoking while still disguising the fact that I have no professional experience to draw on for the sake of my argument?

(Answers [Respectively]: Licensed Merchandise, Food, and, “Hey, quick, what’s that over there?!”)

Today, though, all of that changes.  I’m going to make a comparison of two things based on ACTUAL EXPERIENCES!  That’s because, for the first time ever, I recently completed the design and development of a non-computerized game. 

The Basis

I’ve spent the better part of the last six years designing (or learning to design) video games.  This is a particular branch of the vast community of game genres out there, and it’s one that I’ve been focused on.  It lends to a particular style of thinking.  However, over the past few years, I found myself wanting to do something in particular that demanded thinking outside the confines of electronic gaming.  “Wouldn’t it be nice,” I thought, “if I, as a game designer, had a business card that actually demonstrated that?”  Thus, back in November, I set about converting my business card into a playable board game.  In actuality, I turned it into four games, which I proceeded to unveil in a completely untargeted and reckless manner at this year’s GDC.  At most, roughly one percent of this year’s GDC attendees may potentially know what I’m talking about. 

That process gave me a few new insights into some of the differences between designing for an electronic platform and designing for what is often called a “traditional” platform.  Some are obvious, but some of them can easily slip under the radar.  Or maybe that was just me.  For your consideration…

What are some of the differences between designing a video game and designing a “traditional” game? 

Automation

One of the keys to designing a video game is the inclusion of elements of interactivity.  The game is able to communicate with the player, at least to some degree, and provide some level of automated feedback.  A non-computerized game loses much of this feedback. 

Now, I don’t want to get into a lengthy semantic discussion here, so let me quickly explain exactly what I mean by “automated feedback”.  “Feedback” can qualify as an action presented on one of Monopoly’s Community Chest cards, for example.  However, the player has control over the presentation of that feedback.  The player can always choose not to play with cards, not to draw that particular card, or not to follow the action portrayed on that card (breaking the rules, of course, but still by choice).  Automated feedback is forced on the player – an action triggers a reaction, and the player can’t avoid it.

Thus, in a board or card game, any feedback the game can provide is dependent on the player’s cooperation.  This is the key element upon which the other elements listed below are based.

In the case of my design, the only tool the player can use to aid game feedback is a pencil.  Interactivity is entirely dependent of the player’s willingness to constantly mark and erase spaces on the game board.  Such interactivity is much more easily handled by an automated system.  In an electronic format, the player would only need to be concerned with making a move, not with the specifics of how to mark down each move on the board.

How can this lack of automation be used to the design’s advantage?  I’m not willing to hypothesize too much since I’ve only done this once.  However, I’ll say this much: with a lack of automation, the player becomes much more exposed to the game design’s internal functionality.  The player’s knowledge of that functionality can provide some interesting opportunities for play alterations and some player-based evolution of the game.  You can potentially encourage “hacking”, if you will.  That’s just one example.  I’ll discuss a bit more about the player’s knowledge of game functionality below.

Documenting for Players

One thing I learned to do in college as a game designer (over and over again) was to create and maintain documentation for my games.  I was shown the importance of the DESIGN DOCUMENT, a mystical tome from whence video games are spawned.  Programmers like to sit around this document and shoot down any ideas that emerge from it (i.e., spawn camping).

A design document is written for the benefit of the development team.  Developers turn to this reference as a source of instructions for building the game, constantly updating and altering its content as conditions change.  The design document is often referred to as the “blueprint”.  It provides a basis for what resources are needed, how mechanics fit together, and how basic systems function.  Development teams take these elements and combine them together in such a way that the computer builds a world for the player and, essentially, teaches the player how the game works.

As I was creating my business card, however, I noticed a strange pattern occurring.  Instead of writing a design document, I found myself writing instructions for the player.  I wasn’t so much providing a reference for others (or in this case, myself) to build a game, but rather bypassing this direction and speaking directly to the player.  In essence, I found myself “programming” my game as it was being designed.

Once again, a lack of automated feedback has a great deal to do with this.  In the space of a video game, programmers dictate game functions by telling the computer how to react to a given situation.  Generally, the rules of play are revealed to the player over time as these actions and reactions are repeated.  The development team and the computer have to know how the game works from the beginning, but the player merely needs to observe and learn as the game unfolds. 

In a traditional game, there is no computer to react to game situations.  Any reaction must be made by the player.  As a result, all of the game rules and functions need to be conveyed directly to the player.  “This action has this consequence.”  What would normally be sitting in the code as an “if/else” statement is simply described directly: “If the player rolls a twelve, he draws a card.  Otherwise, he moves the number of spaces displayed by the dice roll.”  In this sense, a non-computerized game is “naked” – the potential actions to be taken are laid out right in front of the player, rather than hidden away in AI functions and code blocks.

This isn’t to say that a design document is irrelevant in a non-computerized game.  There is still information relevant to the game’s functionality you may want to take note of while still keeping it hidden from the player.  Noting particular useful strategies, pointing out advantageous game scenarios, and, depending on the game, listing solutions are all elements that can help you determine what tweaks to make in the rules or what direction to take the design, but it stands to reason that revealing them directly to the player might break the gameplay experience.  In this case, a design document can prove to be a useful addition.  In the end, however, the final rules presented to the player will entail the bulk of the game’s design.

Complexity

Working off of the prior subject comes the issue of complexity.  This is an element that I, admittedly, may not have taken into account as well as I should have.

Considering that a non-electronic game is explained to players largely through pre-written instructions, such a game needs to be capable of being conveyed clearly and concisely through those instructions.  Every game system is built of a set of steps to be followed in sequence.  In a video game, some of those steps are covered automatically by the game.  A non-electronic game, lacking that automated feedback, forces the player to perform every step in the process.  As previously stated, the player has the advantage of seeing all of the immediate consequences of game actions laid out in the game rules.  However, the addition of this information comes at an obvious price – the player has more to learn.

The issue of complexity is primarily an issue of time.  Just as it takes more time to program a computer system to execute a more complex sequence, it takes more time to program a human player the more complex the sequence becomes.  The more time it takes someone to figure out how to play a game, the less likely they will be to play it.  If computer code is written incorrectly, a program may fail to compile properly, but the programmer can continually go back and fix the language used until the program runs.  People aren’t as willing to undergo nearly as much trial-and-error; if someone doesn’t understand how the game works, you can only rewrite the rules so many times before they refuse to even make an attempt.

It’s difficult to describe effectively, but I can tell you straight off that complexity in a non-electronic game is decidedly different than complexity in a video game.  Video games often feature a wide variety of actions, each one with a different effect on the game.  Their complexity comes out of finding the correct situations in which to use each of these many actions, placing them in the correct sequence with the proper timing.  Many non-electronic games feature a very small number of actions and rules.  Their complexity comes out of the player discovering the many different uses for those few actions.  In effect, the video game dictates a play style to the player, forcing the player to adjust his style to fit the game rules.  In the effective non-electronic game, the player’s play style dictates the functionality of the game to a much greater extent.

Looking at it this way, I realize that my business card games were designed from a video game mentality.  They have a heavy emphasis on sequence and cause-and-effect.  As a result, they are easy enough to understand once you understand the sequence, but it takes far too long to fully convey that sequence in written instructions.  The combined instructions for my four games totaled out to a 65-page document.  Granted, this included a number of large pictures, lots of repetition from game to game, and a lack of text-image wrapping, but it still means the instructions for each individual game range from 10 to 25 pages.  Combined together, that’s a bit intimidating to look at.

The basic rules for any game have to be as simple for the player as possible.  For equivalent electronic and non-electronic games, the rules of the non-electronic game will be twice as complex as those of the electronic game, at least from the player’s standpoint.  In order to cover both action and reaction, the player must learn twice as many rules.  As a result, there is a greater need for simplicity of gameplay in a non-electronic game as there is in an electronic one.

This isn’t to say that non-electronic games are doomed to have less depth and complexity than electronic games.  Two non-electronic examples often cited in game design lessons – Chess and Go – demonstrate very simple rules, but with immense underlying challenges.  Understanding how to play takes just minutes, but becoming a successful player takes years, even a lifetime.

Therefore, it would seem that the real trick with non-electronic games is to create complexity through simplicity.  Simple gameplay rules with simple relationships between action and reaction create a game that can be played in an immense number of ways.  The game is approachable, it’s easy to follow, and it promotes repeated replays.  It’s probably worth noting that while these elements are a key consideration in the creation of a non-electronic game, they are also tremendously important in the design of a video game.

Wrap-Up

So there we are.  These are just a few of the new things I’ve come across in my exploration of the non-electronic gamespace.  Looking back, some of my mistakes have become much more obvious, but then again, that’s what this is all about.  I’m here to learn, and I’m here to pass that knowledge on to you.

Thank you.  That is all.

...

By the way, if you’re interested to know exactly what I’m talking about, feel free to sample the Business Card Games at http://www.douglynnportfolio.com/thebusinesscard.htm.  

I’m still looking for some legitimate test data to work with.

The Scientific Method

The question of “The Art of Games” keeps coming up in discussions.  However, there’s a piece to this discussion that’s always present in some form – the Science of Games.  Art or not, these two theoretical situations demonstrate how many, many games out there are products and promoters of the scientific process.

THE GAMER

Problem:

I seem to die every time I fight this boss.

Question:

How can I get past this boss without dying?

Observations:

The boss has a very big machine gun, which fires in long bursts and deals out damage quickly.  He is heavily armored, and as a result, doesn’t seem to move very quickly.  He always seems to know my location, even when I hide somewhere, so he can always track me down.  When hit with a powerful enough blast, such as a grenade, he is dazed for a short period of time.

Hypothesis:

I’m focusing too much on racking up lots of damage at once, spending too much time exposed.  By quickly ducking in and out of cover, I can deal out small amounts of damage at a time.  While it may take longer, it should provide the protection I need to outlast my opponent.

Materials:

Let’s focus on weapons that can discharge quickly between pieces of cover, preferably while I’m on the move.  Grenades can quickly be tossed.  The light machine gun is great for strafing runs.  A medium or heavy pistol is also in order for quick pick-off shots.

Procedure:

1. I began by equipping the Light Machine Gun (LMG) while standing in the opening anteroom.  I approached the corner, hugging the wall.

2. I rushed out to the barricade in the center of the room.  On the way, I fired a quick burst from the LMG.  Having reached the barricade, I immediately ducked down.

3. The boss proceeded to unleash a long stream of bullets from his machine gun.  I waited several seconds for the wave of bullets to subside.

4. While waiting, I prepped a grenade for use.  As soon as the firing ended, I quickly rose up and released the grenade towards the boss before ducking back down. 

5. Quickly, I re-equipped the LMG and waited for the blast.

6. The blast occurs, damaging and dazing the boss.  I rose up and quickly emptied a LMG clip into the boson this occasion.  Before his daze wore off, I ran for third pillar on the right while equipping the pistol.

7. As the boss recovered, I gazed around pillar and fired three shots.  The boss began firing once again.

8. I moved to the next pillar, taking a few hits on the way.  Once more, I waited for the enemy wave to subside.

9. Rounding the pillar, I fired two more shots.  I quickly dove into second anteroom before the next wave of bullets commenced.

10. Within the anteroom, I was able to retrieve fresh ammunition for the LMG and Pistol.  Moving to the corner, I waited once again for the wave of bullets to subside.

11. While waiting, I prepped another grenade, stepping out to release it immediately when clear.  Due to an error in aim, the grenade failed to land as accurately as hoped.  However, the blast radius was still sufficient to damage the boss.  I made a run for the pillars on opposite side of room, re-equipping the LMG.

12. Following the grenade blast, I proceeded to fire precision shots at the boss character’s head for the duration of his dazed period.

13. I ran up to the last pillar in the row, equipping the pistol.  Several more shots impacted me along the way as the boss character recovered.

14. I rounded the pillar and fired two more careful shots.  Following this, I dove back into the first anteroom.

15. Acquiring additional ammunition in the anteroom, I repeated steps 1 through 7.

16. Following a final Pistol shot, the battle came to an end.

Analysis:

Initial results during execution appeared promising.  Though the perceived progress in relation to the time elapsed seemed much lower than in prior attempts, the amount of damage sustained in the process also seemed to be much lower.  While the battle was taking a longer time to complete, it stood a better chance of progressing farther than in pervious attempts.

Results:

This boss has been utterly and completely owned.  In the face.

 I shouldn’t say that.  I barely got through that fight alive.

No, you know what?  Owned.  Destroyed.  Wrecked.  End of story.

Conclusion:

In this instance, panic and haste seem to be less effective means of play than methodical use of cover and speed.  As the boss is based on powerful attacks, it seems to be well-equipped to defend against the same type of attack.  Quickness and a thorough use of defensive cover proved to be the winning solution.

THE DESIGNER

Problem:

This puzzle doesn’t seem to make sense to the QA team.

Question:

How can I make this design easier to understand while retaining an adequate level of challenge?

Observations:

The existing puzzle is meant to reflect upon the main character’s childhood memories.  As a result, certain childlike elements are incorporated into the puzzle.  A rubber duckie, toy frog, and toy firetruck populate the game area, each one with a different function.  Colored pipes on the floor lead from each object to the next part of the puzzle.  The colors of the pipes correspond to the colors typically associated with each object (red firetruck, yellow duck, green frog).  By activating the objects in the appropriate sequence, players fill in freaky void spaces in the water, swim through air (i.e., fly), and alter the water level to progress through.

Hypothesis:

Too many elements are being introduced at once.  If I trim down the number of mechanics used to solve the puzzle, it can help.  By reducing the number of inferences and implied associations, the puzzle should have more universal appeal.

Materials:

The idea of twisting corridors has been done to death, but it works well and is easy to understand.  Twisting corridors.  We’re underground in a storm sewer, so water and swimming seem to be logical components.  I have immediate access to assets for wheels, levers, buttons, and lights.  The existing puzzle contains a rubber duck, rubber frog, and toy firetruck, along with null spaces and colored pipes.

Procedure:

1. Initial re-evaluation.  I examined the nature of the puzzle in relation to the rest of the game.  Which elements are the most vital?  Which are the best fit for the environment?

2. The existing sewer setting proved important to the story’s progression.  Working from that element, the most necessary feature from an aesthetic standpoint seemed to be water.  Consequently, swimming proved to be the primary mechanic fitting the environment.

3. Elements of fear are pervasive throughout the game.  A great number of dark, cramped spaces make the player feel crowded and trapped.  In maintaining this atmosphere, the existing concept of a twisting, narrow maze fit in very well.

4. With these key elements isolated, I proceeded to eliminate the less vital pieces of the puzzle and go back to a more basic starting point – an underwater maze, traversed by swimming.

5. The basic concept, through fitting in with the game, lacked challenge.  Adding a degree of complexity became the next step.  Originally, this was the function of the toys-and-colored-pipes system.  However, the original system proved too complex. 

6. Re-evaluating the system began with removing its “symbolic” pieces.  This meant looking beyond the specific art assets – the toy duck, frog, and fire engine, along with the element of color – to determine the actual gameplay structure of this system.  That gameplay structure turned out to be a simple one – a sequence puzzle.

7. Working the sequence puzzle into the maze system meant avoiding the vagaries and implicit nature of the original layout.  Instead of utilizing numerous objects that do numerous things, I began by simplifying the process and having a single type of object do one thing.

8. Analyzing the gameplay mechanic of swimming suggested that the water itself could prove to be an effective barrier mechanism; the player can only swim as high as the water can reach.  As a result, a secondary mechanic emerged – move the water.  By moving the water, the player can move through the game world.

9. Thus, the function of the single type of object to use was determined.  When used, this object would alter the water level.

10. With the mechanic in place, mapping could proceed.  The existing maze from the original puzzle was in place.  Working from its structure, different water levels were worked out that could be used to access different areas.

11. Upon examining the new mechanics, it occurred to me that the puzzle was not based so much on determining a specific, correct sequence, but on moving from one point to another linearly.  Each object only raised the water level.  All that was required to complete the puzzle was to explore the entire area and locate each object to raise the water.

12. To expand once more upon the mechanic, an element of asymmetry was introduced.  Each object not only raised the water level, but also lowered it in another area.  As a result, some of the locations that could originally be reached with just two moves now required a sequence of five or six moves to reach.  This new layout demanded much more from the player in terms of analysis and problem-solving, increasing its level of challenge.  Still, the concept itself remained quite basic, lacking the implicit nature of the original design.  Incidentally, this mechanic also made more sense aesthetically; water was not simply appearing, but being transferred from one area to another.

13. From this point, all that remained was the selection of the object to be used to alter the water level.  Several existing options were available to choose from – namely, a wheel to be turned, a lever to be pulled, or a button to be pressed.  The lever seemed to indicate directionality.  Since water was being both raised and lowered at the same time, this directionality conflicted with the gameplay.  The wheel ended up being chosen as it seemed to fit more properly into the underwater environment.  Additionally, it provided greater movement than the button, allowing for a more visible effect upon use.

Analysis:

Testing the puzzle on my own time seemed to suggest a much more left-brain-centered design than its predecessor.  Even in its early stages, it seemed more logical than the original design.  Despite the loss of artistic flair and symbolic complexity, it somehow seemed more challenging in its new form.

Results:

A new round of testing indicates a much higher completion rate of the new puzzle design.  Reports of frustration and confusion are significantly reduced, as are reports of accidental solving.

Conclusion:

While artistic expression is important to this game from a narrative and aesthetic standpoint, it doesn’t work as well in the logic-based format of the puzzles.  The more artistic and narrative-based puzzle simply seemed to be confusing, whereas its more logical counterpart was more playable and contributed more to the overall quality of the game.  In this particular instance, the story seems to be told most effectively through the atmosphere and the gameplay, rather than through more literary methods such as symbolism and metaphor.

(No offense intended to the actual designer of “the original puzzle”.  Good times.)

…

Question:

How can I tell people about myself without actually meeting them?

Hypothesis:

Let’s just say I’ll see you at GDC.

Or rather, I hope YOU will see ME.

Lowering Expectations

"Hello. My name is Doug, and I am a motivational speaker."

At least, that's the role I'll be filling today.

There’s quite a serious desire, especially as a beginner, to make a big mark on the game industry.  No matter how rational and level-headed you are, it’s easy to envision yourself as the developer of the next Portal, Angry Birds, or Minecraft.  And yes, there’s the remote possibility that you could be that person.  However, chances are also pretty good that if you get into the game industry at all, you’ll spend much of your career working on rehashes of old concepts, film- and TV-licensed games, and overall generic, unremarkable titles.  If you think about it that way, you can easily start getting concerned.  “I need to make something special right now while I still have the chance.”

So that’s exactly what you try to do.  You put all of your knowledge and skills to the test.  You come up with crazy new concepts and attempt to find ways to execute them.  You attempt to make game engines do things they weren’t designed for.  You work under the guise of “Boy, if I can make this work, I would just be the most awesome person ever!”  You look at your creation as something that no one will be able to ignore.  In a good way.  Not in a Mystery Science Theater 3000 kind of way.

Then again, maybe that’s just me.  Which reminds me…

THIS IS AN IMPORTANT NOTE:

The recommendations in this blog post are not intended to apply to everyone.  This is not general advice.  Everyone has a unique way of working, getting motivated, and making things happen.  If your brain works in a certain way, the information you are about to see may be completely wrong.

What, then, is my target demographic?  Who is this advice designed for?  It’s designed for those who are inspired by the big picture, but who need something else to gain the motivation to learn something new.  It’s for anyone whose delusions of grandeur have overpowered the ability to expand and grow.  It’s for those who have forgotten about the virtues of patience.  And, on a more pathetic note, it’s for people like me who have worked under established guidelines all their lives, and have now realized that they can’t establish guidelines of their own.  In short, it’s for people who need motivation to keep learning.

As we grow up, we’re told to reach for the stars.  There’s nothing we can’t do.  We are awesome.  While this may be true, this line of thinking has a particular, glaring flaw.  When one “reaches for the stars,” there is an implication that the goals we strive for are far away.  In response, we establish short-term goals that can help to lead us to this final step.  Our conscious minds are more capable of interpreting and dealing with these shorter-term goals, delegating our ultimate goal to the back of the mind to be dealt with later.  In a few years, maybe.  Thus, we move incrementally up a path we’ve established, making that unreachable goal seem much more attainable.

As we move closer and closer to our ultimate goal, however, it becomes harder and harder to follow the established path.  While the steps to reach the end become smaller and smaller, the desire to follow those steps diminishes.  When the end is in sight, it comes back into focus and blocks out everything else.  “This is what I’ve sought for years, and it’s about to happen.  My dream is becoming a reality right in front of me.”  We’re so close to the stars now that we can almost reach out and touch them.

“Almost” being the operative word.

Einstein’s theories state that as one moves closer and closer to the speed of light, it requires the expulsion of exponentially greater amounts of energy.  If you’re traveling at 99 percent the speed of light, basic thought would seem to suggest that expending that last percentage point worth of energy would get you there.  In reality, (at least according to the now-aging theory), that extra percentage point would take you to more like 99.00001 percent of light speed.  “Okay, then…light speed is right there.  I’ll just double my energy output and that should put me well over the top.”  So you double your energy output.  You’re now traveling at 99.1 percent of light speed.  So on and so forth.

Reaching for a major goal feels similar to this concept.  In the beginning, it seems outrageous and practically unattainable.  As you move forward and apply yourself to the problem incrementally, you move closer and closer to your goal.  Eventually, you reach that elusive 99 percent.  Only a few simple steps will help you to break that barrier and achieve your dream.  On the other hand, with your dream staring you right in the face, another possibility becomes more and more appealing: you’ll take what you’ve achieved, all you’ve learned, and press forward with it.  You’ll consolidate your 99 percent, make it more efficient, and hope that it can push you the rest of the way.  In the end, though, no matter how much you spruce up your 99 percent, it can still only take you 99 percent of the way.

What’s the point of all this nonsense about percentages?  The gap between knowing MOST of what you need to know about making games and knowing ALL you need to know about making games is bigger than it seems.  More accurately, “knowing all you need to know about making games” doesn’t exist.  There is no 100 percent.  While this is true of anything that demands the accrual of experience, it’s especially true in a field as consistently shifting as gaming.  New technologies, new processes, and new ways of thinking are always entering into play.  There’s always something new to learn.

So let’s take a completely random, out-of-the-blue, entirely hypothetical situation.  Let’s say you graduated from a Bachelor’s program in game design some, I don’t know…32 months ago.  You learned a lot there and built up a pretty sizable skill set.  You know how to market yourself fairly well, and you’ve been trying to use that skill set to net yourself a job in the industry.  Good.  For some reason or reasons unknown, however, you’re just not making a mark with your prospective employers.  Maybe you complain a lot about the requirement for 2 years of experience on so-called “entry-level” jobs.  Maybe you’ve thought about trying to go independent.

Over the course of all this, you’ve been trying to work on some projects to build up your portfolio, and you’ve run into a few snags.  Primarily, you seem to have a lack of fully-completed, fully-playable games available to show to the world.  Now comes the time to ask a question: “Why don’t I have any fully-completed games here?  Is it the fact that I can’t get my [artist / programmer / designer] friends to help [make me some assets / make this thing work / make this thing “work”]?  I know it’s not me because I can do anything.  People have been saying that all my life.  I can do anything, just…not everything all at once.”

Stop right there.  I’m here to crush your spirits.  I’m going to destroy all of your hopes and dreams.

It’s your fault.  You don’t know as much as you think.  You are not worthy.

There.  Now what do we do when people break our spirits?  No, no, stop crying.  It’s okay.

If you find yourself struggling to find motivation, if your eye has been dead-set on the end goal, and if you find yourself struggling to complete your heroic quest, consider that your wakeup call.  What I meant to say is, “You are not worthy…

“…Yet.”

  All that means is that there’s still more to learn.

Of course, the idea that there would ever NOT be more to learn is ridiculous.  What I’m talking about here is taking a step back, going back to your roots, and re-learning the basics.  Whether that means going through old tutorials and training programs for the basics of Unity, something as major as reexamining what makes a game a game, or something as minor as reevaluating the basic language of a C++ sequence you set up at the beginning of a project, going back to basics can remind you of what you need to do to complete your ultimate task.  Treat yourself like a rookie.  At the very least, it will make you feel smart to learn about the things you already know.

But the true goal here is something bigger.  Lowering expectations isn’t so much about making yourself feel more qualified to do what you do.  Really, it’s about reigniting that spark to learn something new.  By going back to the beginning, you get introduced to new avenues you may not have explored before.  New information resources turn up.  New chains of thought are set into motion. 

Perhaps most importantly, you can present yourself with the opportunity to stop trying to solve a specific problem you might be facing.  If you’re building a game from a preexisting engine, it’s easy to get caught up in the frustration of, “I guess the engine just isn’t designed for this.”  Maybe Unreal just isn’t designed to allow two rockets fired from opposite directions to hit each other in midair and explode.  (I’ll admit…I haven’t actually tried this.)  When you go back to the basics of the engine, though, and re-teach yourself about collisions, weapon mechanics, and the basic functionality of code blocks, you can likely discover that all of the elements you need are there.  You may even look at elements you never considered to be part of the solution before.  The more you learn about those basic elements, the easier it becomes to see how they can all be connected to create the desired effect.

Essentially, treating yourself as a rookie gives you the opportunity to stop looking at problems for what they are and start looking at their component parts a bit more.  By doing so, you get a new opportunity to evaluate your problem and tackle it once and for all.

And after that’s done, I’ve got some more work for you.

If you find yourself stuck and you have the luxury of some extra time, step away from the problem and go back to the beginning.  Revisit what you thought you knew, and then, go further.  Before long, you’ll be able to take what you’ve learned and apply it to the problem you’ve been facing.

Theoretically, anyway.  I don’t offer guarantees.

Thank you.  That is all.