Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm not experienced in Game Development questions, but as a programmer. In the language Scala, you can have scalable multi-tasking with Actors, very stable, as I hear. You can even have hundreds of thousands of them running at once without a problem.

So I thought, maybe you can use these as a base class for 2D-Sprites, to break out of the game-loop thing that requires to go through all the sprites and move them. They'd basically move themselves, event-driven.

Would that make sense for a game? Having it multitasked like that? After all, it will run on the JVM, though that should not be much of a problem nowadays.


After dabbling for a while, I noticed there is only one real advantage to this idea: Multicore Support. A simple game loop will only run on one core and will work through everything sequentially.

Since modern computers, even at home, nowadays have two or more cores built-in, I think it is a good idea to enable game programmers to efficiently use the other cores. After all, I think usually the player will only have just the game running on his eight-core machine, so why not.

The other advantage I see is that in Scala, you can have RemoteActors, which can be treated the very same way but run on another computer. So maybe this can simplify network gaming as well.

I intend to build that into my Scala 2D engine as soon as I can.

share|improve this question
I'd be very interested in knowing how this turns out. I've looked at Scala a couple times but never dove into it before. – Davy8 Mar 13 '11 at 0:30
Many would argue that for explicit multi-core support, you are better off with threads rather than processes (and Scala actors model processes). This is because you can take advantage of shared memory across the threads. Of course, that is error-prone in ways that the Actor model is not. – Kylotan Apr 7 '11 at 11:01
Scala actors are multiplexed on top of a thread pool, so that they could be more lightweight than threads. This means that they can manipulate shared memory to communicate, provided that it's synchronized properly. If you use remote actors, then they might be on different processes, and the only way to communicate is sending messages. – axel22 Apr 8 '11 at 6:55
up vote 7 down vote accepted

I didn't try, but I'm a Scala programmer, and I would say that this isn't the best approach. Sprites need to be animated synchronously. Actors have no guarantees that they will be executed fairly - some sprites may thus be faster than others, which is not what you want. You might want to use a barrier to synchronize them, but then - why use actors. If you rely only on message passing , implementing this kind of synchronization (implementing a barrier for 1000+ actors) is an overkill.

Another issue is - what would you use message-passing for? Do you need your sprites to communicate? You could send a message by the master actor, telling each sprite to move to the next frame, but in terms of performance, that's magnitudes and magnitudes more than invoking methods directly and iterating through a set of sprites.

Seems to me that what you need here is some kind of a very lightweight multitasking, and no message passing at all. Rolling in your own actor-like implementation which ensures fairness is probably the best way to go if you want to ensure this, but that's too much work for too little gain. Another thing to look is functional reactive programming and scala.react, I believe that is a better match for this use case.

I've implemented a 2d isometric game engine in Scala. I've only used 1 global actor to update visible sprites which were animated.

You might want to implement your game logic using actors - for instance, to distribute computations on different parts of your game map to different actors, so that they update game state in parallel - and gain a performance gain. I would not use a single actor per game object, rather, an actor per region. If you go too fine grained, performance suffers.

Still, if I were you, I'd try it, just to see what happens.

share|improve this answer

So I thought, maybe you can use these as a base class for 2D-Sprites, to break out of the game-loop thing that requires to go through all the sprites and move them. They'd basically move themselves, event-driven.

What would the event be that moves them?

Would it be an event you emit once per frame?

And if so, how has this changed the system in any practical way?

When originally studying object-orientation in the context of C++, I learned that some people liked to think of a statement such as xyz.doThis(x) as meaning 'send the doThis message to xyz (with payload of x) and wait for an immediate response`. When viewed on this level, there's no intrinsic difference between an event or message based system and a normal procedural one.

share|improve this answer
Actors are a multi-threaded solution. The communications are not synchronous. Scala actors (concept from Erlang) allow easy multi core programmation. – Ellis Mar 31 '11 at 3:55
You do have a point there, but the difference here would be that the Actor-based sprite does not block the game loop while performing the action, whereas the method-approach waits until xyz.doThis(x) is done. I think this could even help to make game logic faster, especially on multi-core systems. – Lambda Dusk Mar 31 '11 at 10:35
It makes it easier to distribute the entity handling across multiple cores, true. But the cost of that is that you can't easily refer from one actor to another without either additional messages or extra data sent in the messages. So you quickly realise that the naive approach here doesn't help you - can you formulate an actor-based way of performing the updates? – Kylotan Mar 31 '11 at 23:19
Currently, I am experimenting with some kind of distributed updating: My actors are like nodes in a tree-structure, and updating the root updates the children, by message distribution. Also, the true advantage will be networking: In Scala, an Actor and an RemoteActor (Actor on another system) can be addressed the same way, by the same messages. – Lambda Dusk Apr 1 '11 at 20:03
Yeah, but the problem is not the triggering of the update as such, it's ensuring the recipient of the message has all the information it needs to act upon it. – Kylotan Apr 2 '11 at 12:55

That's a cool approach to thinking about updating your game objects. I don't know Scala, but I say give it a shot and see how it turns out, and even better post your results!

The main questions that spring to my mind are: How do you manage how frequently some game objects update versus others? Will you need to worry about the sprite actors taking up too many cycles such that rendering system doesn't have time to draw a frame every 1/60th|30th|24th of a second?

Another thing to consider is how this will affect resolution of player vs. AI interactions that rely on the order of a sequence of very quick events. Depending on the type of game, this may not probably won't matter much.

share|improve this answer
The great thing about Scala Actors is that they are message-driven. Every one of them has an own message/event-queue. I am not sure if 'Draw' should be a message or a method for call. I think it will be the latter, so that a Sprite can be drawn any time, no matter the state of their event queue. And they can send each other messages to ensure things get done in a certain order. – Lambda Dusk Mar 12 '11 at 22:11
Be careful there, I don't think having each sprite have a Draw method or event would be useful, except maybe as a flag to toggle visibility. In the render phase of a game loop, the order in which sprites are rendered to the screen has a big effect on the outcome. If you have one sprite that is located in front of the other (dimension being in toward the monitor), you want that one to be drawn second. I see Scala's Actors being useful for the update/logic portion of the game loop. – michael.bartnett Mar 12 '11 at 22:56
Usually, you only have a draw method there, so by implementing it that way there should not be much of a difference to the normal way of dealing with sprites. – Lambda Dusk Mar 12 '11 at 23:11
Ah okay, I misunderstood what you were describing. I was somehow imagining sprites rendering themselves whenever and however they please. Let us know how this turns out! – michael.bartnett Mar 12 '11 at 23:45

Well, I'm not that much of a programmer either, but I don't see any problem on your proposal. I didn't even think of such a way of developing actors.

It may be quite a challenge, since the IA has to be very accurate, to avoid unespected behavior, but besides that, I see it's quite a good proposal

share|improve this answer

If by sprite you mean game entity then sure.

Game entities should never draw themselves. They should update a graphic handle that describes where and how they need to be drawn. The render system or scene graph or whatever does the actual drawing. There is one graphic card, further that graphics card must be synchronized every 16ms. A set up like that just doesn't work well for distributed asynchronous processing.

The render system should be one actor (or possibly a couple if you're tricky). When game entities update the graphics handle it sends messages to the render system. The render system, can them make all sorts of decisions and/or optimizations, e.g. batch rendering, occlusion, physics jitter smoothing, etc.

I am not a Scala developer, but I've done quite a bit with Erlang. So if some of my Scala terminology is incorrect, please forgive me.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.