Monday 6th:

Game Engines & Middleware

Some subsystems are hard to create so it often gets factored out into middleware. Common middleware used for Physics, trees, movie players, rendering, sound. Middleware became popular around 2000 during the ps2 era.

Blink is easy to integrate, you must give it a way to alloc, output rendering, and file io.

Physics is harder to integrate.

Game Engines:

• Quake Engine (1996) – 3d acceleration
• Unreal Engine (1998) – modular arch, unreal script
• CryEngine (2004)
• Unity (2005) – multiplatform

Why use an engine?

• content tools & pipeline
• state of the art rendering
• cross-platform support
• cross-domain integration
• easy gameplay prototyping
• Saves you from writing glue code for a bunch of middleware
• Piece of mind, the code is not junk

We looked at Unity and Unreal. Licensing fees were discussed but I assume again the discussion was not meant to be public.

Unity was design without a single game in mind. Meanwhile unreal was forked from a FPS. Thus Unreal is built around levels yet a sports game must then fit around this.

Why we do not use an engine in this course: They want us to learn the basics and what an engine does and how. More words were used but I’ve simplified.

Optimizations:

• Competition and your artist are going to be pushing your hardware’s boundary.
• Targeting a test may make you miss the the real use case.
• Takes more time to develop than the faster languages
• You’ll be running a optimization on a compiler optimized build so debugging will be hard.
• Hard to find the real gains
• 90/10 rule, most code has little performance impact
• watch for pitfalls like virtual functions
• Cache can cause inversion of inpectations

How to optimize:

• Profile and find performance bottlenecks
• Fix them
• Goto step 1

Instrumented profiling versus sampled profiling versus system trace.

Structure of Arrays versus Array of Structures

We talked about optimization tricks and avenues. Its now 12:00 and we’re taking a break for lunch. I’m hungry.

Coming back at 13:05 we’re talking about C++ internals.

This talk is pretty cool, I should be writing it down =\

Took ten minute break and now we’re back at 14:00, going into networking gameplay.

Sound was covered, I’ve been working on integrating bullet.

Now we’re talking about debuging and recounting our hardest bug stories. Good stories, haha. In theory I should be writing this down but I won’t since I’m lazy and you may want to enrol if you have the chance.

Arrived early. It is Saturday so traffic is low at 8:00 but the snow is still on the road. In calgary after a snow we get pseudo lanes which may more may not match the real lanes.
Saturday the 4th:

The PS4 has crashed and crashes after every startup.

We’re starting on physics at 9:10.

Physics

Types of representations:

• Arbitraty mesh – NO
• triange
• convex hull – hard to make
• simplified volume – boxes, shperes, cone, easy math
• height field
• implicit surface – spline, subsurface, but requirs transformation to trianges

Collision detection

• Collision is inherent O(n^2)
• Games are on average better and few things colide
• Easy assumptions, static objects, etc

Discussed in more detail detection. Discussed some edge cases and their solutions.

Break taken just before 10:00.  Back at 10:04.

Driving physics.

• Fun is the goal, not realism.
• vehicle control interface should be the same for players and ai
• have tunable numbers which may not match real physics

Brick prototype

• gravity should be 2-3x real world
• make a brick
• map user input to forces on the brick

I did not take notes for this section, was working porting Phil’s work to linux. We took a break around 11:20. We’re examining Big Planet Racing’s driving model. At 11:50 we took a quick look at Need for Speed: Most Wanted. It’s 12:00 and we’re pausing for lunch.

We’ve come back at 13:00. We played need for speed for 11 minutes.

Driving AI continued.

You may be able to guess that I am not handling our driving handling. That’s Kyle’s job =)

Took break at about 14:25. Come back but the PS4 has broke and we cannot use NBA as an example at animation.

We’re not using animation but this subject is being covered to give us background.

At the end we had an hour to go over our project. We tried to simplify our game and concrete our goals.

I came in 8 minutes late since Calgary just had a fresh serving of snow and traffic was slow. The class had waited for me which was nice. We started at 9:08

Friday the 3rd:

Gameplay

Also talked about as game mechanics. Its the interactivity which makes games unique.

AI

• The game knows all and can do all so making perfect AI is easy
• The real goal is the make fun AI
• Represent the world to the AI by choosing a data structure

World representation consideration:

• visibility
• audibility
• path finding
• colision detection
• sending messages to groups of entiites
• dynamic loading sections of world

World representation types:

• Single array list
• KD trees
• BSP
• Grid
• Graph
• Spatial hashing

A Array works well for small games and does not have any surprising usage edge cases. Big games use multiple techniques to maximize performance.

In the hulk games when you smash things the resulting debris is a real entity.

Most of the complex methods are spatial which allow log(n) lookup but if the object is inbetween cells then the code gets complicated.

Shpere of influence means inteast of simulating everything in hte world the game maintains only a bubble arround the player. I remember this in Just Cause where cars will disappear as soon as they drive past you. If you turn arround and try to capture a cool car you just saw you’ll miss it if you let it get out of view.

Dynamic entities might be

• players (human & ai)
• props
• power-ups
• rockets

Modeled with simplified spartial representation for collision detection. They might have a state machine to handle behaviour plus attributes like health.

Entity Behaviour

We want out entities to do interesting things. We can program the behaviour or we can simulate it. Simulation would be to use generic behaviours, like Givesdamage = 1 for bullets or rockets. Or Explodes = 2, etc.

Behaviour attributes make the behaviour more rich but make tuning harder. The world will be more active but less controlled.

Triggers

Common way to start entity behaviours. Common types are: volume, surface, time. I remember using these in my Fallout mod. Trigger conditions can send events.

State Machines

Used for simple entities. Most games use adhoc state machines without a formal generic engine. Prototype (game by radical) had a formal generic GUI edited state machine.

Mapping events to intentions

The AI interpets a button press as an intention. Any key presses should be expressed as an intention which then should get mapped. The intention then goes into the player state machine as input but conditions like isFacingWal could act as blockers.

Physics

Not always rigid body simulation. Could be simple like adding vectors. Full dynamics engine can be emulated much cheaper if done right. What the engines bring you is colission detection. It can be used for animation with procedural animation. We’ll look at FIFA for an example.

AI use of physics

In prototype the cars are not simulated by the physics. They move along on rails until a collision. If it collides then the cars are put into the physics simulation until they come to a rest. This means AI controlled entities have no physical attributes yet the AI must have realistic attributes to give the physics simulation when handed off.

Hulk 2 example: When hulk elbows a car, angular volicity is chosen to make it launch up into the air, tumble end-overend, and then land behind him. This is all fake and give to the physics engine from the ai. Thrown objects are not simulated until they hit something. So if you throw a car at a helicopter we want the car to hit. Expect in a full simulation the car’s trajectory will have a fixed curavature. In the game the ai instead drives the thrown object towards the helicopter like a homing missle.

Tuning physics.

Physics is emergent which can be good but hard to debug.  For example if the ai lets a car  drive into an object then the physics will throw the object out at high volocity. You’ll also have to break real world physics else the game will be boring. For example in a hockey game a real world speed for the players feels slow.

Cameras

AI camera models are motivated by gameplay goals. Need to see player, to see important ai entities, and improve controls.

Camera models:

• simple fixed camera like in pong
• tracking camera / following camera
• instant replay camera
• artist controled camera

In Simpson’s hit & run if a car goes over a jump then an instant replay camera will show the jump.

Driving games camera models

• first person – glued to the bumper with N field of view
• third person – should have lag else it will feel like car is nailed to center of screen.

Gameplay sumemry

• gameplay touches on everything
• We’ve skipped some areas like path finding, enemy ai, or ai animation control.

Gameplay section was done at 9:54. We took a break until 10:00.

Its 10:04 and we’re starting on Graphics

Grpahics

A glipmes at a graphics programer’s job.

• main job is creating infulstructure for artists. Work with art director. Common for art team to have 3x artist vs programmers. Programming scales better than art, there is only so many things to do.
• Integrate renderer with components.
• They need to know openGL/Dx but this is only the base job.
• Performance tuning is heavy on graphics. Memory boundaries, gpu time.

Towards the goal of helping the art design they must deconstruct what happens in a scene or concept art. For example we tried to pick out elements from a photo of a car. Things like shadows, reflections, lighting, and motion blur. Then we looked at some concept art for prototype. We noticed that the lighting model was not realistic, too light, but still higher contrast shadows versus typical games.

Art production requirements:

• efficient generate buildings & varied store fronts
• generating reusable materials
• decide geo vs texture detail
• create sinage props
• workflow for placing lights and signs
• solution for creating light volumes
• pipline for static lights
• scalable texture solution for applying grime textures
• build art for multiple levels of detail, Loss of Detail

Rendering Pipeline:

A requirements for this course is to have taken the introduction to graphics course so this section is review. Pipeline:

1. Content tools
2. Asset conditioning
3. scene management
4. submit rendering
5. geometry processing
6. rasterization

Artist pipeline:

Artists create resources, models textures. Some games have the artist create shaders, others leave shaders to the graphics programmers.

Assets then need offline processing for optimization and transformation for the game:

• Export geometry
• Optimization of geometry
• Merge vertexes
• texture compression
• shader compilation

PC may require some of the above steps to be done at runtime. For example shaders must be compiled at runtime. In theory this should help start up time, and let consoles manage to be silly slow startup times.

Scene management:

Done on the cpu we cull things before we send the vertexes for rendering.

• Frustum culling – skip things out of the camera view
• occlusion culling – quick reject objects behind other objects

Complex data structures for this like Octree, KD-tree, etc. Otherwise linear search can work.

Since graphics is not my area so I took the time to fix my FxOS patch.

We took a break around 11:10 and came back at 11:16 to look at Uncharted 3 with a critical eye. I’ll stop typing now. Long loading screen.

We took a lunch break at 12:05. Came back at about 13:00. One of the developers gave some interesting behind the scenes info on the new consoles. Pretty sure the info was not intended to leave the room. Nothing that should have been under NDA but still interesting tidbits we’ll hear in a few years.

Back to graphics.

GPU architecture and internals

Missed 40 minutes of notes here, was working on some emails. Interesting aspects of GPU programming.

Environment maps:

use cube maps, aka 3d maps. Way to store static data for fast runtime.

Ambient occlusion map: biases the light level. A texture which textures the lighting.

Dynamic lights: high power dynamic lights are slow since every light must occur in the shader.

Differend Rendering seperates surface property calculation and lighting.

Shadows:

• Blobs – just stick a blackish blob under something. Example seen form Simpsons Hit&Run.
• Projected texture – shadow based on simplified model
• Stencil – complex magic with something called a stencil buffer. Lots very nice, clean edges.
• Shadow maps – render the scene from the light’s eye and store that depth buffer. Still complex but cheaper than stencil. As you might be able to tell: I’m not my team’s graphics expert. Instead I’m going to do our AI, and some art.

Frame Buffer Effects

Render the scene to a texture then perform post-processing;

• motion blur
• depth-of-field
• refraction / reflection
• color correction – less correction and more mangling. Things like making grass green or adding bloom.

Billboards: a sprite which is alinged with the camera on N axises.

Point sprites: GPU powered primatives which are alligned on 3 axises to the camera.

Skinning: character which can be deformed to match movement.

Display Latency: some games use triple buffering so that they can be rendering 100% of the time. No need to wait while the double buffer waits to blit.

Graphics programming wrap up.

• graphics programming is a collection of disciplines
• know the hardware
• know the techniques
• follow the research
• look at other games
• check out demos from the graphics makers
• read Real-Time Rendering (Akenine-Mollar, Haines, Hoffman)

Break taken at 14:27. We’re back at 14:36.

We’re exploring Assassins Creed 4. That took an hour. Now we are discussing project and work allocation. Most work has been assigned. Onto tomorrow!

 

This semester I am taking the University of Calgary’s Games Programming course, cpsc 585. Like Last semester’s virus course this course also required an essay.  The games course, has lectures for 8 hours per day for 5 days during our block week. A block week is the week before regular classes begin and is used to provide super-concentrate classes or small unmarked courses. After the lectures we’ll spend the rest of the semester programming a racing game as our project. The entire grade is determined by our progress on the game and our final game.

The course is taught by two games developers so there is lots of interesting discussions. Since in general games is a closed community I’ve tried to not include any comments or tidbits which might be insider knowledge.

You may also notice that this course takes a console and AAA focused look. This does mean they are focused on more mainstream games and direction.

These notes were taken in real time. I’m not sure any one will enjoy reading them but I need to write this else I’ll get bored and stop paying attention. Eight hours of listening is a long time!

Tuesday 2nd:

Prior to this we looked at the finance structure of the typical Developer -> Publisher -> Distributor life cycle. I got the impression that work life at Radical improved once EA took them over. This would explain why studios are still selling themselves to EA despite Maxis, or Westwood, or Dice, or you get the idea.

Brief overview of the games industry:

• Movie games often start production during the movie’s post-production. Too late to make a good game.
• Publisher handles IP licensing fees
• Racing games license cars and tracks
• Manufactuerer’s take is greater than what an indipendent developer will earn on the same sale.
• Multi-platform AAA development only budget $20 – 30+ million
• Typical timeframe is 12 – 24 months. Valve was not mentioned.
• Expensive trends: High production values, open world, licensing tie-ins, celebrity voice acting
• Big open world games longer at 3+ year production cycle.
• Games engineering is failry ad hoc.
• EA has structed their development well but you cannot engineer fun.
• EA NBA 2010 cancelled, wasn’t fun. Development went to new studio and given full 2 year dev cycle. Still wasn’t fun. Cannot engineer fun, more will be talked about later.
• Industry expects upstart working hours but pays for 9-5.
• Little formal software design.
• 20-30% of team is programmers, 20-30% of team is scripters who have no formal programming education. Rest is art and game design + managers.
• No initial requirements are fixed.
• “make it not suck now” is the impreative
• Like other software systems: core runtime, tools & pipeline.
• Codebase needs to be maintainable for next year’s game.

Break taken at 10:25.

Back at 10:35. Topic: Fun.

Question: “What do you like about your favourtite games?”

• Playing with friends in borderlands
• Challenging/hard
• Exploring the world like in fallout 3 <- Me

Why do people play games:?

• Reward
• Immersion
• competition
• escapoe
• challenge
• relazation
• excitement
• discovery
• intelletual stimulation
• accompliishment
• variety
• social interacton

All these and what we mentioned goes into what is fun. Theory of Fun: Fun is the process of pattern matching, or grokking a pattern. We have noticed a pattern and used that to “beat” the system = fun in games. Games are safe places to practice grokking still.

Question: What about do you dislike?

• repition, grinding
• hand holding
• cheesy story lines
• Insane hard puzzles, in adventure games <- Me

What isn’t fun?:

• punishment over reward
• tedium
• inconsistency, Example: In Journey Down you can replace virgin olive oil with moter oil, but not a herb with a leaf.
• cheating
• presentation glitches
• boredom

What kinds of games do we like or dislike:

• MOBA
• Open world
• Copetitive
• Hate: driving games and sports
• Any genre, but like COD: online or puzzle solvers

Game Genres:

• Action/Adventure
• horro
• shooter
• stealth
• platformer
• rhytm/music
• MMO
• racing
• sports
• role-playing
• turn-based strategy
• point-and-click adventure
• puzzle

Gameplay style:

• Open world vs Levels
• Casual vs Hardcore
• Violent vs non-violent
• first person vs Third person
• single player vs multiplayer

So while COD and Far Cry are shooters they target a different audience because far cry is open world and single player while COD is leveled and multiplayer.

Non-violent First-Person-Shooter could sell well if it were easy to make. Good example is Portal but that game was hard to make. Style more iportanted to gaming than other medias. Genres bring expectations and decisions. People have cannot switch easy between genres, unlike other medias like say movies. Without competence in shooters Portal cannot be enjoyed to its full.

Genre will define aspects of the game. Can limit creativity. Example: Kart style racing game: you’ll have things on track to pick up and use.

Sucessful games:

• solid core mechanics
• sense of place
• range of challenges
• range of abilities used to solve the encounter
• skill required to use the abilities
• rewards

If you make a new genre/mechanic you must make sure it is solid. Story driven games must have a defined environment where things occur. Even tetris has a location, original used russia. you’re playing tetris is russia, why? because you have to be playing it somewhere! Tetris example of how challenges range from easy on the first level to hard on later. Shooters: you can take different approaches to solve level. You can sneak or go in guns blazing. New equitment can open up new solutions. Give the player onus for rewards, not “press button -> cool thing happens”. Archem Asylum: last baddy taken out -> camera focuses in and shows fuller detail.

Fun is Hard Work TM

• Fun more difficult to plan and schedule than other portions of development
• Often don’t know if it is fun until its built
• Low tollerance to mistakes
• Nothing is fun while you’re working on it, must be brought out
• Exaple: Let’s add cool reflections! -> “Oh, hose reflections do not look good, at all. We’ll have to remove reflections as a mechanic in that one level”

Coure-meta; marks focused heavy on fun and gameplay. Graphics, art, etc, can be messed up but driving mechanic is big deal. Cannot make game fun without god core mechanic.

tuning:

• Easy to pick up, intuitive controls, balanced difficulty and learning curve. Hard to master.
• This is accomplish with extensive tuning. Interate!
• Do not trust yourself to tune, the game has trained you to play the game well! Bring in new people.
• You will become jaded fast! Bring new people in for testing when that happens. Course-Meta: Get friends and family to play test but if you cannot then be aware the game is training you, fight it.
• Me: I remeber develping flash games I would hang out on an IRC channel with other (better) devs. I’d play test a game and it would be hard, I couldn’t get past first level hard. The dev would then respond in bewilderment: “I’ve made that first level really easy!”. The game has trained them to be the first best player for their game.

Originality:

• Novalty great way to differentiate your game from crowd.
• Watch for pitfalls: do not redefine genre’s hard decisions. Example: do not use A & B for movement in a shooter. Trigger buttons should not control vertical view point.

How to get there:

• Design for the player, not for yourself.
• try something but if its not fun scrap it. Watch out: everything is boreing the first try. hard judgement cal, lead game designer’s major skill. “Is this going to work once it has been tuned?”.
• Relentlesy prototype gameplay
• some feature’s goodness depends on payer. Consider making something optional.
• Learn from successful games, but not with a photocopier. Improve what they did, right and wrong.
• Each feature must be justified: we need a menu, a function to draw a model to the screen. Critical features should be implemented fast opening time for tuning. Some needed features can be delayed, like menus. know what can be dropped in whole.
• Big game can focus on perfecting optional things: “we can get an extra point on metacritic if we have awesome water simulation”.
• Details/tuning can take 2-5x the implementation time.

Analyzing games:

• Hard to be game developer without playing games. When you do you’ll notice game details.
• Not everyone must play games: the sound mixer can get away without being a gamer.
• If everyone else is punching the clock then at least the game design must be a gamer.
• Mechanics:
• What are you doing right now, why?
• How is it line or unlike other similar games?
• Level structure, pushing player. COD goes good job, linear but feels free because they’ve pushed you through the corridor and you feel like you could go off the path but just don’t want to.
• How is the story advanced?
• Sound big deal: example: movie’s deleted scenes feel spooky without ambient sounds.
• Watching a cut scene is not gaming so devs trying ways to stuff story into game.
• Metacritic has become major “how good is this game” measuring stick.
• Metacritic has problems but few bad 90+ score games, and few great low metacritic scorers.
• Course-meta: driving the car arround needs to be fun. Keep it simple since we have limited time and limited “artistic resources”, (none of us have done art).
• Course-meta: better to make one fun course and one fun car. Not making new Grand Tarismo.

Summery:

• Games concentrate on and are effective at different aspects of fun.
• Know what is fun for your target audience.
• Play games with critical eye.

At 11:32 without break for lunch yet: Starting on today’s second half, Game Architecture.

Basics:

• Input comes in
• time passes
• rendering and sound go out

Elements:

• Major subsystem, games cover most aspects of computer science.
• main loop
• time, huge since games are about doing things over time
• game state
• communications
• entities, individual simulated actor/unit. Industry terms, also known as agents or actors.

Langauge:

• 15 years ago only answer was C / Assembly or maybe C++
• Now can leverage higher level languages. Brings safety and expressiveness.
• Platform may limit choices: Xbox 360 did have C# support but that would leave you with self-porting mono for the ps3.
• You cannot map executable code pages on consoles. Console manufacturers scared of hacks. So no JITs and most interpreted lanuages.
• Assembly rare now: a recent Radical recent made had maybe 1000 lines of assembly
• Some odd-balls: Jak & Dexter written in a lisp-derivative. Naughty Dog stopped using lisp, their lisp compiler guy got tired and no one else could port to ps3. Now used as in-house scripting language.

The game loop:

• Take user and maybe network input and gerate a displayed frame + sound effects.
• Outer loop handles setup/shutdown, menus, controls overall game flow, updates major subs-systems. Tells input to pull keys, render to render frame.
• Styles are similar to kernels: single-threaded, multithread – cooperative (DOS, Go runtime), multithreaded – preemptive.

Example monolithic:

while (1)
{
    input();
    simulate();
    render();
    sound();
}

Cooperative:

class Task
{
    virtual void Run() = 0;
};
class Rendered : public Task
{
   void run(float time);
};

loop:
while (1)
{
   for (int i = 0; i < task_count; i++)
   {
     task->run();
    ]
}

Pre-emptive

void InputThread()
{
   while (1) input;
}

void SimulationThread()
{
   while (1) simulate();
}

Pre-emptive becomming more common because consoles are more parallel.

Course-meta: use monolithic.

Issues:

• handle all game states: menus, in-game, paused, etc
• Ensure order of operations: collision detection before AI state update
• Ensure consistency of game state across sub-systems
• Maintain modularity, minimize dependeces, reduce bugs, watch for spaghetti!

Comparison:

• Monotlic is easy to code, but gets messy, does not scale. Course-meta: don’t worry about scaling. “if your game cannot handle 200 objects then delete 100 and ship”.
• Monolitic gives game loop too much game state knowledge
• Cooperative tasking system is flexible but losses clarity. Ordering is implicite. Hard to determine what is getting shared and when.
• Pre-emptive systems are tough just like pre-empting kernels.
• Everything is getting worse. 15 years ago only what needed to be was concurrent. Now almost every game system is concurrent.
• No game is pure one system. Input cannot be async, just like networking or sound to lesser extent.
• Typical AAA game looks monolithic from overview but deep down may have coop-multitask in AI for game entities.
• Course-meta: we should be able to skip all concurerncy. Even sound which requires async can be hidden in library.

Other loop consiteradations:

• Some event driven platofrms do not have loop
• Example: javascript uses a timer based loop. Things like request-animation.
• Consoles may have literal while true infinite loop.
• Networking is in effect a subssystem on different machine.
• Fine grained parallelism, not one thread per entity but it would be nice for maximizing core usage. Instead might use task queue.

Lunch break taken at 12:03, return expected at 13:00.

After coming back from break we had a discussion on game pricing and how Microsoft’s no-used-games policy would have pulled the power from Gamestop and allowed cheaper games. I am more sceptical about if this move would have been to the consumer’s benefit.

The discussion has turned to iPhone games and metrics driven game design. “Most game developers are gamers. Sure I’d rather have a hit game over a game which did not sell but as a gamer I find metric targeting games un-satisfying”. Dr. Drezinger thinks these casual games will develop in a different direction from regular gaming.

“Just finding any programmers who want to work on Barbie Clothing designer is a challenge”. “Its realy hard to make games for girls because you don’t have any female developers.” “The developers will ask themselves ‘do I make this tiara pink like the others? Or maybe blue?'”

Lectures start up at 13:05

Time:

• Time is big aspect of game architecture
• How time is handled must be considered from the begining
• Don’t bake the time unit into your interface. Should wrap it in class.
• Watch for time accuracy edge cases
• Should use high resolution integer based times

Wall-clock vs Game-clock

• Game time should be consistent
• Game time should look like real time
• A car running at 100km/h at 60fps should not drop to 30km/h at 20fps
• You can accelerate time like in sports the 20 minute intervals should pass in under 20 minutes.
• You can distort time for gameplay, bullet time or lag compensation
• Old games often got this wrong, would be clocked to cpu clock
• Console games clocked to whole machine, emulators must watch to not run too fast.

Subtleties of time

• Types of clocks: real, audio, simulation, game
• Game states might effect one clock and not another. Example: pausing only stops simulation clock.
• Some subsystems may not accept lare time periods between running. Example: collision checking, else your cars will go through walls.
• If a subssystem has a hard floor on FPS you might have to slow the car down or similar. So at 10fps you might run the clocks at half speed to keep the game playable.
• Example: two incredible hulk games. Hulk had a ground-bound which moved every object around for physics sim so the game would drop to 10fps. The simulation was ran as if 30fps so everything slowed. Players thought this was a neat effect.
• Physics is sensitive to large time deltas else things can start falling through the world.
• Watch for sqew: Example: in Prototype the cut scenes got out of cue with the audio. In this case the game got ran off the audio clock.

Approaches to time:

Fixed step:

• simple but slow downs slow the game.
• Fixed has easy networking and deterministic AI. Networking wise just send people’s key presses.

Multiple simulation steps per render:

• fixed time step per simulation
• but run as many simulations needed to bring to real time
• then render
• Nice because it can handle variations in the render
• Downsides are if the simulation is too expensive you’ll never catch up.
• Can lead to “pop” if simluation/AI runs more often between a render.

Variable step:

while (1)
{
  new = Systemtime();
  step = sim_tim - now;
  siulate(step);
  render();
}

Works well for PC where CPU and GPU are variable power. Pacman has fixed simulate and render cost. Is non-deterministic, complex networking. Assumes last frame is usable for time step in current frame. Again physics depends on good framerate adn cannot skip. AI should work at 15fps but lower could break things.

Sub-iteration:

Like multiple steps and variable step. Run physics at fixed step and everything at variable.

Can also mix with a varaible but capped physiscs. Example: simpsons hit & run would run variable step for game and physics but it had rules for smallest physics step.  Physics was stepped twice if variable time step was too long.

Break would have been here but we’re running slow and we took the break early.

Subsystems & game state representation

Major subssytems:

• Video games have natural decomposition
• Course-meta: each person is going to implement multiple subsystems so keep them modular
• Input
• Networking
• Rendering
• Sound
• Script
• Content Loading
• HUD/front-end
• physics
• Animation
• AI

Ideally susbsystems should treat each other as black boxes. Need encapsulation. Networking is hard to keep encapsulated since it needs state from everything.

Game state

Everything in the game. Each subsystem needs game state, often overlapping but not everything.

Approaches:

• Global state – everything has access to everything else, does not scale.
• Global state can work for small games, “Here is the position of the orange ghost. If anyone needs it you know where to find it (global var).
• Push / pull. Example: AI tells rendered where objects are.
• Brokers generalize push & pull. Ferrys data between systems.
• Broadcast / listener – tracks state changes. Message passing. Convenient. Example: Sound registers for the damage event. Is expensive and must store messages.
• Database: needed when game state is larger than memory. Programming free saving and loading.
• Shared Entities: each system can query a different interface on the same object. Most common method. Warning: don’t use raw pointers use IDs or handles.

Break taken at 14:07 for 8 minutes. Asked instructors about Javascript and webgl for the project.

Entities

Almost every game has an entity system.

Single-rooted inheritance hierarchy:

Naive approach.

class Entity
{
   virtual void Display(void) = 0;
   virtual void Think(void) = 0;
}

class Character : public Entity
{
   void Display(void);
   void Think(void);
}

Each subssystem can only have access to specific interfaces. Bad encapsulation since entity should not know how to display itself.

Relationships get complex and system might dictate interface. Rendering tends to take control. Example: Drawable stuff, not drawable stuff.

Multiple-inheritance can be a solution. So base class like Drawable, or AI.  Scales better, hierarchy is cleaner. Harder to share implementation/code. In C++ some performance pitfalls and is painful. More on this in lecture on C++ internals.

Composition based entities.

So an entity might have a brain which implements the AI interface.  Can share implementations by sharing components.

Entity becomes wrapper so lots of wrapper. Lots of passing by value needed since components cannot access other components.

Sorry, I was rewriting what the intstructor was saying. He was talking about an entity owning a brain and I translated that to components. He is now covered components, it’s nice to hear because I hate inheritance approaches for this problem. Long live composition!

Component-based entities:

An entity is just a set of components. Components can be removed at runtime. Needs complex system for communication. Now we can implement some components in script. So AI could be scripted for ease of development. Display component can be written in native and fast. Be cautious when fetching a full component, prefer event sending.

Entities summery:

Radical’s gamecube era were all inheritance based. Lessons learned, 20k lines in the header file for the character class. Now Redical’s games are all component. Not everything in game industry is component: Frostbite is single-rooted inheritance. So all the cars in the first need for speed based on frostbite had an invisible gun!

Communication strategies

Ways systems and entities can talk to each other:

• Direct function calls – fast but scales poor. Long build times high coupling.
• virtual interfaces – reduced coupling, free polymorphism, but indirect calls.
• events – complex, should be type safe but double blind. No casts should be needed. Example of good system is QT’s signals and slots. Example of bad: WndProc, lots of casting. “heres a 32bit intergers, heres also some other 32bit integer—stuff…”. If done well brings low coupling. Warning: hard to debug. If an event is never fired then hard to find if, when, and why.
• callbacks can assist other methods with easy bi-directionality – “do this thing, then call me back”. More direct than events, easier to debug. Nice if lambdas exist in your language. Helps async and thus helps with concurrency.

Communication summery

• Make the AI authoritative
• Most games never manage architectural purity
• Prototype was done by same team as hulk but switched to components. This unlocked more experiments.

We’re an hour behind at 15:08, eating time into the scripting subject. We’re pushing scripting back and taking a 20 minute break. Coming back we’ll talk about our games and break up into groups.

We’re back at 15:23. Instructors setup a ps3 to demo some games.

We’re starting with Uncharted 2, I’m noticing the load times are pretty insane nothing like on linux with an SSD =).

While the ps3 is acting up we’re jumping into the project. Teams have been selected, I’m in team 2. We can do a racing game or karts or car combat or crazy taxi clone. Requirements are learning the pieces of the develpoment process. We must have a car AI which drives around. We’re allowed to use existing audio, physics libraries. Almost everything else should be written by use. I’ll ask about SDL.

Watch scope. Don’t plan something which would take the need for speed team four years if you only have four months.

Instructor said SDL was okay. Our game idea is a karting area death-match game.