One of the evergreen discussions I see in fora on game design involves asking what a system is about. It pops up regularly as a topic or as a major thread in a discussion on some random question posed by a user. Most of the time, it just rolls off my consciousness like rain off a brelly. Other times, however…well, it pokes me in the liver with enough force to really annoy me.

My annoyance — when I get annoyed — isn’t due to a single, repeated notion that flares up with each new iteration of the discussion. There’s a bit more to it than that. Perhaps laying out the issues in one place will help keep it from annoying me quite so often…I can hope.

The foremost issue I have with asking “Well, what’s it about?” when dealing with a game system lies in how the question conflates systems and games. The two are *not* the same and asking the question as if they are shows a lack of understanding both processes. To wit, a game system is the collection of game structures that a game master uses to create a game to take to the table; the system is not the game, nor are any of the games the system that they share. More than one game can be created using a system and using a system to support one game doesn’t preclude that system from also supporting a different game.

For example, a GM can use a system — say, GURPS — to create a game about medieval fantasy, mercenary units operating in a war-torn region where a couple of failing empires are battling over broken lands. The gameplay loop can be all about being offered contracts, accepting or declining said offers, working accepted offers, and the aftermath of the fighting such work involves, with recovery and political fallout to be navigated before starting the cycle over a gain. Does every game that uses the GURPS system use such a structure? Absolutely not! While that game is about mercenary companies in a war-torn land, the GURPS system is *not* about mercenary companies in a war-torn land. The system can certainly be used to make games about mercenaries, though.

A far more useful question then becomes apparent when discussing game systems: “What sorts of games does it support well?” A system that has detailed subsystems dealing with fighting and recovery is obviously going to support games that involve physical fights. Will it support games that eschew physical violence? Well, that depends on if it has subsystems that can support different types of conflict, such as emotional conflict and social isolation and so forth. If subsystems exist that can support other-than-physical conflicts, then physical fights aren’t a necessary component of games made using that system.

I find that I’m loath to discuss my bespoke system freely, many times, for exactly this reason. I don’t want to try to launch a discussion of any elements of it because of the sense of waiting for the “What’s it about?” to fall and derail any useful subthreads. It can be tricky to route discussions around the wreckage of the question to continue on in useful fashion, so I do find that I often just drop the intention to start a chat because of it. The perceived hassle is greater than the perceived gain.

This has arisen now because I’m at a point where I’m working out the underpinnings of how to explain campaign creation in my GMing guidebook. I think a GM having a solid understanding of what a campaign involves — what it’s about — makes for better games at the table. I’ve seen many discussions of play loops crop up across many venues of late, too, which suggests that reaching an understanding of how loops direct play is now being treated as more important than it has been prior. (Or that I’m simply noticing more references because it’s weighing on my mind.)

I find it more useful to ask what loops a system supports in service of specific games the GM wants to create for their table. To that end, I’ve reduced the notion of what a play loop is to the barest elements with the intent to then expand that basis in different directions to more distinct loops. It is by selecting which of those loops and how many of those loops to use that games are created to take to the table and play out in campaigns. A GM can thus create a tightly-focused campaign that involves only one or two of those expanded loops — a mercenary campaign, for example — or a multi-faceted campaign that includes many different fundamental play loops that offer amny different experiences.

Understanding how to use the system to support the choices makes for a better game experience, is my contention (and my hope). Whether focusing on mercenary actions or monster hunting or trying to track down magical artifacts or offering assistance to random communities or rooting out the machinations of otherworldly threats or any of a number of other approaches, understanding how the system supports the specifics is useful.