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.
Can I Help?
I hope you found this article useful. I'm always available to help with any web questions or issues you have, and offer a wide range of services from simple by-the-hour tweaks and repairs through to fully custom websites. I'm a WordPress specialist and can fix or modify your WordPress installation or build in new functionality. I also offer a free website review (see below) to see where the web could be working harder for your business.
Click here to drop me a line today with any questions or anything you'd like to discuss. I'm here to help!
Free Website Review
Do you wonder whether your website is doing you justice? I look at your website, search engine rankings, social media and reviews, and let you know where you could be leveraging your online presence to do more for your business.
My PDF report is 1000 words written specifically for you. I'll tell you simple, easy wins you can do quickly and for free, through to what you might want to consider if you redesigned your web presence. It's completely free and comes with no obligation other than to tell other people if you find it useful.