We hope you have enjoyed this series and that it gives you a clear picture into how Arjuna works. In this installment, we will wrap up the session with some suggestions on how to lay out your play area, a brief set of Arjuna design notes, and a peek into the development process of Arjuna, complete with some pictures of older versions of the system.

One of the fun parts of being involved in a game’s development is the journey from a rough, usable prototype to a final product. This journey involves more than just artwork and proofreading; the game’s story is usually the main object of refinement. For Gandhi this journey was longer, and more dramatic, than for the other games I have worked on – Gandhi didn’t even begin as a COIN series title, rather as an entry to the 2015 Boardgamegeek Solitaire Print and Play Contest. At the time Gandhi was called Hind Swaraj (meaning “Home Rule”), and as you can see, it was a very different game:

At this time there were only three factions in the game; the Revolutionaries were added later to make sure the narrative included the violent nationalist insurgency that was happening alongside and underneath the more broadly recognized Nonviolent movements. Even this early on, several ideas that would end up in the final game are recognizable:

• Hindu/Muslim Unity would end up becoming the Unity track in Gandhi.
• Semi-independent Princely States limit the Raj’s operational ability.
• “Focus” markers can be placed to change stacking rules at the cost of Raj having more freedom – these would eventually become Protest markers.
• Activists are arrested and placed into Jail.

As this basic design evolved, challenges emerged in crafting the narrative that Bruce wanted players to experience, eventually evolving the game into a traditional 4-player COIN series title. Yet, at its heart, Gandhi never lost its roots as a Solitaire game. We wanted Gandhi to have a different type of Solitaire experience, and that was baked into the design across its 4 year development process. One way this is reflected is in the Event deck. We did not finalize the Events until after the Non-player system was complete, allowing us to reword the Events to maximize playability. Usually this just involved adding some clarifying words to an Event, or changing or removing an option, or making sure that an Event was very specifically “up to” a number of spaces. But, sometimes Events were really hard for a Non-player Faction to execute so they were removed. It turns out, usually these Events were hard for players to use too!

When we actually began designing Arjuna, it became clear that the existing COIN flowcharts are a monumental achievement. It is excruciatingly difficult to make a pen and paper AI that is capable of playing a game like Andean Abyss or Fire in the Lake. My hat goes off to Örjan Ariander, Vesa Arponen, and of course Volko, for their groundbreaking work here. Yet, with Gandhi’s Solitaire roots, we hoped to be able to make something that was understandable visually and intuitively, instead of requiring players to parse technical conditions. At the outset, it wasn’t clear that this was actually possible, but there were a few key moments that enabled our project to succeed.

Early versions of Arjuna used the same basic form and structure as the flowcharts, but randomized the entry point in the flowchart using cards. Here’s an example card from an early prototype of Arjuna:

Some of the things that became the hallmarks of the final Arjuna system are already in place here:

• Each card is two-sided, and is flipped with a simple check.
• Whether the card is executed is decided by second, simple check.
• Raj and Revolutionaries use Activation Numbers, not Resources.
• Each Operation specifies priorities to use when executing it.

There are also many differences:

• Arjuna uses 6 cards per Faction instead of one card controlling all Factions. This allowed a Faction’s Operations and Special Activities to be interwoven for greater effect.
• Arjuna may choose to execute a given Operation one of multiple Special Activities, depending on the checks; in these older cards, there was a max of two checks (Arjuna cards can have as many as 4) so there was less flexibility.
• Arjuna uses the priorities (circled numbers) to direct players in which option to take when an Operation or Special Activity can be executed multiple ways. These old cards used the priorities to override the Space Selection logic, which was unnecessary and complex.
• Arjuna cards always start on their front side, flipping to their back temporarily. These older cards stayed flipped until the check on their back passed, flipping them over again. This made it difficult to predict how the NP would handle some board states and was simplified to make sure that certain situations were handled correctly.

Executing an Operation required space selection priorities, which were on their own chart. As an example, let’s pretend that INC is executing Demonstrate per card FF above; here’s the chart they would use:

This is pretty difficult to parse, but the logic is actually very similar to what Arjuna uses now. The major difference is that Arjuna uses a visual presentation of the instructions, and the selection of origin and destination spaces has been separated into multiple charts. Additionally, we found that a lot of Operations and Special Activities had to contain duplicated logic. For example, Raj Assault, Treaty, Govern, and Martial Law all remove Adversary pieces. By unifying the logic that selected the spaces for these actions into one column in the Space Selection table, we were able to reduce the amount of instruction we needed to give to players, and have Arjuna act more consistently.

We are very pleased with the end result:

• Arjuna does not need an Event table to resolve Events, relying instead on a chart to determine if the Event is effective, and the Space Selection tables to execute the Event.
• All four Factions have their Space Selection and Move Priorities tables inside a single foldout player aid.
• The card-driven system trades off ideal play with ease of use to create an opponent that is still challenging, but avoids deeply-nested decision trees.
• The components take up a small amount of table space and are easy to reference as needed.

Let me expand on that last bullet briefly. Here is my setup at home, midway through the first Campaign of Gandhi. I am playing as the Revolutionaries against 3 Arjuna-controlled Non-players (excuse the clutter to the side):

As you can see, I have my Arjuna deck next to the board, within easy reach, as well as my player aids and rulebooks, and a half GMT counter tray holding my counters. I find this to be a near-ideal setup. I use the pawns to mark spaces for the NP Factions while working through the Space Selection tables, when there are many possibilities. Once I am resolving an NP Faction, the card is in an easy place for me to reference it while looking through the tables. My preferred setup is to place the Campaign reference inside the NP Foldout, inside the Faction Foldout, which looks something like this:

Not only does this make it easy for me to find all the things I need when activating an NP Faction, but I can use the Campaign reference as a guide when I am reading down Space Selection columns, like so (in this example, I am reading down the Congress’ Remove or Replace column):

I find this to require a minimal amount of extra table space and to be ergonomically pleasing as well as easy to use. I hope you can find a similar setup that works for you!

Wrapping up this series – Bruce, Scott and I are thankful that Gandhi has been embraced enthusiastically by new and old COIN fans. The Arjuna system was a labor of love, and something we are very proud of; one question that is consistently asked is whether there are plans to backport this system to older COIN titles. A few things make that difficult:

• Many of the features of other COIN titles (Pivotal Events, Battle Systems) are not present in Gandhi and additional design work would need to be done to handle those.
• The Events as written require extensive additional instructions for NP Factions, and are not written to be resolved by an Arjuna like system.
• Some COIN titles have significantly higher complexity in the execution of their Operations.

That said, we are open to the idea and actively experimenting with using similar systems with other COIN titles. If you are interested in adapting Arjuna to a COIN Series title, and have some experience with game design, please reach out to me and let me know, as I am happy to help.

Thanks for reading!

---

Previous Article in this Series: The Arjuna Chronicles #10: Independence Day Defiantly Declared