In the next version of Adaptory, there’s a brand new building: the oxygen generator. My goal for this building is to reflect real-world water electrolysis; that is, turning liquid water into oxygen and hydrogen using electricity.

The new oxygen generator building

But in order to get there, the element simulation needed a bit of a minor rewrite…

(Warning: Technical gamedev post follows!)

The old data model

In Adaptory, every instance of a building or explorer has its own mass and temperature. Some types of buildings and explorers can also absorb mass from the environment, convert it into another element using some conversion process, emit it back into the environment, and so on.

In the old data model, this was achieved by giving each instance a fixed number of optional mass and temperature slots, for each type of stored mass input and output. Slots that were not enabled had to be stored as zeros/nulls:

Old data model, with one mass stored per strategy

My design goal for the oxygen generator meant turning one element into two elements, either one of which could be prevented from emitting into the environment for whatever reason. In the previous data model, this would have meant adding an additional mass and temperature slot to every building, even though most buildings wouldn’t be using it. It was clear a new approach was needed.

The new data model

In the new data model for Adaptory, every building type and explorer type now defines any number of input and output slots, with each slot defining how it works (absorption, emission, piped in, dropped into the world). Each mass packet is also stored immutably, reducing the amount of memory access we need between world simulation frames.

New data model, with any number of input and output slots

Having this extra layer of abstraction has some significant benefits:

  • Building types that don’t have any inputs or outputs (e.g. solid tiles or wires) don’t end up having to store unnecessary data/zeroes. This reduces memory pressure and should make the game faster. (Even though storing lists instead of primitive values does incur an overhead, this overhead only becomes an issue if the average list size is very small.)
  • The new data model allows for buildings to have categories of inputs and outputs (using patterns), rather than a building only supporting a few predefined elements; this paves the way for refinement buildings and enables future modding.
  • The conversion framework is significantly more flexible. We could now have a building that takes a combination of inputs, does a combination of conversions, and outputs in a combination of different ways.
  • This extra abstraction layer should allow for more opportunities to optimise the element simulation in the future. The element simulation is slightly faster (~1-2%) already.