In the last days I’ve been changing the game architecture in order for all requests to pass through the server. For a matter of simplicity I haven’t added any security related checks in the messages sent by the players (for now…), but all update messages coming from a source other than the server are ignored.
This change hasn’t been very easy because there were a lot of mixed messaging types and the identification of the player to which the data received belonged to relied only on the sender of the message. So, I had to add a way to identify the player to which an update message corresponds since all data received now comes from the server.
There is still some polishing to do in order for the game to run smoothly for all players. For now the host of the game is the only player able have a good gameplay experience.
Hope to post here some more news, hopefully of the completion, about this task during this week.
After giving it a lot of thought about the way the communication is done in NetRumble I’ve decided to make a big change to it’s architecture. The way the different objects are handled in Net Rumble is kind of an hybrid architecture between Client-Server and Peer-to-Peer in the way that each player is responsible for analyzing and sending the message about each other ships. From the beginning, before fully analyzing Net Rumble code, I had planned to first implement VFC using Client-Server architecture and then if I had time experiment using some peer-to-peer modules.
So, for now I’ll be changing the architecture to a fully centralized server one.
In VFC there is the concept of pivot, which is an element that has a virtual relative location to other elements of the game. The main elements that I will need to map with VFC in NetRumble are
For the player’s ships, currently, each player is responsible for it’s own ship: local player is the authority on the death of their own ship and for sending the updates to all other players.
Since ships can move along through different consistency zones I’m thinking about having the host be a central authority and notify when players change relative zones. This is probably only needed when the players are moving closer to each other since that’s when we have to tighten the consistency requirements. So, in practice, the Host player will always be in the tightest zone of all other players so it can judge effectively where other players are.
The asteroids are controlled at the Host player who updates it’s state and sends the information to all clients.
This should be the easiest pivot I’ll have to implement since it’s already centralized and all the calculus will be done at the host. I believe this is a good starting point to implement VFC in this game.
Projectiles and other input
The way the input is handled is this game might be a bit of an obstacle to the implementation of the VFC model. The input is interpreted by every participant in the game the same way, and expected to result in the same output. However, this might not be true due to latency fluctuation, lost packets, and so on. This is usually a nice approach when we are applying it to an RTS (Real-time Strategy) game because these have a tolerance for higher latency. Since NetRumble has more affinity with FPS-style (First-person shooter) I believe this problem should be solved differently.
My idea, in order to improve this too optimistic behavior, is to tag the projectiles with a game time (elapsed time), position, direction and speed (these two can be combined in speed_x and speed_y) and send it out to other players (according to VFC consistency requirements defined). Then, each player will calculate the actual position of the projectile when he receives that kind of packet depending on the speed of the projectile and direction.