Terminology and Miscellaneous about Game Development

1
Terminology and Miscellaneous about Game
Development

• Staffan Björk

2
Overview of the Lecture

• Course updates
• Terminology
• Miscellaneous about Game Development

3
Course Updates

• Pitch for representatives from the game industry
• ES51 13.00-15.00
• DICE Jonas Skantz, Joakim Lord
• Massive Entertainment Niklas Westberg
• Avalanche Studios Oskar Burman
• Muskedunder Interactive Magnus Alm
• No lecture on Thursday
• You get it today!
• Staffan away before lunch on Thursday, rebook
  supervision!

4
Terminology

• Staffan Björk

5
Terminology - General

• Consequent use essential
• Preferably externally documented
• Models and frameworks
• Common initial reference is sufficient
• May be feasible to mark used terms, e.g.
• in quotes
• in italics

6
Terminology game elements

• Definitions of games in gameplay design course
• Definitions in game design workshop book
• Structural framework
• Common concepts
• Do not need to be referenced
• i.e. you do not need a reference to dice

7
Terminology gameplay

• Genres
• well-known ok
• Otherwise exemplify
• Game Design Patterns ( 400 Rules Game
  Ontology)
• By Italics in text
• By brackets if not explicit
• Be critical when these are normative
• Be critical when these are unclear or ambiguous
• Game Mechanics
• Should only be used when
• Well-known
• No similar game design pattern exists

8
Terminology - Miscellaneous

• Terminology from several other areas may be
  relevant
• Programming models
• Movie industry
• Human-Computer Interaction
• What needs to be referenced?
• Not common knowledge

9
References
10
References why?

• Academic approach
• Enables backtracking of information
• Shows that one has done background research
• Can never be complete
• Does the argumentation for you

11
References - what sources to use?

• Types of sources
• Books, journals and refereed articles good
• Gamasutra in this category
• Conferences that accept on abstract questionable
• Course notes comparable to this category
• Popular press, web pages, personal communication
  even more questionable
• Course forum in this category
• This of course depend on access, reliability,
  authors credibility and how permanent the
  refereed material is

12
References - systems

• Several system
• ACM
• 34
• 34 Björk, S., and Holopainen, J. Patterns in
  Game Design. Charles River Media, December 2004.
  ISBN 1584503548.
• Harvard model
• (Björk 2004)
• Björk, S Holopainen, J 2004, Patterns in Game
  Design, Charles River Media.
• American Psychological Association (APA)
• (Björk, 2004)
• Björk, S. Holopainen, J. (2004). Patterns in
  Game Design. Boston, MA Charles River Media.
• Harvard or APA model recommended
• Easy to insert new references

13
References - Games

• Games not really references but examples
• Required information
• Name of game
• Name of publisher
• Release Year
• Preferred information
• Platform
• Game Designer

14
References - examples

• A ref har undersökt vilken ny funktionalitet
  användarna vill ha. Det visade sig att dom ville
  ha ett snabbare system.
• B ref undersökte också vad användarna inte
  tycker om. Dom tyckte inte om att systemet
  kraschade.
• C ref har observerat användarna utan att fråga
  dom om deras åsikter kring produkten. Det visade
  sig att dom inte tyckte om att systemet krashade
  men också att de inte behövde systemet.
• In this example it is difficult to judge what is
  the opinion of the writer and those referenced to

• De finns många sätt att undersöka hur en produkt
  kan förändras där användare involveras. T.ex. kan
  man fråga efter eftersökt funktionalitet ref
  till A B eller var som upplevs negativt ref
  till B. Dock kan direkta frågor ibland bara ge
  förslag till förändringar, för att undersöka vad
  användarna egentligen behöver kan observationer
  ref till C användas. Dock kan olika metoder
  naturligtvis leda till samma result, tex
  resultatet angående krascher ref till B C.
• In this example it is clear that the writer has
  analyzed the references is making a contribution
  through the comparison

15
Miscellaneous aboutGame Development

• Staffan Björk

16
Overview of the lecture

• Bits of software engineering
• But other courses do that
• A mix of noteworthy things and issues that
  hopefully will make game developing easier

17
Software Design
18
Software Design (1)

• Great software is more than just great code.
• First, a great design is needed, before the code
  can be written.
• - Michael Abrash

19
Software Design (2)

• A model is needed before coding
• The more complete the better
• Take the time to do it right
• Choose the right abstractions
• Tools and techniques
• Interfacing, APIs
• Design Patterns
• UML
• Rational Rose
• Naming
• Variables, methods, classes, etc
• Good naming good design

20
Software Design (3)

• Scope Restrictions
• Requirements are often missing
• Flexible but not too flexible
• Turn weaknesses into strengths
• clever level design

21
Design for more

• Even though its bad, code from prototypes is
  used
• Hard to forsee what might change
• but you can forsee change itself
• expect the unexpected
• Design for more
• Multiple enemies
• Multiplayer
• Multiple levels
• Etc...

22
Fix defects early!
requirements design
implementation testing
maintenance
23
Example

• Game developed for special platform
• Optimised graphics
• Hardware didnt support color depth
• Project scrapped

24
Implementing the design
25
Write maintainable code

• Maintain the code you write
• Refactoring ! Optimizing
• Minimize cutnpaste
• Once and only once
• As said before, naming
• Document the code
• Doxygen, JavaDoc, etc...
• Comments need maintenance too
• Update them along with the code

26
Try before you buy (1)

• Tricky algorithms mess things up
• AI
• Conversation engines
• Path finding
• Etc...
• Complicated and time consuming to write straight
  into the engine
• produces bad code that is hardto get rid of

27
Try before you buy (2)

• Create tweakable proof of concept prototypes
• Verify the results
• Separate testbed
• Different (simpler) platform
• Faster prototyping
• Faster testing and tweaking
• Write working and verified code into the engine
• Its clean!

28
Please, follow the script (1)

• Dont hardcode tweaking values
• Its horribly inflexible
• Recompiling is tedious
• Everybody must know the code
• Easy to inject defects
• Scripts allow for
• Simple updating
• Simple access

29
Please, follow the script (2)

• Simple stuff
• Level progression, unit attributes, state
  machines
• Advanced scripts
• AI, autonomous objects, story events
• Techniques
• Text files, Lua, SeeR, etc...

30
Optimizing
31
Warp 9 (optimizing) (1)

• In many applications, speed is not a concern
• In games it is, more often than not, the main
  concern

32
Warp 9 (optimizing) (2)

• Do not optimize to early
• readability decreases
• productivity will get hurt
• Dont optimize until the code is stable
• Make it work, then make it fast.

for(y 0 y lt the_worm-gtheight y ) r
buff-gtliney0 p1 py
the_worm-gtwidth for(x 0 x lt wi x )
r (q p1) r (q
p1) r (q p1) r (q
p1) r (q p1) r
(q p1) r (q p1) r
(q p1) ...
33
Warp 9 (optimizing) (3)

• Put your efforts where it counts
• Double the speed of a function that is used 5
  gives an increase of 5
• Make something that is used 80 only 6 faster
  and its already an 5 increase
• Its hard to guess whats slow and whats not

34
Warp 9 (optimizing) (4)

• Use a profiler

35
Warp 9 (optimizing) (4)

• Use a profiler

36
Warp 9 (optimizing) (4)

• Use a profiler

37
Testing code
38
Test new code (1)

• Code reviews
• Validate return values
• ASSERT, TRACE
• Error checking
• Keep backups!
• CVS, Subversion, etc.

39
Test new code (2)
--------------------------------------------------
------ Log file for Duga (duga_log.txt)
Version v0.1. Build 911. File created
2005-01-30 1244. --------------------------------
------------------------ Initializing
Duga. --------------------------------------------
------------ Initializing Allegro. Allegro
version Allegro 4.0.3, MinGW32.s Client OS
Windows XP Setting default graphics mode.
setting color depth (8) entering graphics mode
(640 x 480 x 8) (window) Installing
keyboard. Installing timers. Installing
mouse. Initialization done.

• Log long procedures
• Write to file...
• Use replays to test new or updated code

40
Test new code (3)

• Beware of Memory leaks
• Memory managers
• Stress test

41
Putting it all together
42
Automatic build process (1)

• Let the computer work
• More reliable
• Save time
• Risk reducing
• Faster
• Anyone can do it
• Not only compiling

43
Automatic build process (2)
Compiling
Testing
File harvest
Installation package
File processing
Notification
44
Lets see...
45
Lets see...

• Design for more
• Test concepts separately
• Script what can be scripted
• Maintain the code
• Dont optimize too early
• Test the code
• Automate the build process

46
The End

• Lets make some great games!