Single script manager for multiple Stateful GOs

Questions
#1

After reading this post I could understand why sometimes it could be better for you to manage multiple similar GOs in a single script rather than having one script for each (and possibly one update function for each). After scanning the bunnymark-defold I could have an idea of how to implement such a Manager that animates multiple GOs’ positions. My question is: What if each of my managed GOs also need to have some basic state (i.e.: health, attack_target, etc)? How would you suggest associating/updating the state of each GameObject?

I mean, I could set properties to the managed GameObjects and update them via messaging, but I think it defeats the purpose of not having multiple scripts in the end.

#2

If you keeping track of your GOs in a table the simplest way is to add those properties to the table.

local my_gos = {
     id  = factory.create(<OPTIONS>),
     state = "idle"
}
2 Likes
#3

Hmmmm, guess I didn’t realize you could do that… Still getting familiar with the whole objects as tables concept (and also messaging). Gonna study some more of the basics.

Thanks

#4

I think it depends on the number of game objects. A small number (needs testing) could have properties on scripts.

But if you already have a manager that keeps a list of objects then I think it makes more sense to store the properties in the manager along with the game object ids.

#5

Yeah, tbh I think my game wouldn’t need that, but since I am still messing with the engine I figured I would test it. Structurewise I feel the code can get quite messy if the managed GOs behavior is reasonably complex, especially since I am still programming with a Kotlin OOP mindset. Will do some tests and see if it can scale

#6

@britzl, by the way, I noticed that on bunnymark you store your list of spawned bunnies in a local var inside the imported module. Is there a good reason to do so (either design or performancewise) ? I am asking this bc right now I am storing my spawned ‘minions’ inside the manager script itself. I don’t think that would make a big differece, right?

#7

That would probably not make much difference.

1 Like
#8

I think lua module is better in case you ever need a different script to access these values. Then you can just require the module there too instead of passing the values in messages or something like that.

4 Likes
#9

Good point!

2 Likes
#10

If there’s one thing I learnt from your answers here, it’s that lua modules are an answer to 90% of problems in Defold =)

8 Likes
#11

Hi, played around today and I am learning a lot! Now I am spawning a bunch of stateful objects and controlling their state on a single update() function. What I couldn’t figure put though is how to make these objects detect one another with collision shapes, I mean, I add a trigger collisionobject to their hierarchy, but, since they don’t have a script attached, I can’t access their on_message to know when a collision happened. Is there a way to make the manager object receive the collision messages instead?

1 Like
#12

Correct, this is not something you can solve without actually putting a script on each object.

The approach with a single manager script is useful for some types of objects. One example is heat seeking missiles. Each missile would have a sprite and a collision object but no script. All missiles are moved from a single manager script towards some target, possibly also removed after a certain distance or time.

The collision detection would happen on the target instead, because the target is presumably something more complex such as a player or enemy ship that needs a script with logic. The target will also receive the id of the missile it collided with so that it can tell the manager to remove it.

1 Like
#13

Got it! What I was trying to achieve was two hordes of minions (lets say team RED and team BLUE), a minion from RED would chase a BLUE one if it gets too close. One naive approach would be for every RED to check for its distance to every BLUE on each frame and start chasing if the distance is less than x. But I think the overhead would be too large for large teams. Another thing I could do is to put a script on the minions that will simply route the message to the manager, this way I still have the limit of 1024 total scripts but won’t waste time with an update function for each one

#14

This kind of check could be handled by the manager if you do some partitioning of the two hordes or detected using an extension for additional performance. Maybe this one: https://defold.com/assets/daabbcc/

Somewhat related: https://defold.com/assets/defarmy/

1 Like
#15

Awesome! daabbcc looks really interesting. Btw, all of this is probably overkill for the number of objects that may end up on the level, but it is so fun to mess around with this hahaha

1 Like