Wartbed:Files/Structure
From Dark Omen Wiki
(→Modules and campaigns) |
(Directory structure) |
||
| Line 22: | Line 22: | ||
:::''Good faction.campaign'' <span style="color:green">- see campaign format below</span> | :::''Good faction.campaign'' <span style="color:green">- see campaign format below</span> | ||
:::''Evil faction.campaign'' | :::''Evil faction.campaign'' | ||
| + | :::'''Resources''' <span style="color:green">- Additional resources common to all campaigns under the module</span> | ||
| + | :::'''Good faction''' <span style="color:green">- Additional resources common to all campaigns under the module</span> | ||
| + | ::::'''Resources''' <span style="color:green">- Additional resources specific to the campaign</span> | ||
</tt> | </tt> | ||
Revision as of 20:24, 31 October 2009
| Note: | This article is ahead of itself. It does not represent how WARTBED currently looks or a decision as to how it will look. It is written as a guideline and as a place to jot down ideas. |
Also see WARTBED file formats article. |
WARTBED main folder
- bin - Executables and libraries
- (bin_d - Executables and libraries for debug build)
- cfg - Currently only contains application.config
- resources - All common resources and assets
- modules - All game module description files and data folders
- Example file.module - see module format below
- Example module folder
- Good faction.campaign - see campaign format below
- Evil faction.campaign
- Resources - Additional resources common to all campaigns under the module
- Good faction - Additional resources common to all campaigns under the module
- Resources - Additional resources specific to the campaign
Modules and campaigns
Modules are large-scale settings. Though intended to represent game remakes (f.i. Bright Portents and the Saga modules are modules implementing Dark Omen and the Myth games in WARTBED) they can of course be totally new games. Modules in turn contains campaigns which are sequences of connected battles within the setting of a module. Modules and campaigns also allow basic customisation of the WARTBED framework, for instance of user interface appearance etc.
All .module and .campaign files must specify a qualitiative name and a version, both of which are strings, and must further specify the folder that represent their local roots (the module path is always relative to the wartbed root/modules directory, and the campaign is always relative to the module root directory). Further, these files may specify an interface file detailing the graphical interface used (if none is given, the interface defaults to the module's or WARTBED's default one) and a homepage string that can be displayed if version dependencies fails.
The .module file
- Should be moved to the Files/Formats article
The .module file defines a module that can be executed in WARTBED (and provided as a parameter to the executable). Module files may only be placed in the modules directory under the wartbed root directory. It describes the name, location and any toggles to global WARTBED rules. Modules may require (depend upon) other modules for data etc.
(text file)
folder = RCTFE/
version = 1.0.0
requires = another module
requires = yet another module
interface = filename.xml //optional
homepage = www.mywartbedmodules.com //optional
Rules section goes here...
The .campaign file
- Should be moved to the Files/Formats article
Campaigns are settings (sequences of battles) in a module. Campaigns may depend on other campaigns and modules. (It has not been decided whether campaigns may depend on campaigns in other modules).
(text file)
version = 1.0.0
folder = good guys/
requires campaign = another campaign
requires module = still another module
interface = filename.xml //optional
homepage = www.mywartbedmodules.com //optional
More stuff will go here...
Dependencies
The dependency can be specified either by filename of the module file, including the trailing .module extension, or the qualitative name of the module.
A possible alternative for the requires format could be a block like
requires
{
module = a module.module
campaign = evil guys.campaign
}
If slashes are forbidden in module names, a module and campaign dependency could be written as
requires horror monsters/vampire fest requires horror.module/vampires.campaign
This last syntax is more difficult to combine with version control, though, and would require something like this syntax:
requires horror.module version:1.5 / vampires.campaign
Alternatively to the requires module and requires campaign tags above, the dependency could be resolved by filename extension.
