Date post: | 17-Jan-2017 |
Category: |
Engineering |
Upload: | timo-heinaepurola |
View: | 172 times |
Download: | 0 times |
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