Personally, I wouldn't organize your actors into "zones" since zones aren't really a concept that would exist in your game and like you pointed out, it can make scaling a bit tricky. The approach that I would take is to use clustering along with sharding to distribute your actors across however many machines you have at your disposal for the project.
If you do end up using sharding, I'm not entirely sure if you would really need to have specialized supervision actors. From what I gather from previous comments, it seems that supervision would mainly be used as a way to quickly get to your child actors (ie. for player and villages) which seems unnecessary since this is something that you can already do quickly enough through ShardRegions/ShardCoordinator. I agree with Guido's original comment in that you should probably use passivation to bring down actors that aren't used often if you want to save on resources. To do this, you will need to use Akka persistence (which you have to do anyways if you plan to use sharding since the ShardCoordinator needs it to recover from failure) in order to save the states of those actors so that they can get restored when they come back up (say if a user logs in again). Now for this, I would probably go for a distributed journal which will allow you to scale much better in the future even if your game does start out small. There are plenty of plugins that have been made by the community for various data stores so choosing one that is easy for you to work with shouldn't be too difficult. You brought up another concern of how will downed actors for players/villages know of events that occur (ie. a village attack) while they are down. For this, you might consider using some sort of messaging queue (ie. Kafka) where these events get stored as they happen. Then when these actors do come back up, one of the first things that the actors would do after restoring their previous state from Akka persistence, would be to go into this message queue and retrieve the latest events in sequential order and apply them to their current state (kind of like what Akka persistence does during the recovery process except that this time you're sort of programming it yourself). For this you could probably organize it in such a way where every village/player has it's own partition based on its id. The reason why I would go with Kafka is because it scales much better than RabbitMQ and it persists things to disk. This approach would probably work best for your player actors although I'm sure you can make something of it for your village actors as well. I haven't thought this part through but I'll leave it up to you to figure out the details :) On Thursday, June 18, 2015 at 12:57:30 AM UTC-7, Amir Karimi wrote: > > Hi, > > I'm working on a simple MMO game as a side project which is like Travian > <https://en.wikipedia.org/wiki/Travian>. I've decided to use Akka as the > game back-end, so I would like to share my design with you. Your > suggestions and feedbacks are very appreciated. > > Each of the following entities are modeled as an actor: > - Player > - Village > - Building of a village > - etc. > > Villages have some resources which are constantly decreasing or increasing > based on multiple factors like buildings level, village population, etc. > (Clearly, I'm not going to change the resource values periodically but I > save the last resource value, its time and the coefficient of increase or > decrease.) > > Each player may have multiple villages. As villages can be conquered by > other players, each village has an state for it's owner player (e.g. > playerId or playerActorRef) and also a player has a list of his/her own > villages (village actors or IDs). > > Each village may contains multiple buildings. As buildings won't be moved > and owned by other villages, they will be created as village actor > children. So the buildings will communicate with their village through > `context.parent`. > > For persisting the game world state I'm going to use Akka persistence > module. > > This is the fundamental of my design although I have several concerns: > > - I'm not sure if players profile information should be stored into > the database or into the player actors (as states). > - According to 80/20 rule, I except 80% of the players to be much less > active than the others but their corresponding actors are still resident > in > the memory even if they have no activity at all. What are the best > practices to reduce the RAM usage for those? > - How can I show the statics and other information in the admin panel? > For example I want to be able to search among players and get their > information. I know I can use actorSelection with wildcard but what about > data pagination? I'm not going to load all players information. > > First of all please let me know if this is a good idea to use actors for > such project. I'm not sure if this approach will make things more complex > or simpler. > > Thanks a lot, > Amir > -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
