Over the years I've accrued some knowledge on the subject of game design and in particular concerning first-person shooters. For those of you looking through this portfolio who desire to one day work in the industry - or if you're a novice designer searching for some helpful hints - this is where I catalog such nuggets of information. Having been deep in the trenches of development, I've learned that some of the best knowledge is passed down from designer to fellow designer. Most the information found here is applicable to just about any type of game or technology. All I ask is that if you walk away from this page thinking its unsound, that you at least try it first. If your conclusions are different than mine I'd love to hear about them.
| Problem Solving "...The Player is Always Right, Not Always Stupid" |
There are a multitude of aspects that make up a well designed level, but the one of paramount importance is the ability for a level to give the player the sense that they are always right. What do I mean by that, you may ask? Well if you can, try to think of a game that you have played in the past with a particular challenge that frustrated you to no end; only to find a very simple solution such as an obscure button to press or a key to pick up. Or perhaps you encounter a particular boss that has no discernible weakness, and you spent days trying to find the chink in it's armor. More likely this was due to the designer not communicating how to achieve your goal, and what's worse is making you - the player - to feel as though you've discovered the secret on your own. Levels that are truly successful are able to convey both on conscious and subconscious terms what the challenge is, how to solve it, and provide the tools necessary for players to succeed - all while making them feel like they've uncovered the solution by themselves.
A classic example of this is the "Key Behind the Locked Door" puzzle. Assume for a moment that you've come across a four-way intersection of hallways, two of which contain locked doors. The first door directly in front of you is marked "Exit", and is clearly the way to, except it is locked. To the left is the second locked door with a window that looks into a vacant office. Just beyond the door is a desk with the required key set in plain view, and even further beyond is a bright-orange door labeled "Section B". Finally, to the right is another hallway with signs painted on the walls pointing in the same direction that say "This way to Section A and Section B". It may even share the same bright-orange color as the door inside the locked room to further tie ends together. At this point, logic should take over and the players know everything they need to, all without needlessly funneling them toward the answer in a fashion that will likely feel very linear. Players can travel down this hallway until they reach a T-junction and either turn towards Section B (the known solution) or explore Section A (which is the "control choice"). This solidifies for players that the outcome - the destiny of the game if you will - is in their hands instead of the designers. if this concept holds true through the rest of the level (and the game for that matter), then the player is made to feel like they are always right.
This concept is very basic for sure, but it is one of the best examples of the three necessities required for players to comprehend how the virtual world works - and it does so on many wavelengths. If you wanted to apply this philosophy to combat, all you need to do is change the variables in the equation. For example: if you wanted to show that a certain type of enemy can only receive damaged of a certain type, you could replace the key with the correct weapon. The signs would be either environmental hazards or fellow protagonists - some of whom would be wielding the key. The enemy in this equation is the locked door, which both reacts and retreats from (or retaliates toward) the wielder of the key. Ideally, you can apply this to a boss character, or any character type that has exclusive presence in the game. The point of all this is that when designing a puzzle, you should never have to make a big glowing sign to tell players "this is the key."
Back to top
| FPS Combat Fundamentals "...Some Advanced Topics" |
The professional level designer starting his career should know most of the basics. They know that putting guys at the end of a hallway will likely move the player in the direction of conflict. They also know that putting bright lights and colors on doorways and around corners can lead players along, and that flat open space is uninteresting for gameplay. Novice designers often learn quickly that using these techniques in repetition will result in repetitious gameplay, no matter how unique the individual space is. What most figure out is that unique presentation, and a twist on basic combat scenarios every now and then can break this cycle - placing a hazard in a room, employing moving geometry, implementing small puzzles between combat, and other interactions that move pace along at different intervals.
The seasoned level designer knows a few tricks beyond the fundamentals of good level design. They understand that enemies and obstacles should be presented in some form of introduction where the player will be aware of what they need to do. Experienced level designers know that lights and colors can have distinctive meanings depending on the design conceits and player's expectations established by the game. They also know that while elevation changes are very good at defining paths and creating interesting navigation, the downside is that it requires a balance between making a space have context within the game's universe and an area that is built purely for the joy of moving through it. Good designers pick up these ideals fairly quickly, usually within the first 2 years - others take longer. The ones that never learn beyond this are usually doomed to stay within the realm of level design throughout their career, sometimes earning a senior design role if they are lucky. The ability that comes from several years of experience - to understand how to break down each second of a battle - understanding how to influence they player's experience from before combat starts until after the battle is over is the difference between being a level designer and a lead designer. Lead designers not only know what techniques work, they know every aspect about why a technique works - and with this knowledge comes the application of altering these techniques in situations to generate truly engaging gameplay.
You may be asking how does one break down a level and know how and why certain techniques work? To start, you need to play games - LOTS of games - and not just any run of the mill games either. Great award-winning games like Bioshock, Call of Duty, and Half-Life, just to name a few. Games that are outside the genre of first-person shooters like adventure-puzzle games, strategy games, platformers, and role-playing games, are valuable resources as well. Playing these while having an objective and observant eye towards how the levels guide you along without being aware of it, how they present challenges, how they reward you for success and punish you for failure, are all useful for dicecting and understanding why those techniques work.
To give you an example, we can break down a typical battle in F.E.A.R. 2: Project Origin (in particular, . Why F.E.A.R. 2 - a game you exclusively worked on - you may ask? Two reasons; it was quite possibly one of the best shooters to cross arcade-style game mechanics with realistic combat utilizing advanced AI, and virtually every battle in the game was methodically and meticulously planned out from spawn to death. In general, Monolith has begun to develop an actual science to certain styles of first-person shooters - the foundation of which is applicable to the genre as a whole. The four pillars on which this science is based upon (at least, in my mind) are presentation, execution, combat aesthetics, and appropriate feedback. While some may argue that I am neglecting the fine art of Pacing in this list, keep an open mind as to how each of these four pillars together create the foundation for this all important element.
To begin we will take a look at presentation. One major directive during the production of F.E.A.R. 2 was that enemies should ALWAYS have a purpose in the world. In other words, they should always be actively engaged in some sort of task before the player arrives so that every group of soldiers armed to the teeth in every battle don't all feel like they've been exclusively waiting for you. This directive supplied three very important aspects to the overall design of the game and the user experience. First, the players have the illusion of complete control over how they choose to engage the enemy. Second, show-casing the AI interacting with the environment on personal levels speaks volumes to the enemy's intelligence and awareness of the environment (fighting an enemy who knows how to utilize the environment as well as the player is far more satisfying than an AI that simply ducks for cover). Finally, certain scripted presentations of new enemies or gimmicks are extremely helpful for players who must be aware of a new mechanic when one is first introduced. Giving the player as much information as possible about the battle before they "commit to the space" is essential to making the player feel confident about their approach, and even encourages them to experiment with choices which lead to emergent gameplay. Next, lets look at execution.
When talking about execution, what I mean in particular is how a scenario is executed. This happens in one of two ways - the "forced initiation", and the player's choice to "commit to the space". Forced initiation is a dirty trick in my opinion. This is the technique through which the player and the enemy are essentially pushed face to face with one another to acknowledge each other's presence, without giving the player the option or choice of how to engage. Although used to some small extent throughout F.E.A.R. 2, the preferred method for engaging the enemy was to have the player "commit to the space". You've seen me quote that phrase several times now and are probably relieved to know why - committing to the space refers the the player's choice to execute the scenario before them. This is accomplished a number of ways; passing through a one-way gate, crossing a visible threshold, making the player's presence known to the enemy by choice through visual contact, making a sound, vicariously injuring the enemy through some mechanic or opening fire, and more. No matter how it is done, it is always initiated by the player as a commitment to play the scenario. When this commitment is established, the player should be held to play the scenario to it's logical conclusion - allowing the player to back-track out of a battle or run past a group of enemies to escape a battle cheapens the experience and in effect destroys the purpose of the game - defeating or being defeated by an opponent. Now, lets take a look at combat aesthetics.
Combat aesthetics is a subject that is difficult to quantify, and is understood by few artists as it has nothing to do with visual aesthetics. This is a subject very near and dear to my heart, as it boils down the science of what makes a gunfight feel right (or in more morbid terms, "what makes the killing feel good"). Combat aesthetics have everything to do with enemy engagement distances, the tactile feel of cover (or protective geometry), the confines of the space, the speed at which things move, and opportunities available to the combatants. In particular, nearly every fire-fight in F.E.A.R. 2 contained one of the following essentials:
- "Flanking Space" - or in particular, geometry or cover provided with an element of risk for both the player and enemies that allows one to flank the other during a battle. There is a heavy concept of risk and reward when presenting players with options in a fire-fight that could mean victory or defeat. The risk in this gambit is the player or enemy exposing themselves to peril in order to secure an advantage over the enemy - which aside from triumph over the scenario, is the overall reward. The sense of out-witting an opponent in battle and emerging victorious is almost universally more appealing than simply gunning down a hapless grunt without any risk. A game without risk is neither challenging, nor engaging.
- "Combat Opportunities" - specifically, things that either players or opponents can capitalize on to improve the outcome of the battle. Most players and designers refer to this mechanic as the "exploding barrel" gimmick. However, when utilized properly by both the AI and a skilled designer, this gimmick becomes the difference between victory and defeat, especially when they can be used to temporarily cut off routes to cover, or apply environmental damage over time. In F.E.A.R. 2, designers used quick explosives like a fire extinguisher simply to knock enemies around or inflict explosive damage to a nearby victim. Larger incendiary devices such as propane tanks, oil drums, electrical junctions, and power transformers were used to effectively cut off entire spaces with damage volumes that the enemies would avoid. For a "gimmick" that temporarily changes the landscape of the battlefield, it is an effective tool for cornering foes and seeing dynamic enemy behavior. Ultimately, it makes the combat feel fresh and reactive to input.
- "Dynamic cover" - there are times when we all look at objects in the game world and think to ourselves "if only I could move that around to make some good cover". F.E.A.R. 2 took a risk - and in truth, made it a fundamental rule throughout the game - with one particular mechanic; the player can do whatever the AI can do. This meant virtually every animation, every interaction, and almost every tactic. Of most things, this included the ability to drag, turn, and topple over everyday objects into viable cover. With this mechanic in play, any object that looked as though it could be used for cover eventually was, but with the caveat that once those positions were used up, the objects in the environment that posed the potential for cover were realized as well. This system of thought toward enemies and players making their own cover not only added a new element of risk and reward, it pushed boundaries in terms of a player's perceived impact and interaction with the virtual environment. Players that were adept at recognizing what objects had the potential for cover could plan accordingly and use that knowledge to their advantage by keeping enemies confined by fire. Others found the dynamic cover useful for progressing through a hostile space when it seemed as though nothing constructed in the environment could aid them.
- "Ample Cover" and the concept of the "Ambush" - think of cover as an artificially intelligent entity all by itself. When an enemy AI is looking for the most intelligent place to hide, it asks the cover nodes which one is the best, based on things like the distance from the target and the field of view they have. Now imagine that during a fight that "ideal cover" has changed - maybe the target has moved too close, or out of the desired field of view. Whatever the reason, the enemies need to find a new "ideal cover". Sometimes that ideal location doesn't exist and the enemy needs a good hiding place until a new ideal location shows up and they can ambush the player when they emerge to claim it. This is why virtually every battle in F.E.A.R. 2 has at least twice the amount of cover for each individual character, including the player. Ample amounts of cover, plus giving enemies a place to hide and ambush from, generates lots of movement - lots of re-negotiating of space to find the ideal spots during combat. This constant kinetic action not only adds tons of visual interest, but makes a kill more gratifying when an opponent is caught off guard and out-smarted between finding these locations. Most importantly, it hits home the idea that the enemy is constantly thinking and strategizing against the player.
In addition to these elements, there is the fact that combat space by itself is a fairly exact science. The relation of objects in space in conjunction to the distance of the target from the player always feels best when these variables are equal to one another. Furthermore, targets are most satisfying to eliminate when their composition in frame is perfectly balanced with the surrounding detail. To bring these highly unstable elements together, a skilled team of designers needs to look at the ideal distance of the target based on it's size and screen presence, balance this with the ideal distance and view of cover placed throughout the environment, the heads-up display and the FOV of the rendered scene, and the architectural elements surrounding the areas with the most potential for a kill. While most studios don't have the time or budget to spend determining if the assembled elements make for a satisfying and well-composed reward, experience in playing and designing these sequences on top of knowing what to look for during play-testing your level will aid quite a bit in creating the ideal combat scenario.
The last pillar of good first-person shooter design is appropriate feedback. Now while in general it is true that this element has more to do with audio, effects, animations, and overall core game design, there is an element to world design that is key to giving good feedback to the player. That element is destruction. Before you go loopy and freak out because you think I'm talking about fully-destructable worlds with invisible player-containing walls, don't. Destruction doesn't need to be on a grand scale to be impressive, nor does it need to involve creating holes in walls. Destruction is relational, and by that I mean not many people have witnessed a building collapsing or a giant fissure opening up and swallowing the world whole. What is my point, you may ask?
There are tons upon tons of minutiae in this world stacked in orderly rows and piles that look like a massive mess when they become disorganized and scattered. Mix in a good three or four piles of different minutiae in a room and you have a royally-destroyed clutter bucket. During the development of F.E.A.R. 2, one of the main directives where combat affecting the environment was concerned focused on having as many objects that reacted to bullets as possible placed in harms way - between the enemy and the player. This in turn causes what they refer to as the "chaos of combat", where countless unpredictable ricochets send flying objects in all directions. This gave battle scenarios extremely satisfying outcomes, as the number of displaced detail objects were universally counted as debris and fallout from the resulting fire-fight. A diverse collection of cans, buckets, boxes, plastics, small furniture, dishes, vases, and an incoherant amount of easy-to-shatter glass all helped contribute to a sense of an environment being torn apart by gunfire. This level of inferred destruction gave extremely positive feedback to the player in the sense that their presence and actions were affecting the environment around them, making them feel powerful and immersing them further into the virtual world.
With the four of these pillars at the root of the core gameplay design and a tighter focus on the little things that make a game feel right, it's still pretty easy to miss the mark. Obviously moderation is the key. Knowing what you need and when to scale back is the difference between under-whelming or over-saturated sequences and well-balanced, well-paced scenarios.
Back to top
| Prefab Gameplay "...Because Your Job Will Only Get Harder" |
I shouldn't make promises with that title, because ultimately the formula varies from game to game. This is less of a "rule of thumb" and more of a humble suggestion, where it applies. Put simply, if players only wanted cool music and awesome graphics then there would be no reason for designers to exist. A designer has the most difficult job on the development team, and I'm not saying that out of ego or frustration. Designers are responsible for - and should be able to apply - a fundamental understanding of how the entire game works. Among other things, they need to understand and work around the engine executing lines of code every millisecond to prevent their design or scripted events/functions from causing either the GPU and/or CPU to hit a bottleneck, how specific materials can have more than one rendering pass and cause a significant loss in frame rate, how certain character animations may leave those AIs in undesirable states that could potentially break a game mechanic, just to name a few. Designers need to take all of these variables, and on top of it all create environments and experiences that saturate and engross players. So why should the best part of the job be as hard?
It is with that ideal in mind that I subscribe to a prefab game design philosophy. I'm not simply talking just about prefab objects and geometric primitives - I'm talking about a full-fledged gameplay scenario... a plug-and-play combat simulation. Similar to using static meshes in Unreal Ed or prefab objects in Lith Tech, prefab game design simply takes the idea of creating a proven combat setup (complete with trigger volumes, scripts, entities/objects, rough grey box geometry, and every basic necessity required for it to work), and place it into a level with minimal-to-no adjustment. Cover objects pre-placed and pre-arranged, the generic physical space in which a world artist merely needs to decorate, and miscellaneous lighting and zoning/streaming are all that should be required beyond placing the simulation into the world.
This is also where the real value of test maps come into play - if you've got a test map of a working game mechanic, then all you should need to do is integrate that work into your level. For example, lets say you've been experimenting with various layouts for medium-range rifle combat and come across a design that plays extremely well. Simply take all the raw elements of the setup (making sure to keep everything dimensionally relative) and create a prefab of the entire battle. Below is an example of a prefab encounter - a simulation - which could be imported into virtually any level.
| Combat Simulation Example |  |
In this simulation, enemies enter the scene using both the hallway and the exit route. Each enemy has one reserve that spawns on death, extending the overall combat time. Reserve enemies can be of the same class or perhaps a stronger variant, which primarily depends on the desired level of escalation. The cover placement allows for both teams of combatants to move into a flanking position, as well as advanced and fall-back positions. This helps to give AIs the appearance that they are intelligently choosing cover. It also has the added bonus of providing a number of solutions to players as to how they choose to encounter the enemy - playing cautiously and remaining in the background, or using the advanced cover and engaging the enemy up close (this can also depend on the arsenal in the player's inventory).
Now, I may come off sounding like an idealist but, imagine during a preproduction phase of a project that you have a couple of designers working purely on creating these grey box combat simulations that can then be plugged into any level, while the other designers work on proving specific mechanics like grappling hooks or gravity. Having a variety of different proven simulations like the example here ready to be placed into a level at the beginning of production would be a huge time saver that can then benefit other aspects of design like fine-tuning performance, or helping the art teams with building detail geometry and applying materials. Also, if your studio plans to rely on the same tech for a sequel or similar title, a good portion of those simulations can be recycled, which frees up the designers to create new simulations and mechanics.
I'll be the first to admit it's not perfect (especially for some projects starting with zero assets like generic AIs and/or weapons), but it is one way of reducing the strain of trial-and-error-based production, and retaining the team of designers that is sometimes shed when a project winds down prior to release and preproduction for the next venture. I do hope for development teams that are building on the tech of a previous title (especially a team that I end up working with) embodies some form of this philosophy.
Back to top
| Tips And Advice "...Things You Should Already Know" |
This last section is a collection of simple tips and techniques that were either passed down or discovered out of trial and error (in the event that someone else wouldn't need to). I hope you find it as useful as I did when I was starting out.
- For love of God and Country, save your work. Don't even think of turning off your Autosave feature... its almost exactly like your cushion acting as a flotation device in the event of a water landing.
- Every studio is different, and thus the cultures and nomenclature can vary quite a bit. For example, studios that rely on Radiant editors to create BSPs refer to raw geometry as brushes, while others refer to raw geometry as simply polygons. If you want to impress your lead designer and make the learning curve for new designers much easier, make a terminology cheat sheet. Once you've learned the vocabulary that your studio uses to describe elements of the production process (everything from basic tool functions to complex processes), copy these terms down and save them for someone new to review. The sooner your new colleague is speaking the teams language, the quicker you'll be able to iterate on tasks.
- You are an idiot not to consider the ideas of your peers. Even if you have a meeting with other designers and a number of solutions that are presented to remedy a particular problem in your level are turned down, don't simply dismiss them after the fact. Some of those solutions are golden nuggets in disguise. I would highly suggest taking some of those solutions and trying them out in test levels that would be easy to implement over your current work. If it works, show it to your lead and credit the individual who inspired the idea. Everyone (including yourself) will be glad you did.
- Test levels are important - almost as important as a game level itself, if not more so. Build them often, prototype absurd mechanics and awkward scenarios. Your understanding of how a game engine works and what kinds of new possibilities exist will expand greatly. Plus, you'll never know when you might stumble onto the next Portal, Braid, or World of Goo.
- Always be aware that your work is your portfolio. Take screenshots and capture videos of your work whenever possible. When your work goes public, it is fit to show - just make sure that what you have to show is impressive.
- Don't try to commit anything to memory that pertains to your work. Instead, commit it to a notebook or word document. Better yet, try getting a microphone and dictate to your computer or even one of those pocket recorders any complex game setups (a complicated setup of objects, variables used in everyday scripting, etc). Save them as mp3s and be sure to label them with a detailed name or description. It may really come in handy when you or a fellow designer need to debug an old feature that you haven't touched in ages.
- Good lighting is all about creating contrast, and one of the best ways to achieve this is by using as few light sources as possible. Always try to rely on the brightest source of natural light first (i.e. the sun, moon, etc.) before resorting to using other artificial sources. Keep the contrast of objects in either the foreground or background as varied as possible, emphasize on shadows and use (or attempt to fake) the natural bounce of light off objects in the scene to reveal objects in the dark. Unless your art director tells you, try to open up every space to be illuminated by the same source of light. When it's needed, use small lights to highlight specific objects of consequence (such as cover, items, or player navigation). Keeping your lighting scheme inconspicuous will in the end become noteworthy for both it's realism and natural beauty.
- If you use a node-based editor (like WorldEdit, for example), try and keep things organized beyond a healthy level of OCD. The last thing anyone wants to do when they have to work on someone else's level is figure out where everything is and what it all does. If the studio you work at doesn't employ a naming convention or organizational tree/hierarchy, implement one. Your co-workers will thank you.
- Be pro-active in squashing little bugs before they become lost and forgotten underneath the piles of major bugs towards the end of the project. Things like miss-aligned textures, small cracks, slivers, and holes in geometry have a tendency to haunt you long after you've finished a project.
That's all I've got for now. Hopefully some of what you've read here has enlightened or inspired you in some small way. If you've got a nugget of wisdom to share, have a different view of some of these philosophies, or would like to continue a more in-depth discussion on any of these topics, feel free to send me an e-mail at nick[at]mohilchock.com.
Back to top
|