Today is the deadline for milestone 2 where we should present a proof of concept to show that our projects are viable and we will be able to finish them. I plan to present the current state of my game and talk a little about how development has gone.
In the milestone 2 directory I have committed all the necessary source code to run the game. The only caveat is that it needs to be hosted by some form of web server such as a local Apache or Node.js instance if you’re using chrome since that browser has some issues loading the textures. For this reason I have put up the source on my server (link in side menu). However using Firefox you can just open the file index.html and play the game.
So three(.js) weeks have now passed and Milestone 2 is on Monday. This will be a fairly short post in part since I have not done much visual word this week and in part since I will make a post on Monday describing the current state of the game.
With that said this week has mostly been devoted to debugging memory problems, as presented in the post “Memory Problems“. I posted that on Tuesday thinking I had solved all problems but this did not turn out to be the case. On Wednesday I found I leaked arrays and objects in the collision response between balls and paddles. After that was solved a small leak still remained in the broad-phase collision detection which I have not modified. I tried a few hacks to get around this in the physics engine one of which helped a little bit. Right now the memory used increases with approximately 100 KB / 10 minutes. While this is certainly not good I recon it won’t be a big problem since by design a game should not take more than 5-10 minutes making a leak this small irrelevant.
Other than profiling I have done some work to make the game feel more well built by using a small button bar with help and stats info instead of printing this beside the canvas. This also allowed me to make the canvas fill the browser window. After some tweaks in the graphicsManager the cameras and renderer changed sizes and aspect ratios accordingly.
I almost forgot to mention that yesterday (Thursday) I added some dumb opponents which just move back and forth as well as score labels. The opponents forced me to redo some of the ball+paddle collision code but that seems to work properly now.
Lastly here are two screenshots of the game. The weird textures on the walls are just a little experiment I’m trying out.
The right one shows what the HUD overlay looks like. They are all also draggable so they can be positioned wherever the user wants.
As always check out the development site for the current version or the stable build for the latest working version.
Over the weekend I worked on the physics for when a ball hits the goal, in which case the ball should be removed from the game. The way I did this was by overloading the default impulse collision response in the physics engine. So when a collision occured I would test if the colliding bodies were the ball and a goal, otherwise I would just call the parent with the collision data and let that handle the impulse calculation. At first this all seemed to work perfectly. However yesterday (Monday) I left the game running for a few minutes and noticed that the framerate had dropped to about 4 fps. So I started profiling the game with the chrome dev tools, both memory and CPU.
So after fixing this error it now runs at a steady 60 fps again using ~20MB at any given time. However a strange behavior (I think) still remains:between 2-15 MBs are released every 1-5 second. I think this is inside the physics engine since an issue about this is currently open on the github page of the project so I will leave it for now and keep it in mind if I encounter problems with it in the future.
*I did make a game using the Nebula3 engine, which uses GC, last year but back then I didn’t know a whole lot about memory management in general so I didn’t understand it very well.
After a week of planning and research I have finally had a week of development. Monday was MS1 and we presented our project again in more detail. Tuesday I devoted to testing how the Web Audio API works since I had read that sound can be a problem when making a web game. However the sources of this where people who made games mostly in 2011 and since then the situation has improved. During my testing I didn’t find any major problemswith audio in either Chrome nor Firefox. So when the time comes (week 8 according to my current planning) I think I should be able to make it work.
From Wednesday on I have been working on the engine itself. I begun with a InputManager in which other classes can register callbacks for most keys. Later on I also added mouseevents. A weird thing I found when listening for key events was that there were three events I could listen to: keyDown, keyUp and keyPressed. All of these included a “which” property which represented the key pressed. However the which of keyDown and keyUp for any given key was not the same as the which for keyPressed. After some searching I found out that Chrome and Firefox didn’t implement this function the same way and after some though I realized I didn’t really need it. So I settled for keyDown and keyUp.
Next were the Graphics. Since I had experimented with Three.js the previous week this was fairly straight forward. From previous projects I knew that having good debug features can really save time in the long run which is why I spent half of Thursday making an easy to use free roam camera. In the endof this post is a gif showing the current state of the graphics.
This is rendered with an orthographic camera above the game to see what the physics engine sees
This is the current state of the 3D world with several balls in play. The blue sides are goals for which I haven’t implemented physics yet. (Click the thumbnail to see the animation)
The animations may look like the game is very laggy but this is just the tool I used to make the gifs. On all computers I have tested it runs at a steady 60 FPS. Test it yourself on mwp.viktorhansson.net/git
I have spent most of today testing out the Web audio API to play a simple sound effect. I thought this was an important test since I have read about many other web game developers having problems with playing sound.
The test site loads a short audio clip using an XMLHttpRequest and can play it in a loop or just a one shot. I had some problems getting it to work for both Chrome and Firefox which turned out to be a problem with the sound output on my computer. Chrome chose one automatically whilst Firefox used the one set in the sound settings
Anyway I think it ought to work in both browsers now which is very good news since I can now begin with the development of the game.
The first week has now passed and since it was the week for planning I have not yet developed much.
In the beginning of the week we presented our project proposals to the other student and teachers. For the rest of the week I worked on the Project Plan during the days and experimented with Three.js and Socket.io during the nights. The project plan can be found in the Milestone 1 folder in the side menu and the result of the night work can be found under the menu Test sites (These may not always be accessible since they are hosted on my school computer).
This is a screenshot of the Three.js test site in Iceweasel (Firefox)
To set up and use Three.js was pretty straight forward and did not pose many problems except some with configuring the shadow cast values of a light. These was easy to fix once I found out that one could render the shadow volume pretty easily.
This is a simple chat application which uses Socket.io to send the messages in realtime. It also features an indication when a user is typing.
The project proposal and presentation can also be found in MS1.