So of course as this entire section of the blog is devoted to, in December 2015 I did Devember, for which my goals were the following:

• Learn the TypeScript language to try and ease the pains of writing object oriented code in JavaScript for the web (specifically games)
• Evaluate the workflow for using TypeScript in WebStorm, especially as it compares to using JavaScript
• Get more familiar with GitLab as an evaluation of how well it integrates with my work flow (primary reason: it allows private repositories for free, which GitHub does not, but also I’m looking at locally install-able solutions).
• Get back into the swing of game development again after a long hiatus

The outcome of this entire operation was a game prototype I called Rx which was a simplistic Dr. Mario clone. The “final” version is posted at itch.io:

[Edit: In December 2016, Nintendo swept through itch.io and threw DMCA take-down notices at anything that looked vaguely Nintendo related, so I deleted the project from itch.]

Continue reading

This years Devember draws to a close with a couple of last commits, cleaning up the remaining issues in the code base. This has been a great experience in generating content for public consumption and I would do it again in a heartbeat.

Reminder: the project repository is hosted at https://gitlab.com/OdatNurd/devember-2015/, with tags for the state of the repository as of the end of each day of Devember.

So what’s different in the code versus yesterday?

Continue reading

The entirety of today’s changes are fairly anticlimactic from a development standpoint, but perhaps a little epic from a git merge hell perspective?

The goal today was simple: the engine and game code were compiling to the same output file, but it was time to have it compile into two parts; the engine and the game.

The rationale for this was to make merges easier, but also to speed up game compiles. One of the things that I’ve noticed over the last month (which didn’t surprise me) is that with TypeScript you can’t just save and reload the page; there has to be a bit of a delay there to allow the compiler to notice that things have changed and recompile. Oh, the number of times I mistakenly though I had not fixed a bug only to discover I didn’t wait long enough.

Continue reading

Yesterday’s plan for today was to work on a SpriteSheet/Sprite/Animation class cluster, but a bit more research into that gave me a bit of pause so I went ahead on to the next item on my list in the interests of getting the Rx prototype more “complete” by the end of Devember, sound.

Primarily the reason for the switch was due to my being unsure as to the best way to proceed with the image code I was working on. It seems that the load event won’t fire if the image is already loaded when you add it, (as far as I can see, anyway) which is not great for code that wants to consume the image. You need to add the handler BEFORE you start the load. I could use the complete property to see if the image is loaded, and if not add an event handler, but that seems like it would create a race condition since events happen asynchronously.

In any case, I proceeded on to including music and sound into the prototype, because if there’s a thing that makes a game seem more “gamey”, it’s sounds and music. You know, if you discount good art, solid game play, controls and other things like that.

Continue reading

First there was sound and music, now there is the ability to stop it from happening. Also a resolution to yesterday’s problem as well.

After giving things some thought, I have fixed the issue I was encountering yesterday, which was really more of a logical inconsistency than anything else. The solution is not 100% clean, but then in game development, I guess that’s the norm?

Continue reading

Today’s changes are hard fought but that mostly has to do with bug chasing. Blah.

I extended my audio preloading to also allow for preloading music files. In reality this is just a special case of a sound that is played looped, but by adding another method and refactoring some code, I could allow for music to be stored in a directory different from sounds, which is better for my delicate sensibilities.

Continue reading

Another “short but sweet” update for the day, due to some after Christmas errands and get togethers with family.

I fixed the bug from yesterday, which turned out to be an incredibly simple rendering bug, of all things. I never tested the blitting API for images when I ported it to TypeScript (shame on me!) and the method for rendering a bitmap centered at a location was broken. The method cheaply translates the canvas to the location to render to make everything simpler but it was not properly restoring the canvas context afterwards.

Continue reading

Well it’s Christmas and it’s been a busy day, but I did manage to find a free hour to throw some code at Devember.

Today’s update brings the beginnings of image preloading so that game prototypes can use actual graphics. Usually at this stage I just do crude rendering, but some things require more detailed or easily recognizable place holders than simple vector graphics sometimes allow for.

I have a simple utility function (well, functions) that allow you to register images to be preloaded, and then kick off the preload. This is fairly simplistic and seems to work just fine. In integrating it with the engine I thought it best if it was transparent so that all you have to do is say in a Scene constructor that you want to preload an image, and then when you invoke Stage.run() it does the preload for you before starting the game loop.

In this area I have some weird bug; the images preload but the dots in the sample “game” that the engine packs with don’t bounce around like they should. I’m not 100% sure why exactly this is the case, but I ran out of debugging time before the arbitrary time limit I set for this.

Now it’s time to get to bed; Christmas may be over, but the usual weekend chores go ever onward.

This will be a short update due to it being Christmas Eve, so lets get right to it.

Firstly, I fixed a bug in the Pointer entity that I introduced when I started with the menu code. That update allows for rotating the pointer in any direction. Since facing right is a rotation of 0,  I modified the polygon to point that way by default. Unfortunately, this breaks the pointer for other orientations.

Continue reading

Today’s update is pretty minimal as far as progress is concerned. The state of things is the same as it was in yesterday’s update, but the code that does it now looks TOTALLY different. Assuming that it being the same code but in a different layout makes it in any way different.

Continue reading