Uzma’s Quest : Thinking About Software Architecture
I want to develop Uzma’s Quest a lot further, but I coded it bit-by-bit without any overall planning, I just sat and coded. Before I can go any further I need to recreate the code with a functional architecture that will allow me to add future code cleanly.
Unravelling the current code
Understanding what I’ve already written isn’t too hard because I wrote it (duh), and I did separate everything up into several modules and a configuration file as I went. I started by going through the major modules and their public functions and mapping out which functions call which and what everything does.
As I began to create a list of details for what each function does instead of having them buried in code, I was able to create a list of exactly what needs to be done in the order to do it.
Blue boxes compute and update values in the global data object, yellow boxes change or create CSS values and green boxes create or delete HTML elements. I originally thought of isolating the CSS and HTML functions within their own modules but it works more logically this way.
Major Game Modules
The loop in the diagram is what I call the recurringGameProcess or RGP, it’s the code that runs over and over while you are playing, until you get to an exit game function (in the red boxes). But there also screens that display at the start, when you complete a level and so on.
Currently, although the ‘gameboard’ is emptied of html elements when the game is not playing, it is still there and the instructions screen is a modal which lays over the top. It’s a function I threw in at the end and isn’t well structured.
It makes more sense to consider the RGP as one ‘mode’ of the game, while the game is playing, and the other screens as a different mode, as though they were two completely different programs.
The modal screen module in green can take care of all the screens to display and changing them according to user input. When the game starts we switch to the RGP module in red, and switch back when it stops.
To do this both modules need to ‘self-create’. When the game starts the RGP module needs to create all the html elements it needs and all the data that it needs. That way both modules will be able to operate without fear of encroaching on the other. Any data that module needs will be passed into it either from a configuration file or from arguments passed into it from the previous module.
The modules in blue will act as bridges between the two game states. When the game starts, the initialise function will delete all html for the modal screen, create and populate the game data object, create all the HTML and CSS it needs, and set the RGP in motion. When we go back to modals, the stop game module will delete all game html, and create and populate the html for the modal screen.