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.
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 [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.
>>>>>>>>>> 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 [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.
>>>>>>>>>> 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 [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.
--
>>>>>>>>>> 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.
|
