MAIN
UE 3
FEAR 2
OFFSET
COD 3
COD 2:BRO
COD:UO
TRINITY
QUAKE 3
DESIGN
FAQ | 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
| Save Your Experiments "...The X-Levels" |
More often than not, the weakest feature in whatever game you are working on will be your AI. This happens during a project for a number of reasons, but most commonly it's due to engineering issues involving stability and performance consuming the majority of development time. Unless a strong effort has been made on the project to focus on AI over a host of other items (such as the renderer, physics, or network code), AI will more often than not be the bane of the design team. It is therefore important to maintain a practice throughout a game's development cycle that can save you a lot of pain and heart ache; "test maps". At work, at home, and on the road, keep making test maps. Of what, and why, you may ask? Simple; it's called "proof of concept".
For starters, test maps are invaluable if for anything else than proving a certain game mechanic will play out exactly as intended, and/or determining the requirements from other resources to make said mechanic a viable contribution to the war chest that will eventually become the game. In other words, they allow artists, animators, and programmers to look at a feature of the AI (or just the game in general) in an ideal setting and plan how best to support it. This way, if during the course of developing your game you run into issues where your new play mechanic stops working, you can take that original test map with the ideal setup and attempt to see if everything still works. If it doesn't you can show it to a programmer, animator, or other responsible party and get the ball rolling on a solution. Having these levels from pre-production up until a game's beta phase is highly encouraged as it eliminates confusion over how an intended feature should work early on, and creates a mandate for the rest of the team's designers on how to replicate the feature in their levels.
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.
- 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.
- 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 LDA_Lake at Hotmail dot com.
Back to top
|