GCU Game Design 2 (2013): Lecture 2 - Menu Flow
•Transferir como PPT, PDF•
2 gostaram•3,050 visualizações
This lecture shows what can happen if you DON'T plan your menu flows and discusses some techniques to help do so.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Destaque
Destaque (10)
Semelhante a GCU Game Design 2 (2013): Lecture 2 - Menu Flow
Semelhante a GCU Game Design 2 (2013): Lecture 2 - Menu Flow (20)
Mais de David Farrell
Mais de David Farrell (11)
Último
Último (20)
GCU Game Design 2 (2013): Lecture 2 - Menu Flow
- 1. Game Design 2 Lecture 2: Planning Menu Flow 2013
- 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. “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 Planning a Front End
- 12. • 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 Flowcharts
- 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. • Link screens with arrows • Italics for important but non interactive items (descriptions etc) • Padlock symbols for ‘locked’ items • Simple use of colour Brent Fox’s Approach
- 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)
Notas do Editor
- We touched upon menus a little in last week’s overview. I also asked you to draw a quick UI of Werewolf last week. Some 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. For example, one team had an ‘options’ item on their main menu - yet couldn’t tell me of any options in their game. So this lecture is intended to help you move away from that kind of thinking.
- I am basing some of this lecture’s material on this book which I’ll probably call Fox throughout future lectures. Brian 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. It 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.
- OK, so the first thing - and I’m sure you’ve covered similar ideas in other classes is planning. First time saves time - a but found in the planning stage is 10 x cheaper to fix than one in corrected later Clarify needs If you are doing a NORMAL hierarchical tree menu and later decide to add animation... 3d menu in madden - they used to have this trophy room - you can look at accomplishments, records etc... it functions like a menu - but it behaves like a mini-game - camera - controls... it’s functionally like a menu but its behavior is like a game that requires its own engine to be written clippy - 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. software won’t support the inclusion of an entity! distribute work team etc programmer / artists / asset / voice etc some games have programmer, artist - mibbe a designer, and then even a post-production element need to who is doing what etc.. Schedule crunch - getting paid / publishers benefit of planning is in the process, not the plan Get approval It might be weird to think of getting approval - at uni you get given a task, and you do it! But in real world, you often need to get buy in or approval from line manager and others all way to publisher. And often you get two lines of management - in-house and publisher! Not always a problem - if relationship good - but if bad, then approval important. EA barry - harry potter and wipeout - he worked on menus for 2 years - any change required a meeting ANY CHANGE!!! so he had to arrange meeting with “another company” (publishing arm) to do any change The point is - it’s your job to get it right first time. your job to manage the manager - you are designer you need approval - but you are also the designer - they need your input e-bug scientists had ‘rank’ on me but probably wouldn’t have made great games. my job is to give what they want even if they don't know what they want
- So how does that actually help your design? How much of a pain would it be to put a counterstrike buy menu in after the fact? There is a reason every source game has that same opening menu - it’s out the box! But the mod team for CS had to extend game engine to include that menu. Civ 4 There is a concept of these civics. There are 5 categories and you can choose from items in each category. Whether you change 1 or all 5, you suffer a few turns of unrest. So When you change one - you’d be as well waiting till you can change them all
- Each civ has preferred civics. Russians may demand communism. Americans may demand you adopt democracy. Imagine that Khan wants me to adopt Fundamentalism. So look at this screen. The player wants to assess the trade. How important is it that I keep this guy happy? What is the impact of the change this guy wants me to make? What you want to do is to click away to your civics screen (see over)
- 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. But the designers, either through oversight, or because they couldn’t find a good way to do it - don’t afford you this luxury. You are forced to accept or decline the trade without the benefit of actually evaluating the offer properly. This 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.
- So here at GCU, we push a user centred approach to game development. This 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, although still too common - and is rarely dependable. We don’t advocate design my committee - but rather design that truly advocates for the user at all opportunities. You might work on a Barbie game! 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. This 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...
- A good example of user centred design is the approach I adopted to designing the e-Bug website. This isn’t a game example - but the same approach was used. The 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 (really hunt) unless they have to. For something that ‘seems educational’ like e-Bug, this was particularly important as the obvious ‘worthyness’ of it might put them off. So 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. However, I also had to satisfy teacher needs and include lots of lessons etc. So I chatted to teachers and found out surprisingly, that many teachers hate what they call ‘chasey menus’ - i.e. drop down / hierarchical menus. When 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.
- Ultimately, you need to know what you want to achieve with your design. Unfortunately, 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. But 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. When 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.
- An example of priorities influencing design is the civopedia from Civ 4 The text here gives historic context - but also in-game strategy and factors. The strategy text is higher than the background text. And the REALLY important stuff - the special abilities and requirements - are separated and in that area, there is NO guff. And this wee side area doesn’t scroll when the other bits of the ui do!
- OK, so hopefully, I have justified the need for doing a good job of designing your menus. We’re going to look at some practical stuff now - how do you actually build one. A quote from Fox here... So 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.
- Are you familiar with flow charts? What did you use? You can use what you like, but we supply Omnigraffle. Good software can draw these out for you. One 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.
- An example of a feature you can’t get to from my own experience. I 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. I 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. I like to think I did a decent job of planning the project - but I had included feature that you couldn’t activate!!! (explain microbe-vision)
- you couldn’t get to this screen!
- can anyone see the programmer art? see that pink button? that was added after the artists left - because I had no method in game to do this. When 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. After shipping, we had to re-contract the artist to do a new button (show demo)
- OK, so you can use any tool you like. We 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. We’ll have a wee tutorial on it - but I won’t be able to get really in depth.
- So - how should you go about actually building the flow chart. As 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. I’m going to suggest you use an approach that is described by the company 37 Signals. These 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... You must read this article before the tutorial. The 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.
- so this is the basic gist of their approach. You start by choosing one of your use-cases - e.g. buy an item with a pencil or pen (sort of explicitly NOT on your computer) you start by writing the context above a line - what the user sees. in 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 then you do your line and write underneath it the ONE option that the user does. In this case - the user may click on an item that she wants to buy. then 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) for 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.
- an example they provide is adding an item to a todo list (read above, describing what’s going on)
- 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. this notation can be used to capture that. What 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) Now - 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. I.e. - you don’t just add an options action! (describe above interaction - how the dotted lines work - how the arrows work)
- 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.
- 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. You 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. If you couple the use case approach with a priority list - then you can really do a good job of meeting needs.
- 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. It isn’t supposed to be very formal.
- OK, so - you’ve done your 37 Signals use-case sketches. You now want to commit to a formal menu design. So we’re going to base our flowchart approach on Brent Fox’s approach. The purpose of the flow chart we make here is (call back to the quote) “ Clear communication of the flow of the interface is the number one goal of a flow chart.” So 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.
- 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.
- So let’s look at a simple chart for a football game. See 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. See 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. This is a simple chart - so you’ll see why you need to use software. You might want to rearrange these.. change things etc.. Note - 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?
- 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. Even though it looks messy - this is actually quite simple to follow. There 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?) There 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). Also note the pop up at the bottom right (Player List) (see next slide)
- Pop ups are a kind of menu or screen. They 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. When 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. Modal 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?