MOBILE GAME ENGINE DEVELOPMENT AT REFORGED STUDIOS

Contents‐ Introductions‐ Why go custom?‐ Engine development principles and processes

Who are we?‐ Founded in 2015 in Helsinki, Finland‐ Industry veterans: League of Legends, World of

Warcraft, Need for Speed...‐ Focused on mobile games and creating unique

worlds

Who am I?‐ Timo Heinäpurola‐ Game engine enthusiast‐ Started programming at 11 and developing

engines at 14

What have I done?‐ IT industry for 5 years

What have I done?‐ IT industry for 5 years‐ Indie development‐ Bugbear

Entertainment‐ Next Games

What do I do?‐ Responsible for our

in-house engine development

‐ Maintaining the vision of the engine

‐ Most of its development

Why go custom?‐ Building an army

battler‐ Large number of

units and effects‐ No billboards

specific rendering requirements

Why go custom?Imagine that this bush here represents us developing our game...

Why go custom?...and we needed to choose the right tool to penetrate this bush.

Which tool should we choose?

Why go custom?Engine Products

‐ Too complex for us to modify for our needs

‐ We only need the knife or the saw

‐ ...but neither is a perfect fit for our needs

Why go custom?Custom Engines

‐ Simple and efficient‐ easy for us to

modify and fix‐ We only need a blade

Pillars of Engine Development‐ Strict resource management‐ Lean and clean code‐ Multi-platform development

Strict Resource Management‐ All systems responsible for their resources‐ CPU time

• Watch out for energy usage avoid too heavy CPU utilization

‐ Memory• All allocations through custom memory manager• Pre-allocate as much as possible• Pooling• Scratch allocators• Object allocators

Lean and Clean Code‐ Aim for a lean and clean codebase

• Orthodox-C++• Small interchangeable elements• Self-commenting code• Up-front complexity• Data oriented design

Lean and Clean CodeOrthodox-C++

‐ Minimize use of C++ features• Only use when of

significant value‐ C-style interfaces

• Opaque structures• Function naming

‐ Objects created through functions explicit verifiable object lifecycle

Lean and Clean CodeOrthodox-C++

‐ All implementation contained in CPP-files

‐ Changes to systems don’t propagate in compilation time

‐ Makes code interface simpler and easier to read

Lean and Clean CodeSmall Interchangeable Elements

‐ Small functions and macros‐ Improves readability and reusability‐ Lower barrier of entry‐ Automatically documents the code

Lean and Clean CodeSelf-Commenting Code

‐ Prefer function and variable naming over comments

‐ Code documentation is automatically maintained

Lean and Clean CodeUp-Front Complexity

‐ Don’t hide complexity‐ If you see magic in code dirty trick‐ For instance, GetDistanceField should never

calculate

Lean and Clean CodeData Oriented Design

‐ Everything is regarded as transformation of data• Every problem is a data problem• Don’t try to implement abstract concepts in code• ...instead focus on what the data is and how it is

modified• Separate function from data

‐ All applications run on real hardware• Data can be organized so that it’s optimal for the CPUOrganization depends on how the data is used

Lean and Clean CodeData Oriented Design – Optimising Data Organization

‐ DRAM, L2, L1 and registers• First try the caches and only then go to DRAM if address

not found• Not finding in cache is called a cache miss

‐ DRAM is around 20x slower than L2 and 200x slower than L1

‐ Caches are updated in bursts (full cache lines are read each time DRAM must be accessed)

Lean and Clean CodeData Oriented Design – Optimising Data Organization

‐ Keep data that is used together close to each other• Allows memory reads to read more important data• fewer cache misses

‐ Process set of same data type on one go‐ better instruction cache utilization‐ cache updates will prefetch next data elements‐ Two examples in effect system case study

Lean and Clean CodeData Oriented Design – Pros and Cons

‐ Pros• Easier to unit test• Simpler to refactor• Hardware friendly

‐ Cons• Requires paradigm shift from object oriented design

Multi-Platform Development‐ Cmake for platform independent builds‐ Port early on and keep it working‐ Continuous integration and automated testing

Case Study: Effect SystemHow did we develop the effect system?

It All Started With a Need‐ We already had a system for rendering particles‐ Game code needed a way to trigger effects‐ Artists should be able to easily create new effects

without code support

...Then we Had Long Discussions‐ What kind of effects would we have?‐ How would game code like to control them?‐ How would artists want to create them?‐ ...

Common Understanding‐ Common

understanding of the problem domain through discussion

‐ autonomous working

ArchitectureWe needed to figure out the architecture that would handle these:‐ Easy to extend‐ Easy to use from

game code‐ Good performance

The Driver System‐ Game code only

knows of a data structure

‐ Game code updates the properties of the structure

DataGame Logic

The Driver System‐ The driver is ran once

per frame‐ ...and updates the

actual effect based on the data

‐ Only the driver needs to know how the effect is built

DataGame Logic

Effect

Driver

Effect ComponentS‐ Effects are collections

of components‐ Implemented on top

of a general purpose entity component system

‐ Data driven

C1 C2

C3 C4

Entity Component System‐ Data oriented design!‐ Entities are sums of their components

• A component defines some part of this data• Component systems define processes that operate on them

‐ Each component type is associated with one system• Each system defines multiple processes• Allows for optimization of component data based on the

process‐ But all components are still accessible and modifiable

globally• Each component has a unique ID that can be used for

referencing

Entity Component SystemImplementation Example

Example: Simple Effect‐ Transform component

defines position and rotation

‐ Particle emitter spawns and renders particles

‐ Emitter links to transform to get position for particles

Particle Emitter

Transform

Example: Simple Effect‐ Game code modifies

data‐ Driver updates the

transform‐ Particle emitter

retrieves particle spawn position from transform

Particle Emitter

Transform

DataGame Logic

Driver

Architecture Summary‐ Data driven – artists

create effects‐ Driver makes the

interface simple‐ Compose and

conquerC1 C2

DataGame Logic

Driver

C3 C4

JSON

Performance Critical System‐ Many simple effects vs. few complicated ones‐ fast spawning of new effects‐ Naturally updating and rendering also needed to

be fast

Optimizing Particle Emitter‐ Single particle has

• Position• Velocity• Rotation• Color

‐ Single emitter emits multiple particles

‐ Many emitters with few particles

‐ Operators touch only a few properties

P V R CP V R CP V R C

P V R CP V R CP V R C

P V R CP V R CP V R C

P V R CP V R CP V R C

P V R CP V R CP V R C

P V R CP V R CP V R C

Optimizing Particle EmitterUpdating Position

‐ Naive implementation‐ Cache line fits a single

particle‐ Component iterates

through each particle‐ Only position and

velocity are touched‐ rotation and color

unnecessarily in the cache line

...

P V R CP V R CP V R CP V R CP V R CP V R C

Optimizing Particle EmitterUpdating Position

‐ Data oriented design group data based on usage

‐ Cache lines contain valid data most of the time

PositionVelocityRotationColor

Summary‐ We chose a custom engine for reasons of

performance and control‐ Tight focus allows the team to be small and

nimble‐ Basic pillars of engine development at Reforged

Studios‐ Effect system overview

We are hiring!‐ Jobs: www.reforgedstudios.com/#jobs‐ Personal

• Twitter: @heinapurola• Facebook: www.facebook.com/heinapurola