Weekly

So this post is is a few days late but that is mostly because I don’t have that much to say this week either. Most of the week I have been working on the final written report which can now be found in MS3. I have also done some setup and cleanup on the server running the game so if it crashes it is restarted. Then I did the presentation and the post-mortem which are also in MS3. Then on friday we had the presentation where everything went well and after which we voted on who should present their projects on the Gradshow on March 28:th. I was chosen as one of the two programmers, which is exiting and somewhat scary.

Next week I don’t think I will do any programming, only improve the presentation and prepare for the next course.

I have been quite busy with other things than this project this week so I have not gotten much work done, except putting the finishing touches on the game like an audiomanager which plays music as well as several different sound effects as well as some settings for the music and fx volumes. Other than that I have mainly fixed all the major bugs that showed themselfs during playtesting. So next week I will just work on the report and fixing the final bugs like AI getting stuck in one end after a powerup has run out.

Like I stated in last weeks blog post I moved the AI to this week so I spent Monday and Tuesday on that and then during Wednesday and Thursday I implemented the powerup/down and today I have made the gameover work when the time is up. For more info on the AI read the post “Dumb AI“.

For the powerup(s) I though that I had only planned on making a ‘faster ball’ powerup but when I checked the project plan I saw that I should instead make two variants, one to make the paddle wider and on to make it smaller. So the way this works is that a powerup will spawn in a random position on the playing field. If it is the wide-paddle one the player who ‘directs’ the ball to it will receive the award and if it is a small-paddle the next player to deflect the ball will receive it. When a powerup has been taken another one will spawn in the next 10-20 seconds.

I also change the walls of the playing field to be angled since I noticed that the ball would often get stuck bouncing between two walls.

And finally today I added a game clock to the server which starts when the first player joins and counts down from 5 minutes. When the time has run out a gameover message is sent to all clients and they all disconnect and the game gets deleted from the server. When a client receives the gameover message a sorted scoreboard is displayed with an option to return to the main menu.

The following video shows the angled walls, the new ai and the powerups

 

 

I decided to change the planning a little once again and push the AI work to next week and deal with GUI and the game-session this week. So I have spent most of it on making a pretty GUI and in the process I had to refine much of the code regarding all the managers and game-session. The code I had when posting the GUI post was completely rewritten yesterday to be more modular and simpler to extend and change. But it looks almost exactly the same. Except I added a working fullscreen button to the options menu :).

When I worked on being able to join and leave I ran in to some problems with resources, both socket.io and three.js, not being garbage collected for various reasons which I hope are all resolved now. I have come to the conclusion that spending more time learning the ins and outs of JavaScript would have been time well spent, since the garbage collected environment is quite difficult to work with when you’ve mostly worked in a manually memory managed language like C++. Another problem I have noticed is that most literature covering the subject is written by web-developers who often don’t take memory management into consideration, although the makers of the JavaScript game engine Construct 2 have posted some very good blog post on how to deal with some of the innate problems with using JavaScript in a real-time context.

This week I have been doing mainly two things. The first one is network-related and the second one is graphics so I have a fancy new screenshot.

During the first half of the week I implemented entity interpolation which is an essential feature in all network games. More details on how I did this can be found in the post “Smoothing Stuff“. It is not perfect but works well enough that I can continue working on other features. Perhaps I will have to work on it a bit more towards the end when I can playtest for real.

The other half I have been doing some cosmetic work combined with some game-logic things. The first plan was to have a screen/display, similar to ones in sports arenas, where I would render the game with different cinematic cameras. So I implemented this but then I started thinking of how the score and name of the players should be (the previous solution seen in earlier screenshots did not look good and was difficult to setup and update) when I stumbled upon this image, depicting the arena in Tron Legacy and that has been the main inspiration for the current version. Unfortunately using this scoreboard I could not keep the “jumbotron” so I decided to scrap that.

Jumbotrone

My Jumbotrone

My Jumbotrone

Tron

When I had the cylinder with textured names and score the next thing I wanted was the light seen in the Tron image. I have not worked that much with shaders before (just implemented phong shading and shadow maps) but after some research I found out that it can be done using volumetric light approximation. And the only resource I found on this topic was a tutorial on how to implement it in javascript with Three.js. The tutorial was a bit outdated (2 years old) and was no longer working but with some modification both to use newer version of Three.js and some modification for my game I got it working. I will write a more detailed post on the VLA later with screenshots.

I then got an idea from a friend that I could use the VLA to create an effect where the ball would look like a hologram projected by something in the middle of the scoreboard. While I think that could be perfect for the environment of the game I can’t figure out a way to do it which would look as good as I want it to so I put that on the backburner for now. Instead I decided to make the entire scoreboard glow. I recon this adds a lot the visuals.

Selection_033

I apologize for the terrible image placement in this post but the wordpress editor is abysmal when it comes to working with images.
Also I finally updated the stable site so now that should work. The server application might crash in which case the game will not work but if you really want to test it you can just send me a message or leave a comment and I will fix it. You can find my mail on my website viktorhansson.net.

Another week has passed and its time for a blog post! As planned this has been a week of networking with a lot of frustrations. But more on that towards the end. First a little roundup of what I have been doing.

Monday was milestone 2 so that entire day was spent preparing and doing that presentation. Tuesday and Wednesday was spent getting socket.io working, read more about this in the post Networking where I explain some implementation details. And lastly Thursday and Friday has been devoted to making the player movement work.

So have I encountered any problems? Short answer: YES. First off I required more time than planned on porting the client code to work on the server. But the biggest problem came forth when trying to make the player paddle move smoothly while maintaining server authority and not clogging up the network by sending the position each frame. After a lot of testing the solution I went with was a similar solution that is explained in Fast Paced Multiplayer by Gabriel Gambetta. I allocate an array with some 10 vectors when the player is created This buffer is then used to store the position each frame. When a message is received with a new position (about every 100-150 ms) the buffer is checked to determine if the position sent from the server is one that the player has visited in which case no correction is required. Otherwise the position is corrected and in both cases the pointer to the buffer is reset to 0. This works quite well but might need some modification since the last position calculated and received before the paddle stops are not exactly the same due to network latency when sending the keyup message.

For now the other connected players have no inter/extrapolation so they only move when the server sends the new position. Fixing this is what I’m planning on doing next week. And per tradition here are some screenshots.

MWP Arena - Google Chrome_020MWP Arena - Google Chrome_019

Its difficult to illustrate multiplayer in just images but an indication visible in the above images is that they don’t see the same planet in the background since they are on opposite sides of the playing field.
I plan on updating the stable site this weekend but first I have to install node and all the plugins used.

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.
MWP Arena - Google Chrome_020MWP Arena - Google Chrome_019
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.

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.

Then I decided to attack the physics part of the game. I had previously decided to use the engine PhysicsJS which is a lightweight 2d javascript physics engine.Since the game is in 3D using a 2D physics engine might seem a little strange. But this is due to the fact that the ball and the paddles in the game will all exist on a plane making the use of a 3D engine unnecessary. Also I didn’t find any (relatively) bug free 3D engines in javascript with good documentation.Like with the graphics part I decided to add some debugging functionality to the physics. This was implemented in such a way that I can toggle some 2D planes andcircles which represents what the physics engine sees above my 3D objects.

This is rendered with an orthographic camera above the game to see what the physics engine sees

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)

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

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).

Three.js testing - Iceweasel_003

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.

 

 

 

 

 

 

Socket.io testing - Google Chrome_005

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.

Socket.io was a little bit harder to get up and running since it required Node.js and all guides and tutorials assumed that you used Node to both host the files on the server and do the websocket communication. I on the other hand wanted to serve the files using Apache and just handle the sockets with Node. By installing the node plugin socket.io-client I found the required javascript file that the client needed.

 

 

 

The project proposal and presentation can also be found in MS1.