I completely agree with you. Thanks again :)
On 06/19/2015 06:47 PM, Guido Medina
wrote:
Trust me you don't want to do concurrency by
yourself even if you are an expert at it, asynchronous design is
the way to go, with Akka that concern is easy enough and you
will be able to focus only on the business logic and produce
results, the last thing I'm going to Advice you is to not
underestimate the documentation, specially the first 3 parts, I
had to learn Akka in few weeks and that helped me the most to
the point that I had no question but only the tricky ones.
On Friday, June 19, 2015 at 2:06:48 PM UTC+1, Amir Karimi wrote:
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
...
>>>>>>>>>> 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.
|
