I’ve fixed the rejoin issue I discovered last week by making a custom connection negotiation system that doesn’t rely on messages sent reliably and that’s handled at a lower application level than I used  previously.

I noticed that player health values weren’t synchronized when clients had packet loss so I added an option to choose if an objects attribute should be sent as a reliable message when it has changed.

I also worked on the project postmortem and milstone 3 presentation.



I got projectile collisions to “work” using the previously mentioned “less-than-elegant” solution. It involves fetching all physics entities within a certain radius and if they belong to a player entity, that entites health attribute is then lowered by a certain amount. Only the server/host checks for projectile collisions and as soon as one occurs the involved projectile is removed from the game.

I’ve worked on a text-based user interface for all states. In the main menu state it shows which keys you need to push to choose if you’re going to host or join a game and it is used to allow you to type the ip of the server you want to join. It’s not particularly user-friendly but makes it easier for me to test things.

In the battle state is shows the players that are in the game and their health. The health values that are shown are taken directly from the player entities that are synchronized using my object views and distributed object system.

I also added a game over state that all players enter when there’s only one player left alive. At the moment it only shows “Game Over” and tells you to press escape to return to the main menu.

While testing the game I noticed that the client was unable to rejoin the server if it crashed or was restarted. When the client restarts it’s packet sequence numbers are reset while the servers aren’t. This causes the server to ignore messages sent by the client since the client sends packets with sequence numbers that have already been received by the server. I’ve started working on fixing this issue.



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.



The primary objectives of this project are:

1. To make a UDP-based multiplayer framework. It should be able to send network messages both reliably and unreliably.

2. To make an entity state synchronization system where changes made to an entity (such as a change in position) are automatically communicated to other players.

I’m currently working on low-level UDP network communication using Winsock.