Before we get in deep, I want to be super clear about what I can and can't do with a piece like this. First, I can't go into detail about the bot's operation. You won't be able to bash together a proto-bot based on what you read here today. All of that will come later. What I can do is offer you a little history about myself and solo games. I can tell you a little about the design philosophy that informs the bot's design and talk you through the basic framework of how the bot works. If that sounds like something worth your time, then read on!
My History with Bots
I am not a solo player. In fact, solo play is somewhat antithetical to both the kinds of designs I work on and my own tastes as a player. I don't find anything objectionable about them in general, it's just not the kind of play that fits into my diet as a gamer or my creative goals.
Having said that, why in the world would I commit to making so many games that feature solo modes?! Well, the cynical answer is that there is demand for it. We've all had game nights canceled last minute and the ability for one or two players to be able to sit down and still advance their Gloomhaven (or Oath) game is a welcome feature. I get that. I also know that finding and maintaining a gaming group is a hard thing. I (attempted) to be an avid 18xx player in small-town Indiana in the late 00s. If there was a platform for me to run trains against a halfway decent AI, I would have jumped at the opportunity. So the position of solo players as a community is one that I'm really sympathetic towards.
But those aren't good reasons to stretch a game's player count. Forget the sympathies and market incentives. We've only got so much time on this planet and even really successful projects only allow for so much design and development time. Why spend time on a solo mode at all? Oath could have been a 3-6 player game if I would have asked. I'm thankful to work at a company that would never pressure me to design a solo mode for a game that I think wouldn't benefit from it. By the same token, when I told Patrick and the team that I thought I could build a good solo mode for Oath, they were delighted.
While I'm not a solo player by nature or habit, I will admit a pretty deep curiosity about the design potentials of the space. I like working on solo engines. They offer me really different ways of thinking through design problems and it's nice to have a challenge. I wanted to build an Oath solo mode because it seemed like an interesting challenge.:strip_icc()/pic4252654.jpg)
I'll be the first to admit that my record here is decidedly mixed. John Company's solo mode has often been described as an academic exercise, and I wouldn't disagree with that sentiment. The first Mechanical Marquise bot (in the Riverfolk Expansion) is tough as nails and behaves more like an ambivalent friction generator than an opponent with a real mind. I read every single negative comment and review I could find on those designs and did my best to improve my practice.
The first step I took was to stop designing. When the time came to figure out what I wanted to put in Pax Pamir: Second Edition, I asked Ricky Royal to join the project, and offered to sit in only as a developer so I could watch him work. After he turned over his initial design, I put it through my own development practice and was able to cut the bot's overall complexity in half without—I think—losing much of what made it special. After that, I watched carefully the progress of Benjamin Schmauss's brilliant Better Bot Project and the internal development that we at Leder Games took them through (ably led by Marshall Britt). By the time Oath's design started taking off last summer, I felt ready to give solo design another shot.
Some Lessons and Core Principles
It's hard to boil that experience of that informal boot camp. I learned so much about the process and it's already influenced my own design practice even in the non-solo elements of game.
The key problem, I think, was that I had mixed up my priorities. When I was working on the Mechanical Marquise and the solo John Company scenario my objectives (from highest value to lowest) looked like this:
1. Simple/Fast to Resolve
2. Difficult
3. Flexible (can be used in a lot of scenarios)
4. Should Feel Like Playing a Game of Regular Root
5. Should Feel Like It Has a Mind
Obviously a good solo mode should have all of those things to some degree. But, after watching Benjamin and Ricky work on their projects, I went into the Oath bot with a very different set of priorities.
1. Should Tell a Good Story
2. Should Feel like it has a Mind
3. Should be Easy to Resolve
4. Should be Difficult/Impossible to Master
Oath is a very story-first design. Basically every mechanical system corresponds to a narrative logic. It's one of my favorite parts of the design. When I eavesdrop on playtesters or read session reports, I love how the game's events and systems bleed seamlessly into the stories people tell about their games. As I went into the Oath bot, I knew I wanted those same kinds of conversations to be possible. This meant designing a bot that engaged with the game's system in similar ways to a player.
Setting the Schedule
One of the first hurdles to the bot's design was figuring out exactly when I was going to have time to build it. My design process (like that of a lot of designers) is highly iterative. When the design is in the hottest periods of development, I expect to burn through a playtesting kit each week. That is, the game will get played 3 to 5 times from Monday to Thursday and then Friday I'll incorporate changes and then print off a fresh kit for the next week.
Oath has been no different. The game went through my usual long gestation of a couple years of concept iteration and loose testing. Once I found an approach that seemed strong enough, it got put through the same paces we put on Root.
Put bluntly, this development schema is not great for bot design. While a design is progressing, I want as few points of friction as possible. So I try to keep the concerns I might have about physical production at a minimum and try not to fall in love with any dependent systems. The design of a bot is the ultimate dependent system. It relies on the whole design to function. This means that it's basically the last thing I can start designing seriously. While it's possible to scout out general bot design strategies earlier in development, it's hard to know exactly how well they will work until the rest of the design is in place.
I think this is one reason why players often think of bot systems as being tacked on to multiplayer games. They basically always are. The key, I think, is giving the bot system enough time to really develop. That was probably my biggest mistake when it came to Root's Mechanical Marquise. My list of objectives was mostly informed by the design time that I knew I could direct towards the effort. Root was developed primarily from August 2017 to March 2018. The Bot was built sometime in the last three weeks or so of development. That's still a considerable amount of time, but because it happened to be located at the end of the to-do list, it meant that I didn't have time to let things simmer.
When we set up the development schedule for Oath, I tried my best to address this concern. Oath's primary development phases began in the late summer and have continued since. We had far more lead-up time compared to Root. My plan is to have the design and all content (excluding art) done by mid to late March. We'll have all of the art and usability testing done by early May.
There's still a lot of content to design, but the basic system is showing a lot of stability. Right before the campaign started I did my first proof-of-concept design on the bot which went well enough that I was comfortable marketing the game with it. This comfort was also possible because I knew I would have time and resources to direct to it. The bot design started properly about two weeks ago, and, in-between all of the Kickstarter work, I've been fleshing out that bot and will probably have it testing externally within a few weeks. With an early April deadline, that gives the team lots of time to iterate and adjust, and still give our editors and graphic designers ample time to work on its presentation and usability.
Okay, So What Does the Bot Look Like?
The solo and two player games of Oath use an automated player who takes the role of the Chancellor. This automated player is a little like Wakhan in Pamir in the sense that it is able to fight both external and internal threats.
In order to do that, I had to create a simple brain that rested on two systems. First, there is the strategic priority system. This system organizes the bot's options into four basic bot behaviors. Each turn, the player running the bot will run through a list of four questions which will determine the strategy the bot will take this turn::strip_icc()/pic5208534.jpg)
Order matters quite a bit. So if the bot lacks prestige (the first priority), it will try to fix that problem first.
Here we start running into some critical problems in the design. Oath is a huge game and it can be difficult enough for a human player to manage the different victory conditions, let alone a simple bot! To fix this, I'm creating four different behaviors for the second priority which is selected when the Bot lacks the Oath condition. These different behaviors serve double duty as when the bot is threatened by a player with a vision they will attempt to block it.
Already, you can see the blind spots starting to form in the bot's thinking. What if there are multiple players contenting for a vision? What if the Bot has plenty of victory points and doesn't need to hold to Oath and would win the game if they would block another player? Those are all great concerns, and I don't know the answer to them yet. In fact, finding those answers is the part of this project that I'm most excited about.
Let's talk about the second big system used in the bot. One of the things that make's Oath what it is are the thousands of card synergies that can exist in the game. It didn't take long for me to realize that these card powers were going to be out of the bot's reach. They simply created too many complicated judgment calls.
But, I wanted to give the bot access to some of the same powers and have it interact with the changing types of cards. This was done by bringing back an element of the design I had discarded from the core chassis months ago, the relationship track::strip_icc()/pic5208536.jpg)
Here's how it works. Each turn the bot will usually play a single card. The card is pulled off the top of the deck and played (if it's a vision, it's instead discarded and another is drawn). When a card is played, it will adjust the relationship track by advancing the matching suit on the “loved” side. Then the card is added to a site with capacity if possible (at the Chancellor's region first, then site's he rules, then anywhere).
As the bot plays cards and advances suit markers on the relationship track, it will effect how much income the bot takes during the first phase of it's turn. It will also effect it's popularity. Essentially the relationship track serves as a tableau of advisers.
Cards with Battle Plans behave a little differently. When they are played, players follow the red arrow from the suit matching the card to the first suit without a relationship. This suit marker is then placed on the hated track. The hated track grants combat advantages against cards of that suit. It essentially allows the bot to participate in the game's combat system and to develop a tactical profile.
How the Bot Grows
This may seem bit dryer than the usual game, and it is. But the bot still engages with a lot of the game's key systems and, critically, still “makes sense” within the game's world and as an opponent. Though simplicity hasn't dominated the bot's design, a lot had to get cut in order for it to be playable.
That brings me to the final element of the bot's design I want to talk about today: the bot's growth. While the bot doesn't interact with the powers on the game cards, it does have it's own deck. And, depending on what happens in the game, the bot will adapt to the next game. Mostly these are buffs and special powers, but they can be liabilities too.
Here I am greatly helped by the game's general structure. For instance, If the bot loses a game or two, it will start getting stronger. More like an invading horde. At this point, the bot will likely put itself in a position where it can remain in power for several games. In this instance, players will likely need to fight the bot on the grounds of prestige. If the empire is toppled from within, the bot will develop internal safeguards to the expensive of the warriors standing guard at the gates.
When I get further along, I'll talk more about that element of the game and how the bot makes offers of citizenship. But, for now I've got to get back to the work of design. If you've been wondering about how the bot plays, I hope this piece clears things up. I'm happy to answer any questions as well.
- Cole Wehrle
Find the original post and discussion on Board Game Geek.