1. Game Development Tools, Techniques, and Tips

2. Getting Started
A game must be planned in the same way as any other software project.
Typically, this means someone must:
Formulate a concept for the game.
Flush out this concept into requirements.
Architect design to meet requirements.
Implement software embodies this design.
Test and refine software into working game.

3. Getting Started: What To Do, How To Do It
Game Logic Tools
Content Creation and Management Tools
Game Logic
Game Content and Assets
Game Engine
Programming and Support SDKs

4. Getting Started: What To Do, How To Do It
Programming or scripting?
If starting from scratch, the game will likely need to be programmed using a traditional programming language.
If using an engine, you may be able to program with a traditional language, or you may have to use scripting instead. Depending on the engine!
While script writing is very much like programming, it is not done using traditional languages, which might not be what is wanted for a programming course.

5. Getting Started: What To Do, How To Do It
2D or 3D?
2D game development is typically easier, both in terms of programming or scripting, but also in terms of content and asset management.
3D game development, conversely, tends to be more challenging, but more interesting.
Depending on your language and tool of choice, however, you might be forced into one of these options or the other.

6. Getting Started: What To Do, How To Do It
Screen shots from two games developed at Western, The Misadventures of State-Man (2D, left) and Smashocosm Tournament (3D, right). Both games received perfect grades, one for gameplay and the other for technical elements.

7. Development Stages Develop original concept Shop to publishers
Create schedule (12-24 months)
Deliver work as milestones (work products or completed activity)
React to customer evaluation

8. Game Development is Unique
Must be willing to rip out features that don’t work
Designers may create things customer never heard of before
May require more research and experimentation than other software development
Often more ideas than time to implement

9. Development Team Size In the 1980’s might be single developer
Most teams today have people
Programming in now a smaller part of the complete project than before (need good software engineering and media design work)

10. Example 1988
3 programmers
1 part-time artist
1 tester

11. Example 1995 6 programmers 1 artist 2 level designers 1 sound designer
Contract musicians

12. Example 2002 2 producers 4 programmers 2 game designers
1 2D and texture artist
3 level designers
1 audio designer
4 animators
QA lead and testers

13. Development Milestones: Development Timeline
Here are some example development periods for different platforms:
4-6 months for a high-end mobile game
18-24 months for an original console game
10-14 months for a license / port
16-36 months for an original PC Game

14. Budgeting Personnel costs Developer/Contractor payments
Salary x time x involvement %
Developer/Contractor payments
Equipment & software
Supplies
Travel & meals
Shipments

15. Kicking Off Tasks - Audio
Sound list
Music specification
Story text
Voice-over script
Creation of sounds
Creation or licensing of music
Recording of voice-overs

16. Quality Assurance Test plan The QA database QA – the view from inside
The QA-producer relationship
Post mortem

17. What are Game Objects?
Anything that has a representation in the game world
Characters, props, vehicles, missiles, cameras, trigger volumes, lights, etc.
Need for a standard ontology
Clarity
Uniformity
Feature, staff and tool mobility
Code reuse
Maintenance
E.g. use of modularity/inheritance reduces duplication
As a rule of thumb, if it has a position it can be a game object, although not all game objects have a position.
Most games try to devise a universal representation for their objects.

18. Components vs Hierarchies
GameObject
GameObject * *
Shift of ontology from a semantic network (nested sets of functionality) to flat aggregation of functionality.
Prop
Attribute<T>
Behaviour

19. Hulk:UD Object Model
Let’s look at an example. This is the object model from the Hulk: Ultimate Destruction game, which predates the game object model.
The two main classes are the character class and the prop class. The character class had to cater for a number of types of characters: Hulk, soldiers, Hulkbusters, boss characters etc. Therefore, it was a superset of the functionality required by all of them, e.g. it contained the AI and cloud code, which wasn’t required by Hulk. As another example, a character could be held or hold another character, prop or a civilian. These 3 cases required different code. Consequently, the file CCharacter.cpp had 11,000 lines of code and the memory footprint of a character object was over 20k. And that was on the last gen hardware.
Props were slightly lighter and had different functionality, although they replicated a lot of the code and data. When it came to implementing helicopters, it proved hard to bend either the Character class or the prop class to fit the requirements, so a hybrid was made, by creating both instances and linking one to another, the so called character props.
When it came to fleshing out the ambient system, the characters were deemed too expensive to use for pedestrians and cows. So the pedestrians were written from the ground up, and cows were implemented as animated props. Both had their own state machines and AI.

20. Prototype Game Objects
Alex
PhysicsBehaviour
TouchBehaviour
CharacterIntentionBehaviour
MotionTreeBehaviour
CollisionActionBehaviour
PuppetBehaviour
CharacterMotionBehaviour
MotionStateBehaviour
RagdollBehaviour
CharacterSolverBehaviour
HealthBehaviour
RenderBehaviour
SensesInfoBehaviour
HitReactionBehaviour
GrabSelectionBehaviour
GrabbableBehaviour
TargetableBehaviour
AudioEmitterBehaviour
FightVariablesBehaviour
ThreatReceiverBehaviour
Helicopter
PhysicsBehaviour
TouchBehaviour
CharacterIntentionBehaviour
MotionTreeBehaviour
CollisionActionBehaviour
PuppetBehaviour
CharacterSolverBehaviour
HealthBehaviour
RenderBehaviour
HitReactionBehaviour
GrabbableBehaviour
GrabBehavior
TargetableBehaviour
AudioEmitterBehaviour
FightVariablesBehaviour
EmotionalStateBehaviour
ThreatReceiverBehaviour
FEDisplayBehaviour
Pedestrian(HLOD)
PhysicsBehaviour
CharacterIntentionBehaviour
MotionTreeBehaviour
PuppetBehaviour
HealthBehaviour
RenderBehaviour
GrabbableBehaviour
GrabBehaviour
TargetableBehaviour
AudioEmitterBehaviour
EmotionalStateBehaviour
FEDisplayBehaviour
CharacterPedBehaviour
Pedestrian(LLOD)
SensesInfoBehaviour
TargetableBehaviour
PedBehaviour
Now let’s compare it to the object model in the Prototype game. Here, all entities are instances of the same class. However, every instance is taylor-made for its specific role. It has only the behaviours it needs.
The main character doesn’t have any AI or cloud data.
The helicopter doesn’t have the character motion, ragdoll or grabbing code.
HLOD pedestrians are similar to Alex, but have fewer behaviours or use their lighter versions.
LLOD pedestrians have only three behaviours!
As you can see, instead of a rigid hierarchy of classes, onto which every new type of entity has to be more or less forcefully grafted, we have a flexible pick’n’mix approach, where every object can be made into exactly what it needs to be, without incurring much overhead.
Ground spike example.

21. An attribute or not an attribute?
Attribute if
accessed by more than one behaviour, or
accessed by external code
Otherwise a private member of the behaviour
If not sure, make it an attribute …
If you find yourself writing a lot of “Get” messages, consider using an attribute instead.
If you are worried that something will corrupt it when it’s a public attribute, remember that you will always get a message if that happens, in which case you can either deal with it, or assert.
Going forward we want to shift most if not all of data to attributes and leave behaviours stateless.

22. Game Object Update
GameObject::OnUpdate(pass, delta) for b in behaviours b.OnUpdate(pass, delta)
OnUpdate() and OnMessage() are the only two entry points to a behaviour.
Finally, to complete the picture, every game object and its behaviours receive update passes.
This is where regular processing is done.

23. HealthBehaviour Example
void HealthBehaviour::OnMessage(Message* m) {
switch (m.type)
case APPLY_DAMAGE:
Attribute<float>* healthAttr = GetAttribute(HEALTH_KEY);
healthAttr->value -= m.damage;
if (healthAttr->value < 0.f)
mGameObject->SetLogicState(DEAD);
break;
case ATTR_UPDATED:
if (m.key == HEALTH_KEY) }
There is no OnUpdate()

24. Interface creating the connection

25. Key Questions
■ How do game interfaces relate to player-centered design?
■ What are the components of game interfaces?
■ What is the difference between a manual and visual interface?
■ What is the difference between a passive and an active interface?
■ Why is usability important in game interface design?

26. Player-Centered Design
What’s wrong with this picture?

27. Interface & Game Features
Gameplay
Story
Character
Audio
World
Platform
Genre

28. Interface Types Manual (Physical)
Bass Fishing
Samba di Amigo
Dance Dance Revolution

29. Interface Types Visual Active
Puzzle Pirates
(radial/pie menu)
I Was an Atomic Mutant
(main menu)

30. Interface Types Visual Passive
True Crime: Streets of LA
(HUD = heads-up display)

31. Interface Types Visual Styles
Split-Screen
(Adventures of Fatman)
Whole Screen
(Myst III: Exile)
Invisible
(Black & White:
Creature Isle)

32. Visual Interface Components Score
Cyclone
Super Collapse

33. Visual Interface Components Lives & Power
Super Mario Sunshine
(Lives)
Tour de France
(Power)

34. Visual Interface Components Map
Age of Empires II:
The Age of Kings
Age of Mythology:
The Titans

35. Visual Interface Components Character
Character creation & management and character inventory interfaces
from The Temple of Elemental Evil

36. Visual Interface Components Start Screen
Crazy Bunker

37. Saving the Game
Quick-save
Auto-save
Save to slot (or file)
“Save-game” debate

38. Guidelines for a Great Interface
Be consistent
Enable shortcuts
Provide feedback
Offer defined tasks
Permit easy reversal of actions
Allow for player control
Keep it simple
Make it customizable
Include a context-sensitive pointer
Implement different modes
Use established conventions

39. Define A Color Scheme Color is a very important part of an interface.
What color is your game? This is a good question to answer early.
Anyone who looks at your interface should be able to see at a glance the color scheme of the entire game.

40. 3D Solutions & Challenges
3D interfaces can be very compelling and the idea of creating a 3D interface seems really cool. 3D interfaces can also be very expensive and time-consuming.
Making big changes to a 3D interface can be more difficult than making changes to a 2D interface.

41. Creating GUI Elements
Generally, we provide the player with a Graphical User Interface for the player to interact with the program. The menu we employ at the start-up of a game, change the setup, or quit – these screens are all examples of GUIs.

42. Know Your User Can we make any generalization about gamers?
Technical level?
Gender?
Other?

43. Know Your User's Tasks Tasks will vary per game
For example, what are the tasks:
in a puzzle game?
in a RTS?
in an MMO?
Multi-player games are interesting, as they combine aspects of instant messaging with other gameplay aspects
Communication is often a necessary task

44. Game
Audio Prototyping

45. Game Audio Overview
Like film audio, game audio is comprised of speech, sound effects and music
However, unlike film audio, the audio is interactive and must respond to changes in gameplay

46. Old-Gen Game Audio Workflow
Conventional methods before the current generation of game consoles (pre-2007) have required recompilation and game coder involvement to hear results which is typically slow:
Create
30 mins
Compile
5-30 mins
Run Game
3 mins
Locate
2-5 mins
Test
5 mins

47. Next-Gen Audio Prototyping
Allow sound designers to create their procedural sound designs in real-time while the game is running
Middleware solutions such as Wwise allow real-time tweaking of parameters, however only for existing patches and basic synthesis unless plugins are used
Use of Kismet within Unreal allows for some scripting

48. Process
What do you need to do to get your audio into the game? Over-prepare for the worst
What tools and resources are you going to use and what software will support your creative design? Work well with your coder & producer
A good process can be found by making all the right mistakes once and taking risks - exciting!
Audio is always last, so be prepared for feature drop, no money, no time & no love :)

49. Definitions Sound: compression waves transmitted through a medium
Wave: cycle of compression and rarefaction
Amplitude: measure of sound wave pressure
Coming soon: cool stuff

50. Common Frequency Ranges
Human Hearing: 20Hz – 20kHz
Human Voice: 90 – 300 Hz
Middle C: 261 Hz

51. Digital Sound A “unit” of digital sound is called a sample
The sampling rate is the number of samples taken per second
Bit depth: size of sound sample data

52. When you’re Project Lead:
Create an audio asset list
“How many sounds can this make?”
“How often will we hear this?”
“How much music can/should we use?”
Excel spreadsheets are commonly used

53. Sound Design Critical is interactive audio component
Sound when event occurs (gunshot when trigger pulled, dialog when character spoken to, …)
Well done, sounds great. Poorly done, ruin all.
Need to avoid repetition
One footstep for 20+ hours of play annoying
Need 6-20 (depending upon budget)
Dynamics can help (pitch, volume, stereo…)
Mix pre-existing sounds with own sounds
Provides “custom” identity for game

54. Open Sound Control (OSC)
OSC is open-source software that allows communication between the game and PD
OSC is included in PD extended and just requires the addition of several C++ modules into the game engine
Access to the game events while the game is running

55. Audiomulch
Independent audio processing tool that is good for granulation
Doesn't support OSC but can receive MIDI control information from PD server
Easy to use and quick to prototype real-time adaptive musical ideas

56. Audio Team Briefly, allow to see some roles
Book has details
Production both science (tech) and art
Three teams:
Music Team
Sound Design Team
Dialog Team

57. Music Team Composer Write custom music (writing, recording, mixing)
Contracted per-project basis
With larger budgets, 1 person will have assistants

58. Music Team Recording Engineer
Enables production of sound through mechanical means
Gets best sounds out of each component
Often work out of home
May often be a sound designer (coming next)

59. Sound Design Team Audio Director/Manager Sound Designer
Manage sound design teams
Keep track of resources and schedules
Execute vision of game producer on sound and dialog
Sound Designer
Bring life-like (and beyond life) sound to game
Critical member, as audio has more capability and more importance

60. Sound Design Team Implementer
Work with production tools to attach sounds to events, characters, etc.
“Level designers” of the audio department
Not too common (may often be “just” a programmer with no audio training), but increasingly more common

61. Dialog Team Voice Actors Dialog Editor
Provide voice for characters, animations, cut-scenes
Unionized (better but expensive) or non-unionized (cheaper, but less expensive)
Dialog Editor
Organize files created by voice actors
Master files, check for errors and submit assets to audio director
Often tedious, but critical

62. Spatialized Audio Making audio provide physical location clues
Mono – one channel, no chance for spatialization
Stereo – two channels, left and right, like the ear works
Different volumes create illusion of sounds in space
Gradual changes give illusion of “moving”
Surround sound – 5 main, 1 subwoofer
Usually, dialog center, music left and right and specialized sound effects behind
Environment can often affect
Bounce off walls, objects – door open and in next room?
Material matters (wood, metal, plastic)
Climate matters (temp, humidity)
Getting better (Creative Labs with Environmental eXtensions, EAX)

63. MP3 – ‘MP3' abbreviation of MPEG 1 audio layer 3
'MPEG' abbrev of 'Moving Picture Experts Group‘
1990, Video at about 1.5 Mbits/sec (1x CD-ROM)
Audio at about kbits/channel
MP3 differs in that it does not try to accurately reproduce PCM (waveform)
Instead, uses theory of 'perceptual coding‘
PCM attempts to capture a waveform 'as it is‘
MP3 attempts to capture it 'as it sounds'.