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, Template:Recipe invokes the Module:RecipeController. The Controller makes multiple calls to the model to assemble the following information before sending it to the View for rendering and returning that markup to fill in the template:

• Module:BaseDataModel and (for example) Module:WorkshopsData:
  • building ID
  • display name of the building
  • building icon
  • information for recipes:
    • efficiency grade
    • production time
    • slots (or groups) of single (or swappable) ingredients:
      • stack size of the ingredient option
      • good ID of the ingredient option
    • stack size of the product
    • good ID of the product

• Module:GoodsData
  • good ID
  • display name of the good
  • icon

This template implements a Model–View–Controller pattern. When you write {{Recipe|Biscuits}}, the Module:RecipeController mediates everything. It requests recipes for Biscuits from most of those modules. The data Models never have to know anything about how data is used or displayed. The Controller then sends piecemeal data to the View, starting with Template:Recipe/view, which owns all of the formatting and layout. The Controller never has to know anything about MediaWiki or HTML markup, just that it provides information one recipe at a time to Template:Recipe/view/row. The View then returns the rendered information in the form of wiki or HTML markup, and the Controller returns that directly to the page to display.

Second example

A second example, Template:Perks displays tables of perks, drawing from Module:PerksData. This is also an implementation of the Model–View–Controller pattern. Authors call {{Perks|...}}, and Module:PerksController fetches data, applies the detailed selection and exclusion logic, and then hands each entry, row-by-row, to Module:PerksView which owns everything about display and layout. The View lays out and formats the rows, caching it all until the Controller tells it it's finished, finalizes the display, and then returns the entire display to the Controller, which forwards it without any additional processing back to the page to display.