1 / 60

Iterative Development

Iterative Development. Simon Sherr & Mark Turmell. Internal Use Only. Agenda. Iterative Development Feature/Sandbox Trap Accessibility Core Designing for Accessibility and Iteration Building from Core. Goals.

lexine
Télécharger la présentation

Iterative Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Iterative Development Simon Sherr & Mark Turmell Internal Use Only

  2. Agenda • Iterative Development • Feature/Sandbox Trap • Accessibility • Core • Designing for Accessibility and Iteration • Building from Core

  3. Goals • To establish a core football Engine that can be utilized to build any football game • Madden, NCAA, Madden Wii, NewIP • Console, PC • Prepare for direct to consumer, membership model. • Modular • Gillette’s Law • Establish a pipeline that would allow outsourcing all production asset variety creation (including gameplay animation). • Eliminate the COSTLY Crunch/Relax dev cycle.

  4. Game Engine Defined • Game engines provide a suite of visual development tools in addition to reusable software components* • Unreal is an engine (but not the right one for us) • Army of Two • Mirror’s Edge • Batman • TNA iMPACT • Gears of War • Adventure Pinball • Nerf Arena Blast • ANT is only an engine, when it is used as one. • This was a requirement when ANT was created (work as an animation module or a gameplay engine) • NHL, FightNight4, Facebreaker, NBA Street, Def Jam Icon, FIFA Street, MMA, SSX, Battlefield Bad Company – all use the ANT Stateflow/Wireframe/Base-Kit “Engine” to build the game from the core out. • FIFA uses the engine to some extent but is on their own with “action layer” • NBA Live is doing a re-write to use the ANT Stateflow engine • Football uses a hybrid of Gamecode, ANT as an animation module, and Emotion2 * Wikipedia: “Game Engine”, Overview Section

  5. How we used to build features

  6. Challenges: Pre-Production Phase • Production/Designer bottlenecks trying to paper design. • Poor design docs • Rarely reflect final design. • Lack sufficient detail. • Difficult for SE’s to do accurate time estimates.

  7. How we used to build features

  8. Challenges: Production Phase • Wasted time and $$ in mocap throwaway. • Wasted time and effort in code and animation throwaway. • Lots of hacking – SE’s and Animators. • Difficult to keep accurate/current schedule. • Everything depends on gameplay, and gameplay is often the last to come in. • Fun can come very late or not at all.

  9. The Prototype Approach • Tech Design Documentation: Sample Info • Stateflow diagram of game system • User Inputs for stateflow triggers • Player ratings for stateflow triggers • Animation info: • start pose • start position (2-man) • end pose • total length (frames) • branch points • trajectory • z-translation

  10. Advantages: Pre-Production Phase • First step involves communication and collaboration (ownership). • Rarely any need for mocap (you are using placeholder animations). • Building features with least animations possible results in no “coverage holes”. • Proves fun early. • Results in truly excellent technical design docs.

  11. The Feature Prototype Approach

  12. Advantages: Production Phase • Mocap shoots in this phase are now way more efficient. • Easier to code more effectively with predefined specs. • Animators can do amazing things when their boundaries are clearly defined. • DD’s can build more accurate schedules and better identify risks and dependencies. • You actually can throw people at the problem during Population phase.

  13. A different approach to Year/Year? Proof of Concept Pre-pro Production Final Old 10 50 50 60 720 Staff Months +Art+FE+Other ~$10M Investment Timelines Budgeting Staffing Quality Known Options? Vertical Slice FEATURE COMPLETE! Proof of Concept Prototype Production Tuning New 1-3 5-12 Mostly Outsourced? 5-12? 100 Staff Months ~$1M Investment/Risk Quality Known Timelines Budgeting Staffing Investment Options: Cut? Shelf? XBLA? $29.99? $49.99?

  14. The Iterative Development Model

  15. Advantages • No one stops working • Far less throw-away work • Features in production have functional and tuned prototypes BEFORE ASSET POPULATION! • No Crunch-Relax-Crunch-Relax cycle • Far less overtime • Far less burn-out • When people are less burned you get less bugs • Production can be Scheduled and Budgeted! • More conducive to a membership or Direct to consumer model • Features can be rolled out as they are done • Features are proven well before they go “Alpha” • Less risk in taking risks = innovation and quality. • In production you CAN THROW MONEY at the problem (or pull money away if you decide it’s enough).

  16. Agenda • Iterative Development Defined • Feature/Sandbox Trap • Accessibility • Core • Designing for Accessibility and Iteration • Building from Core

  17. The “Features” Trap • For 20 years we have been building gameplay based on a feature list. • In Sports, this list is most often extrapolated from analyzing the real sport. “I saw a guy spin in a football game the other day… It was awesome” • Once we have built all or most of these “features”, we then try to piece them together in a sensible manner. • This is not really game design at all. • It’s a sandbox not a designed structure or system • Once serious playtesting begins, usually post-alpha, we then begin to discover holes in the system. “spinning has no purpose at all” • Patching these holes often requires new features, adding unwanted risk and chaos late in the project. • This can be prevented by prototyping and building balanced, closed-loop systems in pre-production. • This starts with the Core.

  18. Gameplay Mechanics • Gameplay Mechanics are actions that a User can perform. • Gameplay is NOT just a combination of mechanics Run Juke Spin Block Hurdle Fumble Tightrope Gameplay Mechanics Football Sprint Celebrate Truck

  19. The “Features” Trap Run Tackle Screen Throw Catch Taunt Block Celebrate Juke Sack Pass Tackle ??? ??? Breakout QB Vision

  20. Gameplay System • Gameplay Mechanics combine together create a Gameplay System Run Simple Run Vs. Tackle System Score Tackled Down Juke Spin

  21. Game Network of Gameplay Mechanics andGameplay Systems make up the Game as a whole Heave Shot inbound Turbo Locomotion Fake Steal Fake Punk Shoot Dunk Punk Steal Jumpoff Dunk Alleyoop Shot Block Dunk Block Steal Bobble Poke Steal Take Steal Counter Steal Counter Punk Body Counter Punk Ball Jumpoff Counter Jumpoff Block Block Alleyoop Fake Shove Trick Shove Trick Point Earned Gbreaker Earned Gbreaker Triggered Light Shove Strong Shove Shove Behind Counter Shove GBreaker GB Trick GB Dunk GB Punk GB Pass *NOTE: This is not an actual game. It is gibberish. GB Reward GB Jumpoff Dunk GB Punk Counter Body GB Punk Counter Ball

  22. Agenda • Iterative Development Defined • Feature/Sandbox Trap • Accessibility • Core • Designing for Accessibility and Iteration • Building from Core

  23. Why We Game • Practicing survival instincts • A chemical reward for practicing survival skills (this is what “FUN” is!!!) • “I want to improve this survival skill”. • Competition of survival instincts • Competition instincts to prove I am a better mate than YOU • “I am better at this survival skill than that guy, don’t you want me now?”. • Escape from personal physical limitations or social societal limitations. • “I want to be a hero” • “I want to be an athlete” • “I want to be strong” • “I want to kill people” • “I need to destroy something” • Social interaction

  24. Accessibility • It’s about “access” not “blocking” • This is not turning off mechanics in “easy” mode • No system should change as difficulty increases • No system should suddenly become available as difficulty increases • Progression is about getting TO the depth not changing how you play. • A casual gamer will go just as deep into systems as a hard core gamer. • A “casual gamer” will stop playing if frustrated. • A casual gamer will not “beat a game in 6 hours and return it”. • If a game is worth returning, it’s not worth beating

  25. Respecting the Casual Gamer! • Casual Gamers play to PLAY, not to win • Winning is a side effect, it’s a feedback loop • “finishing a game” is not where casual gamers stop • Casual gamers will invest far more time in ONE title • And will return to that title for years • Casual gamers will learn depth, and will become very skilled at the games they like to play • Casual gamers will not play frustrating games, it’s not that important to them to “finish” • Kids play games like casual gamers play games • Don’t want steep learning curves • Will not play if frustrated • Will not play if “easy” is too hard • Difficulty should be optional, gradual increases in challenge based on learned or mastered skills. • They are NOT stupid, they are NOT unskilled they just have different goals. • Fun rather than accomplishment, winning, unlocking achievements or game modes

  26. Agenda • Iterative Development Defined • Feature/Sandbox Trap • Accessibility • Core • Designing for Accessibility and Iteration • Building from Core

  27. Core System • Your Core System is the gameplay system a new User will learn first and the one they will use the most. • Improvements and innovations to the core will have the Biggest impact on the most consumers. • You should be able to win and have fun playing your game on “easiest setting” using ONLY the core system

  28. Setting Core Complexity Limits • Identify your target demographic • Create a system that allows all of them to play the game • Provide accessibility to learning other systems that support success in core system • Structured progression • Structured depth • Defined learning steps

  29. Identify your Core Gameplay System • Determine your game’s win condition. • Identify the mechanics that directly impact this condition. • E.g. The act of calling a play in football does not score points BY ITSELF.. So it is not a core mechanic to football. • Identify the mechanics that directly prevent this condition. • These mechanics combine to create a system. This system is your Core.

  30. What is Football Core??? • Win Condition = Score More Points • How do you score and prevent scoring? • Run or Pass into Endzone = Score • Tackle/Sack, Intercept/Block = Prevent Scoring • Core System Mechanics we need to make a CLOSED loop system for. • Offense: BC Run, Pass/Catch Vs. • Defense: Offball Run, Tackle, Sack, Intercept/Block

  31. Simulation Vs. Arcade Sports • Above the core systems for simulation sports games, are the rules of the sport • Visual realism can still be somewhere else in the bulls-eye • Arcade sports can break the rules of the sport, if it’s fun • Goal tending in NBA Street • Blowing people up in Mario Strikers • 1st and 30 in NFL Blitz • The same Technology, Engine, Animation, even Core system can work for both

  32. Agenda • Iterative Development Defined • Feature/Sandbox Trap • Accessibility • Core • Designing for Accessibility and Iteration • Building from Core

  33. Structured Design • Provides foundation to build on • Helps you fill in holes • Allows you to iterate on and structure and more easily balance gameplay • Allows you to control and eliminate exploits

  34. Hitting the Bullseye

  35. Example: MMA

  36. Feedback Loop • In order to learn and eventually master a Gameplay Mechanic the User will go through multiple, chained Feedback Loops.

  37. Feedback Loop Chain Example: Tackle Mechanic Press the X button Enter Tackle State - Fail Player Dives I can dive!

  38. Feedback Loop Chain Example: Tackle Mechanic Press the X button Enter Tackle - Fail Dive Animation Plays Skills can be Chained I can Dive! Dive near opponent Enter Tackle - Success Tackle Animation Plays I can tackle!

  39. Play • User acquires skill/tool. • User experiments with skill/tool. • User eventually uses skill/tool to learn another skill/tool. • User experiences pleasure and starts process all over again, chaining Feedback Loops together.

  40. Fun • Fun is derived from the act of mastering knowledge, skills and tools. • The deeper and more complex the knowledge/skills/tools learned, the more rewarding it feels. • These “aha” moments release a natural opiate in our brains called Endomorphin. • It’s like Morphine. • Which is good stuff.

  41. Problem When Feedback Loops go wrong Press the X button Dive Near Opponent Dive Near Opponent Dive Near Opponent Play Tackle Check Player Rating Generate Random Number Play Tackle Check Player Rating Generate Random Number Play Tackle Check Player Rating Generate Random Number Play Tackle - Fail Dive Broken Tackle Tackle Success Broken tackle ending in Injury I can tackle! I missed! I dive! WTF!!

  42. !Fun • User acquires skill/tool. • User experiments with skill/tool. • User is unable to use skill/tool to learn another skill/tool. • User believes their actions have been in vain, and feel frustration or boredom. • Catecholamines are released when we discover something we have learned is incorrect – this hormone is responsible for anger and frustration, claustrophobia, panic attacks – !FUN.

  43. Question How could we fix it?

  44. Example Problem Example: Hit Stick Flick the Stick Flick near opponent Flick near opponent Check Player Rating Generate Random Number Trigger a hitstick tackle Check Player Rating Generate Random Number Trigger a stumble Tackle Fail Player Stumbles Huge Hit Stick! Player Stumbles I can Stumble?? I can lay people out! I missed! WTF!

  45. What’s really going on Flick the stick Check Player Rating +/- Based on Distance from opponent +/- Based on Ball carrier Proximity +/- Based on Ball carrier juke or spin? +/- Based on Timing +/- Based on Player Balance +/- Based on Player Stamina +/- Based on Pressure Situation +/- Based on Other Voodoo Stuff +/- Based on 20 year old bugs +/- Animation coverage Generate Random Number Success, Failure, normal tackles, hitsticks, injuries, fumbles, broken tackles, gang tackles I don’t get it! Tackling is Random! This game Cheats!!

  46. Proposed Solution 100% deterministic tackle with clear feedback loop Dive nearer to opponent Opponent presses X Dive from far away at Opponent Dive very near opponent Opponent presses X Opponent presses X Opponent presses X Press X from too far away Dive very near opponent Check Player Rating Check Range Check Player Rating Check Range Check Player Rating Check Range Check Player Rating Check Range Check Timing window Check Timing window Check Timing window Check Timing window Tackle Fail - Dive Play huge impact tackle with very small breakout and large fumble window (maybe an injury window) Player does a dive that visually attempts to grab opponent Tackle with a medium breakout window. Play decent impact Tackle with tiny breakout window Failed breakout animation Broken tackle Animation Broken shoelace tackle Animation Fumble Animation Tackle with large breakout window I laid him Out! I caught his shoe lace, I was still too far away. He FUMBLED! (shouldn’t have tried to break such a big hit) He tried to break lose and failed! I can Dive for him! but I was too far away. I laid him OUT! I missed, I was slow! He broke loose, I was slow! I dragged him down slowly

  47. Recap • Prioritize mechanics that make up your core system. • Analyze your mechanics using feedback loops. • Build deep systems with clear feedback around your core mechanics.

  48. Agenda • Iterative Development Defined • Feature/Sandbox Trap • Accessibility • Designing for Accessibility and Iteration • Building from Core

More Related