Hello fellow space explorers,
I am currently working on a Meteor driven game. So far I have got most of the basics for the single player part. I wanted to have your thoughts about how to manage/setup my application so it can easily handle an AI ecosystem.
To put it simple, there will be multiple “actors” that will need to take different decisions at different times. Here’s a basic example:
Actor1 decides to go to the store to buy fruits.
(actor takes time to go to the store)
Actor1 buys the fruits, and goes home
(actor takes time to go home)
Actor1 puts the fruits in the fridge
I have thought of handling this as follows:
Each actor is in a collection (which might differ according to its type)
There is a decision queue collection that stores the actor’s ID and the time expected for it to need to decide something.
I use an autorun on that collection to grab all decisions that need to be taken and trigger the “take decision” event which they are listening to.
The decision is taken and a new decision is added to the queue at the time the task is expected to end.
If the user tries to rob the actor, the event is triggered to make it react.
By using events, I expect to make it run smoother by having all the actor instances up instead of fetching their whole identity and behaviors every time they need to react. But that will also take more and more memory as the world expends, or the players amount increases. So I am expecting to have to spawn multiple instances of the application (maybe I could sepperate AI and Front completely…) but how would someone go in managing the instance of each actors throughout the Cluster?
Has someone already faced this kind of problematic? The AI by itself should not be very heavy for one actor, but the actors count might get in the hundred thousands easily…
Thank you for your thoughts.
Meteor apps use sticky-sessions, so user logins are sticky to a single server. Mongo sharding indexes have the ability to give collection affinity to servers (you’ll need to write custom app code to tell an app to connect to a particular shard).
Between the two, you can plan for certain collections/users to have affinity to certain servers. The last piece of the puzzle is to associate specific servers to specific parts of your game.
In big MMORPG systems, they usually assign separate servers to handle different towns/regions/planets, with users moving from one server to another while they’re progressing through the game. To implement that, when a user moves from one region to the next, you’ll maybe want a cascading update that updates the shard indexes on a collection, and moves it from one shard to the next. You could also implement with a collection meta-collection, if you want to keep sharding for geo-optimizations.
Either way, look into the matb33:collection-hooks package.
Thank you @awatson1978,
This seems to pretty well cover the mongo part, but how would you go about the actual computations? Would simply fetching the data from Mongo, transform it into an actor instance, add traits and behaviors and then ask for his decision, store the result in Mongo and delete the object be more optimal than keeping instances in memory and answer to events?
Also, in your MMO example of having one server per region, I was thinking more about splitting the actors by their numbers more than their localization so a very populated region would benefit computations not used by small regions… They could be devided by race, or profession let’s say… This would also give a benefit as one server does not need to know/execute all behaviors but would be specialized in a certain profession… I don’t know if I’m simply over thinking it at this stage, but I’d like to build the system in a way that could easily scale if things go well…
Thanks again,