Things are finally working as they should! Practically all of the known bugs have been eliminated, lobby code now works, and the client connect routine runs much faster than before. We have added lots of new network message types to allow the transmission of different types of objects in the world and their state at any given time. One nice change is that players gracefully disappear from the game when they disconnect. If the server disconnects, the clients will just exit the game. It used to have unpredictable behavior in both cases. From now on out, I can honestly say that the only real changes in networking will be adding/changing network message types to increase functionality. Things seem to be stable and fast now. See the various CVS log entries for detailed bug fix info and more.

Networking continues to work, and some code has been cleaned up. However, there are some unresolved issues right now relating to crashes when the server closes all connections at exit. The lobby front-end that I worked on is all setup to work, but for some reason since I moved the network connection code out into the lobby the game suddenly has strange issues that keep it from working. For now, the lobby project has been put aside to continue work on other features until we can figure out a solution. Overall, the past week has been more unproductive than usual but this next week should be better.

Objects aren't added twice, since the game world has been changed to check for duplicate object ID's upon adding. Overall, the network is much more stable now than ever and multiplayer gameplay has been implemented. Players can join and leave the game at will, and can interact by moving or jumping around. Collision detection works between networked players as well as room boundaries. Room transitions now work flawlessly for the client player(s). One small issue with networking at this point is the startup/setup time. It takes a number of seconds for the server to start and for the client to connect. This may not need fixing, since it's not really a bug, but it can be annoying. We also have yet to implement a way to specify which IP the client connects to via the graphical interface. Right now the IP is hard coded so it requires a recompile to change it. We are thinking of having a windows MessageBox pop up before the game starts where you can enter your player name, choose your player model (loveseat or recliner for now), and setup network info (Client or Server? If client, IP to connect to?)

Choppiness (sp?) during network play is mostly eliminated. We added a delay (~25ms) between calls to UpdateWorld() so that the server keeps updating a fairly constant rate. Player text messaging is setup as far as the networking framework is concerned, but we still need to make a graphical text input function so people can actually write unique messages. This will be done soon.

One note about the last entry -- the server and client only share the same world for the game that is run in "server" mode. This is because a server thread is started, and then a client thread is started to connect to itself (IP 127.0.0.1). They share a world because the world is global and happens to be used by both but they still communicate via the network just like every other client does.

Major update with regard to networking. Cyrus, Daryl, and I spent a while (10+ hours!!) merging the network and graphics code. We decided to change the network model slightly, in the following way: The server now runs the game itself (with graphics output, user input, etc.). Before, we were planning on having a server thread that runs in the background and you'd have to instantiate a client object on that same PC in order to play the game. This new model adds a slight bit of trickiness to coding, but not much. Just be careful when dealing with input because the client and host games treat input differently. On the client side, the game translates the input into actions, sends the actions to the server and receives asynchronous responses back from the server informing the client how to update its copy of the world. On the server side, the game translates the input into actions, operates directly on its world object to modify objects (since it keeps the master copy) and then broadcasts update object messages out to all clients to inform them of the changes. Not too complicated, but a small oversight could easily make it complicated :).

Another change is that the server has the task of constantly broadcasting updates out to all of the connected clients. This is different than what we had thought about before because the updates are sent out continuously rather than responding to individual messages. This is necessary because the game physics make objects move even without any user input (an easy example of this is projectiles). The "hover bobbing up and down" effect is another example.

There is currently an issue with choppiness (sp?) on the client side, and we suspect it has to do with the server message send rate. It may be receiving messages at different rates throughout time which might cause updates to occur with imprecise timing. We may have to regulate the rate of messages or something, but this is just a guess for right now. There's also an issue where the server version of the game has a horribly slow left/right turning rate (graphically), and the client has a hyper-sensitive super-fast turning rate.

Networking code is coming along well.

I have implemented the basic client and server objects, CSpudClient and CSpudServer. In addition, I have created a class called CSpudWorld that contains all objects in the game. The client and server classes both contain a pointer to an instance of this world class which allows them to manipulate the world based on the messages sent/received via the network. There is currently a front-end to these classes called SpudNetworkConsoleTest, which is basically a console application that can run as either a client or a server and will show the ability to perform standard client/server actions (host a game, connect to a game, send messages, server tells client to create or modify an object in the world, etc.). I have streamlined this code so it should be easy for others to understand.

Here's a recap of what we discussed in our meeting with regard to networks:
The server and client are implemented as objects. One of the machines will act as a host, and it will do so by instantiating a server object, starting the server, then instantiating a client object and connecting to itself. All other clients will simply connect to this server via the host's IP address. The client-side will be doing the graphics output and when user input is received, sending the actions corresponding to this input over the network to the server. The server will receive this, update the world (it maintains the master copy), then send out messages to the clients to inform them of moved/modified/created/deleted objects in the world. The clients will then modify their local copy of the world so that the graphics routines will display the correct world during its next redraw cycle. More to come.