Reengineering Tyrant

Developers
LDS
2005-06-09
2013-04-22
  • LDS
    LDS
    2005-06-09

    Hi guys,

    It's been a while since we reported back. The site hasn't been updated frequently either, due to exam and thesis deadline stress, but we're still slowly progressing towards our reengineering goal of modularizing and splitting up large classes like Game, QuestApp and GameScreen (with the ultimate goal being to separate GUI- and Engine/Game-type functionality).

    By now there are somewhat tangible results. If you're interested, check out the SRE branch in Tyrant's CVS. The main design has dramatically changed. We're working on an overview for you, but it isn't there yet (it's still in dead-tree edition lying on our desks :). Here's an attempt at a sketch of the situation so far.

    For a quick taste of the changes, look at these classes:
    - StartApplet and StartApplication: they function as a starting point for respectively, well, the applet and the application :)
    - TController, AppletController and ApplicationController: after initialization, control is handed over to one of the two latter classes (depending on whether the applet or the application was started). This controller functions as a sort of intermediary between GUI and Game, linking the two.
    - MainGUIPanel: This class is going to replace the GUI functionality found in QuestApp. It is never referenced from other classes directly, but rather through the interface IDisplay that it implements

    These are the base classes that have been created up till now. The goal is to get GUI functionality from Game and QuestApp in MainGUIPanel (and possibly others). The Game/Engine functionality will be moved to Game or other classes.

    We were thinking of slimming Game down a bit by moving the restore(), save(), and associated functions into another class. This shouldn't be too hard and makes Game more manageable.
    Also, we were thinking of extracting message-related functionality (think along the lines of pushMessages(), popMessages(), etc) into a separate messageHandler. This operation shouldn't be too obtrusive either.

    What are your thoughts and comments? What do you think of the current refactored design? Do you have ideas for improvement?

    We're happy with all reactions, good or bad :)

    Leen

     
    • On the subject of messages - I think it would be important to make sure that message handlers can be easily plugged in for the purposes of unit testing.

      i.e. you could choose between a DisplayMessageHandler that writes text to the screen or a TestMessageHandler that just logs outputand lets you query the recent results to test that an expected message received.

      I guess the overall principle is that it should be possible for Game to be completely detached from the GUI and run inside a test harness.