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 Models

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, to see when it was last updated, and to find which data file it loads so you can see when that was last updated.

List of Data Models

• Building data, including things like description, construction costs, category, recipes, and icon:
  • Module:BaseDataModel, an abstract class that specifies three important interfaces for querying building data models and also provides default implementations for the interfaces. See the luadoc at the top of the module for the description of the interfaces and list of methods. The following are instances of BaseDataModel:
    • Module:CampsData, for the Woodcutters' Camp.
    • Module:CollectorsData, currently blank but should include the Mine in a future update.
    • Module:FarmsData, for everything that grows things on Farm Fields.
    • Module:FarmFieldsData, for Farm Fields themselves.
    • Module:FishingData, for the small and large Fishing Huts.
    • Module:GatheringData, for gathering camps that work deposits on the map.
    • Module:HearthsData, for the Ancient and buildable Hearths.
    • Module:InstitutionsData, for service buildings.
    • Module:RainCollectorsData, for the Advanced and regular Rain Collector.
    • Module:WarehousesData, for the Main and buildable Warehouses.
    • Module:WorkshopsData, for industry buildings and some food production buildings.
  • Module:BuildingDataProxy, a utility class that federates method calls to all building data Models, providing an extra layer of indirection between Controllers and the Models. Useful when aggregating data across all building types or when you only need information from the basic building interface. Expensive for some data, because it naively loads the data models one-at-a-time until the right one is found—better to choose the Models you need whenever possible.

• Goods and services data, including category, whether it is food or fuel, trading value, and icon:
  • Module:GoodsData, currently stores all information for all goods.
  • Module:ServicesData, currently no more than a shortcut model that actually references data in Module:InstitutionsData but in a way that mimics GoodsData.

• Perks data, including description, sources, and icon:
  • Module:AltarEffectsData, for all Stormforged Cornerstones.
  • Module:MysteriesData, for all Forest Mysteries.
  • Module:PerksData, for all Cornerstones.

• Species data, including resolve parameters, specializations, and icon:
  • Module:SpeciesData, for the species themselves.
  • Module:SpecializationsData, currently a hard-coded data set that can be used directly by Controllers.

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.