Understanding The FG Architecture

[dulux-oz]

Hi Everyone,

Smite Works has placed an article I wrote dealing with the "architecture" of Fantasy Grounds onto the Wiki, on the Developer Guides page. Although aimed primarily at those wanting to develop Rulesets and Extensions for FG, the information is easy enough to understand that everyone should get some insight into FG out of it, and so I'm recommending it and placing a link to it here.

https://www.fantasygrounds.com/wiki/index.php/Development_Overview

Enjoy

[Nickademus]

Is this the architecture of raw FG or the Smite Works rulesets?

[dulux-oz]

Is this the architecture of raw FG or the Smite Works rulesets?

Its the architecture of the system as a whole (at a pretty high-level) - how the parent and child Rulesets fit together along with how Extensions fit with those - as you would have known if you'd have taken the time to read the first paragraph or so :p

[Nylanfs]

Needs flowcharts and diagrams. :)

[dulux-oz]

Needs flowcharts and diagrams. :)

Feel free :p

[Zeus]

Nice straightforward guide dulux-oz.

[Nickademus]

- as you would have known if you'd have taken the time to read the first paragraph or so :p

Read!? Ain't no one got time for that!

[dulux-oz]

Nice straightforward guide dulux-oz.

Thankyou

[dulux-oz]

Read!? Ain't no one got time for that!

<British accent>And I rest my case, M'Lud!</British accent>

[Falantrius]

To me it seems that the Rule Set is the application/logic layer over the FG OS. The FG OS just takes in the "rules" and processes them.
I believe the Rules Set is also used to not only create the logic for a FG role system but it also describes the Look and Feel in the UI (AKA how its presented). Generating the presentation layer for FG as well. There may be some presentation that the Rules Set does not impact but I would have to look at a lot of other rules sets to see the difference.

The application layer can have extensions that sit along side it and "extend" the rules set logic.

I believe the "Modules" are actually shared data sets used by the Rules Set and are encapsulated above the presentation layer. The data can be moved around and once copied to other areas in the rules set - then can be modified within the UI and linked between areas(Monster Pins/Pogs on maps, Pins in stories, etc). The different areas within FG may actually be defined "buckets/tables" within the database that the rules set defines the layout - I'm not sure yet - still breaking it all down. But its clear that the rules set has some level of modification within the tables - and once data is copied to a "table" the user can modify it without impacting the original item in the shared data set. I think the tables are Characters, Story, Images/Maps, NPC, Encounters, etc.

Lastly, User created data extends the modules with personalization (vs shared data) adding more data to the tables - specific to the users needs - Characters, Story, Graphic Libraries (Maps/Images), NPC/Monsters/Encounters, etc.)

That's how I look at it. I could easily create a diagram if I could get more information on the specifics - its kinda what I do for a living.
I did work for Microsoft for 25 years :) If I could have 30 minutes with the FG developers I could work out all the specifics - always love to help out.

OVERVIEW:

[ User Control ] [Graphic Libraries, and User Created Data Sets]
[Modules][Modules][Modules] [ Shared Data Sets ]
[ Rule Set]]]] [Extensions] [ Presentation Layer and Logic ]
[ Fantasy Grounds ] [OS, DB, Links, Security and UI Engine ]
[ ] [ Network Architecture ]

[Moon Wizard]

FG is the platform and API.
Ruleset is the presentation, logic and data definition all mixed together to define how a game system works on FG.
Rulesets can be layered.
Extensions are additional layers that can be applied on top of rulesets to provide additional presentation, logic and data definition customization. (i.e. house rules, custom windows, etc.)
Every campaign contains a database of all data entries created by the ruleset plus extensions. The database is saved as XML between sessions.
Modules are additional XML data sets that can be added to a campaign.
There is no presentation or logic in the database. It's just an XML data tree. It's interpretation is up to the ruleset plus extensions.
By historical common convention, each record "type" (i.e. images, stories, PCs, NPCs, etc.) is usually stored in a similar place in the XML database, but there is no enforcement by the FG client.


BTW, I am the primary developer for FG (among other hats), if you have questions.

Regards,
JPG

[dulux-oz]

To me it seems that the Rule Set is the application/logic layer over the FG OS. The FG OS just takes in the "rules" and processes them.
I believe the Rules Set is also used to not only create the logic for a FG role system but it also describes the Look and Feel in the UI (AKA how its presented). Generating the presentation layer for FG as well. There may be some presentation that the Rules Set does not impact but I would have to look at a lot of other rules sets to see the difference.

The application layer can have extensions that sit along side it and "extend" the rules set logic.

I believe the "Modules" are actually shared data sets used by the Rules Set and are encapsulated above the presentation layer. The data can be moved around and once copied to other areas in the rules set - then can be modified within the UI and linked between areas(Monster Pins/Pogs on maps, Pins in stories, etc). The different areas within FG may actually be defined "buckets/tables" within the database that the rules set defines the layout - I'm not sure yet - still breaking it all down. But its clear that the rules set has some level of modification within the tables - and once data is copied to a "table" the user can modify it without impacting the original item in the shared data set. I think the tables are Characters, Story, Images/Maps, NPC, Encounters, etc.

Lastly, User created data extends the modules with personalization (vs shared data) adding more data to the tables - specific to the users needs - Characters, Story, Graphic Libraries (Maps/Images), NPC/Monsters/Encounters, etc.)

That's how I look at it. I could easily create a diagram if I could get more information on the specifics - its kinda what I do for a living.
I did work for Microsoft for 25 years :) If I could have 30 minutes with the FG developers I could work out all the specifics - always love to help out.

OVERVIEW:

[ User Control ] [Graphic Libraries, and User Created Data Sets]
[Modules][Modules][Modules] [ Shared Data Sets ]
[ Rule Set]]]] [Extensions] [ Presentation Layer and Logic ]
[ Fantasy Grounds ] [OS, DB, Links, Security and UI Engine ]
[ ] [ Network Architecture ]

I don't disagree with any of that - but I do think it's at too detailed/ICT a level for the vast majority of FG users, hence the reason I wrote the article the way I did :)

Remember, people, to always present your information at the level of the audience - while you may well understand a topic (possibly because you've been "immersed" in the topic professionally for years) the overwhelming majority of people on these boards are, at best, armatures as far as ICT is concerned and therefore couldn't tell a database from a flat-file spreadsheet if their lives depended upon it - its not their area of expertise or interest.

Its up to the experts (that's the Devs, the Community Devs and the ICT Pros using FG) to make sure the 99.9% of the other users of FG can understand what's going on if they choose to know - which means making sure we "meet them at their level" and don't go over their heads with concepts and jargon they don't understand.

My motto in all this - "Assume No Knowledge".

Cheers

[Falantrius]

I don't disagree with any of that - but I do think it's at too detailed/ICT a level for the vast majority of FG users, hence the reason I wrote the article the way I did :)

Remember, people, to always present your information at the level of the audience - while you may well understand a topic (possibly because you've been "immersed" in the topic professionally for years) the overwhelming majority of people on these boards are, at best, armatures as far as ICT is concerned and therefore couldn't tell a database from a flat-file spreadsheet if their lives depended upon it - its not their area of expertise or interest.

Its up to the experts (that's the Devs, the Community Devs and the ICT Pros using FG) to make sure the 99.9% of the other users of FG can understand what's going on if they choose to know - which means making sure we "meet them at their level" and don't go over their heads with concepts and jargon they don't understand.

My motto in all this - "Assume No Knowledge".

Cheers

While I understand what you are saying - I think your overview is a bit too "dumbed" down for most users.

At the same time, I would like to see a version more complete - not a developer written overview but one that you could use to explain it in detail to non-developers.

[dulux-oz]

While I understand what you are saying - I think your overview is a bit too "dumbed" down for most users.

Well, you and I (and my 2nd Year University ICT class) are going to have to disagree on this :)

Cheers

[Falantrius]

FG is the platform and API.
Ruleset is the presentation, logic and data definition all mixed together to define how a game system works on FG.
Rulesets can be layered.
Extensions are additional layers that can be applied on top of rulesets to provide additional presentation, logic and data definition customization. (i.e. house rules, custom windows, etc.)
Every campaign contains a database of all data entries created by the ruleset plus extensions. The database is saved as XML between sessions.
Modules are additional XML data sets that can be added to a campaign.
There is no presentation or logic in the database. It's just an XML data tree. It's interpretation is up to the ruleset plus extensions.
By historical common convention, each record "type" (i.e. images, stories, PCs, NPCs, etc.) is usually stored in a similar place in the XML database, but there is no enforcement by the FG client.


BTW, I am the primary developer for FG (among other hats), if you have questions.

Regards,
JPG

Bowing before the Moon Wizard

At a high level (for dulux)- am I correct in saying that FG consists of:
a) FG Platform and API
b) Layered Rule sets and extensions that provide the presentation, logic and data definitions
c) Modules that provide data for the campaign and are stored in the DB - Modules can be shared data like "Books", "Effects", "Tokens" and other "Library files"
d) Along with Modules - the user can also copy data from modules into each record type and modify it to create their own custom story, NPCs, Links, etc. which are stored in the campaign DB

-----------------------------------
Deeper questions:
removing the rulesets, compaign data, etc. when first installed before a RuleSet is selected- can you break down FG for me into its largest "chucks"
For example:
Installer : that installs FG on your system - also seen as settings in the FG Loader - set directories, store purchases, license keys, etc.
FG Startup: that loads the platform and initializes the API -
FG Loader: that is broken up into:
1) Campaign Initializer: to Create and load campaigns (load rulesets, DB, modules opened and campaign data)
2) License Verifier: to check which license is in place to enable/disable features
3) Update Checker: to contact FG site and validate the install files and/or download new ones
4) Startup: Initializes the Host Address to connect to a specific Campaign setup
Chat Window
etc

Have anything that explains WHAT it does - not HOW it does it?

[Falantrius]

Well, you and I (and my 2nd Year University ICT class) are going to have to disagree on this :)

Cheers

(*big smile*)
Mine are comments coming from a newbie compared your Champion Immortal status.
I'm all good with that - you know I still luv ya man :)
Keep up the great work!

[Moon Wizard]

There's a section in the User Guides section of the wiki for the Launcher. Does this cover your questions on the initial launch screen, or were you thinking of something different?

Cheers,
JPG

[Falantrius]

There's a section in the User Guides section of the wiki for the Launcher. Does this cover your questions on the initial launch screen, or were you thinking of something different?

Cheers,
JPG
Im not looking for how to use the launcher - What I am looking for is the architecture of it. Thinking of it in "Blobs of execution" when you first start the launcher BEFORE the UI comes up - what the launcher does.

Then dividing out the major sections of it out - in the UI - there are a few "Triggers" that kick of other "blobs" of code.
I wasn't looking for the actual code - just high level description of the sequence of events that occur.
Like
1) "Initialize and load Network Drivers"
2) "Validate, recreate or load the Variables Database"
etc
9) "Launch the User UI and wait for a selection"

That sort of thing. If that makes sense.