Interested in creating a new System for Foundry VTT? Follow along as I create a new Foundry VTT System for my homebrew sci-fi RPG, "FutureSpace".
Creating A New System For Foundry VTT Part 2: The System Manifest
Each new Foundry VTT System requires a System Manifest which sets up the basic parameters for the System.
The manifest contains information such as the author, the required Foundry VTT version, as well as any Compendiums or dependencies on other systems, the game's default grid unit size, and more.
system.json - The System Manifest
The system.json file is required in order to define a valid System.
It contains all the information Foundry VTT needs to set up a new System.
If you don't have any applicable files, leave the entry, just make it an empty array.
Sample system.json
{userData}/Data/systems/mysystem/system.json
{
"name": "mysystem",
"title": "Minimal World Building",
"description": "Many details here.","version": "1.0.0",
"templateVersion": 2,
"author": "John Doe",
"scripts": [
"scripts/system-script-1.js",
"scripts/system-script-2.js"
],
"esmodules": [
"scripts/system-module-1.mjs"
],
"styles": [
"styles/system-styles-1.css",
"styles/system-styles-2.css"
],
"packs": [
{
"name": "monsters",
"label": "Monsters",
"system": "mysystem",
"module": "mysystem",
"path": "packs/monsters.db",
"entity": "Actor"
},
{
"name": "items",
"label": "Items",
"system": "mysystem",
"module": "mysystem",
"path": "packs/items.db",
"entity": "Item"
}
],
"dependencies": [
{
"name": "system1",
"type": "system"
},
{
"name": "world1",
"type": "world"
},
{
"name": "module1",
"manifest": "https://web/location/module1/manifest.json",
},
{
"name": "module2"
}
],
"languages": [
{
"lang": "en",
"name": "English",
"path": "lang/en.json"
}
],
"socket": false,
"initiative": "1d20",
"gridDistance": 10,
"gridUnits": "ft",
"primaryTokenAttribute": "resources.health",
"secondaryTokenAttribute": "resources.power",
"url": "https://your/hosted/system/repo/",
"manifest": "https://your/hosted/system/repo/system.json",
"download": "https://your/packaged/download/archive.zip"
}
Field Explanations
name - Choose a unique system identifier. This should be an all lower-case string with no special characters. This name must align with the name of the parent directory within which you create the system.
title - Provide a human-readable title for the game system which is displayed when selecting from available systems in the World creation menu.
description- This field can contain a more lengthy description of the game system. This text will be used to display help or contact information about your system and is also a good place to include any special licensing or attribution information that you need to distribute.
version- The system version number can be a number or a string depending on what versioning scheme you prefer to use. You should always increment the system version number if you make changes to the Data Template which is described below. When the system version is changed, the platform will automatically migrate all content to match the new Data Template schema.
author- Provide your name as the system creator. This field can be any string if you wish to include an email address or other contact information also.
minimumCoreVersion- Specify the minimum Foundry VTT version which is required in order for this system to function properly.
scripts- You can designate JavaScript files which should be included in the game session whenever this System is being used. Each listed script path should be relative to the system root directory. All scripts which exist will be automatically included in the game session and loaded in their listed order. As a best practice, I recommend serving system scripts out of a subdirectory named scripts, but this is not required.
esmodules- In addition to including traditional JavaScript script files, you may also include JS files that use the newer ES6 modules specification. These files are identified separately in the system manifest so they may be correctly loaded as a module rather than a script. ES6 is the latest JavaScript revision.
styles- You can designate CSS files which should be included in the game session whenever this System is being used. Each listed stylesheet path should be relative to the system root directory. All stylesheets which exist will be automatically included in the game session and loaded in their listed order. As a best practice, I recommend serving stylesheets out of a subdirectory named styles, but this is not required.
packs- Game systems may come bundled with Compendium packs which add pre-generated content for Actors, Items, or other supported Entity types. Compendium packs are defined as objects which have their own internal metadata. For each included compendium. These options are listed below:
name- The compendium pack name - this should be a unique lower-case string with no special characters.
label- The compendium pack label - this should be a human-readable string label that is displayed in the Compendium sidebar in-game.
system- Since you are creating compendium content specifically for your system, be sure to reference that the content inside each compendium pack requires the system by providing the system name that you chose.
module- The module attribute of each compendium pack designates which content module provided the pack, since this pack is coming from the system itself we can once again provide the system name.
path- The path for each compendium pack should designate a database file with the .db extension. As a best practice, I recommend placing these database files within the packs subdirectory. You do not need to create these files yourself. If a system includes a compendium pack, the database file for that pack will be created automatically when the system is loaded, if it does not already exist.
entity- Each compendium pack must designate a specific Entity type that it contains. Valid entities include Actor, Item, or Scene.
dependencies- Systems can require other modules, systems, or worlds to be installed to allow their use. If a module has been installed with dependencies, but its dependencies are missing, it cannot be enabled. Dependencies are defined as an array of objects containing the following data:
name- Dependency entries require the name attribute. If only a name is provided, additional details about the module will be discovered from the Foundry VTT website listing.
type- The type attribute instructs Foundry that the dependency may be on a different type of module. By default, dependencies are assumed to be a module, so if you want to depend on a system or world you should be explicit.
manifest- The manifest attribute provides an explicit manifest URL to be used for downloading the dependency. If a manifest is not provided, the dependency package must exist in the Foundry website directory.
languages- The game system may designate an array of language specifications that it supports by default. Each element in the language array is an object which defines the language tag, label, and path to its localization file. The elements of a language object are the following:
lang- The official 2-character language code in lower-case letters, for example, "en".
name- The formal and readable name for the language, for example, "English".
path- Path to a JSON file relative to the system directory where language translation strings are provided.
socket- A system may request a specialized socket namespace to be provided. If set to true, a socket event will be handled by the server with the name system.${id}, in this example case system.mysystem which transacts an arbitrary data object by broadcasting that data to all connected clients. This allows the system to have a reserved channel for messaging events that are needed to coordinate actions across multiple connected clients.
initiative- Not every game system uses the concept of "initiative", but this field provides the default dice rolling formula that can be used to determine the turn order of Tokens within the combat tracker.
gridDistance- This field designates the default amount of distance that a single grid space should typically represent under this game system. This value configures the default value used when a new Scene is created, but can always be changed for each Scene independently.
gridUnits- This field designates the standard unit of measure used to describe distances under this game system. This defines the default value used when new a new Scene is created, but can always be changed for each Scene independently.
primaryTokenAttribute- An attribute path within the system data model that points to an object that contains both a value and max key. The prototype Token for each Actor created in this system will automatically have this resource assigned as its primary bar. Omit this key or set it to null for no default attribute.
secondaryTokenAttribute- An attribute path within the system data model that points to an object that contains both a value and max key. The prototype Token for each Actor created in this system will automatically have this resource assigned as its secondary bar. Omit this key or set it to null for no default attribute.
url- A public URL that links to the repository or documentation pages for the game system. This link will be displayed for users to allow them to find more information about your system.
manifest- A stable URL that describes the latest release version of your system manifest file. This URL is used for automatic system installation in the Foundry VTT setup screen. This manifest URL is consulted during the system update check to see whether a new system version is available for download. It is important that this address remain stable, otherwise, updates will not be detected.
download- A public URL that provides a zip archive of your system. The archive at this URL is retrieved during the automated system installation or update process.
Making It FutureSpace
System Manifest For FutureSpace
Our sample manifest for the FutureSpace system:
{userData}/Data/systems/futurespace/system.json
{
"name": "futurespace",
"title": "FutureSpace System",
"description": "CyborgPrime Games - www.cyborgprime.com",
"version": "1.0.0",
"templateVersion": 2,
"author": "Frank Succardi",
"minimumCoreVersion": "0.7.7",
"scripts": [],
"esmodules": [],
"styles": [],
"packs": [],
"languages": [],
"socket": false,
"initiative": "2d6 + @characteristics.dexterity.mod",
"gridDistance": 1.5,
"gridUnits": "m",
"url": "https://www.futurespacerpg.com/",
"manifest": "",
"download": ""
}
Don't worry about leaving some attributes empty, we will be expanding them later.
What's Next?
Check out the next article in this series: Creating A New System For Foundry VTT Part 3: The Data Template
Check out the previous article in this series: Creating A New System For Foundry VTT Part 1: Getting Started
Your Turn: What Do You Do?
Have you ever created a System for Foundry VTT? Do you have any advice for me?
Tell me about it in the Comments Section. I'm interested in what you have to say about developing Systems for the Foundry VTT.
E-mail Notification Opt-in
Do you want to receive email notifications when we add new game design content?
Sign up on our private mailing list.
YES! Notify me of new game design posts!
Comments powered by CComment