Question concerning multi threading and staying out of trouble

Troubleshooting General Help
21
@normen said:
The complicated thing is having the borders share their objects properly so that balls can roll from one grid to the other.


I had to deal with similar issues in my grass system, bounding boxes extend over page borders etc. It was a lot of boring work.
22

Can I ask a semi related question?



Is it good practice to write one control to control a group of monsters? Like a swarm?



Say if I wanted a swarm of little critters, could they share one AIControl or ScriptControl or whatever, and that has the logic to guide the individuals to achieve their aim of killing the player?



Blehā€¦ having just thought about this, it would be called for each monster every update cycle. So it wouldnt really be any faster. The only way to make it be called once per update and not once per monsters per update would be to implement it as an AppState. Worth it?



My thinking is that it would make it easier for any monsters designated as, say, a healer, to know which of its comrades need healing, and it may be a bit faster too.

23

First, a control can only belong to one spatial at a timeā€¦ so no sharing anyway.



For shared stuff, you are right to consider an AppStateā€¦ but it really just depends on what you want to do. One app state updating multiple spatials isnā€™t really any different than multiple spatials having controls that get updatedā€¦ the same amount of method calls will happen.



Itā€™s just a matter of whether you need to coordinate logic across actors that would be difficult at the control level. Then an AppState might make sense.

24

You can control multiple spatials from one Control just fine, e.g. the children of a Node where the Control is attached. However if its more lobal what happens then using an AppState is probably best.

25
@normen said:
You can control multiple spatials from one Control just fine, e.g. the children of a Node where the Control is attached. However if its more lobal what happens then using an AppState is probably best.


And for the record, normen is not disagreeing with my "a control can only belong to one spatial at a time" statement... just explaining the extended usage of a control being associated with one spatial and being able to control (lower case 'c') its children. A Control has a single Spatial reference... and if you try to add that same Control to another Spatial then it will complain because you can't swap out the old Spatial reference for a new one. (and that's good because it would be very broken otherwise) But the Control will have access to its associated Spatial and that could be a Node with children.

This can work if your actors share a common parent to which you can add the single Control. Though I suspect that's probably not the case here.