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 akka-user+...@googlegroups.com.
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.
|
