Oh - my blog! The lame thing about crunch is forgetting that anything other than the work right in front of you exists.Well, unless you've been living under a rock, you might have heard about a little game called The Last of Us. That has been my life for the last 9 months in particular, but in a less life altering state for the 2 years prior to that also.
We finally downed tools at the beginning of June and literally collapsed from the weight on our shoulders. There was little else to do other than sleep for several days straight and try and remember the wife and child that I used to know before work became all consuming (I have to thank my family for the huge amount of support and patience they showed during these times). Then we wait. Whilst those manufacturing plants whirred into gear far over the other side of the world in China, we all sat in our respective catatonic states, waiting for the first reviews to come trickling in - living in terrible fear that the painful crunch of the last few months was a monumental waste of time.
And then they came, 10 after 10 after 10. Even Edge - one of my life goals was to get an Edge 10, and there it was - and the most proud feeling I've had since my son was born. A few other scores dipped into the "really?" territory, but I have to respect other peoples' opinions, not everyone is going to like it after all. Even now there's a few scores still trickling in, still making me smile.
But now I feel a bit empty.
There's a nagging feeling.
We've got to do this again with the next game, except now, we have to make it even better.
Uh oh...
Life of a Design Monkey
A look at life in the world of games design. From everday annoyancies, interesting concepts and the things that make design fun.
Friday 19 July 2013
Wednesday 21 March 2012
The Kickstarter Revolution
It's been an interesting couple of months in the games industry. Besides UK retailer GAME going down poop creek and UK government finally giving the industry tax relief (see that swinging Stable door guys?), the really big piece of news that everyone is talking about is the possible revolution that Kickstarter is bringing to the industry.
Unless you've been living under a rock you'll have heard about Double Fine's marginal success at getting funding - and by marginal I mean 834% of what they originally asked for (p.s. I punted $15 on it, thought it was worth a stab!). So that's a cool $3,336,371, and that's not including some $110,000 from other premium backers. Not bad, not bad at all.
But surely that's just because it's Tim Schafer (and Ron Gilbert) right? A one off. Pure nostalgia? Well - maybe, but Wasteland 2 has also got backing. So maybe it's just people with industry clout and the sequel to a major franchise? It seems not - just look at projects like The Banner Saga, and any number of iOS projects on there. In fact, according to Kickstarter themselves, something like 45% of games are receiving funding.
That's some exciting future prospects right there! An industry that can fund itself!? No more need for publishers?!
Well that's when things start getting a bit tricky. There's a couple of big, unanswered questions about these projects, with some potentially disastrous consequences.
WHAT WORKS?
Some pretty ambitious projects are being touted in the wake of double fine. Take for example Hardcore Tactical Shooter (catchy name btw). They're asking for only $200,000 to make a full fps game. How? Well they'll crowd source it of course!
So they're not only asking for money, but also help making it? Aren't your funders giving you money for you to make it?
It seems so far that only certain types of project are realistically going to get enough traction, and be able to ask a certain price. Will we ever manage to get to a situation where the next GTA or CoD could be crowd-sourced? Highly unlikely. Publishers aren't going anywhere quite yet.
TAX
Oh boy. The Tax man. Let's be honest, the IRS is gonna want a slice of this pie. How the hell are they going to do that though? The tax implications are extremely complex - and potentially even more complex depending on the type of reward that is being offered through the funding. Are these classed as retail sales? Does every sale of the game to a funder therefore need to be taxed according to the state / federal tax laws? And which state laws do you use? The funder's or the developer's?
I'm sure most of the bigger studios are likely to have access to decent legal advice, but I fear some of the smaller concerns may end up getting a rather large, and rather unexpected tax liability.
One thing you can be sure of, the larger the sums of money exchanging via crowdsourcing, the more interest government is going to show, and the larger the slice of pie they are likely to feel entitled to.
FAILURE
This for me is the biggest question. What happens when a team fails? Having your game funded by fans means you are going to have to deliver a product that they are happy with, it's not just good enough to get any old shit out there. They are putting faith in the developer and will be mighty pissed if the results aren't to their liking.
But worse than this, what happens if the project never comes together? Not only will the fans be disappointed in the lack of a game, but they will have lost money - there's nothing to fuel anyone's ire than being out of pocket with nothing to show for it. And once these fans have been burnt, are they likely to shell out for any future projects?
Only time will tell I guess.
FRAUD
So there's now a lot of money available to fund people. Where there's money there's greed, and where there's greed there's criminality.
How long before fraudulent projects appear, which are little more than scams to alleviate us of our money? I sure hope Kickstarter has got some good safety measures in place to prevent such issues.
CONCLUSION
Well it's all very exciting, and bodes well for many indie teams, finally there is a method of securing finance that doesn't require selling your soul. Finally there is a route to market for games that won't sell 10 million copies, but will have a small and loyal fan base and produce enough profit to keep the developers in pizza and beer.
Let's not get ahead of ourselves though, this may be a new business model, but it's unlikely to be the silver bullet.
Links:
Double Fine Adventure
http://www.kickstarter.com/projects/66710809/double-fine-adventure?ref=live
Wasteland 2
http://www.kickstarter.com/projects/inxile/wasteland-2?ref=live
The Banner Saga
http://www.kickstarter.com/projects/stoic/the-banner-saga?ref=live
Tactical Shooter
http://www.kickstarter.com/projects/355932838/crowdsourced-hardcore-tactical-shooter?ref=live
Unless you've been living under a rock you'll have heard about Double Fine's marginal success at getting funding - and by marginal I mean 834% of what they originally asked for (p.s. I punted $15 on it, thought it was worth a stab!). So that's a cool $3,336,371, and that's not including some $110,000 from other premium backers. Not bad, not bad at all.
But surely that's just because it's Tim Schafer (and Ron Gilbert) right? A one off. Pure nostalgia? Well - maybe, but Wasteland 2 has also got backing. So maybe it's just people with industry clout and the sequel to a major franchise? It seems not - just look at projects like The Banner Saga, and any number of iOS projects on there. In fact, according to Kickstarter themselves, something like 45% of games are receiving funding.
That's some exciting future prospects right there! An industry that can fund itself!? No more need for publishers?!
Well that's when things start getting a bit tricky. There's a couple of big, unanswered questions about these projects, with some potentially disastrous consequences.
WHAT WORKS?
Some pretty ambitious projects are being touted in the wake of double fine. Take for example Hardcore Tactical Shooter (catchy name btw). They're asking for only $200,000 to make a full fps game. How? Well they'll crowd source it of course!
So they're not only asking for money, but also help making it? Aren't your funders giving you money for you to make it?
It seems so far that only certain types of project are realistically going to get enough traction, and be able to ask a certain price. Will we ever manage to get to a situation where the next GTA or CoD could be crowd-sourced? Highly unlikely. Publishers aren't going anywhere quite yet.
TAX
Oh boy. The Tax man. Let's be honest, the IRS is gonna want a slice of this pie. How the hell are they going to do that though? The tax implications are extremely complex - and potentially even more complex depending on the type of reward that is being offered through the funding. Are these classed as retail sales? Does every sale of the game to a funder therefore need to be taxed according to the state / federal tax laws? And which state laws do you use? The funder's or the developer's?
I'm sure most of the bigger studios are likely to have access to decent legal advice, but I fear some of the smaller concerns may end up getting a rather large, and rather unexpected tax liability.
One thing you can be sure of, the larger the sums of money exchanging via crowdsourcing, the more interest government is going to show, and the larger the slice of pie they are likely to feel entitled to.
FAILURE
This for me is the biggest question. What happens when a team fails? Having your game funded by fans means you are going to have to deliver a product that they are happy with, it's not just good enough to get any old shit out there. They are putting faith in the developer and will be mighty pissed if the results aren't to their liking.
But worse than this, what happens if the project never comes together? Not only will the fans be disappointed in the lack of a game, but they will have lost money - there's nothing to fuel anyone's ire than being out of pocket with nothing to show for it. And once these fans have been burnt, are they likely to shell out for any future projects?
Only time will tell I guess.
FRAUD
So there's now a lot of money available to fund people. Where there's money there's greed, and where there's greed there's criminality.
How long before fraudulent projects appear, which are little more than scams to alleviate us of our money? I sure hope Kickstarter has got some good safety measures in place to prevent such issues.
CONCLUSION
Well it's all very exciting, and bodes well for many indie teams, finally there is a method of securing finance that doesn't require selling your soul. Finally there is a route to market for games that won't sell 10 million copies, but will have a small and loyal fan base and produce enough profit to keep the developers in pizza and beer.
Let's not get ahead of ourselves though, this may be a new business model, but it's unlikely to be the silver bullet.
Links:
Double Fine Adventure
http://www.kickstarter.com/projects/66710809/double-fine-adventure?ref=live
Wasteland 2
http://www.kickstarter.com/projects/inxile/wasteland-2?ref=live
The Banner Saga
http://www.kickstarter.com/projects/stoic/the-banner-saga?ref=live
Tactical Shooter
http://www.kickstarter.com/projects/355932838/crowdsourced-hardcore-tactical-shooter?ref=live
Monday 12 December 2011
How to Create a Design Portfolio - Part V: Critical Analysis
A major part of being a designer is being able to look at other games on the market and analyze them in depth. This also becomes a major downside of the job, as it becomes difficult to play a game without casting a critical eye, or trying to work out precisely how something is done. Just remember, that becoming a designer will take away quite a lot of the magic of videogames - be prepared for that!
So - how do you approach analysis of a game?
Narrative
A lot of games tend to have a narrative these days, so as a designer wanting to work on these types of games, an understanding of story is a must. Games still have a long way to go in terms of storytelling - really we are still trying to find our feet, but there are some interesting themes emerging among the wealth of space marine / military fetishism. Bioshock for example uses the narrative to question the nature of player agency - an excellent twist that really made sense of the earlier parts of the game.
There are plenty of resources for good storytelling on the web, it's worth researching a lot of these to get an idea of how a good story is told. Much of it applies to videogames, but there are elements that videogames struggle with - there are also elements that they can do better than other forms of media (exploring the world thoroughly for example).
But there is more to narrative in games than the plot itself. Stories can be told via interactions - characters interacting with each other, or interactions with the world. Environments can also tell a huge amount of story - from small vignettes of one life in this world, to vast changes that may have been inflicted on an entire city, or even planet. Half-Life 2 has a lot of small storytelling in its environment, from newspaper clippings that explain the backstory, to small snippets of people struggling to survive in the world. Some of these small stories can be incredibly moving.
Mechanics Analysis
Mechanics are important to any game, so learning their intricacies and being able to critique them well is an essential skill for a designer.
Look at how intuitive they are, how well they fit with the game, their fluidity, their presentation, how well they are balanced within the system and how they make you feel as a gamer.
Employers are going to be looking at how well you can communicate ideas, so choosing a suitable mechanic and breaking it down in detail will give them a lot of that information. It would also be beneficial to show how you might improve a game mechanic - what sorts of improvements will have a large bang for the buck? Ensure that your improvements aren't going to negatively impact on other aspects of the game.
Level Design Analysis
Good level design is hard to do, but there are plenty of examples of superb level design out there. There are also some examples of poorly thought-out layout that people get lost in, or frustrated. Being able to determine what elements of these contribute to the ease or difficulty of navigation is an important skill.
Levels should also be believable - not necessarily realistic, but they must make sense for the world. I like to breakdown level design by the following attributes:
So when you are analysing a space you want to try and look at it in the terms above: is this space easy to navigate? does the combat space offer a lot of options? what is this scenario doing in terms of gameplay? does the story fit with the gameplay experience?
Balance Analysis
When looking at balance, you are really trying to evaluate how individual elements fit within the whole. You are looking to see if a game has achieved a state of flow through a carefully balanced difficulty curve. You are also looking to see if a game has exploits or some element that breaks the balancing of the game.
Look to see if the worth of items is set correctly, or whether the psychology of the balance matches the feeling the game is trying to portray - i.e. are you starved of ammo in a survival horror game?
Look for a good sense of multiple strategies and potential tactics. Are there lots potential actions - is there any depth in particular mechanics?
What market is the game catering for? Sometimes a game may be particularly dumbed down in your estimation, but are you the intended audience, or have they added a difficulty level that does cater for you?
Overall Experience
A game is often more than the sum of its parts. Each of these parts contributes to the overall experience, as a designer being able to talk about this overall experience is also very important. Whilst there may be issues with individual aspects of a game, it may be able to overcome them - this is a chance for you to describe why something has this elevated status - or perhaps why the overall experience doesn't come together for some reason.
Conclusion
Casting an objective eye over games is an important skill. Looking at great games can give you a real insight as to great techniques to hook the player, but "bad" games can also be important to look at, not only to see what problems they have, but also to occasionally find the nugget of an idea that can be refined and improved upon. As a designer, playing games is research, it may make you lose some of the magic of playing games, but it also gives you a great excuse to play more of them. So go ahead and play - you might learn something!
So - how do you approach analysis of a game?
Narrative
A lot of games tend to have a narrative these days, so as a designer wanting to work on these types of games, an understanding of story is a must. Games still have a long way to go in terms of storytelling - really we are still trying to find our feet, but there are some interesting themes emerging among the wealth of space marine / military fetishism. Bioshock for example uses the narrative to question the nature of player agency - an excellent twist that really made sense of the earlier parts of the game.
There are plenty of resources for good storytelling on the web, it's worth researching a lot of these to get an idea of how a good story is told. Much of it applies to videogames, but there are elements that videogames struggle with - there are also elements that they can do better than other forms of media (exploring the world thoroughly for example).
But there is more to narrative in games than the plot itself. Stories can be told via interactions - characters interacting with each other, or interactions with the world. Environments can also tell a huge amount of story - from small vignettes of one life in this world, to vast changes that may have been inflicted on an entire city, or even planet. Half-Life 2 has a lot of small storytelling in its environment, from newspaper clippings that explain the backstory, to small snippets of people struggling to survive in the world. Some of these small stories can be incredibly moving.
Mechanics Analysis
Mechanics are important to any game, so learning their intricacies and being able to critique them well is an essential skill for a designer.
Look at how intuitive they are, how well they fit with the game, their fluidity, their presentation, how well they are balanced within the system and how they make you feel as a gamer.
Employers are going to be looking at how well you can communicate ideas, so choosing a suitable mechanic and breaking it down in detail will give them a lot of that information. It would also be beneficial to show how you might improve a game mechanic - what sorts of improvements will have a large bang for the buck? Ensure that your improvements aren't going to negatively impact on other aspects of the game.
Level Design Analysis
Good level design is hard to do, but there are plenty of examples of superb level design out there. There are also some examples of poorly thought-out layout that people get lost in, or frustrated. Being able to determine what elements of these contribute to the ease or difficulty of navigation is an important skill.
Levels should also be believable - not necessarily realistic, but they must make sense for the world. I like to breakdown level design by the following attributes:
- Function - what is this space used for, in terms of physical function (what is this space for in the world), "ludic" function (what this space is used for in gameplay terms) and narrative function (what this space represents in the story).
- Form - the physical shape of a space and the items within it - landmarks, architectural style, how well the space fits the world, etc.
- Flow - the physical flow (organisation of space and movement through it), the "ludic" flow (how the player moves through the space, the pacing of events and goals) and narrative flow (showing the progression of the narrative through the world space.
So when you are analysing a space you want to try and look at it in the terms above: is this space easy to navigate? does the combat space offer a lot of options? what is this scenario doing in terms of gameplay? does the story fit with the gameplay experience?
Balance Analysis
When looking at balance, you are really trying to evaluate how individual elements fit within the whole. You are looking to see if a game has achieved a state of flow through a carefully balanced difficulty curve. You are also looking to see if a game has exploits or some element that breaks the balancing of the game.
Look to see if the worth of items is set correctly, or whether the psychology of the balance matches the feeling the game is trying to portray - i.e. are you starved of ammo in a survival horror game?
Look for a good sense of multiple strategies and potential tactics. Are there lots potential actions - is there any depth in particular mechanics?
What market is the game catering for? Sometimes a game may be particularly dumbed down in your estimation, but are you the intended audience, or have they added a difficulty level that does cater for you?
Overall Experience
A game is often more than the sum of its parts. Each of these parts contributes to the overall experience, as a designer being able to talk about this overall experience is also very important. Whilst there may be issues with individual aspects of a game, it may be able to overcome them - this is a chance for you to describe why something has this elevated status - or perhaps why the overall experience doesn't come together for some reason.
Conclusion
Casting an objective eye over games is an important skill. Looking at great games can give you a real insight as to great techniques to hook the player, but "bad" games can also be important to look at, not only to see what problems they have, but also to occasionally find the nugget of an idea that can be refined and improved upon. As a designer, playing games is research, it may make you lose some of the magic of playing games, but it also gives you a great excuse to play more of them. So go ahead and play - you might learn something!
Monday 5 December 2011
Design Tests - What to Expect
Here's a little piece on design tests I wrote for another blog, but I thought I'd repost it here:
Game Design is in the unfortunate situation of being one of
those intangible disciplines, particularly to outsiders. A typical conversation
with Muggles tends to go along the lines of:
“So
what do you do for a living?”
“I’m a Game Designer.”
“Oh so you make all the art?”
“No”
“Oh so you do the programming?”
“Not quite”
“So you just play games all day then?”
*Sigh*
“I’m a Game Designer.”
“Oh so you make all the art?”
“No”
“Oh so you do the programming?”
“Not quite”
“So you just play games all day then?”
*Sigh*
The biggest problem is that design isn’t a clearly defined
role across all studios – every team is slightly different. Which makes the job
of hiring someone difficult, whilst a candidate might show good promise in
their creative ideas, they may lack the technical understanding required to
make those ideas reality. The other issue is that people’s perception of what a
design portfolio might look like are vastly different, in fact many designers
don’t even have a portfolio.
So how do you determine a good candidate from the heap of
CVs / Resumes that lie before you? Well many studios will set you a design
test. These tests can vary greatly in form depending on the studio, I’ve seen
everything from a simple questionnaire about games and game design, creating a
level layout on paper, to a full-on create a level using a specific editor (a
little excessive in my opinion). Unfortunately
I’m not going to present you with specific tests from companies, as many of
them are time limited, and by getting this information ahead of time you are
gaining a competitive advantage. No, I’m not going to do your homework for you!
However, in most cases there are some common threads that you might find
throughout and there are certain things that employers are looking for.
Creative Thinking
Of course a designer needs to be able to think creatively. A
good design test will give you a fairly limited brief, detailing exactly what
they expect you to show. Designing within constraints is actually a vital part
of design – in fact without constraints design is often a complete mess. So
read the wording of the test carefully – make sure your ideas cover everything
specified in the brief.
However, don’t always be completely limited by the brief. If
there is a slightly crazy idea you have, then feel free to explore it, but also
be prepared to justify it, or flag it as something that might cause issues.
Be original. That’s not to the point of making something
completely innovative, but don’t just copy something you’ve seen in another
game. Believe me, your prospective employers will see through that one in a
second.
Be inspiring. When you’re putting your ideas on paper, then
you really want them to show you at your creative best. Do something
extraordinary. Get yourself noticed.
Mechanics Design
Ability
Often a test will ask you to break down a mechanic or design
a new mechanic from scratch. This is where technical ability starts to show
through. There are several things that your employer could be looking for here:
- Ability to analyze a game
- Ability to reverse engineer an existing mechanic
- Ability to come up with complimentary mechanics or to refine existing ones
- Ability to clearly communicate information with a team
Mechanics tests generally take the form of written documents
(it would be pretty hard to ask you to create a working example). A good rule
of thumb when writing mechanics documents is to use as many diagrams, flow
charts or other visual aids as you can. Also don’t write reams of paragraphs,
use bullet-points to keep information salient.
Level Design Ability
Level Design is often a more elaborate process than a
mechanics design test, as it will generally require you to sketch out a
scenario, often in 3D.
If you are asked to create a 3D mockup, I suggest you use
Sketchup to allow yourself to quickly build the geometry (unless you are
extremely skilled in a more elaborate 3D package). You might be asked to build
something using a specific editor such as Unreal. This can be very time
consuming, so make sure you are ready and willing to undertake such a test if
you are asked to do so. I know that a lot of time consuming tests tend to put
more senior designers off applying to studios, so it tends to be the studios
with more prestige that enforce these kinds of test.
Otherwise, your test is likely to take the form of a
document, complete with sketches to show the flow through the level. Even if
you do a 3D model of your level, I’d suggest also creating an accompanying
document, as it is much easier to express your ideas fully that way. But again,
keep it fairly brief – use bullet-points.
Employers will be looking for a range of skills:
- Ability to create interesting scenarios
- Flow through the level
- Interesting vistas, story moments, etc
- Understanding of space and suitability to mechanics of the game
Time Management
If a studio imposes a time limit on their design test, you
can ensure they are looking for how well you can manage your time – the shorter
this time period, the more this becomes a factor.
My advice in this scenario is to be extremely organized.
Break down your time into chunks of what you need to do to complete the test.
Spend the allotted period doing what you have specified, then don’t overrun
that time. If you get finished early then you can go back over what you have
done and make improvements, but if you run out of time then it is not going to
look great for your final test.
Communication &
Willingness to Collaborate
Generally if you’ve done a good enough job on the test, your
prospective employer will invite you in, or contact you to engage in a dialog
about the test. This is a chance to see how well you can communicate your
ideas, but there is also another agenda at play here. Your employer will also
be looking to see how attached you are to your ideas, and whether you become
precious about your work.
Teams need to collaborate to get the job done, if you are
clinging doggedly to an idea, then that throws warning signs up in their minds.
However, you can also be too agreeable. If you bend on every single decision,
then it might show that you are too willing to change based on external
pressures, or you do not have enough confidence in your own ideas. Pick your
battles in this instance, explain which aspects of the design you really like,
and those that you feel need further attention.
Conclusion
Tests can be pretty brutal, and a lot of established
designers refuse to do them, as they feel that their experience should speak
for itself. I think it depends on the candidate and the studio. With my
experience, I wouldn’t expect to go to a general studio and get a huge week
long test. However, when I applied to Naughty Dog I fully expected to get a fairly
tough one (and did). If you’re new to the industry you really have to prove
yourself, so even the lowliest studio may end up testing you. Really it is up
to you, if you feel the ends justify the means then go for it, but don’t fall
into the trap of doing it half-heartedly – I’ve seen those kind of applicants
before, and they get weeded out in seconds.
If you’ve been sent a test by a studio, good luck. If you
nail the test you’re usually going to get the job (unless you turn up with a
bloodied axe and a terrifying grin of course…)
Monday 28 November 2011
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:
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:
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.
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.
Thursday 17 November 2011
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.
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.
Monday 14 November 2011
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:
Multiplayer
Multiplayer levels require a slightly different set of skills:
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.
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.
Subscribe to:
Posts (Atom)