Overhaul World threading model?

[rdlester]

Currently, each World inherits from Thread. This, from one perspective, is pretty wasteful, as it means that switching between Worlds requires spinning one thread down and another thread up. It would be better to simply have a single "Logic" thread that stored an "active World"; switching between Worlds would then simply consist in changing the active world on the logic (and main Processing rendering) thread.

On the other hand, if one treats World as a System in entity-component-system, it might be nice to have multiple Worlds running at once on separate threads, each handling an individual component of the game logic. This is perfectly possible in the current system, but not how we initially conceived of Worlds, however, and is not how our tutorial is written. It'd likely be a lot harder for inexperienced programmers to understand.

[samael775]

Hey Ryan! My github email was out of date so I just noticed all your comments about updating for Processing 3.

As I recall, we had always conceived of the game having one World. The only reason I can think of switching for Worlds would be for say switching levels. And the spirit of Hermes and of Processing is simple and easy to use. You shouldn't need to worry about things like multithreading. Supporting multiple Worlds as threads might be a cool option for advanced users, but we wouldn't want a beginner to have to worry about it at all.

So I'd say whatever's simplest. If there's a viable way to use Worlds for multithreading maybe that makes sense, but only if that doesn't complicate things for the average user.

[rdlester]

The single-World-per-game model really only works when just prototyping a mechanic; it becomes a little tough to manage when you want things like menu screens separate from the main game. Users do in fact seem to want this. The most apparent way to build these in our current system is to make a World for each type of screen (main game screen, pause screen, main menu, etc), then switch between them. Only one will ever be active at a time.

Currently, we do not enforce that constraint. Since World directly subclasses Thread, the user has to manage switching between Worlds themself; if they screw up, they'll wind up with multiple threads running simultaneously. Additionally, threads are expensive to start and finish, adding a ton of overhead to each switch. Note that World subclassing Thread already means that it is currently viable to use Worlds for multithreading.

My suggestion is to remove the Thread superclass from World and instead add a WorldManager singleton class that inherits from Thread. Users will start or switch between worlds with WorldManager class methods, which will take care of properly completing one World and starting the new one. This will vastly simplify switching between Worlds, and will additionally remove a lot of boilerplate from starting up a World even when only one is used in a game. If this sounds good to you, I'll close this bug and merge it into #7.

Of course, none of this really matters if I can't get Hermes to work with Processing v3 (see #6).