Best practice to implement global manager entity?

[Naga]

Hi,

Generally I need a global manager (e.g. game manager) to:

• Store the shared data for every entities (e.g. current in-game time, stock market)
• Fire global events to any entity in any place in game world (e.g. earthquake, notify players in the end of a turn)

The problem is how to implement global managers in SpatialOS, or how I should convert these to SptialOS-style systems. How do I make sure global managers can be static within workers and also thread-safe? (not tested yet) Is there any good way to keep global data other than the singleton of global class in SpatialOS? Or should I put every shared data into components?

So far I know I can make an entity accessible to global by setting global_component_streaming_query in worker config files, and the players can get the updates from components passively, but how can I make an entity also can reach to any player entity in the game world when it needs?

I have to admit that I don’t know SpatialOS very well, and many things I haven’t tried myself. Since many functionality and tutorials are not documented yet, just wonder that if anyone is willing to kindly share the successful experience about the design patterns or structures, which may save me a couple of days or even weeks.

Thanks

[callumb]

Hey @Naga !

So…actually the best practise for “global managers” is generally to not use global managers.
However, I appreciate that can be problematic!

So, with “world time” as long as you are happy with your workers concept of time not being exact across the network ( because, that’s really really hard to do) you could have a global time keeping entity that is either:
a) always checked out, by all workers using a streaming query
b) easily found, ID stored and periodically messaged.
This would be good for finding out what time it is in game on a minute-minute basis ( you could also use this entity to manage sun/moon cycles etc) because the network bandwidth would be pretty small.

For a stock market: depending on your use case you could go for a real life hierarchy where:
a) player’s ping their nearest “bank” entity with the transaction
b) occasionally the “bank” entities update their manager with their list of transactions
c) eventually a centralised master entity has an up-to-date view of the economy

With regards to an entity being able to reach every player, a “registry” system would work:
a) players that are created register with an entity
b) when they are deleted, they de-register
c) the register entity can be used to iterate across all current players and send them notifications.

You may encounter issues with the above at scale: but there are methods we can apply later on for optimising!
Does this help at all?

[zachc]

Thank you @callumb !

We definitely do not need exact time across the network and it would be fine if entities ‘ticked’ on their own to trigger state changes rather than all entities being ‘pushed’ by a global game manager to change state.

[Naga]

Hey @callumb!

Thanks for giving examples of implementation for these abstract questions even I didn’t elaborate them!

@zachc and I do need to implement something like day/night cycles instead of exact in-game time. And the structure of the stock market example could be applied to other similar systems. For player management, that seems a good way to handle this.

I guess I know how to start on these systems now. Thanks again!

[krnlpanick]

This is good info, and here I am -sitting here, fighting the urge to not build a distributed ledger / consensus platform on top of SpatialOS (re @callumb stock market scenario).

FWIW - as described this is the basic concept employed by all financial systems in the “real world” today; and it’s not beyond reason to think that Spatial would make a great platform for a distributed ledger / consensus based “stock market simulator” game of some sort, simulating massive economies is right up SpatialOS’ alley (as it were) and a lot of the hard platformy stuff is free in SpatialOS architecture.