Network

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

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

So the rest of this week I’ve spent on trying to Implement a basic network structure. The network uses UDP and I find it kind of tricky to get up and running. I could send data back and fourth for a while and it worked really well, however the client broke down after a while and said that it had a bad address to the host. So I’m currently working on rewriting that at the moment, not very much to show. I have however implemented a Ping sequence, assuring that no one stays quiet for to long, and it will only start pinging in the absence of packets. I’ve also made a sort of handshake protocol when a client connects to a server where they exchange information,

I will continue the work on network next week, trying to fix so that the client can retain the host’s address and keep sending data. Then I will make sure that the basic sending and receiving data works flawless and that users can successfully connect and disconnect. I will also try to use the network to show something visually next week.

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