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
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.
The project is progressing. I started where CS255 ended: loading assets. I am currently loading box2dweb from a script that also loads my images and will load my sounds (when I have sounds). Next up, I need to get the ball bouncing.
Although I have worked with WordPress for other people in the past, this is the first time I have used it myself. I can see the appeal for bloggers. I think that I shall add a blog to Steampunk Road as well, particularly if I can find a 19th century newspaper or steampunk theme.