Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Architecture wrangling...

Sign in to follow this  


Have gotten a fair amount of work in recently..
We had ANZAC day here yesterday, so with a day off contracting it gave me another opportunity to work on the game.
Spent the first part of it tweaking the software architecture. This is really a bad habit of mine that I'm trying to avoid!! I must confess, I'm an architecture junkie.. could happily tweak the design for days and still not be satisfied :P

Fortunately I was able to restrict my latest relapse to half a day and I think the new design is better for it.

The original design was based on the popular Model-View-Controller architecture pattern.

I think this is a good choice for games as it forces the separation between the "presentation" - the rendering engine that displays graphics to the screen and the "model" - the part of the engine that handles the rules of the game and other calculations.

Ironically (maybe) through the Wikipedia link to Model-View-Controller, I discovered this excellent link on GUI architectures and ended up modifying my design slightly to be more in line with the Model-View-Presenter pattern with a passive view. (these terms are described verbosely on the website above)

Due to an implementation constraint caused by driving the game via Python (another story altogether), I've already been forced to implement a "form server" as a stand-alone COM server, which is driven by a Python extension module which is, in turn called by the main module running in the Python interpreter.

The new design introduces the concept of a "Presenter" module which is (amongst other things) responsible for organising the layout modes of the form server. Up until now this handling was implemented in the form server itself, but now it has been reduced to a dumb slave that must bend to the whim of the Presenter!

The presenter will be written as a pure Python module, with the form server a python extension module written in Delphi that calls COM, the advantage of this is, if the game is ported to another platform, only the "view" (form server) of the M-V-P architecture need be rewritten and it is now "dumb", so should take minimal work. Well at least in theory :P
Sign in to follow this  


Recommended Comments

There are no comments to display.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!