A deeper dive into entities and attributes

Hello! In this previous post, we went over an entities and attributes overview, which hopefully exposed, in a clear fashion, the basic building blocks of the upcoming Ad Lumens "game engine".

In this post I would like to dive a little deeper on exactly how entities are designed, manufactured and what their operational requirements are. Same overall goal:

• Exposing some of the principles behind the nascent mechanics
• Sanity check for me, with ideally feedback sent by leaving me a message or directly on Discord

Chronofagism

The first reality of it all is: this is time-consuming. Very time-consuming. Hopefully the dive we are about to get into will be able to explain/justify it, but several factors kick in:

• "Two step forward, one step backward" very much summarises the qualitative phase I am currently in. That means experimenting, prototyping, trying to anticipate upcoming mechanics problems/incompatibilities between what is and what will problably be.
• Quantitatively is less of a problem, although still a lot to do: this is more about populating content, finding nice, relevant, varied and (hopefully) original ideas
• … while making it all fit inside a clear, solid and logical unified system.

The two entity types this post will talk about are two among around 220 that have been (and are being) designed. I think that illustrates why this (nice and interesting) endeavour is taking so long! Note: this is about 50% of the entity classes, so about as many more will be to work on.

Quick overview of our deep dive

1. We will use two arbitrarily selected entity types, rather different in the role they play. Both belonging to the unit layer
2. We will discover what their slots are
3. We will pick a material used in the crafting of those units.
4. We will discover how attribute emergence works, also using examples and explanations
5. We will briefly touch on what manufacturing them means
6. And finally we will discover how unit-layer entities can run and operate, usually within the context of a higher-order entity

Entity types

We will use two rather different entity types:

• A specific energy generation unit: the Tokamak fusion reactor
• And a specific ship frame unit: the Load-bearing Frame

They are humanly defined as follow:

Their availability is gated behind the following sciences:

Which makes them both entry-level entity types, i.e., ones available at the very beginning of the game.

Their slot definitions is as follows:

Where all masses are expressed in fractions (base/minimum/maximum), and end up being normalised so that their sum == 1.0. As you will see below, mass fraction do have an impact in terms of game mechanics; they are not here only for fluff!

Materials and tags

In order to manufacture/build/craft instances of the two entity types above, a faction needs to use materials. The fact that material themselves need to be crafted is interesting, but irrelevant to this post.

As the previous post briefly explained, materials can be only used to manufacture a unit slot if they have the tag that matches the one assigned to that slot.
Conveniently, the tag STRUCTURE_SUPPORT is used in both entity types (for the slots SUPPORT_FRAME and RIGID_MEMBERS), which is why we will use it for our deep dive.

Our picked material for structure: Titanium-reinforced structural alloy

This alloy, belonging to the entity class MATERIAL_METAL, has the tag STRUCTURE_SUPPORT, so is the one we will use for this example.

This section will be an opportunity to show how materials are generally defined; so even though all the details therein will not be immediately relevant to our dive exercice, it's always nice to get those extra bits, isn't it?

Attributes deserve their own table, as they are common to all materials. In other words: all materials, whether metals, polymers, time crystals or biomaterials, share these attributes.

Important: all material attribute values are expressed as a multiplier of Iron (Fe). This choice was made because Iron is a univeral point of convergence whether energy is added or removed; in many ways, it is also the most stable element in the universe.

This is only 5 attributes out of 44 possessed by all materials; but only those 5 are going to be used in our example.

Player factions will of course be able to manufacture slightly better (or worse!) versions of such materials!

Attribute emergence expressions

Now each of our two example units (the reactor and the frame) also have attributes; these make far more sense in functional/performance terms and are more "macro" in the characteristics they describe.

One universal unit-level attribute is Integrity (ING). By universal is meant that all units have the ING attribute.

This attribute is defined as follows:

One extremely important point: ING, like many other unit attributes, is expressed per unit of mass. Which means it is an intensive attribute. Very logically, to obtain the actual total integrity of a unit, one must simply multiply its ING attribute value by its mass. This then results in an extensive (or quantitative) attribute value!

The ING expression for the reactor

Is defined as:

(2.8e5 
+ 3.6e5 * norm(
    sawhm('STRI', ['PRESSURE_VESSEL','SUPPORT_FRAME']) 
    * math.sqrt(sawhm('COHS', ['PRESSURE_VESSEL','MODERATOR_WATER'])) 
    * math.sqrt(sawhm('DEFT', ['CONTROL_RODS','HEAT_EXCHANGER'])) 
    * (0.7 + 0.3 * sawhm('RADT', ['SAFETY_SHIELDING','PRESSURE_VESSEL'])), 
    0.16, 
    0.40
)) * rho_mod

The ING expression for the frame

Is defined as:

(3.0e4 
+ 3.0e4 
    * norm(sawhm('STRI', ['RIGID_MEMBERS', 'JOINTS', 'LOAD_BEARING_LATTICE']) 
    * math.sqrt(sawhm('COHS', ['RIGID_MEMBERS', 'JOINTS'])) 
    * math.sqrt(sawhm('DEFT', ['FORCE_RESOLVER', 'PREDICTABILITY_OPTIMIZER'])) 
    * (0.7 + 0.3 * sawhm('THSR', ['RIGID_MEMBERS', 'JOINTS'])), 
    0.16, 
    0.30
)) * rho_mod

Emergence explanation

The expressions above of course deserve a little bit of explanation!

First, the values are temporary so can be more or less ignored. What is important is the form of each expression, which I will try and detail here.

The basic anatomy of an expression is as follows:

(BASE + SPAN * normalise(
  DRIVER
  * math.sqrt(SHAPER_1)
  * math.sqrt(SHAPER_2)
  * (0.7 + 0.3 * LIMITER),
  M,
  K
)) * density_multiplier

More details:

Emergence breakdown

First, let's examine a typical driver/shaper/limiter:

norm(sawhm('STRI', ['RIGID_MEMBERS', 'JOINTS', 'LOAD_BEARING_LATTICE'])

This does the following:

1. It picks the slots whose names/symbols are ['RIGID_MEMBERS', 'JOINTS', 'LOAD_BEARING_LATTICE']
2. It takes the materials that were slotted into them
3. For each material (they do not have to be all the same), it picks the STRI attribute as a multiple of Iron
4. It then performs a weighted hamornic mean on each slot on the list of STRI attribute values, thus taking into account mass fractions of the picked slots
5. Then returns the value

Next, let's imagine a crafting design results in the normalise output being 0.5 and the final computed unit densities being within the allowed ranges. We will then end up with the following intensive intensive values

• For the reactor: 2.8e5 + 3.6e5 * 0.5 = 4.6e5 J/kg
• For the frame: 3.0e4 + 3.0e4 * 0.5 = 4.5e4 J/kg

Which, when multiplied by the total desired mass, will result in final ING values for both units.

Why is this time-consuming?

Well, first of all each entity class has to be assigned unit-level attributes (note: I have not really started working on entity-level attributes yet, although those should be quicker/easier as they will emerge from far less moving parts).

Then several things have to be done for each entity type (as children of their respective entity classes):

1. Define the slots
2. Each attribute has to be mapped to an expression (dynamic since each entity type has a unique slot layout)
3. Given ~200 entity types and around 15 attributes per entity class so far (including universal ones)… well yeah… it does take time

But this is all making good progress! I estimate being about halfway through this process; knowing a lot of time has been spent on going backwards and forwards after discovering "problems". Standard stuff :-)

Another complexity layer: crafting time and difficulties

The above various steps illustrate the kind of logic that will be run when designing an entity based on an entity type. In memory data will hopefully make this reasonably quick.

But that is just the design; once that design is saved in the database, etc. a player faction still has to manufacture the unit using its specifications: mass fractions, materials used, etc. Here two main attributes are taken into account:

• MTIM or manufacturing time, expressed in s/kg
• MDIF or manufaturing difficulty, expressed in the engine's internal difficulty class (more on this in an upcoming post)

Both attributes are intensive: they represent the inherent and qualitative difficulty and time to manufacture/craft the unit; to compute the final time and difficulty the engine takes them both and modifies them using the unit's desired mass (obvious) but also the faction's expertise in the manufacturing of such an entity type.

It is still a bit early to talk about faction skills, but too late: in a nutshell, some faction-wide skills (as opposed to crew member skills) will be applied to the manufacturing process, and will allow factions to (non-exhaustive list):

• Manufacture more quickly
• Manufacture more easily
• Manufacture with a higher chance of high quality output

Neat, heh? :-)

Yet another complexity layer: entity metabolism

Now we are happy: we have designed our unit-layer entity and we have manufactured it. So it sits there or what? No of course not, its exists to be slotted into a higher-order entity - for example: a ship!

It's kind of screamingly obvious but it bears repeating: a ship runs on power. Sometimes a lot of power.

But that's okay… this is sci-fi!

But that's not okay as Ad Lumens tries to be almost realistic. :-)

Enter what is perhaps a solution (it certainly looks like it at the moment!): Entity Metabolism.
First of all, even equipment, units, ships, etc. all have metabolisms - the principle is not limited to organic/living units, but is applied to everything that:

• Consumes
• Produces
• … and generates waste

So a human crew member will consume food, atmosphere, entertainment, etc. It will produce work, morale, social cohesion (or lack thereof!), and generate waste (heat, organic, atmospheric, perhaps others). A cyborg will consume mostly energy and perhaps parts? Will produce pretty much what a human does and probably generate only waste heat. All this, for crew members and "smaller entities" is to be determined still.

What is however well under way is the mechanics for larger stuff, namely: units. Now units can be split into broad families when it comes to metabolism:

• Units that generate power by burning fuel
• Units that generate power by harvesting it passively from the environment (no, there are no wind turbines in space, although it is probably a good idea to think about them in atmospheres!)
• Units that store energy and can release it in a system when needed
• Units that consume energy

… all of which will generate waste: heat, radiation, etc. Said waste must be managed lest you turn a ship into radioactive slag. Not good, very not good.

Metabolisms are thus being put in place, slowly… and via unit-layer attributes such as:

All the above are intensive; again, this means that a final unit corresponding attribute will have to be multiplied by its mass, to get, for example, total energy density (for a battery).

Another important detail of metabolism is the route via which resources can be transported. Why? Well to cover cases similar to the following:

• A propulsion engine being fed its fuel via more than one storage unit
• Some units being assigned dedicated power sources; for various reasons: critical support, or to avoid unwanted strain of other systems.
• When a ship or station has several heat dissipation units/heat buffers. In which case the route determines the destination of waste heat.

… and so on. :-)

In conclusion

This was reasonably long and dense so thank you for reading what I hope can start to clarify some mechanics around entity design and manufacturing! As always, please feel free to comment, or drop a constructive feedback message here or directly on Discord.

Sounds complex? Sure it kind of is. But again, my goal is to put in place a complex system that does not feel complicated to use. So anyone would be able to chuck in default values and launch a manufaturing process, without the least care in the world about optimising a unit!