I tried adding the floor using Tiled and TexturePacker — I really did. Unfortunately, it does not appear to be working and I really don’t have time to fix it now. The code and files are all there, so it probably won’t be too hard to get it working once I do find time. I do have a question about it though. Why is there no callback to let us know when it has finished loading?

One weird thing is that “spritesheet.js” will not load at all. In fact, it completely hangs up the asset loader Javascript code and keeps the game from running. I had to comment it out. I was not really using spritesheet.js anyway, but I find it curious that it could somehow stop the show even though I was not calling that code. Another mystery to be solved when I have the time — later.

And speaking of the asset loader and atlases, I asked the following question on the Udacity forum and as far as I know at the time of this writing there has been no reply yet. Here is the question:

If loading images one at a time is such a bottleneck that we create a single image instead and then use it as an atlas, why don’t we combine all of our Javascript files into one file? (Probable answer: very different file sizes and load times between images and plain text.) Given that I have to flush my browser’s cache (or tell it not to cache in the first place) in order to run my latest Javascript code anyway, it seems like it would not be such a hardship to keep it all in one file. That is generally not good programming practice, I know, but given all of these other issues, it seems reasonable — and if not, at least after everything is finished it seems reasonable to combine all of the Javascript into one file. This is particularly the case because I ended up having to load my Javascript files in at least three batches to avoid race conditions on code dependency.

Maxwell’s Demon is ready to play, if not quite ready for prime time. I still need to lay down a floor using the tile atlas, and it would be nice to pre-load my audio. Of course, a background soundtrack would be good to have too. Alas, I have not time for all of that. I’ll start with the atlas and see if I can accomplish anything else, but I really need to study for the certification exam instead.

I have switched over to Maxwell’s Demon. It currently has a hot molecule (in red) and a cold molecule (in blue). You don’t have to watch very long to determine that molecules can change temperature when they collide.  I will need to take that into account. It would be fun to show a distribution graph alongside the game. I will do that when I have time. I suppose “losing” would be when the molecules all reach some type of thermal equilibrium.

Note to those having trouble with items sticking to walls (as I was). Set

• Box2D.Common.b2Settings.b2_velocityThreshold = 0.0;

first thing to avoid this problem.

I finally got my paddles working properly. I wanted a key press to pop up a paddle for a tenth of a second and then have the paddle disappear. This worked well, except for the fact that my keyboard, like most keyboards, will automatically start sending repeat key presses when held down. So I had to add some logic to the InputEngine to essentially disable the onKeyDown method for a key immediately after its first invokation until a matching onKeyUp method call for that key re-enables it.

Oddly enough, now that all of the pieces of “Meltdown!” are present, I have decided to switch to a game based on Maxwell’s Demon because it will be quicker to program and more fun to play. “Meltdown!” will probably need a great deal of game play, testing, and redesign to get it right.

I am hard at work using the InputEngine to pop up paddles with which to whack the ball. In so doing, I discovered an apparent error in InputEngine.js. Whereas it has “event.keyID” for identifying which key is pressed or released in the “onKeyDown()” and “onKeyUp()” methods, the correct attribute is named “event.keyCode”.

No steps back! Things are finally starting to come together the way they are supposed to do so. I have added sound to the game. I still need to load the sounds before the game actually launches, but that is a minor issue.

I finally have my ball on the canvas. Unfortunately, it is not behaving well at all. Ideally right now it should just sit there because I have defined gravity as:

b2Vec2(0.0, 0.0)

But for some reason, the y-value is changing. To add weirdness to it, the y-value changes differently for different starting y positions. I think it has something to do with my “ground” bounding box. Time to do a little exploring.

Update: It was a problem with my ground bounding box. My ball was inside the box. Turning the ground into a “wall” and placing the ball outside of it fixed the problem.

Update update: I now have a bouncing ball! This might actually work now!

I added the InputEngine.js Javascript file to the game only to discover that the gPlayer0 object it requires is a mess. For one, it is obviously supposed to be global (since it starts with ‘g’), but is instead within gGameEngine on Udacity. I am beginning to think that I should download the Grits code and start from there.

Meltdown! is not really a game yet, but it is doing many of the things games do. For one, it has a functioning game loop now. If you go to the web page here, at the time of this writing you will see it displaying some text with a running counter on the canvas. Google Chrome says that it is running very close to its desired frame rate of 60 fps (Frames Per Second). I am liking Google Chrome’s developer tools more and more as this project continues. If you don’t need a running assessment of frames per second, I was pleasantly surprised to find that the code works just fine on Internet Explorer 9.

I also realized today that at the end of Udacity’s “HTML5 Game Development” course, you don’t have a functioning game! This is a huge oversight in my opinion. I suspect that the instructors just ran out of time, probably due to trying to do too much too quickly. The whole course should probably be redone with a very simple game in mind (a single bouncing target with one turret gun to shoot at it, perhaps) that is developed from start to finish as the course progresses. It could still have all of that wonderful stuff about atlases, asset loaders, physics engines, audio, etc., but everyone would also have a working game when they finish.

Among other things, we are encouraged to use readily-available tools such as Tiled and TexturePacker. I downloaded those yesterday and fully intend to use them, but I doubt that they will add much to my little game at this point and I am rapidly running out of time. TexturePacker may be useful to me in Steampunk Road though. After I finish this project, I will have to see if I can integrate an atlas in with Google’s Maps API to cut down on load times.