Decouple Game and Graphics Engines entirely.

[danini-the-panini]

In light of what Dr. Solms mentioned at the demo, as well as the exchange of emails between us, I have come to the conclusion regarding the interactions between Tokyo and the Graphics Engine. I believe that the two are too intertwined, despite the fact that Tokyo speaks to Athens purely through an [interface/abstract class].

My idea is that, through some kind of observer design pattern we can leave the representation entirely up to a third party (such as the frontend) or a fourth party (such as a component specially designed to transform Game States into drawables). The communication is described in figure 1.

    +-------------+                     +--------------+
    |    Game     |                     |   Graphics   |
    |   Engine    |                     |    Engine    |
    +---------+---+                     +--------------+
        ^     |                                 ^
        |     | 1. Notify observer to draw      |
        |     |                                 |
        |     |                                 |
        |     |                                 |
        |     |       +---------------+         |
        |     +------>|               |         |
        |             |   Observer    +---------+
        +-------------+               |  3. Tell Graphics Engine
 2. Read game state   +---------------+     to draw

Figure 1. Communication flow in the Observer Pattern.

Pros:

• Complete Decoupling of Game and Graphics Engines.
• Moves resource loading outside of the Game Engine.
• Game Engine becomes all about Game State updates and nothing about visuals
• Completely allows the Graphics Engine to be added or removed at any time without hassle from the Game Engine side.

  Cons:

• Requires the addition of another component.
• Requires the development of an observer design pattern
• Performance MAY be a concern, but I doubt it (See Dr. Solms's emails)
• Requires a large amount of refactoring on the Game Engine's side.

  Conclusion:

I believe the Pros outweigh the Cons in this case. It requires a bit of effort on behalf of the team, and we should sit down and design the communication flows between the components. However it provides a large amount of flexibility and based on the tests Fritz and I have done will probably not amount to much performance decrease. We can do profiling after the change to see where any bottlenecks form but I am pretty sure that we will not find any, and if so they will probably be due to a silly mistake somewhere.