Sprites as Actors

Question

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.

EDIT:

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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.