How to Create a Design Portfolio - Part IV: Game Balance & Playtesting

So we've looked at the broad aspects of Mechanics Design and Level Design and potentially have a working game. Generally the refinement of a game comes via Game Balance and Playtesting (the latter part is essential to get proper game balancing in my opinion).

Game Balancing

Game Balance is a wide and complex topic, and a design skill that is often overlooked. The approach to balancing can also differ greatly between projects ore even between individual designers.

Simulation
Simulation is the concept of roughing out your gameplay in a reduced form - this might take the form of a board game, a spreadsheet, or a myriad of other ways.

The idea is to simulate the concepts and math behind the mechanics and by doing so, tune the various numbers that make it up. Generally I find the spreadsheet approach works best for modelling more complex games, as you can model in detail the underlying math that is involved.

Board Games, or Card Games can work well for digital versions of turn based video games, and allow the designer to see if the numbers for the turn system work. It can also result in some fun board games!

Data Analysis 
Rather than simulating the game, the other approach to game balance is to analyse data to look for patterns, or to calculate specific values that help you determine the game balance. Almost always this will take the form of a spreadsheet, as it really is the best way of laying out numerical data and creating charts, etc to visualize this data.

When balancing mechanics you need to determine a value to balance against. This will vary depending on what aspect you are attempting to balance:

• Damage Balancing - in an action game the likeliest method for balancing weaponry is based on Damage Per Second (often abbreviated as dps).
• Cost Balancing - if you are looking to balance the cost of items then you need to establish the worth of each element. The criteria for determining worth will be based on the main mechanical purpose of the elements in question (for example weapons are likely to be determined by dps).
• Ammo / Charge - distribution of ammo or level of charge for a weapon or skill is balanced by working out the ideal level at which ammo / charge should be kept compared to the number of shots to take down an enemy.
• XP / Levelling - determining how fast you want a player to level is the first step, from there you can work out the amount given per kill. You'll then want to increase the bar for each subsequent level so that you can prevent farming of XP in lower level areas.

Playtesting

Showing playtesting in your portfolio can be a little tricky, but there are a couple of ways you can approach the subject and prove your thinking in regards to playtesting methods:

• Create a playtesting plan for a specific game
• Detail elements that might be suitable for instrumentation
• Analyse data from an existing game and create a plan for improvements

Ideally you'd have your own game on which to perform these actions, but even without this you could use existing games to test your mettle.

Playtesting Plan

A playtesting plan should specify the conditions for playtesting, and the specific purposes of each test. There is a lot of great information about playtesting that can be gleaned from the web, but the real masters of this are are Microsoft User Research. Now these guys have state of the art equipment and environment for studying users playing the game, so unless you are detailing the playtesting of a AAA game, you are unlikely to be able to replicate their exact methods. You can however make sensible suggestions to get similar results with less equipment, and also detail what type of questions you might ask to gain insight as to how players are feeling playing the game.

Instrumentation Variables

Instrumentation is the act of outputting data from the game into a database so that various mechanics can be analysed and player progress monitored in detail. The type of data will of course depend on the game you are making, but typically you want to track various categories of data:

• Injury / Death - when a player is close to death, or where death actually occurs 
• Actions - places where particular actions are performed (combat, jumping, etc)
• Time - where players are at particular times - can be used to see when players are stuck)
• Fun - prompting the player to score their enjoyment at specific intervals can be used to see where players are or are not enjoying the experience

These data points should also store positional data, so that you can create Heat Maps - information that can be overlaid onto layout maps to see where particular events are occurring.

Data Analysis and Change Implementation

Data Analysis is required to make sense of any information gathered through questionnaires and via Instrumentation. This generally is done via either a spreadsheet and charts (particularly for questionnaire and mechanics data) and Heat Maps - positional data mapped onto a layout map. Heat Maps have been used in a lot of statistical analysis, even in sports such as Baseball. They are particularly useful for level design issues.

Ideally you'd have performed playtesting on your own game and have your own data sets to work with, but without this information you can attempt to perform analysis on existing data - such as Heat Maps shown for games such as Halo.

Determining how to interpret the data and present a list of suggested changes can be a lot trickier. Really a lot of it has to do with the philosophy of the game - what are the core themes of a particular level? Is the game ammo starved? Is the player meant to feel powerful or vulnerable?

Analyze each of the problems, then present a list of changes that you feel would correct these issues and detail how they would resolved the problem (without impacting something else).

If you are analyzing your own game then determining this philosophy is your own task. If you're analyzing an existing game, then you will have to show evidence of how you would balance a particular element to suit the game's approach. The latter can be harder to get right - particularly if you are presenting this data to the team from which the game originated.

Conclusion

Game Balance and Playtesting are two fundamental skills that a designer must learn. As a portfolio piece they can be difficult to display adequately. However, it is unlikely that many other applicants will bother to show their skills in these fields, so presenting such information can be the thing that makes you stand out from the crowd.

How to Create a Design Portfolio - Part III: Game Mechanics

Game mechanics is often considered the more pure design aspect of Game Design - often put on a higher pedastal that level design - though I feel that both are equally deserving of respect, but do require differing skillsets.

Displaying game mechanics in a portfolio is fairly tricky. We can simply document game mechanics via mechanics spefications, which proves you can document, but does it prove that the mechanic is fun? There really is only one surefire way to do that - that is to present mechanics ideas in the form of a game that you have  developed. There are a number of ways you could approach this...

Development Approaches

DIY
If you are going to embark on your own game design, then bear one thing in mind - keep it fairly simple! If you try to recreate Final Fantasy all by yourself, then you are highly likely to fail. Small games that have impressed me in the past have started with a very simple mechanic and embellished it across the course of the game. I hired a great designer (Giles Coope*) based on his small game involving one button press - Pizzicati.

There are plenty of methods of developing your own games these days. We've already mentioned UDK and Unity in previous articles, but there are also plenty of other options - XNA is another create framework to get started building games. There are also old school options like Flash.

If you are going to build your own game to showcase mechanics, I'd probably choose Unity, as it is the most rounded engine, is available on all platforms (including browsers) and supports several well known languages. XNA is interesting and very fully featured, but is limited to windows 7 phones and the Xbox 360 - it does however have a route to market through the indie games on Xbox LIVE, but if you are looking for good sales figures here you might find it somewhat lacking. UDK is just very complicated when going beyond level design - as it means digging around in UnrealScript and altering several important game files. Unity is a bit more abstracted and less prone to complete meltdown, plus you are really writing mostly your own code, not delving around in others.

You are going to need to be able to program, it's unfortunately a bit of a pre-requisite for building your own game. However, I cannot stress how helpful knowing a programming language is going to be for a designer. Most studios require designers to be able to script in some rudimentary form. The more programming knowledge you have, the easier this will be. If you really know about scripting, it also informs you about what is possible - which is great when certain programmers might be trying to pull the wool over your eyes ;)

* After working at Ninja Theory for a few years, Giles has now go on to become an indie developer - massive good luck to him - he'll do great ;)


Modding
The mod scene is a great place for would be level designers to learn their trade, but can also be a place to learn about mechanics design - assuming that the mod is significantly changing the original game.

Due to the way that most games are made, changing mechanics in game mods can be fairly hard work - it definitely requires coding experience. UDK / Unreal 3 mods are perhaps the best to get into, since the engine is so ubiquitous these days. Using UnrealScript will give you a real advantage in the workplace, but be warned, it can be a real pain to get things up and running, and because everything is so complex and interrelated, it is very easy to break something and find yourself in a code mess (keep very regular backups!).

Of course when showing a team built game you are going to have to explain to employers exactly which parts you worked on.

Competitions
I am slightly jealous of students these days, since there is now a wealth of opportunity to do game design - all sorts of free engines and most interestingly for me, a wealth of game design competitions to enter.

These can be a great way to build up a portfolio piece quickly, and have the added advantage of working in a team - demonstrating to you future employer that you can fit right in.

Of all the competitions around game design, the one that has really gained an international reputation for game design students is Dare to be Digital (which I had the privilege of being a guest judge for in 2009). This requires students to form teams and submit a game proposal to a panel. The panel then select finalists, who will spend a summer building their game before it is finally judged at the end of the competition period. The best game even wins a BAFTA!

There are of course others: DreamBuildPlay is run by Microsoft for its XNA suite. Epic run their Make Something Unreal - then there is the fantastic work done at the Independent Games Festival.

There are many more of these around, so keep your ear to the ground. If you can get into one of the bigger ones, such as Dare to be Digital, it can be a real highlight for your Resume/CV.

What to Show

So what do you need to show in your game to highlight your game mechanic design skills? Well really good mechanics tend to be composed of the following elements:

Good Haptic Design 
A good interface between control device and game is essential. The mechanic needs to be built to suit the input method.

Far too often I see touchscreen phones with the HUD D-Pad as an interface - this is a case of a game being forced onto an unsuitable mode of input. If you are developing phone games then use a suitable input method that is suited to touch control.

This also applies to game controllers. Be aware of the general pattern of hand movement during play. For example, first person games nearly always use shoulder buttons for major functions such as firing, as the face buttons cannot be used well whilst moving the second stick. Putting binary controls onto analogue triggers is another problematic control input, as it becomes fuzzy as to where the on / off boundary is.

Think about what the major actions of the game are, and map the controller according to these main actions - for example: the primary face button should map to the most performed action of a game if it is 3rd person.

Intuitive - Yet has Depth
A good mechanic should be intuitive - the best way to be intuitive is to have real world correlation. Whilst being intuitive is a key part of being a good mechanic, it also has to have depth - it needs to stand up to repetition. Generally the best way of doing this is through combination with other mechanics. Again the interrelation of mechanics has to be intuitive - if it has a real world correlation, then it is much simpler for a player to grasp.

User Feedback
A good mechanic will communicate with the player - it will tell them when it has been performed correctly, and will inform them when the player has not done the right thing. User feedback should be unambiguous. It should clearly show consequences of actions. There are many ways to do this, from animation, SFX, particles, screen flashes, HUD information, voice over lines, controller rumble, etc. Use what is suitable for each purpose, but always be clear about the message you are giving the player.

One example of a great game that I felt was completely undermined by bad (or even non-existant) user feedback is Uplink. This game by Introversion required you to hack into systems. If you leave any trace then you will get caught. Unfortunately they never told you when you had left information that leads to your capture, so you never learn how to prevent yourself from being caught. I felt it destroyed the whole experience for me - but I know that this was actually a conscious decision by the developers.

Engagement
Above all a mechainc has to be fun, especially one that will performed many thousands of times over the course of a game. Whilst all the above are a vital factor of making an engaging mechanic, there is also an element of "special sauce" - the feeling of flow when performing an action, the quality of the animation, the exquisite timing of an action or reaction.

This is where a lot of the talent lies, it's fairly easy to get a workable mechanic up and running, but the polish and refinement to make the mechanic just right requires time, a lot of playtesting and constant balancing to get just right.

How to Create a Design Portfolio - Part II: Level Design

Level Design is a very broad subject, and one that takes real skill, which is why it constantly amazes me how many companies view it as a low level profession - almost grunt work, whereas mechanics design is often seen as the pinnacle of design prowess.

It is the responsibility of a Level Designer to create spaces that people will utilize, move through, engage with and ultimately enjoy. All these responsibilities are rather similar to those required of an Architect - something that takes 7 years of training at university to become qualified in - so why is the job so often given to anyone who can just barely wield a level editor?

Thankfully there are plenty of companies around that are now understanding the importance of game space, and treating those that craft it with due respect. Which in turn means it is becoming more difficult to get into such studios without proving your skills as a game designer.

Type of Content

So what should your design portfolio be made up of? There are a few approaches to task, and the approach will depend on where you are applying.


User Generated Content


There are several games available that are championing User Generated Content - such as Halo (Forge), LittleBigPlanet, Infamous 2 and Mod Nation Racers. In truth, this is nothing new. I remember playing around with a world editor for a game on the spectrum. However, what has really changed is the ease of creation and sharing of these creations.

I tend to seperate UGC from Modding, since there is a large difference in technical ability required to get started. UGC is designed to be user friendly with a shallow learning curve. That's great for anyone who is new to game development, and wants to get a taste for building their own levels, etc. It does however create a number of limitations on what you can show professionally.

If you are trying to get a job in a specific company - i.e. Media Molecule, then UGC offers the perfect portfolio piece to demonstrate that you are capable of working for them. When applying to other companies it starts to get a lot trickier however. Firstly you have to assume that they have a copy of the game in order to play your level, then you have to hope that they are looking for designers of a similar genre. The biggest problem comes from the technical limits of the editors. Because they are designed to be so user-friendly, it is a big jump to assume that you are going to be able to dive in with a "proper" world editing tool, or be able to get to grips with a scripting language.


Therefore, I'd suggest that USG shouldn't be in your portfolio unless you are applying directly to the studio that made that specific game. Even then, you'd better make sure that your creation is something truly astounding, since they are likely to have a huge number of potential designers just sitting there in the database that they could tempt to do it for a profession (certainly a number of Media Molecule's designers were hired this way).

Mod Levels / Projects

Modding is a step beyond simple UGC, since it requires the creators to deal with more traditional world editing tools and scripting. Hence it really is the best way to get a foot into the industry door if you have the talent. This used to mean buying a game that game with the editign tools, but with recent developments in engine licencing, it is now pretty much free to get started (UDK, Unity and CryEngine3 all have basic licenses available for free).

Back when I started making levels for Half-Life, it required a large amount of perseverance and determination to get levels up and running. The supporting community was pretty small, but very dedicated. Lighting builds for levels used to take 2 days on my old machine. Things are a lot easier now thankfully, but that also means you have more competition.

If you can, try and join a mod team working on a specific mod of a game, as it will give you that experience of working with a team to create the game, which will prove invaluable.

Also remember that in order to show the game running your prospective employer will have to have a copy of the game, so don't pick anything too obscure (or use one of the free engines).

Finally, you will need to think about what exactly you want to show in your portfolio. I cannot tell you how horrific some of the stuff I have been sent in the past has been. Please don't send in your first map where you work out how to do a box and switch that turns on a light - it impresses no-one. You are actually going to have to build a fully featured single player scenario, or create a multiplayer map that show understanding of competitive map requirements.

In order to allow anyone who doesn't have the game or SDK installed on their machine, making a walkthrough video is a great way of demonstrating your design skills. You might even want to do some design commentary over the top to explain your thinking.

Level Design Process

Whilst the finished article is what will prove your design skills, it is important that you actually demonstrate a clear design process - this will give employers confidence that you can repeatedly deliver work of high quality in a time constrained environment, and can communicate your ideas to the team. Whilst there is no set  design process, there are definitely approaches that work better than others. What follows is the basic design process I follow

Research
Coming up with a brief set of notes of research on the setting, tone and style of your level can pay dividends. Source images for architectural styles, landscape looks, or lighting tones to show how you are thinking about the space.

Layout Sketches
Another important step is to sketch out rough layouts. There are numerous ways to do this, but as I mentioned in the documentation post previously, using a 3D sketching tool such as Sketchup allows you to get a more wholistic view of the level layout, and understand how space relates to each other.

Blockmesh / Greybox
From these basic sketches the greybox can be built. This is not required to be high quality modelling - this is more about the space itself - marking out the flow through the level. This greybox will be refined through multiple iterations as the scripting and playtesting feedback starts to inform the level layout.

Blockmesh could be done in a number of different ways. You could use a dedicated 3D modelling program such as Maya or 3D Max. Alternatively you could use the tools available in world editors such as Unreal. They are slightly different approaches to modelling, as one is based around polygon manipulation and the other is based on Constructive Set Geometry (CSG). It is valuable to learn both of these approaches.

Initial Scripting
This is where the scenario really starts to take shape, and where the choice of design tool really starts to affect how you will be working. There are two types of approach to scripting in most engines: scripting languages and visual scripting. The type of scripting you do will likely be based on your technical background.

Scripting Languages.
If you are using Unity then you are most likely to be using scripting languages such as JavaScript, C#, Boo (I use C# since I am a great fan of the language) - though a couple of visual editor plug-ins have been written for it (http://hutonggames.com/playmaker.html). Other games use Lua and Python fairly extensively (Source engine uses Lua for example). This approach generally requires a background in programming, otherwise it will be a fairly steep learning curve

Visual Scripting
This is where I would highly suggest using UDK or an Unreal 3 based game to create a level design portfolio piece, as visual scripting has been woven heavily into the fabric of the whole tool-chain. Kismet and Matinee work side by side to allow the designer to do some incredibly powerful stuff in terms of level design. The other advantage is that a lot of studios are using Unreal 3 engine, so having knowledge of how it works is a
distinct advantage.

Once you have set up the basic scripting for your level you will need to rework and refine. The only way to do that effectively is by playtesting.

Playtest & Revise
As a designer on a level, you are generally so close to your work that it makes it very difficult to be objective about how well something is playing. The only way to effectively gauge how good the level experience is, is to get another person to play through your level as you observe them. This is important even on your own profile piece, as it shows that you are used to following established techniques of development. It may even be a good idea to detail exactly how you went about playtesting.

Armed with data from your playtest, you can now revise and refine your design. Ideally you want to get at least 7 people to play through your level - that tends to be the optimum number to find most of the issues that people will have.

Add Final Assets
This is a stage that you might not need to engage in for a design porfolio, since the major part of level design is done, and is now reliant on other members of the team to generate the final assets that you will bring together into the finished article. If you have great art skills then you may be able to accomplish this part as well, but be aware that very few companies expect level designers to be building art assets in this day and age - it generally falls to environment artists. Thus it would be better to concentrate on making a fun experience rather than a beautiful looking level.


What Employers are Looking For

So what is the viewer of your level design actually looking for when they play through? This partially depends on what type of map you are creating. Since they are two fairly different skill sets, it's worth considering Single Player and Multiplayer seperately.

Single Player
Single Player portfolio levels may need to show a degree of skills:

• Original, interesting scenarios 
• Cinematic flair
• Technically tricky scripting
• Set-pieces
• Puzzle design
• Drawing the player's eye
• Use of light, shape, etc to guide the player
• Verisimilitude - ensuring that the space makes physical sense
• Understanding of combat spaces
• Flank routes
• Fronts
• Combat "puzzles"
• How to bring waves in
• Crescendo

Multiplayer
Multiplayer levels require a slightly different set of skills:

• Conflict points - areas where teams meet
• Strategy choice - the ability to use different playstyles
• No overpowered positions - every strong position should have a weakness to overcome it
• Flow - different patrol routes, multiple entrances & exits to each area
• Lines of sight - allowing open areas with good cover, danger points and safer areas
• Understanding of risk & reward - offering a powerful weapon in a dangerous to reach location for example
• Theme - showing an interesting theme in terms of geometry (i.e. arena, circuit, etc).

Take your time in developing a portfolio piece, this is going to show an employer how your skills measure up to other designers out there. Those of us who are currently employed in the industry may have a distinct advantage here, since we are probably developing such portfolio pieces all the time. Just remember to always show your best work - quality is far more important than quantity.

How to Create a Design Portfolio - Part I: Documentation

To Document or not to Document


Not all documents are created equal. Different companies have different styles, heck, even different designers within different companies have different styles. There is one thing in common if you are going to include documentation in a Portfolio - keep it brief. The employer only needs one example of something, not the complete game design. A portfolio should only contain your best work - providing too much work of little substance is a mistake many people often make.

There are several forms of documentation that you might want to explore / include in your portfolio - that is not to say you will need all of them. Remember a portfolio should be tailored to your skills and the job you are applying for.

Typically design documentation falls into one of the following categories:

• High Level Outlines
• GDDs
• Mechanics Specifications
• Level Outlines
• Analysis

High Level Outlines

A "High Level" document is one that is used to show the essence of the game to someone unfamiliar with it. In order to do this, it must be as brief, yet deliver as much impact as possible. There are a variety of techniques for doing this from the old fashioned bulletpoint USP list, the walkthrough, the Vision Statement, the X or the "Elevator Pitch". However the most useful is probably the concept of Pillars.

What is this fancy Pillars of which you speak? Pillars are 3 - 4 core elements that define your game. They work as a method of marketing the game, and they also work as a method of informing the design of your game. If a feature doesn't fall within the core pillars, then it is effectively superfluous.

For example, the core Pillars of Enslaved were:

• Spectacular Cinematic Action
• The relationship between Trip and Monkey
• Dramatic Storytelling

These have a dual purpose, you can explain to someone quickly what your game is about, and you can inform your design through each of these attributes.

Once you have your pillars you can begin to elaborate on how these will be displayed in game. For example, in the case of Spectacular Cinematic Action, we wanted to show extremely death-defying set-pieces - like climbing up a collapsing crane 100ft off the ground. For the relationship between the two lead characters we wanted this to be reflected in gameplay, as well as in story - so Monkey helps Trip through specific gameplay actions, and Trip has abilities that help Monkey - we needed a symbiotic relationship between them that the player was engaged with. In terms of dramatic storytelling, this not only informed the script, but also how the worlds were built - we wanted to tell a story with the environment itself.

A one page outline that explains the core principles of the game is a very useful thing to show, as it gives evidence that you can work at the high-level vision point. However, as a designer, you also need to prove you can make ideas work. That's where more detailed documentation comes in.

GDDs

This is where it is all too tempting to start creating a huge Game Design Document to show just how well you can write / design in massively verbose detail. Here's a tip for you. No-one reads these documents but you, not on any project you work on, and most certainly not by a prospective employer looking at a candidate (unless they are incredibly masochistic).

So how should you do a GDD? Well there are many schools of thought on this, but after several years experience writing huge tomes, and attempting smaller notes version, I have come to the conclusion that small, visual design documents are by far the best method of communicating the vision for a game.

Certainly the GDD for Enslaved was almost all done via diagrams. In order to do this we used Visio rather than Word, and found it much easier to create flow charts, stickmen diagrams, etc to express the basic mechanics of the game. It worked very well - publishers were really impressed with the way we created this document and responded warmly.

So my advice - create a visual design document for a small game - don't try for anything epic - just show a few basic mechanics and how you envisage them to work. Keep it light on implementation details, really GDDs are a selling tool - a method to sell your idea to the team and to the publisher. Separate documents should be used to write an actual specification for how a mechanic will work.

Mechanics Specifications

Now we are getting to the more technical aspects of design. It is worth noting at this point that a lot of companies don't expect designers to go to this kind of depth - often it will fall on the heads of programmers to devise the actual method that a mechanic will be implemented. That doesn't mean you shouldn't learn the skill of writing a mechanics specification, as it will demonstrate your ability to think technically and will help you from having the wool pulled over your eyes.

Technical specifications like this are going to go through many, many rewrites and require constant updating, so their natural format tends to be a wiki page. You're unlikely to supply a whole wiki with your design portfolio, but bear in mind the style in which a wiki is written - with questions being asked, and responses rolled into the design. 

Okay. So writing a technical spec. What do we need to include?

Synopsis

What are we trying to achieve? Summarize this at the beginning - give examples that indicate how a mechanic might behave. It you have reference picture or videos then link to them.

Breakdown

Use bullet points to breakdown the mechanic into its constituent parts. Show cause and effect - doing this, will lead to that, etc.Use diagrams wherever possible - a picture tells a thousand words.

Flowcharts

If we have a state machine, or a particular flow through a mechanic, then a flowchart is a great way to describe simply how it will work. Flowcharts are particularly useful when expressing AI states - detailing how a character will behave.

Balancing Parameters

What parameters should be exposed to the designers so they can tweak said mechanic - i.e. aim angle for a melee lock-on system, or fire rate for a particular weapon. You should also detail what type of parameter it should be (int, float, bool, string, object, etc), as well as a potential default value or capped range.

Required Assets

Detail exactly what elements are required to make the mechanic work - what props are needed, animations, sound effects, visual effects, voice over lines, etc.

Risk vs Desirability

A good think in terms of production is to think about how essential a mechanic actually is to the game, and how much it will cost to build it. This could be reflected by two numbers - a high desirability vs low cost is a no-brainer, but when weighing up which mechanics to cut - having a high cost mechanic, it is sensible to know how important it is to the game.

Level Outlines

A level outline is a brief description and layout for a level that details the major events that will occur along the way.

I've approached this a number of ways in the past. Originally I would have done a 2D layout with bulletpoints detailing what happens where, but these can be very flat.

The most successful outlines I've done have been using a very quick 3D tool known as Sketchup. I cannot recommend using this enough, as it can help in two ways:

• Quick visualization of the level layout in three dimensions
• Can provide an interactive fly-through of the level

Key to using this tool is to not act like you are actually building the level. You are merely building a sketch of the level to communicate ideas to the team.

Creating an interactive fly-though is also interesting, as elements can also be marked out. By creating different tabs you can fly through the level in sequence showing what happens where. However, I wouldn't use it as the sole method of showing the level to your team, as not everyone will have Sketchup installed. Instead a supporting document should also be created using screenshots at various points, which are then annotated with the player path and the major events that occur. I tend to call these documents Blueprints, to reflect the architectural nature of them.

Analysis

Analysis of your own game, and other games in your field, should be something that a designer engages in often. You won't stay ahead of the game, think of new ideas, or more importantly, learn from others mistakes if you don't look at what others are doing.

We are going to take a further look at different types of analysis in later blog posts, so for now I shall just say get playing other games with an analytical eye. We'll revisit this topic later.

Hope this blog post has been of some use. If there is anything anyone wants me to elaborate on, then feel free to ask further questions.

How to Create a Design Portfolio - Introduction

The Design Portfolio

Believe it or not, the design portfolio is actually a very rare thing. It is not often that I have seen any designers turn up to an interview with a collection of examples of their work. Usually designers are judged on the merit of their performance in an interview, or the results of a company's design test. Those designers that have included some materials with their submissions are often rather flaky or somewhat misguided. Honestly, your potential interviewer hasn't got time to sit through and read a 200 page design document.

But you can guarantee that an artist is judged on the merits of their portfolio, an animator on the quality of their reel, and programmers are often asked to prove their skills with some kind of tech demo. Surely there is a way we can provide employers with a portfolio to show design skills?

That's what this series of design blogs I am about to embark on will explore, in order to do so I will examine several potential aspects of a portfolio:

• Part I - Documentation
• Part II - Level Design
• Part III - Game Mechanics
• Part IV - Game Balance & Playtesting
• Part V - Critical Analysis

Not all of these elements will be necessary for a design portfolio - and indeed some designers may not even find sections particularly relevant, but hopefully they will provide insight into what potential employers are looking for in a designer and what will help you stand out from the crowd.

LA Noire - Why The Bodies Look Wrong

So Brendan McNamara has commented on what a lot of people have noticed about the dissonance between facial animation and body animation in LA Noire:
McNamara: why you thought LA Noire's characters were "dead from the neck down"

"That's because we had all this animation in the neck and all this animation in the face, but the clothes don't move. Once you get to the level that people can actually see that level of realism, then people expect to see clothes moving and the rest of the body moving in a way we can't replicate in video games."

I'm afraid I don't buy this at all. The problems stem from the way the performance is captured, and the fact two different techniques are being used to do this. Behind the Scenes of LA Noire

1. Body Capture
The body is captured in the traditional manner with actors working together in the studio. This is a proven technique, and is used by most AAA studios. There are different ways to get the facial information - Naughty Dog records only body performance, then hand animates the faces (using videos for reference). This creates a very stylized animation for the faces - not necessarily realistic. Compare this to Avatar, Heavenly Sword or TinTin, where facial performance and body performance are captured using the same technique - small dots that are tracked by the cameras. With the right density of information, a good solver and a decent facial rig, good results can be generated - but at this resolution there is the very real danger of the Uncanny Valley - the slightest error being magnified and ruining the whole effect (like the dead eyes of Polar Express).

2. Facial Capture
This is the unique and impressive tech part of LA Noire. The facial capture uses 3D scanning of the actual face, which is then mapped onto the character's face. In order to do this, the actor has to sit very still on a chair while a number of cameras are targeted at their face.

• This results in a very high resolution capture, but has several significant problems. 
• The actor must remain facing a certain direction, they cannot turn their head. 
• There is only one of these rigs at any one time, so actor's performances are captured in isolation. 
• They are required to act in a sitting position only. 

You can instantly see that this is going to have an impact on their performance. They cannot move around much, and they have no-one to reflect off.

3. Combining
This is where LA Noire falls down - every performance is effectively two performances. The body and face are combined, and this is why there is a dissonance.

It is very difficult to get ADR (Automated Dialog Replacement) to match when re-recording voice work (hence why it is often obvious, or is done when the character is not facing the camera). Effectively the entire performance is ADR'd across the whole game and this is why they don't match a lot of the time - humans are very good at picking up on human movements, so can instantly spot this difference.

No amount of clever work on the clothing will fix this issue - for this technology to really work, they need to be able to capture the whole performance at once.

Design Methodologies

What is game design? It's a question that gets asked a lot, and the answer is generally completely different depending on who you ask.

The reason for this lack of shared response is the different methodologies present at different studios, and even within different designers at the same studio. What is right and wrong? To be truthful, no one method is the "correct" method, but there are definitely elements of each style that can be tied together to make a more rounded design approach.

Schools of Thought
Firstly lets consider the main thought process of how a game should be structured - generally there are two schools of thought in this regard:

• Scripted Design - tightly controlled, generally linear experiences where set-pieces are constructed to the player to engage with. This can be seen best in games like Half-Life and Uncharted.
  
  
  + Produces unique scenarios
  + Tends to be very narrative driven
  - Costly to develop
  - Can lead to limited player freedom
• Systemic Design - a set of building blocks are designed and then layered together to form a large potential outcomes. This is demonstrated best in games like Grand Theft Auto and Deus Ex.
  
  
  + Creates emergent play
  + Offers a lot of player choice
  - Creates emergent problems!
  - Can lead to a sense of repetition

Each of these schools of thought has their champions and detractors. Some despise the linearity imposed by scripted methodology, others enjoy the thrill of the rollercoaster ride it provides. However, great games are able to combine elements of both - so it might be a fairly scripted experience, but it offers lots of choice within each scenario for example.

Design Techniques

The task of actually creating levels and mechanics for a game can be approached from a number of ways. Again, there is no "right" or "wrong" way to do this, but different methodologies have distinct advantages, and conversely their own disadvantages.

Paper Design - GDD
The act of documenting a game mechanic or level layout is a very traditional approach. It shares the vision for the game to the team in a presentable fashion. A good game design document can help cement this vision and encourage communication throughout the team - it can avoid confusion and act as a reference point.

However, paper design is very much the Grand Old method of game design, and can be seen as something of a dinosaur by many. Writing documentation isn't glamorous, and is fraught with potential issues. If the document isn't continually kept up to date with the latest changes, then people lose trust in it.

+ Specifically states the intent of a mechanic of level design

+ Tangible evidence of a particular idea
+ Great for communicating the vision to the publisher

- Time consuming to keep up to date

- Can lead to inflexibility: "that's not how it is in the GDD!"

- Doesn't prove that gameplay or level design is actually fun to play

Documents are definitely useful, but should be kept should concise and up to date. In 3rd party studios, good documentation is essential to keep the publisher up to speed. Beware - they should never become gospel.

Formal Structured Approach

Several designers (such as Doug Church) are pushing for a more rule based approach to game design - approaching it as a scientific method. The belief is that a good set of rules can be defined rules to create a game experience. There is some mileage in the pursuit of this ideal, as it does create a lot of desire to analyze approaches to design and look at what works and what doesn't. On the counter side, design is part science, but also part art. Art often relies on breaking the rules to find something more interesting. It's a fine line to tread, and there is a danger that the formal approach might "suck out the soul" of game design.

+ Highly analytical approach to games

+ Creates a set of rules that can be clearly states

- Can be very rigid

- Ignores the artistic process that relies on breaking the rules
- Might create identikit games without anything really original

I'm not sure how much mileage there is in following a strict set of rules, however, I do believe the pursuit of analysis is a great goal to have. If this method produces a set of guidelines for what tends to work well, then I believe it will have a useful place. It shouldn't be used to quash creativity however.


Iterative Design
Iterative design is the process of quickly prototyping an idea, then refining it again and again to produce a final product. This process forgoes any formality to concentrate solely on one element at a time and work to make that element fun. There is a danger that this process the elements won't fit together as a whole, so someone should always be considering the big picture. There is also the danger of overrunning time.

+ Pursues elements that are fun

+ Refines and polishes elements

- Can become endless

- Can result in chaos if not kept in check

- Can limit the amount that is done

- Must be careful to consider each parts place in the whole

The iterative process needs to be carefully managed. It needs to have enough room to breathe, but it needs someone disciplined enough to say when enough is enough.

Rational Game Design

Rational design breaks design down into a series of building blocks. These building blocks are then combined to create more interesting scenarios / combinations of mechanics - a bit like a giant Lego set.

The first step of rational design is to break the game into its core mechanics. Then you can start to work out how they interact with each other. Rational design fits very well into the Systemic Design school of thought.

+ Creates emergent scenarios

+ Becomes quick and easy to build new scenarios

- Can be difficult to test

- Can lead to repetition or lack of anything spectacular

Rational design is useful for creating stock scenarios for a game, but in order to make something unique, you may have to use elements that are unique to a particular scenario.

Empirical Method

The empirical method is the use of observation to inform design decisions. It can actually start before the game has even begun through the use of focus groups.

Once there is a game to actually play, then the process of usability and playtesting can begin. This is the act of bringing in external people to play the game, observe them, record their actions and interview them on their reactions to the game. Data can also be gathered using instrumentation to output exactly what players are doing where.

+ Invaluable information about where players are getting stuck
+ Information that can be used to improve the game significantly

- "Evidence" can be manipulated and used politically

- Focus testing can result in bland experiences if over-relied upon

Whilst I have my reservations about the use of focus testing, the art of usability and playtesting is absolutely invaluable - in fact I firmly believe that high quality games cannot be made without it these days. The only thing to be wary of is the misuse or bad interpretation of data. It is important to approach the data processing without any kind of agenda, otherwise it is easy to cherry pick information that backs said agenda and obscure you from the actual truth.

The Ultimate Method?
The ultimate method is to combine as many of these methodologies such that you get the advantages with each and hopefully avoid the disadvantages.

Document what you can, but do it in a concise way that allows quick iteration. Perform iteration, but make sure that you have an end goal and timescale in mind. Come up with a set of rules for your game, but don't let them blind you to something awesome. Create building blocks, but remember that unique elements will make your game stand out from the crowd. Playtest and expose your ideas to focus groups, but don't be swayed by popular opinion if it isn't right for the game.

Ultimately each studio has a house style, and each individual designer will have their own approach that may (or sometimes may not) fit with that. Just be aware that other methodologies may have some use to you that you might not at first be able to see. Don't be close minded - always be prepared to learn something from others.

Combine elements of all design approaches to gain all of the advantages