Converting your game to DOTS - Unite Copenhagen 

That's my new tagline!

And even so, I watched the presentation at 1.75 speed... It's amazing.

Thanks!

I, for one, have (unknowingly) always been a more data-oriented guy, but, since I am programming-wise not too experienced yet invested, I didn't know how to implement such concept; and this really helps quite a heckin lot!

I hope my face lives up to imagination, though I know that it does not :)

I feel your pain

Thank you!

Thanks

Wakka Wakka

Thanks!

Thanks!

This is an important change for a couple reasons. 1) If using UnityEngine gives you everything, it gives you *everything* whether you need it or don't. 2) by separating it, we have the ability to release updates at different time intervals from the core engine. This way, you don't need to wait for the next dot release to get a bug fix to an auxiliary feature

Junaid Malik

Howdy, 1) You don't "attach" systems. If things match the query, then they run on the data. 2) If your query is pulling entities that you don't want, then you need to refine your query. The entity debugger will show you all the entities that match the queries of your systems so you can tell if it is grabbing the right things. 3) How would the engine know what entities you want to filter for? Granted, there will be more UX iteration and less boilerplate code in the future, but you will always need to determine what entities to query for

in respect to differentiate between Entities that have the same components but aren't the same "type" you use a tag component it's a component like any other, that you attach to an entity, but it contains no data (so it doesn't weigh in memory) and you use this tag to refine your search for instance, both players and enemies may have a healthComponent, and maybe you want a system for the players health only You would add a playerTag and filter with both components there are another talks at unite 2019 that answer this questions, just take a look at the ones that talk about ECS and DOTS I recommend one that's about creating a third person zombie shooter with DOTS

Ya, I thought about doing it that way, but I wanted it to be very obvious that I have created it and then needed to dispose it. "Using" doesn't make that completely obvious to a casual observer

If you are here for the thumbnail, you'll want 6:29

Poppycock!

I also use 2 space indentation :P

@@Bossti AAAAAAHHHHH. You're the type of person my mom warned me about.

The type of person who grew up in the K&R ghetto of C style coding (sameline { and stuff) :D Hey, at least I‘m not using m_ or *gasp* _ as member prefixes. Anymore. :P Also, I can see the appeal of still not using var but then again I try to limit my line width to 120 characters and some type names can get really really in the way of readability. But I don’t mind it when I read other peoples code. It‘s like just because I like Conan Doyle I can also enjoy some Shakespeare

@@Bossti Fair enough. I can get behind that common ground.

Jobs is part of DOTS. You should focus on tutorials like this one that teach you how to use all three pillars of DOTS (ECS, Jobs, and Burst Compiler) together. But many tutorials just use Jobs and Burst Compiler, OR ECS, instead of all 3.

For better or for worse, we've spent a lot of time trying to make code act more like the real world.

It is already -running in its own job (edit: I haven't seen the source, so I don't know if thats the only thing the job it is in does, although it is a fair assumption)- jobified , that's why this demo was possible. What he meant is that it is not efficient to run all those collisions as, for example, some are guaranteed to never collide, such as bullets going the same way an enemy is or bullets higher than the enemy height. There are lot of ways to go about optimising this, some already implemented in the physics engine, some more project specific. Wikipedia has a nice overview under the optimization section of the collision detection article.

@@ChrisDaramouskasGiannikou So the job is not the problem but the implementation?

@@masterneme Exactly, it's an overkill to run collision checks between every target/bullet.

@@ChrisDaramouskasGiannikou I see, thank you.

Yes, what was said is correct. Also, even once an enemy or bullet dies is a collision, all other enemies / bullets still check against them for collision so it is wasteful

try "using Unity.Transforms;"

@@mikegeig4297 thanks for you answer :)

Lots being done at unity (roll eyes)

It's an updated version - hoping to see NEW Code

I've done the talk before. I was asked to deliver it again.

@@mikegeig4297 Thanks for clarifying!

@@mikegeig4297 Great talk, but I would love to see an ECS demo that wasn't just a fancy particle system demo. Rarely do most game entities simply rotate and move forward. It'd be nice to see how ECS can be used for other gameplay tasks such as driving animation, more useful AI/target selection/decision making, event handling such as handling events from triggers, etc. You know, things most people need for a game :).

You could query for any data component they had. In this case though, there wasn't any data that was specific to enemies that no one entity had, so I created an empty one. I could have put data in there, but it would be wasteful since I didn't need any data

@@mikegeig4297 That makes sense. I'll have some more specific data that I could check against. Thanks for the help

There is a system that moves things forward. Check out the repo to see all of the code. I only had time to show a small example

Well that's good

Not all code works with burst. If it was on by default for each method or job, you'd be flooded with "this code doesn't work with burst" messages

There are quite a few factors. Part of it is needing to load much more info into the CPU and traversing memory when dealing with Monobehaviors and Game Objects.

Mike Geig I see, thank you Mike! Actually we are about to start implementing ECS into some parts of our project. I’m expecting it’ll be of great help!

@@lama89625 Let me know how it goes! Definitely plan your data out on paper first. Can help a ton!

@Keeper Holderson Well, first of all, class connections are easier to track. Also classes are easier to group into libraries, refactor or change. I don't know what's possible with ECS, I know only what our team did, and it was not really manageable

There are several titles being developed with this tech. I totally understand about maintenance concerns but have come to feel like it really isn't that bad and in a lot of places can be much easier to extend, maintain, and track. It does require some workflow and design changes though, which can be a large investment depending on your team size and skill set.

We use it for a multiplayer mobile game. Can't imagine doing it without ECS, would a pain due to specific requirements of the game that leverage the performance benefits of ECS. Also writing logic in systems separate from data makes game mechanics more scalable.

Windows built in magnifier now supports hotkey + mouse wheel zooming

Not sure I get what you mean? It's all data either way. Do you mean serializing to a file?

@@mikegeig4297 I suppose? Say you have a game where your carrier space ship is making millions of drones - how would you save that entity data to a file so when they restart the game, those drones reload into play. I'm assuming some similar fashion of calling / creating the entity, but I don't honestly fully understand that either...

@@nicholaswillcox Same as you would with any data. You would run a system on the main thread that queried for all the data you wanted, and then use IO to write it to a file / database / whatever. Loading would work much the same way

Do you have the Hybrid Renderer package enabled?

@@alessandrocolombo4192 thanks, I installed the hybrid renderer and now it get´s rendererd. great. but physics do not work. rigidbody and collider are ignored. I also tried to install "unity Physics" but that does not help.

rigidbody works (I had set iskinematic to true). though I wonder why setting it to false via script does not work. Anyhow - colliders do not interact with terrain or other "normal" monobehavior objects. But they work for entiy colliders.

The demo that was sent out Is shomehow confusing since because you can spawn either go and entities you have also normal monobehaviours but entities interactions as far as I understood and got have to be managed via specific jobs

(I'm not native so in order to avoid misinterpretation I just want to quickly point out that I found this video very clear and useful (I was at Unite too) I used the world confusing as in ambiguous in some points :))

Are you using a material that supports GPU instancing? It really makes the hybrid renderer run more smoothly. May also be something to do with system timing or something.

It's probably reflection, or more likely an extension method for an interface. Can't go far in C# w/o both of those, highly recommend you learn about them.

@@phobos2077_ isn't that bad for performance?

@@thomasanderson1416 not bad if it's done only once during initialization phase. Irrelevant cost for a lot of ease of use benefits.

@@phobos2077_ In that case they could use some sort of FindObjectsOfType internally and it would be even more easy to use. That was my point all along.

@@thomasanderson1416 there is such an option as well via EntityQuery. Not sure if it's possible to process these queries via Jobs though (using multiple threads)

Entities don't "contain" anything, which is why dot notation won't work. They aren't pointers, they don't contain data. They are simply indexes of a memory collection. So manager.SetData(entity...); is more akin to saying myArray[entitiesAreIndexes];

​@@mikegeig4297 Hi Mike, thanks for all your replies. Believe me I do know what DoD is, and its differences from OOP. But I was talking hopefully of another layer of abstraction that could potentially let us keep using SOME of the workflow/UI OOP principles we used to have should we choose to (for good reasons). Mainly the [option] to attach data/system combos (a single script that contains both) just to tag our target entities. Then the ability to automatically query those entities and their data. We'd implement a function like OnSetup() to get any extra data and references like Time.deltaTime then work as we're used to on maybe OnUpdateForEach() (we'd not even need dot access - everything is set from OnSetup()) Unity behind the scene schedules the system on all components that are tagged with the "script" so to speak. That way we can have the best of both worlds without the entity manager and query headache. This is also practical: think if we have identical entities and want to only randomly select some of them to run. All this could be just an option of course, we also could use query system without attaching scripts as well. This is all just a thin layer of abstraction and creativity to make things a bit more terse, I'm not arguing about the data philosophy here and nobody says we can't improvise.

Entities

because it's in early development stages and this is just a demo (I hope)

(good presentation)

It works on either version. The packages update independent of the editor version

@@mikegeig4297 Brillant! My DATA will be happy

@@snaecooceans8744 that's what it's all about!

there is a Unite Talk called Interaction between Entities where they explain this precisely it's not as direct as an oop approach but it's a way better code structure that can save a lot of time, memory, and problems but I'm curious, in which case would I need to compare an entity data with every other entity?? please give me some examples

Lloyd Vincent it’s almost like the packages are marked prerelease for a reason

Good catch on the hybrid renderer part. I forgot to mention it in the talk. To be fair though, it is extremely difficult to mention *every* single aspect of something in a talk. Regarding the repo, I have an updated version that will go live when 2019.3 does. Remember that 2019.3 is beta and isn't out yet.

Thanks for the reply. I don’t expect all the details, just enough that it’s possible to follow along. Great talk otherwise though, between this and some tinkering around I was finally able to get ECS working on my own from a blank project, something which has eluded since late 2018.

@@LloydVincent11 I'm glad you got it working. Let me ask your honest opinion (so I can do better in the future). Obviously, you were frustrated because the talk didn't fully equip you to try this out yourself. I assumed that having the repo would be good enough support to enable that, but as you pointed out the repo doesn't work with the latest beta. If the repo had worked with the latest beta, would that have been good enough, or should I have been more thorough in my presentation explanation?

Totally agree. I even try to point out that this situation is ridiculous and I am only using it because it is an easy to understand example.