Client Architecture

Some time ago I was thinking about the client and how I was going to design with Gui flexibility in mind. I put together a little design diagram which used the bridge pattern to help me vary Gui libraries alongside variations in screens being rendered.

However, once I started looking at the code for wxWidgets I realised that this design would not be sufficient because Gui libraries such as wxWidgets are not just libraries of widgets that you plug into your existing applications - they are complete application frameworks within which you develop your code. What this means is that changing from say wxWidgets to Guichan (the one I used whilst developing Morde) is not just a matter of swapping out a few classes. It's involves reworking the architecture of the client code completely.

In addition to the possibility of supporting multiple Gui libraries in case I should want to switch at some time, I also want a front end that does not have any graphics and just outputs to a console. I could use this for unit-testing. For example, rather than manually testing my Gui by loading it up, moving a module around and checking it works, I can develop unit tests which will call functions that simulate the user having pressed navigation buttons to the same effect. Thus, I can automate the testing of pushing a module to the boundaries for example.

If I wanted to get really clever, I could put this kind of behaviour into a script, give it some basic intelligence and I have myself a 'bot' that can play the game according to its scripted rules. Now why would I want bots? Well, for starters I could create bots that perform a complex set of steps for more thorough testing. Secondly, but adding some randomness I may expose bugs that I hadn't uncovered via my hand-crafted bots. Lastly, it could form the basis for scripted NPC modules which will act as enemies in the game.

So, I need at least two completely different front ends. In the case of graphical one, no matter what Gui library I use, I want to use SDL for my underlying drawing code so any SDL code can sit in its own library and thus I can make my real client very thin in architecture. Here is a new diagram that I knocked up:


I've just made up names for classes here, none of them are in place yet. The common library is common to both server and client code.