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.
No comments:
Post a Comment