Obviously, when considering the time spent at the different modules in this project, it was markedly more difficult to implement the game over a network than anything else. The fact that the networking side took up the largest chunk of time was no accident. Not only did we have to study, learn and understand network code for the first time, we had to take what we had learnt, and apply it to our own game module. This last part, in itself, would prove to be the largest problem we encountered.
Initially, after studying the supplied ipxchat.c source code, we took on the task of rewriting the code, dividing the Transmit/Receive function in an effort to fully understand its workings. It was to be some weeks before we had a program which was resembling in successful actions the original chat program. The next step was to determine what exact communications we required from the client and server, and to go about writing simple code to achieve this, outside the game. It took a further month before we had the desired functionality from this set of programs. The plan now was to insert the relevant functions into the finished game code, and to sit back and watch as the project virtually finished itself. Needless to say, it was a complete disaster. The packets which would go harmlessly (and, admittedly, obliviously) astray in the previous programs now resulted in one frozen test after another. The game was programmed in such a way that one lost packet would mean disaster, so it was vital that all packets sent would be received. It soon became apparent that it was the complex handshaking system in place that was the problem. The packets being lost were not those destined for the client, but rather the confirmation characters that the client was sending back to the server. In other words, the server would freeze in a sending loop, waiting for a packet that had already been sent, whilst the client moved on, up until it began to wait for a packet from the server, one that it would not be receiving.
In the end, it was a simple idea which allowed us to overcome the problem of the lost packets. The theory was thus : if the client was to begin listening for packets before the server sent them, surely it could not fail to receive? So, apart from some simple handshakes at the very beginning of the program, so as to ensure links had been established, each handshake exchange in the game was removed, and replaced with a delay on the part of the sender. Hence, every time a packet was being sent, the intended receiver was already in listening mode. And for the first time since any networking code was introduced to the game, it ran through successfully to its finish.
Another problem we encountered was the inconsistency in graphics when we ran the game on three different machines. There may have been different configurations, or different versions of Turbo C / Borland C compilers. The solution we decided upon was to include the graphics files we knew were compatible with the game with the final package, and to have them installed into a folder which would then be referenced by the executing game, ensuring compliant graphics regardless of the machine it was being run on.
Another problem we faced, and a further deterrent from coding a 6 player game, was the lack of memory space available for us to work with. Turbo C only offers 640k, which was quickly eaten up. By linking the game code with a Borland C memory file, bc3nwres.lib, we were free to continue to a certain point. When we ran out once more, it was time to divide some of the code into header files, even going so far as to compile the intro sequence seperately, and calling it as a system command in the actual game program.