I do agree with Luis, but I wasn't pushing much that approach because AFAIK you are new to Akka and you have only one server, the concept of sharding and Akka persistence can be overwhelming at first, but if you read between the lines, the hash code approach I proposed initially is the skeleton of any sharding mechanism, which isn't more than hash maps and hash codes in steroids, it will help you study better the behavior of your players, game and actions as it evolves which will lead you to: Wait, this sharding distribution I'm using is just what Akka Sharding does.
Now I don't like to jump from zero to the extreme because to get there you have to dominate the framework you are using, the evolution to such advanced stage should come natural, if you force it and try all in a single small project from the beginning you might just give up because of the overwhelming factors and technical issues I'm sure you will face. HTH, Guido. On Friday, June 19, 2015 at 5:23:33 PM UTC+1, Luis Medina wrote: > > 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.
