57
CSCE 552 Fall 2012 Language and Programming By Jijun Tang

CSCE 552 Fall 2012

  • Upload
    ginata

  • View
    39

  • Download
    2

Embed Size (px)

DESCRIPTION

CSCE 552 Fall 2012. Language and Programming. By Jijun Tang. Methodologies: Code and Fix. Unfortunately very common Little or no planning Always reacting to events Poor quality and unreliability of finished product “Crunch” time normal. Methodologies: Waterfall. - PowerPoint PPT Presentation

Citation preview

Page 1: CSCE 552 Fall 2012

CSCE 552 Fall 2012

Language and Programming

By Jijun Tang

Page 2: CSCE 552 Fall 2012

Methodologies: Code and Fix

Unfortunately very common Little or no planning Always reacting to events Poor quality and unreliability of finished

product “Crunch” time normal

Page 3: CSCE 552 Fall 2012

Methodologies: Waterfall

Very well-defined steps in development Lots of planning ahead of time Great for creating a detailed milestone

schedule Doesn't react well to changes Game development is too unpredictable

for this approach

Page 4: CSCE 552 Fall 2012

Methodologies: Iterative

Multiple development cycles during a single project Each delivering a new set of functionality Refinements are needed

The game could ship at any moment Allows for planning but also for changes

Page 5: CSCE 552 Fall 2012

Methodologies: Agile Methods

Deal with the unexpected Very short iterations: 2-3 weeks Iterate based on feedback of what was

learned so far Very good visibility of state of game Difficult for publishers or even developers

to adopt because it's relatively new

Page 6: CSCE 552 Fall 2012

Languages

C/C++ Java Script: Flash, Python, LISP, etc. C# XNA for PC and Xbox

Page 7: CSCE 552 Fall 2012

Lua Example

Page 8: CSCE 552 Fall 2012

MSTS Example

Page 9: CSCE 552 Fall 2012

Choose a Scripting Languages

Consider whether you need one at all What features do you need? What kind of performance do you need? What debugging facilities does the

language have? On what platforms does it need to run? What resources and expertise are

available?

Page 10: CSCE 552 Fall 2012

Programming Fundamentals

Page 11: CSCE 552 Fall 2012

Data Structures: Array

Elements are adjacent in memory (great cache consistency) Requires continuous memory space

They never grow or get reallocated Use dynamic incremental array concept GCC has a remalloc function

In C++ there's no check for going out of bounds Use vector if possible Keep in mind of checking boundaries

Inserting and deleting elements in the middle is expensive

Page 12: CSCE 552 Fall 2012

List

Very cheap to add/remove elements. Available in the STL (std::list) Every element is allocated separately,

not placed contiguously in memory Lots of little allocations Bad cache awareness, but can use arrays

to hold pre-allocated items Single/Double linked list

Page 13: CSCE 552 Fall 2012

Lists

Page 14: CSCE 552 Fall 2012

Dictionaries

Maps a set of keys to some data. std::map, std::hash, etc Very fast access to data Perfect for mapping IDs to pointers, or

resource handles to objects May waste space, need to design

comparison operators

Page 15: CSCE 552 Fall 2012

Hash Table

Page 16: CSCE 552 Fall 2012

Others

Stacks First in, last out std::stack adaptor in STL

Queues First in, first out std::deque Priority queue is useful in game to schedule

events

Page 17: CSCE 552 Fall 2012

Stack/Queue/Priority Queue

Page 18: CSCE 552 Fall 2012

Bit packing

Fold all necessary data into a smaller number of bits

Bool in C++ may use up to 4 bytes, thus is very expensive

Very useful for storing boolean flags: pack 32 in an integer

Possible to apply to numerical values if we can give up range or accuracy

Very low level trick Use shifts to handle the operation or use assembly Only use when absolutely necessary

Page 19: CSCE 552 Fall 2012

Bits

Page 20: CSCE 552 Fall 2012

Inheritance

Models “is-a” relationship Extends behavior of existing classes by

making minor changes Do not overuse, if possible, use component

systerm UML diagram representing inheritance

E ne m y B o s s Supe rD upe rB o s s

Page 21: CSCE 552 Fall 2012

Polymorphism

The ability to refer to an object through a reference (or pointer) of the type of a parent class

Key concept of object oriented design C++ implements it using virtual functions

Page 22: CSCE 552 Fall 2012

Multiple Inheritance

Allows a class to have more than one base class

Derived class adopts characteristics of all parent classes

Huge potential for problems (clashes, casting, dreaded diamond, etc)

Multiple inheritance of abstract interfaces is much less error prone (virtual inheritance)

Java has no multiple inheritance

Page 23: CSCE 552 Fall 2012

Dreaded Diamond

It is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C.

If a method in D calls a method defined in A (and does not override the method), and B and C have overridden that method differently, then from which class does it inherit: B, or C?

Page 24: CSCE 552 Fall 2012

Component Systems

Component system organization

G am e E nti ty

N am e = s w o r d

R e nde rC o m p C o ll is io nC o m p D am age C o m p P ic kupC o m p W ie ldC o m p

Page 25: CSCE 552 Fall 2012

Object Factory

Creates objects by name Pluggable factory allows for new object

types to be registered at runtime Extremely useful in game development

for passing messages, creating new objects, loading games, or instantiating new content after game ships

Page 26: CSCE 552 Fall 2012

Factory Pattern

Page 27: CSCE 552 Fall 2012

Simple Sample Factory - I

Page 28: CSCE 552 Fall 2012

Simple Sample Factory - II

Page 29: CSCE 552 Fall 2012

Singleton

Implements a single instance of a class with global point of creation and access

For example, GUI Don't overuse it!!!

Single to ns ta tic S in g le to n & G etI n s tan c e( ) ;/ / R eg u lar m em b er f u n c tio n s . . .

s ta tic S in g le to n u n iq u eI n s tan c e;

Page 30: CSCE 552 Fall 2012

Singleton Example

Page 31: CSCE 552 Fall 2012

Adapter

Convert the interface of a class into another interface clients expect.

Adapter lets classes work together that couldn't otherwise because of incompatible interfaces

Real interface

Page 32: CSCE 552 Fall 2012

Adapter Pattern

Page 33: CSCE 552 Fall 2012

Adapter Example - I

Page 34: CSCE 552 Fall 2012

Adapter Example - II

Page 35: CSCE 552 Fall 2012

Observer

Allows objects to be notified of specific events with minimal coupling to the source of the event

Two parts subject and observer

Page 36: CSCE 552 Fall 2012

Observer Pattern

Page 37: CSCE 552 Fall 2012

Composite

Allow a group of objects to be treated as a single object

Very useful for GUI elements, hierarchical objects, inventory systems, etc

Page 38: CSCE 552 Fall 2012

Composite Pattern

Page 39: CSCE 552 Fall 2012

Composite Pattern Example - I

Add many more inherited classes

Page 40: CSCE 552 Fall 2012

The Five StepDebugging Process

1. Reproduce the problem consistently2. Collect clues3. Pinpoint the error4. Repair the problem5. Test the solution

Page 41: CSCE 552 Fall 2012

Expert Debugging Tips

Question assumptions Minimize interactions and interference Minimize randomness Break complex calculations into steps Check boundary conditions, use assertions Disrupt parallel computations Exploit tools in the debugger (VC is good, purify) Check code that has recently changed Explain the bug to someone else Debug with a partner (A second pair of eyes) Take a break from the problem Get outside help (call people)

Page 42: CSCE 552 Fall 2012

Game Architecture

Page 43: CSCE 552 Fall 2012

Overall Architecture

The code for modern games is highly complex The Sims: 3 million lines of code Xbox HD DVD player: 4.7 million lines MS Train Simulator has 1GB installed, with only

10MB executable With code bases exceeding a million lines of

code, a well-defined architecture is essential

Page 44: CSCE 552 Fall 2012

Overall Architecture

Main structure Game-specific code Game-engine code

Both types of code are often split into modules, which can be static libraries, DLLs, or just subdirectories

Page 45: CSCE 552 Fall 2012

Overall Architecture

Architecture types Ad-hoc (everything accesses everything) Modular DAG (directed acyclic graph) Layered

Options for integrating tools into the architecture Separate code bases (if there's no need to share

functionality) Partial use of game-engine functionality Full integration

Page 46: CSCE 552 Fall 2012

Ad-hoc

Page 47: CSCE 552 Fall 2012

Modular

Page 48: CSCE 552 Fall 2012

DAG

Page 49: CSCE 552 Fall 2012

Layered

Page 50: CSCE 552 Fall 2012

Overview: Initialization/Shutdown

The initialization step prepares everything that is necessary to start a part of the game

The shutdown step undoes everything the initialization step did, but in reverse order

Page 51: CSCE 552 Fall 2012

Initialization/Shutdown

Resource Acquisition Is Initialization A useful rule to minimalize mismatch errors in the

initialization and shutdown steps Means that creating an object acquires and

initializes all the necessary resources, and destroying it destroys and shuts down all those resources

Optimizations Fast shutdown Warm reboot

Page 52: CSCE 552 Fall 2012

Overview:Main Game Loop

Games are driven by a game loop that performs a series of tasks every frame

Some games have separate loops for the front and the game itself

Other games have a unified main loop Must finish a loop within 0.017 second

Page 53: CSCE 552 Fall 2012

Tasks of Main Game Loop

Handling time Gathering player input Networking Simulation Collision detection and response Object updates Rendering Other miscellaneous tasks

Page 54: CSCE 552 Fall 2012
Page 55: CSCE 552 Fall 2012

Sample Game Loop

Page 56: CSCE 552 Fall 2012

Main Game Loop

Structure Hard-coded loops Multiple game loops: for each major game state Consider steps as tasks to be iterated through

Coupling Can decouple the rendering step from simulation

and update steps Results in higher frame rate, smoother animation,

and greater responsiveness Implementation is tricky and can be error-prone

Page 57: CSCE 552 Fall 2012

Execution Order of Main Loop

Most of the time it doesn't matter In some situations, execution order is

important Can help keep player interaction

seamless Can maximize parallelism Exact ordering depends on hardware