Our intention was to code a fully working, networked game, to the specifications we proposed, to operate through to its conclusion without failure. In this regard, the project was a reasonable success; as we near the end of the allocated time, the game, complete with additional graphical intro and outro sequences, is functioning, with only minor glitches left to be tackled.
The original specifications allowed for 3-6 players to engage in the same game, at the same time. However, the final submitted project only allows 3 players on the one round. The reason for this change in plan is very simple : the game map that we designed to keep track of moves was coded originally with 3 players in mind, assuming that it would be simply a case of adding in the extra players when required. However, it soon became apparent that any more than 3 players on the map screen gave the graphics an ungainly, cluttered look. Adding in extra players now would involve redrawing the game map, perhaps to higher specs, but by this stage, our project time was entirely taken up as we attempted to get to grips with network coding. Once we had one client (Player) working with the server (i.e. 2 players), it was merely a matter of copying, pasting and making minor adjustments to the code to upgrade to a 3 Player game. So, in theory, it would simply involve similar actions to upgrade the game to 4, 5, or 6 players. One more critical problem was the fact that our original game engine was designed using turbo C which only allows up to 640K of ram to be used. Once the mathematical work involved in the game engine , the questions and the graphics were implemented into a stand alone game we had exhausted all available memory , this fact seriously impeded our efforts to achieve a fully operational application allowing the user to run with between 3 & 6 players.
One of the minor glitches mentioned above is as follows. Once we removed the original complex handshaking system from our code, there was no longer any way to ensure that each and every vital packet sent was received at its intended destination. The delay system that was implemented was a huge improvement, but was not without its faults. Even though the delay periods allocated should have allowed each packet the necessary window to be received, the concept of lost packets on a network came into play, with a packet occasionally getting lost in the traffic. To overcome this, we arranged the code in such a way that each packet was sent twice, with a further delay between, to compensate for the slight possibility of the first packet being lost. This was a further improvement, to the extent that now the game ran through fully to its completion almost every time we tested it. However, there still was that tiny random possibility that a packet would get lost in the network, which more often that not would freeze the game. In essence, the game is not 100% completed – there is a tiny scope for error. Given more time, it is possible that the delay mechanisms could be redesigned to offer complete functionality.
Assess Eurovision Pursuit yourself.....
Download the StandAlone version (one PC, no network required) of Eurovision Pursuit, here