Are actors the right tool to implement the messaging between a simple multiplayer game?

I'm thinking about using actors for a simple Asteroid-like game written in Scala and Java2D, which can be played by two players in a cooperative mode.

Both players can control their own ship on a shared playing field, where asteroids float through the space.

I wonder if actors are the right tool to implement the network elements between both players, like position updates or the destruction of an asteroid.

What would be necessary to implement it? What would be the hard parts? I fear that I will have problems with keeping them both in sync...

Is there a better solution available?

EDIT:

I don't plan on doing any fancy stuff regarding firewalls or NAT... I thought of havin开发者_JS百科g a small "server" to which both clients connect. (In reality one client will just start up the server and run it on the same pc.)

Both clients will connect to it, preferably both with a remote actor, so that I don't have to special case the remote/local case.

I have no problems with going the P2P route, if it is easier. The demands are fixed and I never have to plan for the case of "we need a 64 player game!!!".

---

I’ve recently been involved in the development of a game which more or less used the same kind of messaging approach. I.e. having a remote server listening on a port somewhere and then several clients connecting to it and passing messages back and forth.

It was done in Python, though, and as we did not want to rely on any external libraries, we did write our own kind of actors and a remote messaging system on top of them. As it turned out, there were a few speed issues but I think they were mostly related to Python’s way of doing threading (and our lack of understanding of it). Benchmarks for Scala Actors or Akka always gave better numbers than what we were able to do in Python.

Synchronisation was not a big issue for us, at least not in the game itself. But then we did not have that many data to exchange and it was a round based game. So, each of the clients was queried one after another and if there was a timeout then the next client would be queried. In our problem, the clients were only reacting on what the server presented them. This might, however, not be the best solution in a more real-time game.

For a real-time thing you might have an incoming queue (Actor) on the server to receive all the client moves and probably have a separate channel for the game state to avoid blocking. This would indeed be a bit more involved to synchronise. So it depends a bit on how fast you need updates.

---

For whatever it is worth, some of the early adopters of Akka were multiplayer games, though I cannot provide a reference for it.

Also, Call of Duty's multiplayer core is written in Erlang. That link's to a presentation by the guys who did it, and it is very interesting stuff.

---

Actors is definitely one way to go if there is a lot of asynchronous messaging (i.e., messages sent without any prior state)

I would implement it as follows: each player will be a Actor receiving messages from the other player. Messages sent to actors will not be lost, so you will eventually reach a synced state once all messages have been delivered. You will have to write your own syncing algorithm, of course.

It is possible to use the RemoteActor API to directly access the remote actors, or to use an intermediate communication medium (e.g., Sockets) to transport the messages.

I am assuming that there is no central server for coordinating the players.