Can I build a multi-threaded system that handles events from a game and sorts them, independently, into different threads based on priority, and is it a good idea?
Here's more info:
I am about to begin work on porting a mid-sized game from Flash/AS3 to Java so that I can continue development with multi-threading capabilities.
Here's a small bit of background about the game:
The game contains numerous asynchronous activities, such as "world updating" (the game environment is constantly changing based on a set of natural laws and forces), procedural generation of terrain, NPCs, quests, items, etc., and on top of that, the effects of all of the player's interactions with his environment are programmatically calculated in real time, based on a set of constantly changing "stats" and once again, natural laws and forces.
All of these things going on at once, in an asynchronous manner, seem to lend themselves to multi-threading very well.
My question is:
Can I build some kind of central engine that handles the "stacking" of all of these events as they are triggered, and dynamically sorts them out amongst the available threads, and would it be a good idea?
As an example:
Essentially, every time something happens (IE, a magic missile being generated by a spell, or a bunch of plants need to grow to their next stage), instead of just processing that task right then and adding the new object(s) to a list of managed objects, send a reference to that event to a core "event handler" that throws it into a stack of all other currently queued events, which then sorts them out and orders them according to urgency, splits them between a number of available threads for as-fast-as-possible multithreaded execution.
Best Answer
Ahhh concurrency in Java :-). Right, so I'm going to give some general advice here:
Model your asynch processing on a whiteboard, then get someone else to come in and challenge your assumptions, especially the assumption that you need it in the first place (it sounds like you do, but it never hurts to challenge that). There's a whole bunch of concurrent data structures you could use to model what you're trying to achieve, see my mention of Brian's book to get a good practical guide on these things (in Java).
Concurrency in Java is hard - Objects are mutable by default, implicit locking is hard to get right and you often have to deal with the low-level construct that is Thread itself. If you are going to do the work in Java, then read Brian Goetz's excellent Java Concurrency in Practice to make sure you avoid the major pitfalls. Java 7 improves things again, but there's still some fundamental issues that make it hard (for now).
Given 2. it's well worth looking at a framework or even another language on the JVM that abstracts away from this. Popular choices today include the Akka framework (that both Scala and Java support), GPars (Groovy) or out and out Clojure (If you like Lisp).
HTH a little!