Wysiwyg Wizards Logo
Wysiwyg Wizards Text Header

Codex Commander Data Builder

The CC Data Builder is a java program that allows you to input and manage data in a user interface that can then generate JSON code that is compatible with Codex Commander.

 

It is downloadable on Windows and requires Java to run. You can download the latest version of Java here: https://www.java.com/en/download/

 

Make sure to whitelist the Databuilder as most antivirus will flag this software. The software is perfectly safe however as this is Wysiwyg Wizards first project we havn't obtained a Code Signing Certificate, which would solve this issue.

 

The data builder automatically generates unitID's and optionID's, which is why it is strongly recommended to use the data builder rather than code the JSON manually. See the section on 'Collaborative Data Building And The ID System' for more information.

 

Data building is recommended only for enthusiastic users, as it can be clunky at times and may require the user to edit JSON data manually. Mistakes can cause large quantities of data to be unusable. Furthermore, finding the best way to organise the data can be challenging (deciding when to use equipment lists or if to have certain categories). When using the program, it's highly recommended to use the 'Save JSON' function as much as possible, and create backups of the .txt files.

Data Design and Logic

Note of Diagram Notation:

 

  • Properties with an elipsis (...) denote that they contain a list of objects, rather than just simply number or text.
  • Dotted lines denote objects that are contained within the parent object. For example, there are many 'Category name (text)' objects inside of a 'List of categories...' property.
  • Solid lines denote that the object is a property of a parent object. For example, each 'Game' object has a property of 'Game name (text)'.

 

Notes on Equipment Lists:

 

  • Equipment lists are a way of cutting down data inputting time and processing time. They're used when many units use the exact same options (same name, cost, autoadds). When creating and referencing equipment lists, the name of the equipment list MUST begin with a '$'. This is done automatically by the program when creating a new equipment list. To reference an equipment list, add an option to the unit with the name of the equipment list prepended with '$'. The option cost and autoadds do not matter, so leave them blank.
  • For example: 'Knight', 'Soldier', and 'Lord' all use the options 'Sword', 'Bow', and 'Axe' - where the price and autoadds of these options are the exact same for each unit. Creating an equipment list called '$Weapons', adding the 'Sword', 'Bow', and 'Axe' options to it, and adding the '$Weapons' option to the 'Knight', 'Soldier', and 'Lord' cuts down data inputting time and processing time.

Restrictions:

 

  • Restrictions are currently in development and are not fully implemented yet.

Additional notes:

 

  • Categories can be added to both games and armies. All armies share the same game categories. However, if there's a category that's only specific to that army, then it can be added to the list of that army's categories.
  • When creating equipment lists, the name of the equipment list MUST begin with a '$'. This is done automatically by the program when creating a new equipment list.
  • Currently, the only currency is points. The philosophy of the current design is that it only contains as much data as necessary, and the most popular miniature wargames use points. If there are miniature wargames that have a different currency - then with enough demand that currency will be added to the data structure of Codex Commander.
  • Equipment lists are referenced by each unit, not created for each unit. This means that if one unit references an equipment list, the options in that equipment list will have the same optionID's as the options gained by another unit referencing that equipment list.

Codex Commander at its core is about building lists quickly and easily. Therefore the design of the data is as minimalistic as possible. However, the downside to this approach is that restrictions are a little more difficult to use.

 

This diagram represents the JSON data structure, and its design is aimed to fit the mould of as many miniature wargames as possible, though it is susceptible to change (click to enlarge):

Codex Commander Data Structure

Using the Program

Notes:

  • It must be run as an administrator.
  • The JSON generated by the program is saved to the installation folder under the file 'CCJSON.txt', as well as read from it when launched.
  • The 5 windows follow the hierarchy of the data, where an object needs to be created in order for it's child objects to be created. For example, you can not add an army to a game if there are no games. To select an object left click on it in the window.
  • The 'Generate army files' button creates a folder in the installation directory named 'Army files', and splits the JSON code army by army. This allows the data to be more easily downloaded by Codex Commander as it is harder to download one single large file than multiple small ones.
Codex Commander Data Builder Screenshot

Collaborative Data Building & The ID System

No unit or option can have the same unitID or optionID as another unit or option per game. For example, one game called 'Mages Vs Goblins' has an army called 'Mages' that has a unit called 'Mage' with the weapon 'Staff'. The 'Mage' unit could not have the same unitID as the 'Staff' option's optionID. If another army has the unit 'Mage', it will have to have a different ID to 'Mage' unit in the 'Mages' army. This is because Codex Commander allows different armies to be within the same list, as it can be useful to differentiate units that are identical but from different armies.

 

It is possible for 2 people to work on different armies on the same game for some games. However if the game often requires the user to switch between armies and compare unitID's and optionID's (like with the future restrictions system), it may be best to wait for one army to be done before starting another.

Documentation