iterative development

60
Iterative Development Internal Use Only Simon Sherr & Mark Turmell

Upload: lexine

Post on 24-Feb-2016

60 views

Category:

Documents


0 download

DESCRIPTION

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. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: Iterative Development

Iterative Development

Internal Use OnlySimon Sherr & Mark Turmell

Page 2: Iterative Development

Agenda

1. Iterative Development2. Feature/Sandbox Trap3. Accessibility4. Core5. Designing for Accessibility and

Iteration6. Building from Core

Page 3: Iterative Development

Goals

1. To establish a core football Engine that can be utilized to build any football game

1. Madden, NCAA, Madden Wii, NewIP2. Console, PC

2. Prepare for direct to consumer, membership model.

1. Modular2. Gillette’s Law

3. Establish a pipeline that would allow outsourcing all production asset variety creation (including gameplay animation).

4. Eliminate the COSTLY Crunch/Relax dev cycle.

Page 4: Iterative Development

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

Page 5: Iterative Development

How we used to build features

Idea

Creative Brief

Feature Brief

Tech Brief

Pre-Production

Prod

Page 6: Iterative Development

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.

Page 7: Iterative Development

How we used to build features

Idea

Creative Brief

Feature Brief

Tech Brief

Pre-Production

Prod

MoCapCoding Animating

Feature In

Fun/Ready?

Re-codeRe-animateMore mocapHack, Slash

NO

Prod

Production

Final

YES

Page 8: Iterative Development

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.

Page 9: Iterative Development

The Prototype ApproachIdea

Prototype

Code(Hack)

Animation(Placeholder)

Feature In

Fun/ready? Continue?NO

Cut Idea

NO

Refine Idea /iterateYES

Tech Design Documentation

ProdReady

Pre-Production

Tech Design Documentation: Sample

InfoStateflow diagram of game systemUser Inputs for stateflow triggersPlayer ratings for stateflow triggers Animation info:

start pose start position (2-man) end pose total length (frames) branch points trajectory z-translation

Page 10: Iterative Development

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.

Page 11: Iterative Development

The Feature Prototype Approach

Idea

Prototype

Code(Hack)

Animation(Placeholder)

Feature In

Fun/ready? Continue?NO

Cut Idea

NO

Refine Idea /iterateYES

Tech Design Documentation

ProdReady

Pre-Production

ProdReady

Production

MoCap

Code(Proper Implementation)

Animation (Final Quality)

1-off to completion built to spec

Fine tuning

Populate with tons of content.

Final

Page 12: Iterative Development

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.

Page 13: Iterative Development

A different approach to Year/Year?

Proof of Concept

10

Pre-pro Production Final

50 50 60

Production Tuning

Mostly Outsourced? 5-12?

TimelinesBudgeting

Staffing

Quality KnownTimelinesBudgeting

Staffing

Investment Options:

Cut?Shelf?XBLA?$29.99?$49.99?

Quality Known

100 Staff Months~$1M

Investment/Risk

Options?720 Staff Months+Art+FE+Other

~$10M Investment

Vertical Slice FEATURE

COMPLETE!Proof of Concept Prototype

5-121-3

Old

New

Page 14: Iterative Development

The Iterative Development Model

Page 15: Iterative Development

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).

Page 16: Iterative Development

Agenda

1. Iterative Development Defined2. Feature/Sandbox Trap3. Accessibility4. Core5. Designing for Accessibility and

Iteration6. Building from Core

Page 17: Iterative Development

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.

Page 18: Iterative Development

Gameplay Mechanics Gameplay Mechanics are actions

that a User can perform. Gameplay is NOT just a

combination of mechanicsRun

Hurdle

Juke Spin Block

Fumble

CelebrateSprint

Tightrope

Truck

Gameplay Mechanics

Football

Page 19: Iterative Development

The “Features” TrapRun

Taunt

Juke

??? ???

Sack

Tackle

Pass

QB Vision

Tackle Screen

Block Celebrate

Throw Catch

Breakout

Page 20: Iterative Development

Gameplay System

Gameplay Mechanics combine together create a Gameplay System

Simple Run Vs. Tackle

System

Run

Tackled

Juke SpinDown

Score

Page 21: Iterative Development

Network of Gameplay Mechanics and Gameplay Systems make up the Game as a whole

Game

*NOTE: This is not an actual game. It is gibberish.

Locomotion

Shoot Dunk

Shot Block

Jumpoff Dunk Alleyoop

Dunk Block

Turbo

Trick

Counter Punk Ball

inbound

Shove

Heave Shot

Counter Punk BodyJumpoff

Counter

Counter Steal

Punk

Steal Bobble Take StealPoke Steal

Fake Steal Fake Punk

Steal

Block Alleyoop

Jumpoff Block

Trick Point Earned

Gbreaker Earned

Gbreaker Triggered

Fake Shove

Counter ShoveLight Shove Strong

ShoveShove Behind

GB Jumpoff Dunk

GBreaker

GB Trick GB Punk

GB Punk Counter Ball

GB Dunk GB Pass

GB Punk Counter

BodyGB Reward

Page 22: Iterative Development

Agenda

1. Iterative Development Defined2. Feature/Sandbox Trap3. Accessibility4. Core5. Designing for Accessibility and

Iteration6. Building from Core

Page 23: Iterative Development

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

Page 24: Iterative Development

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

Page 25: Iterative Development

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

Page 26: Iterative Development

Agenda

1. Iterative Development Defined2. Feature/Sandbox Trap3. Accessibility4. Core5. Designing for Accessibility and

Iteration6. Building from Core

Page 27: Iterative Development

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

Page 28: Iterative Development

Setting Core Complexity Limits

1. Identify your target demographic2. Create a system that allows all of

them to play the game3. Provide accessibility to learning other

systems that support success in core system

1. Structured progression2. Structured depth3. Defined learning steps

Page 29: Iterative Development

Identify your Core Gameplay System

1. Determine your game’s win condition.2. Identify the mechanics that directly

impact this condition.1. 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.

3. Identify the mechanics that directly prevent this condition.

4. These mechanics combine to create a system.

This system is your Core.

Page 30: Iterative Development

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

Page 31: Iterative Development

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

Page 32: Iterative Development

Agenda

1. Iterative Development Defined2. Feature/Sandbox Trap3. Accessibility4. Core5. Designing for Accessibility and

Iteration6. Building from Core

Page 33: Iterative Development

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

Page 34: Iterative Development

Hitting the Bullseye

Page 35: Iterative Development

Example: MMA

Page 36: Iterative Development

Feedback Loop

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

Page 37: Iterative Development

Feedback Loop ChainPress the X button

Enter Tackle State - Fail

Player Dives

I can dive!

Example: Tackle Mechanic

Page 38: Iterative Development

Skills can be

Chained

Feedback Loop ChainPress the X button

Enter Tackle - Fail

Dive Animation Plays

I can Dive!

Example: Tackle Mechanic

Dive near opponent

Enter Tackle - Success

Tackle Animation Plays

I can tackle!

Page 39: Iterative Development

Play

1. User acquires skill/tool.2. User experiments with skill/tool.3. User eventually uses skill/tool to

learn another skill/tool.4. User experiences pleasure and

starts process all over again, chaining Feedback Loops together.

Page 40: Iterative Development

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.

Page 41: Iterative Development
Page 42: Iterative Development

When Feedback Loops go

wrong

ProblemPress the X button

Play Tackle - Fail

Dive

I dive!

Dive Near Opponent

Play TackleCheck Player RatingGenerate Random Number

Tackle Success

I can tackle!

Dive Near Opponent

Play TackleCheck Player RatingGenerate Random Number

Broken Tackle

I missed!

Dive Near Opponent

Play TackleCheck Player RatingGenerate Random Number

Broken tackle ending in Injury

WTF!!

Page 43: Iterative Development

!Fun

1. User acquires skill/tool.2. User experiments with skill/tool.3. User is unable to use skill/tool to learn

another skill/tool.4. User believes their actions have been in

vain, and feel frustration or boredom.5. Catecholamines are released when we

discover something we have learned is incorrect – this hormone is responsible for anger and frustration, claustrophobia, panic attacks – !FUN.

Page 44: Iterative Development
Page 45: Iterative Development

Question

How could we fix it?

Page 46: Iterative Development

Example ProblemFlick the Stick

Tackle Fail

Player Stumbles

I can Stumble??

Flick near opponent

Check Player RatingGenerate Random NumberTrigger a hitstick tackle

Huge Hit Stick!

I can lay people out!

Flick near opponent

Check Player RatingGenerate Random NumberTrigger a stumble

Player Stumbles

I missed! WTF!

Example: Hit Stick

Page 47: Iterative Development

What’s really going onFlick 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 coverageGenerate Random Number

Success, Failure, normal tackles, hitsticks, injuries, fumbles, broken tackles, gang tackles

I don’t get it!Tackling is Random!This game Cheats!!

Page 48: Iterative Development

Proposed SolutionPress X from too far awayTackle Fail - Dive

Player does a dive that visually attempts to grab opponent

I can Dive for him! but I was too far away.

Dive from far away at OpponentCheck Player RatingCheck Range

Tackle with large breakout window

I caught his shoe lace, I was still too far away.

Dive nearer to opponent

Check Player RatingCheck Range

Tackle with a medium breakout window.

I dragged him down slowly

Dive very near opponent

Check Player RatingCheck Range

Play decent impact Tackle with tiny breakout window

I laid him OUT!

Dive very near opponentCheck Player RatingCheck Range

Play huge impact tackle with very small breakout and large fumble window (maybe an injury window)

I laid him Out!

100% deterministic tackle with clear feedback loop

Opponent presses X

Check Timing window

Broken tackle Animation

He broke loose, I was slow!

Opponent presses X

Check Timing window

Broken shoelace tackle Animation

I missed, I was slow!

Opponent presses X

Check Timing window

Fumble Animation

He FUMBLED! (shouldn’t have tried to break such a big hit)

Opponent presses X

Check Timing window

Failed breakout animation

He tried to break lose and failed!

Page 49: Iterative Development

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.

Page 50: Iterative Development

Agenda

1. Iterative Development Defined2. Feature/Sandbox Trap3. Accessibility4. Designing for Accessibility and

Iteration5. Building from Core

Page 51: Iterative Development

Systemantics*

“A complex system that works is invariably found to have evolved from a simple system that works.”

“A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over, beginning with a working simple system.”

*Gall, John. The Systems Bible: The Beginner's Guide to Systems Large and Small (Third Edition of SYSTEMANTICS), General Systemantics Press/Liberty, 2003

Page 52: Iterative Development

EA Football

Textbook example of a complex system (that isn’t even really a clearly defined system)

Years of legacy feature trap designs creating a complex sandbox of mechanics without deliberately connected closed systems Lacks a simple defined core anyone can play Lacks defined/deliberate depth

No clear learning progression No obvious starting point for accessibility

Lacks balance and iterative structure A new system to support run, breaks tackle, breaks catching etc..

Lacks clear and consistent feedback loops Too many features rely on “coverage” and random dice rolls (random

failure is not feedback) Too many legacy bugs covered up with legacy band-aids making

iteration and innovation almost impossible without months of patching up what it breaks. Player mirroring

Page 53: Iterative Development

Football Needs Core

The concept of a closed core system does not deliberately exist in the current game.

In design all systems should support core If they don’t then they don’t influence anything that

directly influences win conditions (and therefore has no purpose).

Return to core and build layers from there Football becomes easy on easy Accessible to anyone age 6-60 Left stick, 1 button = a core a 60 year old will “get”

Page 54: Iterative Development

Football Positional Core???

Line play example Guard Vs. Tackle Win Condition = Protect Vs.

Sack/Tackle Core System possibilities.

Block Vs. Pass Left/Right – Fighting game system? Power/Finesse – Fighting game system?

Page 55: Iterative Development

Where we want to be Simple FUN, Accessible core system FUN depth through clear stepped learning

progression, mastering systems that all directly or indirectly SUPPORT the CORE Clear feedback loops Risk/Reward based success variation No random numbers!

The ability to add or swap out systems without breaking other existing systems Closed loop design Modular design Modular AI

Wii, PS3, 360, PC – All 1 Engine.

Page 56: Iterative Development

How We Get There (Safely). Return to CORE football with a TINY team

Concept 2-3 people, Prototype 5-7 people Prove we can make fun/accessible core with minimal investment

Make a closed loop core system anyone can play Run Vs. Tackle Pass/Catch Vs. Sack/Block/Intercept

Construct an true “engine” A true testbed A play designer that JUST WORKS based on rail-tracks locomotion. Locomotion System with pathfinding and avoidance Take Pro-Tak to the next level, and have it function 100% in the testbed

No roll of dice features No coverage-based features Create deliberate layered progression and layered depth Ship an intermediate new IP football titles along the way, with

the eventual goal of having a true “football engine” for NCAA and Madden and any other football IP we can dream up.

Page 57: Iterative Development

What we need to start Small Team, 3 people Animation/Engineer/Designer

Football Playmaker (interface and technical plan) 2d Xs and Os (perhaps an eventual facebook and iPhone ap)

Could be used by football coaches to design plays for real football Modular - Could potentially be used to position teams of enemies for shooters based around

the concept of “pre” and “Post” action assignments and path finding Any number of characters

Each has a path, and a modular assignment while moving or standing at the end of the path.

Time-out default assignment (e.g. “chase ball”) Locomotion requirements

Railtracks Avoidance and Pathfinding

Core gameplay technical execution and gameplay design Run v. Tackle Pass v. Sack/Intercept

Technical design for bringing Pro-Tak into ANT testbed MMA interaction was already designed as the first steps to do this

Page 58: Iterative Development

What Comes Next Small Team, 7-12 people (Staffed based on

presenting the design pitch) Setup Run Vs. Tackle prototype in Testbed

1 – 6 players (2 vs. 5 tackle alley) Includes functional pro-tak defensive player switching logic Includes base pursuit path finding

Setup Pass Vs. Sack/Interception prototype in Testbed Build Playmaker and run plays with any number of players and

user-generated starting formations. Play CORE football in Testbed

Choose offensive formation and Passing or Running Plays Choose Defensive formation and Play Play Football Core System for Run/Pass with 2 (or more) players

Page 59: Iterative Development

The Iterative Development Model

Page 60: Iterative Development

Questions?