The specialization project was finished Friday 21/03/2014. That week I spent the first two days implementing the highscore list function and finishing the sound effects. I ended up with two different highscore lists, one for the cooperative game-mode and one for the versus game-mode. The difference between them being that in the cooperative list the names are made up by the first seven characters of each players name, instead of just one name per line in the versus highscore list. When a game is finished the highscore is sent by the host to the server keeping them. After it have updated the list (if it was necessary) the updated version is sent back to the host, who will forward it to all the clients.

The problem that I had with the sound effects that wouldn’t play was that I didn’t handle other things that a WAVE file could include like ‘fact’ about the media. After fixing this and actually reading the ‘data’ into the sound effect they played nicely. So I ended up with three different sounds for explosions, one laser sound, a thrusting sound, two sounds for the saucers and two for the background heart beat that’s playing like an background music/effect.

I’ve done loads of small fixes trying to get the game to be more stable, and then I finally set the version to 0.1.0, the first official beta!

Over all the project has gone well. I’ve succeeded with creating my Asteroids game and integrated a network solution with functions that reduces the feel of latency and increases the playability of the game. The game supports up to four players, have sound effects, text and highscore.

The downsides under this project have been that I was behind my schedule the last weeks, even though I somehow managed to fix everything before deadline. I feel that I stated that I would have too much done at the end of the project in my report, and what I stated was pretty specific too. I had pretty hard last weeks when I had to fix the sound effects and highscore, and would gladly have skipped the audio if I could. but I’m glad I didn’t, because I managed to implement it and it really brought the game to life.

Main Menu, first beta

Main Menu, first beta

Browsing servers in the server list

Browsing servers in the server list

Top 10 cooperative highscores.

Top 10 cooperative highscores.

Top 10 versus highscores.

Top 10 versus highscores.

Game Over screen.

Game Over screen.

Masteroids

Masteroids

Share it
  • Twitter
  • Facebook
  • email
  • LinkedIn
  • Tumblr

And so on the second last week, the creator of Masteroids introduced death into his game. He saw that is was good and so he moved on to the next task.

This last week I’ve got a lot of work done. I implemented lives and that players can die, and get a Game Over screen. I implemented the saucers, one big that fires at random and one small that aims at the closest player. I limited the amount of bullets in the air (space) from the same player to 4, which is the same number as in the original Asteroids. Also the time to live on the bullets are much shorter, so you never feel ‘out of ammo’.

I had a huge bug in the game that slowly made my controls for the ship stop working, one after the other as the game was played. It only appeared when I spawned saucers, so I obviously thought that was the origin of the problem, but then I found out that my input manager thought that several buttons were pressed, starting with the first char and going upwards, until it said that I was pressing all the controls at once and the game then crashed. This was very hard to debug, since every single try that I made had to go on for 2-3 matches where I spawned a hell of a lot saucers. It showed up to be a problem with how I had implemented my input manager (I’ve had problems with it before, probably the same source of the problem, but I thought it fixed), the problem was how I stored the boolean array indicating which buttons were being pressed and not and how I used it. I ended up converting to the C++ way, using a vector instead of an array, and passing copies to everywhere instead. This ultimately solved my problem.

I’ve done lots of improvements and bug fixes as well. I fixed so every entity have width and height that they take into account before going over one edge and reappear at the other side of the screen. I tweaked the font a little so that smaller font looks better at original resolution, and started using it through out the game. I’ve implemented so the player(s) get an extra life per each 10.000 points they score. That smaller saucers appear more frequently until a score of 40.000 when only they appear.

I’ve also implemented sound effects, is really brings the game alive. I ended up using OpenAL after lots of effort spent on PortAudio that I just couldn’t get to work. Both of them are cross-platform and I find that important when selecting a library (so is LodePNG and FreeType that I use). I don’t have all the effects in the game yet, but that shouldn’t take long. I got hold of some of the original sfx from Asteroids that I’ll be using, but I’m currently having problems with the saucer sounds, they appear to be to short to play, ending up saying that they have no data on them. VLC can’t play them but Movie Player can.

I’ve started on the highscore synch and will complete it this final week. Same goes with the sound effects. Then there will be bug-fixes and play-test so that I can improve the game overall.

Share it
  • Twitter
  • Facebook
  • email
  • LinkedIn
  • Tumblr

Since last update I’ve been working on menus. They are very simple and can only be interacted with by using the keyboard. They’re build by text and indicators showing what item/option currently is selected. Doing menus in code only, without the use of scripting is very time consuming and I don’t recommend it unless it’s really thought through. My menus aren’t so well made, not that fancy and they are sometimes not so easy to navigate but they will simply have to do. In the lobby I have implemented a simple chat as well. I added functionality that checked available screen resolutions for your monitor(s) and they are selectable in the options menu (of course I added the original 1024×760 Asteroids resolution as well). Settings such as player-name, game-name, last joined IP and port number are saved, because I find it tremendously disturbing if I have to type everything in at every play.

The perhaps bigger thing I’ve been working on is the server-list. When hosting a game, it is now registered on my server. So clients can now browse available hosts and join them, without any annoying IP-lookups and such. The information displayed about the servers are game-name, IP address of the host and the port number the application is running on. Of course direct connection is available as well.

I’ve fixed a lot of bugs that have occurred and improved various aspects of the application. I’m a little after schedule and will have to implement the saucers and extra-lives for the players.

Main menu

Main menu

Credits

Credits

Options

Options

Enter player name

Enter player name

Host settings

Host settings

Join menu

Join menu

Browse servers

Browse servers

Direct connect

Direct connect

Lobby and Chat

Lobby and Chat

Share it
  • Twitter
  • Facebook
  • email
  • LinkedIn
  • Tumblr
Original drawings of the asteroids

Original drawings of the asteroids

It’s been a while since I last posted a update, but I’ve been really busy implementing things for my game. I started with creating the asteroids, I have four different types taken from the original asteroids game, as shown in the drawing to the left. The asteroids are starting a certain distance from the centre of the game plan so players have a safe spawning zone. The asteroids, 4 to 8 of them are started in their largest form. They simply float around on the screen and when destroyed they will spawn 2 smaller asteroids until they already are at their smallest.

Some physics had to be implemented. Even if it’s simple 2D physics they still took quite a while to complete. To start of I had to create a base ‘Entity’ class, holding the graphical content and some possible physics body. I should really have done this earlier but back then I had no need for it. Anyhow I started with axis aligned bounding boxes (AABBs). They are boxes that encapsulate the object and are always aligned with the worlds XYZ-grid. AABB is perfectly fine for the lasers that the players fire, but not so much for the asteroids so I had to implement a radius/sphere collision check as well.

I also implemented score, now when I have something to shoot at. Destroying a large asteroid yields 20 points, a medium 50 points and a small one 100 points. The large saucer will give 200 points and the small one 1000 points. I’ve decided to put the points from killing a player at 400, but this may be altered later. The score can be kept together in the group if playing in coop mode, or split into one for each player in versus mode.

I have lots of things left to do on my game, but I think I will start completing the menus and creating a game-lobby.

AABB & Radius/Shere collision

AABB & Radius/Shere collision

AABB & Radius/Sphere collision

AABB & Radius/Sphere collision

Radius and AABB

Radius and AABB

AABB

AABB

Asteroids in different sizes

Asteroids in different sizes

Asteroids

Asteroids

Share it
  • Twitter
  • Facebook
  • email
  • LinkedIn
  • Tumblr

I added functionality to my program to easily create buffered meshes made from other things than just triangles, because what I really need for this game is lines. So that is what I added, and with the use of that new functionality I were able to create more asteroids-like players and bullets.

The greatest thing I’ve been working with is the ability to render text in my application. I’m using a library called FreeType and with the use of it I’m now able to load ‘.tff’ fonts into my application and use them to render text in my application. It was hard to figure out how I should use it but eventually I succeeded. For now I have to specify which font I want to load in and in what size I want to load it. I have implemented functionality for rendering text with left, center and right alignment. This is great for things like my Title and menu, I made a simple start menu where I can select host or join game, the rest of the menus will follow next week.

I have also been working on switching game states, going from the menu state to the game state. This required allocation and deallocation of resources which gave me graphical glitches and problems. But after some debugging I found out that the way I removed meshes on introduced a possibility of removing the wrong buffers. After fixing that switching states are going smoothly.

I will continue my work on the game, creating the asteroids, maybe start with the physics and render the score and other things I can do with the ability to render text.

Hello world text

Hello world text

Menu

Menu

Masteroids ship

Masteroids ship

Share it
  • Twitter
  • Facebook
  • email
  • LinkedIn
  • Tumblr

This week I’ve made massive progress within the network of my game. I started this week with fully implementing the entity interpolation. What it does is smoothing out everyone else’s movement, this is important since one only get fragments of data which results in very ‘jumpy’ position if not handled correctly. So when I’ve received two or more updates (I have a lerp time on 100ms, updates being received every ~50ms) one can take out positions in between the updates which leads to smooth movement.

The next thing I worked on was client-side prediction. This is for making you feel in control of your own character, actually simulating the actions before he receives validation from the server. This is important because it is annoying to feel that one’s input is slightly off when looking at the time between pressing a button before something actually happens on the screen. So by starting to move the ship before receiving answer from the server this is solved.

The prediction causes a problem though, because it’s just a prediction. So I had to introduce something called correction / movement-correction in order to make sure that the client and server actually were on pretty much the same positions. This is done by every time an update is received from the server the client looks at what input number/sequence the verified update had. By using the correct positioning from the update, he can apply all newer, non-verified input after that to get another, more accurate, predicted position. He saves this position as a target and will move towards it every update. This makes the client’s predicted ship end up on the same track as the one the server is simulating for it.

No pictures on the updates, the game look like it did at the last pictures except the movement is much smoother. The core network is pretty much done and I will hold on extrapolation, because for now I don’t feel like it is needed. So I will focus on the entity system and how to render text for now.

Share it
  • Twitter
  • Facebook
  • email
  • LinkedIn
  • Tumblr

I’ve started working with the interpolation but it’s not yet working, so I will continue working on that this week too.

Last week I lost a couple of days and got behind schedule. I was supposed to implement the entity system and improve in the player ships, but now I have to do that this week instead. This shouldn’t really be a problem squeezing in in this week’s schedule but I know some days will go missing this week as well.

Anyway this week I will continue the work on interpolation. When that’s done I will focus on the player ships, entity system and then start looking into text rendering.

Share it
  • Twitter
  • Facebook
  • email
  • LinkedIn
  • Tumblr

Oh the time synchronization.. Yes I encountered this problem too when I started implementing entity interpolation.

So basically I wanted to interpolate entities between positions but in order to do that I first need a synchronized game time. This is due to the server will set a time stamp on every update snapshot. And in order to determine where between the snapshots the entities should be rendered clients need to have the same game time as the server.

I am synchronizing the clients game time when he connects. I used this article to implement this Clock Synchronization of Client Programs,it works like this:
The client sends a join request packet to the server. The server determines that the game version etc. is the same then it starts sending time synchronization request packets to the client, whom replies with time synchronization replies as fast he receives a request. After 10 of these requests and replies I have some ping time samples. By sorting out some samples that were way off the normal and taking a mean value of the remaining the server can approximate the average ping time for that client. So he then sends a join accepted message containing the clients information including game time and ping delay, working as game time offset.

Now I can finally start working with the interpolation!

Share it
  • Twitter
  • Facebook
  • email
  • LinkedIn
  • Tumblr

Now the week is over and on Monday milestone 2 is due. At this milestone we are to deliver a proof of concept, something that shows that our projects are viable.

Since last post (Tuesday) when I had some working movement I have been working on moving the ‘moving’ part to the server instead of the client. What I had was the client moving his ship, sending the position to the server who them forwarded it to everyone else. This is called client authority since it’s the client that determines where he will move, this allows people to modify the client or its packets in order to cheat. What I want is server authority where the server does all the moving of the players, all the clients does is sending their input. So this is what I’ve implemented, I have the clients generating input about 30 times each second. These inputs are sent to the server about 20 times each second (only the new ones are being sent). The server applies the movement and tells everyone of the position in the next update.

For feeling more in control of your own spaceship I have some client-side prediction, where your ship moves directly at your input without waiting for the server to answer. But because this is only a prediction the movement can go wrong and has to be corrected, we must do that too. So we keep a buffer with previous inputs so when the actual position we got from a certain input is returned, we simply correct our movement at that input, then apply all newer inputs after that which gives us our new predicted position.

This is what I have for milestone 2, a game supporting 4 players over the network, with server authority, some client prediction and movement correction.

Share it
  • Twitter
  • Facebook
  • email
  • LinkedIn
  • Tumblr

Fixing my network problem that I had last week took less time than expected, by doing some more research and changing some code I got it up and running again. And after fixing some other issues (like the client was only able to send one packet each frame) the network base feels pretty solid. I corrected the ping functionality so users could be timed out and implemented a sort of ‘global’ state, enabling my program to always handle general stuff like Ping messages independent of what state the game itself is in (menu, settings or in-game etc.).

Connecting to the server works, so I implemented functionality for server to shut down, clients to disconnect and server to disconnect clients. This makes the network much easier, no crashes when clients disconnects or restarts of the program to try again. Together with the time out functionality of the ping messages, the joining and leaving works seamless.

This week’s work is dedicated to the things I’ve mentioned above and actually getting something visual from the network to the second milestone on Monday. So I implemented some basic functionality for adding spaceships and making them move across the network. I’m using Valve’s article about their Source Multiplayer Networking as a guideline. I’m currently sending about 20 updates per second from each client to the server, and the server sends everyone’s position and rotation twenty times each second. This works for now but it uses client authority, I will have to make it server authority later on or else there’s a possibility for cheating. There is no entity interpolation yet so the other player jumps between their positions, but I think it works as a proof of concept.

So what’s up next? Well I’m thinking about trying to implement a more correct movement method using server authority. Maybe it would be fun to be able to firing some lasers in the concept too, but then I have to create a better entity system and that’s up next week.

Four players connected

Four players connected

Four players moving around

Four players moving around

Share it
  • Twitter
  • Facebook
  • email
  • LinkedIn
  • Tumblr