Computers in Wargaming - 4 - Fit for Purpose

Computers. I've been around them for years - I worked with them throughout my professional career, and I've always been interested in what can be done with them, though they don't really excite me in their own right. I don’t build them, I don’t properly understand the engineering and, though I can do (and have done a good deal of) relatively simple programming, I definitely regard myself as a user rather than a techie.

[When I was considering how best to structure this post, I found a comment I had added to a previous posting, which gets across a few of the messages well enough for me to re-use it as a starting point, albeit in smartened-up form.]

Computerisation of my wargames has worked pretty well for me, but not through the use of anything that I bought or that someone developed for me. I am the proud owner of 2 commercially available computer-managed Napoleonic games for use with miniatures, and I don't use either of them. I have Follow the Eagles - Tactical (I think), which is quite thorough, though I don’t care much for its playability, and I also have Iron Duke which is far cheaper, more tweakable and generally more friendly - yet I haven't really used that very much either. It’s OK – I paid for them, so I am entitled to an opinion.

Apart from the inflexibility (and implied threat) of a sealed "black box" system, there is a common mistake that designers make: because they can't help it, because they were trained that way, because this is how computer applications look nowadays, they write nice, Windows-style GUI (Graphical User Interface) systems in Visual Basic or similar, which require a dedicated, mouse-wielding operator to read a screen full of nice coloured text, select things from drop-down menus, set radio buttons, click on defined areas of the screen for choices and actions etc. For a miniatures game, I believe this is wrong. Too much distraction - first off, the classy interface between the operator and the machine is completely cancelled out by the totally useless spoken/misheard interface between the players and the operator; secondly, this is a miniatures game - everyone is supposed to be looking at the action on the table - the computer is, almost certainly, a major nuisance. My own home-built systems are very simple data-capture programs which run on a very small, battery powered net-book which can be handed from player to player as necessary. The only entries are single key-touch (e.g. y/n) type responses to direct questions, plus unit numbers where necessary. That's all. This is a conscious attempt to simplify the user interface to the lowest possible workload.

OK – that is a suitable point at which to introduce the subject of Fitness for Purpose. Let’s take a fanciful example.

If you have to write (say) an automated inspection inventory system for some hazardous environment, where the staff will be working in cold, or damp, or toxic conditions, where they may be climbing on observation gantries, or wearing protective clothing (big gloves, say), it would be a major error to design a desktop type application which requires constant use of a mouse, or a lot of free typing, or which generally looks like the sort of package which accounts clerks spend their days with. The hardware is going to have to be compact and tough and convenient – maybe even specially built – and the input is going to have to be a real lumpen data-capture arrangement, such that they can hit big buttons with their gloves on, do the absolute minimum of tinkering, and read the big numbers without difficulty and without mistakes. They will not want to wait for McAfee to finish downloading an update in mid-job. They will probably not wish to be offered the chance to chat online, unless it is to set off an alarm. It would be a good idea, very early in the design, to brainstorm exactly what the intended users require of their system, so that the builders do not simply default to something they prepared earlier. [Factual digression: I recall a team of very expensive external contractors coming into an insurance office to design a client-server system to support the customer helpdesk. Since they did not understand the business, nor the processes involved in insurance, and since they were in a hurry, they immediately set about producing a re-hash of a system they had previously built for a police force in New Zealand, with some changes in the wording. It wasn’t a success, the business users were upset, and they had to start again.]

If we take a small leap to what we hope is a slightly less hazardous environment – that of the miniatures wargame – the same principles still hold true. As far as possible, we should aim to use the computer only for what it can advantageously do for us. We do not wish it to divert the players’ attention from the tabletop more than is strictly necessary, and we certainly wish to design the input arrangements so that they can be handled on the fly by the players, without burdening them with an unacceptable extra workload, without requiring them to sit down at a side table, without slowing everything down, and without confusing anyone, or making them fed up. There will be some trade-off, naturally – any tasks that the computer requires us to do will obviously take a measurable time – the aim must be that the extra time taken is justified by the convenience or labour-saving which the computer achieves.

The first viable home computers were sold with the BASIC programming language installed. It can be argued that the use of BASIC - a relatively high-level language - was a major step towards making home computers work. It was now possible for a member of the public to purchase a branded box off the shelf of a high street store, take it home and start writing simple executable programs straight away. BASIC was excellent - it read very like structured English, was simple to learn, and yet had a fairly sophisticated command set. It was greeted with great sniffiness by the grognards of computing of the day, since it wasn't "proper" programming. A great deal of commercial programming on mainframes at that time was still carried out in low-level, numeric languages such as IBM Assembler, which were labour intensive and difficult to master, but which produced software which ran very quickly and efficiently. The real practical disadvantages of BASIC (as opposed to the prejudices) were two-fold:

(1) The English-like instructions, though compact and easy to use, are not compiled into a stored set of machine instructions; this means that each time the computer reads your BASIC program, however many times it has run it before, it has to interpret it as it goes along, and create machine-code type instructions for execution. The interpretive process was very slow indeed in 1981 - remember that the chip speeds of these early machines were very low. Thus BASIC programs which required a very large amount of reiterative mathematical processing could run so slowly as to be useless. One way around this was to embed chunks of machine code into the BASIC programs, which would run much faster. Machine code was much nearer to the concept of traditional computing, and was specific to the processor chip in your particular machine, but there was a learning overhead.

(2) There is a maximum size of 64 Kilobytes for the program listing. In the days when programs were stored/saved on audio cassettes, and home-brewed programs tended to be small, this wasn’t really a problem. More sophisticated stuff, like video games, was always written in machine code anyway, so that it would run fast enough to be acceptable.

Fine. I bought a Spectrum in the early 1980s, I started writing software for my wargames, and I wrote it in BASIC, since that is pretty much all there was. In places where the processing was too slow, and sometimes if I needed to save some space, I used some machine code routines (PEEK and POKE – ah, nostalgia). The way this progressed has already been described sufficiently in section 2 of this series of posts. It’s worth observing that, though there were a number of people experimenting and producing software for their own wargames (like me) at this time, I am unaware of anyone who attempted to market anything like this then. Two possible reasons present themselves without much thought – firstly, there was no common view of which rules the game should follow, and, secondly, although the Spectrum was probably a market leader, there was a great variety of makes and models of computer available, and no two could share software.

Then everything to do with wargames went on hold for me for a period of about 15 years. When I restarted, one of my earliest jobs was to transfer the old BASIC programs (I had printed out the listings) onto a modern IBM PC. It made sense to start with a close approximation to what had been working on the Spectrum before the Intermission. Getting the BASIC written, with equivalent function, and debugging it all was enough of a chore without learning a new programming language or rewriting the game rules at the same time. I could start improving/tinkering later.

I got my Ancients game (Camulos) up and running and, since the Napoleonic game used large chunks of the same logic, I spent some time sorting out the Ancients. Since the world had moved on, I started to teach myself Visual Basic, and prepared to rewrite the wargame programs in a smarter, more modern Windows environment. At this point I also started looking at some of the available commercial offerings, and discovered that I was really very unconvinced about the classic Windows GUI front-end, and its suitability for a miniatures game. After buying some examples of games, going down some blind alleys and, really, confirming what I had suspected, I decided to stick with BASIC, though by this time it was called QBASIC. I am aware that this decision may be considered laughable, but if I had rewritten them in another language, I would still have been looking for something that behaved like the QBASIC programs, so I could not see the point of migrating the software just for the sake of it. I improved the programs a lot, designed them to work more efficiently and split them into functional modules. They are still written in QBASIC to this day – and, of course, like all rule sets, they are still being improved!

OK, so what happened to the 2 great problems of BASIC which I noted earlier? Good question.

(1) The processing speed of modern computers is so high that even interpretive, clunky old QBASIC executes with blinding speed. No longer a problem – not even a little bit.

(2) The 64K ceiling is still a constraint. The answer is to split big programs into functional chunks which can call each other and pass data to each other. When one of my battles reaches a decision point, my main Battle Manager program will store all the relevant current information about the battle and all units, and will call the Result Assessor, which starts off by looking for the handover file and loading the saved data.

Note that I am not suggesting that anyone starting now should necessarily use BASIC – my point here is that what appears to me to be the optimal input arrangement for a miniatures wargame management system is handled quite adequately by QBASIC, though the choice of language is obviously up to the programmer!

Here is a screen shot from the Iron Duke game – note that it is a conventional Windows GUI, mouse-driven application.

Here are a series of screen shots from my own QBASIC game – some examples of how the computer directs the progress of the game, stepping through the turn sequence and cueing the action, reporting on events as they occur.

It was a bad day for the 16th Light Dragoons, and especially for General Anson.

Weather checking is a good example of the sort of background task which a computer handles well.

That is really as much as I wanted to say. In my experience, once you are used to the convenience of an automated system (provided it is, in fact, convenient), all the memory work and mental arithmetic of a complex dice game can seem exhausting. My 8-year-old son became interested in my games recently, and so I put together a very simple dice-driven game for him, to get him some experience. When we were an hour into it, he asked if we could play the computerised game instead, since he found the dice a distraction. Now there’s heresy. It is possible, of course, that my simplified dice game was dreadful...

Lastly, to repeat the message which overrides all of this – computers have been useful because they have allowed me to use fairly complex rules without losing the will to live. The option would have been to cut back drastically on the complexity. If the Commands & Colors rules – straightforward as they are - provide games which run crisply, I shall be very happy to leave the computer on the shelf. It is, and always has been, just a tool, just a means to an end.