Functional Java also has a very high performance Actor implementation, which is essentially the same one that's in Scalaz. The gold standard for actor systems these days though is Akka, which has both a Scala and Java API.

I see a number of big issues in the Java implementation up top. The big no-no is the use of a single thread per-actor, which you simply should never be doing for any kind of serious actor system. Use a thread pool, or better yet make the execution strategy pluggable.

The overloading of wait/notify/notifyAll is probably not a good idea either, since it's too easily confused with the same-named methods on Object, but it's minor compared to that previous one. I think everyone should explore the actor model, try inventing their own, but then look at an industrial-strength implementation and see what they do differently and why.

I don't get it. Reading the wikipedia (http://en.wikipedia.org/wiki/Actor_model) it sounds like these are nothing more than 'nodes' on a communication network? I'm not seeing the point? Why have them? They don't appear to be designed do any work at all other then shunt data off to other actors??

The point of an actor is that they do useful work whenever they get a message, which results in side effects and usually one or more different messages going to other actors. The akka docs make it a little clearer than the wikipedia article, and there are also tutorials you can look at.

I use actors in my code by having a web service send a message to an actor to process everything async, then after much expensive backend processing, get back a reply (also via an actor message) to send back. Inbetween there's a network of service classes that are themselves actors that send each other messages.

If you've ever used a Message Driven Bean in a JavaEE app, those are also basically actors (with a very heavyweight mailbox).

Although I haven't done much work with Actors, I always thought it would be interesting to try and set up GameEntity's as Actors and handle things asynchronously, although you could simply have an Update message that it reacts too.

I've been tinkering with a game that does exactly that, and in fact goes totally nuts with the idea and makes every damn thing an actor, including every square on the map (it's a tile-based game). It even uses libgdx's scene2d actors for the graphics, which are of course a very limited form of actor (they're not even threadsafe) but handy for what they do. It is not at all small or efficient that way, but hey it runs fast enough on my machine anyway.

Recently I did what I tend to do, tore the whole thing up and started over. My quest for purity and using scalaz actors will probably be falling by the wayside, and it'll likely be stateful Akka actors this time, become() and all.

If you've ever used a Message Driven Bean in a JavaEE app, those are also basically actors (with a very heavyweight mailbox).

Cheers for the replies sproingie, I have worked with MQ Series stuff before (ie: set up JMS message queues to chit-chat with AS400 stuff) and did think to myself that perhaps Actors were an alternative to this. I'll take a look at those links of yours soon (on lunchbreak atm)

Actors localize state, they don't share it very well, because unless you're willing to do some fairly complex stuff around Lamport clocks (or vector clocks), you're not going to get consensus among them on what the current state actually is. Akka has a few things around STM to help, but if you're really going for a shared AI state, actors are not a great model for that.

I see a number of big issues in the Java implementation up top. The big no-no is the use of a single thread per-actor, which you simply should never be doing for any kind of serious actor system. Use a thread pool, or better yet make the execution strategy pluggable.

The overloading of wait/notify/notifyAll is probably not a good idea either, since it's too easily confused with the same-named methods on Object, but it's minor compared to that previous one. I think everyone should explore the actor model, try inventing their own, but then look at an industrial-strength implementation and see what they do differently and why.

Thx for pointing that out. I changed it to use a thread pool instead and my performance increased by 6 times. Strangely, the default Scala actors don't seems so fast. For sending and receiving 100000 messages it takes :

If you do an empty benchmark with messages that don't get any processing, scala is likely to underperform because it just plain has more overhead. Even then I'd try benchmarking it against scalaz or akka actors, since scala.actors doesn't have the best latency characteristics.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org