Game Development: Design

1
Game Development Design Programming

• Staffan BjörkNiklas Elmqvist
• Combined Lecture Game Design Simulation
  Engines (Wednesday, December 7th)

2
Outline

• Game Development Process
• Designer-oriented and Programmer-oriented
• Development Teams
• Roles
• Design vs. Programming
• (Game Programming from a Designers POV)
• Programmers Design-Driven Control
• Designers Clarity of Gameplay Design

3
Game Development Process

• Gold Chapter 9
• Fullerton et al Chapter 13

4
One Model for Stages of Development
Concept phase

• Design-oriented
• Width representing freedom in design space
• Weak link to programming
• Shows approximately how finished code should be
• But entire code section CAN be replaced if well
  planned development process

Pre-production phase
Production phase
QA phase
Maintenance
5
S/W Engineering Process

• Programmer-oriented
• Many different kinds of programming processes
• Example Waterfall model
• Linear development model
• Can add iterations
• Observation Game development processes
• Lightweight
• Tolerant to change
• High hacker factor

Requirements
Analysis
Design
Implementation
Testing
time
6
S/W Engineering Process (2)

• Typical Each iteration ends in a milestone
• Important subset of finished game
• Characterized by important features
• External milestones high-level (weeks and
  months)
• Internal milestones low- and medium-level (days
  and weeks)

Milestone 1
Milestone 2
Milestone 3
IM1
IM2
IM3
IM4
IM5
IM6
time
7
Iterative model for design

• Iterative Design
• Setting an initial goal
• Stepwise developing and refining
• Evaluating against initial design goal
• Can be either code-oriented or gameplay-oriented
• Can switch between the two when new cycle is
  started

Identify Gameplay / Technical Requirements
Playtest / Evaluate
Formalize Ideas / Create Specification
Test Ideas / Implement
8
Conceptual Models

• The conceptual model (in S/W Eng) is a model of
  the domain-specific concepts of our application
  (game!) in the analysis phase
• The domain-specific concepts are decided upon by
  the designers!
• Bridge between game design and programming
• This is a potential problem
• Analysis cannot begin before designers started
  designing
• Designers and programmers must(?) work together

Major problem Game design has no such concept
language!
9
Example Conceptual Model

1
1
Player
Tournament
1
1
Car

1
1
Track
Human
Computer
Event
1
1
4
1
1
1
1
Wheel
Engine


Checkpoint
Results

Simple Car Driving Game
Goal
Qualification
Major problem This is a static model!
10
Risk Management (Programming)

• Some programming tasks are more difficult than
  others
• Tasks should be prioritized w.r.t risk
• Difficult and/or time-consuming tasks
• Use prototypes to test technical concepts
• Give designers an idea of what is possible (and
  what is not!)
• Early iterations complex and difficult tasks
• Late iterations bells whistles

11
Risk Management (Game Design)

• Some design tasks are more difficult than others
• Graphic design, sound design, level design
• All game design is critical
• Tasks can rarely be prioritized w.r.t risk
• Exact design requirements impossible
• Iterations are rarely incremental improvements,
  but rather radical changes
• Not so in the balancing phase

12
Game Development Teams

• Gold Chapter 10
• Fullerton et al Chapter 12

13
Game Development Teams

• Trinity of overall roles in a game development
  team

Artists
Programmers
Designers
14
Programming Roles

• Lead Programmer
• Technology Programmer
• Tools Programmer
• Architect
• Low-level Programmer
• ....

15
Designer Roles

• Producer/Game Designer
• Lead Game Designer
• Game Designer
• Level Designer

16
Artist Roles

• Concept artists (2D and 3D)
• 2D artist (textures, UI design, graphical look)
• 3D modeller
• Animator
• Character animator/modeller
• Technical artist
• Liaison between art and programming teams
• FMV/Cutscene artist

17
Development Team Model

• Golds diagram of ideal involvement of teams

Designers
Programmers
Artists
QA
Implement
Design
Test
project start
project end
18
Development Team Model (2)

• Is Golds model a good model?
• Nogame development needs a holistic approach
  where all groups are present at all stages of
  development
• Examples
• Designers design document is revised at all
  stages of development
• Programmers prototypes, implementation,
  bugfixing
• Artists concept art, production art

19
Development Team Model

• Our diagram of ideal involvement of teams

Programmers
Designers
Artists
Usability
Implement
Design
Test
project start
project end
20
Development Teams External Interfaces

• Producer publisher, financial department, CEOs
  of developer, subcontractors
• Marketing audience, journalists
• Distributors Products, services
• IP holders companies, actors, authors, artists
• Players - expert players, novice players, fan
  communities
• Relatives
• Interest organizations
• Legislators

21
Game Design vs Programming
22
Game Design vs. Programming

• In all engineering disciplines, there is a
  constant battle between form and function
• Engineers focus on function
• Designers focus on form
• Problem form and function are often conflicting
• Game designer focus on gameplay (interaction
  function?)
• Example Building construction
• Architects design the appearance and style of a
  building (ideas, creativity, theme, design)
• Building engineers (try to) realize the ideas of
  the architects (mathematics, mechanics, building
  laws, technology, and conventions)
• Sometimes (read often!) this is impossible!

23
Game Design vs Programming

• Another aspect lies in what kind of problems
  designers and engineer face
• Engineers predefined problems that can be
  evaluated without full-scale experiments
• Designers loosely-defined problems that can not
  be evaluated reliably without full-scale
  experiments
• This is of course a generalization
• In an ideal world the designers could solve their
  problem first and hand over their solution as a
  problem to engineers
• We do not live in a perfect world
• Intended interaction and enjoyment is hard to
  reliably or meaningfully quantify at a level
  which allows explicit design

24
Game Design vs Programming

• The same conflict exists also in game development
• Game designers game concept and structure (oh
  look, here are the MS Word monkeys again...)
• Game programmers implementation of game (yech,
  and here come the keyboard cowboys...)
• Clearly, this conflict is counter-productive
• We need to bridge the gap between designers and
  programmers
• Speak the same language
• Understand the challenges of each respective role

25
Closing the Gap

• In the following slides we will look at how to
  bridge the cultural divide between designers
  and programmers
• Programmers Design-Driven Control
• Techniques for giving designers the control they
  need to be able to do their job
• Designers Clarity of Gameplay Design
• Techniques for identifying what parts of
  programming are re-usable, extendable, or simply
  experiments

26
Programmers Design-Driven Control

• Gold Chapter 8

27
Introduction

• Programmers want to bridge the gap between design
  and programming
• We need to provide designers (and artists) with
  the appropriate
• Content editors
• Level editor, game object editor, AI editor, etc
• Scripting language
• Text-based tools programming or GUI

28
Why a Scripting Language?

• Why do we need a scripting language?
• It seems an unnecessary cost in terms of
  development time
• Why not provide designers with a C compiler and
  some library functions specific to our game?
• Scripting languages are useful for a number of
  reasons
• They allow for rapid development of complex
  in-game behavior
• They raise the abstraction level to game concepts
• They allow us to decouple behavior from game code
• No more designers asking for more more more
• No responsibility for game design concepts!

29
Scripting Languages

• Problem Not all designers have a programming
  background
• (All in the game design course fortunately!)
• Can be difficult with very complex abstract
  programming concepts
• Solution Use a simple and standard scripting
  language in your game engine
• Preferably allow for automatic script writing
  through some kind of visual programming
• Avoid changing language often

30
What is a Simple Language?

• What a simple scripting language is can be
  difficult for a programmer (like us) to answer
• Here are a few guidelines
• No pointers
• No concurrency
• No complex programming constructs
• Should have automatic garbage collection
• Other possible(?) approaches
• Visual programming language (Lego Mindstorms, EON
  Studio)
• Programming-by-example

31
Designers Clarity of Gameplay Design
32
First of all

• Programmers are designers!
• initiate change in man-made things
• Programmers design code
• This can be done in many ways, and the difference
  between different solutions cannot always be
  judged quantitatively
• Programmers often design interaction
• Focusing on function means focusing on how things
  will be used by people interaction
• This has been present in design before but first
  became apparent and explicit when complex
  computer applications were created
• Especially for leisure and voluntary activities
  which games are an example of!

33
Introduction

• Unbalanced fields
• Game design at an disadvantage to help
  programmers due to age of discipline
• As can be seen from the lack of reference to a
  chapter on the heading slide
• Game programmers can rely on general programming
  knowledge to help bridge the divide
• Game designers cannot rely on general design
  knowledge to help bridge the divide
• Primarily since game design is not strongly
  connected to design in general yet! If it ever
  will be!
• Levels of design
• Level designers etc. can be helped by scripting
  languages
• But what should a scripting language support?
  Needs to be decided by the game designer!?!
• But can be very helpful for a game designer to
  figure out the gameplay!

34
Clarity of Gameplay Design

• Main Idea
• Make as clear as possible the overall intended
  goal with the game design process
• So that changes of plan cause as little code as
  possible to be abandoned
• To make clear what programming tasks are
  experimental
• Effect Game designers must have a basic
  technical understanding of programming
• Make the programming as tightly coupled to the
  gameplay design as possible
• Making full use of the medium / design material
• Make use of the potential interactivity of
  computers
• Make programmers more equal design partners in
  the process
• Assuming that gameplay is wanted more than
  narrativity

35
Suggested Approach

• Describe core gameplay in terms as close as
  possible to what programmers will code
• Enable focusing on those details
• Enable the creation of a skeleton system (core
  game engine) that supports this gameplay but can
  be expanded with other functions
• Describe continuously what is finalized and what
  is not finalized regarding gameplay
• Allow programmers to be aware of what parts will
  be included in final version and therefore can be
  refined
• Allow programmers to suggest how non-finalized
  areas can be explored through programming
  experiments

36
Suggested Method 1

• Code experiments
• Will Wrights approach to game design
• Many small programs to explore different aspects
  of gameplay (simulations)
• Take interesting parts and make fewer larger
  programs
• Iterate until finalized gameplay emerges together
  with programs

37
Suggested Method 2

• Provide programmers with descriptions of intended
  gameplay on level which is as concrete as
  possible
• Design Document
• Game Design Patterns, Game Mechanics, Formal
  Abstract Design Tools, etc.
• More about this in the game project course

38
Summary

• Intrinsic conflicts between game programming and
  game design
• In some ways easier than design and engineering
• Game designers focus on interaction (related to
  function)
• In other ways harder than design and engineering
• Evaluation is dependent on users rather than
  designers
• We have presented two approaches to mitigate the
  intrinsic conflict
• Design-driven control programmers giving
  designers the tools they need to do their job
• Clarity of gameplay design designers
  externalizing the game design process for
  empowering programmers

39
But wait, there is more!
40
Simulation Engines Info

• Viktiga deadlines
• Projektposter 13 december kl 12.00
• A1, PDF, inte för mycket färg!
• Presentation 15 december kl 10.00-13.00
• Obligatorisk närvaro!
• Rapport (personlig) 9 januari (2006) kl 24.00
• Personlig uppsats och dagbok
• Rapport (gemensam) 9 januari (2006) kl 24.00
• Grupprapport ca 10-20 sidor

41
Game Design Info 1/2

• Assignment 4
• Individual
• Task
• Describe a gameplay style by defining it, giving
  game examples that have the style, and guidelines
  for designing such game
• Not an established game genre!
• Report
• Make use of concepts in book (especially chapters
  2-5) to strengthen your description
• Discuss how chapters 6-11 should be changed or
  should focus for the selected gameplay style
• Use the Structural Framework when useful
• Check with Staffan that gameplay style is ok!
• Supervision 08.00-10.00 13.00-15.00 Thursday
• And more after that

42
Game Design Info 2/2

• About presentation next week
• 105 minutes for each
• 08.00
• Make powerpoint presentation
• Describe genre, narrative, and theme
• Describe core gameplay
• Note how the game concept differs from existing
  games
• Mail Staffan presentation on Monday if you are
  not bringing your own laptop
• Supervision 08.00-10.00 13.00-15.00 Thursday
• Supervision available next week also