Valkyrie Dev Blog #13 – Framework

Warning: No pretty pictures or anything in this post

So nothing has happened on the front-end since post #11 but a lot has been happening behind the scenes. I’ve never worked on a game of this scale before, but I recognize the value in having a well-organized system for how things are processed in the game. So I’ve been working on setting things up to be much cleaner than they were initially. When I started, I was still in “test mode” so all of the code was pretty much crammed into a single “song controller” object that would load in the simfile, extract the necessary data from it, spawn the arrows, and then manage the timer the arrows all reference. As the game grows bigger and more complex, this kind of approach is simply not an option, so I figured I should start fixing it sooner rather than later.

Loading process – First order of business was to separate the simfile loading process from the actual song gameplay code. Part of the song controller was split off into a song loader. The process goes like this internally: The player selects a song from the menu and a song loader is spawned. The loader opens the simfile and reads in the data. During the data extraction process, it also validates the data. If there’s anything wrong with it, loading is aborted and an error is generated (more on errors next). If everything is good, the required data then gets passed along to the song controller, which then goes ahead and spawns the arrows and runs the song.

Error reporting – Again, as the game gets bigger and more complex, it’s important to have this under control. The more components are added, and especially given that user-generated content is a part of this game, opportunities for errors to arise only increase. Unfortunately, Gamemaker: Studio has some shortcomings, one of which being…well, a nonexistant error system. Many languages have exceptions, but GM does not. If a fatal error is encountered (say, division by zero, for example), the runner crashes and the end-user is presented with an ugly error that exposes some of the inner-workings of the game. User experience should be kept simple and clean, so having them see code like that is certainly not ideal. But since there’s no way to handle these errors in code, our best bet is to find erroneous inputs and either correct them or stop the processes before a crash occurs. So I ended up creating my own error system that works like this: At the beginning of the game, an error handler object is spawned. Whenever new “controller” objects are spawned, they are passed along a reference to said error handler. Each controller does their own error checking, and if they find one, they call a function I wrote that will pass some information such as what object detected the error, and an actual error message, along to the error handler. The handler will then log the error and determine the next action to take, such as kicking the user back to a menu or displaying some sort of error message.

So yeah, this post is kind of more on the technical side, but I wanted to share some of my experience here, working with setting up an internal framework in the game, as it’s something I’ve never really done before. All previous projects of mine have been simple enough not to require this kind of structure.

Anyway, see you all next week!

You May Also Like

Leave a Reply

Your email address will not be published. Required fields are marked *