hello again

I really enjoyed not coming home exhausted every day, unable to do what I actually want to do.

Of course I was much less productive than planned, but it was a vacation after all.

Yup

So i have run into a issue using the ecs... lets say we have a inventory ( simple list of integers as id's for item-entities ) and we wanna fire events once a item was added, replaced or removed... i have found two ways of doing this, both are pretty ugly. First way... we write a system which tracks the inventory history of each player/entity... and a system which checks the last frame inventory and the current one in order to determine changes.

Second way is that we have three methods inside the inventory component (add, replace, remove) which fire internal callbacks once those methods are used.

Which one would you choose ? What is better in terms of multithreading ?

Do people mix events with ECSs? I thought ECSs don't use events.

Well i would use a entity as a event... thats how i often saw it

The system approach would use a entity as a event while the component approach would use callbacks ( consumer/action e.g. )

Ok probably first another question... is there a way to multithread ecs - systems while they depend on each other ? For example... lets say we have : AddToSendSystem ( Adding attributes we wanna send to the client )... SendSystem ( Runs over the added Attributes for sending them to the client ) and a ClearSendSystem which runs at the end to clear all sended attributes... Is there a way to multithread this ? Or is this impossible because the order matters

You can group systems that are read-only together and run them in parallel. You can also run systems in parallel that don't touch the same data.

@nwp Thanks ! So theres no way to "multithread" system that needs to run after another ? Is there some kind of structure/architecture to prevent such sequential systems ? ^^

@Tyyppi_77 So we store some kind of history for each component with certain read/write acess ? And theres no other way ? For example if we have a physics system running in once thread and a network system in another thread... both are running parallel and offer a good performance... lets say we wanna send physic packets to the client over the network system... so we write another system which runs over physic and network components... and boom

everything requires to run on the same thread because of the sequential execution.

ECS do use events

For the specific question I wanted to do a prediction ECS. Basically you have a stale state from the network. It's stale because you don't get updates every frame, so the state lags behind in time, but it's correct. In parallel you run the physics system which calculates what will happen. It's up to date and what you show to the user, but it might not be correct because someone might have changed something which you're not aware of yet.

Every once in a while the network system makes an update to the network state, the physics system throws away its state, copies the network state and runs it to the current time. That way you have 2 mostly separate systems and you don't need any locking. I never got around to try this though.

@nwp Thanks ! So basically the "NetworkSystem" is read only and should run fine between the threads because it does not modify anything... it simply reads... our "physics system" is also fine because it simply writes stuff into the physics components on its own thread... So we have two seperate threads working with each other... what happens if we wanna add a third system which writes to components both of them ?

Is it able to run on its own thread ( guess not ), should it run on the same thread as the physics ? Or the same thread as the networking ? :o

Or does our 3rd system simply requires locks in order to work properly ?

@genaray In this example, your physics and network systems can still run in parallel, you just schedule your network-physics system to run after both have completed. If one runs much faster than the other, hopefully you have some other systems scheduled that can keep the thread working productively until the slow system finishes and your next batch of work is ready to issue.

@genaray The network system cannot be read-only because it has to make changes to the system based on receiving information from the network. Additionally the system you describe is not safe. One only writing and one only reading does not prevent any of A, B, C or D.

Alright thanks for the help... this already takes me further @DMGregory @nwp ^^

Oh i often heard there are ecs - frameworks making use of "jobs"... what are "jobs" ? Just code executed async in another thread or is there more ?

A job is usually a small work unit that isn't necessarily tied to a single thread. You might have several worker threads that each pull jobs off the waiting queue as they have availability.

So you might have a physics integration system that needs to update all your physics bodies by stepping them forward one time step, integrating their acceleration, velocity, and position to a new state for collision checking.

Each one depends only on its own local data, so you could split this work between threads to run in parallel, rather than running the whole system sequentially on one thread.

You might parcel it up into jobs where bodies 1-16 and 33-48 get processed by worker thread #1, and bodies 17-32 get processed by worker thread #2.

By chopping up the work into a lot of smallish, independent units, you can more easily fill in gaps where one thread is waiting for another. Anytime a thread is idle, it can just grab the next work unit that's been queued up and start working on it, without waiting for a whole system's worth of work to finish serially.

Some of the details can vary a bit from one framework to the next, so it's always a good idea to at least skim through the documentation.

Jobs are what America has a lot less of now.

^ Glad to see the 'Mericin gov'mnt is auto correcting fake news here.

@DMGregory Thanks, finally a good example :D If i understood that correctly... we could also create a "Job" system by simply letting a system create multiple threads to process its data ? For example a "SaveSystem" which splits the entities, getting saved ,into multiple batches for being processed by their own thread, in order to get inserted into the database ? Is this also some sort of "Job-System" ?

Usually the threads themselves would be independent of any one system (since spinning up or retiring threads has substantial cost, we'd often rather re-use them)

So the system wouldn't create the threads so much as queue-up work to be done by the existing threads. As Pikalek says though, the details vary significantly between frameworks.

Saxophone!!

@Almo Good track. :) What brought that on?

I played it for someone else, and thought "hey those guys might like this too"

You are correct. :)

:)

one of the best uses of saxophone i've heard.

one of the electronic guys I listen to plays bass clarinet :S

And several other odd instruments.

From the title I can only think of...

:)