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 almost every version. 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 uploading and automatically propagating changes from new data as easy as possible.

Model–View–Controller concept

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

Most of the data-driven parts of this wiki are implemented in a Model—View—Controller design pattern.

When authors include a template in an article, the template waits for a reader to visit that article. (Templates do not pre-compute anything.) When the page loads, the template invokes a Controller. The Controller knows how the author wanted the data to be displayed on that page and which data to display because of the template parameters. The Controller grabs data from one or more Model modules and re-organizes it to suit the purposes of the template. The Controller then calls the View template or module, which lays out and formats whatever the Controller gives it. The Controller then makes any final adjustments, but usually just immediately returns what the View made. This is what appears on the page.

Data Model

The data is spread across multiple Models (modules whose names end in Data) and related via unique identifiers (IDs) for goods, buildings, and effects like perks. There is one Model for each of the different data files provided by the developers, so that each Model can own its data file. The Models own retrieval, sorting and reorganizing, and serving queries for information from Controllers. This means that Controllers do not retrieve entire data sets, but smaller subsets of the data—ideally the minimum necessary per page view, rather than loading the entire game data on every page load even if only a small section is needed for a given page.

Here are the Models on our wiki. If you need to write a new template with new functionality, you will need to write a new Controller that connects to the appropriate Models and a new View to standardize the display of that information and make it easily maintainable. The primary data dimensions that relate the data together across Models are called out.

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

• 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.