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?
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.
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.
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?
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.
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.
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.
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.
For today’s Devember update, I bring you an ugly and not entirely functional title screen! Also I thought I’d show off a picture of the game over screen while I’m at it, since I never did that yesterday.
Our title screen is currently very simplistic with just some (vaguely) informative text and a semi-functional menu. This should actually allow us to select a level AND a speed AND a music, but I don’t have sound support yet and speed support is not added but would be simple to do so. Also the level changing does not yet function (it should really be a slider or something, but this is a simple prototype after all). However, the option to start the game actually works.
The prototype title screen
Selecting the start game option switches to the game scene, which is the main scene that drives the actual game play. When the game is over, it switches to the game over screen:
Our simplistic game over screen. “Press enter” flashes for “panache”
This should really display a menu to start over or quit, but for now it just has an implicit retry; pressing enter switches back to the game scene again. As mentioned yesterday, the game over screen invokes the render method on the game scene before rendering its own text.
This is not a lot of outward forward progress but behind the scenes I am working towards a more generalized menu scheme that I can pull out into its own class or classes for reuse; possibly into the engine itself. Currently the code is all in the title screen method, where I’m working to implement all of the features that I think it should have before I start to make it more generic and refactor it out.
Based on the proximity to Christmas and the enjoyment of festivities therein, I’m not sure how fleshed out this is actually going to get over the next couple of days. I would like to have this and possibly also the image and sound preloading into the engine before the end of Devember, though.