Advanced Game Design Prof Roger Crawfis Computer Science

Advanced Game Design Prof. Roger Crawfis Computer Science & Engineering The Ohio State University

Course Overview Project-based / Team-based Little lecturing Focus on programming for games Systems integration – graphics, sound, AI, networking, user-interfaces, physics, scripting Utilize higher-level toolkits, allowing for more advanced progress while still developing programming skills.

Course Structure I will lecture for about the first week and a half. Student game project groups will provide several presentations on their game ideas and progress. Student technology teams will provide an intermediate and an advanced lecture on their findings and analysis about their area.

Project Goals Large-scale software development Team-based (synergistic development) Toolkit-based (fast-start development) Learn and utilize the many nongraphical elements needed for games. Leverage and extend your software engineering, graphics, AI, …, expertise.

Elements Gaming Engine Responsible for providing primitives Hardware abstraction Handle different areas of the game l Physics, AI, etc. Game Defined by a genre Defines the gameplay

Requirements of a gaming engine Stunning Visuals Immersive sound stage Varied input/output devices Scalability Simulation Animation Networking

Requirements of a game Scripting Artificial Intelligence Supporting Tools Optimizing game content Developing game content Extending game content Debugging / Tuning of game performance

Stunning Visuals Adding realism Smarter Models Use hardware Bump-mapping Dynamic water or other liquids Rich textures (Billboards, gloss-maps, light-maps, etc. ) Shadows Particle systems

Immersive sound stage Multi-track sound support Positional sound effects (3 D immersion) Dynamic sounds / movement (doppler effects)

Input devices Commonly available devices are Keyboard, mouse, gamepads and joysticks Force feedback (haptic) devices are gaining popularity Steering wheels Joysticks Motion tracking Output devices Multiple monitors Head mounted displays

Scalability Multiple hardware capabilities Multi-resolution models Multi-user support LOD Multiple model definitions Multi-res models Subdivision surfaces

Simulation Virtual worlds are all good to look at Immersion breaks when real world physics are not applied So we need Collision detection Collision response

Animation Linear transformations Modeled animations Articulated motion Lip syncing Facial Expressions Blending animations

Networking Multi-player support essential Common problems Latency Synchronization Scalability Consistent game state Security

Scripting Strict coding is tedious Support for scripting is essential for RAD Scripting has added a whole new fun factor for many games.

Artificial Intelligence Games need specialized AI Strategy Path finding Modeling behavior Learning Non-perfect! Fast!

Tools Creating varied content models, video, images, sound Integrating content Common file format support Supporting existing popular tools via plug-ins 3 DS Max, Lightwave, Maya etc. Adobe premier, Adobe Photoshop

Interactive Programs Games are interactive systems - they must respond to the user How?

Interactive Program Structure Initialize User Does Something or Timer Goes Off System Updates Event driven programming Everything happens in response to an event Events come from two sources: The user The system Events are also called messages An event causes a message to be sent…

User Events The OS manages user input Interrupts at the hardware level … Get converted into events in queues at the windowing level … Are made available to your program It is generally up to the application to make use of the event stream Windowing systems may abstract the events for you

System Events Windowing systems provide timer events The application requests an event at a future time The system will provide an event sometime around the requested time. Semantics vary: l l l Guaranteed to come before the requested time As soon as possible after Almost never right on (real-time OS? )

Polling for Events while ( true ) if ( e = check. Event() ) switch ( e. type ) … do more work Most windowing systems provide a nonblocking event function Does not wait for an event, just returns NULL if one is not ready What type of games might use this structure? Why wouldn’t you always use it?

Waiting for Events e = next. Event(); switch ( e. type ) … Most windowing systems provide a blocking event function Waits (blocks) until an event is available Usually used with timer events. Why? On what systems is this better than the previous method? What types of games is it useful for?

The Callback Abstraction A common event abstraction is the callback mechanism Applications register functions they wish to have called in response to particular events Translation table says which callbacks go with which events Generally found in GUI (graphical user interface) toolkits “When the button is pressed, invoke the callback” Many systems mix methods, or have a catch-all callback for unclaimed events Why are callbacks good? Why are they bad?

Upon Receiving an Event … Event responses fall into two classes: Task events: The event sparks a specific task or results in some change of state within the current mode l l eg Load, Save, Pick up a weapon, turn on the lights, … Call a function to do the job Mode switches: The event causes the game to shift to some other mode of operation l l eg Start game, quit, go to menu, … Switch event loops, because events now have different meanings Software structure reflects this - menu system is separate from run-time game system, for

Real-Time Loop At the core of interactive games is a real-time loop: while ( true ) process events update animation / scene render What else might you need to do? The number of times this loop executes per second is the frame rate # frames per second (fps)

Lag is the time between when a user does something and when they see the result - also called latency Too much lag and causality is distorted With tight visual/motion coupling, too much lag makes people motion sick l Big problem with head-mounted displays for virtual reality Too much lag makes it hard to target objects (and track them, and do all sorts of other perceptual tasks) High variance in lag also makes interaction difficult

Computing Lag Process input Frame time Update state Render Process input Event time Lag is NOT the time it takes to compute 1 frame! What is the formula for maximum lag as a function of frame rate, fr? What is the formula for average lag?

Frame Rate Questions What is an acceptable frame rate for twitch games? Why? What is the maximum useful frame rate? Why? What is the frame rate for NTSC television? What is the minimum frame rate required for a sense of presence? How do we know?

Frame Rate Answers (I) Twitch games demand at least 30 fs, but the higher the better (lower lag) Users see enemy’s motions sooner Higher frame rates make targeting easier The maximum useful frame rate is the monitor refresh rate Time taken for the monitor to draw one screen Synchronization issues l l Buffer swap in graphics is timed with vertical sweep, so ideal frame rate is monitor refresh rate Can turn of synchronization, but get nasty artifacts on screen

Frame Rate Answers (II) NTSC television draws all the odd lines of the screen, then all the even ones (interlace format) Full screen takes 1/30 th of a second Use 60 fps to improve visuals, but only half of each frame actually gets drawn by the screen Do consoles only render 1/2 screen each time? It was once argued that 10 fps was required for a sense of presence (being there) Head mounted displays require 20 fps or higher to avoid illness Many factors influence the sense of presence

Reducing Lag Faster algorithms and hardware is the obvious answer Designers choose a frame rate and put as much into the game as they can without going below the threshold Part of design documents presented to the publisher Threshold assumes fastest hardware and all game features turned on Options given to players to reduce game features and improve their frame rate There is a resource budget: How much of the loop is dedicated to each aspect of the game

Decoupling Computation It is most important to minimize lag between the user actions and their direct consequences So the input/rendering loop must have low latency Lag between actions and other consequences may be less severe Time between input and the reaction of enemy can be greater Time to switch animations can be greater Technique: Update different parts of the game at different rates, which requires decoupling them For example, run graphics at 60 fps, AI at 10 fps Done in Unreal engine, for instance

Animation and Sound Animation and sound need not be changed at high frequency, but they must be updated at high frequency For example, switching from walk to run can happen at low frequency, but joint angles for walking must be updated at every frame Solution is to package multiple frames of animation and submit them all at once to the renderer Good idea anyway, makes animation independent of frame rate Sound is offloaded to the sound card

Overview of Ogre 3 D Not a full-blown game engine. Open-source Strong user community. Decent Software Engineering. Cool Logo

Features Graphics API independent 3 D implementation Platform independence Material & Shader support Well known texture formats: png, jpeg, tga, bmp, dds, dxt Mesh support: Milkshape 3 D, 3 D Studio Max, Maya, Blender Scene features BSP, Octree plugins, hierarchical scene graph Special effects Particle systems, skyboxes, billboarding, HUD, cube mapping, bump mapping, post-processing effects Easy integration with physics libraries ODE, Tokamak, Newton, OPCODE Open source!

Core Objects

Startup Sequence Example. Application Go() Setup() Configure() setup. Resources() choose. Scene. Manager() create. Camera() create. Viewport() create. Resource. Listener() load. Resources() create. Scene() frame. Started/Ended() create. Frame. Listener() destroy. Scene()

Basic Scene Entity, Scene. Node Camera, lights, shadows BSP map Integrated ODE physics BSP map Frame listeners

Terrain, sky, fog

CEGUI Window, panel, scrollbar, listbox, button, static text Media/gui/ogregui. layout CEGUI: : Window* sheet = CEGUI: : Window. Manager: : get. Singleton(). load. Wind ow. Layout( (CEGUI: : utf 8*)"ogregui. layout"); m. GUISystem->set. GUISheet(sheet);

Animation Node animation (camera, light sources) Skeletal Animation. State *m. Animation. State; m. Animation. State = ent>get. Animation. State("Idle"); m. Animation. State->set. Loop(true); m. Animation. State->set. Enabled(true); m. Animation. State>add. Time(evt. time. Since. Last. Frame); m. Node->rotate(quat);

Animation Crowd (instancing vs single entity) Instanced. Geometry* batch = new Instanced. Geometry(m. Camera->get. Scene. Manager(), "robots" ); batch->add. Entity(ent, Vector 3: : ZERO); batch->build(); Facial animation Vertex. Pose. Key. Frame* manual. Key. Frame; manual. Key. Frame->add. Pose. Reference(); manual. Key. Frame->update. Pose. Reference ( ushort pose. Index, Real influence)

Picking

Picking CEGUI: : Point mouse. Pos = CEGUI: : Mouse. Cursor: : get. Singleton(). get. Position(); Ray mouse. Ray = m. Camera->get. Camera. To. Viewport. Ray(mouse. Pos. d_x/float(arg. state. width), mouse. Pos. d_y/float(arg. state. height)); m. Ray. Scene. Query->set. Ray(mouse. Ray); m. Ray. Scene. Query->set. Sort. By. Distance(false); Ray. Scene. Query. Result &result = m. Ray. Scene. Query->execute(); Ray. Scene. Query. Result: : iterator mouse. Ray. Itr; Vector 3 node. Pos; for (mouse. Ray. Itr = result. begin(); mouse. Ray. Itr != result. end(); mouse. Ray. Itr++) { if (mouse. Ray. Itr->world. Fragment) { node. Pos = mouse. Ray. Itr->world. Fragment->single. Intersection; break; } // if }

Particle Effects m. Scene. Mgr->get. Root. Scene. Node()>create. Child. Scene. Node()->attach. Object( m. Scene. Mgr->create. Particle. System("sil", "Examples/sil")); Examples/sil { material Examples/Flare 2 particle_width 75 particle_height 100 cull_each false quota 1000 billboard_type oriented_self // Area emitter Point { angle 30 emission_rate 75 time_to_live 2 direction 010 velocity_min 250 velocity_max 300 colour_range_start 0 0 0 colour_range_end 1 1 1 } // Gravity affector Linear. Force { force_vector 0 -100 0 force_application add } // Fader affector Colour. Fader { red -0. 5 green -0. 5 blue -0. 5 } }

Particle Effects Particle system attributes quota material particle_width particle_height cull_each billboard_type billboard_origin billboard_rotation_type common_direction common_up_vector renderer sorted local_space point_rendering accurate_facing iteration_interval nonvisible_update_timeout Emitter attributes (point, box, clyinder, ellipsoid, hollow ellipsoid, ring) angle colour_range_start colour_range_end direction emission_rate position velocity_min velocity_max time_to_live_min time_to_live_max duration_min duration_max repeat_delay_min repeat_delay_max Affectors (Linear. Force, Color. Fader) Linear Force Affector Colour. Fader 2 Affector Scaler Affector Rotator Affector Colour. Interpolator Affector Colour. Image Affector Deflector. Plane Affector Direction. Randomiser Affector

Fire and Smoke affector Rotator { rotation_range_start 0 rotation_range_end 360 rotation_speed_range_start rotation_speed_range_end } -60 200

Cel Shading vertex_program Ogre/Cel. Shading. VP cg { source Example_Cel. Shading. cg entry_point main_vp … default_params { … } } material Examples/Cel. Shading { … vertex_program_ref Ogre/Cel. Shading. VP {} fragment_program_ref Ogre/Cel. Shading. FP {} }

Cube Mapping With Perlin noise to distort vertices void morningcubemap_fp ( float 3 uv : TEXCOORD 0, out float 4 colour : COLOR, uniform sampler. CUBE tex : register(s 0) ) { colour = tex. CUBE(tex, uv); // blow out the light a bit colour *= 1. 7; }

Bump Mapping + =

// Noise texture_unit { // Perlin noise volume texture waves 2. dds // min / mag filtering, no mip filtering linear none } // Reflection texture_unit { // Will be filled in at runtime texture Reflection tex_address_mode clamp // needed by ps. 1. 4 tex_coord_set 1 } // Refraction texture_unit { // Will be filled in at runtime texture Refraction tex_address_mode clamp // needed by ps. 1. 4 tex_coord_set 2 } Reflections & Refractions

Reflections & Refractions

Grass Each grass section is 3 planes at 60 degrees to each other Normals point straight up to simulate correct lighting

Post-Processing Effects

Supporting tools (add-ons) Blender, Autodesk 3 DS, Milkshape 3 D, Softimage XSI importers/exporters Particle editors, mesh viewers GUI editors Physics bindings Scene exporters and lots more Add-on site

References http: //www. ogre 3 d. org/

Design Patterns First, an aside on Design Patterns

Ogre Foundations Root Render. System Scene. Manager Resource. Manager

Ogre Foundations Mesh Entity Material Overlay – Overlay. Element, Overlay. Container, Overlay. Manager Skeletal Animation