Game Design 2: Menu Flow (2011)
•Als KEY, PDF herunterladen•
8 gefällt mir•6,609 views
The document discusses planning menu flow in game interfaces. It recommends creating flowcharts to identify how users will navigate between screens, which helps clarify design needs, distribute work, and get approval. Flowcharts should be based on user testing and priority design goals like simplicity versus customization. The document describes flowchart software and techniques like 37signals' approach using simple sketches for use case modeling before finalizing menu designs. It emphasizes planning navigation from a user-centric perspective to avoid missed screens.
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (19)
Ähnlich wie Game Design 2: Menu Flow (2011)
Ähnlich wie Game Design 2: Menu Flow (2011) (20)
Mehr von David Farrell
Mehr von David Farrell (19)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Game Design 2: Menu Flow (2011)
- 1. 2011 Game Design 2 Lecture 2: Planning Menu Flow
- 2. Book: Game Interface Design (Fox)
- 3. Why plan? • Getting it right first time saves time • Clarify your needs • Distribute work • Schedule • Get approval
- 4. Helping Games Design • CounterStrike ‘buy’ menu. • could have been difficult to put in later • Civilization 4 Trade screen • interface forces single civic change • this hurts the design
- 7. User Centric Design • You are (almost never) your target user • Find out what they think of other interfaces • Design around their preferences • Test your design and iterate!
- 9. Prioritise Design Goals • Always conflicting factors in a design • fact filled educational game • slick interface • Prioritise simplicity or customisation?
- 11. Planning a Front End “Clear communication of the flow of the interface is the number one goal of a flow chart.”1 1. Brent Fox, Game Interface Design, Page 13
- 12. Flowcharts • Identify how you get from A to B • If you use good software, you can mock up different flows using same screens. • Avoid having screens that you can’t get to
- 16. Flowchart Software • Any tool that works • Illustrator? • Flash? • Web tools like lovelycharts.com • Omnigraffle
- 17. Flowchart Techniques • 37 Signals is a company that specialises in well designed groupware. • They have a simple approach to flowcharting • (article here: http://bit.ly/37flowcharts ) • Good for Use Case modelling
- 18. use case • For example - imagine you are going to have a menu in your game to buy and sell goods in a shop. • There are many ways of doing this • so you decide what your usage-cases are: • buy item • sell item • compare items
- 19. • and then for each of these usage cases, follow the 37 signals approach to do a quick sketch of a possible screen flow
- 23. Multiple possible user actions Multiple outcome actions
- 24. End result • Lots of separate use-case sheets • you then take all these sheets and condense them into ‘actual menu’ decisions • you will have some conflicts if two use cases would like a certain screen to behave correctly ‘for them’ • better than ‘just deciding’ because you think about the user at all times and won’t miss screens (e-Bug)
- 25. 37 Signals Sketching • Pro’s • Good for quick idea sketching • Good for use case modelling • Easy to see important elements without getting lost in detail • Should be done before you start ‘filling in the gaps’ in your menu design
- 26. Brent Fox’s Approach • Draw a box, place title at top • Write screen options in box • ‘Guess’ at options in each screen
- 27. Brent Fox’s Approach • Link screens with arrows • Italics for important but non interactive items (descriptions etc) • Padlock symbols for ‘locked’ items • Simple use of colour
- 30. Pop Up Menus • Not usually standalone • Usually appear on top of screen • Cover only part of screen (dim) • Modal • Usually little info • Don’t usually go anywhere (dead end)
Hinweis der Redaktion
- We touched upon menus a little in last week’s overview. \nI also asked you to draw a quick UI of Werewolf last week.\nSome of you designed menus and one of the things that happens when you just ‘design a menu’ off the top of your head, is that you might forget to put something in - or you might put something in that you don’t really need to.\nFor example, one team had an ‘options’ item on their main menu - yet couldn’t tell me of any options in their game.\n\nSo this lecture is intended to help you move away from that kind of thinking. \n
- I am basing some of this lecture’s material on this book which I’ll probably call Fox throughout future lectures.\n\nBrian Fox is a game designer with many years of experience and he is one of the few people who has tried to actually write a book on game specific UI. \n\nIt is a little bit light on theory - most commercial designers don’t have good answers for ‘why’ but it’s good on practical advice and even though the Flash is a bit out of date now, it’s still a decent book.\n
- OK, so the first thing - and I’m sure you’ve covered similar ideas in other classes is planning.\n\nFirst time saves time - a but found in the planning stage is 10 x cheaper to fix than one in corrected later\n\nClarify needs\nIf you are doing a NORMAL hierarchical tree menu and later decide to add animation...\n3d menu in madden - they used to have this trophy room - you can look at accomplishments, records etc... \nit functions like a menu - but it behaves like a mini-game - camera - controlls...\nit’s functionally like a menu but its behaviour is like a game\n\nthat requires its own engine to be writen \nclippy - if you want an agent to give context sensitive help (like clippy - or like the advisors in civ - then you need to know this well in advance.\nsoftware won’t support the inclusion of an entity! \n\ndistribute work\nteam etc\nprogrammer / artists / asset / voice etc\nsome games have programmer, artist - mibbe a designer, and then even a post-production element\n\nneed to who is doing what etc..\n\nSchedule\ncrunch - getting paid / publishers\nbenefit of planning is in the process, not the plan\n\nGet approval\nIt might be weird to think of getting approval - at uni you get given a task, and you do it!\n\nBut in real world, you often need to get buy in or approval from line manager and others all way to publisher.\nAnd often you get two lines of management - in-house and publisher!\n\nNot always a problem - if relationship good - but if bad, then approval important.\n\nEA barry - harry potter and wipeout - he worked on menus for 2 years - any change required a meeting \nANY CHANGE!!!\nso he had to arrange meeting wiht “another company” (publishing arm) to do any change\n\n\nThe point is - it’s your job to get it right first time.\n\nyour job to manage the manager - you are designer \nyou need approval - but you are also the designer - they need your input\n\ne-bug scientists would have designed a shitty game \nmy job is to give what they want even if they don't know what they want\n\n
- So how does that actually help your design?\n\nHow much of a pain would it be to put a counterstrike buy menu in after the fact?\nThere is a reason every source game has that same opening menu - it’s out the box!\nBut the mod team for CS had to extend game engine to include that menu.\n\nCiv 4\nThere is a concept of these civics. There are 5 categories and you can choose from items in each category.\nWhether you change 1 or all 5, you suffer a few turns of unrest.\nSo When you change one - you’d be as well waiting till you can change them all\n\n
- Each civ has preferred civics.\n\nRussians may demand communism. Americans may demand you adopt democracy.\n\nImagine that Khan wants me to adopt Fundamentalism.\nSo look at this screen. The player wants to assess the trade.\nHow important is it that I keep this guy happy?\nWhat is the impact of the change this guy wants me to make?\n\nWhat you want to do is to click away to your civics screen (see over)\n
- and you want to see what your options are and then change all the other ones you want and then go back and tell Khan that - yes, you’ll adopt fundamentalism.\n\nBut the designers, either through oversight, or because they couldn’t find a good way to do it - don’t afford you this luxury.\n\nYou are forced to accept or decline the trade without the benefit of actually evaluating the offer properly.\n\nThis is the kind of scenario where you might FORGET in the moment that the player needs to do this considering when changing civics. But if you planned properly, and adopted a true user-centred approach, you would have noted the requirement and implemented the screen more effectively.\n
- So here at GCU, we push a user centred approach to game development.\n\nThis is contrary to the auteur approach - where it is one person’s true vision and everyone else’s view is secondary... That approach is rarer and rarer - and is rarely successful. We don’t advocate design my committee - but rather design that truly advocates for the user at all opportunities.\n\n You might work on Barbie! Or more likely, a social game for so called ‘middle aged housewives’ - you are so very different from your audience (unless you’re designer for game designers!) so you need to design for them.\n\nThis means getting to know your user. This means finding out how THEY experience other interfaces. And ultimately, you design for what THEY would like, and you iterate and you iterate and you iterate...\n
- A good example of user centred design is the approach I adopted to e-Bug.\n\nThis isn’t a game example - but the same approach was used.\n\nThe website had to suit different types of users. Youths needed very quick and easy access to the games. I didn’t want them to have to go hunting for the games - because all research shows that young people won’t do that unless they have to. For something that ‘seems educational’ like e-Bug, this was particularly important.\n\nSo in addition to the top level menu item ‘games’ - I also ensured that the very first thing you saw when you visited in was a little animation that linked to the games. So people looking for the games had TWO really visible links on the main page.\n\nHowever, I also had to satisfy teacher needs and include lots of lessons etc.\nSo I chatted to teachers and found out surprisingly, that many teachers hate what they call ‘chasey menus’ - i.e. drop down / hierarchical menus.\n\nWhen you imagine building a site like this - with lessons and downloads and additional files... the natural way is through a pulldown hierarchy. But because the users didn’t want that, I designed this menu / side menu design that was easy to use, but avoided that particular type of component.\n
- Ultimately, you need to know what you want to achieve with your design.\n\nUnfortunately, you really can’t “have it all”. You WILL have conflicting factors in your design. For example - if you’re working on an educational game that has lots of important text - say describing animals in Africa - this would conflict with the desire of users to not read reams of text.\n\nBut if your priority is that text, then you are choosing to make a small sacrifice in user experience to meet your main goal. You see this ALL THE TIME in games.\n\nWhen you see a game and ask ‘why didn’t they just do this?’ - the odds are that they did consider it but chose not to do it. Often you’ll hear journalists complaining about devs ‘why didn’t they do x - why didn’t they do y?’ - but when the journos jump ship and become devs, you often see them commenting on this - they have a new perspective.\n
- An example of priorities influencing design is the civopedia from Civ 4\n\nThe text here gives historic context - but also in-game strategy and factors.\n\nThe strategy text is higher than the background text.\n\nAnd the REALLY important stuff - the special abilities and requirements - are separated and in that area, there is NO guff. \n\nAnd this wee side area doesn’t scroll when the other bits of the ui do!\n\n
- OK, so hopefully, I have justified the need for doing a good job of designing your menus.\n\nWe’re going to look at some practical stuff now - how do you actually build one.\n\nA quote from Fox here...\n\nSo we’re going to be making flow charts - but you must remember that the whole point is to communicate how the interface - how the menus - will flow.\n\n\n\n\n
- Are you familiar with flow charts? What did you use?\n\nYou can use what you like, but we supply Omnigraffle.\nGood software can draw these out for you.\n\nOne of the benefits of proper flow charting (and wireframing, which we’ll cover later) is that you can avoid having screens that you can get to.\n\n
- An example of a feature you can’t get to from my own experience.\n\nI designed the e-Bug games when I had artists working with me. They were with me for a year, but I was on the project for about 3 years.\n\nI fully designed both games before writing a single line of code and when I started programming, I focussed on the physics engine of the platform game - because that was where the risk was on this project.\n\nI like to think I did a decent job of planning the project - but I had included feature that you couldn’t activate!!!\n\n(explain microbe-vision)\n
- you couldn’t get to this screen!\n
- can anyone see the programmer art?\n\nsee that pink button? that was added after the artists left - because I had no method in game to do this.\n\nWhen the game shipped, this ugly thing was in it. And not only was it ugly - it was also inappropriate - MV only means something in English.\n\nAfter shipping, we had to recontract the artist to do a new button (show demo)\n\n
- OK, so you can use any tool you like.\nWe use Omnigraffle because people say it is market leading software. I am not an expert on it but we have it - people like it - you may use it if you wish. \n\nWe’ll have a wee tutorial on it - but I won’t be able to get really in depth.\n\n\n
- So - how should you go about actually building the flow chart.\n\nAs I said, we’re going to use much from Fox in this lecture - but I disagree with the way that Fox decides which items to where in his menus.\nI’m going to suggest you use an approach that is described by the company 37 Signals.\n\nThese guys created Ruby on Rails and Bandcamp - and they’re known for writing high quality, easy to use software. They’ve also released some books etc... \n\nYou must read this article before the tutorial.\n\nThe basic idea is that instead of thinking about what items should appear in the menu - you think about a use-case of your program and then imagine the clearest way to get to that option.\n\n
- \n
- \n
- so this is the basic gist of their approach.\n\nYou start by choosing one of your use-cases - e.g. buy an item\n\nwith a pencil or pen (sort of explicitly NOT on your computer) you start by writing the context above a line - what the user sees.\n\nin our example - you might say the user is looking at a screen that shows all options the shop keeper has for sale - so above the line you write the context - e.g. screen showing items for sale\n\nthen you do your line and write underneath it the ONE option that the user does.\n\nIn this case - the user may click on an item that she wants to buy.\n\nthen you draw a line from the action item to the next thing - and you again describe the context (what they see) and the action (what they do)\n\nfor a simple use-case - i.e. user buys an item - this may be just two or three of these little atoms of work - but for a larger use case, it may span multiple pages.\n\n
- an example they provide is adding an item to a todo list\n\n(read above, describing what’s going on)\n
- But of course, one use-case can have many paths. What if the user didn’t have enough money to buy the item from the shop? it feels like there are at least two branches there.\n\nthis notation can be used to capture that.\n\nWhat you do is the same as before - but you use a dotted line for each potential action the user may make. (e.g. valid / invalid pass as above)\n\nNow - the important and subtle thing here is that you don’t just go ‘my menu has these items’ - you work in the context of the usage case that you have identified.\n\nI.e. - you don’t just add an options action! \n\n(describe above interaction - how the dotted lines work - how the arrows work)\n
- See here how at the ‘submit valid params’ user action - there are multiple outcome actions - this shows that the notation can cope with that kind of scenario.\n\n\n
- It isn’t trivial to condense all of these hand written sheets down into concrete menu items. But this is a technique we can use to coax our brains into finding all of those edge cases.\n\nYou may find that two use cases conflict - that’s to be expected - but use your judgement to resolve it - do you put two conflicting items into a sub menu? e.g. ‘play now’ could be single player - could be multi player - you could put single / multi under play now - or you could put play now under single and multi - it’s a choice you need to make - but you make it having considered the user’s need.\nIf you couple the use case approach with a priority list - then you can really do a good job of meeting needs.\n\n\n
- Do this in PENCIL - the idea here isn’t to get a final menu / screen flow straight away, the idea is to think like a user and get an idea for how things should hang together.\n\nIt isn’t supposed to be very formal.\n
- OK, so - you’ve done your 37 Signals use-case sketches.\n\nYou now want to commit to a formal menu design.\n\nSo we’re going to base our flowchart approach on Brent Fox’s approach.\nThe purpose of the flow chart we make here is (call back to the quote) \n\n“Clear communication of the flow of the interface is the number one goal of a flow chart.”\n\nSo this is the actual document you create that you could hand off to someone to build the menu. This is the formal realisation of the stuff you were figuring out with 37 signals.\n
- When you come to do your own flow charts - I don’t *mind* if you deviate from this - this isn’t gospel. But I want to see a legend - I want to know what YOU mean by the padlock. I want to know what YOU mean by colour. \n
- So let’s look at a simple chart for a football game.\n\nSee how the padlocks are used - there is meaning there - he’s showing that locations 3-5 behave like 1 & 2 - but that they are unavailable at the beginning of the game. A note should accompany the flowchart to reference WHERE you can get more info on this.\n\nSee how he uses italics - under Team, you have Team Description - this is ‘important information’ - i.e. we have a non-obvious requirement for this particular menu that makes it behave differently to other menus.\n\nThis is a simple chart - so you’ll see why you need to use software. You might want to rearrange these.. change things etc..\n\nNote - there are things here that he seems to have missed that you hopefully wouldn’t miss if you adopted a use-case approach. What about ‘pick a team’ - why does play now go to location? Surely I’d rather pick team than location?\n
- This is a more complex version of the same game. It’s messy visually - but one idea we will come back to a few times on this class is that complexity and complication are different things.\n\nEven though it looks messy - this is actually quite simple to follow.\nThere is something on this chart that I don’t like - can anyone guess what it is? (non-legend icons - the red, purple, yellow icons - what do they mean?)\n\nThere are some weird decisions. There are screens here that you can get TO from two locations but BACK only takes you to one - you can use colour (and legend it!) to solve this problem (e.g. options screen).\n\nAlso note the pop up at the bottom right (Player List) (see next slide)\n\n\n
- Pop ups are a kind of menu or screen.\nThey are almost always related to the previous screen. You click on an army and a pop up opens to ask you e.g. how many rations to supply. A pop up’s function is to drill into detain on a specific item that doesn’t feel like having a whole screen allocated to it.\n\nWhen you pop up, you put a semi-transparent dimming layer between pop up and previous detail. This makes the pop up POP from the background.\n\nModal screens are screens that require action before you can return to the previous screen. Most pop ups are modal - after all, what happens if you choose something else on the previous screen?\n\n\n