Another week, another game development related update. If the last couple of days have taught me anything, it’s that it’s easier to get back into the habit of doing a weekly blog than it is to remember where you left off on a project. I also got a good reminder on how quickly code rot can set in (apparently). All in all, just the right amount of weird problems to mark this return to business with a little style. However, lets not get ahead of ourselves.
I thought I’d start off by re-familiarizing myself with the ts-breakout code in general, and in the ts-game-engine code in particular (since I’m going to use it in the fast-approaching Devember project I’m gearing up for). This went pretty well, although I almost immediately discovered a bizarre problem.
Amongst other recently released changes in Sublime is the notion of “Phantoms”, which are styled bits of HTML that can be inserted into edit windows. The base Sublime
exec command (used for building) uses it to capture error messages from the build process so that error messages can be inserted inline with their location in the text.
About three weeks ago, the TypeScript plugin for Sublime was updated, and among the changes is support for phantoms. So now instead of just showing you errors underlined in red, it actually will show you the error message. It also shims in a phantom when you jump to an error message from the build panel.
When I dove into the code the first thing I thought I’d do was insert an obvious error just to see this in action. However I never actually got the chance because it turns out that I already had an error.
In my code for reading the high score list from the browser’s local storage, I pull out the value for the score (which comes out as a string) and then use
parseInt to convert it into a number. However this was generating an error because TypeScript (rightfully) thinks that the result variable is a string, and you can’t store a number into a string.
While I can’t argue with the logic of the error message, I’m entirely baffled as to how that was not an error previously, as the entire working tree was clean of changes as far as git was concerned. I did a little checking to make sure that the TypeScript plugin does not suddenly come with it’s own packed in version of the TypeScript compiler that is a newer version than mine, but that is not the case.
Aside from this little bit of code exploration, I also did some more research for the game that I’m going to try to clone for this year’s Devember project. Unlike Rx I’m not working from documents that precisely define how all of the logic in the game fits together. This time we’re playing it by ear and just coming up with something similar. This seems like a nice test for trying to divine game design of existing games.
To this end I spent a bit of time playing the source game (in a couple of incarnations) and making some notes on how everything seems to work. I did in fact lightly peruse the manual for the game to make sure I didn’t miss any key mechanics, but apart from this I think I have enough to work from. This also sparked some ideas for changes that could be made, as well as extra additions.
I’m currently trying to decide if it’s within the spirit of Devember to spend a bit of time working on some of the graphic assets prior to the start of the project. I’m thinking that this should be OK as grinding away at sprites is most definitely not coding, which is the main thrust of the what Devember is all about. I could also go more the route of Rx, where instead of sprites everything is simply rendered canvas shapes. That also has it’s own appeal.
All things told, there’s a bit of time left to try and figure that one out. Barring any untoward issues my co-worker might have, I have the entirety of next week off. Hopefully I can find some time to work on more game development related stuff in there, although I’m currently spinning a lot of project plates (both of the computer variety and the “real world” kind).
It’s going to be an interesting week regardless.