Cs 480/680: Game Engine Programming Introduction

CS 480/680: GAME ENGINE PROGRAMMING

INTRODUCTION

1/10/2013 Santiago Ontañón [email protected] https://www.cs.drexel.edu/~santi/teaching/2013/CS480-680/intro.html

CS 480/680

• Focus: • basic and advanced techniques for game engine programming.

• Topics: • What is a game engine? • The game loop • 2D/3D Graphics • Sound • Physics simulation • Collision detection • Networking • Game AI Outline

• Course Structure • Project • Schedule • Papers • Introduction to Game Engine Programming • Group Formation / Paper Assignment Outline

• Course Structure • Project • Schedule • Papers • Introduction to Game Engine Programming • Group Formation / Paper Assignment Course Structure: Evaluation

• Undergraduate students: • Game Engine Project (85%) • Class attendance and participation (15%)

• Graduate students: • Game Engine Project (70%) • One paper presentation in class (20%) • Class attendance and participation (10%)

• Online students: • Participation will be measured by activity in the class discussion board • Presentations will be delivered electronically (via a powerpoint/ keynote presentation with audio, youtube video, etc.) Course Structure

• Every week (3 hour class):

1 hour Lecture

Student presentations 1 hour Project Progress Reports

1 hour Time to work on your projects Course Structure

• Every week (3 hour class):

Also: If you find a new game that uses an original concept in terms of game engine programming (or one that you’d 1 hour Lecture like to learn how it’s programmed), please bring it up in class, or send me a link to it before class, so we can show it and discuss it! Student presentations 1 hour Project Progress Reports

1 hour Time to work on your projects Text Book

• Not mandatory to have it (but recommended)

• Covers most of the content from the lectures

• Great asset for working on your projects Outline

• Course Structure • Project • Schedule • Papers • Introduction to Game Engine Programming • Group Formation / Paper Assignment Game Engine Project

• Groups of 2 – 3 students: • 1 student groups are discouraged: part of the experience is working on game development teams. If you want to do a project on your own, you’ll have to do extra work to compensate and get the maximum grade.

• Each student picks a topic (students in the same group can be working on different topics): • For example: collision detection, physics simulation, game AI, networking, lighting, etc. • Groups will build a game engine, making emphasis on the topics of the members of the group

• Each group will build a game engine (not a whole game, just the engine!). This means, you don’t need to have dozens of levels, and many enemies, etc. Just one or two levels, or a small map is enough. Topics (not exhaustive list)

• 2D / 3D Graphics Rendering • Lighting • Animation • Collision detection (2D / 3D) • Physics simulation (2D / 3D) • Artificial Intelligence • Sensing • Networking • Scripting • Dynamic asset loading Platforms and Development Language

• Platforms: • Any platform, as long as it is possible to show it in class (ask instructor if your platform is not in this list): • Linux, Mac OS X, Windows, Android, iOS, Web (HTML5/Flash)

• Languages: • Any language, as long as it allows the student to learn and implement the desired components • For example: • C, C++, Lisp, Java, Python, Javascript, Flash, C#, etc. Libraries

• You are welcome to use ready-made libraries for your projects but…

• Use them only for those parts that are not the focus topic of any student in the group.

• For example: • If a student picks “physics simulation”, then using ODE will not be allowed. • If no student in the group has picked “physics simulation”, then you are welcome to use ODE in your project. Deliverables

• Group formation (week 2)

• Game Engine Architecture document (week 4) • Document detailing the architecture of your game engine, all the modules you will implement, libraries you will use, data structures you will use, communication between modules, libraries you will use, and assets required. • Deliverable 1: 2 – 6 page description document. Include a description of what demo you will show (levels, assets, etc.)

• Game Loop (week 6) • Development started, game loop created. • Deliverable 2: demo to instructor, source code, 2 – 8 page description document (updated from last deliverable).

• Demo (week 8) • First demo, major development effort completed, and only details left. • Deliverable 3: demo to whole class, source code, 2 – 6 page description document

• Final Project (week 10) • Complete project. • Deliverable 4: demo to whole class, source code, 2 – 8 page description document (updated from last deliverable) Undergraduate vs Graduate projects

• Graduate students are expected to pick topics that are state of the art (e.g. “Phong shading” is not acceptable, since it’s a very old, very well known technique). Those topics are fine for undergraduate students.

• If you are unsure whether your topic is “state of the art”: ask the instructor. Examples (idea 1)

• Standard 3D FPS • Topics: • Student 1: Dynamic lighting and shadow casting • Student 2: Network multiplayer • Platform: Linux • Development language: C++ • Libraries used: SDL, OpenGL, ODE, SDLMixer, SDLSound, SDLImage, SDLNet, SDLTTF • Demo: • Single map with closed and open areas (to show off lighting), just one type of enemies • 3D models downloaded from the internet from open source repositories, map authored in a simple text file • Networking support for LAN, allowing up to 4 players and allowing an unbounded number of observers (to show off networking) Examples (idea 2)

• 2D RPG (Zelda-style) • Topics: • Student 1: Artificial Intelligence • Student 2: Network multiplayer • Platform: Linux/Mac/Windows • Development language: Java • Libraries used: none • Demo: • Single level (with enemies and NPCs with different behaviors to show off AI) • 2D models downloaded from the internet from open source repositories, map authored in a simple text file • Networking support for LAN, allowing up to 4 players and allowing an unbounded number of observers (to show off networking) Examples (idea 3)

• MMO • Topics: • Student 1: Dynamic asset loading • Student 2: Networked Persistent world • Platform: HTML5 • Development language: Javascript • Libraries used: none • Demo: • Two large areas with different complex assets (to show off dynamic asset loading) • 2D/3D models downloaded from the internet from open source repositories, map authored in a simple text file • Networking support having a server that maintains the state, and clients connecting to play the game. Allow for having multiple coordinated servers (to show off the persistent world) Examples (idea 4)

• Car Racing Game • Topics: • Student 1: Physics simulation • Student 2: Collision Detection • Platform: Android • Development language: C++ • Libraries used: SDL, OpenGL, SDLMixer, SDLSound, SDLImage, SDLNet, SDLTTF • Demo: • Single track with one type of opponents, but with track element of different types: curves, jumps, loops, walls, etc. (to show off physics and collision detection) • 2D/3D models downloaded from the internet from open source repositories, map authored in a simple text file Examples (other ideas)

• 2D platformer (Mario-style) • Graphic Adventure (Monkey Island) • Shoot-em up (Raiden) • Fighting game (Street Fighter) • Physics-based game (Angry Birds) • RTS game (Starcraft) • 2D MMO (Fantasy Online)

• Be original! • Check out indie games such as Limbo, Voxatron, Legend of Dungeon, Spelunky, Fez, etc. for ideas! (see the end of this slides for more ideas) Outline

• Course Structure • Project • Schedule • Papers • Introduction to Game Engine Programming • Group Formation / Paper Assignment Class Schedule

Week Topic Project W1 Introduction: Architecture Form groups / select topics W2 The Game Loop Declare groups / topics W3 Graphics: 2D / 3D Rendering W4 Collision Detection Deliverable 1: Architecture Document W5 Input Handling / Networking W6 Physics: 2D / 3D Simulation Deliverable 2: Game Loop W7 Animation W8 Scripting and AI Deliverable 3: Demo W9 Case Study W10 Project Presentation Deliverable 4: Final Presentation Outline

• Course Structure • Project • Schedule • Papers • Introduction to Game Engine Programming • Group Formation / Paper Assignment Paper Presentations

• Each graduate student needs to select a paper: • Read it carefully (follow references if needed for fully understanding the topics) • Prepare a presentation for class: • In-class students: 10 minutes • Online students: 5 – 7 minutes (since you can prepare it more carefully)

• List of papers available on the BBLearn page for the course.

• Select three papers, and send the titles to the instructor by order of preference. I will assign the papers trying to respect these preferences as much as possible. Paper Presentations

• Example papers: • “Camera Control Techniques” • “Real-Time Strategy Network Protocol” • “Cartoon Rendering: Real-time Silhouette Edge Detection and Rendering” • “Real-Time Shadows on Complex Objects” • “A Brief Introduction to OpenAL”

• Most papers are selected from the “Game Programming Gems” book collection. The papers on the website is a selection I did. But if you are interested in any other paper from that book collection, let me know, and I’ll get you the PDF. (table of contents can be easily found on Amazon) Presentation Advise

• Do not assume we know what you are talking about: introduce the topic, and provide context • The presentation is not just for the instructor to see if you understood, is for the whole class to learn something

• Be visual: • Use figures in your slides, not just text

• Structure your talk, do not blindly follow the order in the paper, for example: • Topic introduction • Problem being tackled • Presented solution • Results obtained Outline

• Course Structure • Project • Schedule • Papers • Introduction to Game Engine Programming • Group Formation / Paper Assignment What is a Game Engine?

• Piece of software that can be used to build different games in a given genre

• Typically “data-driven”: • Game logic not hardcoded into the source code, but in external configuration files.

• Game vs Game-Engine: • If a game program requires significant restructuring to turn it into another game, it is a game, but not a game engine. • If a game program can be adapted to run different games easily, then it is a game engine Game Engines

Unreal Pacman SCUMM VM Engine

Non Maximum reusable reusability Game Engines

Unreal Pacman SCUMM VM Engine

Non Maximum reusable reusability Game Engines

Unreal Pacman SCUMM VM Engine

Non Maximum reusable reusability Game Engines

Unreal Pacman SCUMM VM Engine

Non Maximum reusable reusability Game Engines

Unreal Pacman SCUMM VM Engine

Non Makes more economical Maximum reusable sense for game companies to reusability head here, since allows for maximum software reusability and cheaper development. FPS Game Engines

• Example: Half-Life FPS Game Engines

• Example: Half-Life

• Needs: • Efficient 3D rendering • Responsive control/aiming mechanic • Variety of weapons • Loose collision detection for player • High quality animations and AI for opponents • Small-scale multiplayer capabilities Platformer Game Engines

• Examples: • Ghost’n’Goblins (2D) • Super Mario Galaxy (3D) Platformer Game Engines

• Examples: • Ghost’n’Goblins (2D) • Super Mario Galaxy (3D)

• Needs: • Support for dynamic scenario (moving platforms, etc.) • Accurate collision detection • Third person camera with advanced camera collision systems (for 3D games) • Triggers and puzzle-like scripting support Fighting Game Engines

• Examples: • Street Fighter II (2D) • Tekken (3D) Fighting Game Engines

• Examples: • Street Fighter II (2D) • Tekken (3D)

• Needs: • Advanced animation system (realistic skin, and cloth movement) • Accurate hit and collision detection between different body parts • Input system capable of detecting complex combos • Simple static backgrounds (maybe with moving crowds) Racing Game Engine

• Examples: • Super Cars (2D) • Out Run (2½ D) • Track Mania (3D) Racing Game Engine

• Examples: • Super Cars (2D) • Out Run (2½ D) • Track Mania (3D)

• Needs: • Efficient rendering of distant backgrounds (e.g. 2D shapes in 3D environments) • Complex data structures to store track geometry • Complex camera control to ensure good viewing angles in different scenarios • Accurate collision detection • Realistic physics simulation RTS Game Engines

• Examples: • Starcraft RTS Game Engines

• Examples: • Starcraft

• Needs: • 2D / 3D rendering of large number of units (level of detail rendering) • Accurate modeling of terrain (height fields, etc.) • Fast path-finding on dynamic terrain • Artificial Intelligence and scripting support for opponent strategies MMO Game Engines

• Examples: • Fantasy Online (2D) • WoW (3D) MMO Game Engines

• Examples: • Fantasy Online (2D) • WoW (3D)

• Needs: • All the needs of a FPS/RPG plus… • Massive multiplayer support (state consistency) • Meta game support (markets, forums, chats, guilds, etc.) Other Genres

• RPGs: • Specialized engines (complex character development support) • 3D RPGs typically built on top of FPS engines

• Sport games: • Mainly dependent on complex animation systems

• Simulation games: • Sim City, etc. (specialized engines)

• Puzzle or Mini-games: • Tetris, etc. (specialized engines, but can be built with general purpose engines) Example Game Engines

• Quake: • Id Software • Inherits from “Castle Wolfenstein 3D” (1992) and Doom • Other engines such as the one of “Medal of Honor” are based on it. • Quake / Quake II are open source: • https://github.com/id-Software/Quake • If you download it, you can compile with visual studio, and if you own the original game, you can actually run your own compiled version, trace it with the debugger, etc.

• Unreal • Epic Games Inc. • Used in “Unreal Tournament”, “Gears of War”, etc.

• Source: • Used in “Half-Life 2”, “Portal”, etc. Example Game Engines

• OGRE (FPS) • Panda3D (Any kind of 3D games) • Torque (FPS) • SCUMM VM (graphical adventures) • RPG Maker (2D RPGs) • Blender (Any kind of 3D games) • Stratagus (RTS games) … Game Engine Architecture

• Composed of a set of layers, each one of them providing higher and higher-level functionality (not unlike a regular OS)

• Can be very simple of very complex

• In addition to the run-time (the code that runs when the game is being played), game engines typically include content authoring tools (level editors, script editors, etc.)

Game Engine Architecture

Game Specific

Game Engine Functionalities

Game Dependencies Engine Resource Management Utility Layer Platform Independence Layer SDKs OS DRIVERS HARDWARE Game Engine Architecture

Game Specific

Game Engine Functionalities

Game Dependencies Engine Resource Management Utility Layer Platform Independence Layer SDKs OS DRIVERS HARDWARE SDKs

• Typically used: • Data Structures: STL, Boost, Loki • Graphics: OpenGL, DirectX • Animation: Havoc, Edge, Granny, Euphoria • Sound: OpenAL • Physics: ODE, Havoc, PhysX • … (add your favorite library here) Game Engine Architecture

Game Specific

Game Engine Functionalities

Game Dependencies Engine Resource Management Utility Layer Platform Independence Layer SDKs OS DRIVERS HARDWARE Platform Independence Layer

• Layer that offers the functionality of all the libraries below in a platform independent way. • For example: • If coding a game for 2 platforms, where one only allows Physx, and the other only ODE, this layer would define an API that the game engine can use, independently of the physics library underneath • There are many existing platform independence layers available for graphics, sound, etc. the most popular is SDL (Simple Directmedia Layer) with abstractions for: • Graphics, sound, keyboard, mouse, network, threading, etc. Game Engine Architecture

Game Specific

Game Engine Functionalities

Game Dependencies Engine Resource Management Utility Layer Platform Independence Layer SDKs OS DRIVERS HARDWARE Utility Layer

• Set of basic functionalities, not provided by any of the linked SDKs, and that are required by the game engine. • Typically: • Memory management: standard memory allocation might not be fast enough for a game engine, custom memory allocation routines are typical. • Math: basic set of functions for geometry, trigonometry, quaternion, matrix, equation solving, numerical integration, etc. as needed by the game engine. • Data structures: trees, graphs, etc. (anything not supported by STL, Boost, etc. that the engine needs) • Algorithms: search, sort, etc. • Random number generation (if standard does not satisfy needs) • File parsers (XML, etc.) • Configuration Game Engine Architecture

Game Specific

Game Engine Functionalities

Game Dependencies Engine Resource Management Utility Layer Platform Independence Layer SDKs OS DRIVERS HARDWARE Resource Management (Assets)

• All games require assets (bitmaps, 3D models, maps, sounds, etc.) • The game engine should provide functionality to load/save/ create/query assets such as: • 3D models: • Meshes • Textures/Materials • Skeletons • Animations • 2D models: • Bitmaps • Skeletons • Animations • Fonts • Maps • Sound files • Collision resources (collision shapes) Game Engine Architecture

Game Specific

Game Engine Functionalities

Game Dependencies Engine Resource Management Utility Layer Platform Independence Layer SDKs OS DRIVERS HARDWARE Game Engine Functionalities