RSS

Category Archives: Design

Who is your game aimed at?

This post follows on from this one about defining your game’s personality and making sure you sell that to your team and your stakeholders.  Selling a vision to a team is all well and good, but if you want to make sure the vision you’re selling is on point, you need to spend some time working out who your game is aimed at.

Demographic

You already know that this is important to your game.  Everyone does.  It doesn’t take a design genius to know that a game aimed at teenage girls probably shouldn’t focus on tight Street Fighter timing and controls.  It’s worth remembering however that while the ‘who’ you’re aiming your game at clearly has an impact on what you make it also has a distinct impact on how you make it.

Who’s Actually Going to Play This?

So often in development this is something that the people selling your game don’t actually, fully know.  They’re either waiting for stats about hardware sales to come through or they’re hedging their bets while they gather data on other, similar titles.  That’s fine to some extent but developing a game with absolutely no idea to whom it’s going to be sold can absolutely wreck your game in later stages of development.  Publishers do focus tests some time after alpha and end up saying things like:

“It turns out that soccer moms really, really dig the basic concept but hate the main character.  I know! It’s crazy, we weren’t even targeting them with this title.”  Then there’s an awkward pause.  “It’s fine to change the main guy right?”

Extreme example maybe (or maybe not…) but even small changes at a late stage can kill a project by a thousand little cuts; heading off as many of them as possible at the beginning of a project by knowing EXACTLY who you’re selling this game to is a worthwhile thing to do.  So if the people selling your game don’t know exactly who they want to sell it to yet, you need to work with them to define a target audience you can all agree on as soon as possible.  You also then need to spend a good deal of effort throughout the lifecycle of the project making sure that they understand that design decisions are being made based on this audience.

Take control

If you’re publisher or sales team has no clear idea who they want to sell to, there are a couple of things you can do.

  1. Use your experience as a developer to work out an acceptable target audience for the general game idea (if the publisher are looking for a WWII FPS this is pretty straightforward, if they want a golf game featuring wizards and orcs it’s less so).
  2. Develop the game whilst budgeting and scheduling for a lot of focus and usability testing.

The first point is relatively straightforward but still comes with the risk that the publisher changes their mind later on in development (although by agreeing age groups and target audiences up front you’ve minimised this to some extent).

The second option is the ideal line to take.  If you’ve got independent facts about who liked what about your game, whether it’s something as general the concept art for the main character or something really specific like the number of people who prefer clicking and holding the thumbstick to duck, you can always rely on metrics.

A Note about Testing

The trick with testing, as someone I once worked with sagely said, is to “never listen to anything anyone has to say in usability tests”.  You need to make sure you’re information is coming as much from measurement as possible.  People lie, people misunderstand questions and very often people get carried away with being in a focus group and tell you anything as long as it seems like it’s what you want to hear.  You can attach metrics to almost any aspect of your game if you design the tests.  Want to measure whether people like a certain character design over others?  Measure length of time they spent looking at conceptimage4.jpg when compared to images 1,2 3 and 5.  Even better go to a proper testing facility and measure their biometric reaction to it.  You can interview people about the designs on top of this but getting a measure of something as simple as time spent looking at the image can assist you in filtering these interviews.

Design for your market and test it

If you’re in the business of making games that are intended to be sold, you’re making them to a market.  Sometimes this market is simply people who like fun new things and you can go ahead make the next Limbo but often the reality is that you’re making something where your vision holder needs to work with a variety of stakeholders and here understanding and testing the market you’re aiming at is key.  A good designer’s gut instinct about something should never be ignored but testing a hypothesis out either with up-front focus testing or with user testing a prototype can help you make an informed call about whether or not you want to devote a portion of the game’s budget to a new feature or not.  You don’t even have to go to the trouble of focus testing some ideas, building up a good competitive analysis of similar titles and checking their reviews for clues as to why it scored well or badly is a hugely valuable task for designers or production assistants at the start of a project.  Just make sure this data is searchable, either by being properly tagged in a wiki or in a well-specced spreadsheet.

In Conclusion

So over the last few of posts, we’ve looked a little at the idea that it’s important to be able to define your game’s personality but also why it’s important to make sure that personality matches up with a target audience.  Test, research and confirm with your stakeholders what you’re making and then make sure you sell that game to your team and your company.  It’s vital that people work towards the same goal and that’s staggeringly difficult to ensure with a game, something that takes years and tens (often hundreds) of people to do.

Advertisements
 
Leave a comment

Posted by on March 1, 2011 in Design, Process, Production

 

Who is your game and who is it aimed at?

These are two key questions that need to be answered right at the start of development.  They need to be understood and agreed upon by whoever has the job of selling your game and they need to be thoroughly and absolutely communicated to your team by your vision holder.   I’ll look at both questions over the course of a couple of posts, looking first at the concept of a game’s identity.

It's a question

Who is Your Game?

Whether a dev team intends it or not, every game ends up having a personality.  It’s in how the game feels, how the game plays and how the game communicates with its audience.  You find it in the dialogue, the animation, the way the game punishes and rewards you, the environments, the characters, the audio and the GUI.  It’s the first thing a player will sense and it’s often the only thing they’ll remember when the game is back on the shelf or sitting in a second hand bin in GameStop.  The best developers spend a lot of time honing this personality, this vision and then make sure every aspect of the game oozes with it.  The worst don’t even acknowledge its existence and their game comes out confused and weak; built by committee.

Coming up with a vision is a process that is particular to individual teams and designers.  It can come by divine spark, from boardroom discussions or from great brainstorming sessions but it’s not the subject I’m interested in here and now.  What I want to look at comes after you nail this vision; it’s about how you make sure it runs through the life of your game and how everyone involved in the game’s creation stays true to it.

Get the Vision Out There

Once your vision holder has the vision in their head, they need to get these out there to everyone else.  Everyone on the game team should know the game vision.  How is the game supposed to feel? Why is that important?  What is the game’s personality?  I wouldn’t expect everyone on the team to be able to answer those questions as succinctly as the vision holder or producer but I would expect them to be able to get the key points across.

My preferred method of communication here is to boil your design down to two key words, then work up a key phrase and branch out to some key images and rules.  Once you have these, get them on a wall somewhere in the team area and make sure everyone sees them.

Key Words

Nailing two key words is hard.  You want more.  You want sentences.  You’ll argue about them with everyone if you’re brainstorming it and you’ll argue about them with yourself if you’re going it alone but keeping it to two words is a really good way of ensuring that you know the absolute top priority, nitty gritty elements of how you want a user to feel when they play your game.  The last game I worked on ended up with two words only after a five hour meeting between the project leads, the vision holder and the studio design director.  It was a nasty meeting – at one stage featuring only the word FUCK in block capitals on a whiteboard but we came out with something rock solid that we referenced right up until the dying days of bug fixing before release.  Does this feature/art/bit of polish magnify one of the two key phrases?  No?  Then have another think about it.

Key Phrase

Once you have your key words, you can move onto a key phrase.  The most useful part of doing this is that it can be attached to the branding side of your game from an early stage.  Brand people like a strong phrase because it attaches emotion to a product in the same way a strong image does – you can use this to help others get their heads around how your game will feel.  Where the two key words are used as ideals to hold all project work up against, the key phrase is used to sell the emotion of your game.  It can describe the game or it can be something a little more abstract, it depends on who you’re dealing with.  Descriptions at this stage can be risky because they can start to list content and that’s something you want to leave until a little later in the process but likewise if you’re dealing with fairly literal people, they can be the most succinct method of communicating the game’s feel.  Try to fill it with powerful words and active verbs and try to keep it short too, 50 – 70 words should be plenty.

Key Images

Words are good but visual references are by far the quickest way of accurately selling an idea to others.  If you’re lucky enough to have a vision holder who can wield a Wacom tablet, you’ll do well.  If not, then Google Image Search and understanding concept artists are your only options.  The vision holder needs to reference anything from games, TV, film, graphic design etc. that they feel helps get the game vision out of their head.  These can serve as precise visual targets to hit or simply inspiration but images are so easy to point to and discuss that they can save hours of explanation during the development of a game.

It’s also worth noting that there are usually a few visual or character traits that people commonly attach to your game that aren’t relevant and it’s just as important to pick these out and make them public.

Vision Presentation

Once you’ve got these images, words and phrases picked out, do a PowerPoint and ideally present this to your team somewhere.  I know, PowerPoint presentations are for sales people and marketing assholes but I’m a huge fan of what a well crafted PowerPoint can do.  At their best, they provide a simple, lean message that cuts out the fluff of a Word document.  Fewer words mean more eyes will read them all and that’s exactly what you need here.  If you haven’t got a boardroom or area to present it, email it around and spend time with people making sure they’ve seen it and understand it.

Vision Wall

This is by no means a new concept but it backs up your presentation beautifully.  A vision wall is a tried and tested way of getting key images and ideas front and centre and gives anyone who visits your team area a clear idea of what you’re trying to make.  Your vision holder should put up their key images and these should be grouped by game areas if necessary (GUI, level 1, boss encounters) and updated regularly to keep it valid.  Your key words and key phrases should be up and you should also put regular screen captures from the game to highlight areas that are working well and strongly support the game vision.

Some words from this blog post in a cloud

We’ll deal with ‘who’s going to play your game’ in the next post.

 
1 Comment

Posted by on February 9, 2011 in Design, Production, Project Management