Hives, wasps & leviathans

The v0.6.0 version unleashes the first spacegoing forms of life.

In this cycle, a fair bit of time was spent refactoring ship modules to be usable with other entity types as well. Adding a module to an entity now requires adding it to the struct that holds its data members, and registering the byte offset of the module inside a table. This table is zero-initialized, so zero is considered a safe invalid value for a module because entities never have a module at a zero-byte offset (they have their type information there). I guess you could think of this as a crude form of a static entity component system.

This means that a lot of entity-related functionality on both the server and the client sides can now be expressed generically, without constraining the type of the entity. For example, the host device event handlers were all rewritten to work with modules, not ships. Also, clients can now use navigation and drive modules to integrate entity positions more accurately, reducing jitter from acceleration.

Hives are ancient, sprawling structures found at regular intervals, buzzing with calculated self-replication. They send wasps towards barren worlds to secure and exploit inorganic raw materials.

Wasps are non-sentient forms of machine life assembled in hives. A wasp flies out towards a barren world to guard and extract inorganic raw materials from it. Launches stingers at hostile entities that come into the range of its sensors, but will not deviate otherwise from its purpose.

Leviathans are immortal creatures of the void exhibiting deep-space gigantism. Suspected to be non-sentient, they are hostile to all other known forms of life. They wander the universe randomly, and they avoid deep gravity wells. If their hull is destroyed, they fall into a dormant state to regenerate it.

Stingers are projectile weapons launched by wasps that damage the targeted entity’s hull upon impact. They expire and self-destruct if they do not reach their target in time.

Also, now that there are some entities moving about and querying the world around them, I got curious about performance. While I’m uncomfortable sharing numbers that will not reflect your configuration (due to hardware) and will increase both in the future (as the world grows denser and more complex) and with the number of connected clients (as the server needs to spend time synchronizing with them), I still think there are good reasons to record these numbers here.

Running on an i3-10100F, compiling mods with gcc and -O1, starting a server, logging in, generating a world, and waiting for wasps to fly out, the time taken to tick the world climbed up to roughly 2 milliseconds in release mode, and 3 milliseconds in debug mode. For a server that ticks 10 times a second, this means about a 2-3% load (currently running on a single core).

I got curious about these numbers because I would like servers to be able to run on efficient, low power CPUs, such as ARM Cortex and Intel Atom processors. For example, running the current world on a Cortex-A72 (4-core, 1.8 Ghz), I could expect performance on a single core to be 4-6x worse, resulting in a 10-15% load, which makes me hopeful that there’s still room to grow.

Note that while performance seemed even, the measurements showed spikes every few ticks, because the cpu frequency scaling governor on my linux machine was set to schedutil. When measuring performance, make sure to set your governor to performance temporarily to make it avoid dropping cpu frequency at low loads, which skews measured times by about 3-5x in my experience.

Other notes:

• the client now uses a color palette, removing many repetitive color conversions
• the client now integrates position and point physics from navigation and drive modules
• some host device event commands were renamed and moved to different indices
• some utility functions were generalized to help with concise entity logic
• troph simulaition updates are now staggered, spreading out their performance spikes
• ships are now spawned with a slight random offset from the origin
• entity addition and deletion queues were added for the server
• controller keybind conflict for GL_GAMEPAD_BUTTON_DPAD_DOWN is now resolved