What is Complexity?

Quite a question to answer, so I will talk about my experience.

Me and my friends wanted to play a Pokemon Tabletop RPG, and we chose Pokemon Tabletop United (PTU for short). This game is fun and crunchy. Crunchy, for me, is when you need to spend some time doing math, cross-referencing rules, and double-checking character stat sheets during or before play. And my friends didn’t especially like crunching numbers during sessions, so the game ended up losing popularity in our playgroup.

Complexity for us didn’t do much, so I took on the task of attempting to simplify the game.

In more abstract terms, It sort of works like a scale, the more and more complex math you need to do during your playing session and the more mechanics and conditions you need to keep track of, the crunchier the game becomes. If in a given system, I need to add up four different situational bonuses to roll a hit, then that system is crunchier than one where I need to roll a single die with just one static bonus.

As an example, Powered By the Apocalypse games have a little crunch. Shadowrun is crunchy. Dungeons & Dragons 3.5e is crunchier than 5th Edition and Pokemon Tabletop United is crunchier than the version I wrote.

My process started with suggestions I had been piling up in my head. Those ended up as whole cuts and changes to the original game and in the following sections I will go over the most relevant, detailing the thought process behind my decisions.

Divided by 5

This was the kickoff change.

The game is about Pokemon, and the Pokemon in the original videogames level up from level 1 to 100. This means that if I were to adapt Pokemon to a d20 system, it would make sense to develop a d20 system and then multiply it by 5, then everything looks one-hundred-ish. And that is how the game looks, most numbers are around multiples of five.

This may or may not be the way the developers designed the game, but it’s a pattern I noticed in the design.

The smallest bonus you generally get in PTU is a +5. Although there are some exceptions, I think it’s safe to call the +5 a unit, as the other bonuses were also generally multiples of five.

But handling bigger numbers is generally harder than handling smaller ones. Adding up 1 + 2 + 1 is faster than adding 5 + 9 + 4. So I had to reduce the number’s magnitude.

Divide by 5 to the closest and we get a smaller, easy-to-handle, bonus.

Damage Base

In the same vein, I removed what in the game is called a Damage Base.

Next to each pokemon attack (Move) there is a number, called Damage Base, which can be referenced in a chart, where it also tells you how many dice you would roll when using that Move. Why the redundancy? Well because there are bonuses and penalties to the Damage Base.

Instead of rolling additional dice, you get a +1 to the Damage Base, go to the chart, and then get the new dice you need to roll.

At first, I removed all bonuses to the Damage Base. So we players no longer need to check the chart to see how many dice they need to roll. Then realized that players don’t even need to know the Damage Base exists.

So I kind of kept it as a design tool only and used it to balance and compare Moves with similar power. No abilities or features alter Damage Base anymore, they let you roll additional dice. And Moves now only list the number of dice the player should roll, if any.

Injury System

The game has a secondary health point system. If any Pokemon were to accrue enough injuries, independently of their HP, they faint. Injuries heal at a different rate than HP and are acquired by meeting different conditions, like receiving heavy blows.

Injuries also reduce the pokemon’s maximum HP. So a pokemon with healing abilities would eventually get so many injuries that it’d make it’d be impossible for them to heal up enough to sustain the damage they are taking. So it worked as sort of a countermeasure to recovery strategies.

I took a different approach. I removed injuries and tried to handle recovery strategies by limiting them through the Moves Frequency mechanic.

Moves have a Frequency, they can be used a number of times at different intervals. At-will can be used freely, scene moves can be used a number of times per fight, and daily moves a number of times per day. Healing moves fall generally under the daily category because they influence HP, which is a resource restored by resting.

So I made the compromise of removing the Injury system but, in consequence, I had to be extra careful with the number of uses allowed for healing moves.

Volatile and Situational vs Static and Significant

This is the nomenclature I came up with for a design pattern I noticed.

There are a lot of sources for Bonuses in PTU: Moves, equipment, consumables, food, abilities, features, and edges. And… I think that’s it, but I might be missing a few. The complex part is not specifically the number of sources, it’s the fact that they only last for a certain amount of time or that they might be active due to certain criteria being met. And multiple of them could be active or inactive at the same time, making the players tweak the numbers every turn. This is what it means for a bonus to be volatile (disappears quickly) and situational (is not always active).

And to reduce complexity, we can reduce the amount of headspace required by the players. Using a lot of headspace means that the player is trying to keep track of all of these situational bonuses and penalties, while trying to remember when to apply them and when they expire. This takes up space in their minds, which might be fun for some players, but attention does not necessarily lead to interesting decisions. And we had situations where our players forgot to add that additional “+2” and felt bad because of it.

So I took a few pages from Dungeons & Dragons 5th edition, and Bonuses are now only static or significant. 

Static bonuses make you work up-front, so they are good at streamlining gameplay. A static bonus doesn’t vary or change during play. So by adding more of these, the game would still need some prep work. But during playtime, players would just need to reference the numbers they pre-recalculated and roll dice.

The other method is making bonuses significant. You can increase significance by turning the bonus number into an action, like rolling a die or making a decision. The Advantage and Disadvantage mechanic is an example of significant bonuses in dungeons and dragons.

Advantage and Disadvantage
Characters rolling with either Advantage and Disadvantage roll two twenty sided dice when taking the affected action. If they have Advantage, they pick the highest roll of the two. If they have Disadvantage, they pick the lowest.

You can also make bonuses significant by making them Unique. But uniqueness is a compromise. If there is only one ability that increases your damage in the whole game, players will remember it. But that means that designers cannot include any other bonus that affects the same types of rolls. An example of this is the Bless spell in Dungeons and Dragons.

Bless is a volatile but unique bonus, It lasts only one minute or until the caster breaks their Concentration. And it reads:

You bless up to three creatures of your choice within range. Whenever a target makes an attack roll or a saving throw before the spell ends, the target can roll a d4 and add the number rolled to the attack roll or saving throw.

This means that when they roll to attack or try to save, they roll a d20 + an additional d4. This bonus is unique because it’s the only bonus (that I‘m aware of) that applies to attack rolls, and it’s also significant because the player is rolling an additional die, they are taking physical action. And since this is the only bonus to attack, people roll a d20, add the static modifier and ask, do we have Bless?

These methods can, of course, backfire. Add too many “Significant” bonuses and players are rolling a ton of dice. Make your Unique bonuses trivial and they will forget about them. Static bonuses as well, if every time a player levels up, they need to recalculate all of their stats, then this alone might be cumbersome enough to deter them from playing.

So what did this mean for my version of PTU? It meant getting rid of volatile and situational bonuses and replacing them with significant and unique ones. Did I achieve that? Partially. I added an advantage system and that helped to get rid of the attack bonuses, but since I was trying to keep the amount of content the same, it meant that it was hard to ensure uniqueness, and I might not have achieved it. I could take one step forward by cutting content. There are a lot of Moves and Abilities, and they add uniqueness to the pokemon themselves, but also add complexity to the game.

Combat Stages, a Volatile System

Here is another compromise I had to make. One I’m not entirely satisfied with.

Combat stages are a core mechanic in the pokemon games, and PTU has most, if not all, of those mechanics in their rules, plus some extras (like injuries). They are not 1 to 1 translations, they are adaptations and pretty good ones at that. Combat stages in the pokemon games are multipliers to pokemon stats. Multiplication is a basic operation, but not the most basic. So I replaced the multiplication part with addition.

But combat stages vary throughout a battle. They are affected by Moves and abilities and features. They are volatile and, as established, hard to track. So I should remove it, right?

Well, here is the issue, Combat Stages is too much of a core mechanic of pokemon games, and I wanted to keep all of those in this adaptation. One solution was to turn the most important buff Moves into unique and iconic Buffs. Like Haste or Barkskin in D&D. But this meant cutting other moves, which is something I didn’t want to do.

So Combat Stages stayed. I’m pretty sure they are the only volatile bonus remaining (except for some abilities I failed to translate), and they are a core mechanic of the game, but still, it takes up headspace and makes the game a bit harder to play.

Complex Skills

Some RPGs have skills, they generally represent out-of-combat capabilities. Are you good at bartering? How much do you know about the world? If you try to be charming, what are your chances of actually succeeding? All of these are also represented in PTU.

Skills had some issues that increased the game’s complexity. They affected many things, not just out of combat abilities. An example would be that to calculate how many spaces a character could move on the board, they had to average their “athletics” and “acrobatics” skills together. Skills also influenced some other secondary stats, which should be ok, mostly, but the thing that affected complexity the most was Edges. Special abilities that were derived from skills.

Edges were small, unique, and flavorful abilities used to spice up a character.

Most Edges had an influence over combat, or you could also spend edges to level up a skill on a 1-to-1 basis. A player character acquired 4 edges at level 1 and 1 every other level thereafter. This meant that players had to make quite a few choices at the first level. And some others while leveling up. But there were two issues here. One is that they weren’t really impactful or powerful.

And this is, I believe, a common pattern in complex systems, where a character’s power level is actually a sum of tiny choices and bonuses.

The other issue lay with the other choice system. Features. On the levels you didn’t gain an edge, you earned a Feature. Features were more powerful, approximately twice as much, than an Edge. But to qualify for a Feature you generally had to meet some requirements. Those requirements came in the form of Skills, and they were pretty tight. This meant that you had to plan your skills, and thus your Edges, ahead of time if you wanted to hit the Features you liked, and that took some careful planning.

Even if it’s not playtime, planning time can be cumbersome as well. So how did I reduce it? I cut the Edges while turning the most iconic edges into Features.

On the other hand, the aforementioned Features were also grouped by Classes and you could take them, mostly, in whatever order you wanted. I removed that as well, classes are now more linear and offer fewer choices but the process is more streamlined.

Other changes

Attack Penalty

To put it simply, all moves had a penalty to their attack roll. It was, generally, -2. So I got rid of the penalty. I thought about increasing defense by +2 for everyone, but in the end, I just ditched it. Moves with higher penalties now roll with Disadvantage (roll twice, pick worse).

Tutor Points

Pokemon had these points that allowed them to learn extra moves and abilities outside of the ones they could learn by leveling up. I removed them. These points were a throttle to avoid players teaching too many of these to their pokemon, but there were already some other throttlers in place, in addition to these points. I had to be careful, but I thought I could do without them.

Ability Points

Another throttler. This time it’s for player characters. Some abilities were too powerful and had to be limited. To limit them, they spent Ability points so their usage weighed against other abilities. I removed the Ability Points and costs and decided to balance powers via the Frequency mechanic instead.

The bulk of the work

It went over every Feature, Ability, and Move in the game. Adapting it by applying the changes above. I kept the ones I couldn’t adapt listed in my notes. If you want to look for them yourself, they are volatile.

3 Pokemon per team

This is more of a house rule, but tracking all 6 pokemon per player was too much for us, so in my playgroup we limited it.

Summary

It was a long but fun project. It is not complete, but I learned a lot along the way. Sadly I never got to playtest it with my group. Someday I might, or, most likely, I’ll build a softer system from the ground up, making compromises on my own terms.

If you read this far, thank you for reading. I hope this has been insightful in learning about my creative process.

My version of the rules
Companion spreadsheet
Pokemon Tabletop United Official Site
Original Companion Spreadshet