A brief exchange with a user raises good questions
Last changed on
Yesterday blackcat sent me an email, asking a couple of questions about Adlumens. I asked him for his approval to publish a translated version of our brief exchange (the original was in French), since I felt it did raise some interesting questions, what's more from angles I felt I had not necessarily thought strongly enough about. :-)
The message from blackcat
Hi,
I am contacting you because I cannot publish any comment. I met the same error as the login issue: "No challenge token, please try again". I tried to apply the same procedure, but to no avail.
I would like to ask you two small questions:
- Will the game be long-lived (for example like OGame) or will it be shorter (as for Stellaris)?
- Ship movement: will this be as realistic as the rest of the galaxy (such as using Tsiolkovski rocket equation [link mine] for physics, etc)? Similarly, will ship construction be modular like in Aurora 4x, or will it be "simpler" and target a large(r) audience, leaving space for other gameplay aspects?
Again, congratulations for this extraordinary work!
Have great day,
[REDACTED]
Handmade translation, hopefully reasonably close to the original. Tradutore, Traditore.
Adlumens's answer
I got the approval for this one.
Hi!
Argh, I really need to fix these Cloudflare tokens issues! My apologies…
Interesting questions -- I hope my answers will be as well!
Game duration
If I ever manage to support everything for a MMO (design, hardware, etc), then games will be long. Very long. Or potentially very short depending on choices made by the player (aggressive, constantly at war, etc). However I am currently focusing more on rhythm than duration; in other words: whatever the "endgame" is, at what speed can it be reached? 1 week? 2 years? What for? What to do during and after this endgame?
Whatever the above, the base idea is about managing a population limited in numbers (at most a few hundred people). Population can of course evolve during the game and grow by orders of magnitude. With all the challenges this represents in terms of management and playability!
Game realism
I am trying! But my goal isn't to create a "pure" simulation. so Δv, reaction mass consumption and others will of course be taken into account, but in a more "abstract" way, that is, after being translated to game engine values.
The reasons for this are both simple and not-so-simple:
- pseudo-realism remains one of my objectives, but not if it means sacrificing good old science-fiction :)
- how to build a game engine able to handle both pseudo-realism and actions/possibilities that are completely crazy and belonging to the domain of utter science-fiction?
For example: "how much Hydrogen do I need to move my ship from planet A to planet B?" versus "fold space-time as a defensive action against an attack of a topological nature"
Another example: "travel to the asteroid belt X will take 4.5 months [almost realistic, beginning of the game]" versus "perform a Void jump from planet A to another star system 45 light years away [ingame travel time: 5 days, endgame, pure science-fiction]"
The interesting problem is finding how to handle the whole spectrum [near future [pseudo-realism] -> all the way to the distant future [completely off chart]]?
These examples are completely arbitrary but illustrate the immense chasm that separates base technologies from the endgame ones. The difficult thing is that this whole spectrum of actions must be based on common foundations!
Food for thought… :-)
Ship/station/other complexity (?)
For this the answer is quick: it will be very complex. ;-)
My issue is then:
complex != complicatedI am currently in the middle of the "design phase": database normalisation (my "Brejnevisation"), entity recursiveness, etc. It is an extremely interesting (and fun!) phase, but I try to be demanding about how it feels overall; the result is this is all rather time-consuming.
Currently on the menu:
- research on sciences themselves, but also blueprints, etc
- manufacturing processes with components, options
- modularity which I hope will be extreme! with almost limitless customisation options
- attributes, skills, stances and ingame actions
Thank you and have a great day too!
[REDACTED]/Adlumens
Perhaps a more complete series of answers…
I thought I might expand a little on my answer which - before and after translation - feels a little bit… deconstructed.
Elephant in the room number 1: yes this Cloudflare token is an issue that I must tackle. But I cannot deactivate it for fear of being absolutely flooded with crap from bots (which are around, believe me).
Elephant in the room number 2: thank you for using the word "extraordinary". That is indeed very nice to read :-).
Game duration
To be blunt: I am not sure the concept of game duration is even the right one. You see, we are not talking about Counter Strike rushes or World of Tanks rigged-MM (joke) 15-1 purples/tomatoes games that last 2 minutes versus lengthy, sometimes weeks-long godmode games on CIV or Stellaris, etc.
No, because to me at least, the concept of game duration implies that the world has a duration. That, when your game is finished, the world in which it took place is finished as well, whether you win or lose. Whether the "map" is static, fully procedural or a mix in between, that remains true.
Since Adlumens's world is persistent and the world is the game, the game is persistent and so has no duration.
Which is why, in my answer above, I mentioned rhythm as perhaps a more relevant take on things.
However, game duration can also mean how long does my faction remain alive?. In which case yes, duration has a completely valid meaning.
All in all, I would say player objectives and behaviour both dictate rhythm and duration:
- if a player is stuck to his screen, his rhythm will naturally be more intense than that of a casual player.
- if a player chooses to be aggressive towards other players (piracy, etc), that's his choice; but this choice will potentially shorten his game because I do plan on making combat deadly, brutal and final, especially at early tech levels. So pick the wrong target and pay the price.
- all of the above being cadenced by the game engine, whose rules cannot be gone around.
That's all great… but what does that mean for a future game?
It still remains to be determined, as I believe an overall feeling will emerge when the engine is born. I know I wrote earlier that the game will not be fast-paced and I stick to that. However, you can never anticipate the truths, problems and deviations that unmistakably emerge from implementation:
- mechanic A was designed in a specific, thoughtful way and yet feels too fast or easy; or too hard and slow;
- mechanic B has a real-world duration problem because it lasts for too long and frustrates players.
etc, etc. The list can probably be endless. The good thing is that the engine will be 100% data-driven, so changing value A or B will not be complicated. See below for a bit more on this. :-)
Caveat
I do plan at some stage to offer "sandbox-like" galaxies/worlds that would enable players to play either alone or in the company of a restricted group of other players, in their own private galaxies. These galaxies would be more controllable in their nature and size.
In this case perhaps game duration would have more of a meaning; since galaxies could very well come and go at the whim of players, who could very well choose to "end the game" forever, which would probably destroy the galaxy along with the factions that existed inside it, etc.
This is something I discussed with another user, so there might actually be demand for it. Another idea on top of it is scenarios/campaigns: where the "main" player would play more like a gamemaster/storyteller and guide/direct NPC factions against or with player factions. Some kind of demiurge able to customise his own galaxy and hopefully in a way that other "actual" players can enjoy.
The feasability of all these NPC-related game modes/extensions is of course heavily dependent on LLM usage.
A lot of work to be sure…
Game realism
There is this principle that Adlumens embraces, however futile it may feel from the outside: suspension of disbelief. The test today is to create several facets in the world, the angles from which you can see it and interact with it, that make one believe "yeah this actually could work". The whole house of course collapses as soon as a serious scientific mind scrutinises it: for example, the procedural universe - it is quickly apparent that it is full of holes, imprecisions, dirty shortcuts and outright impossibilities. But that's ok, we are not trying to build a simulation!
Once someone adheres to the base universe (whether procedural or scientific via the Tech tree), a lot of work is already done, as suspension of disbelief is at least partially entrenched.
I have tried so far to build things that reach this very important step. To each his own of course, and many people will simply and naturally reject what I've done. And that's fine, they will consider Adlumens as 100% science-fiction and imagination, which hopefully (and if they so choose) will not ruin their experience of the (future) game.
The way I have tried this is principally via:
- Usage of SI units: seeing a reactor output displayed in Gigawats, a population expressed in actual number of people, a planet's atmosphere described in Kelvin and Pascals do help. As opposed to:
Reactor Power: 2,City population: 12andAtmosphere class: 43. Or whatever. These are abstractions which, even though they work perfectly well when used by their respective games, are counter productive for what I want to try and do. - Scientific research: starts at knowledges that are all very familiar to us. This I believe contributes to immersion. Later, these knowledges/sciences gradually evolve towards far more advanced/alien versions, by which time hopefully the brain is hooked thanks to continuity. Hopefully. :-)
Again, this all may seem futile but is actually very useful when working through design, content, database structure and whatnot. A bit like a compass. :-)
Assuming suspension of disbelief has settled in, Adlumens can afford the luxury of gradual divergence from what's real. This is when truly science-fistionesque stuff start to appear, the imagination can run wild and personal tastes/vision/dream start kicking in. SI units are still used, but at scales that are today only mentioned in Kardavashev-scale types of contents. We are talking about 10 to the power 21+ W power generators as standard power sources, worries about continuity instead of death, mind-merging, topological control of space-time and many others.
The stuff of wild dreams. :-)
Adlumens does diverge from pseudo-realism way before such end-game content can be played with, though. Quickly checking the Tech tree allows to spot that divergence as soon as tier 2 or 3 are reached. Or at least that's how I feel about it. Again, to each their own.
Currently on the menu
Blackcat's email was actually very very, VERY timely. :-)
Why? Well because I have reached point where I feel I can start giving perhaps a high level overview of the nascent game engine. Its main skeleton has reached a stage that satisfies me and perhaps more importantly, seems to be able to support what I want it to do.
Entities
In the game engine, everything that is not a scalar is an entity. If it can be:
- Built
- Scanned or analysed
- Destroyed or damaged
- Carried around or transported
- Traded
- Jettisoned
- Part of a bigger whole
- Used as an ingredient in a "recipe"
- Intercepted
- Read or written
- Moved from one place to another
- Used to influence movement or nature
- Extracted or refined
- and many others…
… then it is an entity!
Almost: there also needs to be all the "glue" around entities to make them interesting and interactive.
So given what entities can do and be subjected to, how do they manifest ingame? I think the easiest way to answer this question is to show a very initial (and temporary) list of ship/station components, from the PLATFORM_STRUCTURE and PLATFORM_LIFE_SUPPORT entity classes. Here goes:
| Class | Name | Symbol | Description/notes |
|---|---|---|---|
PLATFORM_STRUCTURE | Load-bearing frame | FRAME_LOAD_BEARING | Low-tech ship frame; mass limited by structural strength; mass is not only pure mass but mass subjected to acceleration/deceleration; max mass depends on materials |
PLATFORM_STRUCTURE | Inertial stress frame | FRAME_INERTIAL | Frame mass limited by materials too; but vastly increased resistance to forces; max mass depends on materials |
PLATFORM_STRUCTURE | Field-suspended frame | FRAME_FIELD_SUSPENSION | Fields offload structural stress, including forces; mass limitations much less; so exotic/degenerate materials can be used |
PLATFORM_STRUCTURE | Photonic truss frame | FRAME_PHOTONIC | Lattice of light-guided struts using photonics for load-bearing. Photons "stiffen" flexible beams on demand. no mass, which is nice. but then what impact? optional photonics for wavelength-tuned rigidity. Low maintenance. |
PLATFORM_STRUCTURE | Sectional hull | HULL_SECTIONAL | The most primitive form of deep-space shielding, consisting of standardised industrial plates mechanically fastened to the frame. Individual sheets of alloy or reinforced polymers are bolted, riveted, clamped or arc-welded onto the skeleton. Every intersection requires a synthetic gasket or sealant to maintain atmospheric pressure. |
PLATFORM_STRUCTURE | Monolithic composite hull | HULL_MONOLITHIC_COMPOSITE | The pinnacle of static material engineering, where the entire exterior of the vessel is forged or cast as a single, seamless part. Using massive industrial foundries or molecular growth vats, the hull is created with a perfect, continuous crystalline lattice. There are no bolts, no welds, and no seams. |
PLATFORM_STRUCTURE | Swarm membrane hull | HULL_SWARM_MEMBRANE | Nano-bot swarm encased in polymer envelope; reforms on damage. Fluid-like repair; default: swarm patching; plug-in: micro-electro mechanical systems for bot coordination. Fills dynamic swarm evolution from fluid hull. |
PLATFORM_STRUCTURE | Quantum braced frame | FRAME_QUANTUM_BRACED | Entangled braces link frame nodes via quantum mechanics; stress on one instantly reinforces all.; Near-no mass limit (virtual bracing); default: superposition load-sharing. |
PLATFORM_LIFE_SUPPORT | Waste recyler | WASTE_RECYCLER | mechanical shredder; |
PLATFORM_LIFE_SUPPORT | Adic molecular disassembly unit | ACID_MOLECULAR_DISASSEMBLY_UNIT | Acid bath: Polymer-lined basin with chemical mixers; Dissolve materials into ions (salvages 50% atoms from scrap). |
PLATFORM_LIFE_SUPPORT | Water processor | WATER_PROCESSOR | Bioplastics mesh stack in polymer housing; leap from boiling to multi-layer filtering for contaminants. upgrade: osmotic membrane; more purity and thruput; then: Electrodialysis (Nanocomposite ion exchangers in polymer cells) |
PLATFORM_LIFE_SUPPORT | Catalytic atmospheric processor | ATMOSPHERE_PROCESSOR_CATALYTIC | Polymer catalyst beds in composite housing; Convert pollutants; better filtration. |
PLATFORM_LIFE_SUPPORT | Cryosleep module | CRYOSLEEP_MODULE | Bioplastics insulated pod with polymer coolers. Freeze crew in ice matrix.; no “in=sleep” health checks; upgrade to get some. upgrade: healing WHILE IN CRYOSLEEP; upgrade: neural connection so mind can be kept active (learning, sanity stabilisation, etc) |
PLATFORM_LIFE_SUPPORT | Vertical tower hydro farm | HYDROPONIC_FARM_VERT | vertical flow for space-saving. produces compact fruit; |
PLATFORM_LIFE_SUPPORT | Food synthetiser | FOOD_SYNTHETISER | first version is: compose ingredients; later: grows stuff on its own; overall food tiers: SLUDGE (algae/gel), BASIC (roots, grains), GOOD (berries, herb, fish), LUXURY (real meat, eggs, nuts, fresh fruit) |
PLATFORM_LIFE_SUPPORT | Tank cultivator farm | ALGAE_FARM_TANK | ~500 litres of brine, green algae; high o2 generation; strain manipulation (lipid++) for more quality; better photoreactor for better yields |
PLATFORM_LIFE_SUPPORT | Escape pod module | ESCAPE_POD_MODULE | 24h life support, with water. cryogenics/statis field can be integrated; thrusters can be added |
PLATFORM_LIFE_SUPPORT | Incarnation chamber | INCARNATION_CHAMBER | For consciousness threads/avatars |
PLATFORM_LIFE_SUPPORT | Noetic bay | NOETIC_BAY | mind regen; resurrection; experience merge; "birth" and "death" of minds. noo-related |
BIOLOGICAL | Base human | HUMAN_BASE | A well-known arrangement of molecules. :-) |
These are all entities destined to become part of a larger whole, most likely a ship, station or surface/atmospheric colony. I have not included all my notes, that would be too long and defeat the point of this post.
Attributes and skills
All entities share the same 14 attributes. These represent the values inherent to an entity along several dimensions (a bit like aspects in the Tech tree). As of writing this, the database contains the following attributes, which I will not detail too much just yet:
| Name | Symbol | Description/notes |
|---|---|---|
| Tier | TER | The approximate tech level the entity belongs to. Useful for scans, reverse engineering, etc. |
| Power | PWR | Represent physical power in general |
| Precision | PRE | Overall agility, precision or accuracy |
| Processing | PRO | General ability to process information |
| Stability | STA | Overall resistance to overload, panic. |
| Influence | INF | General ability to project around in the environment |
| Interface | INT | Inherent quality of communication with the outside world |
| Integrity | ING | Reflects overall physical status |
| Load | LOD | Stress, strain or load |
| Coordination | COO | Degree of coordination, cohesion or integration |
| Reliability | REL | Overall ability to be replied upon |
| Readiness | RDY | Reflects overall metal/informational state |
| Age | AGE | Age in seconds |
| Longevity | LNG | Represents how long the entity will exist before showing signs of failure |
The good thing is that those attributes can be used to describe/stat human beings, engines, ships, weapons, data, cyborg and drones, anything really. But again, since this is all database-powered, the list can change and probably will!
Skills represent the taught components of an entity. My current list is in even drafter status than the rest so I will not show it here today. Just know that there are currently about 50 skills and 250 different stances linked to them.
Capabilities and relationships
Something is still missing though: we know what an entity is, but not what it can do! This is where capabilities come in such as:
- Ability to deal and resist damage (thermal, kinetic, radiative, biological, etc.)
- Contain other entities (cargo, crew, fuel, passengers, etc.)
- Consume and generate other entities: Power, resources (which are entities) at a known rate
- Capacity to move, accelerate and decelerate
- Capacity to detect and evade detection
With the above we will already have a wealth of options, which start at the bottom with the relative wealth of resources offered by the procedural universe.
Actions
Are the final glue (for now), and kind of describe the subject/verb/adverb/object syntax of everything that can occur in the game.
In closing
That's it for this post, which was longer than I expected. :-) Others will come as I feel importan(ish) stages are reached in the design and coding of this thing.
Please signin to add your comment.