"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...


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.

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.


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"

Hello everyone!

Although challenging, we’ve had a great start to the year. The launch of Federations was a huge success for us as a game and we passed 3 million base game copies sold in March.

The 2.7 Anniversary Update gave us an opportunity to add some game features that timing didn’t allow us to fit in for Federations release, add a little more life and ambiance to the galaxy by refreshing some of our in-game visuals, as well as remastering our sound assets.

Also, in case any of you missed the Anniversary Trailer, you can watch it here:

As some of you already know, most of Paradox takes a Summer break during July, and after the 2.7 Update and associated hotfixes, the we have been busy planning the future development for Stellaris. Since we want everyone to have an opportunity to have a break, especially with the world in the state that it’s in, we’re having a Dev Diary hiatus until later in the Summer.

We don’t yet have any specific dates for when the Dev Diaries will resume, but rest assured, we remain committed to working on the game, making important improvements, and adding some new fun stuff. We will be sharing more progress after the summer!

We hope you all will enjoy your summer, stay safe, stay healthy and we’ll be back later in the Summer!

Hello everyone!

We're finally done with the verification process of 2.7.2, and in addition to the fixes on the beta branch right now we've added a few more. Thank you for your patience :)

If you wanna read the full patch notes, see the forum post here

Save games shouldn't be adversely affected by the switch from 2.7.1 to 2.7.2, but just in case you do encounter issues, you can roll back to a prior version via right click on Stellaris in library -> properties -> betas -> choose the desired version.

If you want to do crossplay MP between Steam and our other release platforms (Plaza/GOG/MS Store), you need to opt in to the crossplay beta "stellaris_test" by the same method.

Hello everyone!

We know you've been waiting on us to fix the performance issue, and we have finally found the cause and fixed it! However, we haven't properly tested this build yet. So in the good old fashioned "getting you the fixes as soon as possible" way that we work here on Stellaris, we have set up a beta branch in Steam that you can opt into while we continue our verification process in-house!

For the full patch notes, see the forum post here.

Please note that 2.7.2 is an optional beta patch. You have to manually opt in to access it. Go to your Steam library, right click on Stellaris -> Properties -> betas tab -> select "stellaris_test" branch.

If you want to play crossplay multiplayer with your friends on non-steam platforms you can opt into the "crossplay-rollback" branch in steam.

Also note that save file compatibility between versions is not guaranteed. If you have an important 2.7.1 game going, don't try to load the save in 2.7.2.

Hello everyone!

We hope you are enjoying your time with 2.7 and the 4 year anniversary of Stellaris! It’s very fun to see how far the game has come, and just as interesting to imagine what the future can hold.

We want to make sure that Stellaris is well-prepared for more content in the future. Something we’ve learned, especially with CK2, is that a long tail of new content can make it very difficult for players to see what kind of DLCs are available for the game. As we recently announced, Stellaris has more than 3 million players, and we want to make sure that players – both new and old – have an easier time finding content that they might like.

In order to improve visibility, starting today and lasting for a couple of weeks, we’re going to be running a couple of experiments that will be looking at DLC visibility within the game. We will be running a controlled experiment that will split up the player base into different groups, where each group will get a slightly different experience (or no change, in the case of the control group). The experiment will only affect the main menu and empire creation/selection, and will not have any effect on the game as you are playing. The purpose of this is to gather some insights into what kind of visibility features are actually helpful.

Before you grab your laser-powered pitchforks and plasma-illuminators, and complain about development focus, rest assured that all of this work has been done by an external team (who has done a great job btw!) and has had no effect on the development of Stellaris as a game :)

I want to emphasize that even though we want to improve the visibility of content for the game, it will never come at the expense of the game experience itself, so you don’t need to worry about that. It is very important for us that our players are able to immerse themselves in the Stellaris universe and to have fun while they play.

And because a dev diary can’t be complete without pictures or teasers, here’s two icons related to some future content. What could it be..?

Stellaris 2.7 "Wells" Update is live now!
This update reinvigorates the galaxy for PC users, with New Visuals, Galactic Community resolutions, Federation Joint Operations, and updated Habitats.

You can read more about what the patch is about and a few thoughts from our Game Director in last weeks Dev Diary.

Two things to mention:
We have discovered and are aware of a performance hit in 2.7.1, and we are currently working on getting it fixed. So if you notice a slight dip, don't worry about it. We have our best people on it!

And we have removed an entry from last weeks changelog: "The enigmatic fortress doesn't regenerate once it's been disabled anymore". It turns out the issue still occurs, so as not to cause confusion we have removed it.

Save games shouldn't be adversely affected by the switch from 2.6.3 to 2.7.1, but just in case you do encounter issues, you can roll back to a prior version via right click on Stellaris in library -> Properties -> Betas -> choose the desired version.

Once again, thank you all for playing Stellaris and happy four year anniversary!
PS. You can play Stellaris for Free until May 17th during our free weekend!


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

Hello everyone!

As we’re approaching the 4th anniversary of the release of Stellaris, I thought we would take a look at what Stellaris is, and how much has changed since its release on May 9th 2016.

Stellaris was the studio’s first original IP in many years, so when we released the game we didn’t really know exactly what makes Stellaris. As a natural consequence of that the game has changed a lot since release as we explored what the game is really about, and which experiences we think are fun and valuable.

Stellaris is an exploration-focused space-fantasy strategy game that explores dystopian and utopian themes in a playful and light-hearted manner. There is no one “true” timeline and it's important that players are able to tell their own stories – every story is equally true.

The best thing we can do is provide more tools for storytelling, and of course new gameplay to make playing the game more interesting.

Stellaris has had time to really grow in these last 4 years, and I thought it would be fun to take a look back and see how far we’ve come.


In the last 4 years we have (in no particular order):

• Added a whole bunch of new anomalies to explore
  
• Tweaked the galaxy multiple times to feature more interesting things to discover
  
• Added a new Archaeology system
  
• Added Relics & Minor Artifacts
  
• Added terrifying Leviathans
  
• Reworked the economic system to feature jobs
  
• Added Civics & Authorities for more options during empire creation
  
• Added Traditions & Ascension perks for more customization of your empire while you play
  
• Added a whole bunch of new portraits for you to choose from
  
• Added Starbases and changed how you take ownership of star systems
  
• Added Hive Minds & Machine Intelligence empires
  
• Added bigger and bigger ships like Titans, Juggernauts, Colossi and Juggernauts
  
• Reworked Federations and added new Federation types
  
• Added the Galactic Community
  
• Added a whole bunch of diplomatic actions, such as federation associate, improve relations or defensive pacts
  
• Added Curator, Artist and Trader enclaves
  
• Reworked space combat & balance multiple times, and added new weapons such as the extra large Tachyon Lance or Mega Cannon
  
• Added a lot of megastructures such as the Dyson Sphere or the Mega Art Installation
  
• And so much more....

We have come a long way since the release of Stellaris, and our story has just barely begun. I think we have a lot to be excited about for the future, as Stellaris has almost infinite potential.

Let’s take a look into the future together!




To celebrate these 4 years, and to take another step into the future, we will be releasing the free 2.7 ‘Wells’ update next week on Tuesday the 12th of May!

For this update we’ve been looking at a lot of your feedback from 2.6 Federations, and added a couple of new features and made some tweaks to already existing ones.

We will be releasing 2.7 ‘Wells’ as 2.7.1.
If you wanna read the full pach notes, have a read in the forum post here.


Thank you all for your continued support! We’re very thankful for being able to work on such a great game and to have such an engaged and great community!

Let’s celebrate many more anniversaries to come!

Hello everyone!

Today’s dev diary will show you some of the improvements we’ve made to federations for the upcoming free update!

Federation Voting
Since the release of Federations and the 2.7 update we’ve wanted to make some improvements to how voting in federations is handled. Most of the improvements are related to UI and better feedback, but there’s also been some changes to functionality.

You are now able to use Favors to increase the acceptance chance for your AI-controlled federation members.



You are now able to use Favors to increase the acceptance chance for federation law proposals.

We’ve also changed how AI acceptance works for federation laws, so that it is more transparent and more consistent with other features in the game. We look at the AI attitude a lot more now, and it will affect which laws the AI is attracted towards. For example, militaristic empires, or those with either Honorbound Warriors or Federation Builders personalities will be more likely to accept a higher fleet contribution law.

Generally speaking, the best way for you to pass new federation laws is to get the Federation Cohesion to 90 or above, and then suggest a new law change.

When it comes to suggesting changed, the AI will still not attempt to suggest changes very often, unless they are the federation president.



The AI will generally not want to increase Centralization unless Cohesion is 90 or higher. Cohesion also directly affects the acceptance chance by a factor of x0.25 (100 cohesion equals +25 acceptance).




The UI for voting on war declarations has received a face-lift. It’s now more clear which war goal is used, and you can see a summary of the target of the war, and which their allies are. This should hopefully make it easier for you to decide if you are in favor of the war or not.



Whenever a federation law has been voted on, you will now get a pop-up that clearly informs you on what the results of the vote were, and how your federation allies voted.



We’ve also improved the feedback you get whenever your federation unlocks a new level.

Something we wanted to do, but couldn’t do for 2.6 due to lack of time, was to add some more flavor events to federations. We had some cool ideas for things we wanted to try, and we’re very happy that we’ve been able to add some events for the upcoming 2.7 update.

Joint Operations are events to which each member of a federation can contribute, and the types of events will depend on your federation type.

Research Co-operatives have the chance to engage in a joint archaeological dig across their region of federated space. Galactic Unions and Research Co-operatives alike may also find themselves dealing with strange new stellar phenomena at their federation capitals. Hegemonies will have the option of a grand project to celebrate cultural uniformity – and to see who’s still willing to tow the line. Military Alliances can partake in a joint training exercise, while Trade Leagues may seek to improve their collective worth through harmonized logistics.

In all cases, collaboration will bolster cohesion within your federation – however members may sometimes be tempted by individual gains, and further challenges may arise if the federation does not act as one.



A small change we’ve made, albeit probably a welcomed one, is to make it far less likely for the leader of a Common Ground or Hegemony start to be blocked off by their federation members. It’s very likely that they will have at least one open hyperlane to an unexplored star system.

---

That’s it for this week! Next week we’ll be back with some more information regarding the upcoming free update!

Greetings!

Today we’ll touch upon a subject dear to the hearts of many galactic rulers - namely Edicts!

Background
Edicts are meant to be a way for your empire to focus on certain issues without necessarily taking a permanent stance on them. More permanent stances on issues would be covered by Policies.

Although we felt that Edicts do fit this role pretty well, there were a couple of issues with the system that we think could be improved. The fact that Edicts would always time out felt like a little bit of unnecessary micromanagement at times, and didn’t really emphasize the feeling of “I am choosing to focus on these 2 things right now”. We felt that it would fit better if Edicts had a greater emphasis on making choices that you can go back and change, rather than being things you constantly go in and refresh.



An old friend with a slight makeover. Some Edicts are now toggled on/off instead of being on a timer

Edict Capacity
Enter Edict Capacity – a new mechanic that puts a soft limit on how many Edicts of a certain type that you can have active at once. Similar to Starbase Capacity, your empire will suffer penalties if you exceed it, and the penalty in this case being Empire Sprawl. For every toggled and active Edict above the Edict Capacity, your Empire Sprawl will be increased by +25%.

By default, an empire will start with an Edict Capacity of 2, and can be modified by things like Authority, Civics and Ascension Perks. These values are very prone to being changed as more balance feedback comes in.



Dictatorial and Imperial Authority now increases Edict Capacity by +1.



The God-Emperor knows best.



You can now vigorously enact more Edicts.

Not all Edicts will use Edict Capacity, but rather only the ones that last until cancelled will. Edicts that can be toggled will have an Activation Cost and a Deactivation Cost, which is usually Influence. This means that you are paying the Influence when you are making changes, rather than paying to upkeep the Edicts you want.

Edicts that last until cancelled will be marked with a different icon from the edicts (and campaigns) that expire once their duration runs out.




An example of two different Edicts. Red: toggled - lasts until cancelled and uses Edict Capacity. Blue: temporary - lasts for 10 years and does not use Edict Capacity.

Edicts
Some of the Edicts have changed and we have added a couple of new ones, to better fit with the Edict Capacity. Let’s take a look at a few of them:



Whenever you need to stimulate your economy, subsidies can be the way to go. There are Farming, Mining, Energy and Industrial subsidies.



Neighbors suddenly turned hostile? Need to secure your borders? Pass this Edict to refocus your efforts!



Has the galaxy become more hostile? Do you need to build a powerful fleet to project your power? Focus on Fleet Supremacy for a more powerful and imposing fleet.

Pop Growth is problematic, so we have made some changes in the upcoming patch that will reduce Pop Growth from different sources across the board (more on that later). Food Policies are no more, and the popular Nutritional Plenitude is now a toggled Edict instead.



No longer a food policy (they don’t exist anymore). There are different versions for Hive Minds and Rogue Servitors.

Resource Edicts, Campaigns and Unity Ambitions
The model for the new Edict Capacity doesn’t fit very well for all types of Edicts, which is why the rare resource Edicts, Campaigns and Unity Ambitions remain unchanged and keep working like you are used to. This is also better for modding purposes, so that modders have the opportunity to use Edicts however they see best.

Finishing thoughts
Overall we feel like the new system better allows us to structure how the players get the tools they need to focus their empires for certain tasks. As we make more additions to the game in the future, this new system will also allow us to give the players more tools to address certain issues.

----

That is all for this week! We will be back again next week with another dev diary, this time about some federation-related content!