Do you have player IDs? design your application to have zones divided by a
number -preferably a power of 2-, say, 64, now you have 64 evenly
distributed "shards" so to send a message to player ID = 1001 then you just
need to 1001 mod shards, no look up needed, it is just a convention you are
using.
On Friday, June 19, 2015 at 12:37:43 PM UTC+1, Amir Karimi wrote:
>
> Yes it would be very nice. But I have no idea how to find a player zone.
> Suppose player A want to attack player B. First we need to find out the
> player B zone (to find it's supervisor). Right? Then we need an actor which
> knows about the players zone. That would be the bottleneck again.
>
> On 06/19/2015 04:00 PM, Guido Medina wrote:
>
> Nvm, that would run into the same problem, instead, eagerly load the
> player's zone -a supervisor for a bunch of players- and then lazily load
> the player per zone, that will keep your actors distributed and also will
> prepare your code to use these zones as shards when the game grows.
>
> On Friday, June 19, 2015 at 12:27:39 PM UTC+1, Guido Medina wrote:
>
> You could even have the concept of lazily load the zone and each zone
> lazily load the players.
>
> On Friday, June 19, 2015 at 12:25:47 PM UTC+1, Guido Medina wrote:
>
> 50K is like zero for current and modern hardware, so, I would say, load
> them lazily from your players' supervisor and don't expire them until you
> start seeing a problem, expiring them would require you only to set context
> time out at preStart() and then handle the timeout message which would be
> to just send a poison pill to your actor.
>
> There is another detail though, for the sake of concurrent delivery
> under high load, you would be receiving all messages at that one
> supervisor, do you think that will scale well? say you have 1000 attacks,
> you will have to forward one at a time, so the concept of zone -think of it
> as a shard or hash- is not a bad idea, a way to minimize coalition.
>
> On Friday, June 19, 2015 at 11:56:40 AM UTC+1, Amir Karimi wrote:
>
> You're absolutely right. I need at least one supervisor (or maybe two;
> one for players and one for villages as they are top level actors). This
> way I can deactivate and lazy load them as you said.
>
> And yes I don't have millions of players :D but I hope some day I'll ;)
>
> But seriously, as I won't have millions of users (I'm planning for 50K at
> max) what about keeping all actors in memory? It will make everything
> easier and faster.
>
> On 06/19/2015 03:05 PM, Guido Medina wrote:
>
> Say you don't have zones or any sort of grouping, you need at least one
> supervisor, I wouldn't recommend you to make all your players top level
> actors where their parent is /user, you need a fast way to locate "a
> player" and context().child(...) is such way IMHO, sharding with persistent
> actor is another way which was mentioned but it adds more complexity to
> your design, you don't need to de-activate actors though, maybe you just
> lazy load them with the method I gave you but again, you need one
> supervisor, you will be surprise how many millions of actors you can hold
> in memory, do you have millions of players?
>
> If so then you are rich and we are talking of distributed gaming and
> stuff :D
>
> On Friday, June 19, 2015 at 9:07:58 AM UTC+1, Amir Karimi wrote:
>
> Thanks Guido, this is good idea but as I'm not going to make this game
> distributed (at least in the near future) I feel this approach increases
> the complexity and I don't know what would I get instead of this
> complexity? (except for RAM usage optimization)
>
> The reason why I decided to use Akka is to make things simpler. For
> example I believe Akka would help me to handle the game entity states in a
> very simple and concise way. But it introduces new concerns about RAM
> usage. It can be handled with the help of Akka persistence and supervisors
> although it's not as simple as I thought.
>
> On 06/19/2015 11:40 AM, Guido Medina wrote:
>
> You can activate an actor if not present, as long as you send the message
> to its supervisor, so you have to keep say, supervisors per zone? and each
> supervisor will try to send/forward the message to such child and if not
> present create it.
>
> This is an example in Java where I do the same thing for account, the
> accounts actors are not eagerly created but on demand, the following method
> is inside the supervisor actor class:
>
> private void applyToAccount(Currency currency, BalanceOperation
> operation) {
> final ActorContext context = context();
> context.child(currency.code).
> getOrElse(new AbstractFunction0<ActorRef>() {
> @Override
> public ActorRef apply() {
> return context.actorOf(balancePersistorProps(currency), currency
> .code);
> }
> }).tell(operation, noSender());
> }
>
> HTH,
>
> Guido.
>
> On Friday, June 19, 2015 at 7:48:43 AM UTC+1, Amir Karimi wrote:
>
> I think It's not enough. There are events which will happen when the
> user is not logged in. For example an attack on a village (which its owner
> is inactive) or occupation of that village also generates a message to the
> owner player actor (which is not resident) as well. So I can't activate
> them just at login times.
>
> On Thursday, June 18, 2015 at 3:55:03 PM UTC+4:30, Guido Medina wrote:
>
> You can set context time out for actors, if they don't receive a message
> within some time passivate them, activate them at login, that way you don't
> have to lazy load when the player is active but at login which will
> basically happen asynchronously.
>
> Now, Akka experts should tell us if setting context timeout for many
> active actors is a bad idea.
>
> HTH,
>
> Guido.
>
> On Thursday, June 18, 2015 at 8:57:30 AM UTC+1, 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 a topic in the
> Google Groups "Akka User List" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/akka-user/IAyHHn1vJL4/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> akka-user+...@googlegroups.com.
> To post to this group, send email to akka...@googlegroups.com.
> Visit this group at http://groups.google.com/group/akka-user.
> For more options, visit https://groups.google.com/d/optout.
>
>
> --
>
>
>
>
> * Amir Karimi (+98) 912 211 9506 www.dev-frame.com
> <http://www.dev-frame.com> *
>
> --
> >>>>>>>>>> Read the docs: http://akka.io/docs/
> >>>>>>>>>> Check the FAQ:
>
> ...
--
>>>>>>>>>> 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 akka-user+unsubscr...@googlegroups.com.
To post to this group, send email to akka-user@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user.
For more options, visit https://groups.google.com/d/optout.
