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

Social Gaming - Making it Better

I'm not a fan of the current crop of social games, because they just smack of lazy / copycat game design. Most off all however, they aren't taking advantage of their single biggest USP - the social network. In fact, some of these games are actually on the fringes of being immoral - after reading an article in Edge about the comparison of these games to drugs, not sure I agree 100% with the conclusion, but certainly they are designed to use behavioral conditioning and peer pressure.

So rather than act like a virus and attempt to spread as far and wide as possible, I got to thinking about how you could actually make a game that uses the social network itself, rather than abuse the network as it seems to do currently.

Before we delve into the potential for connectivity, we must understand the platform itself. Whilst a standard multiplayer experience with everyone playing against each other at the same time could be possible on Facebook, the drop in, drop out nature of the platform makes such games difficult to organize. This is why turn based games, or co-operative suggestion works better. So with this in mind, we can think about prior examples of where this has worked really well.

Asymmetric Multiplayer
One intriguing type of multiplayer that could work really well with large groups of people, is an asymmetric design - that is where one or more players have different goals to the others.

For example - imagine a spy game, where the other players had to determine who the spy was. This could easily be envisioned as a Who-Dunnit mystery like the board game Clue.

Then there's the Games Master paradigm, where one of the players controls the experience for the other players. This can fit very neatly into the social structure - certainly there are probably plenty of D&D styles of game on Facebook already, but it wouldn't be too hard to tailor this to a more mainstream audience.

Augmented Reality Games
Another great aspect of the platform is its embedded nature in our lives. Now so many users have Facebook, etc on their phones, they tend to use these devices to check in to various real world locations. What if we took advantage of that with our games?

Take for example Geocaching. Here people use the GPS to find real-world caches of treasure. We could easily make these virtual caches, and set riddles, puzzles, etc for people to solve as they check in to various places - this could easily tie into discount promotions at stores to allow a possible source of revenue.

Social Engineering
What if we use the social network literally - what if we had a political game where you had to lobby people and get them to vote for you? Some kind of virtual government. You could even tie this into a Sim City style game, so we could create a series of interlinked games that are tailored to the respective tastes of different people - one person could be the urban planner, whilst their citizens play their own political games within the city, which in turn provides challenges for the city planner.

How to Get a Job in Game Design (Revisited)

So a fair while ago I made a post about how to get a job in game design. After reading Mat's little blog post on Getting Into Games, I thought I'd follow his ideas up by being more specific about what you need to be a designer.

The Essentials

There are several requirements for designers that are non-negotiable. Without these skills you can pretty much forget about even bothering to become a designer, as you're not going to be able to do your job effectively.

1. Communication
This is the big one. Forget about having tonnes of ideas - ideas are worth nothing unless you can communicate them to the world. Design is in its purest form communication of an idea and nothing else.

There are two groups you need to converse with - your team and your audience.

Conversing with your team can take a number of forms - not every designer is born equal in communication skills. Some are verbally adept. Others are better at communicating through the written form. Others may have visual design skills that communicate best through images. Whatever the form of communication - there must be at least one clear method that demonstrates this communication skill. If you are bad at verbal forms of communication then it can make interviews pretty tough. My suggestion in this case is to be honest - tell your potential employers that your communication skills are better served through other methods, and provide examples.

Conversing with your audience is a little different. A good designer doesn't just design games for themselves. They must understand the commercial realities of the market. They must be ready to engage in user testing - gaining data from their audience and interpreting it in a way that will benefit the game. Good games are very, very rarely designed in a vacuum - that is to say that everyone needs feedback and critique.

2. A Lack of Preciousness
This may at first seem odd. Shouldn't I champion my ideas? Should I not defend them? Simple answer - no.

A good designer will be willing to collaborate. They are willing to listen to everyone's ideas (no matter how daft they may sometimes seem). They act more as an arbiter of ideas, filtering out elements that work from those that don't.

In regards to their own work, they must be open to critique and be ready to change and improve upon what they have done. If you feel really strongly that something is the right direction and it is being challenged, the best possible advice I can give is pick and choose your battles. If you defend every single idea you have, there is no room for maneuver. If you carefully consider which ideas are worth holding onto - then you are compromising - and compromise is an essential part of collaboration - it shouldn't ever be seen as "giving in".

3. Passion for Games
There's no doubt that without a passion for games, then there's no point in becoming a designer - you simply won't enjoy the job.

This passion should extend beyond a small subset of games, otherwise you end up becoming too narrow minded. There is potential for the spark of an idea in all genres - new mechanics, ideas for scenarios, enemy types, etc.

But don't play games at the exclusion of all other information. This leads neatly into the next requirement...

4. Passion for Information
A good design has a thirst for knowledge that is almost impossible to quell. They should want to learn about almost every subject, since there is something of use for any designer.

Doing research is an essential part of developing a good game - and learning about history, geography, math, etc will ensure that the designer is rounded enough to think about things from many different angles. You can always tell when the design of a game has had a poor background in research - even the smallest detail being wrong can lead to obvious holes for your audience.

So get reading - the internet is the most incredible invention for human knowledge in our entire history. Use it, but remember that not everything you read is correct ;)


The Advantageous "Qualifications"


So the essentials seem a bit intangible? Yes - that's because the essence of a designer is fairly intangible. I've worked with designers from all types of backgrounds:

• Computer Science graduates (of which I am one)
• Modders (of which I also am one)
• History graduates
• English graduates
• Physics / Philosophy graduates
• Engineering graduates
• Game Design graduates

All of these are perfectly valid for designers, but guess which ones have the toughest time getting game design jobs? It might surprise you, or might not, but Game Design graduates are less likely to get the job than the others. There is a large amount of disdain for Game Design courses within the industry, except from a select few colleges / universities (such as Carnegie Mellon or University of Abertay). So what do we look for in designers?

1. Academic Qualifications

Like it or not, Acadameic qualifications are extremely useful (but not essential I might add). They show employers that you have the ability to work at a certain level. They show you have applied yourself to a subject and potentially mastered it. They show that you have a thirst for knowledge. As mentioned above though - the type of qualification is important. Don't do a "bums on seat" degree like Media Studies - and if you are going to do Game Design, ensure that you do it to build you portfolio, because the qualification isn't going to get your foot in the door as courses currently stand.

I'd actually suggest doing something more like Engineering, Computer Science, Product Design or Architecture, as these teach you skills that you are going to be learning on a daily basis, but aren't as narrowly focused as a Games Design degree (also if you don't get in the industry you have a fallback plan, because a Game Design degree will get you laughed out of most "serious" jobs).

2. Modding

This is the single best way of getting in the industry - since it proves several things - a passion for games, an aptitude for creating things and the self motivation to do your own work. The major benefit of this is it also builds your portfolio for when you decide to apply for a job in the industry. Just remember when applying for jobs, that the way modders work and the way professionals work is very different.

If you want to start modding, pick a game you enjoy and go from there. These days its a lot easier than when I started back in 1998 - since you can pick up a copy of UDK or Unity and create your own games with relative ease.

3. Extra Curricular Interests

Don't just play / make games - this makes Jack a dull boy. You need to be rounded in your interests - as mentioned above - you need to have a thirst for knowledge.

Play sports, learn an instrument, read books, watch movies, go hang-gliding or cook food. Do something that ignites your passion beyond just gaming. This is more important to an employer than you can possibly imagine.

Guiding the Player

How do you guide the player without holding their hand too much?

It's a difficult problem, made all the more tricky by the different capabilities or tastes of players. If the hand of the designer is seen too much it becomes too easy - the player feels led through the game. Too hard and the player gets frustrated and ultimately turns to Gamefaqs or a strategy guide to seek out the answer to their problem.

Navigation
Navigation is the key area of where guiding the player comes into play. The way you plan navigation for the player is determined in a large part by the type of game structure you are using - is it a linear adventure, or is it more of an open world? Either approach relies on one thing - a clear goal. If you muddy the goal at any point, then the player starts to lose track of what they are doing, and in turn finds it harder to navigate the world.

With a clear goal set, it then becomes a case of how you signpost that goal. This is where things start to differ.When you are creating a linear experience things are fairly easy - there is but one path for the player to travel, so it becomes a case of clearly showing the exit point for any one area. There's a lot more depth to this than initially meets the eye however, and requires careful lighting, shapes, and flow through a space to ensure the exit is recognized by the player. However, the problem with linear design is how to make it an interesting space that doesn't feel entirely linear. This is where the concept of wide-linear comes into play - creating pockets of free-form gameplay to allow choice, broken up with pinch points and diodes to push the player forward. Providing a single landmark that can be recognized through the area can also help the player to align themselves in the world and understand how the current space fits within the whole level.

Open world games are a lot trickier. Valves and pinch points can't be used in the same way, and a lot of the tricks used to point players in a certain direction won't work from every angle. The key thing here is to ensure that the world has plenty of landmarks to enable the player to learn the space quickly. They can use these landmarks to understand how the space fits together and where one chunk is relative to another. There's a fascinating book that delves into the way that humans organize spaces such as cities in their mind, which can provide great insight for open world game developers -Image of the City. Open world games often use waypoint markers as a device to guide the player. This can occasionally seem like a crutch - particularly if the fiction of the worlds doesn't really support the idea.

Puzzles
Another area where players constantly butt up against the potential to get stuck is in puzzles. This can be a very difficult tight-rope to walk due to the difference in players' cognitive abilities. People are good at different things - some like math, others are better at solving spacial problems.

The issue becomes one of either holding the player's hand too much and giving them the answer, or making it so hard that they just go and look on gamefaqs for the answer.

There is no right answer here, but the best approach is to provide enough clues for the player to make some simple deductions. Then make the next clues a little more obscure, but provide a way to solve them from the information around them. Don't show them the answer - just provide a little more information over time. The secret here is also a lot of playtesting - but don't assume that your audience won't get it - you'd be surprised how many people actually find their way through as long as enough information is provided - show them that they have that information and it should be enough for them to figure it out and get that sense of reward.

Mechanics

Forms of guidance can also exist at a lower level - within the core mechanics of the game itself.

One example I can use from personal experience to highlight this issue, is the ledge behavior we employed in Enslaved. The idea was to stop the player from experiencing frustrating falls to death, but the decision really divided the audience. A lot of players loved it - it removed that die / retry issue altogether for tricky traversal. A similar number of players hated it - it felt too much like they were being prevented from having the active choice - there was no challenge.

So how do you solve this? The key is to either provide ensure that there is always the potential for danger, a feeling of being challenged in all mechanics. Mechanics without challenge or skill tend to fall flat, as they feel like going through the motions.