Close Combat: A Short History

I found this while going through some files on my computer. I'm not 100% certain, but I think this history was written by Keith Zabalaoui.

Once upon a time, there were no personal computers. We played our wargames using cardboard counters, paper maps, and dice, and we liked it. We wished we didn't have to memorize pages of rules, could move hidden troops, or could find an opponent in our neighborhood that was free at the same time we were, but we dealt with it. Then came the PC.

Oh, what glorious things we can do with a PC! We can teach it the rules, have it keep hidden units hidden, and play against the computer when no one else was around. But we were not satisfied. The graphics were generally worse than our beloved paper games. We still had to know the rules to figure out how to play the game. And the artificial intelligence of the computer was so lame, after the first couple of games, we wished we had a human opponent.

Then came a minor revolution in the art of computer wargames. SVGA graphics allowed the game to show the detail of a paper map and cardboard counters. Interfaces became more intuitive with GUIs and graphs instead of text and tables. Modems allowed PBEM so a human opponent could be anywhere in the world. But still, something was missing. The immediacy of battle, the cries of the wounded, the sense of being there was not there.

In the spring of 1992, Atomic Games decided there had to be more to wargames than the counter and the hexagon. More action than with PBEM and turns or phases. We embarked on what we hoped would be a revolution in wargames. Project X was born.

Project X was just a concept in Keith Zabalaoui's mind. Meeting with Chuck Anderson (graphics), Larry Merkel (Strategic AI), and John Anderson (Game System and Tactical AI, no relation to Chuck), Keith presented his view and we talked about what could and couldn't be done. What we wanted in the game, what we didn't want. Chuck created graphs and perspective renderings to show how an angled view would hide too much due to building walls and trees, and would have a very limited view. He calculated scale and dimensions of vehicles and determined that either we could only show less than a hundred meters on the screen, or we wouldn't be able to see the soldiers on the screen. The thought of playing the game with less than 100 meters visible at a time was disturbing because it would mean that you would rarely be able to see who or what was shooting at your men as most engagements occur at a much greater range. We compromised and came up with a scale where one could easily view 100 to 200 meters, then doubled the size of the soldiers in relation to the terrain, and increased vehicles to 1.5 times the terrain to keep the infantry from dwarfing them.

Given these restrictions on range and viewable screen, we needed to have the battles occur in dense terrain so that it would limit long range engagements. We also wanted the battle to have the US and the Germans as the opposing nationalities plus the battle had to have name recognition. Normandy and its bocage was a natural choice.

We wanted the player to feel that he knew each of the soldiers on his side. That he would be pained for their loss and would treat them as more than just a sprite on a screen. Keith contacted a psychologist he knew from playtesting V4V games, Dr. Steven Silver, and asked if he had some insight as to how soldiers react on the battlefield. Dr. Silver proceeded to write up an article and a series of tables describing the affects of stress, the detrimental nature of prolonged combat, and the unpredictable nature of man. Using this information, John created a series of formulas that kept track of every single bullet fired on the battlefield and its impact to the physical and mental well being of the soldier being targeted.

At one point, we discussed having soldier books for each soldier that gave the player a sense of who that soldier was and where he came from. We ruled this out once we realized that due to attrition and the sheer number of troops, it wasn't practical for anyone to get that attached to each soldier. Having to write letters to the parents of your lost men was also dropped for the same reason.

At this time, Larry dropped out of the team due to work load (all of us but Keith were doing this project on a part time basis while working full time with a NASA contractor), so in early '94 we were in need of an AI programmer. Through gaming contacts, Keith found Gary Riley, an expert in AI systems and developer of the CLIPS system used extensively in the NASA community. Not only did he play games, (a must in writing the AI for one), but he was an excellent programmer.

We began discussions with Avalon Hill to find a producer not only for this game, but also for the V4V series which was coming to an end due to financial problems at 360 Pacific. When the concept of the game was shown to Avalon Hill, it was done so with the forewarning that it was not Advanced Squad Leader, but what we thought small arms combat was like. i.e. we wanted to capture the essence of what ASL was representing, not the game. As such, the project now gained a working title of Beyond Squad Leader, for taking the small unit combined arms concept to something beyond what was done with the Squad Leader system.

At this point, Keith felt that it would be better to have someone else than himself do the user interface programming (Keith had done the work on V4V before handing it off to Jeff Wesevich). As he put it, "Why would I want to do all the programming when I can hire someone better than me to do it?". That better programmer was the Mac Meister, Steve Mariotti, who had recently graduated from the University of Texas. Our team (on the Mac side) was now complete. Steve was experimenting with animation techniques allowing us to have shadow effects (drive a tank under a tree and the tree shadow will cover the tank). Chuck was rendering vehicles in 3-D using a magnetic scanner and multiple graphics packages. Gary was developing algorithms to calculate the best movement path with regard to enemy fire and covering terrain. And John was busy tracking hundreds of individual soldier actions to make sure that a soldier loaded his weapon first before trying to fire it.

The summer of 1994 was when things were tough programming. None of our code was interfaced and we had limited means to tell what was happening. Gary drew out a square map grid where he placed counters representing the teams and tracked their actions via a command line interface that reported location and action of each team. He had to use a simple CRT and unit strengths to resolve combat. John had a similar system where the paper map represented a small section of terrain and he tracked the stance and move of each soldier through dozens of lines of events generated for each second of game time. He was ecstatic once Steve got the graphic interface tied in so he could actually see the soldiers doing those actions, plus Chuck could see his soldiers animate.

The big push was to get something that was demonstrable at the 1995 Winter CES in Las Vegas. Pulling the long hours we hacked together a simple demonstration where the Germans set up in a wheat field and were ambushed by Americans behind a hedgerow. (Yes, it's not realistic, but better for demonstration than the Americans getting whacked.) No user issued commands could be made but it was still popular at the show as people watched the soldiers run, crawl and blow up into little bloody bits.

In the summer of 1995, things were picking up in the programming area and we were all amazed at how enjoyable the game was, even in its early stages. Our in-house testers were having a blast even while testing. Chuck quit his full time job to work on the soldiers and guns and smoke animation and explosions, and map rubble, and so on. He needed three machines to keep up with all the animations he was generating. We also added our PC programmers from the World at War (formerly V4V) series when Jeff Wesevich (PC programmer extraordinaire) and Michael Traffanstead (the PC prodigy) started working on the PC port of this previously all Mac game. Also coming over from the WaW team was our historian and survivor of many a re-enactment Eric Young, who immediately set off to build the maps that represented the historical terrain the battles were being fought over. With all these people, we needed a project manager to keep track of what everyone was doing and what they were supposed to do. Doug Walker was brought in from NASA to coordinate, and communicate with our developers and producer.

By now, Atomic Games had published 2 games with Avalon Hill, Operation Crusader and Stalingrad in the new World at War series. Based on those experiences, we did not believe Avalon Hill was capable of handling a game as complex and as popular as we believed Close Combat was going to be so we began looking for a new publisher.

Both SSI and Origin Systems were shown the game and we received offers from each, but then a tester for the World at War series that worked at Microsoft found out we were looking for a new publisher for the game and convinced management at MS to check out the game. One thing led to another and MS and Atomic Games agreed to produce the game, code named "Grunt".

Only one more programmer to add. We wanted the game to be networkable as we felt the strength of this game system was in the head to head play but no one at Atomic had the experience or the time necessary to make a real-time network game work. Along came Linux / Network guru, Joe Rumsey, from California. We finally had all the pieces in place.

Development was working at full speed. We would put new code together, play it a while, decide that it didn't work right, then code some more. Features were thrown in and out on the fly. Eighty hour weeks were common but we were all dedicated to making the game work. The list of features to add was limitless so we had to say "no more" just to have the chance of getting the game out. By March '96 the game was mostly complete and we went into bug fix mode. Another 3 months of 100 hour weeks and it would be ready. With everyone working on the game at home and over the Internet, there was no such thing as not working. Everyone had their machines on 24 hours a day and worked when they were not sleeping. Finding food that could be easily eaten while typing was a big plus. Pizza, chocolate covered expresso beans, Mountain Dew, little powdered sugar doughnuts, Coca-Cola, cup upon cup of coffee, etc.

June 25th, Release To Market day. It was here, the game was done, we were happy. Everyone was exhausted. None of us wanted to go through that again. Well, ok, maybe once more but next time we will schedule it so we don't have to work huge numbers of hours in a week, have all the features worked out and planned in advance, and develop it on time. At least that's what we are planning...

Stowaway to Oblivion

During college in the early 1980s I wrote a never published text adventure called Stowaway to Oblivion. It was written in BASIC on the Apple II and had a very simple verb-noun parser. It was a fun little program, but I've always wanted to revisit that code and do something a little more sophisticated á la Zork.

Sadly I no longer have the source for Stowaway, but when I decided to write a new tutorial for CLIPS I came back to the idea of revisiting text adventures. Although the commercial market collapsed several decades ago, I discovered there's still an active community writing text adventures.

In writing the tutorial, I've been happy with how well suited CLIPS has been for this type of application, but as it turns out there's another declarative programming language called Inform 7 that's specifically designed for writing text adventures. It's pretty cool.

Jerry's Doom

Dungeons & Dragons

If you ever played Dungeons & Dragons, this blog has some information on its history you might find interesting.

I remember first playing D&D with the original set of rules at a friend’s house around 1976, but I eventually grew tired of the dungeon crawls and Monty Haul style of play that the game mechanics seemed to encourage (intentionally or otherwise). If I wanted to simulate a Vietnam search and destroy mission, I’d play a war game, not a role playing game.

It stands to reason that if you have a rule book full of magical items that players can acquire, they’re going to want to acquire as many of them as they can. One of the (unintentionally) funniest lines I’ve heard a dungeon master utter was “You’re limited to one magical artifact per day.”

Many of the D&D magic items have somewhat comical names, such as “Boots of Dancing.” On the infrequent occasions that I was playing with a Monty Haul group, I’d often claim my character possessed mock magical items. My favorites were the “Dagger of Healing” (1d6 of healing and 1d6 of damage) and the “Sword of Surgery” (2d6 of healing and 2d6 of damage).

Here’s how it works, I explained, I just keep stabbing myself until I start to feel better!

No one ever batted an eye.`

Settlers of Catan

If I could only recommend one game for a family to own, it would be Settlers of Catan, created by Klaus Teuber. It's the closest thing to a perfect game I've ever played. There are a number of reasons why I highly recommend it.

1. It’s a race, not a brawl

Games like Monopoly and Risk are brawls—you win by essentially beating your opponents into the ground and taking away everything they possess.

Races, however, are won by being the first to achieve an objective. In Settlers, you win by being the first to earn 10 victory points. Building settlements and cities gain you victory points that are never lost.

And as you build, the average number of resources you receive each turn will increase. This allows you to do more each turn and mitigates the effects of other players ganging up on you.

In my experience, races have much broader appeal than brawls, particularly among casual gamers. That’s not to say that Settlers is completely lacking in direct conflict between players—there’s competition for open spots on the game board and some accomplishments yield victory points that can be taken away—but these brawl elements are well balanced with the race elements of the game.

2. Clean, simple rules

The rules are simple enough that they can be taught verbally. The recommended age is 10 or older, so once the kids are old enough the entire family can play. And if you’ve ever played a game where the rules are ambiguous about what to do for a certain situation, you won't have to worry about that playing Settlers.

3. Minimal waiting

In many games, players are only allowed to perform actions on their turn. In Settlers, a player can only build on their turn, but players are eligible to receive and trade resources during any player’s turn, so there's incentive to barter so you’ll have what you need for building when your turn comes around.

4. Reasonable playing time

Most games can be played in 30 to 90 minutes—depending upon the number of players and their experience—so you can play at least several games in an evening. If your strategy isn’t paying off or you have a run of bad luck, you won’t have to suffer the entire evening.

5. Replayable

The game board is constructed by forming a large hexagon out of smaller hexagons representing different terrain types. This allows for a large number of board combinations affecting both resource availability and desirability of open spots. There are many different strategies for winning that can be learned through repeated play.

6. Experience counts

There's a good mix between luck and experience. Resource production each turn is determined by a die roll, so while it’s possible for a complete novice to win with beginner’s luck, experience definitely gives you an edge in selecting the best placement for your settlements and cities, determining which trades are in your favor, and devising the best strategy for a given situation.

7. Lots of expansions

If you like Settlers, there are a number of expansions for it (including one that allows up to six players rather than just the two to four that can play with the basic game). There’s also a family of similar games using the same tile-based resource generation mechanics.

8. Intelligent tutoring agent

OK, so this one’s only of interest to artificial intelligence nerds, but there’s an intelligent tutoring agent for Settlers built using CLIPS.

Candy Crush

Candy Crush is the kind of game R.J. Reynolds would make if they were peddling entertainment rather than cancer. The game itself is visually appealing, fun to play, and very addictive. It’s that last element that really adds the sleaze to the coercive monetization King Digital Entertainment uses to generate income.

I’m one of the 70% that’s never spent money on the game and never intend to, but was I tempted to pry open my wallet the other day when I saw this while playing:

Live forever! You mean I can pay something reasonable like $10 or $15 and just play the game continuously? I don’t have to wait or spend money to continue playing each and every time I run out of lives? That’s something I’d be willing to buy!

Oh, wait. By forever you mean the next two hours, not for all time. So if I lose lives at a rate of one each minute, how many “unlimited” lives can I get?

Let’s see… 117. 118. 119. Infinity. That adds up.

No thanks, I’ll spend my money elsewhere.

Just say no to coercive monetization. Play but don’t pay. Develop patience or spend your money on games that charge you upfront and allow you to play continuously.