These technologies and architectures are so appealing to me but I'm
still in doubt
whether I should follow these interesting approaches or just make a
traditional software (with a monolithic database-driven model).
Although this is a side project, it's very important to me. I should
get it done.
Anyway, thanks a lot Guido for your kind advices.
On 06/19/2015 05:19 PM, Guido Medina
wrote:
And don't worry about performance, assuming each
shard has a pattern of Single Consumer - Multiple Producer, make
sure the inbox type for shards and players is
SingleConsumerOnlyMailbox which is a the fastest Akka mailbox
atm.
On Friday, June 19, 2015 at 1:43:46 PM UTC+1, Guido Medina
wrote:
If your number of shards is high enough and
your hashcode is smart enough coalitions should be very
minimal, I think you should have stats of how many players
you have per shard and how busy shards get, and between
restarts -maintenance time-, redo your numbers and
hashcode formulas, otherwise you will have to do what hash
maps implementations do when there are to many coalitions
which is to redistribute all the shards, up to you which one
you go for, I would say, pick a high number of shards like
1024, then you will have avg of 50 players per shard.
On Friday, June 19, 2015 at 1:26:51 PM UTC+1, Amir Karimi
wrote:
Yes that would be easy and
scalable! Just out of curiosity, what if a zone get too
active? In another world how can we have asymmetric zones
so that we can balance zones pressure by moving active
players between them.
The first thing that comes to mind is that players
shouldn't have any idea about the zone their live in.
Whenever we need to find out a player zone we send a
message to all zones asking about the player and wait for
the response from the zone in which the player actor
lives. The problem is that the player may have been moved
to another zone in the middle of the finding process :(
It seems like the cellular mobile network. How can they
find the BTS to which my phone is connected?
On 06/19/2015 04:31 PM, Guido Medina wrote:
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.
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 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.
|
