You are right Guido, I never used Akka in production though I have
implemented several successful applications with Scala, Play and
ReactiveMongo. And there is a single server with 50K user at
maximum. Certainly, supporting more users and advanced scenarios
would be great but as I said I fear I'm involved in technical issues
more than the real work. Maybe I'm wrong!
On 06/19/2015 10:08 PM, Guido Medina
wrote:
I do agree with Luis, but I wasn't pushing much
that approach because AFAIK you are new to Akka and you have
only one server, the concept of sharding and Akka persistence
can be overwhelming at first, but if you read between the lines,
the hash code approach I proposed initially is the skeleton of
any sharding mechanism, which isn't more than hash maps and hash
codes in steroids, it will help you study better the behavior of
your players, game and actions as it evolves which will lead you
to: Wait, this sharding distribution I'm using is just what Akka
Sharding does.
Now I don't like to jump from zero to the extreme because
to get there you have to dominate the framework you are using,
the evolution to such advanced stage should come natural, if
you force it and try all in a single small project from the
beginning you might just give up because of the overwhelming
factors and technical issues I'm sure you will face.
HTH,
Guido.
On Friday, June 19, 2015 at 5:23:33 PM UTC+1, Luis Medina
wrote:
Personally, I wouldn't organize your actors
into "zones" since zones aren't really a concept that
would exist in your game and like you pointed out, it can
make scaling a bit tricky. The approach that I would take
is to use clustering along with sharding to distribute
your actors across however many machines you have at your
disposal for the project.
If you do end up using sharding, I'm not entirely
sure if you would really need to have specialized
supervision actors. From what I gather from previous
comments, it seems that supervision would mainly be used
as a way to quickly get to your child actors (ie. for
player and villages) which seems unnecessary since this
is something that you can already do quickly enough
through ShardRegions/ShardCoordinator.
I agree with Guido's original comment in that you
should probably use passivation to bring down actors
that aren't used often if you want to save on resources.
To do this, you will need to use Akka persistence (which
you have to do anyways if you plan to use sharding since
the ShardCoordinator needs it to recover from failure)
in order to save the states of those actors so that they
can get restored when they come back up (say if a user
logs in again). Now for this, I would probably go for a
distributed journal which will allow you to scale much
better in the future even if your game does start out
small. There are plenty of plugins that have been made
by the community for various data stores so choosing one
that is easy for you to work with shouldn't be too
difficult.
You brought up another concern of how will downed
actors for players/villages know of events that occur
(ie. a village attack) while they are down. For this,
you might consider using some sort of messaging queue
(ie. Kafka) where these events get stored as they
happen. Then when these actors do come back up, one of
the first things that the actors would do after
restoring their previous state from Akka persistence,
would be to go into this message queue and retrieve the
latest events in sequential order and apply them to
their current state (kind of like what Akka persistence
does during the recovery process except that this time
you're sort of programming it yourself). For this you
could probably organize it in such a way where every
village/player has it's own partition based on its id.
The reason why I would go with Kafka is because it
scales much better than RabbitMQ and it persists things
to disk. This approach would probably work best for your
player actors although I'm sure you can make something
of it for your village actors as well. I haven't thought
this part through but I'll leave it up to you to figure
out the details :)
On Thursday, June 18, 2015 at 12:57:30 AM UTC-7, 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.
|
