Game Engines

10/21/2015 Message Game Engines: Why and What? Dan White Technical Director As you learn techniques, consider how Pipeworks they can be integrated into a production [email protected] pipeline. Sense of scale… Budgets and Timeline Video games word-wide: $110 billion Individual Game budgets are big. business in 2015 ◦ Current AAA titles: ◦ Main driver of 3D graphics hardware $30 million budget, 2+ year dev cycle. Not simulations or NORAD GTAV = 1 $Billion, $265 million to develop. ◦ Main driver of 3D rendering software ◦ Even mobile games: $500 thousand Not Hollywood ◦ Project completion date is very important. Particularly for licensed properties, sports, holiday launches, or anything with advertising. ◦ Schedules from 3 month to 5+ years Managerial Ideal Olde Tyme Game Making Game development Money Product organization Turbo Assembler Programmer Game 6 months More Money 35 years ago, a game might have1 programmer, and maybe 1 artist They were written…like a novel is written. 1 10/21/2015 A current mid/large size project A different approach looks very different… Head Count Jumpman Artists Atari 800 Animators circa 1983: Designers Scripters Programmers Producers This game had an EDITOR! On large projects, programmers are a small part At the time, this seemed revolutionary to me. On smaller projects, a larger part This doesn’t even include QA Doom Engine cemented the idea Game Engine Concept Doom released in 1993 A collection of reusable tools and runtime for making games. ◦ Spawned An integration platform for all the different HeXen, features of the game. Heretic and so on. Used by the different disciplines to do their work. ◦ Started the idea that an Ideal is you don't need engineers to make a game. engine is After all, you don't need engineers to write a book or potentially design a building valuable on Still plenty of work for engineers!! its own. How the team works… Production should be a pipeline Tool chain Runtime Back End Artists Animators Import Assets Distribute DesignersC Engine Product Edit Game Load Collect Data Data Scripters Audio Bundle for Simulate Analyze Designers Game specific Runtime code Gameplay Programmers Present 2 10/21/2015 Who are the engine users? Everybody wants… Artists Easy of use: ◦ People with art talent and a wide range of technical skills. ◦ Intuitive UI ◦ They want to make assets in a DCC tool (e.g. Maya) and put them in the game. ◦ Stability ◦ Need to be able to see the final result. Fast iteration times: Designers ◦ Make a change ◦ Also a wide range of technical skills. ◦ See the result ◦ They want to arrange content to produce fun. ◦ Make another change Place objects, manipulate values, script actions. Game programmers Iteration is the KEY to making games ◦ Engineers writing code specific to the game you are good! making. ◦ Good: Play in editor…10 second loop ◦ Organizationally separate from the people making the ◦ Bad: Bundle and launch full game…8 minute loop engine. Key Engine Features Other Features Rendering Asset Management ◦ Versioning Serialization Build system ◦ Asset loading Sound Object simulation Animation Camera & Controls Physics UI system ◦ Cloth ◦ Need for shell and HUD (Simple) Networking Do not underestimate! And on and on... ◦ Feature set grows over time ◦ No feature is minor when your game requires it! Unity Unreal 3 10/21/2015 Spigot It’s a hard problem Engines take many years to develop. ◦ Many fail. Not because of the difficulty of basic research. ◦ Most features begin in academia, or with graphics card manufactures. Hard part is integration into a usable system. Key Integration Points For a Feature More Integration Points Tool Chain Storage & Loading ◦ How do you get external assets into the game? ◦ ◦ Example Meshes: How are your configuration parameters Built in Maya stored by the editor? Exported as FBX Ideally, this will be text so you can diff results. Imported into editor for display ◦ How will the data be preprocessed at build In-editor UI time? ◦ How will artists and designers configure your feature? Runtime data is highly optimized, and this can take a Visual editing is better. long time. This is usually the most time consuming part. ◦ How will data be quickly loaded at runtime? ◦ How do people preview and iterate? May need to stream it. More Integration Points Interactions Runtime How does a feature interact with other ◦ What code runs in the actual game? features? ◦ Games are real-time systems, hence predictable performance is key. ◦ Sometimes features work against each other. Do not amortize costs in algorithms. ◦ You can’t just change the rendering pipeline ◦ What resources to you need: Memory cause you want to. Texture Memory Usually this is the hardest (if not the CPU GPU most time consuming) part. ◦ Can you make the code parallel? Interactions with other features. 4 10/21/2015 Example Feature: Particle Systems Basic Idea Render a sprite many many times to produce smoke, explosions, etc. Can produce a wide variety of effects with small amounts of source art. ◦ Great for engineers who want to make cool stuff. Generally not physically based. ◦ Not widely studied in academia. Tool Chain Editor UI Particle system: Particle systems: ◦ Input is textures. ◦ Invent the concept of “emitters” which Made in Photoshop produce particles. Imported as PSD, JPEG, etc. ◦ Using existing UI for materials. In Unreal, this is a graph-based system. ◦ Use a property sheet for parameters. ◦ Use a visual editor for curves. Supports splines. Unreal Material Editor Unreal Cascade Particle Editor 5 10/21/2015 Storage, Preprocessing, Loading Runtime Particle system: Particles: ◦ Editor description could be text. ◦ Straightforward to write. ◦ Runtime data is small. ◦ Render large numbers of dynamically updated Store as binary POD. quads or primitives. Reference materials, which pull in textures. It’s a bad idea to call DX/OpenGL many times. Converted to DXT or similar. Need to coalesce in vertex buffers or display lists. ◦ Extremely fill intensive. ◦ Updating many particles is CPU intensive. Particle systems very suitable for parallel processing. Interactions Some observations… Particles are typically translucent. ◦ Rendered with alpha. The editor and tool chain are much more ◦ Should they write to the Z-buffer? Probably not. complex than the runtime. You will likely have to sort them relative to other objects. Depth complexity of particle systems is very high. ◦ Lots of UI work! ◦ Will destroy your fill rate if they are close to the camera. Have to LOD particles as you get close, or limit camera. The whole team works with the tool ◦ May implement lower-res render to texture. chain, but only engineers work with the If you have depth based fog, do you apply fog to the particles? Deferred rendering runtime. ◦ A screen space rendering technique that uses passes. ◦ Productivity payoffs for improved tools can be ◦ Doesn’t handle alpha. What to do? Dithering very large. Separate forward rendering pass. Hardware Evolution: Downside of Engines Where are we going? NES PS1 PS2 PS3 Current Xbox One Cost. PC Produces external dependencies. CPU MOS MIPS 294 MHz 3.2 GHz 8 Cores at 8 Core Te c h R3000A- MIPS POWER 3 GHz AMD Poor support for particular genres. 6502 32-bit "Emotion PPE, custom 1.79MHz RISC chip Engine" seven CPU ◦ e.g. RTS at 33 MHz 3.2 GHz Frequency: SPEs 1.75 GHz Generic performance may not be as good GPU - 66 MIPS 147 MHz 550 MH Gerforce 853 MHz vector "Graphics z based 650 GPU as special code. math unit Synthesizer" on 1058 Mhz Custom on CPU Nvidia 384 Cores AMD These are issues as old as software. G70 Storage Cartridge CD DVD Blu-Ray HDD HDD 6 10/21/2015 Content is King Beyond the Engine: The Back End We have already reached the sweet spot Disruptive force since late 2000’s: for most game features: ◦ Piracy, and the need to control it ◦ ◦ 4 enemies to 8 big difference Digital Distribution ◦ Success of MMORPGS (e.g. WOW) ◦ 64 enemies to 128 small difference ◦ High broadband penetration PS2 was the tipping point between ability ◦ Microtransactions as business model to display content and ability to make it. ◦ Resurgence of the PC, and emergence of mobile We are now firmly in the era where ◦ Abundant web technology & infrastructure content creation cost is the driving factor. Result has been the rise of games with a “back end” component Runtime performance gets even less ◦ Means: the game connects to a database important. Implementation Backend is typically not part of the game engine. Uses technologies not traditionally part of game development. Primary reason: “mainstream” software development tools can be used. ◦ Node.js ◦ .NET ◦ CodeIgniter Back End Implications What it takes… Once you connect to a database, many things become easy: Games are a serious career for people who ◦ Cloud based save load are serious about it. ◦ Multiplayer lobbies & leaderboards But not synchronous MP Game programming involves skills missing ◦ Social integration from a traditional CS program: ◦ Freemium economy & transactions ◦ Mathematical modeling, vector math ◦ Piracy protection ◦ ◦ Telemetry, which has changed game design forever Simulation & physics Typically implemented via a HTTP/HTTPS & REST ◦ Graphics, particularly special effects ◦ Most common back ends are PHP, but all kinds used This is why I’m so excited about this class! ◦ Most common database is MySQL, but nosql is gaining Programming tasks often end up with a Games are much more write heavy than other Web apps complex integration step. ◦ Scalability is a problem 3rd party hosting services (AWS, Rackspace) used a lot ◦ Strong programming skills are essential. One of the biggest areas of active “research.” 7 10/21/2015 Message Recap As you learn techniques, consider how they can be integrated into a production pipeline. Iteration! Iteration! Iteration! 8.

Load more