Firestorm Engine

ADVANCED 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 dont 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

Vector3s 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 thats 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 lets 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 everymans engine for AAA developers, and has been for
nearly two decades.

Source code Access via Epic Games Github

Essentially unlimited moddability, as long as youre 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. Thats whats realistic for you to implement

Unreal Engine

Unity 3D

Phoenix Engine
(Overgrowth)

Well Optimized
Portable to different
games
Useable

Portable to Different Kinds of

Games
Scalable
Useable

Well Optimized
Scalable
Useable

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