One Billion Fighters or None

15 Jan, 2026

In a recent conversation over on Phlox’s, we were discussing what constitutes a “fighter” class in GLoG. The question was not just what features, but how they should be distributed. When does a fighter gain a second attack, if at all? Is four class features at template A too many? These feel like high-level, bottom-up design questions that are difficult (and, I’ll argue, foolish) to resolve in abstract.

My response to this kind of low-context question is always :itvariesbygame:, but I want to dig a little deeper into why.

What is a fighter?

To echo Wittgenstein, consider what we call “fighters.” What is common to them all? For those who have read their share of gloghacks, we might be able to conjure a list of features we associate with this category of classes. For example:

• Parry
• Extra Attack
• Bonus to-Hit
• Bonus HP
• Fighting Styles
• Techniques
• Notches
• Weapon Proficiency

Note that I have already included more features than many classes contain, but this list could go on and on. We could imagine any number of classes that bear what Wittgenstein would call a “family resemblance” — each having many but not all of these class features. We could imagine some minimal fighters:

Some of these classes are likely more engaging than others, but we could combine any number of sets of fighterly features from our indeterminately long list. Critically, there is no feature that appears in every fighter, nothing common to all. “Fighter-ness” is not a cleanly definable category.

So, if you ask me “does a fighter work like this?”, the answer is always yes.

But Vivanter...

I can imagine two clear objections at this juncture:

First, I’ve already acknowledged that some fighters we might generate in our Wittgensteinian game might be better to play than others. Very true. Could it be that a fighter that is “better written” is more of a fighter?

Well, no. A fighter might be a great fit for your specific design, but there is no sense in which that fighter might be generally applicable. My design may have different concerns than yours. This is not just a question of balance, but artistic intent. When you add features to a class, you are describing what that type of character is like in your world, writing mechanical poetry. Refine your query!

Second, this is all awfully abstract. There is a concrete corpus of fighters out there, even if it might be difficult to collate. Could we not describe them statistically and construct a sort of heuristic fighter?

Sure, and maybe you can picture that fighter in your head — an extra attack at roughly Template A or B, some kind of scaling feature early on, etc. We might think of genre familiarity as a hazy version of a similar process. But this heuristic fighter is descriptive, not prescriptive. It tells us how fighters are, not how they must be. Designing your fighter to be like the heuristic fighter (and thus recognizable to a genre-savvy reader) might be your goal. Then again, designing against the grain to make something defined by its difference from the set might be as well.

So what?

None of the above is helpful advice. Thus, I think, folks’ frustration when I respond to questions about abstract design with :itvariesbygame:. I can imagine reading that as a sort of sneering “just figure it out.”

What I want to say is that cohering to recognizable archetypes is one of many possible design goals that I would never take for granted when engaging a creative work. And that if we are engaging those archetypes, then I, as a reasonably enfranchised reader, am looking for the ways that you are glossing those archetypes.

I want you to stage a new and surprising encounter with my old frenemy, the fighter. I want the pleasant frisson of recognition, but the intrigue and risk of something I have never tried before. I want the mechanics to do part or all of that work. If you are choosing mechanics based on whether they fit my description of a fighter without the guiding star of other design goals, I think you are undermining your own design process.

#GLoG #theory