Project organization

[Xarxus]

My work is progressing and since I continue to consider myself a total inexperienced I turn to you for advice.
From what I understand the ruleset can contain rules and data, the module contains data, the extension contains
behaviors (rules?) - right now I don't care about themes.

The system that I am implementing from the paper point of view is like this:

manual 1 - is the basic manual, contains the rules, races and professions
manual 2 - is the manual that explains how magic works, contains spells, but the rules are in manual 1
manual 3 - is the combat manual, it explains how weapons and armor work, but the rules are in manual 1
manual 4 - is the manual of advanced magic, contains advanced rules for magic and new professions
manual 5 - is the advanced race manual, contains advanced race rules and introduces new ones
manual 6 - is the monster manual with rules and descriptions
Usually the first 3 manuals are enough to play, but I would like to be able to have the others available as well,
on request.

I've thought about a bit of architecture and I need your advice. I would lean towards solution B, but I don't know
if it's the best and if there are better ways to organize the work. From the point of view of system distribution,
solution C seems really annoying to me.

Solution A.
ruleset - I put all the rules here, even those of the advanced manuals (4 and 5), perhaps adjusting their
application with an option and with the presence of the loaded manuals
modules - I make a module for each manual with the corresponding data

Solution B
ruleset - I put all the rules here, even those of the advanced manuals (4 and 5), perhaps adjusting their
application with an option and with the presence of the loaded manuals, and add the data of the basic manual
(or the first 3)
modules - I make a module for each manual with the corresponding data (not the 1st one or the first 3)

Solution C
ruleset - I put here only the rules of the basic manual, including the data
modules - I make a module for each manual with the corresponding data
extension - I make an extension with the rules of the manual

What do you recommend?
Thanks in advance.

[Valarian]

The ruleset is the functional layout for your system. The character sheet, NPC sheet, item attributes, combat tracker. It's what makes Fantasy Grounds work specifically for your system.

Extensions are just that, extending the functionality of the ruleset. If a supplement changes the character sheet slightly, or you want a separate theme for the various frames, this goes in the extension.

The module holds the reference text for the system. All the rules, and data, goes here. For NPCs/monsters, races, etc., you can create the data in an open campaign and then cut & paste the data from the campaign file (db.xml) to the module. Or you can start with an exported module containing the data and then add the rules and other surrounding text to the module.

[damned]

Ruleset is not just the rules.
It is the computer programming that allows Fantasy Grounds to adjudicate or apply the action the PCs or NPCs take.
It does not contain rules for humans to read.

The mod contains all that.
The module should come in two (or maybe more) parts.
One part Players should have access to and one part Players should not have access to - eg Monsters.

[LordEntrails]

Don't put any "text" or anything to read in the ruleset. It is just all the game mechanics and the object records (PC, NPC, etc sheets). You can make a base ruleset for the mechanics present in modules 1-3 and extensions for the extra mechanics in modules -6, or you can just put it all in one. One is probably easier, but you might want the segregated approach so you work towards a minimal viable product.

The create a FG module for each of the modules 1-6, so that they can be built, loaded and organized just like the printed books.
EDIT: Oh, and as damned says, if the modules have player vs GM facing material, then separate those into different FG modules. Plus you might want to include a 3rd "map" module" so that GMs can load and edit maps easier than if they are in the GM module.

[Xarxus]

I do not understand. MOD can contain LUA?

PS ty all

[damned]

No.
Mods contain XML and images.

[Valarian]

Any sheet layout (XML) and automation (Lua script) goes into the ruleset (.pak), or extension (.ext) if not part of the base functionality of the system.
The reference library module (.mod) contains all of the text and data. All rules, races, professions, spells, monsters, etc. would go into the module. The module is XML and HTML.

[LordEntrails]

Look at existing examples in FG. For example, 5E is a ruleset (and you can open it up) and is a child of the CoreRPG ruleset. You will see if you start a campaign using either of those ruleset and you don't load any modules, you will see the character sheets are all laid out, you can manually enter all the data you want, but that there is nothing included. Then go and load the SRD modules. You can even open those up. They contain the text of the rules, and the actual classes, and weapons, and spells, and NPCs etc.

Follow the same approach and you will be good.

[Xarxus]

I'm so confused. Let's try with an example.

Let's say we have two paper manuals: the basic manual defines the races and these have 3 stats.
The expansion manual, in addition to defining new races, adds 2 more stats, bringing them to 5.

I thought of putting the basic manual data in the ruleset, while I imaginethe expansion manual data
in the module, as well as the modified version of the character sheet.

The problem is: where do I put the LUA code that manages the two new stats?
According to Solution B I thought of putting it in the ruleset, subordinating its use to the presence/loading
of the module and maybe even to an option.

[damned]

There are no manuals in the ruleset. Period.
By ruleset I mean PAK.

[Xarxus]

So i should build a rulest with all the LUA, a mod for the base manual and a mod for the advanced one?

[damned]

Yes.

[Xarxus]

Perfect, I get it. Thank you all for your patience.
:D

[Valarian]

Let's say we have two paper manuals: the basic manual defines the races and these have 3 stats.
The ruleset (.pak) will contain your blank character sheet layout for the 3 stats, and spaces for adding whatever other attributes, skills, and stats are required by the basic game.
Your module (.mod) for the basic manual will contain the race descriptions and what the stats are for that particular race. As with the D&D 5e module, you can create the module entry so that a player can drag and drop the race from the module to the character sheet and have the 3 stats filled in.


The expansion manual, in addition to defining new races, adds 2 more stats, bringing them to 5.
An extension (.ext) will add the additional 2 stats to the blank character sheet defined in the ruleset.
Your module (.mod) for the advanced manual will contain the modified/new race descriptions and what the stats are for that particular race.

[Xarxus]

So the advanced mod will need the extention. What happens if the extension is not loaded?

Ty 4 all

[LordEntrails]

So the advanced mod will need the extention. What happens if the extension is not loaded?

Ty 4 all
It doesn't require an extension. But, depending upon how you want things to work you may want an extension.

For example some possible approaches for you;

A) One ruleset, no extensions
In this model you would create one ruleset that has all the mechanical capabilities for the basic and advanced game. You could allow GM options to turn on/off the display of such, or you could just have all the fields there and the 'basic' users would need to know that they don't fill them in. This would probably be simplest for the users as they would not need to use or understand extensions.

B) One Ruleset, one+ Extension
Here you would have a ruleset that sets up for the 'basic' game. Character sheets, rules automation, etc would only support the basic rules of the game. Then you could have one (or more) extensions that add the advanced character sheet fields, objects types (i.e. vehicles or similar), etc. This would require for the advanced fields that the extension be loaded when the campaign starts each time (extensions default to loading what was loaded last time). If someone disabled the extension in the future, you would have to make sure the campaign would still run with just using the basic rules functionality. Depending upon your architecture, this may or may not be easy. Also, users might get confused if their wasn't a clear (out side of FG) difference between the basic and advanced rules. But if this is a commercial product, then it would allow you to force users to buy the advanced product in order to use the advanced rules extension (not saying that is a good marketing strategy, just that it is a strategy).

Either way, all of the readable text and data objects themselves go in modules.

[Xarxus]

Ty all for your information.
@LordEntrails - I think I will proceed as indicated by option A. It is more linear and I think it is easier to use when distributed or published.

[Xarxus]

After a long time (I had to work a lot and Covid created a lot of problems - by the way, welcome back to everyone) I'll resume the discussion here.

I opted for option A that LordEntrails suggested to me.

Now I find myself having to manage this situation: I have a single ruleset and two modules. In the second module things are added (e.g. skills), but also changed. Is it possible to make sure that the version of the second module is used when this modifies the one already present in the first? If so, how?

[Xarxus]

Ok, it seems is not possible

[LordEntrails]

So you have two development campaigns (A & B). Each makes a module. And in B you copy a item (#1) from A and modify it? And then you have play campaign C and load both A & B?

If so, then when you are in C, there should be two entries for the item (#1), one listed as coming from A and one listed as coming from B.

If instead, in development campaign B you only modify the item (#1) from A, when you export it will not export the modified item (since it comes from a module). And therefore in Campaign C you won't see the changes from B, you will only see the item (#1) from A.

[Xarxus]

I'm not sure I understand. My situation is this: ruleset (A), module with skills (B), module with skills (C).
B and C have many skills, one of which in common (version of C has some modifications).

For now what happens is that by loading both modules (B and C) from A I see 2 skills with the same name, one coming from B, the other from C.

I would like to make sure that by loading module C I only see C's version of the skill, and not B's one. Obviously I have to continue to see B's other skills.

By the way, ty!

[damned]

I dont think you can do it.
Create a module D that contains B-duplicateskill and C

[Xarxus]

I think is not a solution for me. You can load only one of them or both. So when loading only C, no B skill should be in game.
I suppose that I should insert in A (ruleset) some code to avoid players to use the B version when C is loaded, even if visible.

[damned]

There may be a language challenge here -

"If when loading C no B skill should be in the game." then dont load module B?

[Xarxus]

Ah... ok, you mean
B - stand alone
C - stand alone
D - B + C

Right?

[LordEntrails]

Yes.

Because Both B & C have the same skill, when you load them both into a play campaign, both will show. Their is no 'load order' or way to get one to overwrite the other. You can either tell players to always use the skill from C if it exists, or you can make a new module (D) that has copies of the skillsfromC d the unique ones from B. Personally, the second option is too much for me, but that is your call.

Edit: Note, that because D has to contain copies of the skills from B & C, now when you update a skill, you have to update it in 3 places; B, C & D. I would never get that right.

[Xarxus]

It's too much for me too. Consider that the modules are more than two and the loading combinations are impossible to manage.