Wiki data model

Overview

The data model on this wiki serves up information on-demand to guests to our wiki site. Page authors can connect use the data model to serve up large amounts of accurate information consistently across pages.

Because this is the official wiki, the Eremite Games developers provide us with new drops of data every few versions. Our wiki data isn't updated automatically when the game patches, but the data model has been set up in such a way to make incorporating the new data as easy as possible to keep up with the game updates.

Model-View-Controller concept

Pages on the wiki include Templates that invoke Lua modules enabled by the Scribunto extension.

When you write a new page and you use an existing template, that template waits for a wiki guest to view your page. When the page loads, the template invokes a Controller. The Controller knows how you, the author, wanted the data to be displayed on that page because of the template parameters you wrote. The Controller uses your template parameters to determine which data to grab from the Model module(s) and how to organize the data when it is displayed. The Controller then calls the View module(s) to perform the actual layout and formatting of the data, so that it's consistent across pages. The Controller then makes the final assembly and returns what the View wrote, which is what appears on the page.

Data Model

The Model is spread across multiple data managers (modules whose names end in Data) and connected via unique IDs (identifiers) for recipes, goods, buildings, and services. These are separated according to the different data files provided by the developers, but also provide a way for Controllers to retrieve smaller subsets of the data for each page viewed, rather than loading the entire game data on every page load even if only a small section is needed for a given page.

See each module's pages for complete documentation on that module.

Here are the data modules available in our Model. If you need to write a new template with new functionality, you will need to write a new Controller that connects to the Model via one or more of these modules. The primary data that relates these modules together and connect to Controllers are called out.

• Building statistics, including things like construction goods, category, recipes, and icons:
  • Module:CampsData
    • camp ID of the building
    • camp display name
    • good ID of the resource node that are gathered, but the secondary gathered goods are not included in the data
  • Module:CollectorsData, for industry buildings that sit on resource nodes or passively collect
    • collector ID of the building
    • collector display name
    • good ID of the resources collected
  • Module:FarmsData
    • farm ID
    • farm display name
    • good ID of the resource harvested
  • Module:WorkshopsData, for industry buildings and some food production buildings
    • workshop ID
    • workshop display name
    • recipe ID of the recipes available
  • Module:InstitutionsData
    • workshop ID
    • workshop display name
    • recipe ID of the services provided

• Recipe statistics, including goods and efficiency grades:
  • Module:WorkshopsRecipesData
    • recipe ID for production recipes
    • product ID of the good produced
    • ingredients, a list of good IDs required or optional
  • Module:ServicesRecipesData
    • recipe ID for services recipes
    • service display name
    • service goods, a list of good IDs required

• Goods statistics, including whether it is food or fuel, trading value, and icons:
  • Module:GoodsData
    • goodID
    • good display name

Examples

Example from the in-game recipe book

Therefore, in order to display something like what the game has in the recipe book, the Template:Recipe template needs the following data:

• Module:WorkshopsRecipesData
  • recipe ID to match with workshop data
  • efficiency grade
  • production time
  • good ID of the product
  • stack size of the product
  • ingredients
    • groups of alternative ingredients
      • good ID of the ingredient
      • stack size of the ingredient

• Module:WorkshopsData
  • display name of the building
  • recipe ID to match with recipe data
  • icon

• Module:GoodsData
  • good ID to match with product and ingredient data
  • display name of the good
  • icon

This template implements a Model–View–Controller framework. When you write {{Recipe|Biscuits}}, the Module:RecipeController mediates everything. It requests any data where Biscuits is the product from all of those modules, so they don't have to know anything about how the data is displayed. The controller then send piecemeal data to Module:RecipeView which owns all of the layout, and the controller only has to know that it's adding things row-by-row--nothing specific about the layout. The View then returns everything once fully assembled, and the controller sends it directly to the page to display.

Second example

A second example, we also display tables of perks, drawing from Module:PerksData. This also implements a Model–View–Controller framework. You call {{PerkSearch|...}}, and Module:PerkSearchController mediates fetching the data, applying the search logic, and then handing each entry, row-by-row, to Module:PerkSearchResultsView which owns everything about display and layout. It assembles the rows, storing it all until the controller is finished, applies any final layout, and then returns the entire display to the controller, which forwards it without any additional processing back to the page to display.