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