2017
Applying Systems Engineering Thinking
onto Game Development
2017
Why are we here today?
Why are we here today?
• Developing our careers
• Learning the best ways to build things
• Learn what to do in order to enter the contest (the
PDF forms)
2017
Introductory Material
Systems Engineering Best Practices
An interdisciplinary approach and means to enable the realization of successful systems
(INCOSE handbook)
5
Introduction to Agile (Scrum)
Role of SE in Agile Projects
6
April 9-10, 2016
Pre-Production
Monthly: Update the
plan (and the form)
adjust the prioritized
work to be done
Main Production
Game System Project Phases
Game System Development Lifecycle
Pre-Production
Pitch
First
Prototype
Concept
PreProduction
Design
Main Production
Implementation
“Game elements and
programming”
Game Development
Post-Production
Alpha
Test
Beta
Test
Game Testing
Deployment
Master
Mapping to Systems Engineering Best Practices Model
Successive Refinement
Project
Development
System
Design
System
Design
Unit
Integration &
Testing
System
Development
System
Testing
System
Testing
Project
Deployment
10
2017
Competition Requirements
Introduction to GameSIG
 Develop a playable
level of a game that’s
potentially
marketable
 Fill out the Game
Overview form
 Make a YouTube
video pitch for your
game. Be convincing –
this is your sales
pitch!
 Top 10 games do a
live presentation at
the event
This could
be you….
Our first winner, Axle
(Chapman University),
went on to get their
project funded on
Kickstarter and publish on
both Android and iOS.
13
Typical Timeline
Workshop ‘16
Training
Feb 2017
Mar 2017
Apr 2017
May 2017
June 2017
Prototype Game Basic Playable
Iterative
YouTube
Coffee
Game
Refinement
Demo
Concept and
Begin Asset
Submission
Pizza
Initial Design
Production
Design Review Asset Integration
Document
Playtesting Demonstrable
Updated Design Updated Plan
Game in
Development
Documents
Asset Integration Final Form
Plan
Prioritization
Updated
Implement
Development Plan Contingency Contingency Plans
Planning
Judging Criteria
1. Market potential of the game
a. Does the game have the potential to be turned
into a viable, marketable game?
b. Does the demonstrated level clearly illustrate the
game's potential?
c. Does the audiovisual content sufficiently
demonstrate the game's appeal?
Judging Criteria
2. Original Work
a. Is the work presented by the team original work
of theirs in the following categories?
□
□
□
Assets
Code
Concept
b. Did the team clearly disclose the use of assets
created by or owned by others?
c. The team must be mostly students
Judging Criteria
3. Playable Demo/Pitch
a. Did one of the team members actually play the
game during the presentation?
b. Was the team's presenter knowledgeable about
the game's features?
c. Was the "pitch" compelling and convincing?
d. Did the demonstration include at least one
playable level of the game?
Judging Criteria
4. Best Engineered Game
To be eligible for the Best Engineered Game
Award, teams must submit AT LEAST THREE
versions of the Game Overview form – early
in development, during development and
upon final submission
□ More is better
2017
Workshop
Team Establishment
The first step is to establish a team consisting skills,
passion, and team spirit to go for the challenge.
20
Team Establishment
• Members of a team can come from more than one school,
but note that you'll still need to select one "main" school –
the one where your faculty advisor is based.
• One person can be on more than one team.
Function
Name
School
Contact
Team Captain
Project Manager
Art Designer
IT Manager
Programmer 1
Programmer 2
Tester
Advisor
Consultant
21
Idea Establishment
 Understand the competition theme/objectives
and rules clearly
 Predict what impact will success have -- How will it be measured?
(What is success?)
 Define team’s goal (Objective) (e.g., What attractions does the
team intend to offer?)
 Determine the game system’s differentiators; capture the Core
Components of the system (Winning Strategy)
 Identify research required to design and build the system
 Identify sources of the references (e.g., the applicable books,
articles, and/or on-line resources)
 Identify runtime environment (e.g., tools, lab, materials, etc.)
 Draft early art work and create the promotion video
Note: Core Components are the primary functional areas of the target game system. Focus Points are detailed functional
breakdowns of a Core Component
22
Idea Establishment
Elevator Pitch for your Game system
short, clear description of the game: genre, theme and primary goal
e.g., “A side-scrolling shooter game where the enemies are
vegetables and you are a squirt bottle of ketchup."
One-Paragraph Summary of Gameplay and Objectives
What role does the player take on? What does the player do in the game? Are
there levels? A "boss" to beat at the end of a level? How does the player win?
Keep this short and focused – a single paragraph.
The summary of elements that you'd want to put on a Web site or on a physical box.
Show at a glance what makes the game interesting, fun and unique.
Core Component
Description
On video
CC #1
Description 1
Yes
CC #2
Description 2
Final
CC #3
Description 3
Yes
CC #4
Description 4
Final
Note: An elevator pitch is a short summary used to quickly and simply define a product or service and its value proposition
23
System Design (1)
 Define the system scope and associated
system boundary
 Identify the project risks, payoffs, constraints ,and assumptions
 What are the system requirements (Core Components and Focus
Points) ? Do the requirements cover both functional and
operational areas? Are the requirements reflecting the winning
strategy defined previously?
 Estimate the cost and budget of the team (Program Management :
how can the team stick to the budget?)
 Lay down a project schedule for building the needed team skills and
developing, integrating, and testing the system.
 How will progress be measured? What are the major check points
(milestones) to assess the progress?
 What tools, lab, materials, etc. are required for the entire
competition (divided by phase)?
24
System Design (2)
 Can the requirements be broken into groups
of functions?
 What is the plan for how these groups of
functions can be tested?
 If the system is going to be built on an existing system/products,
what are the system/products currently designed to do? What are
the limits of existing practice? What new capability can the team
add? How does the new capability help the team to win?
 What solution options may be appropriate? What option is
better/best? (analysis of alternatives, decision analysis & rationale)
 Can the defined requirements be traced back to the completion
rules and policy (traceability)? Any redundant or unnecessary
requirements?
25
Project Definition Example
1. Core Components
2. Focus Points
3. Task List
26
1. Core Components
 Define the most important components of
your software
• No more than ten
• High-level
 Be sure to cover all aspects
•
•
•
•
Client
Server
Gameplay
Engine
27
2. Focus Points
 For each Core Component, define a set of
specific functions that it must perform
• No more than ten
• Give each a short name
• Then describe exactly how it fits in to the big
picture
 Try to cover all possible functions
• You’ll know you’ve succeeded when you’re writing
a task list and everything has a Focus Point
28
3. Task List
 List every task that you think is required
• Break down into small pieces, ideally at most a
few days in length
 Tie back each task to a Focus Point
• If there isn’t one that fits, then add it
• If there’s a missing Core Component, add that, too
• Repeat the process until you have a complete list
 Plot out each Focus Point on a calendar
• No need to get too specific; this will change
29
System Design (sample)
• Project Metric helps the team manage their system
features, responsibility, and projected schedule.
• Feature breakdowns provide a
system-wide status
Nov
Core
Component
Game
Engine
Story Engine
Multiplayer
Focus
Point
Team
Member
World Editor
RC
Upgrade UV Map
Handler
AK
Text Renderer
MD
Story Editor
EH
Behavior Models
KL
Ten Story Lines
CU
Game Globals
OD
Comm Protocols
JS
Client-Server APIs
KC
Dec
Schedule
Jan
Feb
Mar
April
May
Show approximate dates below
30
System Development (1)
 How to pick the best/most workable ideas?
 Define User Interface (UI) and User Experience
(UX) flows. Define information that impacts
these flows?
 What information (Data) are stored by this system? What are the
outputs of this system? What are the inputs? Any outputs are fed
back into the system?
 What programming language and logic are used?
 How will progress be measured? How to verify and validate design?
 What trade studies are needed to establish the design?
31
User Interface Flow
“Back”
Button
Main
Menu
Monster Whack Button
Monster
Whack
Game
Game
Over
Test Plan (high-level approach)
 Ask yourself:
• What are the most important parts of the user
experience?
– Then document how you’ll make sure they work
• What are the most likely failure modes?
– Then document how you’ll trigger and debug them
• How can we test the game all the way through?
– Write a “how to play a level” outline
– Add shortcuts or cheats to the code, if needed
• Will anything be confusing to new users?
Form Details








Game Description
Target Platform
Target Game User (Audience)
One-paragraph summary of gameplay and
Objectives
Key Features
Game Art
Software Libraries and Packages
Third party and ready made assets
Conclusion
 By integrating the INCOSE System Engineering Guidance with the
IEEE Game Special Interest Group’s application, we reveal the
potential of creating real values for the participating teams in the
following areas:
•
•
•
•
•
•
•
Team: Better team organization and coordination
Idea: Effective requirement identification and selection
Design: Efficient Core Features determination and design
Development: Organized, clear, and traceable implementation
Testing: Focused and sensible evaluations
Deliver a well-thought-out game
Continue improvements to the team’s skills and capabilities
35
2017
Exercise
Exercise
 We will fill out a plan for the Monster Whack
Game - each table is a team
37
10 Min – Define Team Roles
 Define the team member roles at your table
 Who is the Scrum Master (facilitator of the team,
could be the Team Captain)
 Who is the Product Owner (sets priorities, technical
lead or Project Manager)
 Who are the Team Members (include User
Experience and other roles you think are important)
 Definition of Done – Everyone at the table has a
defined role on the team and it is written on the
form.
38
Team Establishment
• Members of a team can come from more than one school,
but note that you'll still need to select one "main" school –
the one where your faculty advisor is based.
• One person can be on more than one team.
Function
Name
School
Contact
Team Captain
Project Manager
Art Designer
IT Manager
Programmer 1
Programmer 2
Tester
Advisor
Consultant
39
Report Out
 One or two tables report their team roles.
 Any questions?
40
10 Min – Game Description
 Define a game description for Monster Whack
 Use sticky notes for individual ideas and then
talk them over as a team
 Definition of Done – A written description on
your form that is on the table
41
Report Out
 One or two tables report their game
descriptions.
 Any questions?
42
10 min – Define Target Platform
 Team members brainstorm what platform should be
used to create the Whack Mole Game
 Write the target platforms considered onto sticky
notes
 If trade studies will be done to select the target
platform include that on the stickies
 Definition of Done – Target platforms and trade
studies on sticky notes in priority order
43
Report Out
 One or two tables report their target platform.
 Any questions?
44
10 min – Define Target Game User
 Write the Target Game User onto sticky notes
and order them by most common to least
common
 Definition of Done – at least one sticky note
with a Game User Name is complete that the
team agrees is their target user.
45
Report Out
 One or two tables report their target game
user.
 Any questions?
46
10 min – Define Game Objectives
 Team members write a list of the game
objectives
 Definition of Done – Objectives written on the
form
47
Report Out
 One or two tables report their game
objectives.
 Any questions?
48
10 min – Define Key Features
 Make a list of the Game’s Key Features on
sticky notes
 Discuss and select the most important 5
features
 Definition of Done – The top 5 List of Features
is added to the form, others can be included
after those.
49
Report Out
 One or two tables report their key features.
 Any questions?
50
10 min – Define Game Art
 Sketch a user interface and concepts of the Art
to be used
 Definition of Done – On 8 ½ by 11 white paper
• Show a user interface layout
• Or list the user set of steps to play the game
• Include a description of the art planned to be
used, for example picture of a mole, a cloud, a
hammer, etc.; is it 3D, 2D, cartoonish, realistic, etc.
51
User Interface Flow
“Back”
Button
Main
Menu
Monster Whack Button
Monster
Whack
Game
Game
Over
Example Characters:
53
Example “World”:
54
Report Out
 One or two tables report their game art.
 Any questions?
55
10 min – Brainstorm
 Software Libraries and Packages
 Third party and ready made assets
 Definition of Done – Sticky notes of potential
libraries, packages, third party assets, ready
made assets to use or consider using in the
game
56
Report Out
 One or two tables report their software
libraries, software packages, ready made
assets, and/or third party software.
 Any questions?
57
Retrospective - Game
 Everyone write on their sticky notes:
• Of all the game plans what looked like a
interesting approach, caught your attention,
seemed cool?
• Of all the game plans what idea or ideas seemed
unlikely or hard to do, perhaps not cool?
 Ask for a few to share their stickys with the
room
 Collect these stickys
58
Retrospective - Planning
 Everyone write on their sticky notes:
• What worked well planning as a team
• What could be improved with the planning as a
team (didn’t work well)
 Ask for some to share their stickys to the room
 Collect these stickys
59
Retrospective - Workshop
 Everyone write on their sticky notes:
• What worked well with this workshop
• What could be improved with this workshop
(didn’t work well)
 Collect these stickys
60
Conclusion
 Assemble your team for a Video Game
development
 Start with a planning session similar to this
where the initial concepts are talked through
and written down in the form as seen on the
next chart.
61
62
Best Engineered Game - New Form Content
63
Best Engineered Game
 A new award in addition to the Game Award.
 Need at least three or more forms to show
how your game developed and changed over
the months between now and the final
submission
64
Next Steps
• Contact [email protected] for a list of
available Systems Engineering coaches and
mentors
• Recommend planning and updates occur monthly
• Recommend agile practices be used to prioritize
the list of tasks to get to a demonstrate-able
feature of the game at least monthly
References
•
•
•
•
•
•
•
•
•
•
•
•
http://www.danpontefract.com/wp-content/uploads/2014/04/goodbye_team.jpg
https://www.nintex.com/blog/wp-content/uploads/2015/11/SMC-Managing-Teams.jpeg
http://myfootpath.com/wp-content/uploads/2012/06/communications_degrees-480x280.jpg
http://www.guidanceshare.com/wiki/Application_Architecture_Guide_-_Chapter_9__Layers_and_Tiers
http://www.projectmanagementdocs.com/images/work-breakdown-structure-tree-view.gif
http://www.erights.org/talks/categories/categories.html
http://i.stack.imgur.com/2hdRj.png
https://cloudant.com/wp-content/uploads/cloudantBlog_foundbiteUML_d1.png
Honour, Eric. C. 2004. Understanding the Value of Systems Engineering. INCOSE International
Symposium. http://www.incose.org/secoe/0103/ValueSE-INCOSE04.pdf
INCOSE. 2011. INCOSE Systems Engineering Handbook. International Council on Systems
Engineering, v3.2.2. http://www.incose.org/ProductsPubs/products/sehandbook.aspx
ISO/IEC. 2008. 15288 Systems and software engineering — System life cycle processes. ISO
(International Organization for Standardization) and IEC (International Electrotechnical Commission).
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43564
Leffingwell, Dean. 2011. Agile Software Requirements, Lean Requirements Practices for Teams,
Programs, and the Enterprise. Pearson Education, Inc., Boston, MA.
http://deanleffingwell.com/book-agile-software-requirements/
66
Thanks To Members of the WG and












The Aerospace Corporation
Booz Allen Hamilton
Chapman University
Creativita Institute
Dassault Systemes
Gems Learning
International Council on Systems Engineering – Los Angeles Chapter
Northrop Grumman Corporation
Quicksilver Software, Inc.
SE Consulting
University of California Los Angeles
University of Southern California
67