The Fantasy Grounds Architecture
Fantasy Grounds (FG for short) consists of a number of components that fit together to provide the gaming experience that we've all come to know and love. These components are: the FG-Engine, FG-Launcher, Rulesets, Extensions and Modules. This article briefly discusses (at a reasonably high-level) each of these components and how they fit together to form the overall FG experience.
The FG-Engine And The FG-Launcher
The FG-Engine is what we call the actual program (the fg.exe and associated files), while the FG-Launcher is the first set of screens we see when we start the FG-Engine. The FG-Launcher screens are the ones that allow us to select how we are going to use FG: as the GM or as a Player, and which RPG (role-playing game) we are going to play. When we start up FG we are starting the FG-Engine and the FG-Launcher is loaded for us automatically.
The FG architecture consists of the FG-Engine on top of which runs a Ruleset. A Ruleset contains all the mechanics and automations for playing a given RPG: the die rolling, what constitutes a hit, how the hit points work, how the saving throws work - how everything works. The 3.5E D&D mechanics are different from (but similar to) the 4E D&D mechanics, which are different from the 5E D&D mechanics, etc, etc, etc. Thus, each of the rules mechanics for a given RPG is collected into a different Ruleset.
One way to think about this architecture is like a game console (X-Box, Play Station, etc) and game DVDs or cartridges: the FG-Engine is the "games console" and the Rulesets are the "game DVDs".
In a way, the FG-Launcher can also be thought of as a Ruleset: it contains not the mechanics to play an RPG but the mechanics to load a selected Ruleset or connect to another person's copy of FG as a Player.
Now because a lot of the mechanics for a lot of different RPGs/Rulesets are the same (or very close) it makes sense to pull those common mechanics out into a separate, common "pile", and then load that "pile" into FG when we load a given Ruleset. This idea is accomplished by using "parent" and "child" Rulesets; the common "pile" for just about all current Rulesets is the CoreRPG Ruleset, and any Ruleset which uses the common "pile" is a "child" of the CoreRPG Ruleset.
So, the 3.5E Ruleset, the 4E Ruleset, and the 5E Ruleset (and others) are all "children" of the CoreRPG Ruleset, and the CoreRPG Ruleset is the "parent" of these various Rulesets. When we load/select a child Ruleset in the FG Launcher the parent Ruleset is loaded automatically first, and then any changes to the parent Ruleset specified in the child Ruleset are applied.
It is possible to continue down this chain indefinitely, with child Rulesets having children of their own, and so on. An example of this is the Pathfinder Ruleset: it's very, very close to the 3.5E Ruleset, so the Pathfinder Ruleset has been made a "child" of the 3.5E Ruleset and is loaded on top of the 3.5E Ruleset (which in turn is loaded on top the CoreRPG Ruleset). So we could say that the Pathfinder Ruleset is a "grandchild" of the CoreRPG Ruleset.
It's important to note at this stage that only one Ruleset is in action at a time (the last one in the Ruleset Stack), even though parent Rulesets may be loaded first.
It is also important to note that the FG-Launcher is NOT a parent Ruleset: the very last act that the FG-Launcher performs once we click on the FG-Launcher's Start Button is to unload itself from the FG-Engine, so it is not available to the Ruleset that we have choose to load.
So now when a Ruleset Developer wants to develop a new Ruleset all they have to do is work out which of the existing Rulesets has the closest mechanics to the desired RPG and then make their new Ruleset a child of this existing Ruleset. At the very least just about all new Rulesets should be children of the CoreRPG Ruleset, because the CoreRPG Ruleset has just about all of the "basic" things needed by FG to play a RPG. This is why you can play any RPG with FG: just use the CoreRPG Ruleset.
So how do Extensions fit in?
Well, an Extension is a modification to a Ruleset. It might be a change of resource (language or graphics), it might add some extra functionality (some "house rules") to a Ruleset, or it could be just about anything else. My DOE: Locations Extension, for example, adds the ability to store information organised by place, while my DOE: Weather Extension provides a mechanism for determining the weather; my DOE: Base Extension adds (in addition to being the foundation of all the DOEs - Dulux-Oz Extensions) the ability to set your die colours by using a Colour Hex Code, in addition to using the existing 11 Colour Buttons; you get the idea.
Extensions are loaded after the Ruleset Stack is loaded (after the parent Ruleset and any child Rulesets), and more than one Extension may be loaded at once. The order that Extensions are loaded is arbitrary: it is possible for an Extension Developer to specify when their Extension is loaded relative to any other Extensions (try to be first, try to be last, etc) but there is no guarantee, and most Extension Developers don't bother to specify anyway (although it is considered best practice to do so). It is also possible for an Extension Developer to specify if their Extension should or should not be loaded with others, but again most Extension Developers don't bother to specify (and again, it is considered best practice to do so if required).
Because each Extension modifies the existing computer code or resources, etc, of the loaded Ruleset, if two Extensions try to modify the same thing then only the last Extension in the Extension Stack that effects the thing being modified applies. This is why some Extensions won't work with others and why sometimes two Extensions will "break" each other - they're trying to both modify the same thing in the loaded Ruleset. A prime example is trying to load two Theme Extensions at the same time (a no-no): each Theme Extension changes the graphics used by a Ruleset, and as each Theme Extension is trying to replace the same graphics they "fight" one another and cause problems. The only way to fix problems caused by conflicting Extensions is for the two Extension Developers to work together to come up with a solution; sometimes a solution is not possible, but often one can be found.
So should a Developer use a child Ruleset or an Extension for their changes?
Well, it depends upon the extent and the scope of the modifications. If the modifications are designed to be used by more than one RPG (such as my DOE: Locations Extension) then an Extension is the way to go. If the change is relatively minor and doesn't really involve changing the mechanics (eg changing the graphics used by the Ruleset) then again, an Extension is probably best. If the modification is significant and might really be considered a new RPG, then a child Ruleset is probably best. But in the end it's really a matter of taste for the Developer.
So, finally, how do Modules fit it to the FG Architecture?
Well, Modules hold information relevant to the RPG setting. Typical Modules might be a Monster Manual, a Spell Grimoire, the plans for a space station, or the details of an Adventure. This information isn't the mechanics of a RPG, but often uses the mechanics. Modules are loaded and unloaded as required by the GM and/or the Players during the FG session, just like you'd open and close an RPG's physical reference books as you look up various information.
So now you should have a good idea of how the various components of FG fit together, which should help you in understanding how and why FG works the way it does.