[Q] How to access GameObject values from within ECS?

[river yoke]

I am currently trying to access Data i have in Monoworld, from within an ECS based ISystem. The player has his position stored in a public variable, accessable from anywhere in the "MonoWorld" by simply using "PlayerData.PlayerPos".

How could i access this Data from within an ECS ISystem? I am using multithreaded jobs with Burst and IJobEntity.

Here is the code of my moving system:

In the above seen image, the code still uses an entity as player position, but i would want to replace currently used "playerPos" by MonoValue "PlayerData.PlayerPos".

[astral wedge]

hmm, what you are trying to do is practically conceptually against ECS

what is main in your project? entity or GameObject?

if you want to do ECS, entity must be main and everything is just component of it

in OOP vice versa

[river yoke]

I had started the game as mono with OOP, then ran into performance issues when spawning about 1000 animated enemy units. So i found out about DOTS which seems to be the exact solution to this problem. Therefore, my plan was: staying at OOP, but outsource performance critical parts to DOTS and Multithreads 🙂

[astral wedge]

well, then you shouldn't really use entities

you can just use jobs and burst

this will keep your project intact

for ECS it will probably be easier to rewrite from 0 😅

[river yoke]

i can?? How is this possible : () ?? I thought Jobs and Burst is bound to ECS/ DOTS or?

[astral wedge]

ECS is bound to Jobs and Burst

not vice versa

just look at their manuals

packages aren't hard to use

and manuals are really good

The only reason to use ECS in OOP project atm - to make some kind of internal simulation

[river yoke]

If i use burst and jobs without ECS, what benefits would i miss (by passing on ECS)? As the main benefit i saw is the job systems (which i though is not the same than c# job system?)

[astral wedge]

well, ECS is simply faster on it's own, but it has very different architecture and is not even production ready

I prefer ECS for architecture personally, because it's about composition vs inheritance

so you quite literally never have to access other logic systems

since all data is public for any other system

[river yoke]

This opens to me whole new options, i am still in shock, as since over a week i suffer frustration from trying to dig into ECS, but now i can use the parts i need without the complication of ECS world - is this correct?

[astral wedge]

yeah, all those parts are own packages

without dependency on other

but they work best together

but simply jobs + burst is enough to boost some existing project

[river yoke]

i thought they all build-up on each other, wow, this is very valuable info, thank you!!

With jobs and burst- but without ECS, i can still achieve this performance jump (like seen here, with timemarker) ?: https://youtube.com/watch?v=BNMrevfB6Q0&si=EnSIkaIECMiOmarE&t=1521)

[astral wedge]

depends

if you rely on built in unity components you can't rewrite

and they are your bottleneck

then probably not

if it's your own logic which is bottleneck, potentially you can

some assets on asset store actually utilize burst

for this reason

[river yoke]

i will give this a shot, thank you very much!! I suddenly feel the motivation again that has become lost over the past days of frustration, i am happy you told me these infos, thank you very much 🙏