This week I’ve been working with Nebula 3 to create a  simple  game that uses my entity state synchronization system. It consists of two main states, a menu state and a battle state. The menu state is used to host a game and allow a client to join the game. When the host starts the game it creates player entities which in turn are automatically created on the client.

When the battle state begins, the host and client are each assigned one entity that they can control. As they move around, that entities position is automatically sent to the other player.

I’ve also added the ability for the entities to shoot projectiles. The plan is that when a player entity is hit by a projectile it’s health attribute is lowered and if it’s reduced to zero it’s considered ‘dead’ and cannot be controlled. The last entity standing wins the game.

My current problem is that  I haven’t been able to get the projectiles to collide with anything when using physics. If i can’t get it to work somehow I’ll have to use a considerably less elegant solution.



I’m currently working on a system to synchronize Nebula 3 game entities via the network.  I’ve made a component that allows you to register attributes of an entity that you want to be distributed. When the game server creates an entity an ObjectView, which keeps track of the attributes, is automatically created and registered with a DistributedObjectServer.

The DistributedObjectServer regularly goes through all registered ObjectViews and ask if any of their attributes have been changed. Any changed attributes are packed into a message along with the ObjectViews ID and sent to all clients.

The clients are then supposed to relay themessage to their version of the ObjectView which interprets it and updates the attributes, but this hasn’t been properly tested yet.

What I’m going to do next is create a game server/client to test the system.



A simple test program that I made for milstone 2 is available from the “milstone 2” link. It has a textbased interface that lets you test sending message between a NorgnaClient and a NorgnaServer. It has an option for simulating packet loss to help demonstrate the difference between sending reliable and unreliable messgages. The program starts both a server and client and they listen to different ports so it’s possible to test it locally. The input handling is very limited and the messages you type in can cannot contain any spaces and you have to type either true or false after the message to indicate if you want it to be sent reliably or unreliably.

Example of sending a reliable message: send hello true

Example of sending an unreliable message: send hello false



I’ve made a simple server and client. The server allows a specific amount of clients to connect to it and will only accept messages from those clients. It regularly sends heartbeat messages to the clients and if a certain amount of time has passed since they responded to one of those messages, it’s assumed that the connection has been severed for some reason and that client is removed from the server.



Wrapper classes for Winsock UDP sockets have been made and UDP packets have been successfully sent and received.

I’ve also managed to send packets reliably. Each time a reliable packet is sent it is stored and if the receiver doesn’t confirm that they’ve received the packet within a certain amount of time it is sent again. To test this I had the receiver randomly discard 95% of the packets to simulate packet loss but I still received the packets in the end.  If no confirmation has been received after the packet has been resent 10 times the application will stop resending them.

What I’m going to do now is make a system for notifying a higher application layer that a reliable packet wasn’t received so that it can handle this in an appropriate way. When that’s done I’m going to start working on a server and client.