Going... going... gone; Peter Gouldesbrough and the 5mm Blocks

Recently, someone made a jocular reference to the old Minifigs 5mm troop blocks, which, for me, come under the general heading of Did This Really Happen?

I'll come back to the 5mm blocks in a minute or two, but for me the strongest recollection is that they remind me of Peter Gouldesbrough, one of the better known of the earlier Scottish wargamers - who for a while was a great enthusiast for these blocks - and of a brief period when I spent some time with him, so let's start with Peter.

The General from the Braid Hills

Peter was retired when I met him. We were introduced by a mutual wargaming friend, who had mentioned to Peter that I had been working on some pioneering solo wargame projects involving microcomputer programs. Peter had just been given one of those newfangled Sinclair Spectrum thingummies as a present, so that must mean 1982 at the earliest. Since my first wargaming sabbatical started in 1985 (major dose of Real Life for some years thereafter), this dates things pretty accurately.

Peter was friendly with a number of the leading post-war lights of the hobby - Peter Young and Charles Grant for a start - and he is quoted in a couple of Featherstone's earlier books. He was a complete gentleman, always - I never saw him without a suit and tie, as far as I can remember.

When I met him he had recently disposed of his 20mm figure collection, and had converted to the Minifigs 5mm block system. He had redrafted his own wargames rules to suit this new scale, and this is where he wanted my help with some programming, so he could use his new Spectrum to do the record-keeping and the calculations. I was invited to participate in some of his new Napoleonic "microgames" at his house - his home and his games were every bit as dignified as I had expected. 

We made some good progress with the automation of his rules, though I learned the hard way that he could be a dreadful bully, albeit a gentlemanly one! I found a number of arithmetical errors in his rules, but when I drew them to his attention I had a hard job getting him to admit they were wrong, never mind getting agreement to correct them!

5mm blocks - picture borrowed from the Wargame Hermit's excellent blog. One reason
why these were short-lived, I think, was the poor quality of the casting - the moulds
were breaking up very soon after they were launched. Also, it is only now that I realise
that these blocks were introduced circa 1972, and withdrawn in 1976, so they were
already long-OOP when I was introduced to Peter's game!

The games themselves were visually interesting, though for my taste Peter had re-engineered his wargames in the "wrong" direction; a move to 5mm gave the opportunity to stage colossal battles in a compact space - this is what I would have done - but he had gone the other way. For example, he had French battalions consisting of 12 blocks of 3-deep infantry. His rules had very detailed instructions on the deployment of these half-company sections, so that changing from column to line, or sending out skirmishers (and the skirmishers were cast on tiny strips, which were exchanged for the close-order blocks as required) was a very precise, not to say painstaking, operation - as I recall, his game used 30-second bounds, to make sure we did it all properly. I also remember a couple of hilarious incidents when we lost some of the tiny troops on his battlefield. His wargames room was upstairs, on an attic level, and was rather dimly lit; add to this the fact that his table was a very dark green, like a table-tennis table, with Plasticine hills to match, and it was little surprise that the soldiers used to disappear from view. On a couple of occasions the French "lost" a regiment of light infantry on the hills, simply because we failed to spot them in the gloom. The skirmisher strips would gradually disappear, too - occasionally a couple would turn up behind the clock on the mantelpiece, one was found on the floor (fortunately before it was stood upon), one was spotted hanging from the sleeve of my sweater (wouldn't have happened with a suit), and on one occasion we found one embedded in a hill when we were clearing up.

Peter's thoughts on 5mm - despite what he says here, his interest in
manoeuvre resulted in his sticking with the 30-second moves!

When it was tested and reliably stable, I was roped into helping with a demonstration of the 5mm-block+Spectrum game at a wargames show one weekend in Edinburgh's Adam House, at the foot of Chambers Street, in the old University territory. This was a very long day - I was involved in the transport and setting-up, which wasn't helped by our being stuck in a quiet backwater of the basement, and thereafter I was the computer operator, gaming assistant and general gopher, helping out with numerous runs through a suitable set-piece battle. I recall that Peter had hand-painted a poster for his game, with the legend, "GOING... going... _GONE", with appropriate pictures of British Napoleonic infantry gradually shrinking into invisibility.

I regret it was not a terrific day. The weather was dreadful, the show was poorly supported (at least our bit of it was) and we had maybe a dozen casual visitors during the course of the entire day. Peter, understandably, was rather miffed after all his hard work, and became somewhat grumpy. At one point an acquaintance of mine came over and chatted with me for a couple of minutes. Peter was furious - I was not there to chat to my friends, etc. I fear that, though we didn't actually fall out, the day ended on a low note.

Ancient, appropriately grey photo of Adam House

I was unwell for a while with glandular fever, but a few months later my wife and I were invited to a party at Peter's home - a very pleasant evening, and everything was very friendly, but after that I lost touch with him. Eventually, as these things tend to go, it was so long since I had spoken with him that it became awkward to make the effort to phone him up. Thus, I am ashamed to say, I never met with him again. Mind you, it might well be that he was extremely relieved to be rid of me!  

Peter told me a number of very entertaining tales of his experiences in WW2 - since I am not a family friend I am reluctant to recount any of these at the moment.

I don't really know what became of Peter - this post is prompted really by my wondering whether anyone would care to contribute any tales of the Minifigs 5mm blocks, and in case anyone can provide any more information about Peter himself. I am very much indebted to Clive, the Old Metal Detector, for providing me with some clippings about him from Wargamers' Newsletter. Also, if anyone remembers the Edinburgh wargame shows at Adam House (must have been 1984 or 85, I reckon), please shout. I guess there was some more serious stuff going on upstairs!   

Hooptedoodle #263 - The Airline and the Krell

I was not personally impacted by the dreadful systems failure which hit British Airways and their customers a few days ago - my heartfelt sympathy is extended to anyone whose holiday was destroyed, or who suffered personal discomfort or inconvenience - all of that goes without saying. I am interested to see that there will be an independent enquiry into what went wrong - I fear that there might just be a whitewash job, or that some poor department head somewhere will be the subject of a token beheading, but in principle I look forward to seeing what they come up with. This is something of a hobbyhorse of mine. Certainly the current official explanation that it was all due to a power surge of some sort seems so laughable that it is equivalent to the old catch-all, "the dog ate my homework", though, naturally, it would be unwise to pre-judge. Already, there is sinister mention of software support having been outsourced to India - erm - right...

There was a professor from Glasgow University on BBC Radio 4 this morning, talking about the boring but rather essential matter of system resilience. He talked a lot of sense - there is not much sense around on the radio at the moment (don't get me started on the Election).

If you will forgive me, I'll plead for two quick timeouts at this point; the first is a link to a post I wrote here almost 5 years ago - The Banks and the Krell - about the increasing scope for catastrophic system failures in business, and the implications for society in general. If you care to check that out, it will save me saying a lot of the same things again. If you do not care to, that's fine too.

The Krell's computer installation in The Forbidden Planet

The second is a short story about a car I used to own. It was a 1995 Mercedes - only Mercedes I ever owned, and it was a great car - not very exciting, but dependable, and built to last. The date is significant, because it was a period when cars were starting to be equipped with automatic sensors and systems which were intended to make life simpler for the motorist, but also meant that the family car was becoming more and more of a mystery to both the owner and the supposed mechanics at his local dealership.

After a while, my Mercedes suddenly started suffering frequently from a flat battery - eventually it was every morning. The dealer replaced the battery (at Mercedes prices, of course), and checked the car over - no problems. Well - not so fast. The battery was flat again the following morning - that's the new battery with the clean new labels on it. The car went back to the dealer, who kept it for two days and returned it with a clean bill of health. Battery was flat again the next day. A terse phone call prompted the offer of another replacement battery under the terms of the warranty.

In desperation I took the car to a proper automotive electrical engineer somewhere near Prestonpans, and within an hour he had identified the problem. The car was fitted with a special sensor, the entire purpose of which was to detect if the electric windows had been left open when the vehicle was locked with the remote key. If it found that any one was open, it automatically switched in the motors which closed the windows. Great idea, eh? Unfortunately, the sensor had become faulty, so that when the car was locked the system incorrectly detected an open window, and attempted to shut it. Since the sensor was faulty, of course, the car was never satisfied that the windows were now closed, and it continued to try to close them continuously until next time it was unlocked. This doesn't mean that the motors were grinding away - the motor would not actually run if there was any resistance (another safety feature), but it would keep checking and trying - silently - and by the next morning this would have consumed enough power to flatten the battery.

The engineer rang the workshop at the Mercedes dealer and discussed the options with them; I could pay £370 + VAT for a replacement system - no other possibilities. In fact there was one other possibility, but I'll get to that.

I talked it through with the engineer. I was probably going to sell the car within a year anyway, and I had never left - nor was I likely to leave - the windows open when I locked the car. If I did, the worst result would be an open window - without the keys, the immobiliser system (Ha!) would prevent anyone pinching the vehicle.

Thus my £370 + VAT would provide a complete solution to a problem which I was unlikely to have. The alternative was simply to remove the fuse from the bit of the system wiring which supplied power to the Windows-Open-When-Locked sensor - the cost of this would be zero, of course, though I might be at risk, however unlikely, of leaving the windows open by mistake. No brainer - I went for the cheaper solution.

There are many lessons like this, but that one stuck in my mind - someone had provided a costly, over-the-top, luxurious solution to a problem which did not seem terribly serious, and - after it became defective - had thereby generated a much more significant operational problem in my use of the car. Something wrong there?

This whole industry expanded at a crazy rate - huge cleverness being applied to provide solutions to problems which might or might not exist, in the holy names of convenience and (the ultimate trump card) safety. My wife's current car knows when it's raining, knows when you need to change gear, knows when it needs to switch on the lights, knows the numbers in the phonebook on her mobile, will give you running statistics on things you never even thought of, has a built-in satellite navigation system, has an intelligent cruise control system which can be set to maintain a minimum distance to the car in front and - of course - can park itself without your assistance. It's wonderful that a piece of everyday technology can do all these things, and some of them are definitely useful, but what's going on here? If my wife's car suddenly stops running, or if the doors decide they are not going to let her get in, she is well and truly stuck. There is no question of opening the bonnet and spraying WD40 on the plug leads, or improvising a temporary fanbelt replacement. She is stuck. All she can do is phone up on her mobile, and get a mechanic with a laptop to come when he can, and diagnose what the problem is.

Righto - our cars are very unlikely to conk out, compared with cars we've had in the past - this is the power of technological progress - but if they do then the degree of well-and-truly-stuckness may be of a different order from what we have seen in the past. Not only has our vehicle let us down, an event which we will not have expected and for which we will not have a back-up plan, but our greatly diminished residual experience of coping with emergencies, of applying flexibility and adaptability, of having contingency margins built into our Plan for Today, the unfamiliarity of having to switch on our own lights and wipers, of getting to Lancaster without having a robot tell us what to do - none of these things is going to be a big help.

To sum up - the technology looks after us wonderfully well, but if anything fails we can be more desperately exposed than we used to be.

Consider the mobile phone networks. Presumably your local (or national) service could be impacted by a power surge (surely not?), or a malware attack - it is even possible for natural events like unaccustomed levels of sunspot activity to cause technology headaches. It could happen. If it does, how many kids will be out of touch - lost somewhere on the way home from school? - how many mothers are going to be running around screaming OMG? - how many calls will not be made to rescue sevices in response to genuine emergencies? - how many online banking transactions will fail because the text message to the mobile with the passcode will not work? - how clever is your Apple Pay app going to be in the supermarket? Does any of us have any idea what we could do, in the event of what might be a fairly routine and low-level failure?

Well - you might, quite possibly - but I know that I don't, and I've thought about it - I used to have to think about things like this in my old job. My 2012 post about the Krell was mostly about the fact that we take these advances for granted, and we very quickly forget what it is they are  doing for us, and what it was that we used to do for ourselves before they arrived. We do not understand how the business which employs us works, because normally we do not need to; we do not know how to spell "laughs out loud" in full, nor how to read a map, because we no longer do things like that - there's no demand for that sort of knowledge.

If your airline of choice has a major systems collapse, and they do not seem even to know what it is, or what caused it, you may not find this reassuring. One day, aircraft may be so complex that only the onboard flight systems know how to fly them - with who knows what level of outside communication with global systems. In a world where, to save money, we are trying to achieve UK passenger trains manned by a single individual, how long will it be before the flight crew on a plane are just there to serve the coffee and make sure the computer is happy? At what stage will progress mean that they are no longer able to land the stupid thing without the technology?

Do you feel lucky, punk?

Hooptedoodle #212 – Technology Yawn Hour – Mac Viruses

Good Heavens - THEY are going to terminate my account - I must do something really
stupid without delay. This screen courtesy of EasyShopper, I believe - interestingly, the target
URL for this screen is something to do with a mortgage portal. Why don't these creeps just
go and die somewhere? 

For a few years now I have been using a Macintosh as my main computer. I still have a desktop Windows machine, because it is much better for some jobs, but the Mac is my main internet tool. One great advantage this brings is that I have almost forgotten about viruses – the Apple architectures are less vulnerable to malware anyway, but also the relatively small potential-victim base makes the OS X world less attractive to those sad little single-cell organisms who spend their nights attempting to wreck the internet by contructing viruses.

I’ve had a few minor jolts this week. First came from an invitation to update my installed (Mac) version of Adobe Acrobat. I accepted this, as one does, and very quickly got an alert that an unauthorised browser extension was being installed – Joyround. I attempted to cancel the installation, but my Safari browser went very strange immediately afterwards. My homepage was changed to an unfamiliar Google search request screen, and all new opening tabs showed the same screen. Google Calendar, which I use on my desktop and my iPhone for all family and business schedules, also began to behave strangely, interrupting the normal functionality with a recurring pop-up screen (which I couldn’t exit) inviting me to apply for a fancy deal on an iPhone6.

I corrected my browser preferences, and I ran a Mac malware checker, and found and eliminated the aforementioned Joyround abomination. Sorted – I am back to the normal Mac world of calm, except that I seem to be getting intermittent advert interruptions from something called EasyShopper – I’ll see if I can find how to get rid of this. The stupid screen shown at the top of this post is courtesy of EasyShopper, as far as I can tell.

Discussion with my son reveals that he recently had to reinstall Adobe Acrobat on his Windows laptop, because an update seemed to have put an undesirable extension onto his web browser.

Corrupt this

Watch your step. Carry a baseball bat at all times. If you get an invitation to bring Acrobat up to date, check that it is genuine and what you are installing – even if it is a kosher upgrade you may find that you have Chrome as your default browser afterwards if you do not carefully uncheck the necessary boxes.

Hooptedoodle #57 - The Banks & the Krell

It is easy to use a blog as a dumping ground to share visions of gloom, or to have a sad little go at someone or something one has a personal grievance about. I try not to go overboard, and I try to keep it humorous, but I admit that I have a tendency to make a noise if I think something is sufficiently bloody awful to warrant it. I realise it may not achieve a great deal, but at least I’ve contributed my rather shrill tuppenceworth. This, I am led to understand, is one of the merits of the Internet.

Like most of the population of the UK, I’ve been a bit depressed by the state of our banking industry recently. I never worked for a bank, but I did work in the finance industry for my entire salaried life, and my views on this may be better informed than most.

There is a lot of virtuous outrage (partly fuelled, as ever, by public envy of personal wealth) over the situation of the gentleman at Barclays who may or may not be answerable for some stupefyingly corrupt behaviour in the Bad Old Days just before the world ended in 2008. I don’t wish to add any further silliness to what is already a hysterical issue, but I am mystified by his defence that it wasn’t him, that there were people who worked for him who were responsible, and he didn’t know.

OK – I’m not actively involved now, and maybe values have changed, but it seems to me that:

(1) If they pay you a lot of money to be in charge, then ultimately you are accountable for what happens in your area.

(2) Naturally you cannot know everything that goes on, but you are obliged to stay on top of things – to ensure that governance, procedures, rules and an ethical culture are in place to check that staff know what they can and cannot do, and to enforce correct behaviour. If you do not manage to do this – and it will not be easy – then you have failed in your job and you are answerable.

(3) Thus (in my extremely humble opinion) the man from Barclays either knew what was going on – in which case he is culpable – or else he was not in control – in which case he failed in his job and is therefore still culpable. It’s a tough life in a top job – that’s why they get all that money.

Anyway, that’s not what I wanted to write about. I wanted to write about the Krell.

If anything, I am more alarmed by the software failure at NatWest Bank last week – a system change caused problems which separated many of NatWest’s customers from their money for a period of days, and generated huge inconvenience and actual hardship. Scary.

On a smaller and less disastrous scale, I had a customer’s-eye view of the recent switch of Bank of Scotland to Lloyd’s Bank’s computer systems. It wasn’t good. For a period of some months, the bank was running with an interim system which had customers queuing up to fill in slips of paper in a manner such as I had not seen since the 1980s. Retro banking. I am confident that Lloyds and Bank of Scotland did their best in a difficult situation, but for a while their systems were really not fit for purpose. It’s a dangerous sign, but on a number of occasions I found myself thinking that this would not have been tolerated in my day.

My day? What the blazes has it got to do with me, then? Well, as it happens, I was a computer person for almost all my working life. By the late 1990s I was in charge of all business software development for a very large financial institution which shall forever remain nameless, and I knew the guys who had the equivalent roles in most of the UK banks – and they were good. They would not have rolled out any system which didn’t work, or which used customer inconvenience as a buffer to tide them over.

So what has changed?

Well, I was also around when the seeds of the coming storm were sown in the 1970s and 80s, so I have a very fair idea what I’m talking about. Which brings me to the Krell.

I don’t remember the details – maybe you do – but in the film The Forbidden Planet the Krell are a mighty, super-intelligent race of beings who have died out (for reasons I also cannot remember – perhaps they smoked), and part of their legacy is a collossal underground computer installation, which has been running for thousands of years and is still running – and nobody knows what it is doing.  That’s the important bit – since no-one knows what it is doing, no-one dares switch it off.

Right. Back to the 1980s.

In the 1980s I was a business systems analyst. We were hotshots. We would go into a traditional business department and we would ask them all about what they did and how it worked. We would capture the expertise of some very experienced and intelligent, professional people, and we would draw dataflow diagrams and build data models and we would automate their processes. It was brilliant. We used to make people happy – we took huge amounts of drudgery out of their jobs, we built in safeguards and automatic audit trails, and we saved them enormous amounts of money. When Jeannie who did the commission work became pregnant and left (and people did things like that in those days) then they didn’t need to replace her. Not only that, but any new staff who did come in required much less training, since a lot of the expertise and decision-making was now built into the computer system.

Fantastic. It was a wonderful job – people actually loved us. I have never been so happy at work.

Move the clock on 10 years. It is time to go back to one of our departments and their 1980s systems, and see what needs to be done to get things squeaky again – because there is now an accumulated tangle of 10 years of emergency fixes, rushed changes to support product launches and new regulations. Time for a detox.

Problems. If the analyst sat down with the new department manager in 1990, he might well be talking to someone who had no experience of this area before the systems were put in. It was almost certain that this manager would be unaware of some of the business rules, because they were now built into the desktop system – they just happened automatically. Similarly, the new model of the business process they agreed on might well omit a vital job which happened every night at 2am in the middle of a batch run which no-one understood any more.

Around this time, we used to talk a lot about system ownership. Business managers would laugh at this, and produce comic visions of putting their system in a bag and taking it home, but by and large they had washed their hands of understanding. When the computer systems arrived, responsibility for understanding the business shifted by default to the IT people. They had, after all, got everyone into this mess.

Well, the bad news is made even worse by the fact that the computer analysts had moved on as well, and the constant focus in the business world will always be to cope with new changes. Maintaining the old stuff is a lower priority – especially when it comes to allocating the budget. Yes, we know the roof is leaking and the foundations are sinking, but what we really want is a shiny new barbecue and some of that decking stuff. Great.

Everyone remembers that there was a huge panic prompted by fear that the year 2000 would cause disastrous software failures – a lot of money was spent and a lot of effort expended. Since we are all still here I guess it worked, but the thing I remember most is the effort that went into digging into that mysterious old software – paying over the odds for people who knew how it worked and – most scary of all – finding people who could still read the ancient languages it was written in. Looking, in fact, for surviving members of the Krell.

And still time passes, and still the software deteriorates, and still our understanding of what the great machine is doing becomes more hazy. Yes, business managers should have paid more attention and kept in touch with how things work, and – certainly – IT people should have spent less time obsessing about crap like Information Engineering and client-server and object-oriented and (who can forget...) artificial intelligence, but the fact is that they didn’t. Lots of money should have been devoted to keeping the old systems up-to-date and clearly understood and operationally viable, but it wasn’t.

The Krell are dead. The machines are still running. The problems at NatWest are just the beginning, gentlemen. The decay of old systems is exponential. Building replacement systems is not possible, because nobody any longer understands what it is they would be required to do.

Welcome to the beginning of the end. I must have a look on Amazon and see if I can get a cheap DVD of The Forbidden Planet.

Hooptedoodle #54 - Ding Dong, the Witch Is Dead

I have, in the past, made the occasional utterance about time lost to the antivirus software from McAfee which I pay for as part of my agreement with my Internet Service Provider.

Things have got so bad recently that I started having a look at a few of the support discussion threads for McAfee, and it seems that - though the originators swear it is now fixed - things went pear-shaped after an upgrade last September. All over the known world, McAfee's customers are becoming more and more stressed. At the start of this week, it took eight minutes for me to open a Word document which I had typed up and saved the previous day - McAfee was checking it. At various times in the day, even when I am not online, the desktop computer's fan has been switching on and - there it is - McAfee is suddenly using 90% of available CPU. No-one knows why, not even McAfee. On Tuesday we had a minor family problem and I had to find some things out and get stuff arranged quickly - no go. McAfee wouldn't let me do anything. It was busy.

The final straw was when I found a suggestion from a member of a support team on one of the discussion threads, which suggested that the person writing in with the problem should think about buying a more powerful computer, so they could live with the demands of their AV software.

As Descartes used to say at breakfast, "Un oeuf is enough". I am, as it happens, planning to upgrade my desktop machine in a month or two, but it certainly isn't going to be because McAfee forces me to do so. So I have uninstalled McAfee - it didn't go willingly, but it is gone. I am now paying for a licence which I am not using, but to hell with it. I have installed Microsoft Security Essentials, which is free, and which appears to work nicely and quietly in the background without drama. It did a full system scan yesterday in a little over 2 hours, which compares favourably with McAfee's recent record of 8 hours. When the new machine comes, I intend to put McA back in place, but I will remember that there is an alternative if I need it. In the meantime, I can get on with things and smile a little smug smile to myself.

There is a description of computer malware on one of the support sites I was reading, and part of it says:

"A virus's primary function is to take control of the computer's operating system and deny user access to communications and application software"

Seems strangely familiar - normally you don't have to pay for a licence for it, though. All together, now, please join in...

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.