Title: Windows Waffle

Author: 

Date: 01 February 1994 08:58:00 +00:00 or Tue, 01 February 1994 08:58:00 +00:00

Summary: 

Body: 

When computers are mentioned in conversation outside of the working environment, the next question asked is invariably "is it a Sega or Nintendo?". The vast majority of non-programmer/professional user seem to think that games consoles are the only form of computers that people own. To a certain extent, I'm sure this is caused by the overwhelming attraction that computer games have to some people. So I ask myself, can this be harnessed to assist programmers learn new skills?

I think it can. Games present a format that is easy to visualise the end-result. There is also a degree of magnetism to the idea of being able to modify the internal workings of a game - as well as the kudos of demonstrating your complete mastery of the game.

To this end, I am going to use a game to demonstrate the life-cycle development of a project using OOA/D and OOP using OMT (Rumbaughs Object Modelling Technique) and C++ respectively.

The game will run under MS-Windows, and three versions (OWL 1.0, OWL 2.0 and MFC 2.0) will be written. The source code will be on disk, only the outline and rationale will be in the magazine. No previous knowledge of Windows programming is required, as a consequence, it may start a little slow for more advanced programmers. I hope they will not ignore these articles as I hope they will participate in providing ideas and improvements to the project. The project is not intended to be a work of art that tries to say "this is the way to do it", far from it, any blind-alleys or methods that don't work well, will be documented. Learning from design and coding mistakes can prove just as useful as those that work, and should provide some chance of avoiding similar mistakes in the future.

A sad confession; at this moment, I do not know exactly what the game will be. I suspect that it will evolve as the design becomes more complete. What I would like to do is to play against real opponents. This will require two (or more) PC's to be connected and for the game information to be passed between them. It seem that to achieve this I will have to write a small communications program. I really am letting myself in for a lot of work, but I do hate computer opponents, so I will have to pay the price.

So what's the game?

After much cogitation the best idea that I have come up with (that is both achievable and instructive) is a game of battleships (not the game with squares and guessing A-4 etc). Further suggestions will be considered, but I need to know soon. I will start by getting the comms classes built first and these will be of use for any multi-player game.

The type of game means that each player will only be informed of what can be seen. This means that reconnaissance will be essential. One of the complexities with a multi-machine game is the co-ordination and synchronisation. To achieve this, one of the PC's will be nominated as the master, and will be responsible for such tasks as map generation and timing controls.

The first of these articles (Issue 5) will concentrate on the design and coding of the low level communications classes, as well as the principles of passing information between all the machines involved. The method for PC-PC communication has to settled on. This must be very flexible as it can then be used as the basis of other games.

PC-PC Communication.

This will be achieved by use of the PC's RS232 ports (serial ports) and will be physically connected by means of null-modem cables (see notes at end). It is intended that the PC's will be directly connected to each other rather than thru modems. (perhaps someone else would like to extend the classes!).

Firstly, the connection of two PC's together conceptually proves no problem, a single cable between the machines will suffice. But how can the system be made flexible to cope with variable numbers of PC's and remain simple. Some of the PC's will need to use both of their serial ports if three or more PC's are to be joined.

The simplest connections are as follows:

Will this work? Physically yes, but it will make for more complicated message handling routines. Messages would have to flow in two directions from the central PC's (B,C,D & E) and only one way from the end PC's (A & F). This situation would be bearable if messages were to be targeted at individual machines and a routing table of how to contact each machine were mapped. I want to avoid this situation and so propose to use a simpler method based on the idea of a ring topology Local Area Network.

or viewed as a ring:

With this method, each PC is connected to the others by two cables. To ensure things stay simple, all messages will flow one way around the ring, so that each machine will always receive messages on one port and transmit on another. Messages will be "broadcast" and sent to all machines. As one machine receives a message, it will first re-transmit this message to the next machine and then action the message.

The keen-eyed reader will by now be saying that the message will run around the forever. This is true, so in order to stop the message running around the ring forever, the message must be tagged with the originator-id and the message will not be propagated when received by the originator.

Thus we have the conceptual basis for sending messages in a controlled manner between 2 or more PC's. Between 2 PC's only one piece of wire is needed.

Due to the requirement for two ports, this is going to mean that unless you have a PS/2 type mouse, the use of the mouse is out. Thus the game will be run on a keyboard only basis.

Throughout this diatribe, I will be frequently breaking off the main flow to try and provide an understanding of a mechanism or method. The more advanced programmers will be able to skip through these as they are aimed at the relative newcomer.

Notes: 

More fields may be available via dynamicdata ..