Design and Programming: The Best of Frenemies

Views:
 
Category: Entertainment
     
 

Presentation Description

Ben Sharples, Steve Thornton, Sperasoft

Comments

Presentation Transcript

Slide1:

DESIGN AND PROGRAMMING The Best of Frenemies Ben Sharples Technical Design Director Steve Thornton Lead Game Designer

WHO IS WHOM:

WHO IS WHOM Steve Thornton Lead Game Designer Ben Sharples Lead Technical Designer 8+ years experience 10+ shipped games Handheld/Console/PC Previous roles Game Director Lead Level Designer Assistant Lead Designer Senior Designer Games Designer Cool and fun, nice hair 10+ years experience 10+ shipped games Mobile/Handheld/Console/PC Previous roles Gameplay programmer Script Team Level Designer Technical Designer QA Technician Old and cranky, nearly bald

OVERVIEW:

OVERVIEW What is this talk about? Design are the high level vision holder and content driver of the game Programming make everything in the game actually work A game starts with design and ends with programming The friction between conceptual vision holders and technical implementers Resolving common conflicts and dispelling myths Finding ways to improve and encourage trust between the disciplines

OVERVIEW:

OVERVIEW Observations are based on AAA game development 1 Clarifications Observations are based on a “vision-led” hierarchy 2 We will eventually address hybrid roles 3 Problems identified are based on common trends 4

THE SINS:

THE SINS Design Sins (according to programming) Programming Sins (according to design) Don’t understand how things work Don’t consider the cost of requests Don’t provide clear instructions Aren’t reliable, change their mind No hard skills Exaggerating the cost of requests Letting personal agendas affect technical evaluations Creatively unambitious Don’t care about the game @

DEPARTMENT FOCUS:

DEPARTMENT FOCUS Design FLOW Programming MECHANISM

BAD SPEC:

Design must properly communicate their vision to the team, but… BAD SPEC What can go wrong ? Not identifying all required assets Not covering full feature flow Not considering variables outside the intended flow I thought it was obvious!

COMMON SENSE:

COMMON SENSE Why wouldn’t a non-designer use “common sense” to solve a problem themselves? Assumption is a risk Everyone has their own frame of reference Any detail not specified can be easily misinterpreted Designers often make the mistake of assuming the game world will behave like the real world for “free”.

PLAYING DEFENCE:

PLAYING DEFENCE Designers can become defensive under questioning Ideas can be very personal, making criticism feel personal Changing your requests after giving them feels like poor leadership How can a designer avoid becoming defensive? Learn to say “I didn’t think of that” and “I don’t know yet” Remember that the team will appreciate a lead who can adapt

DETAIL ORIENTATED:

DETAIL ORIENTATED Consider the programming perspective… Programmers are detail orientated by necessity – in their world a single detail that is missing or wrong can break everything Programming tasks are unpredictable Programmers worry something cannot be done When asked to estimate an intimidating task, programmers will play it safe to avoid looking bad Programmers can help the discussion process by polishing their own soft skills.

“THAT’S IMPOSSIBLE”:

“THAT’S IMPOSSIBLE” The truth? Anything is possible. They have deemed the cost to be “obviously” ridiculous It exceeds the current limitations of the chosen tech What does a programmer mean by “impossible”?

THE IMPOSSIBLE DREAM:

THE IMPOSSIBLE DREAM What should a designer do in the face of the impossible? Don’t try and pitch the “how” to experts Ask to actually hear the estimated cost Make clear the core goals of your request Find the key places where you can compromise Give the programming team time to research Make a prototype Assure your experts that you won’t make a decision without them!

Decision time:

Decision time Help programmers inform your decisions Sell the vision, the “why” with the “what” Avoid pressure to come to a decision “in the room” Give time to research and prototype Why do engineers fear “bad” decisions? They don’t want their time wasted They don’t want to spend their skills on something they don’t agree with They fear it will lead to stressful schedules or over-time What can designers do to reduce this fear? Be categorically opposed to over-time and crunch You are a team leader, do not allow people to work too hard for your goals

FEAR OF CHANGE:

FEAR OF CHANGE Why do designers change their mind? All creative tasks require iteration Feedback from higher in the hierarchy Requests from other departments How can designers limit the impact of changes Be sensitive to morale when passing on feedback Don’t judge the idea by the prototype assets Future Proof your ideas against the most likely changes DESIGNER PROGRAMMER

Hybrid Theory:

Hybrid Theory The most common “hybrid” role is designers working in the editor Generally designers only work on high level editor tasks, using tools exposed / created for them by programming Advantages Designers can iterate manually Design get to see the impact of their requests first-hand Improvements to relationship due to hard skill demonstration Technical can inspire the creative Disadvantages Sometimes a little information can be worse than no information Design do not always follow “best practice” when working in tech – No training Creates tool requests from design in addition to feature / asset requests New type of design support is needed – usually creates a tools team

Hybrid Theory:

Hybrid Theory It’s rare in AAA for programming to be directly involved in creative decisions, outside of suggesting alternatives and compromises to requests Some studios have a technical expert role between design and programming Advantages Acts as an ambassador between design and programming Can assist in future proofing, such as suggesting key balancing variables Disadvantages Being too close to the implementation cost to make objective decisions Technical tasks are time consuming, and require too much personal focus Risk of “bottle-necking” production

FIN:

FIN “Making a game combines everything that’s hard about building a bridge with everything that’s hard about composing an opera. Games are basically operas made out of bridges.” - Frank Lantz Director of the N.Y.U. Game Center and designer of the iPhone puzzle game, Drop7

authorStream Live Help