The Quicksilver Story: Chapter 9

Welcome to Quicksilver!

This is the ninth post about the story of our company. You can jump to the beginning here: The Quicksilver Story: Chapter 1 and to the previous chapter here: The Quicksilver Story: Chapter 8–>

Our story is four decades long, and still going strong. It involves more than 50 games for numerous different publishers, and a number of military training apps that leverage our game-design and educational-game background. Here we will cover the second part of that story: our award-winning logistics training software.


Military Applications: Distribution Management Cognitive Trainer
Our largest and most successful military software project was known by the delightful acronym DMCTI: the Distribution Management Cognitive Training Initiative.

Pretty much every military trainer we did had an alphabet soup of a name, but this was a real mouthful.

The goal here was to train logistics specialists. An army needs supplies in order to fight, and logistics personnel see to it that they have what they need when they need it. It’s a critical and complicated job, but not always immediately rewarding. It involves reading reports, finding available transports, monitoring road safety and closures, and dealing with sudden changes in requirements. The Army developed standardized planning and reporting software, so we had to replicate its key functions in our app.

A quick observation: one of the most jarring aspects of this project, for us, was the visual aspect of the Army's logistics software. It was truly ugly: garish in color, brutalist in layout, awkward and overly difficult to use. Coming from the perspective of an industry that prides itself on visual excellence, we were somewhat taken aback by the screens that we saw. Not to say that DMCTI is as pretty as a video game. It's not. But the contrast between the app's screens and the simulated reports is pretty dramatic.

How do you make this subject fun? That's quite a trick. Moving pallets of toilet paper, bottled water and artillery shells is not exactly gripping material. It's also a high-pressure, low-reward job, where folks only get noticed when they make a mistake. Stakes are high -- not getting bullets to the front line could have serious consequences. But how could we make our trainees want to learn how to do it?

Games are storytelling, at a fundamental level. We’re creating a world, weaving a compelling tale, and inviting the player into that world. As designers, therefore, we look for the story in any situation. We look for ways to weave the subject matter into a coherent and compelling tale where participants are eager to see the next chapter. We’ve talked previously about how we turned a series of typing lessons into an adventure in Type to Learn 4. Military trainees have a different approach than elementary school kids, so first we had to learn to think like they do.

Military personnel like to demonstrate that they’re good at what they do – whether it’s combat or logistics. So we turned our training lessons into puzzle-solving exercises. We challenged the trainees to show off their ability to fix situations that had gone sideways and to avoid traps that had been laid in front of them. Could they still get everything where it needed to go when a bridge was blown up? Or when a sudden additional need arose at one of the forward bases? We put them in the middle of interesting stories, and they eagerly competed to find the best solutions.

DMCTI is a great example of taking an ostensibly “dry” subject and breathing life into it. We’ll see another example later, when we talk about The Game of Tradeoffs that we did for the Naval Postgraduate School. In this case, we had a great deal of help from our Army SME (“Subject Matter Expert”), who absolutely loved telling us stories of his many exploits in various combat theaters around the world. We eagerly listened to many hours of tales about operations gone awry, troublesome people and crises averted. He brought a deeply personal depth to the content that would not have been evident at all from the Field Manuals and reports alone.

How do you add engaging videos to such a product?

This tool needed to be able to be used "on laptop on a mountaintop in Afghanistan" -- in other words, on a minimally capable device, running on battery power, in a place where there was no outside connectivity. The laptops used by the Army at that time were very basic Lenovo/IBM business laptops with zero 3D graphics capability. We couldn't do pretty, interactive videos.

We used a trick we’ve used several times before: we did pre-rendered videos instead. We were able to use all of the advanced tools in desktop rendering packages (smoke, particles, and excellent lighting) by spending many hours rendering and then compressing the videos at an appropriate resolution. We made numerous variations of the videos to match the options that the user selected (time of day and number and types of trucks in a convoy, for example). Then we simply looked up the video that matched the scenario and played it back at the appropriate time. It worked perfectly, and looked great even on a low-power machine.

One of the first things our team did was travel to a training base where we learned how the Army’s logistics software, called BCS3, worked. We took an accelerated course because we just needed to know the reports, but didn’t need the “buttonology” – which buttons to press to make it work.

That’s an important lesson. Trying to simulate everything about a given process is impossible. The designer has to choose carefully what is to be included and what can be abstracted away. In Full Spectrum Command, we abstracted the combat mechanics. We didn’t simulate every bullet; we literally rolled dice to determine combat effects. For this product, we decided to replicate the BCS3 reports, but to simply let the user press a single button and get the report that would require a sequence of commands from the real software. We had to focus on reading the report, not on the buttonology of how it would be obtained.

Similarly, we had to decide how much of a simulation would be required in order to make our lesson plans work. We decided that, since the typical logistics cycle is 72 hours, we would need to replicate events during that time, and therefore needed at least a semblance of real-time tracking for each vehicle. This was made even more necessary by the possibility of random events causing changes in plans.

Still, there had to be limits. This is where our game design background helped again. There are tricks for making a user feel like they have complete freedom while actually constraining their actions to a subset that you want to allow. We sometimes describe this as “building a foot-think plexiglas wall in the world.” We make it look like the world goes on forever, but in fact you can’t get beyond certain hard limits.

In this simulation, we had to prevent the trainees from just “calling in the helicopters” when a road got blocked; that’s not always a solution, and we wanted to make them do it the hard way so they’d be prepared when the situation cropped up in the real world. So we grounded all of the aircraft. Similarly, we limited which bases would get resupplied from outside the theater of operations, both to keep our design simpler and to prevent Captain Kirk’s solution to the Kobayashi Maru scenario (non Star-Trek fans: look it up. He cheated).

Likewise, there are too many different commodities for us to be able to simulate all of them. Besides, we don’t need 100,000 different items to teach lessons about planning, coordination, and how to read orders carefully. So we chose a small subset, ranging from several kinds of ammunition to bottles of water and, of course, toilet paper. This actually makes sense to logistics personnel, because there are separate “desks” that handle specific commodities, so we just explained that the trainee was assigned to a desk dealing with these specific items. Piece of cake.

There was an additional twist: the software had to not only simulate behavior, but also monitor the trainee’s actions and score them based on whether they solved the puzzle correctly. After that, it also needed to recommend specific sections of the Field Manual to review for remedial help. In effect, we needed to put the instructor inside the machine somehow. The solution to this was quite complicated, but it worked perfectly:

  • Define every possible skill that the logistics trainee needed to learn. This turns out to be easier than it sounds, because our incredibly talented SMEs had already done this as part of their classroom work. We modified their list, trimming it to the subset of actions we needed to train, and ended up with a list of about 100 “Terminal Learning Objectives” (like “Leadership”) and “Enabling Learning Objectives” (like “Understand Radio Frequency Identification Device (RFID) Systems, capabilities and employment”.
  • Working with the SMEs, define a set of ten scenarios that would each highlight just a few of these TLOs and ELOs. Make sure the language is authentic. Then prioritize them so we could pick just a few and build a good story around them. And be sure to note which supporting documents contain descriptions of the task.
  • Again, with SME input, list all of the tasks the trainee should be performing to accomplish this mission. Draw a one-page flowchart depicting the order in which the tasks need to be done. Some can be done in any order (review three reports), but you can’t assign trucks until you first check to see if they’re available.
  • Here’s the cool part: now we assign Learning Objectives to each task in the flowchart, so that we know what skills are required to complete the task correctly. If the trainee fails to perform a task in the right order, that’s a failure, and we can score it accordingly. Plus, since we’ve defined which pages in the Field Manuals apply to each task, we know what reading material to recommend – no “AI” needed.
  • But it gets better: we designed the scenarios very carefully, so there were only one or two viable solutions. Then we hid the best option by providing additional information that looked helpful but in fact closed off certain options (trucks available, but on the wrong day, for example). We therefore knew for sure that the trainee would have to choose either ten or twelve trucks from this one base to get the commodities where they needed to be, and any other option was a failure. So we could grade the result reliably and automatically – again, no “AI” needed.
  • The result of all of these careful design decisions was that we could create a customized, actionable evaluation of the trainee’s performance, complete with a printable list of review items, if any.
  • The trainee could “drill down” and see details of each item that either passed or failed.

Designing simulation-based scenarios isn’t simple, especially when complex timing relationships are involved. We had to create an entire simulated world with several forward bases, several supply bases, and a network of roads between them, some of which were unsafe, dangerous or simply unavailable. Then we had to define which commodities were needed at each location and create pre-existing convoys that were already taking those items to them. We tested these to see if they actually worked. Then we “broke” them by closing bridges or changing requirements so they could be used as the basis for our lessons.

Managing this much data was a huge challenge, so we created a spreadsheet to structure all of the details. For each scenario, we created, in addition to the items discussed above:

  • a list of the simulated reports that would be available
  • lists of routes with distances and statuses
  • lists of commodities and their locations
  • lists of available vehicles (with times)
  • a list of all active convoys (typically about 50)
  • a list of transportation movements that had been requested
  • and a number of smaller, supporting tables

We are tool builders. And we believe in the “lazy programmer” theory of software design: the best programmer is one who wants the machine to do all of the work and invents time-saving tools to avoid tedious manual efforts. Naturally, we designed this entire spreadsheet (1,000 lines x 100 columns per scenario) to be exportable to data files that could be used directly by the code. Visual Basic is a strange and quirky language, but it worked great at converting our complex tables into data files in XML format.

The first scenario took six months to build. The second one took three months, and the third one a single month. The other seven were done in about a week apiece. Because we’d laid out such a powerful framework, constructing the later lessons simply required permuting some of the earlier ones and tightening down the challenges.

D E S I G N  N O T E

Easter Eggs

One of the fun traditions of the video game business is adding "Easter eggs" to games -- clever, often amusing hidden features. Management is often aghast at such things; people have lost jobs because they put Easter eggs into their games. Mattel Electronics was very guarded about employees, including their names, so they had very strict policies against adding Easter eggs to cartridges. Nevertheless, some did slip through
When it came time to create videos for DMCTI, we couldn't resist adding an appropriately themed Easter egg to the software -- one that would add a little levity to the training. One of the scenarios involved a missing Humvee, so we decided that it had not in fact "gone missing" but had instead been abducted by aliens. We rendered a movie (which we won't show here) of the UFO flying up to a vehicle on a dark road at night and "beaming it up" before zooming away. It was hilarious.

Modern publishers and clients are more accepting of the practice of incorporating Easter eggs into products. However, they do expect to be notified of their existence. And that's perfectly reasonable. We had a formal meeting to discuss this with our Army representatives, explaining the meaning of Easter eggs and then showing the specific one we'd designed for the game.

They saw that it was indeed tasteful, appropriate and even integrated into the story, so they approved it.

The last scenario was designed to be the true test of the trainee’s ability. It involved sending multiple classes of supply from multiple supply ports to a forward base. But there was an extra twist: the obvious and simplest solution wouldn’t work, because it would disrupt convoys going elsewhere and get the goods to the base too late. A very careful reading of the mission orders was required in order to discover the proper solution.

We sat down in a conference room at ICT headquarters with our Army SME and the main Army procurement officer. We set a laptop in front of them with the final scenario set up, and walked them through the briefing. Forty-five minutes later, they had worked out a plan that they proudly announced would break our scenario. Great job, team. We then had them start the real-time simulation. Two simulated days later, they got a big, red error box – the necessary supplies had not been delivered when needed. They flunked! They were shocked, until we explained their mistake: they’d misread the reports and sent the right stuff to the right place on the wrong day, falling right into the trap that we’d set for them.

They approved the final milestone with no changes.

DMCTI won the 2008 Army Modeling and Simulation Award for Training. In its announcement, the US Army said:

"The Training Modeling and Simulation Award for 2008 is awarded to the Distribution Management Cognitive Trainer Project Team. The Team is commended for developing a Personal Computer, game-based training tool, that is being used to train US Army logistical planners on exploiting the capabilities of the Battle Command Sustainment Support System, the capabilities of logistics information management systems, and training the key principals of Distribution Management to improve the analysis, mission planning, and decision making skills of tomorrow’s logistical leaders.

"This effort demonstrated how to effectively design, develop, and use game technology to enhance training opportunities for Soldiers. It has been successfully integrated into formal Distribution Management training courses and was fielded to Battle Command Sustainment Support System users Army-wide beginning in 2008. The project demonstrates that modeling and simulation tools can be used to support training in institutional, operational, and self-development domains. The efforts of the Distribution Management Cognitive Trainer Project Team reflects great credit on themselves, RDECOM Simulation & Training Technology Center, and the United States Army."


Coming Up Next: Chapter 9 – Going Mobile

While our Army work was going strong, we also realized that a major new technology was reaching the public and would have a dramatic effect on game development. We decided that it was time to enter the mobile game market.



This is not for human consumption.
Quicksilver Software has long been involved in military product development, although that information has largely been hidden due to the highly classified nature of the company's work. Beginning in the early 1950s, Quicksilver's crack teams of military strategists were hard at work creating sophisticated space combat simulations and managing large-scale wargaming projects for the Department of Defense. The company maintains a significant although virtually invisible presence inside the Beltway in Washington, D.C.

Looking For a Top-Notch Team to Solve Your Impossible Problem?

Let’s talk! We love to take on new challenges. Tell us what you need and we’ll let you know how we can help.

You can reach us here: https://www.quicksilver.com/contact.html#contact.


For more information:

You can find us on the Web at www.quicksilver.com.