Zaztl’s time had come. The Ritual of Elevation was soon to begin, and as she was inching ever closer to her own final destiny, she wondered “Is this perhaps the start of a new life?”. She couldn’t help but to latch on to hope in her moment of dread, but she also knew the futility of the question.

No Jeferian would ever know the answer to that question.

Shumon ins-Beth was born, the newest individual to join the Pasharti species.

---------------



The result of dark experimentation by the Jeferians - the former owners of the planet Taralon - the Pashartians are the ultimate parasites. Originally a semi-sapient creature dwelling in the depths of Taralon's mountains, the Jeferians uplifted and augmented them to act as a subservient slave race. However, their uplifting was rather too effective, and they unleashed a monster. Horrified at the capabilities of their creation - which included the ability to absorb other sentient species and turn them into Pashartians - the Jeferians tried to shut down the experiment. However, a small group of uplifted Pashartians escaped.

Over the years, they bided their time, managing not only to evade capture, but also gradually increase their numbers and develop a technological base to rival the Jeferians. Eventually, the Jeferians noticed that something was amiss, but by then they were powerless to resist.

Soon the Pashartians had seized control of the planet, unleashing violent pogroms on their erstwhile oppressors - all the while further increasing their numbers. Now poised to take to the stars, the Pashartians stand ready to pursue what they see as their solemn duty - the conversion of all lesser life forms to their likeness.

---------------

Hello everyone!

Two weeks ago we announced the Necroids Species Pack, and today we’ll be giving you more information about the gameplay aspects. But first, I’ll take the opportunity to link the trailer once again, in case you missed it.

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

For Necroids we wanted to add some new gameplay that would be available to many more different types of empires and species. Unlike Lithoids, these Civics and Origins will not require you to use a Necroid portrait. For Lithoids we felt like it made sense, but in this case we didn’t want to impose any limitations on your imagination and creativity.

Necroids gameplay includes:

• Necrophage (Origin)
  
• Memorialist (Civic)
  
• Death Cult (Civic)
  
• Reanimated Armies (Civic)

[/b]
[/list]



Necrophage is a new Origin that means that your primary species has a very hard time to procreate by themselves, but is instead dependent on transforming other Pops into themselves.



Necrophage Trait - live long and consume



Chamber of Elevation - when regular Uplifting isn’t enough



Necrophytes - Hey, what does the necro part of my job title stand for anyway?

---

In addition, there is also the Reanimated Armies civic that we showed in DD #185. This civic replaces the Military Academy with a Dread Encampment, and can recruit Undead Armies that are unaffected by morale.


Reanimated Armies - the ultimate in recycling.


Dread Encampment Building - wouldn’t want to get caught dead here


Undead Army - it’s not wight how they work them to the bone, but they don’t complain




Necromancer job - some say it’s a dead end job, but they’ve made a grave mistake
(Note: Above image includes the bonus from Ground Defense Planning)

This civic has a few restrictions - no pacifists, and it conflicts with Citizen Service since it replaces the Military Academy. Some subtle differences exist between Soldiers granted by Military Academies and the Necromancers from Dread Encampments - they’re Specialist tier and provide more defense armies, provide some research benefits, and will summon additional defense armies under Martial Law instead of increasing Stability.

---

That is all for this week! Next week we’ll take a look at the art process and all the effort that goes into creating the Necroid portraits!

We’ll be eagerly reading your responses, and remember that...


Jeff sees all

My name is Fredrik Toll, and I am the Art Director for Stellaris. For this week's dev diary, we wanted to give you an insight into the development process of creating the ships for the Necroids Species Pack.

Let’s dig right into it!

After settling on the theme, the first thing we do when embarking on designing a new ship-set for a species pack, is going through the core ideas of the species pack with our internal team of concept artists. In this case it was centered around the theme of death, and the various species who have cheated it. After the brief, we had everyone write down their association and ideas for this theme to know what everyone is thinking. This allows us to align more what it’s all about, share ideas, and inspire each other. By doing that we are able to highlight what is more important and what does not fit with the theme.

After this we do a search for visual reference to use in the concept process. These can be anything from patterns, statues, tiny objects, to buildings, whatever inspires us visually in connection to the theme. We look mostly for shapes, but also materials. Architecture is usually a great source of inspiration, they have great shapes, and a scale suitable for ship details. We try to avoid using other existing ships as reference since we want to develop something original, not just a variant of others, though they can still be a reference, if only to show what we don't want.
For Necroids we looked a lot at Art Deco and brutalist architecture, tombs, pyramids, as well as skulls, fossils and many other things. After reviewing and discussing the references we start sketching, going wide, anything goes. Sometimes they align a lot with our references, other times ideas come from nowhere, it’s all part of the process. This leads to a whole lot of Ship designs ideas. Here are a handful of those.



Ultimately we settled on these two references as our direction. They felt like something far away from existing ships, as well as fitting well with the theme.




These ships are only the start though. Once we have chosen one of the styles we did in our initial look development. We have to flesh out what those mean. These are just side-views, they do not tell you everything you know, in fact, opinions of how to interpret it can differ significantly. So we need to figure that out, as well as adapting it for the demands of the game, such as having sections, having turrets etc.

Usually we start with the Cruiser, since it’s a good mid-size ship close enough to all ships sizes that it’s relevant for all designs. You also have a fallback option, if it turns out that it looks too big, you can just use it for the battleship. If it turns out too small it will be the destroyer or corvette. Here you can see a few of the concepts from the process. It looks pretty straightforward, but it takes a lot of back and forward before we nail it down.



Once you have the style narrowed down, it’s time to make all the actual concepts for each and every ship. Even though the style is figured out, each ship is a bit unique and each of them present new challenges, and new parts of the style to figure out. The civilian ships are different from the military ships. Each of the military types ships has a different size, and the style differs significantly from the corvette to the juggernaut. Each of the civilian ships has a very unique design and they have more in common with some stations than they do with each other. The construction ship and the mining station often share traits, as do the science ship and the research station.

The science ship for instance, has a much more high tech appearance than the other ships. The process is made easier though from the work we have done on previous shipsets. Some standards have been set, the science ship for instance usually has a more “cool” appearance with a more streamline almost racing type ship. This helps us know where to aim, and apply the style on that.
Sometimes it's pretty straightforward – Let’s take the example of the Science Ship. First we start by making a couple of rough versions, then choose one of those versions, then make some more versions based on that one. We then continue the process by once again choosing one of them, refining the details to finish the design, and in the end we create an asset sheet. The asset sheet is for the 3D artist to model, and know where to apply which material. It speeds up their work a lot and makes sure everything is consistent.





If you wish to see more art examples of the Necroid shipsets and read more about the art process, check out the forum post here!

Hello everyone!

Today we bring you some exciting news about our upcoming Species Pack! We’re happy to announce that our next species pack will be themed around death and should allow you to live death to the fullest! Check out the trailer below:

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

• 15+1 new portraits (the +1 being machine)
  
• 1 new Ship Set
  
• 1 new City Set
  
• 1 new Room background
  
• 1 new Origin
  
• 3 new Civics
  
• 1 new pre-scripted Empire
  
• 1 new Advisor Voice

We wanted to add ships that had a more sinister or evil appearance, and I’m very happy to say we’ve made something really great. We’ll go into more detail about the ships, and give you a peek into the art process, in a future dev diary.

True to the theme, we wanted the portraits to revolve around death, but not look outright undead or decaying. We never intended the Necroids to be specifically undead, but rather themed around death. Similar to the ships, we will be doing a dev diary in the future to give you a peek into the art process, and also reveal all the new portraits. Stay tuned!

Regarding the other features, we have already shown you some of them, such as the Death Cult Civic and the Memorialist Civic. The remaining features will be revealed over the next couple of weeks, and maybe you'll even get to learn about Jeff. But for now, let’s pass the Mishar Cabal into our memories.

---

General Donnten threw her bloodied axe next to Ostiir’s severed head. The others in the Leadership Council would remember this the next time they considered interrupting her in the Mishar Althing.

She pushed past the acolytes that were coming to deal with the corpse. They were annoyed - the rites were always harder if the head was removed - but they would just have to stitch it back together.

Smiling to herself, she left the arena. At least Ostiir would be an obedient little soldier now.

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.

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


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.