That’s a pretty cool idea, but it’s not what I was thinking. The API seems a bit clouded. I should explain a bit more.
By default the observable is ‘executed’ using the game loop scheduler. This schedules the observable to compute in the same tick, and is a good behavior for most cases.
There should be a Scheduler interface. One for the game loop(e.g. server.scheduler.loop), one for ‘asynchronous’ computation server.scheduler.async that is outside the game loop, and finally a delayed game loop one server.scheduler.delayed.
I’ll explain. Once the middle action is done(with the slow math), we’re no longer in the same tick of the game loop! That is what the server.scheduler.loop scheduler is. Remember that at runtime the whole observable chain gets resolved, so loop will refer to the resolved tick, which is a good default behavior, but not what we want. In essense, loop always references the scheduler in the current tick. If we tried to execute something in the loop scheduler after that tick has passed, we’ll get some sort of error. Instead, we wish to use the server.scheduler.delayed scheduler, which schedules our computation for the next available tick.
If we wish to do computation in a different scheduler, that’s what we tell the observable. Your example is pretty similar, but instead becomes:
Observable<Vector> positions =
server.events.playerMove().map(new Fn<PlayerMoveEvent, Vector>() {
public Vector call(PlayerMoveEvent event) {
return event.getPlayer().getPosition();
}
})
.schedule(server.scheduler.async) // for async computation
.map(new Fn<Vector, Vector>() {
public Vector call(Vector vector) {
return /* do complex slow math */
}
})
.schedule(server.scheduler.delayed)
// put it back in the game loop as early as possible
.on(new Callback<Vector>() {
public void call(Vector vector) {
// apply result on the main thread
}
});
And I agree that with Java 8 callbacks and functions will be super sweet. 