Tuesday, January 7, 2020

CLIPS Year In Review: 2019

This felt like a year of slow progress. I spent some time on the release of version 6.31 of CLIPS, but otherwise I spent my time slowly but steadily honing Adventures in Rule-Based Programming.

Plans in 2020 are the same as plans from 2019: release version 6.4 of CLIPS and publish Adventures in Rule-Based Programming.

Saturday, December 28, 2019

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...

Thursday, October 10, 2019

Low IQ Republicans


Try pulling your head out of Trump's ass. Right or wrong, this move is completely consistent with everything he's said and done.

Wednesday, June 5, 2019

Disappointed Yet Again

When I am Earth Overlord, it will be a crime to create a TV series without a detailed plan for bringing it to a satisfying conclusion. This decree will be retroactive for Game of Thrones.