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.