For the networking module, basic client/server communication is completed. Both client and server side module has InitNetwork(), Send(), Receive() function. These function will be used by the network module inside the world manager to perform more advanced opreration such as adding user to a game, initialize game state, etc.
- Jeffrey 4/17

Client/Server model was revised to have smart clients. Another words, the clients will have their own representation of the environment, and the server will have the master environment. In this configuration, the clients will be able to execute events on their own, and the server will play the role of arbitrary and sanity checker for the clients.
- Kamil 4/17

All goals were met on the networking front. We started with simple client/server example application that incorporated a GUI front end. From this application we generalized to create another application that has the ability to send any datatype (ie. a user-defined class) between the client and server. From a client initiated action input is taken from the GUI and sent to the server which then directs the message to all the clients besides the original sender. That message is then displayed to the screen of the client. Essentially, this is a prototype for the text messaging we intend to integrate into our game. In the future, we intend to use this same model to build our final NetworkManager. To do this, we have to generalize the code some more, specifically separate the GUI from the domain logic. Also, the code has to be modified to conform to the agreed upon interface.
- Tilman 4/17

This week's work started with stripping the GUI codes out of the sample client application to make the networking module a stand-alone class. Basically, the information needed will be passed in from a driver class rather than accessing a GUI item. It turned out that stripping codes is rather the easy part. Instead, most of the time spend on making the whole things compiled, linked and run. Most of errors are not due to C++ syntax but rather due to project settings. For instance, we couldn't initialize COM at all even after all necessary files are included. After tried so many ways to overcome it, the solution turned out to be that we need to define the runtime system to be NT 4 above otherwise the Visual C++ compiler ignore all references to all COM functions. Thanks to Kamil for figuring that out. After solving all these errors, more efforts will be spend on handling DirectPlay messages. We will test the client class with the existing simple server program. Once the client side is done, we will move on to the server side.
- Jeffrey 4/25

Networking did not live up to the schedule this week. We did not manage to extract the relevant portions of the SimpleClientServer example as we had planned. The code was tightly integrated into the GUI and was coded specifically for the example application and not with modularity in mind. Hence, our attempts to derive an independent network manager were thwarted by global variables, specific user-defined types and GUI routines. Our efforts yielded a NetworkClient, separate from the GUI, however not yet fully functional. The slow pace of progress was not only due to the unexpected complexity of the problem but also to poor management and planning. We waited too long and had too little manpower dedicated to this all-important aspect of IO. In response to this a quick search on the net yielded a set of networking classes that might prove useful for our purposes. While having more limited functionality (the code is based directly on sockets, not DirectPlay) it is significantly more simple, understandable and already implemented as a module. We are currently assessing the cost/benefit trade-off if we were to adopt the new code and cease development of the old code.
- Tilman,Kamil 4/25

Networking is moving nicely this week. Both the server and client is done and the client is being intergrated with the event manager. We also fix some memory leak problem. The task remains is to pass event over the network. There is a function call sendMessage(Event e) to send events. Since sending over entire class is very inefficient use of bandwidth. We need to pack the essential information into strings and unpack them when they are received. Therefore, we need to add pack and unpack functions to Object, Event and all subclasses. We also modified our network model slightly. The server now serve as a broadcasting station and user management tool. And, it will start up a client app as the master client app and use this master client as the blue-print to sync other client apps, as opposed to having having a client app as a intergal part of the server app. This reduces the complexity of the project. The entire networking module should be completed with the next few days.
- Jeffrey 5/1

This week my goal was to get Networking up.
We switched from using DirectX to using a socket-based package called NDK. This code base proved to be much easier to understand and hence we were able to get a simple server and client running in a few days. We added the ability for clients to connect/ disconnect from the server and for the server to keep track of its connected clients. On unexpected disconnects the server still recognizes the missing client and frees the proper memory. We added the ability to send text messages for chatting and enabled the client and the server to ping each other.
We also slightly changed our client/server model.
Next week we plan to integrate Networking into our overall world/event model.
I also worked a little bit on overall game design coding some of the necessary utility classes.
- Tilman 5/1

With Craig's and Tilman's help, we got the networking module working and just in time!!!
Now, Synchronization, Content and Game Dynamics are one my mind! :)
- Tilman/Kamil 5/23