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:
> 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 <javascript:>.
> To post to this group, send email to akka...@googlegroups.com
> <javascript:>.
> 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:
>>>>>>>>>> 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.
