Friday, April 20, 2012

Game system software architecture

Before I start with Milestone 6, which is about the implementation of a game system, I decided to do some refactoring first.

To allow quick and easy changes to my game system, all logic related to it should be concentrated at one place: A GameSystem class which implements all the game rules. All the provisoric existing logic needs to be removed and replaced with calls to this class. The game system does of course need the system-specific stats of all the participants like mobs and players. Storing this data in the existing objects would be a violation of the principle to isolate the game system. So every participant now gets a gameSystemDelegate object with all the game system specific data which is received from the GameSystem during construction and is passed to every call to GameSystem instead of the original object.

To allow easy replacement of the game system, I decided to follow the principle of dependency injection and the strategy pattern. GameSystem as well as the delegates GameSystemPlayer and GameSystemMob are only interfaces. The implementing class Wizardwar is only referenced in the main class, where it is used for a global GameSystem object referenced everywhere else. The implementations of the delegates, WizardwarPlayer and WizardwarMob, are only referenced in Wizardwar.

That way I could create an entirely new game system, and the only place in the engine code where I need to make a change is the line gameSystem = new Wizardwar() in the Main class.

About the wizardwar package itself: I intend the delegates to be "dumb" data holders with all members set to public. All game logic should be contained in the Wizardwar class.

No comments:

Post a Comment