Finally I got to the main implementation and use of the VFC model for the NetRumble game.

In order to keep the class as simple and separated from the specific game (Net Rumble) as possible, I used interfaces which must be implemented by the game objects that are intended to be pivots. I'm already using it on the asteroids and the player's ships.

It's working just as expected for the asteroids and the ships movement. From the first tests I did it's clearly observable the difference in the movement of asteroids and, specially, ships. Using the scale parameter to choose the area shown in each player it's possible to see the enemy ships further away and analyze their behavior depending on the consistency zone in which they are. The jumps in the positions of the ships are very frequent in the outer areas and their movement is smooth in the inner areas, where consistency requirements are tighter. The tightest area of the game should include all or most of the player's original view of the game.

There's still one issue I have to deal with in order for the game to run correctly. At this moment I'm using the ship pivot for the input and for the position. The player input includes the movement and the firing of projectiles. I need to change the way the firing is handled and create a new message type for projectiles. Then, the projectile would become a pivot and would be sent to all players accordingly.

Soon I'll try to post a video feed of the gameplay for you to observe the given behavior. I'll also now start making some tests to check how much bandwidth is used with and without the use of VFC and collect other useful information about the communication.

Well, as I said in my last post I made a new custom PacketWriter class. It's working fine and compatible with the PacketReader on the other side, by instinct since the order in which each member is written/read from the packets is not specified. It only requires one more step before beginning each packet to Reset the packet, but becomes much more flexible in terms of reuse of the same packet to send to a group of peers.

I've also done some refactoring of the code more specific to the VFC implementation: drawing of the consistency areas identification, custom packet writer, and so on. It is now packed in a different namespace.

Since I allowed the players to join the game in progress there were a couple bugs in the state of the current game when a player joined, in particular:

• he wouldn't see a power up had already been spawned - the host now checks for a power up when the player join and sends it's spawn message;
• wouldn't know about the current weapon of each of the other players (if they had caught a power up earlier) - the periodic status packet for each player now includes the current weapon he has.

Some other bug related to the change to the client-server architecture was the acceleration of the other players comparing to the host. The other players would be slower. To pass this around it is only needed to use the same direction input while another packet with new input is not received by the host. It works like a charm.