Entities preview: focus on energy generation (part 3)

Continued from this post.

Energy generation: metabolism

Generally, a unit's metabolism is defined as:

• What an entity consumes
• What an entity produces
• What an entity generates as waste

Consumption

Consumption is either fuel, power or both. As mentioned in part 1, energy generation units consume fuel, whether Hydrogen, reaction mass or Deuterium-Tritium, etc. This rate of consumption is calculated by multiplying the unit's FCRT attribute (expressed in kg/s/kg) by its mass; this results in a consumption in kilogrammes per second.

The values revealed in part 2 may not seem like a lot; but remember these values are expressed in kg/s per kg of the reactor. So a 1-tonne generator will multiply that number by 1,000 and a year is 31,536,000 seconds so masses are spent quickly!

For example, a more "realistic" main ship fusion reactor is likely to be closer to 1,000 tonnes than 1,000 kg. Which brings its fuel consumption rate to 0.0000000035 kg/s. Going back to our two entity types:

The above example consumption values may seem very low. And in a way they are. But these are reactors, ultra-confined and isolated, built to run things in loops, etc. So someone might think "yeah but then fuel is an afterthought, what's the point?". And perhaps they would be right. But fuel consumption for propulsion is completely different: we are talking orders of magnitude higher and there, fuel is definitely not an afterthought. Ships will have to stock up on fuel, in quantities far from negligible, and manage it: weigh burn rate versus ETA, and so on.

Production

Production output is most of the time a useful resource or scalar, used by siblings. In the reactors case, that resource is RESOURCE_POWER, which will be considered as the main resource for many other unit-layer entities throughout the ship/station/vehicle.

One important aspect when designing a ship is that said ship will be able to host several power sources. The reasons do not really matter: it could be because the designer wants a backup, or again because they feel some power-consuming units should have their own dedicated power source. It does not matter and the choice is free. What matters is that each consumer will be assigned its power source via a route, clearly announcing: "this is where I get power from".

Even though that may seem redundant (haha), the intent is to try (on top of meta design choice) and simulate having very intense power sources dedicated to hungry consumers: propulsion, weapons or defensive systems, perhaps even industry. But then having less "expensive" power sources could be useful for cheaper consumers such as habitats, science & research, perhaps even detection and communication.

Again, the decision is to be taken at design-time and is free.

Waste

Waste is generally something you either want to get rid of or recycle. In the case of energy generation units, the generated waste is WASTE_HEAT, which must be dealt with lest the ship starts to melt. I may have plans for radiative waste too… but first things first, as I am not sure this would bring any other thing than complexity for the pure sake of it.

The attribute ENEF is central to the concept of waste as (1.0 - ENEF) is usually generated as waste heat; so the higher the attribute, the lower the waste and the less one has to invest in thermal dissipation units (which are an entity class in their own right).

Regime

Regime is the "throttling" part of metabolism. Its value is normalised and so comprised between 0.0 and 1.0.

• A metabolism at 0.0 is basically turned off.
• A metabolism at 1.0 is at full load.

However, a metabolism can be cranked up above 1.0. When doing so, several things happen:

• Consumption rates increase. Obvious, but not in a linear fashion. Kinda like more exponential…
• Waste also increases, beyond linearly as well.
• Useful output increases linearly.
• And last and surely not least, the unit may suffer permanent damage. Probably symbolised as ING loss.

So pushing a unit beyond its operational parameters is doable yes, but will be made risky and the resulting penalties largely outweigh the benefits (diminishing returns). Of course Scotty will be glad to assist, and crew member skills will play a major role in such endeavours.

Notes, thoughts, etc.

And that's it for the energy generation entity class! It is of course not 100% finished and needs polishing, but I for one am satisfied with the state it is in at the moment:

• I like its overall flavour: the progression is well spread over sciences, and the energy sources do get a growing sci-fi-esque feel to them as you go up in tier.
• Slots work and the attribute/metabolism synergy seems to work as well!

Of course nothing is set in stone at the moment and I will gladly take feedback, comments, etc. Either via commenting below, by using the contact form or on Discord.

As mentioned in part 1, other classes are pretty much in the same state of advancement, which means that what you have just managed to read through (and I thank you for that :-)) can be multiplied by about 18 to get a feel of how much has been done.

I will try and make the site update worthy of the reasonable "informational density" for those entity classes & types, the attributes, etc. So perhap expect dynamic graphs to play with curves under individual pages, and fore sure later a playground in Tools & Experiments to build ships, drones, stations, etc. And spot the bugs!

A waking dream

Think about the ENIAC and compare it to a modern tool such as mid-range phone.

Here are the (simplified) ENIAC's characteristics versus that phone:

Damn! So Ad Lumens is that: what if humanity managed (when and if pushed to its extremes, and limits) to continue on this path? What if indeed?

Which makes me think that Ad Lumens's scientific ladder and scaling is very very VERY conservative. Ah well, we'll see!

One last thing

This may all seem complicated! And it kind of is, I confess. But the ultimate playability goal is to make this all as seamless and easy to use as possible. Briefly:

• you want defaults values? You can use default values
• you want to spend 1 hour on a design? You can do so as well
• you want your faction to specialise in the manufacturing of entity type XX or YY? You can do so as well.

UX and so on will of course be a challenge (and hopefully not look like a bloated pile of excel spreadsheets), and will try to give visual feedback as often and simply as possible, to get a quick and instant understanding of parameters influence. All a challenge in itself that will come when it comes. The idea right now is to work on the underlying mechanics. :-)