fbpx
Performance Check

Technical Debt Applications for Tabletop Games

I’ve been in the IT (Information Technology, not Inter-Dimensional Monster Clown) industry for quite some time. Over that period, I’ve worked as a technician, engineer, project manager, program manager, technical supervisor, and operations manager. I’ve had a hand in some pretty big stuff – a thing I can’t talk about but “involves space,” a certain computer being on a gameshow, creating some code that made the internet better, and a lot of boring stuff to people not in the industry. At the same time, I’ve been playing tabletop games for a almost a decade longer than I’ve been in the industry – video games even longer than that. The IT industry has a gulf between the various components that comprise it. People believe t if something relates to software, it can’t possibly relate to anything else. Tabletop games and technical debt can’t coexist, right?

While the industry continues to try evolve past this silly idea – and it is very silly – I have been thinking about how many thing have developed as part of the IT industry that apply to other areas and mediums, but never get spread outside of the industry because – outside of the people doing TED talks – we tend to focus on whatever our products will do – over-hyping the impact it will actually have on the greater world – rather than what we are doing to get there. As a brief aside, IT people either hate or love Silicon Valley for showing the rest of the world exactly what the industry is like – I’m on the love side. This is a shame, because so much of software and hardware design is applicable to all design – tabletop games included. One of the most important of which is the concept of technical debt.

What is Technical Debt?

Technical debt is the cost of future effort for the work that you are currently doing. Successful companies implement software or hardware debt incurred 10-30% technical debt (of the total segment time) for any given segment of work (generally between 1-4 weeks). If your technical debt is consistently 30%, every three segments of work would generate a complete segment of work that could be wholly consumed by addressing the technical debt (not that you necessarily do that.) Like monetary debt, interest accrues.

The longer the technical debt goes unaddressed, the larger the debt grows. If the debt goes unaddressed through twelve segments, the scope of the technical debt is massive and unwieldy. The smaller the segment of work, the more likely the technical debt is deliberate. The opposite is to true for longer segments of work. This is unintuitive, at first glance. More time to work means you make better decisions, right? Not necessarily. A longer time period is more likely to result in changes to the original scope being made. The scope changes create additional work in need of definition. Smaller segments result in more flexibility – everything being equal.

Gaining Technical Debt

Technical debt accumulates in myriad ways. In most business environments, business pressure and last minute specification changes are the obvious culprits. Close behind these two are an inadequate scope or definition of work. The fun doesn’t stop there. No or poor documentation, no or poor collaboration, insufficient knowledge or skill, no framework or standards, lack of testing,lack of rework, too many dependencies, and parallel development contribute to technical debt. These last two directly impact  play during the lifespan of most games. The others are no less important – the order of importance is about the same – but these two are witnessed by players and DMs alike. Third edition feats and the various UAs all spring to mind. Not to mention the copious amounts of race versions released (here are the ultra-true versions of giants, honest!)

Tabletop Application

While the term is technical debt, it refers to any sort of creation or design process. In tabletop games, the game system and the games being run within the system both qualify. These are creative processes requiring design. This isn’t just referring to the initial outlay of the idea. It refers to continuous integration and continuous delivery after release – splat books expansions, and so forth. This is about the nitty-gritty of arcs and the session-to-session play on top of overall campaign and rules design. These are discrete instances to investigate in order to see illustrate how technical debt plays out on macro and micro levels. In doing so we will look at the following – all of which build upon each other to depict technical debt in action:

  1. Rule Design: 5e Ranger
  2. World Design
  3. Arc Design
  4. Session Design

The Debt of the 5E Ranger

If you know me or have read my work here in depth, you know I have some…strong feelings on rangers and their themes. Ranger is one of the 5e classes to only have two archetypes presented for it in the Player’s Handbook, and the only one to not  have a theme to go along with it.

Barbarian isn’t far behind in this regard, but their thematic presentation is still much better – ancestor/spirit worship vs. berserker. Bard only has two, but it presents the concept of bardic colleges and strongly differentiates between the two implementations. Druid struggles a bit, though the “cleric of the land” and “shapeshifter” themes at least come with the idea of a council and group dynamic through the inclusion of circles. Sorcerer only has two archetypes, but their theme is crystal clear – carriers of magical bloodlines with a born ability to shape magic. Ranger is in a much worse state.

Ranger People, Ranger Problems

Rangers have almost no thematic ties to the rest of the game. The lore presented encourages a ranger to remain somewhat separate from the adventuring party. The archetypes presented for them are “weapon-focused” and “I have a pet.” Even in the under-represented classes, this is a stark example of lack of theme. The “weapon-focused” archetype encourages you to be good at only one style of combat, though you could mix it up if you used rapier, I guess.

The theme is just the tip of the iceberg. The paladin is the other hybrid in the initial book release. The paladin’s theme is incredible clear – holy warriors with unbroken sacred oaths. Their class features do a lot of heavy lifting on a thematic and strength level – auras, divine smite, and their spells are both effective and communicate the core class theme. Compare this to the ranger.

Specific Issues

Favored enemy still exists, but the previous strength and iterations of it – coupled with the “racist class feature” nature of it – sees a reduction in importance and potency. Natural Explorer is a great concept, but it doesn’t jive well with the way the 5e skill system is presented. Primeval Awareness is the signature core feature in the way divine smite is for paladins. It’s massively unwieldy, and even a cursory glance at it reveals the issues with it (see the links above for too much discussion on this point.) The top end vacillates between magical and non-magical feature presentation, with abilities either modifying lower abilities or outright replacing them.

This is to say nothing of a lack of strong theme through their spells list – outside of them all being “hunting related.” A full line of trap spells, a greater emphasis on the “arrow spells,” or even some group buff-type stuff we see out of paladin would have gone a long way to filling that gap.

5e Ranger 2.0

This is not a whinefest about the class. This highlights how the issues here affect everything else. A few things are evident here from a technical debt standpoint. It is clear there is a lack of framework or standards being applied here. Look at paladin, in contrast. The team was undeniably up against a release date. There is pressure to ensure something is available for publishing, and the scope of the work for ranger is incredibly ill-defined. What is the ranger supposed to look like? Uhhhhmmm? Right. This is all technical debt. It is clear that ranger is underwhelming and is in need of some serious help to complete. Let’s call this a lack of rework.There is a strong case to make for all of this, as we did get a rework of ranger.

It is a bottom-up rebuild that also included lore and a world-hooks. This new implementation is also in need of feedback and iteration, increasing the technical debt of this specific presentation. The rework time of this version is much faster, presenting a further released version in a very playable – though still incomplete – state. Unfortunately, this causes another issue to raise its head – parallel design.

Rework Debt

There was a lot of work done on a lot of fronts to “fix” the issues with ranger through archetypes, spells, and other means. That work requires reconciliation with the new version of ranger in order to remain valid. At the same time, new development needs to either hinge upon this reworked class, stay tied to the initial version, or account for both. Organized play has a core+1 rule for books, meaning it’s entirely possible for the revised ranger to fall out of legal play. WotC addresses this concern or not. This sets a precedent for this sort of action either way. I don’t know is this has occurred. I am just pointing out it’s additional work and debt to then accrue.

Magical, Mystery Debt

We now have a situation where something like ranger poses a serious problem. Will the world be able to support the core functionality of the class? Do you address the problems of the class? If the world is a desert hellscape in 90% of the land, Natural Explorer is diminished. Favored enemy plays an important role. This is to say nothing of the fact Primeval Awareness is going to require the world to be fully fleshed out due to the size it covers. Underdark, I’m looking at you, here. You need to worry about not only the core implementation of ranger, but also the alternate version of ranger. Is either version allowed, just one, or both? This is still in flux, and any further rework of paying down of the technical debt impacts this decision.

This might seem myopic, but let’s think of it from a perspective of world mysteries for a moment. In Everquest, the leader of the Freeport militia – the warrior guards of the city – is Sir Lucan D’Lere. A use of the detect undead spell causes you to face him, but the code in the game is unreliable so no one thought anything of it. Once people level up and epic weapons (class specific weapons of great power that you quested for) become a focus, Sir Lucan D’Lere turns out to actually be a death knight. This snaps  a lot of the storylines into focus and alters the story of what is going on in the city. Instead of being something subject to discussion and discovery within the game world, the assumption is the technical debt of the game is so high this is just a bug.

Imagine this from the perspective of the ranger.

Ranger Debt in Action

Rangers stand next to Sir Lucky, and pop their Primeval Awareness. Instead of knowing, “hey, this guy is undead or something weird is going on,” you know “something within one or six miles of me is undead.” This isn’t to further slam the uselessness of the skill, but illustrates how technical debt compounds. Instead of being allowed to know something weird is going on, the class feature tells the ranger nothing, shifting the onus to the DM to present that information correctly.

If the DM isn’t able to get the information across in a natural, digestible way, the reveal of Lucky DL as a death knight is going to be met with frustration. The players cannot make informed decisions on the matter, it is because of the lack of integrated design. The party laments their lack of paladin, instead. The previous technical debt impact the mystery presentation and solution. It compounds because of the flailing mystery and frustration. This is an oversimplified example, but hopefully it illustrates the point sufficiently.

World design establishes hooks the players can investigate. There’s a skull-shaped mountain the north! If you don’t know what’s in the mountain, you kick that can down the road until such time as it becomes important. Once you do so, everything you pitch about the world directly impacts what is in the mountain. If you continue to build the mystery, it matters even more. This is debt needing resolution prior to the mountain being actually important to the story. Otherwise you end up with a product that is half-formed and ill-defined. It’s the same thing.

The Story Burden of Technical Debt

This directly translates to the handling of story arcs. Using the case of Sir Lucan D’Lere, let’s look at how this might resolve. The players work for or against the Freeport militia. If they work for them, the DM’s goal is to initiate a reveal of them as the villains, and cause a faction or alignment swap from the players. If they work against them, the DM’s goal is to allow the players to discover the underlying cause of the motivations, and remove the militia from power. World design impacts the presented mystery and the rules design above it. The arc story builds around the gaps in the previous design areas in order to meet your needs. Previous technical debt limits the mystery solutions, placing business pressure on the DM.

The DM ensures the arc is solvable by the players in a way that is in tune with their skills and characterization. The DM also ensures the mystery doesn’t club them over the head. The blunting of the tools at the player’s’ disposal requires different resolution presentation. Notes, conversations, context clues, investigations, etc. all build upon the initial mystery. This isn’t a bad thing, necessarily.

Initial design issues trickle down to the arc planning level. This is a lot more work for the DM, and the DM has to come up against the very real deadline of running the action game – to say nothing about successful presentation of content. It’s great to plan for a pile of text props, secret conversations, and clues, but missing some of that is likely in the pressure of the deadline unless it is your full-time job. Perfection is fleeting, is what I am saying.

The Game to Game Impact of Technical Debt

This all directly impacts what you are going to need to do on a session by session basis. All of the above mystery parts will be important to driving the story, but it’s going to be the actions in a session that actually drive it. In order to get the arc completed, the clues and information provided need to be fully given out and need the time to be contextualized by the players. To do otherwise is to rush the arc and will result in an unsatisfactory product.

It’s very hard to present a mystery in a satisfactory manner already, and if the players feel at all lead or as if they got a “gimme” from the DM, it sours the taste. It’s a careful balance between giving the players exactly what they need and being withholding to let the players initiate it. When the sessions have a limited time frame – let’s call this business pressure again – something different becomes a concern – the pacing of the individual sessions.

Our Lamentations

Despite all of our best efforts, we are mortal creatures with limited time. A session might run from two hours to seven hours, but eventually the session comes to an end. There is no telling if every point of the DM’s outline is going to be met in a given session. Assuming for a second that the outline is over ambitious, it creates a circumstance where the next session needs to account for that elongated schedule and move things along at a faster rate for initial arc plan adherence.

This creates a situation where a compressed session timeline can easily result in a lack of understanding of scope or lack of planning/knowledge situation. Either the scope creeps to encompass more story and view, or it shrinks in order to get back onto the initial timeline. The players face the truncation of their planning and discovery phases, and their reactions are subsequently impacted. It easily creates a session where it feels like the players didn’t get to do a lot, and the world zooms along without them, if the DM isn’t careful. Not the most ideal circumstances, to be sure.

Putting a Bow on It

This isn’t to say that the above is bad. Sometimes technical debt isn’t a bad thing. However, it is indisputably a real thing. The initial decisions around something like ranger impact every design stage afterwards because of the debt accrued in just that design segment. That’s not even accounting for the other areas of technical debt for a more macro look at the total technical debt. This paying down of initial debt is possible- stuff like UA and additional books are an attempt at doing just that – but when the monetization of debt for the consumer is a very different situation. It’s completely understandable, but that’s how we get into the greater world of splat books, DLC, season passes, homebrew, and expansions.

We will never get away from technical debt, but it is possible to get closer to a position where we have less technical debt. A lot of this depends on a good, accessible tool for tabletop games in general. D&D Beyond is not that tool, but it’s a step in the right direction. Digital media is a way to get continuously improved design into the hands of content creators and players. Unfortunately, we are still a long way off from seeing it realized.