GAME 1024: Advanced Game Programming

1. GAME 1024: Advanced Game Programming Lesson 9: A Glimpse Into Your Future! By Kain Shin

2. Quiz • What is your name and are you a fighter, magic user, or stealth specialist? • Give at least four steps of an algorithmic thinking process • What is one thing that can cause a delay in the instruction pipeline? • What is one thing you can do to minimize cache misses? • Unroll this loop:for(int i=0; i<100; ++i){ arrayValue[i] <<= 1;}

3. Bonus Topic: Finite State Machines for Games • What Is It? • Example: Traffic Light • Example: Animation state (stand, walk/run, jump, attack, react, die, etc.) • Why Should I Care? • Because switch-statements-inside-update-functions suck • What’s a Basic Implementation? • class cFiniteStateMachine • Holds a registry of all known states • Associates state IDs to state objects • Updates the current state • Abstract class iFiniteState • OnEnter function • Update function • OnExit function • State Transition Methods • From within the update function of the finite state • Via an explicit call to cFiniteStateMachine::Transition(stateID)

4. User Interface • Requirements • Hooks to Input • Hooks to Simulation Pause/Unpause • Modal Screens – Exclusive Input • Non-Modal Screens – HUD • Buttons, Checkboxes, Sliders, Scrollbars, Sprites, Models, etc… • Preferably Data-Driven • Minimize File I/O After Initialization • Systems Design • class cUIManager • Contains a registry of all screens that will ever exist: map<screenID, iScreen*> • Manages one stack of modal screens • Non-modal screens can either be managed in a separate stack or piggy-back off a modal screen • Pointers of screens from the registry are pushed/popped to/from the stack • Listen for Input Events: Routes input to the top-most modal screen • Routes updates to the Topmost modal screen, no updates reach the other modal screens • Renders all active screens after the world is done with its render • The game simulation takes place within a modal screen

5. Graphics • Let’s Talk About… • How a block of memory turns into monitor pixels • Blitting Sprites • Rendering Vertex Data • Rendering Texture Data • Normals and the Lighting Model • Orthographic vs. Perspective Projection • 2D Animation • UV Scrolling • The 3D rendering state machine • Scene graph • 3D Animation (Bones System) • Billboarded Quads • Particles • Pixel/Vertex Shaders • Full Screen Effects

6. Artificial Intelligence • Let’s Talk About… • AI for Games • Meant to be fun, not smart • Architecture Suggestion: • Brain (Eyes and Ears) – Manages states on the controller. Your AI code would live here. • Controller (Strings) – May contain multiple finite state machines for body animation, speech, health, superpowers, etc. • Character (Puppet) – Rendering Information lives here • Event System Usage • The brain would be a listener • Examples of events: explosion nearby, bullet fired, bullet hit nearby, actor movement • AI Programming falls into two categories… • Decision Architectures:Stimuli + CurrentState = Decisions • Path Planning:CurrentPosition + DesiredPosition + NavigationData = MovementDecision

7. 3D Camera Programming Overview • Camera on a stick • Camera as an AI (Lots of Math!) • Useful Features: • Debugging: • Bread Crumbs • Astral Projection • Gameplay: • Designer/Artist Specified Camera Spline Movement (Cinematics) • Camera Shake • FOV changes (i.e. Burnout) • Common Issues: • Camera + User Controls + Game Design = Lots of Iteration! • Geometry Occlusion (Third Person) • Backing up into a wall • Something moves between the player character and the camera

8. Audio Programming Overview • Basic Model for 3D Audio • AudioListener – Position and orientation moves with the player • AudioSource • Audio Programming Issues • Resource Management (streaming, hardware limitations) • Data hookup • Localization • lip synching • Association with actors in the world • Special effects • Reverb • Doppler • Occlusion

9. Physics Programming Overview • Basic Physics Model for Games • All actors have an invisible physics representation • Movement is authoritative • Physical Properties • Mass • Restitution • Coefficient of static/dynamic friction • Joint properties • Center of gravity • Current linear velocity • Current angular velocity • Etc. • Types of physics interactions • Collisions • Applied Forces • Volume Penetration • Joint Simulation (including soft body simulations)

10. Multiplayer/Network Programming Issues • Shared Screen Multiplayer (Gauntlet, Mario Party) • Shouldn’t be hard if you use the brain-controller-puppet model • Split Screen Multiplayer • Render bandwidth is the primary issue • Downgrade graphics features • Downgrade art content • Memory is the secondary issue for streaming worlds • Don’t let the players exist too far from each other… somehow • Screen real-estate is the remaining issue • Design your UI and gameplay to support smaller screens • Network Multiplayer • Event System Required! • Network bandwidth is the primary issue • Minimize the size of event data, and compress the data before sending • Freeze all clients until they are in synch (boo!) • Make simulations deterministic so that you only need to send delta information with reasonable corrections for lagged evvent notifications • Design for lag (dead reckoning, time stamps, predictive algorithms, slow animations, etc.) • Design for low bandwidth (i.e. state-base combat in MMOs) • Security is the secondary issue • Authoritative Server data • Cheat detection

11. Tools Programming Overview • Purpose of Tools: • Allow non-programmers to be productive • Minimize human error • Save time • Tools are separate from the game • Don’t have to be written in C++ (C# is becoming the language of choice) • Doesn’t need optimized performance • Outputs a file that the game can read • Examples of Tools • World Editor • Localization • Remote Debugger

12. Final Thoughts • Check your syllabus to see the other ACC courses that focus on today’s material. This class was specifically designed to not overlap with these other courses • I learned more of this material from books than I learned in a class or on the job. • Don’t re-invent the wheel: Learn how other people have tackled the problem before you make up your own solution • Usually, a good system is one that people don’t talk about because they have no complaints. Try paying attention to these “invisible” systems the next time you play a game.