Replacable graphics engine

[danielduner]

I think we should try to make the graphics engine replaceable in some way.

This has already been done for sound (using an interface), which allows us to have a place-holder sound player that can be used on computers without sound cards.

Possible uses for replacing graphics:

• When using unit tests, perhaps we want a dummy-graphics module that doesn't actually draw anything
• During AI-training we want to avoid drawing anything, to make the game run as fast as possible (in combination with removing the ticks-per-second limit)
• When porting the game to some other Java platform (for example GWT or Android) we will want replace the graphics engine, sound engine, input system and resource loading/saving (but probably keep the rest of the game mostly intact)

[master-lincoln]

I think we only use the Bitmap class methods for drawing. So this would be as easy as creating an interface...

[danielduner]

I think so too :)

[kylecbrodie]

Solved! see my branch abstract/graphics. I'll send a pull request tomorrow must sleep

[danielduner]

I haven't looked at your code, but I've just gotta say: I love working on this project <3

[fierydrake]

I have a huge refactor of MojamComponent I'm working on in my local copy. You may or may not think this is a good idea. Basically, it splits into a bunch of bits: GameLogic (most of tick()), GameInput (interface), GameView (interface), CanvasGameView (implements GameInput & GameOutput), GameSound (interface), SoundPlayer (implements GameSound), Menus (a Deque to hold GuiMenus). GuiMenus got a refactor with automatic locale awareness. Texts became the owner of setLocale() and notifying listeners of locale changes. ClickableComponent became locale aware through new class LabelledClickableComponent, and the ids were removed in favour of dealing with clicks in the GuiMenu definition by adding ButtonListeners.

This is a means to an end: that is to allow an easy interface (GameInput/GameView) to making adding SynchronizedNetworkView and UDPNetworkView (and corresponding RemoteGameLogic and potentially LocalGameLogic and ServerGameLogic -- may make these the same).

That way the RemoteGameLogic can implement response prediction and ServerGameLogic can inherit from LocalGameLogic and additionally implement lag compensation (in their UDP implementations, at least.) The SynchronizedNetworkView would use the current synchronized random approach.

[master-lincoln]

@fierydrake Looking forward to the pull request. If there is an end in sight with your work, we could hold back other major contributions to the mentioned classes.

[fierydrake]

@master-lincoln I'll try and push a branch for you to look at. Unfortunately, due to the exploratory nature of the coding, it's all come out in one big lump rather than a bunch of reasoned commits. This is going to make it hard to merge. I'd appreciate comments, because I'm aware that not all of my ideas are good ones (although note, there's quite a lot of "deal with this nastiness later" going on, because there's so much that could be done). Sorry to take this issue a little off-topic, will continue discussion in a separate issue.

[godleydemon]

looks like parts of this is done, the other bits about slick2d should remain in its own issue. Closing due to inactivity.