written by CheerfulGoth and Caligula Caesar
Hello there!
I’m CheerfulGoth, a content designer on Stellaris, and today I’m excited to share the design process behind the Tiyanki Grave Mound that was added in the Fornax patch!
To allow new content designers to familiarize themselves with all aspects of the game, they are usually assigned some onboarding tasks. The Tiyanki Graveyard was a combination of two such tasks: designing a unique solar system with new ships on patrol, and creating an arc site.
Stellaris already includes a massive amount of content, and one of the hardest things as a new content designer is to avoid retelling stories. I decided to focus on space critters, because they have relatively few events associated with them, and most of these haven’t been touched in years. We already have a system where Tiyanki are born, so why not show where they die?
Something that struck me while rereading all our Tiyanki-related content was that killing them allows you to research the Regenerative Hull Tissue, but their superior healing abilities don’t have any narrative impact. This gave me the idea of a sort of ‘elephant graveyard’ full of wriggling corpses that don’t stop growing even if they’re dead.
After getting the main concept approved, it was time to build the event chain. The onboarding tasks required me to create new ship types, so I decided to make some static Tiyanki gravekeepers protecting the arc site. I knew some players would never hurt a Tiyanki, though, and I wanted to keep the content accessible to different playstyles. A special project was thus added, allowing pacifist players to lure away the gravekeepers without hurting them.
Communication between different departments is crucial when working on a team. I wanted my ball of corpses to look the part, but the art team was busy working on Toxoids — so instead of requesting art assets for a minor onboarding task, I experimented with what was already in the game. After all, we already have a perfectly good Tiyanki Matriarch corpse. Why not scale it down and spawn a couple copies around a planet, wrapping it in tentacles?
My first attempts, however, produced… Unintended results:
Space in Stellaris is actually flat: all planets and spaceships are bound to an invisible 2D plane. We can offset the coordinate of ambient objects (decorations) to make them appear above or below the plane, but we usually use this kind of trick only for temporary VFX, like when a planet cracker hovers over a planet.
Figuring out how to wrap a planet in corpses took a bit of experimentation, but eventually we got there!
Once implemented in-game, the content gets tested for bugs by QA. While testing, we noticed a curious issue: the graveyard looked fine when you encountered it the first time:
But if you closed the system view and opened it again…
…It ballooned into a fleshy monstrosity whose size rivaled the Sun!
The cause, as fellow Content Designer Caligula Caesar discovered, turned out to be an obscure bug that resulted in offset decorations being incorrectly sized during initialization.. As mentioned above, we usually use offset for temporary VFX, so this bug has never been noticed since release!
At this point, the art department stared at my work in mild horror and decided it was best to create an unique asset for it. The graveyard looked fine, but smashing ambient objects together is not standard practice and could potentially create performance issues. Nevertheless, the horrible mishmash provided a useful reference for the concept art and the final model:
My graveyard was dismantled, but I hope it will inspire you to create even worse abominations.
Here’s a handy summary on how to offset ambient objects. When spawning an event object, make sure sure to use use_3d_location = yes to be able to adjust its position.
Offsets an object on the horizontal axis (left or right).
Takes both fixed values or a min/max amount (useful for randomly spawning multiple objects in a while block). Example
create_ambient_object = { while = { count = 10 create_ambient_object = { type = “small_dead_tiyanki_object” use_3d_location = yes entity_offset = { min = -10 max = 10 } location = this } }
}
Example Result
Objects spawned with random horizontal offset.
entity_offset_height
Offsets an object on the vertical axis (up or down). Example
Takes both fixed values or a min/max amount (useful for randomly spawning multiple objects in a while block). create_ambient_object = { while = { count = 10 create_ambient_object = { type = “small_dead_tiyanki_object” use_3d_location = yes entity_offset_height = { min = -10 max = 10 } location = this } }
}
Example Result
Objects spawned with random vertical offset.
entity_offset_angle
Offsets the angle at which the object is spawned in relationship to its spawning point. Think of a clock: the base entity is the pivot, while the new objects are spawned around it. Example
Takes both fixed values or a min/max amount (useful for randomly spawning multiple objects in a while block). create_ambient_object = { while = { count = 10 create_ambient_object = { type = “small_dead_tiyanki_object” use_3d_location = yes entity_offset_angle = { min = 0 max = 360 } location = this } }
}
Objects spawned with random angles.
entity_face_object
Automatically rotates the object towards the target.
Scope: planet, fleet, star, this. Example
create_ambient_object = { type = “small_dead_tiyanki_object” use_3d_location = yes entity_face_object = star
}
Example Result
Left group is set to face the star (not in the screen). Second group is set to face this (the planet they spawned from).
base_angle_towards
Determines the default angle of the object in relationship to the base entity.
Scope: planet, fleet, star, this. Example
create_ambient_object = { type = “small_dead_tiyanki_object” use_3d_location = yes base_angle_towards = this
}
Example Result
Both Tiyankis have an angle of 0°. One is set to base_angle_towards = star, and is aligned to its “face” like the planets. The second is set to base_angle_towards = this, where this is a planet with an angle of 180°
No tiyankis were harmed in the making of this dev diary.
——-
But that is not all! For I, Caligula Caesar, have something quite cool to show off, namely some experimentations with galaxy shapes.
We haven’t made any changes to the available galaxy shapes for… I think since release, unless I am mistaken. Anyway, we wanted to spice things up a bit, and took a look at whether we could persuade our galaxy generator to create new shapes.
First we taught it a few new tricks. Now you can define a new galaxy in script and feed parameters into it, and it will be available to select in the galaxy generation screen. This means that when modders inevitably decide we didn’t go far enough in this dev diary, they can make their own combinations without replacing existing ones. It now also doesn’t determine its behaviour based on what the galaxy shape is called. With this I mean, in the current version the 2-spiral galaxy will always have two spiral arms, and you can merely tweak how thick and twisting these arms are – this is no longer the case. Now you can freely define how many arms you wish to have, and also combine them with a ring if you so please.
As a result, we could add a few new shapes. For instance, we could add some spiral galaxies with different numbers of arms:
But there was more we could do. In particular, we wanted to make a few galaxy shapes that would create some unusual galactic terrain, and some potentially interesting asymmetric starts. For instance, we could make a twist on the two-arm spiral galaxy that has very thick, slightly winding arms, resembling a bar galaxy:
Credit: NASA and STScI 
Yes, those two halves are connected by a single hyperlane
A ring galaxy and a spiral galaxy could be combined to make a “cartwheel” galaxy:
Credit: NASA, ESA, CSA, STScI and Webb ERO Production Team 
Alternatively, we could omit an arm of a 4-arm spiral, and create something we dubbed the “hedgehog”:
Finally, in a bout of silliness, I also added the “starburst”, which is a shape that is actually impossible in reality, but might create some interesting gameplay:
Another thing related to galaxy shapes which we’ve looked at a bit is static galaxies. This is the system modders use to generate a specific preset galaxy, for instance certain total conversion mods. It turns out that the code for generating a random galaxy (i.e. those we usually generate) and that used for static galaxies differ completely, which specifically became an issue during galaxy generation: the two different versions of the code probably did the same thing once upon a time, but inevitably the code has diverged, so modders reported numerous issues with static galaxies. For instance, it was not possible to use secondary species, and there were a number of small issues with starting setups, such as starbases and sectors not automatically spawning. It also wouldn’t call the empire_init on_actions, which would cause further divergence from how things would be if a regular galaxy was generated.
Anyway, I probably shouldn’t talk about this, since the code has not yet even been approved, but I tried to combine as much of the random galaxy and static galaxy code as possible, resolving a fair few issues with the latter, and hopefully making it more robust in the future. (Also, on the prompting of a modder, I added the ability to specify “effect = { }” in a particular system’s entry in a static galaxy. And you should now be able to create several static galaxy maps rather than being limited to one).
So, basically, for players who enjoy mods that create bespoke galaxies, you will probably be able to get access to much improved versions of these in the near future. (Can’t promise it will definitely be in the next patch).
