Building Block View

[ Level 1 | Level 2 | Level 3 ] The gaming gets organized in this SCS. The mission s are defined and their play results collected in t his subsystem. Game Masters can add local games to the system to enable a full track of an operative’s history. In addition the shared campaign is created here. The results of all tables are combined into a shared campaign moving on.

[ Level 1 | Level 2 | Level 3 ] The storm knight s or stormer s (referred to as operative s of a campaign are managed inside of this SCS.

[ Level 1 | Level 2 | Level 3 ] The opposition to the Players is known as Threat in Torg Eternity. This system lets create new threat in addition to the ones defined by the original publishers. It also creates the famous threat cards out of the data and the image provided by the user creating the threat.

[ Level 1 | Level 2 | Level 3 ] A rip-off of the original Torg Codex. A page I really appreciate and that shows the value to a lot of players. Best case scenario is that the SCS could still run completely separately without relying on any other SCS (even with another theme for page display).

[ Level 1 | Level 2 | Level 3 ] A quite straight forward user management system. It is based on kp-commons-users. Authentication is offhanded to OpenIDConnect providers. So this SCS only manages some Out-Game stuff.

[ Level 1 | Level 2 | Level 3 ] A generic arbitration system to sort out differences.

[ Level 1 | Level 2 | Level 3 ] A discord bot and module to send discord messages.

[ Level 1 | Level 2 | Level 3 ] The common java script, CSS and images or other resources that are used on multiple SCS. Helps the browsers to cache by referring the same stuff with the same URL instead of copying it to the different SCS.

[ Level 1 | Level 2 ] The client and datastore libraries used within the systems.

[ Level 1 | Level 2 | Level 3 ] The publication of the shared campaign. This SCS is currently only an idea. It could be a blogging system containing the campaign updates. Technically it could be a plugin for wordpress to access the dcs-gaming to build an in-game view of the shared campaign.

IDs throughout the system are UUID, not the simple numbers used by other systems. Reason is, that the ID should be generated on first creation of an object and UUID is a nice way to handle that distribution.

Some SCS declare a FoundryVTT API. This API is not defined yet. Objective is to offer FoundryVTT modules to integrate with DCIS to enable game play and make it as easy as possible for players to play Torg Eternity. These modules are not planned yet and will come after the base system.

The SCSs containing data types that are also provided by the torg-codex should provide an interface for the torg-codex to include that data.

There could be a plugin for WordPress to update a shared campaign based on the data given by dcis-gaming.