A system reference document covers a portion of a game's content and collects it for future use. I will use four system reference document types to describe various strategies of collecting content.
A SRD's type informs the designer's approach to creating content. You have content complete SRDs, partial content SRDs, content-dependent framework SRDs, and content-independent framework SRDs, each of which has their own benefits and downsides.
These types broadly relate to scale. This isn't a rule, and scale isn't the metric I used, but it correlates well.
System Reference Document Types
Each type of SRD has a particular set of characteristics.
It is important to remember that a freely licensed game is not automatically an SRD. While a freely licensed game may function like an SRD, an SRD is a separate package aimed at designers who want to work with the game. Some setting-agnostic games may function like an SRD, but they would still include content tailored toward players alongside content focused on designers' interests.
The different types of SRD are characterized based on what content they serve.
Content complete system reference documents are suitable for any use, but usually foster a market around supplemental content.
Partial content SRDs provide a basis for creating supplemental materials, but can also serve as the basis for complete games with enough work put in.
Framework system reference documents feature mechanics rather than content, though they may be playable as-is.
Content Complete SRDs
Content complete SRDs allow the use of every element of first-party content for a game (and may also optionally integrate open-license third-party content), intended to provide an optimal framework for further production.
These offer tremendous opportunities for people who want to make their own game or create supplementary content for the base game.
The reason to offer a content complete SRD is that you can entice lots of players.
Games like Pathfinder have used this method, with a system reference document that features the complete rules content of the game. However, they don't feature the art, setting, or adventure content. This encourages players to take the plunge into buying commercial products.
For people using the SRD, a complete SRD provides opportunities to build on existing content easily with no legal issues.
Although it can be harder to compete with the existing content, it makes creating small content to supplement the SRD easier since you can always use, for instance, pre-existing monster and enemy stats.
The downside of producing a content complete SRD is that you're competing with your own work. The free playable content means that people can pick up the SRD and play, even if it lacks some optimizations.
Of course, given the prevalence of piracy, this is more of a question of which method you feel comfortable with. Having a content complete SRD does not guarantee commercial failure. It can even help drive traffic to storefronts or Kickstarter, something which the game Open Legend capitalized on.
Disclosure: I was a play-tester for Open Legend and I am listed in the credits of Open Legend. At one point I was tapped to provide setting content for Open Legend, but the deal fell through.
Partial Content SRDs
Partial content SRDs have the core mechanics and rules of the game and some of the content needed to play. However, they do not contain the amount of content intended for full playability.
This sort of SRD has some benefits over a complete content SRD for creators.
It's less effort to maintain a partial content SRD. Because it focuses on a core set of content, it's much easier to maintain and distribute.
It also protects a lot of your own work on the game, even more so than a full content SRD compared to a fully open-licensed game,
The exact degree of content included varies from SRD to SRD. Dungeons & Dragons' Fifth Edition SRD features a generous sampling of the options from the core rulebooks of Fifth Edition, clocking in at more than 400 pages. However, it only includes skeletons of player character features so that the SRD itself isn't competing with the actual rulebooks.
One advantage this creates for third-party creators is that there really isn't a freely available first-party rule-set for the game. Any third-party complete rule-set doesn't need to compete against playable free content in the SRD.
However, it also means that supplemental content can only be based on SRD content, and not other first-party content.
Framework SRDs
Framework SRDs feature only minimal content. They may not even feature example content from the game itself, especially if play is systematic. One of these SRDs that I've enjoyed is Fari Games' Breathless SRD, which I've used to make several games.
I'd divide framework SRDs into two camps: complete frameworks and partial frameworks. This is based on the amount of work needed to get them into shape to play a game.
Complete Framework SRDs
Complete framework SRDs include a full set of playable rules out of the box. However, they don't feature a lot of content.
Breathless, which I've used for a few games, and Charge, which I used for my game Consoles & Controllers, are both complete framework SRDs.
Complete framework SRDs still expect added content, but this revolves around tailoring the SRD to your setting or style of game.
Breathless, for instance, has fairly content agnostic mechanics. When I make games based on it, I focus on writing a setting and then adding a couple thematic rules. In my game Breaking Through, I add a dice-based oracle for random heist generation and a few mechanics built to simulate heist gameplay.
Charge depends on playbooks, and while there's a generic one in the SRD you'll really want to flesh these out to make a game. Consoles & Controllers did this by using in-universe games, each of which had a couple character options with their own ARPG-inspired skill trees.
For a light game, a complete framework might be a self-contained game. My Initiated SRD is a complete framework, as was the Hammercalled rule-set that preceded it.
Partial Framework SRDs
Partial framework SRDs have the core mechanics of a game but are not play-ready out of the box. For instance, The Resistance Toolbox has the same core rules as Rowan Rook and Decard's Spire. Because its sample content is not generic and repurposable, you couldn't pick it up and play it directly from the SRD.
I used the Resistance Toolbox (and a hack of it) back in the day to make Waystation Deimos.
The distinction between a partial framework and a complete framework is that a partial framework will require the addition of certain types of content. A complete framework will permit more flexibility for future development.
Both Resistance and Charge expect designers to add the content for character creation.
Charge can handle this in a generic rules-driven fashion straight out of the box.
The samples in Resistance, although perfectly fine, cannot really make a game in their own right. Both Charge and Resistance assume multiple character roles as "playbooks" within the context of a particular setting, but Charge provides a universal generic option. Resistance provides examples of how individual implementations might look.
Another example of this distinction is in the Trophy SRD, which I used for my game Recension.
Although the SRD is a framework, it leaves out core components (skills and rituals) featured in the game itself. This is an obvious case of a partial framework rather than a complete framework.
Modularity
One concept that might come up when dealing with an SRD is the idea of modularity.
A modular SRD has components that are optional.
Initiated builds on a layer format. This makes them inherently modular, since you can leave out or replace any layer you don't want.
There are advantages to modularity, but also costs.
One advantage of an SRD is that it represents stable, play-tested, and well-polished content. Adding or removing pieces disrupts this balance.
You might also have certain assumptions built into each module. For instance, Initiated assumes the presence of one to three layers, each of which provides numbers to a modifier on a central die roll.
This helps prevent massive issues with any particular element, albeit by imposing significant constraints.
In other cases, making modifications cannot be so easily accomplished. Breathless and Resistance both have narrative-style outcomes, and Breathless is mathematically minimalistic.
The consequences of this are that you might not achieve modularity because there aren't levers to use. When working with Breathless, I've often modified the core mechanic. This would break compatibility with many other modules or add multiple central mechanics.
That's not bad, but it changes the way the rule-set works in qualitative ways.
Modularity and Assertions
The distinction between Fudge, a traditional mechanics-driven game, and Fate, a more narrative-focused derivative of Fudge, is a good example.
These are games with nearly the same mechanics. You can mistake one for the other if you're not looking closely.
But the directions they travel in are significantly different.
Fudge plays like D&D. You're good at stuff, which gives you a bonus, then you roll. Fate has that, but it's also more about who you are in a narrative sense. Aspects come up in the story, and you invoke them.
You can use a system from one in the other or vice versa, but it will carry baggage with it. Fate wants you to be invoking aspects, adding aspects, and changing the scene dynamics. These all represent narrative changes.
Fudge wants you to be stacking numbers to dominate and master the world, not set the stage.
As such, any modular system needs to be up-front about its assertions.
Any module added on must either align to the existing assertions or overlay its own on the system.
It is not enough simply to have mechanical interoperability.
Implications of System Reference Document Types
The system reference document is supposed to be a game's foundation. The more content in it, the more it's been built up beyond that initial foundation.
Heavier SRDs are more readily adapted by adding branches of content outward, while a lighter SRD will require more input. A designer adding something to a framework may find that making a complete game is just as easy.
More content lends itself to derivatives that require the original SRD or game. Less content lends itself to new games. You don't see people making games that reference Lasers & Feelings without reproducing the rules, because Lasers & Feelings is a one-page game.
At that point, you're much better off just integrating the system, rather than referencing it.
But you do see people adding a class option or adventure to Pathfinder. This is because it has a large body of open content to reference. Rather than reinventing the wheel, it's possible to reference an existing corpus, even when making quite significant derivatives.
D&D has, by merit of its openly licensed content, achieved both a large supplement community and several independent spin-offs. Because its core content isn't freely available, people don't play D&D unless they buy (or pirate) it.
This paves the way to competitors built on its SRD.
All these subsequent products are predictable as a result of the type of SRDs that spawned them.
More on SRDs
Check out the following articles for more information on SRDs:
The Art of the System Reference Document: Licensing
The Art of the System Reference Document: Uses
Posted from my blog with Exxp : https://loreshapers.net/the-art-of-the-system-reference-document-types-of-srd