Inside GMT One: Behind the Design of Tru’ng

This month we wrapped up design work on the bots for Fall of Saigon, the upcoming expansion to Fire in the Lake. This seemed like a good moment to reflect on the journey that it took to get to this point and share some of the things we’ve learned along the way. This is definitely not the end of the road – more card-based COIN bots are coming – but it’s a good point for reflection. The card-based bot system used in Tru’ng does not originate with Fire in the Lake, but is an offshoot of Bruce’s work on Gandhi (the card based system in All Bridges Burning is unrelated to Tru’ng and Arjuna, and was developed by VPJ Arponen specifically for ABB). When Volko asked Bruce to make card-based bots for Fall of Saigon, we knew that we would have to evolve the system to accommodate the increased complexity in Fire in the Lake. After all, we couldn’t make bots that could play Fall of Saigon unless they could also play Fire in the Lake. Originally, the system used in Tru’ng and Gandhi’s Arjuna bot was called the “COIN Card Driven Solitaire System'” or “COIN CDSS.” This was a descriptive, but stupid, name. GMT One developer Joe Dewhurst suggested a different name: Jacquard, after the Jacquard loom. The Jacquard loom was a programmable mechanical loom that used a series of punched cards to enable automated production of textiles. These punched cards inspired Charles Babbage when he was designing the first mechanical computer, and punchcards were used to program computers as late as the 1980s. Since our cards in Arjuna and Tru’ng enable an automated opponent, the name was appropriate. The Jacquard system was designed according to a few principles (these will be familiar to regular Inside GMT readers). These are hierarchical – in any area where one of the principles contradicts another one, we give greater priority to the one listed first:
  1. We value the Intent of the Designer over Enhancement of the Solitaire system. At the end of the day, the design of the Solitaire system is, itself, part of the design of the game. Therefore, we will not retrofit a game unless the designer is eager to see a new system in their game and willing to support the design and development of the system. For Fire in the Lake, we had Volko’s help in understanding what the core elements of the model were and how he envisioned them interacting.
  1. We value Usability over Perfect Play. We do not seek to design an opponent that will take advantage of every mistake a player makes, but rather seek to provide a competitive and appropriately difficult opponent that, generally, follows the rules of the game. We also strive to keep the system ergonomically simple to reduce tedium. For example, all cards can be held comfortably in one hand and the most important charts fit on the inside of a foldout PAC, limiting the need to flip back and forth between various components.
  2. We value Clarity over Thoroughness. No system can account for every situation, so we seek to provide clear processes to handle the unaccounted for (e.g. “Choose Randomly” by a given method, “Discard this card and draw another”, etc.). We use the fewest possible steps for each procedure, separate different types of procedures into discrete steps (e.g., “which action?” is separate from “where execute that action?”), and rely on random selection to the least extent possible.
  3. We value Simplicity over Cleverness. We would rather have a system that follows the existing rules of the game rather than create many new rules, but we will prefer Usability over Simplicity when the two are in conflict. For example, Arjuna does not require a separate sheet of instructions for implementing Events; this was eliminated to speed play. In Tru’ng, we needed this list of instructions because it would have been less usable for players to not have these instructions.
Whether you play solo or are just down a player or two, we want to make sure that the game is still an enjoyable experience, and that the narrative beats of the game come through. At GMT One, we feel this is the core reason that people play solitaire games. Cole Wehrle, the designer of Leder Games’ Root, summarizes what we think solo players want:
I thought they wanted a little friction box, and you could see how well you could push against it…I realized that what they wanted was for the game to tell a compelling story and still have a kind of narrative logic, even if they were down a player.
Our goal is to provide that narrative logic and compelling story, and we think that these principles are the best way to that kind of experience. Let’s look at one way these priorities play out – the space selection tables for the NVA bot. Our first priority was to make sure that Volko and Mark were aligned with our principles. We learned a lot from Volko and Mark – from showing them the bots at the GMT Warehouse, to many phone calls, they were invaluable in helping us understand what the NVA should do. But more than that, they were in agreement with the general approach that was being taken for the project, which was a very important part of the design. So next we prioritized usability. There are several ways that usability comes through in these tables:
  • This table is used for one thing – selecting spaces – but it is used for selecting spaces in almost every case where the bots select a space.
  • One table is used for each faction, but no more than one table.
  • The information is presented visually where possible, and uses color to emphasize conditionals.
  • There is information encoded in the ordering of the columns which can be used to prioritize an action when an event would allow a choice between two columns.
  • The final two rows provide convenient reminders to players of universal rules of the system.
  • The columns present categories of action rather than specific Operations or Special Activities, making them reusable and reducing the number of columns.
  • All space selection is presented on a single player aid card, visible at the same time.
But notice the second half of that value statement: “over Perfect Play” – while these tables are great, they have a major limitation. The rows are in the same order for every action. Why does that matter? It means that the granular control that could be afforded by having a different column for every different option of each specific operation or special activity is missing. Generally, the top condition of each column quickly narrows down the list of options, and the later rows select from among a few options. However, this can lead to suboptimal choices when the top few options don’t narrow down the choices, or are skipped entirely. We feel that the tradeoff of usability from these charts outweighs the fact that sometimes the bot does something silly (players have also been known to do this on occasion). No solo system will ever be able to emulate a player perfectly, but we hope that playing solo with Tru’ng, or adding Tru’ng to a multiplayer game lets you experience the narrative journey of Fire in the Lake in a satisfying way. And I hope this article has showed some of the tradeoffs that go into the design of a system like Tru’ng, and what to expect with Jacquard bots in the future. People Power and China’s War will both use the Jacquard system, and we have some other things to announce, soon. Next time on Inside GMT One, the Jacquard system developer Kevin Crooks will outline the challenges of evolving Tru’ng for Fall of Saigon.
Previous Articles: Inside GMT One: What’s Next for Fields of Fire? Inside GMT One: Solo Play in Red Flag Over Paris
Jason Carr
Author: Jason Carr

Please note: I reserve the right to delete comments that are offensive or off-topic.

We'd love to hear from you! Please take a minute to share your comments.