View Single Post
Old 11-16-2012, 09:39 PM   #10
camlorn
Member
 
Join Date: Aug 2011
Posts: 144
camlorn is on a distinguished road
Re: Event-based with threads instead of game loop

Well, akka is synchronous, but not. If you have only one core, and akka decides that the best configuration for your system is to have one thread, all actors will share that thread. It will not appear to be synchronous, if you code the actors correctly; this is why non-blocking actors are important. But, if akka decides that your system can handle more than one thread, then actors will share the number of threads that are available, and it won't always be synchronous. If all method calls are turned into actor messages, and you refactor the code so that you use the reply mechanisms properly, it is possible to either have it be synchronous (with appearence of asynchronous behavior) or truely asynchronous. The akka kernel, unless reconfigured by you, will determine all this automatically. What you would probably do is have one blocking actor that blocks for the duration of your game, and have it send messages to other actors that are non-blocking representing your objects and players, etc. I am butchering akka, here, as it's something I've read a lot about but never really used; akka and scala is typically more research-oriented, though some big companies have adopted it (either facebook or twitter, can't remember which atm), and most of the examples aren't something practical. I doubt, unless you're using scala, that you will "fall in love" with it, but I do maintain that an actor system of some sort will avoid a lot of headaches. If I were coding a mud and decided to abandon the game loop, I'd use actors over threads any day. And, to give it credibility, the people developing scala made their actor system deprecated and are now shipping akka actors with the release candidates for 2.10, with the intent of making it a core part of the language, or something very close to that.

Actors, as a general concept, are a different, more light-weight and argueably less complex, model of multitasking and asynchronous behavior. Thinking of them as threads isn't how it works, not really; doing so will probably lead to difficulties in embracing the concept. The underlying actor library or system will handle the thread part of the equasion for you.

As for learning scala: you can learn enough to use it as the "improved java" in an afternoon. Porting existing java code is easy enough, and they do interop (scala to java--the other way is a bit harder, but very doable, so long as you don't use scala's ability to put symbols in method names).

One nice thing scala offers is this: I saw an example once that actually defined a special // operator on integers that allowed one to do things like val x: fraction = 1//2 (val and var are different, and a bit complicated. it's kind of like a variable). You could then multiply and divide fractions and do anything you cared to with them, include add them to whole numbers and such, and they were represented internally as fractions, and they looked identical to using an int or a float, and you couldn't tell the difference. There's cool stuff in scala, but there's gotchas, too, and I'd have to say don't go learn it if you've got something half-coded in java.
camlorn is offline   Reply With Quote