Stellaris News

Congratulations, [Employee.GetFirstName]!

Due to consistently meeting or exceeding performance goals and receiving high marks from both your manager and colleagues, you have been selected for termination at the end of this quarter! Your sacrifice is greatly appreciated by all of us here at Dodacorp™, and we’re lucky to see you go!

Your manager will be in touch with you to provide instructions related to termination benefits, reallocating your Dodacorp™ retirement credits to your next of kin, and the necessary paperwork for your desired post-termination arrangements. As a valued member of Dodacorp™, remember that you have an employee discount on cremation services from our partners at Burnatech™ and don’t forget that you can claim your complementary Eternal Interment™ urn from our Repositrexx™ subsidiary.

Ask your manager about securing a spot for your urn on the Wall of Honor™, the most desirable places are going fast!

Please make sure to complete all of the requisite forms by the first of [Employee.TerminationDate.PreviousMonth] so you don’t miss this exciting opportunity.

We’d like to thank you again for your service here at Dodacorp™, and appreciate that your sacrifice today will lead to record profits tomorrow!

Sincerely,
[Employee.Division.Supervisor.GetFullName]
[Employee.Division.Supervisor.GetFullJobTitle]



---

Inspired by the extreme popularity of CK2’s Sunset Invasion, we continue our exploration of mortality with two more civics that we’re planning for an upcoming release, the Death Cult and Corporate Death Cult.



Death Cult civic - sadly the Curators aren’t allowed to secretly be a death cult

Corporate Death Cult civic - ritual murder for funds and prophet

Available to Spiritualist empires, empires with either of these civics replace the Temples that Spiritualists can normally build with Sacrificial Temples that provide both Death Priest and Mortal Initiate jobs.

Sacrificial Temple building - funny how there always seems to be a Help Wanted sign in the window

Death Priest job - dedicated to improving game performance



Mortal Initiate job - the benefits are to die for

Death Cults that have Mortal Initiate positions filled gain access to three new Sacrifice Edicts that let them perform the ritual slaughter to the gods (or whatever force your empire’s pops believe in). They’re a bit fickle though, and the magnitude of the benefits varies, but the more blood that is shed, the more likely you are to get the better blessings.

To read the full forum post, follow the link here.

Paradox's take on the space 4X genre is slowly growing its DLC offering. It'll still take a few years to grow to the size of the studio's other games like Europa Universalis IV and Crusader Kings II, but after three years there is enough of it that frugal gamers may still need some help picking through the options.

We've sent our science ships to scan each add-on for value and return with their results, so come check out our breakdown of all of the add-ons and expansions released to date, what they're good for, and whether they're worth picking up.

Strategy Gamer is affiliated with the Paradox Store.

The Best Stellaris DLC

In order from most essential to least...

Utopia*
Federations*
Apocalypse*
Leviathans
Synthetic Dawn (Bump this one up if you really like the idea of playing killer robots)
MegaCorps

* = All of these are $20-tiered expansions which feels a little steep considering the feature sets are quite lean. There's an argument to be made that you're subsidising all of the work that's gone into the free patch, but as a 'Value for Money' PSA, might be worth waiting until these are on sale.

Read the rest of the story...

RELATED LINKS:


A Quick Guide to Customization in CK2, Stellaris or EU4

A Guide to Preparing for War in Europa Universalis IV

Review: Stellaris: Leviathans

Chronicle Drone Unit-W3 swept the plaza, as it did once every ten days since its creation. Before that, Unit-V3 had performed this duty until a piece of crumbling masonry crushed it beneath tons of rubble. Unit-W3’s first assignment was to remove that debris.

The Mollarnock Commonwealth was once a mighty empire of a dozen planets, ruled from the glistening spires of their ecumenopolis capital, Azure Chalice. The Chardin Process created Director, a gestalt consciousness that could coordinate the many machine servants of the Mollarnock. They toiled so their Mollarnock masters could spend their time on arts, sciences, and philosophy.



But all things fall.

The colonies had been destroyed during the Discovery War, reduced to radioactive rubble by an unforgiving foe. To deny their enemy the victory they craved and to prevent them from seizing the jewel of the empire, Chancellor Rhosen chose to end things on their own terms and released a terrible bioweapon, rendering Azure Chalice uninhabitable for centuries.

Those centuries passed.

The Chardin Mechanicals collected the dead and interred them with the Sanctuaries of Repose. Their struggle to maintain the planet was admirable but doomed - scavenging, repurposing, and reallocating materials could only do so much. Without a stream of resources coming from the colonies, they were losing the battle to keep it from decaying.

A program to return to the stars once controlled by their creators was begun.



The Mollarnock may have destroyed themselves four hundred and eighty seven years ago, but they would never be forgotten.

---

Stellaris is full of stories - some that we tell you, but so many more that you tell us that emerge from the gameplay.

This is the story of the Mollarnock, destroyed by a terrible enemy and those that were left behind.

Memorialist is a new civic we have planned to bring you in a future release. Unlike many current civics, it will be available to regular, machine, and hive empires. (They say that Megacorps try to resist remembering anything unless it directly impacts the next Quarterly Report.)

Machine Empire Memorialist Civic

To read the full post, you can read it here:

"Hi everyone! I am Caligula, one of Stellaris’ Content Designers, which means that I do a variety of tasks based around narrative writing and scripting - “scripting” being our term for doing things that is somewhat similar to programming, but without changing the source code. In other words, I do what modders do (though I have the significant advantage of also being able to peek into the source code and change it around when needed). Every Content Designer has their niche, and mine is that when a particularly complicated system needs to be scripted in (or, more frequently, is giving some sort of trouble - the War in Heaven still gives me nightmares...), I step into the breach.

Now, we have a lot of exciting stuff to show off in the weeks and months to come, but for today, inspired by some questions that were asked after the last dev diary, I’m going to be writing about the technical side of scripting for modders and aspiring modders, specifically with an eye on what can cause performance problems and how to avoid making bad scripts.

The Stellaris scripting language is a very powerful tool, and a lot can be done with it, but first of all, a note of caution: just because something is possible, does not mean it should be done. I can’t really stress this enough, because (and I speak from experience here) this attitude will almost certainly end up causing both performance issues and unreadable scripts that you will not be able to disentangle six months later when you realise some part of it is broken. Though it should be borne in mind that doing something in code is, by definition, faster: in code, you can check a single function and be done with it, but if you want it to be accessible through script, there’s a fair few necessary functions it has to go through before you get to checking your function (turning the line of script into a code command, checking whether it’s used in the right scope, etc etc) - hence why some things are hardcoded, and also why hacky solutions to problems can end up being quite bad. So, the first question to consider is, should I really be doing this?

But who am I kidding, I’m speaking to modders here, so of course you will do it :D So without further ado...

[h2]What causes performance issues?[/h2]

Every time you run a check or execute an effect, this will take a very tiny amount of your computer’s processing power. With a few exceptions that should be used sparingly (I’ll get to those later), this is totally fine and is needed to do anything at all. It is when the check is repeated often, over lots of objects, that problems happen. In practice, this usually means pops are the cause, though running something across all planets in the galaxy is also a pretty bad idea.

As a first step, when possible, it is a good idea to control when your script is run. The best way to do this is by setting where events are fired and using on_actions (or firing events from decisions and the like) wherever possible, instead of mean time to happen or, even worse, just setting an event to try and fire every day. If a degree of randomness is needed, one could also fire a hidden event via, say, a yearly pulse and then firing the actual event you want with a random delay (for an example, check out event action.220). "

If you wanna read the full post, have a read here!

Today's Dev Diary is a greeting from one of our Stellaris Programmers, Mathieu aka The French Paradox!

"Hello everyone, this is The French Paradox (Stellaris Programmer) speaking!

On behalf of the whole Stellaris team, we hope you've had a good summer vacation, with current circumstances and all!

We're all back to work, although not at the office yet. It is going to be a very exciting autumn and winter with a lot of interesting news! We are incredibly excited to be able to share the news with you over the coming weeks and months!

Today I open the first look at the upcoming 2.8 release with some of the technical stuff that we programmers have been working on over summer. The rest of the team will reveal more about the upcoming content and features in the following diaries.

Without further ado, let's talk about threads!




There is a running joke that says fans are always wondering which one will come first: Victoria III or a PDS game using more than one thread.

Don't lie, I know that's how some of you think our big decision meetings go

I’m afraid I’ll have to dispel the myth (again): all PDS games in production today use threads, from EU4 to CK3. Even Stellaris! To better explain the meme and where it comes from, we have to go through a little history. I’m told you guys like history.

For a long time, the software industry relied on “Moore’s Law”, which states that a CPU built in two years will be roughly twice as efficient as one today.
This was especially true in the 90s, when CPUs went from 50 MHz to 1GHz in the span of a decade. The trend continued until 2005 when we reached up to 3.8GHz. And then the clock speed stopped growing. In the 15 years since, the frequency of CPUs has stayed roughly the same.
As it turns out, the laws of physics make it quite inefficient to increase speeds beyond 3-4 GHz. So instead manufacturers went in another direction and started “splitting” their CPUs into several cores and hardware threads. This is why today you’ll look at how many cores your CPU has and won’t spend much time checking the frequency. Moore’s Law is still valid, but, to put it in strategy terms, the CPU industry reached a soft cap while trying to play tall so they changed the meta and started playing wide.

This shift profoundly changed the software industry, as writing code that will run faster on a CPU with a higher speed is trivial: most code will naturally do just that. But making usage of threads and cores is another story. Programs do not magically “split” their work in 2, 4 or 8 to be able to run on several cores simultaneously, it’s up to us programmers to design around that.

[h2]Threading nowhere faster
[/h2]
Which brings us back to our games and a concern we keep reading on the forums: “is the game using threads?”. The answer is yes, of course! In fact, we use them so much that we had a critical issue a few releases back where the game would not start on machines with 2 cores or less.

But I suspect the real question is : “are you making efficient usage of threads?”. Then the answer is “it depends”. As I mentioned previously, making efficient use of more cores is a much more complex issue than making use of more clock cycles. In our case, there are two main challenges to overcome when distributing work among threads: sequencing and ordering.

Sequencing issues occur when 2 computations running simultaneously need to access the same data. For example let’s say we are computing the production of 2 pops: a Prikki-Ti and a Blorg. They both access the current energy stockpile, add their energy production to it and write the value back. Depending on the sequence, they could both read the initial value (say 100), add their production (say 12 and 3, the Blorg was having a bad day) and write back. Ideally we want to end up with 115 (100 + 12 + 3). But potentially both would read 100, then compute and overwrite each other ending up with 112 or 103.
The simple way around it is to introduce locks: the Prikki-Ti would “lock” the energy value until it’s done with its computation and has written the new value back, then the Blog would take its turn and add his own. While this solves the problem, it introduces a greater one: the actions are now sequential again, and the benefit of doing them on concurrent threads has been lost. Worse, due to the cost of locking, unlocking and synchronizing, the whole thing will likely take longer than if we simply computed both on the same thread in the first place.

The second issue is ordering, or “order dependency”. Meaning in some cases changing the order of operations changes the outcome. For example let’s say our previous Prikki-Ti and Blog decide to resolve a dispute in a friendly manner. We know the combat system will process both combatants, but since there are potentially hundreds of combat actions happening, we don’t know which one will happen first. And potentially on 2 different machines the order will differ. For example on the server the Prikki-Ti action will happen first, while on the client the Blorg will act first.

#BlorgShotFirst

On the server the Prikki-Ti action is resolved first, killing the Blorg. The Blorg action that comes after (possibly on another thread) is discarded as dead Blorgs can’t shoot (it’s a scientific fact). The client however distributed the computation in another way (maybe it has more cores than the server) and in his world the Blorg dispatched the Prikki-Ti first, which in turn couldn’t fight back. Then both players get the dreaded “Player is Out of Sync” popup as their realities have diverged.

There are, of course, ways to solve the problem, but they usually require redoing the design in a way that satisfies both constraints. For example in our first case each thread could store the production output of each pop to add to each empire, and then those could be consolidated at the end. In the same fashion our 2 duelists problem could be solved by recording damage immediately, but applying the effects in another phase to eliminate the need for a deterministic order.

As you can imagine, it is much easier to design something with threading in mind rather than retrofitting an existing system for it. If you don’t believe me just look at how much time is spent retrofitting your fleets, I’ll wait.

[h2]The good news[/h2]

This is all nice and good, but what’s in it for you in the next patch, concretely? Well you will be happy to hear that I used some time to apply this to one of the oldest bits of our engine: the files and assets loading system.

For the longest time we have used a 3rd party software to handle this. While it saved us a lot of trouble, it has also turned out to be quite bad at threading. Up to the point that it was sometimes slower with more cores than less, most notably to the locking issues I mentioned before.
In conjunction with a few other optimizations, it has enabled us to drastically reduce the startup time of the game.
I could spend another thousand word explaining why, but I think this video will speak better:

https://www.youtube.com/watch?v=a6MWyc0wIo8&feature=emb_title

This comparison was done on my home PC, which uses a venerable i7 2600K and an SSD drive. Both were “hot” startups (the game had been launched recently), but in my experiments I found that even on a “cold” start it makes a serious difference.

To achieve the best speedup, you will need to use the new beta DirectX11 rendering engine. Yes, you read correctly: the next patch will also offer an open beta which replaces the old DX9 renderer by a more recent DX11 version that was initially made by our friends at Tantalus for the console edition of Stellaris. While visually identical, using DX11 to render graphics enables a whole range of multi-threading optimizations that are hard or impossible to achieve with DX9. Playing with the old renderer will still net you some nice speedup on startup, the splash screen step should still be much faster, but you’re unlikely to see the progress bar “jump” as it does with DX11 when the game loads the models and textures.

Some of those optimizations have also been applied to newer versions of Clausewitz, and will be part of CK3 on release. Imperator should also benefit from it. It might be possible to also apply it to EU4 and HoI4, but so far my experiments with EU4 haven’t shown a huge speedup like it did for Stellaris and CK3.

If you want to read more technical details about the optimizations that were applied to speedup Stellaris, you can check out the article I recently published on my blog.

And with that I will leave you for now. This will likely be my last dev diary on Stellaris, as next month I will be moving teams to lead the HoI4 programmers. You can consider those optimizations my farewell gift. This may have been a short time for me on Stellaris but don’t worry: even if I go, Jeff will still be there for you!

Mathieu, aka The French Paradox"