A Network Protocol for Movement (Part 1)

Posted on January 17, 2008 by Chris at 8:03 am

Introduction

This is a first-draft attempt at making a network protocol that will allow the effective communication of a mobile unit (mob) in a 3D world. This kind of protocol is no doubt required to make any network game that requires movement movement in 3d space, which is most network games these days. It can be easily adapted to be a 2d protocol by ignoring z coordinates.

I’ve decided to go with the TCP for this protocol, as the packets automatically show up in the order that they were sent. While UDP would probably be a better option considering it won’t wait for lost packets to come through, we would need to add more controls to ensure that we were working with the latest information. UDP packets can turn up at any time or not at all, and while we could handle the not at all, packets that turn up out of order could send a mob back to a previous location which would not be beneficial.

I’m planning on having two more parts to this in the future.

  • Part 2 - Will cover the creation of the server application
  • Part 3 - Will cover the creation of a sample client application

The Protocol

  • Each message will start with a single byte that indicates what type of message is being recieved
  • The Vec3 datatype will contain three Double values indicating the x,y,z coordinates
  • If you know much about 3D maths, the UpVector and RightVector should make sense. These values indicate precicely which way the mob is facing.
  • For this protocol to work properly in implementation we will probably need to turn off the Nagle algorithm using TCP_NODELAY
  •  

The table below shows the structure of the messages that we will be handling in the protocol. I may need to make changes to this structure in the future, if a required function is not covered.

Byte - Message Type 01 - LOC_Connect Int32 4 bytes SessionID 02 - LOC_AcceptConnection Int32 4 bytes MobID 03 - LOC_GetMobLocation Int32 4 bytes MobID 04 - LOC_MobLocation Int32 4 bytes MobID Vec3 196 bytes Location Vec3 196 bytes UpVector Vec3 196 bytes RightVector Double 64 bytes Velocity 05 - LOC_UpdateMobLocation Int32 4 bytes MobID Vec3 196 bytes Location Vec3 196 bytes UpVector Vec3 196 bytes RightVector Double 64 bytes VelocityWhat the sever will do

  • Accept a LOC_Connect message from a new client
  • Send a LOC_AcceptConnection message with the unique MobID new player
  • While the connection is still active, accept LOC_UpdateMobLocation messages, and store the most recent detials for each Mob
  • For each LOC_UpdateMobLocation message recieved, send an equivalant LOC_MobLocation message to each connected client

What the client will do

  • Send a LOC_Connect message to the server
  • Wait for a LOC_AcceptConnection message, and store the MobID value for future use
  • Periodically send a LOC_UpdateMobLocation message to the server, indicating the current location of the client’s unit
  • Accept LOC_UpdateMobLocation messages, keeping and displaying the locations of each MobID.

Notes

  • The current location of each mob, along with the speed that they are moving is controlled by the client. Additional controls could be added later to ensure that the client is using allowable values in it’s location messages, and rejecting or modifying the values as required.
  • The SessionID value passed in the LOC_Connect message can be used to integrate with other services. For example, a login server may accept authentication information, then pass a unique session id indication authentication was successful.
  • Using the location, vectors, and velocity values a simple dead reconing system can be implemented.

Data Binding in Windows Forms

Posted on January 10, 2008 by Chris at 12:37 pm

Was playing with an old application that I wrote for work and realised that I’ve completely forgotten about how data bindings work with Windows Forms applicatios. So, I thought I’d add a blog entry about it, so that I can refer back to my various pearls later.

Data binding is a nifty method of making your controls talk directly to your data. While there are other methods that may be faster, data binding is very useful for getting things up and running quickly.

All System.Windows.Forms.Control objects come with their own DataBindings member. This is the thing that allows the magic to happen.

Suppose that you had a DataTable that you were storing all of you application’s data in, and this table contained the columns customer_id, customer_name, customer_address, customer_type and so on.

To set up a databinding to these items you would use code similar to below.

   // m_CustomerName is a TextBox added using the form designer
   // m_DataRow is the record that you are currently editing
   m_CustomerName.DataBindings.Add("Text", m_DataRow, "customer_name");

Viola, now whenever you make a change in the text box, your record will be updated as well, and as easy as adding a single line of code to your initialization function. As an added bonus, your textbox will have it’s value set to whatever is in the field when you bind it as well.

Suppose that you have a specific type that you would prefer to fill out, like the one below.

   public class Customer
   {
      public int CustomerID {get; set;}
      public String CustomerName {get; set;}
      public String CustomerAddress {get; set;}
      public int CustomerType {get; set;}
    }

The code for doing this would be exactly the same, with the property name passed as the paramater.

   m_CustomerName.DataBindings.Add("Text", m_CustomerStruct, "CustomerName");