外教课010_1_Introduction

Introduction to Development game systems

7 lectures:

1. Game Development Basis
2. Game Architecture
3. Math, Geometry and Collisions
4. Rendering
5. Animation
6. AI and Pathfinding
7. Audio Programming, history of games

Overview of games software

Game system overview

Hardware

• many hardware
• support all is challenging

Game Engine

• game specific and not game specific code
• all code that is not game specific is game engine
• the graphics engine, physics engine, sound manager, network manager, pathfinding, …

Tools

• Maya, 3ds amx, Adobe Photoshop…

Third party frameworks

• OpenGL…

In this course

• focus on the game specific code
• learn some of the theory behind a game engine

Data structures

• improve performance

• memory fragmentation

  some data structures causes more

Array

• fixed size
• to make bigger, create a new and larger array and copy
• insertion and deletion will also do this
• in C++, the software will not warn if we try to access elements out of bounds

Alternatives to Array

• in C++, std::vector; in Java Vector or ArrayList; in C#, ArrayList
• hide all the problems of size increase/deletion/insertion
• it’s useful if we don’t know the exact size of the array

Linked lists

• common in game programming
• fast to add or remove elements, since no copying of other elements is required
• drawbacks
  • require more memory(pointers)
  • not stored consecutively, worse cache consistency
• single linked or double linked
• double linked lists require more memory, but faster if traverse the list backwards

Dictionaries

• one object usually have an associated unique ID number
• maps a set of keys(the ID numbers) to a set of elements
• accessing a random element based on a key is much faster

Queue

• need elements are always sorted, priority queue is good
• update the high priority, and lower the priority
• priority queues are useful for pathfinding

Other data structures

• ask spatial queries
• more efficient to store based on location
• hierarchical grids or other trees

Memory efficiency

• store flags(多个bool) more efficiency, bit packing
  • store several booleans in a single value
  • use bit masks to check
  • example
  • many languages have
  • use if you have several boolean flags in an object with lots of instances
  • but is error prone, compiler do not same check safety

Scripting

• game engine and game specific code is often written in a compiled language, C++. C#, Java
• compiling and building can take much time
• game designers can write some high level code for the game, be addressed using scripting

Scripting Languages

• more simple to use than fully-featured, compiled languages
• interpreted at runtime and therefore does not require any compilation
• Therefore the behavior of for example a character can be changed without having to recompile the whole game
• can often update existing scripts or write new scripts
• players can mod(ify) the game after release(无敌？)
• most important reason: the time between when we make a code change and when the results are
  seen in the game
• fast and easy to update scripts and see the effects
• depend on how the scripting engine works, sometimes need modify and reload while playing

Drawbacks

• Performance
  • usually not compiled
  • interpreted at runtime in the scripting engine
  • lower performance than in compiled, game specific code
• Tool support
  • supported by development tools(Eclipse…)
  • the tools are simple
• Error handling
  • since interpreted at runtime, no compiler tell you about errors in the code
  • tools(开发工具) are not as rigid(精确的) as a compiler
  • limited support for exception handling
  • most are dynamically typed(variables don’t have type), difficult to track down bugs
• Communicating with the game engine
  • must do if want to be useful
  • extensive interface to the compiled game code
  • if action not in interface, can’t do it

Popular scripting languages

Python

• object-oriented, interpreted
• exception handling

Lua

Object-oriented design in games

Object oriented design

• fit well to game development

Inheritance

• share some common variables, hit points…
• base class, sub class

Polymorphism(多态性)

• the ability to refer to an object by a reference to its base class rather than a reference to the true class
• if call a method for each object, they now decides what to do by running their subclass specific AI code

Multiple inheritance

• many languages do not allow inheritance from multiple class, but not C++
• should avoid multiple classes, example problem DOD(Diamond Of Death)

Drawback of inheritance

• Tight coupling
  • coupling means two classes know and depend
  • good for loose coupling, easy to change or replace class
  • if tight, dependent on each other, update or replace can cause unforeseen problems
  • Inheritance is the tightest
• Unclear flow of control
  • if inherit and override too much, difficult to see use which version
  • more difficult if overridden method call the parent version of the method
  • Small updates high up in the hierarchy can have large (unintended) effects on sub classes(子类)
• Not flexible enough
  • DOD

solve it by component systems

Component systems

• relies on the composition principle
• create one base class and attach components, not create separate classes
• component has some logic or functionality
• component is simply to be added or replaced to change functionality
• add or remove don’t need recompilation(can change during running)

Data-Driven Composition

• game entities are defined in separate data files
• change without recompile
• loose coupling

Drawbacks of Component systems

• difficult to debug
• difficult to use break points
• interaction between components use message passing system, but not high performance
• difficult to keep the code and data in sync in data-driven approach
• lead to difficulties in seeing how objects interact with other objects

When to use component systems

lots of entities

Design patterns

general solutions to specific problems that often occur in software development

Singleton

Object Factory

Observer

Composite

Development processes

Waterfall model

Summary