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

• Player ships
• Asteroids
• Projectiles and other input?

Player Ships

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.

Asteroids

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.

Here are some screen shots of the game with the original view port and the current one (scaled to half the size).

<p>Original game play view </p>    <p><a href="//lh5.ggpht.com/_6Gs1Q7vPPW0/SblymBz_Q3I/AAAAAAAAA1U/v5ZNV8GDBBw/s1600-h/NetRumble-original%5B4%5D.jpg"><img title="NetRumble-original" alt="NetRumble-original" src="//lh5.ggpht.com/_6Gs1Q7vPPW0/SblymvUJV2I/AAAAAAAAA1Y/II60gBoTqYM/NetRumble-original_thumb%5B2%5D.jpg?imgmax=800" border="0" width="244" height="196"></a> </p>    <p>Zoomed out and circles added (draft)

<div>Technorati Tags: <a href="//technorati.com/tags/Screenshots" rel="tag">Screenshots</a>,<a href="//technorati.com/tags/Game+play" rel="tag">Game play</a>,<a href="//technorati.com/tags/sprite+batch" rel="tag">sprite batch</a></div> </span>

List of fixed bugs in NetRumble Starter Kit:

• The game couldn't find network sessions. This bug is already fixed in the latest version available from the XNA Creators Club online.
  File: MainMenuScreen.cs
  Method: FindSession

- searchResultsScreen = new SearchResultsScreen(NetworkSessionType.PlayerMatch); 
+ searchResultsScreen = new SearchResultsScreen(sessionType);

• Projectiles could pass the barriers
  
  File: CollisionMath.cs

  Method: CircleRectangleCollide

- if((distance > 0) && (distance < radius)) 
+ if((distance >= 0) && (distance < radius))

New features added:

• Full screen view - hard-coded for now, will add as an option in menus;
• Configured to use current windows resolution;
• Scaled the game world so it's possible to view a larger portion of the arena;
• Circles with different radius and colors around the player's ship (for now these are mere drafts but will correspond to the consistency areas)

In this blog I'll be posting the work I'll be doing for my masters dissertation in Computer Science and Engineering which I'll be doing at INESC-id and Instituto Superior Técnico in Lisbon.

The main goal of this project is to adapt and implement Vector-Field Consistency model in the communication used in a multi-player game.

I'll be using a XNA starter kit game: NetRumble, a two-dimensional shooter where, originally, up to sixteen players compete online in a death match arena filled with asteroids and power-ups.