Archives

All posts for the month February, 2014

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

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.

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.

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!

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.

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