ARTtech seminar: Timo Heinäpurola: Mobile Game Engine Development at Reforged Studios

00:00 hi everyone our next speaker is Timo

00:03 haina portola from Riyadh studios where

00:06 he works as senior engineer and he's

00:08 going to talk about mobile game engine

00:10 development at the studio welcome

00:21 so hello everyone and welcome to this

00:25 talk about mobile game engine

00:27 development of reefer studios so I'm

00:30 going to start off with the short

00:31 introduction of the company and myself

00:33 followed by why we actually start

00:36 developing custom engine in the first

00:37 place that's actually a question that I

00:40 hear quite a lot and the majority of the

00:45 presentation will actually be about

00:46 in-house engine development principles

00:47 and processes so to start off the

00:51 company was found in 2015 so a bit over

00:55 a year ago in helsinki finland by for

00:57 industry veterans so people who've been

01:00 developing games such as league of

01:01 legends wool of warcraft Need for Speed

01:03 a long list of really high-profile

01:05 titles actually and as a company were

01:07 focused on mobile games of almond and

01:09 creating unique wells so my name is

01:12 dimma Hannibal I'm basically a game

01:15 engine enthusiast you could say I

01:17 started programming when I was about 11

01:18 started working on engines when I was 14

01:20 so I've been doing this for pretty much

01:22 as long as I remember and still having

01:24 tons of fun I actually started in the IT

01:28 industry so my industry experience comes

01:31 from there originally I did that that

01:34 for five years but during those five

01:36 years I had this burn to actually be in

01:39 the game development industry so I

01:41 started doing some indie development in

01:42 addition to basically hobby development

01:45 as well so at least one game didn't

01:48 really make that well develop it with my

01:50 own 3d game engine though so I ended up

01:53 moving to bugbear entertainment where I

01:56 initially started working on rich racer

01:58 drift topia did some work worked there

02:01 but my main priority was actually

02:03 working on next car game wreck fest as

02:06 the lead programmer towards the end of

02:09 the project then after that moved to

02:12 next games started working as the lead

02:14 programmer on the walking dead

02:16 no-man's-land and also did some work on

02:19 compass Pointe West so enamored reforge

02:23 and my responsibility is basically the

02:26 in-house engine development process so

02:30 this basically means that I maintain the

02:32 vision of the engine but I also do most

02:34 of its Duvall

02:35 so we actually have a very flat

02:37 hierarchy at the company so people are

02:39 working in different disciplines or

02:41 different areas of the game and the

02:43 engine but my responsibilities made it

02:46 to basically make sure that everyone has

02:48 all the information that they actually

02:49 need to work on features on there so why

02:54 did we start developing custom engine in

02:56 the first place we're basically building

02:58 an army metalurh so this means that we

03:00 have a large number of units and effects

03:03 on the scene at the same time and a

03:05 solution that actually many companies do

03:08 or take is that they use billboards for

03:10 for all the characters to basically cut

03:13 down on the rendering time but we didn't

03:15 want to do that we wanted to create a

03:17 more vivid and more complex environment

03:19 with complex animations and effects so

03:21 this basically led to very specific

03:23 rendering requirements so as us as a

03:28 small thought game here imagine that

03:30 this bush here we present us developing

03:32 our game and the task at hand is to

03:35 actually penetrate this bush with the

03:37 right kind of tool so which tool should

03:39 we choose if we have two options the

03:41 machete or the Swiss Army knife both

03:44 basically achieve the same task but

03:47 there's differences in how well to

03:48 actually do that so as you might have

03:51 already guessed a Swiss Army knife here

03:53 basically we present engine products so

03:57 for us basically we had relatively or we

04:01 have very specific needs for the render

04:02 as already mentioned so we would have

04:05 basically needed to do quite a lot of

04:07 modifications to the engine but this

04:09 meant that we would have basically

04:10 needed a full engineering team to really

04:14 take control of the engine and to

04:16 actually modify and we only needed a

04:19 relatively small set of these features

04:21 because there's a lot of features in

04:23 existing engines that are targeted

04:25 towards different kinds of games and we

04:27 didn't need those and these tools that

04:32 we could have basically used we're not

04:33 really a perfect fit for us either so we

04:36 started looking at custom engines custom

04:39 engines basically it could be simple and

04:41 efficient they could target is very

04:43 specific need that we had they would

04:45 also be a lot easier to modify and fix

04:49 because we have the historical knowledge

04:50 we actually understand how the engine

04:52 was developed and how it basically works

04:55 and we only need of the blade so we

05:00 needed a very specific tool for a very

05:02 specific kind of game so now mr. looking

05:07 at how we actually do this thing so

05:10 first of all I'm going to go through a

05:11 couple of engine development pillars

05:13 players that are pretty much underneath

05:15 anything that we do on the engine so

05:19 first of all we have strict resource

05:20 management then we have lean and clean

05:21 code and multi-platform development I'm

05:24 going to go through each of these in a

05:25 bit more detail now so to start off

05:29 strict resource management what this

05:32 basically means for us is that every

05:34 system is basically responsible for

05:36 managing their own resources on mobile

05:39 platforms it's really important to

05:41 remember that the amount of resources

05:43 that you can actually use is typically

05:46 not very near to how much resources the

05:49 device theoretically has so basically we

05:56 need to be really careful with how much

05:58 and how we actually use those resources

06:02 there are a couple of types of resources

06:05 everyone basically knows this but the

06:07 first that I'm going to cover here is

06:09 CPU time so on mobile one thing that we

06:12 really need to take into account is that

06:14 it's not all about the frame rate and

06:17 how much like the percentage of how much

06:21 you actually use from the processing

06:23 power you need to look at the energy of

06:25 how much you're actually using so how

06:28 much how much energy your process is

06:30 basil basically using when it's

06:32 computing stuff so basically if you

06:36 reach 60 frames per second with ninety

06:38 percent processor utilization that's

06:40 probably not a good idea because you're

06:42 going to be eating through your battery

06:44 pretty quick so the second type of

06:49 resource is memory so for us basically

06:54 all allocations or remember all memory

06:56 allocations actually go through our

06:59 custom memory manager so this basically

07:02 allows us to keep really good track of

07:04 how much memory were actually using and

07:06 where we're doing the allocations the

07:09 memory manager also provides us with a

07:11 lot of utilities and tools that help us

07:13 you know do this tracking and actually

07:16 optimize our memory usage we also

07:20 encourage all systems to do pre

07:23 allocation as much as possible so when

07:27 initializing a system we try to

07:29 pre-allocate as much of the memory that

07:32 we actually need for processing and then

07:34 of course d initialize or free that

07:36 memory when the system is they

07:37 initialize the memory manager actually

07:41 supports pooling pooling is basically

07:44 the idea of you know grouping memory

07:46 allocations depending on how you're

07:49 using it were you using it and we have

07:51 two types of polls actually we have

07:53 static polling and we have dynamic

07:55 polling so dynamic polling typically

07:59 allocates from the heap and first you

08:02 can create your own heaps but the idea

08:04 is that it is it is for dynamic memory

08:06 usage where you don't necessarily know

08:08 how much memory actually going to need

08:10 static pooling on the other hand

08:12 basically allocates a block of memory

08:14 that we can then allocate our actual

08:17 objects or the data that we actually

08:19 need from and these can form hierarchies

08:22 so this way we can basically more easily

08:25 group our memory allocations based on

08:28 system and based on usage then we have

08:33 allocators which are basically the

08:35 primary interface for allocating

08:38 allocating memory basically so we have

08:40 first of all we have scratch allocators

08:42 which are really good for things like

08:45 per frame allocation where we actually

08:47 need to allocate some memory for the

08:49 frame operations but we don't need to

08:51 persist those allocations so we can

08:54 basically flush the buffers after after

08:57 we're done with the frame then we have

09:00 object allocators which are really good

09:03 for recycling memory for objects so we

09:05 know the size of the allocations and we

09:07 actually have built on top of this

09:09 low-level object allocator system we

09:12 have a

09:13 macros and templates that are basically

09:14 there to enable constructor and

09:17 destructor logic to build to be built on

09:19 top of that so next up we have leaning

09:24 clean code as the second pillar here so

09:27 what we aint aim to aim to do basically

09:30 in the engine is keep the code base as

09:33 lean and clean as possible so we have a

09:36 number of things number of items here

09:38 that help us with that or that we follow

09:40 to basically reach this goal so we have

09:44 Orthodox C++ small interchangeable

09:46 elements self commenting code upfront

09:48 complexity and finally data oriented

09:50 design bitter in the design is a very

09:54 important topic and I'm going to use a

09:55 bit more time to talk about that once we

09:57 get there so first off object for

10:02 orthodoxy plus what so what Arthur doc

10:05 C++ basically means is that we trying to

10:09 use them we try and minimize the number

10:12 of C++ features that we actually use so

10:15 we focus only on the features that

10:16 really provide value to us so we don't

10:19 use C++ features just because they are

10:21 there just because they're cool but

10:24 instead we use them only because we

10:26 really need so things that we don't

10:30 actually use real-time type information

10:34 of runtime type information exceptions

10:36 sequel ha streams and we all the only

10:39 use meta programming in moderation so

10:42 very conservative current server they

10:44 blew all our code is is written or all

10:48 the engine code is written in C style

10:51 interfaces so we use sea salt interfaces

10:53 there this basically means to two major

10:56 things so we have all pake structures

10:58 and we have function of function naming

11:01 certain types of function naming so to

11:03 explain these basically you can see on

11:05 the right hand side image here at the

11:08 very top you can see the struct entity

11:10 which basically is just the forward

11:12 declaration of that there's an entity

11:14 somewhere in there but we're not talking

11:17 about what it actually means or what

11:20 kind of data it contains and then we

11:23 have a number of G that's not really

11:25 readable but

11:26 anyway we have a number of functions

11:29 that actually just take pointers to that

11:32 object and those are actually the

11:34 operations of the system object creation

11:38 all also goes through functions so this

11:42 basically leads to explicit very file

11:44 object life cycles so the system can

11:48 track which objects have actually been

11:51 created when they're actually freed if

11:54 they are free to when the system is they

11:56 initialized and all of that and all

12:02 implementations are actually contained

12:04 in the cpp files so we don't really

12:08 include a lot of functionality in as in

12:11 line methods or as we don't write

12:14 classes that have a lot of you know

12:16 fields in there in the header actually

12:19 define all the internals in there so

12:21 this basically leads to the fact that if

12:25 we actually change the internals of the

12:27 system add new fields modify

12:30 functionality this doesn't propagate

12:31 into the compilation time of the system

12:33 so that is the very clear reason why we

12:36 actually do that it also makes the code

12:38 interface a lot simpler and a lot easier

12:41 to read so small interchangeable

12:48 elements basically we try and write all

12:52 our code in small interchangeable

12:54 elements so small functions and macros

12:57 instead of huge monolithic ones and the

13:01 idea is basically is that we do that

13:03 upfront we basically minimize the amount

13:06 of refactoring that we actually need to

13:08 do when we need to you know add new add

13:11 new functionality using that

13:13 functionality so it basically helps us

13:15 in doing that and it also improves the

13:17 readability of the code and lowers the

13:20 barrier of entry for people who haven't

13:22 really been working on the code before

13:24 so it's easy to read and it kind of

13:27 automatically documents the code so this

13:30 actually brings me to my next point

13:32 which is self commenting code this is

13:35 something that's been this got discussed

13:37 quite a lot and P some people believe

13:39 that you

13:40 should comment a lot some people that

13:42 you know you should explain everything

13:43 in code and we're kind of on the middle

13:45 ground here but we prefer function and

13:48 variable naming over commenting so

13:51 instead of writing really long comments

13:53 we try and explain everything using code

13:55 itself this isn't of course always

13:57 possible what we but we strive to do

13:59 that the benefit is really that code

14:03 documentation is automatically

14:04 maintained for the most part at least so

14:10 often complexity basically a lot of code

14:16 tends to be relatively complicated of

14:18 course in game game development and you

14:20 get it you get into functionality or you

14:22 get into functions that might be really

14:25 really complex terex to actually

14:27 understand and then you have these quite

14:30 often you write these really simple

14:33 interfaces that you know don't really

14:37 tell you what the function actually does

14:39 so that is one thing that we don't do

14:42 either we try and write our interfaces

14:44 so that you can actually understand this

14:47 this functionality is going to be really

14:49 complex it's going to be really

14:50 expensive so from the point of you know

14:55 from the time that you actually start

14:56 using the functionality you immediately

14:58 see that this is going to be really

15:00 expensive say try and not use that

15:03 because a friend actual tell me once

15:06 that if you see magic in code it's

15:09 probably just a really dirty tricks

15:10 there's no such thing as magic in code

15:12 so you should get immediately wary if

15:14 when you do that as an example here a

15:19 real life example actually if you we

15:23 have we had a get distance field

15:24 function which basically you know the

15:29 name implies it basically returns a

15:30 distance field okay but it was actually

15:33 computing this distance field so we had

15:35 occasional frames where we actually got

15:37 this method called and we have glitches

15:40 on those frames but it was really hard

15:42 to actually find because it was an

15:43 occasional friends so that is that it's

15:46 one thing for instance you should just

15:47 buy a small change just call it

15:50 calculate distance field that

15:52 communicates that it's actually going to

15:54 be

15:54 more expensive so now basically two I

16:01 guess my favorite topic in a way which

16:04 is data oriented design so what data are

16:08 into design is basically about is that

16:10 everything is regarded as transformation

16:13 of data from one form to another it

16:16 might be creating new data modifying

16:18 existing data or creating new data but

16:21 it's still transformation so basically

16:24 every problem is regarded as a data

16:27 problem and this means that we don't try

16:30 to express these really complicated

16:33 structures and communication between

16:35 these different concepts in the real

16:38 world we don't try to implement that in

16:40 the code itself but instead we look at

16:43 what the actual data is that defines

16:45 that concept and what the processes are

16:48 that operate on that we also separate

16:52 function from data so this means that

16:55 basically different processes can

16:57 operate on the same data and we can

17:00 build more complex operations that are

17:02 actually easier to understand because we

17:04 don't need to have all that glue between

17:06 the different objects and concepts one

17:10 real really core concept of data or into

17:12 design is that all applications are

17:14 actually run on physical hardware real

17:17 tangible physical hardware not some

17:20 academic daydream basically but on real

17:24 hardware so this thinking basically

17:27 allows us to organize the data in such a

17:30 way that is optimal for the different

17:33 target systems organization of the data

17:37 of course depends on how we actually use

17:39 the data and this is why it's super

17:41 important that we actually understand

17:43 our problem really understand the

17:45 problem and the data not just the

17:48 interfaces between the object what we

17:50 actually need to do to achieve the

17:52 results so optimization for us of course

17:57 is really important and to understand

17:59 why the data layout is so important on

18:02 CPUs we need to go through quickly how

18:07 memory is basically structured so again

18:10 this might be something that you know

18:11 people have pretty good knowledge about

18:14 but I'm still going to go through that

18:15 to basically make sure that we're on the

18:17 same page here so basically we memory is

18:20 built on hierarchy you have registers

18:24 which are the closest to the AL use

18:27 their the workhorse of computations

18:29 basically then you have a number of

18:31 caches l1 l2 l3 you could have an elf

18:34 for as well and these are really fast

18:36 blocks of memory that are actually on

18:38 the CPU chip itself and then finally you

18:42 have deer on which is the slowest type

18:44 of memory that we're going to be talking

18:46 about here of course we have disk we

18:47 have DVD and so on so when accessing

18:52 memory and updating the ballys in the

18:54 registers the CPU actually first checks

18:57 if the address can be found in the cache

18:59 in a cache which cash depends on the

19:04 implementation so not finding in a dress

19:09 and the cache is called a cache miss and

19:11 if a couch Mase happens then the

19:13 processor will basically have to go do a

19:15 round trip to the DRAM an issue a memory

19:18 read why this is so important is that

19:22 the DRAM is about 20 times slower than

19:25 the l2 cache and about 200 times slower

19:28 than the l1 cache these are empirical

19:31 values not you know to specific

19:34 architecture though but roughly to get

19:37 the scale of things and add it to that

19:41 caches are actually updated than bursts

19:44 so full cache lines are read at an ever

19:47 every time basically a cache miss

19:49 happens and when the D rom needs to be

19:53 accessed so how we actually utilize this

20:00 we can actually utilize the cache

20:01 updates by basically grouping data that

20:06 is used together group it together group

20:09 it basically so that it's close to each

20:11 other this basically allows for memory

20:17 reads to read more data at any time more

20:20 important data and results in fewer

20:22 cache misses overall also we try and

20:27 process as much of the same type of data

20:32 objects at the same time with the same

20:35 code because this basically also

20:38 improves the instruction cache

20:39 utilization because instructions that

20:43 the processor actually execute our data

20:45 as well so they're also read through

20:47 caches and as already kind of mentioned

20:52 ketchup states will also fetch the

20:54 vicinity of the address there so they

20:56 will fetch important data if we have all

20:58 that data laid out consecutively in

21:01 memory actually have a couple of

21:03 examples here about data oriented design

21:06 overall coming up so the pros and cons

21:13 first of all it's actually really easy

21:15 to unit test data on to design

21:18 applications designed that way because

21:20 you have the data readily accessible

21:21 it's not hidden behind some arcane

21:24 objects it's basically easy to verify

21:27 that the data is actually correct it's a

21:30 lot simpler to refactor because you have

21:32 sets of data you have processes

21:35 operating on that data so you don't need

21:38 to handle these dependencies between the

21:40 objects create intermediate objects just

21:43 because you need to handle a certain

21:45 dependency and it's also really hardware

21:48 friendly which is really good for an

21:51 application cons basically the major

21:54 Connel varies mentioning here is that it

21:57 does require a paradigm shift so if

21:59 you're used to object-oriented

22:00 programming you might be in for a

22:03 surprise so finally the third pillar is

22:08 multiplied from development so basically

22:13 the you know the game that we're

22:16 actually making needs to run on multiple

22:18 platforms we have development platforms

22:21 when as Windows Linux OS X and we have a

22:25 couple of target platforms which is like

22:27 iOS and Android and actually also

22:30 linux is also a target platform because

22:31 our server environments use that so how

22:35 do we actually manage this whole thing

22:37 well basically will you see make see

22:41 make is basically a tool that executes a

22:43 certain kind of script that defines the

22:46 projects in the platform independent

22:48 manner and once he make then does is

22:51 that it generates the platform dependent

22:53 versions of these projects and this

22:58 basically allows us to not care too much

23:00 about you know of course we need to care

23:03 on the programs that we need to care

23:04 about what kind of code we ride for the

23:06 different platforms but we don't need to

23:08 make changes into all of the different

23:10 projects to just make it work on each

23:11 plunger a platform will support it early

23:15 and now we're basically is keeping it

23:16 working and we're actually helped here

23:19 by continuous integration and automated

23:23 testing currently automated testing

23:25 actually means unit testing but we're

23:27 also planning on a wider ranging

23:29 integration testing framework so how do

23:33 these things then actually fit into the

23:35 real world well here's a case study of

23:39 how we develop the effect system itself

23:42 so it all started with a need basically

23:45 we already have a particle system so we

23:49 had a system for rendering and spawning

23:52 particles but what we didn't have was a

23:55 system for game code to actually trigger

23:57 the effects and we also wanted to have

23:59 tools and a way for artists who actually

24:02 create effects easily and with minimal

24:05 engineering effort and also effects can

24:09 be wildly complicated they can have like

24:11 multiple meshes lights multiple particle

24:13 limiters and all that so we didn't have

24:15 these kinds of structures so then we

24:18 asked ourselves a lot of questions so

24:22 what kind of effects would we have how

24:25 game code actually like to control these

24:27 effects and finally how would artists

24:30 really want to create these effects etc

24:34 so we actually believe in long

24:36 discussions so we we have quite a lot of

24:38 discussions between the engineers about

24:40 different different areas of the engine

24:43 and

24:43 of the game code itself and this is

24:46 basically something that we do to get

24:48 everyone aligned with with the problem

24:51 domain and can understand what we're

24:53 actually doing here so overall this

24:56 leads to autonomous working better

24:58 autonomous working because we know that

25:00 everyone has an more or less same ish

25:02 understanding of that of the area so

25:07 when we were finding answers to these to

25:11 these questions we noted a couple of

25:13 things that we needed to take into

25:14 account for the when designing the

25:17 architecture so first of all needed to

25:19 be super easy to extend it needs it to

25:22 be easy to use from game code and it

25:24 also needed to quite naturally have

25:27 really good performance so what we

25:31 basically ended up with the front face

25:34 of the system is called the driver

25:36 system and in this driver system

25:38 basically the game code actually knows

25:40 only of a single data structure which is

25:43 returned to it when the effect is

25:45 created this also have act as access the

25:48 handle to the effect game code then

25:51 updates properties in this data

25:52 structure after this the driver is run

25:57 on this data once per frame and it

26:00 updates the actual effect based on this

26:02 data so only the driver actually needs

26:06 to know about the details of how the

26:08 effect itself is built or small parts of

26:12 the details which I'm going to be

26:13 talking about in a bit the engine also

26:16 supports a number of a number of default

26:18 drivers but game code can also implement

26:21 their own ones if they want to so

26:25 effects are basically build up of

26:27 components they're basically just a

26:29 collection of components and this system

26:35 is actually built on top of the same

26:37 system that anything else in the scene

26:39 so basically we can attach anything into

26:41 an effect we can attach a model lights

26:44 whatever basically is in the scene so it

26:48 adds a lot of a lot of flexibility and

26:50 it's data-driven so all of this data can

26:53 actually be loaded from configuration

26:56 files

26:56 configurations and setups of the

26:58 components so what is this entity

27:02 component system then well first of all

27:07 it's an example of data or interdesign

27:10 so in an entity system entities are

27:13 actually just the sums of their

27:15 components a component defines a certain

27:20 set of data that defines parts of the

27:23 entity and we also have component

27:26 systems that operate on this data and

27:29 basically this all-in-all defines what

27:33 the entity itself is so we don't define

27:37 these the concept actually encode but

27:40 instead we implement the concepts

27:41 themselves each component is also

27:47 associated with one system for doing the

27:50 crucial operations of the component so

27:53 each system basically defines multiple

27:55 processes these could be updating could

27:58 be our rendering etc and this overall

28:04 this allows for optimizations on a

28:06 system versus by a system basis based on

28:09 how the processes are actually using the

28:11 data itself but all components are still

28:17 accessible and modifiable globally so

28:19 this seemingly tying the code to the

28:23 data is only for the more processing

28:27 intensive stuff so each component is

28:32 basically variable globally so we can

28:35 basically link components to each other

28:39 through their unique IDs which their

28:42 associated when the components loaded so

28:45 here's a little code this isn't this

28:48 isn't the engine code but it's basically

28:49 it has the same principles um so here

28:54 you can see the header file on the

28:55 left-hand side yeah it's readable good

28:58 so on the left-hand side you can see the

29:00 header file which is basically very very

29:02 simple again this reflects what I showed

29:05 earlier on simple C style code

29:08 so we have the forward declared

29:10 transform which is the component data

29:13 and then we have a single function you

29:16 could have a bunch of other functions of

29:18 course here but this is the most

29:19 important for this this use case so it

29:22 finds the component based on the ID of

29:24 the component so on the implementation

29:27 side here you can see we have actually

29:30 defined the structure so it contains a

29:31 position and rotation then we have a

29:33 number of vectors we have one for the

29:36 transforms 14 world matrices and one for

29:40 the transform component IDs and then we

29:44 have transformed update this is

29:47 basically a process of the trial of the

29:50 component system so this is called by

29:53 the entity system when we need to update

29:54 all different components and then we

29:59 have the other function here which

30:00 basically just loop through loops

30:01 through the ids and it returns the

30:04 correct transform so looking at the

30:07 implementations here it's important to

30:09 note that the first function actually

30:11 only accesses the position rotation

30:13 information and writing out the world

30:15 matrix so it makes sense to actually

30:18 have the position and rotation

30:19 information close to each other because

30:21 that's what we're operating on so that's

30:24 what we have the transform component

30:25 there and then in the find you can see

30:29 that we only are accessing the IDS of

30:32 the components so we don't really need

30:35 to access the data stored in the actual

30:37 transform components so we can basically

30:39 just iterate through all the ideas in

30:43 consecutive memory keeping the cache

30:45 odds and then finding the correct ID and

30:47 returning a pointer to the same

30:49 transform at the specific index so this

30:53 basically allows us to have different

30:55 use case at different layouts for memory

30:58 depending on how we're actually using it

31:00 and as a final note on this slide the

31:04 transform find function isn't really

31:06 very safe some of you probably might

31:07 have noted that and this isn't actually

31:09 something we're going to be doing in

31:11 production it's for demoing purposes in

31:15 production we actually have quite a lot

31:17 of you know complicated structures for

31:19 optimizing the different layouts

31:21 specifically in this run

31:22 form component actual so with that in

31:26 mind we create a simple effect we had

31:30 just has a two components basically we

31:32 have a transform component and we have a

31:34 particle emitter component and these are

31:36 linked to each other so the particle

31:38 component knows about the transform

31:41 component then we have the game code

31:44 modifying the data that is provided to

31:46 it when the effect is created the driver

31:49 is being run on that data and it

31:51 basically updates the transform

31:53 component so it only needs to update

31:54 your transform component where where the

31:56 effect is actually going to be the

32:01 particle emitter can now retrieve the

32:03 position rotational information from the

32:05 transform the snowing where to spawn the

32:07 particles and at which orientation so to

32:13 summarize the architecture it is

32:15 data-driven so artists can basically

32:18 create effects by creating and creating

32:22 a file and effect file basically a JSON

32:24 file and of course we have tools we can

32:27 we can build all kinds of tools on top

32:29 on top of this then we have a very

32:32 simple interface for actually using the

32:36 effects from game code and the effects

32:40 are built in a componentized manner so

32:43 that we can we can basically extend the

32:46 system really easily by creating new

32:48 components so the system is also

32:52 performance critical which in our case

32:55 actually means multiple simple effects

32:59 versus a few complicated effects meaning

33:02 again that we need to be able to fosston

33:05 we need to be able to spawn new effects

33:08 really fast and the way we were actually

33:11 doing this is that when we're first

33:13 encountering a temblar or an effect

33:18 template we create we create a binary

33:21 representation of that template so that

33:24 creating a new effect actually just

33:26 becomes pretty much a memory copy

33:32 naturally updating and rendering also

33:35 needs to be super fast

33:36 so I still have time for a example here

33:40 of another example of data oriented

33:42 design actually which is particle

33:46 emitter component optimization

33:48 specifically updating specific

33:50 properties so let's say that for this

33:54 example we have a particle that contains

33:56 position velocity rotation and color

33:58 information and we have multiple

34:03 particles being emitted by this with one

34:05 emitter and then we have multiple

34:07 limiters a very typical example

34:11 operators then actually touch only a few

34:14 properties at a time so first looking at

34:18 a naive implementation we would have

34:21 them defined in a single structure each

34:23 of those properties and multiple

34:25 instances of that structure and let's

34:27 say a cache line for this example here

34:30 contain could contain only a single

34:33 structure at a time so the component now

34:38 iterates through each of these particles

34:39 but only the position and velocity are

34:41 actually touched so the rotation color

34:45 information is actually unnecessarily in

34:47 the cache line so what we did is again

34:51 we looked at how we actually use the

34:53 data and we group that data based on

34:56 that so instead of having them all the

35:00 properties in the same structure we

35:02 actually have them laid out property by

35:04 property consecutively memory so when

35:07 we're accessing individual particles

35:10 we're accessing individual indices at

35:12 the Indies arrays but at every index

35:16 we're actually reading in important data

35:18 for the next particles that we're going

35:21 to be processing so that basically

35:25 summarizes it um we chose a custom

35:29 engine for reasons of performance and

35:31 control we also keep a really tight

35:34 focus on how we actually a what we

35:37 actually do on the engine and this

35:39 basically allows us to keep the team

35:41 small and nimble I also show basic

35:45 pillars of how we develop the engine

35:48 an effect system case study for how we

35:51 actually do this thing in the real world

35:56 so here's the we're hiring slide so if

36:01 you're interested please go and check

36:03 out our web page and also here's here's

36:08 some personal data as well have a

36:10 Twitter account so if you are interested

36:13 in some tidbits of tech information go

36:16 follow me and then also my facebook

36:19 public facebook page for that I use a

36:21 son kind of a blog at you small small

36:24 block post in as well so that's it thank

36:28 you and I think it's time for questions

36:41 you

36:51 hi you talked a lot about a lot of code

36:55 cleanliness and the performance of it my

36:59 question basically would be the day that

37:01 what do you do when these two sort of

37:04 end up clashing and an example that I

37:06 used here is this is use of vector

37:08 instructions you can do a lot of really

37:10 powerful stuff by like embedding a bit

37:12 of assembly code into into your code

37:14 with a bit of if deaths or easier it's

37:18 your cleanliness basically force you to

37:20 but it just sorta like structure the

37:22 data data so that the compilers

37:24 optimizer will do it for you yeah so

37:28 basically the question is that what do

37:30 we actually do if different principles

37:33 here clash and that we you know we

37:35 actually are kind of forced to optimize

37:38 more right a bit dirty code or yeah that

37:42 I do view or is like hard headed towards

37:45 that okay well if you're gonna have to

37:47 rely on the on the compiler to do that

37:50 to do that or and we'll do it or we'll

37:54 do that okay well no we're not going to

37:56 be completely hard-headed about this

37:57 we're gonna do do a bit of at a bit of

38:00 assembly code there so it looks a bit

38:02 ugly but it produces better results yeah

38:05 yeah we're so yeah basically we use

38:08 common sense so we're not hard headed at

38:11 things and one actually one point in

38:14 data or in the design itself is that we

38:15 really need to understand the problem

38:17 and if the problem is something that we

38:19 need to do some tricks with and then

38:22 we're going to do that and but the thing

38:24 is that we try and keep the code still

38:26 like understand as understandable as

38:28 possible but if we need to go a bit

38:30 further in optimization and do some

38:33 really tricky stuff then you know that's

38:36 just what we need to do I mean the

38:37 product is still the most important

38:39 thing but the cleanliness of the code is

38:41 more for arm you know it's it's a

38:46 guideline it's a it's how we what we

38:48 strive for so we're not too afraid to

38:51 actually you know go away from that a

38:54 bit okay thank you

39:00 you

39:06 how often does iOS updates or updates in

39:11 the actual platform break your stuff

39:16 well so the question is like how how

39:19 often does iOS and different platform

39:22 updates actually how often they do break

39:24 our stuff well not much actually because

39:27 we haven't really gone we try and keep

39:30 the code as platform agnostic still as

39:33 possible there are some occasions of

39:35 course when when something happens but

39:38 of course we're not yet in production so

39:41 we're going to see that quite a lot I

39:42 would say but currently it hasn't really

39:45 been that much of a problem and for the

39:48 big part probably because we try and

39:51 keep up the standards we try and

39:53 basically keep the code simple and clean

39:56 and we haven't really needed to do a lot

39:59 of platform dependent heavy

40:02 optimizations as of yet

40:10 any more questions first if you want you

40:17 can come talk to me after this

40:18 presentation as well okay if not then

40:21 let's give it around warm applause to

40:24 the mall thank you