Pong

[rvanheest]

I made a 'semi-working' implementation of Pong. The ball mechanics is not in yet (still have to figure that out) but the paddles do work! If you want, you can check it out in commit cf88a1c43b301309a43295ad666b8c42898c0968.

(quick remark: the ui is written in Swing, until now. It has to be rewritten in JavaFX, but that shouldn't be a big deal, I think, since I kept a strict separation between Model, UI, UI-observer and controller)

My question is if I used RxJava to its optimum? I have used it in the controller (key controller) only and used Java's 'regular' Observer-Observable pattern for keeping the UI in sync with the model. I know that it is mentioned in several places that Rx's Observer/Observable are not the same as Java's Observer/Observable, but I am not sure whether that means if I can uses Rx's ones for the Observer-Observable pattern as well?

[flatmap13]

You should use Rx for the (GoF) Observer/Observable patterns. Some differences that stand out:

• Rx Observables can signal Observers that there is no more data or that an error occurred.
• Rx Observables are highly composable.

Also, try to keep the blocking (synchronous) code to an absolute minimum, i.e. keep it reactive :-)

[rvanheest]

Great news! Our first game (Pong) is done! See commit 5a8f211881e765af358786caa63ef0316607a146

[flatmap13]

Nice, I was able to build and play the game! Did you identify any concepts that can be reused in the other games?

[rvanheest]

Well, the FXScheduler and key observables are useful to copy to other places. Maybe the Rx team should consider making a plugin next to SwingRx: FxRx or something like that, containing some useful stuff for working with Fx applications.

[flatmap13]

Nice idea, perhaps you can lead the way? :-)

[rvanheest]

Besides having completed this game, we still have a few issues.

1. The program will continue to run if we quit the application. I couldn't find why, even though I looked into the FlappyErik example which is quit similar.
2. We utilized the bug that was discussed last time to get a fluent version of the paddles. In FXObservable line 100 is commented out. When you change this line with line 101, you will see different behavior from the 'hardcoded' sample and the sample that was run by the clock (which is the ideal situation).

In this game I used immutable state for the model. To keep things interesting, the next game (Tic Tac Toe) will be implemented with mutable state instead. I want to see what the differences are for working with RxJava (since most Java applications in 'real world' are using mutable state).

[flatmap13]

Another thing, I thought you were going to implement varying angles of return for the ball bouncing mechanism? Is the speed and/or angle of the ball dependent on the place where it hits the paddle?

[rvanheest]

That was what we intended to do, but it worked out differently... Until now the speed vector is fixed on [vx, vy] = [0.5, 0.3]. First we want to make 10 'working' games and if we have time left, we can add these kind of things.

[rvanheest]

As you already might have expected, I came up with the 'best' peaces of the puzzle during my trip home by bus :)

As mentioned before, I had utilized a bug in RxJava (already fixed) and did not implement the FXScheduler correctly (as discussed during today's hackaton). Now this scheduler is implemented in a better way (copied from the work of @Lars6) and the paddles are controlled by the clock and the inputs: Observable.combineLatest(clock, inputs, (c, in) -> in).

@GeorgiKhomeriki, I assume this was what you meant when we left?

[flatmap13]

Yes, that was what I had in mind yesterday :-)