Having one mover per game object is unstandable...

[lucky6969b 1332]

I'd rather having singleton for each type of mover because

if I had 1000 game objects, I would have 1000 such movers flying around in the system.

If I had 2 types of movers for each game object, I'll have 2000 movers....

This is keeping to grow exponentially....

 

But Having said that, when using a singleton for mover types,

I need to setup the owner of each request, because I push them into threadpool,

when it comes out, I don't know whose is whose.

 

The problem I come up with this, is when I forgot to set owner, or forgot to set it,

everything will be screwed up...

 

I really don't want to give the mover some unnatural arguments, because I'm just interested in the results afterall.

But I really hate to setup the owner for each request...

Your opinion please?

Thanks

Jack

Edited May 31, 2017 by lucky6969b

[Kylotan 10267]

It's not clear what you mean by 'mover', or why you might need more than one per game object, or why it would grow exponentially instead of linearly. It's also not clear how the threadpool factors into this, or what the requests do.

Could you please explain this more specifically?

[lucky6969b 1332]

Mover is just a pathfinder, yes, I misused the term, linearly is more appropriate...

[Kylotan 10267]

If the question is, "how can I ensure asynchronous pathfinding requests know who submitted them" then the answer is trivial; force the request to include the submitter. You say you "hate to setup the owner for each request", but that should not be difficult - just pass in a pointer - so there is presumably something else that you aren't telling us which makes this awkward.

If you're worried that the object doing the request might get deleted before the request comes back, you can use a weak pointer, or you could store an ID or a name instead of the pointer.