banner map

The first, and probably the largest alternative approach to the project, would be to code the majority of the game in Visual Basic, as opposed to C. At the beginning, having only spent a couple of weeks programming in the VB environment, we did not feel confident enough to undertake such a task, opting instead for C, a language that we already had a good deal of experience with. Now, after almost two semesters of studying VB, and also how to interface with C via dynamic link libraries, we would be confident in our ability to develop the project in a Windows based environment. This is not merely an observation based on the graphical advantages upon inspection, it was found that the code used in VB to allow machines on a network to communicate is decidedly easier to follow than the IPX code we used in C.

Another improvement would be to allow the server program the option of deciding how many other players to include. Originally, the specifications were for a game of 3-6 players across a network, but time, and indeed code size restrictions limited us to getting a 3 player game running succesfully. In thoery, if the game works for 3, it is only a matter of copying the code, and making some small internal tweaks to allow more players to join. The option could then be included in the server's game menu, and he / she will decide how many players are to be included, allowing the program to forge the necessary communication links.

One improvement that could be made to the existing C program code (and would have to be made if more players were added) is as follows. A function entitled SetupForSend is called at the beginning, its function being to set up the sending computer, allowing it to transmit the data it wishes succesfully. This function takes the connection number of the intended destination, and prepares the data packet for transmission. In the server code, there are two separate functions, SetupForSend1 and SetupForSend2, used to prepare for transmission to Player 2 and Player 3 respectively. Each function must be called before each packet is transmitted, hence ensuring that each packet is sent to its proper destination. An alternative approach to this would be to declare a global structure, and in it store the relevant information which the SetupForSend computes. Therefore, each time a new packet is to be sent to both players, the program will simply have to reference the data structure before sending, as opposed to having to run through the SetupForSend functions each time. Again, it was the fact that we were held back for so long by the networking code which prevented us from implementing this improvement.

Another possible improvement to be considered would involve removing the game questions from the program code entirely, placing them in a database which could be referenced as the game ran. This was only a late suggestion, brought about by the fact that the Turbo C compiler was complaining about a lack of memory space to compile a full (stand alone) game with graphics. Compiling in Borland C over-rode this particular qualm, but the idea of a question database could be a viable one.