firestorm engine brownbag edits
DESCRIPTION
A presentation of my research on Game Engine ArchitectureTRANSCRIPT
Firestorm EngineADVANCED GAME PROGRAMMING AND DATA-ORIENTED DESIGN
Motivation and Description of Work
What is a Game Engine?
The underlying technology of a game
Combines different libraries into a collected framework
Can be general purpose, or specific to a game.
Preferably Data-Oriented, such that non-programmers can design and edit game without having to dig into code.
What I want to gain from this project
Learn about the different choices made by Game Engine Engineers
Learn about how different systems interact to create a completed program
CSCI 345: Video Game Design
Made 2D games in SDL
Covered Object Oriented Programming, AI, networking, threading, physics, audio, and a little bit of art.
Definitely served its purpose as an introduction to game development. Very Comprehensive.
Many games used very “Viking code”
My term for game jam code. Essentially code not focused on elegance, just function.
Very Domain Specific
Many of the games had a specific set of levels. Expanding them to full-fledged games could only happen with great effort.
Lots of code refactoring
CSCI 445: Computer Graphics
Very broad covering of Computer Graphics and Computer Vision Needed to cover all aspects of how computers display graphics and look at
images.
Started with basic 3D Math
Vectors, matrices, transforms
Did some canvas programming in HTML5
Discussed differences between 3D art programs, parametric programs like OpenSCAD, and real-time programs like Unity3D
Projects varied from scripted 3D scenes to 3D games to oceanic simulations.
Not a lot of focus on real-time rendering or programming directly in a 3D stack like OpenGL or DirectX
Component-Entity System
A variant of the “Composite” Design Pattern
All game objects are treated as containers of components.
All components derive from a “component” interface.
Main functionality of the component interface is an update function.
All components link back to their parent Entity
Engine contains a list of all components in the scene, and loops through them every frame, calling their update function
Essentially all component subclasses are treated as components.
Component-Entity System
Easily Serialized
Each component has a serialize() function that outputs all public variables and any others needed to instantiate it into a textual format.
Can interact with editor via an inspector
Can be saved out to a scene file
Game Systems – Components for the Engine
Can also treat discrete systems as components.
Main systems are: Graphics, Input, Sound, Collision/Physics and Scripts
Can load systems independently of each other
Systems that don’t need to be linked together are kept separate
Can load a specific system for debugging
Can keep systems independent of components, if libraries are ever switched
Switching Renderers or Audio Libraries based on need
Can strip down for mobile if needed
Designing my own
Libraries used: OpenGL and SDL
Brief Summary of Real Time Computer Graphics
Before the GPU
Vector3’s or vertices are taken as points in model space
Multiplied through one or transformation matrices to get them into world space.
Vertices are mapped in groups of three to an array that holds which three vertices create a triangle
Passed into the GPU
Stage 1: Vertex Shader
All vertices pass through this function and are passed along in groups of three to the fragment shader.
Often where vertices are moved from world space to camera space, such that the camera is at 0,0,0 relative to all vertices.
Brief Summary of Computer Graphics
Fragment Shader
Also known as the Pixel Shader
Takes a fragment, or a triangle that’s on the screen, given by the vertex shader and processes each pixel.
Determines what color each pixel should be and outputs it to the monitor.
Bottlenecks
Amount of triangles – GPU bound
Complexity of Computations – GPU Bound
Many Objects – CPU Bound
My OpenGL Graphics System
What you usually have to do:
Create Data Buffers
Vertices, Triangles, Normals, Textures
Bind the buffers to the GPU
Send the data
Get the locations for shader program data
Pass in data to the shader functions
Enable the attribute arrays
Draw the vertices
Disable the attribute arrays
Bind data for the new object
Send the data
Enable the attribute arrays again
Draw the new vertices
Set the new program
Create new data buffers
Draw new arrays
My OpenGL Graphics System
What I want to do:
For meshes: component.update();
For the graphics system: system.update();
Much abstraction is needed.
Abstracting OpenGL Into Something Manageable
Transform Class – Holds locational data for an object
Has reference to its parent transform, so that objects can have children and parents
Mesh Class – Relevant mesh data
Vertices, triangles, normal
Shader Class – Compiled GPU Program
Material Class – Link to Shader and the data for the pointer like textures
Mesh Renderer Class – Points to Mesh and Material classes, actually sends data to GPU and draws it.
Graphics System
Engine-side system used to manage all graphical data
Holds window, context, and other GPU Specific data and pointers
Solely responsible for holding graphical settings.
Also handles any post-processing effects that affect the entire screen
All this discussion is probably boring, so let’s look at some examples!
Case Study: Unity 3D
Technically now just Unity 5
Lots of books, lots of games, lots of documentation. Can be ported to basically anything.
Pillars of Eternity Highlights everything good and bad about Unity
The good
Ridiculously versatile. Pillars uses a combination of pre-rendered backgrounds and 3D rendered characters to create an isometric effect.
The Bad
Poorly Optimized. Not only is the game rife with bugs, but for skeletal characters, each bone is considered a separate object, creating lots of needless overhead. When the game has to display a lot of characters, the game chugs.
Maintenance is not simple. Once the game is packaged, all assets are stored in binary files for quick access. Patching requires a rebuild, instead of patching a script or two.
Case Study: Unreal Engine 4
Even more Games, even more documentation, few books
Hundreds of games made by hundreds of developers.
This is the everyman’s engine for AAA developers, and has been for nearly two decades.
Source code Access via Epic Games’ Github
Essentially unlimited moddability, as long as you’re willing to modify the source code.
Not very scalable for weaker machines.
Learning Curve can be a bit high.
Case Study: XNA and Monogame based Engines
James Silva and John Sedlak: Building XNA 2.0 Games
Focuses on 2D
Uses modern animation ideas rather than focusing on pixel art
Focuses around building reusable tools and an editor, rather than building a specifc vertical slice of a game.
Limitations of this approach:
Scope limited game engine
Final Case Study: Overgrowth
A game engine and game made by David Rosen over the last 7 years(!!)
Ninja Rabbit Combat!
Extremely well-featured. Includes a complex procedural animation system, an extremely in-depth game editor, and lots of neat graphical and physics features
Used to make a couple variations of itself, a fighting game, and an action-adventure game, primarily.
Very scope-limited to its own game, although within already implemented mechanics, very versatile.
Conclusion of Game Engine Studies
An engine can be
Portable to different kinds of games
Well Optimized
Scalable
Useable
Pick 3. That’s what’s realistic for you to implement
Unreal Engine Unity 3D Phoenix Engine (Overgrowth)
Well OptimizedPortable to different gamesUseable
Portable to Different Kinds of GamesScalableUseable
Well OptimizedScalableUseable
Choices I would make Knowing what I know now
C# and Monogame, not C++
2D, not 3D
General-Purpose engines are interesting, but not practical to create
Making engines is hard