Last week, we wrote about some of the menu support tasks we handled for Project Spaghetti in overtime. This week, we decided to make the switch from the hand-coded coordinate system to a more object-oriented approach. What this means is that we no longer have to manually write down coordinates for where we want things to respond to the mouse, and we no longer have to redo the same code over and over again for each individual menu item.
The main reason we went through all of the work it took to completely switch over the menu system was a little trepidation about how the game would work on touch devices, should we produce it on those platforms. All of the hand-coded coordinates should theoretically work, as we have GameMaker surfaces doing all of the work of resizing our screen to fit different resolutions, but we couldn’t be sure, and switching to an object-oriented approach came with three other advantages: 1) changing the menu is much, much easier, 2) localization is easier, and 3) less code means fewer places for things to go wrong.
Menu changes are easier, because each menu option is contained within an object placed arbitrarily in the room. If we place “Start Game” in the upper left corner, it just works, whereas before we’d have to dive into the script and readjust everything, including menu options unrelated to “Start Game”. This means, if we need to add a new menu option in the future, say “Leaderboards”, we could just pop it in wherever we need. Arrow selectors and slide bars are also all objects, which can be added as needed.
We also have the mouse reaction area auto-sized to fit the text, which leads to the second advantage: making localization easier. It’s a relief not to have to worry about text lengths breaking the system. It also helps with English, because we don’t have to go in and figure out resolution coordinates for each menu item based on how long the text strings are.
And, of course, because we switched to objects, repeating code that does the same thing is no longer necessary. We make it once in an object, and create as many instances as we need. If anything is broken, it’ll be broken everywhere, which is actually a good thing because it makes problems easier to spot and address.
In addition to moving menus to an object-oriented approach, we did fix the player dodge from last episode by, again, simplifying things. Rather than worrying about speeds in 4 different directions, and whether or not the dodge input came from the mouse, a controller, or a keyboard, we relied on one speed and the player direction to determine how far the cowboy would slide when he did a dodge roll. That results in much less code, and it works the same way regardless of whether the keyboard, controller, or mouse is being used to move the character. One path means only one place to look if something goes wrong with the dodge!
A few other behind the scenes tasks we took on in overtime were 1) testing a fade transition and 2) switching from a hash file check to a base64 encoding system for save files. The fade transition was relatively easy; we created a persistent fader object that lives on a timer and dims then undims the screen when it gets made. And switching to base64 encoding was simple as well. Before, to ensure players didn’t tamper with important values in the save file, say high score, we created an encoded hash file, which would be referenced whenever the game loaded values. If the game detected tampering, it would default the high score to 0. It worked, but it resulted in an extra file, potentially confused players, and a possibility for something to go wrong, whereas with the base64 encoding, the high score is just encrypted right in the save file, making it much, much simpler and safer. Plus, without a tempting number staring them in the face, players will be less tempted to modify the value and end up breaking their game!
That was quite a bit of overtime, and, except for dodging, none of it is anything the player will ever see, but it’s a relief to get it all done in time for this weekend’s episode!