Stellaris News

"Hi all! I’m Caligula, our resident scripting language magician. As someone who works with our scripting language - both using it and improving it - on a daily basis, I’m very happy to be able to show off some of the new stuff that modders (and us inhouse) will be able to use going forwards, once the upcoming patch hits.

I’ll begin with a rundown of the new features:

• Espionage: modders can add new operations, much like arc sites
  
• First Contact: script driven, so modders can change much of the system, but all first contact is now technically one long event chain, so overwriting could be an issue. Luckily we have a new effect, “fire_on_action”, which has been inserted into various places that should alleviate this
  
• Become the Crisis: code features e.g. the interface are all activated by script. So in theory, one could overwrite the whole feature to be whatever sort of progression to a goal you happen to want to mod in.
  
• Emperor/Custodian: feature designed by the most experienced Content Designer at PDS. Brought with it many collateral scripting improvements, such as far more flexibility with galcom resolutions and the ability to spawn federation / community fleets via script.
  

Now, it’ll be exciting to see what modders do with this, but there’s so much more that we’ve done since 2.8 hit, so...

[h3]General improvements and standardisations[/h3]

It would be fair to say that the Stellaris scripting language has grown incrementally according to the game's needs. This is not unexpected - Stellaris itself has grown incrementally. But it has had the side effect that a lot of different people have contributed to it, and so inconsistencies between different implementations have arisen. On the user side, this would show itself in, for example, things which work in one place but do not work in other, equivalent places.

For the upcoming patch, we had time to take a holistic view of certain things and implement some general improvements and standardisations.

A quick win in this regard is what is known internally as "script lists". These are a code system which generates random/every/any/count_whatever_object from a single section of code - guaranteeing that the way that array is built is the same between them, i.e. any_owned_pop checks exactly the same pops as every_owned_pop would execute on. We have been using these for quite a while, but there were still some very old implementations for certain scopes that predated them. The result of this was in some cases confusion - for example, x_pop and x_planet did sometimes radically different things depending on whether you used every, random, any or count (e.g. working in different scopes, sometimes referring to all the objects in the game and sometimes all of those belonging to the current scope...). Disturbingly, it was found that any_ship referred to "any ship in the game" and was in fact used wrong 100% of the time in our scripts. Another result was that in some cases one of the versions (usually the "count" version) was simply missing.

With the next patch, nearly all of the pre-script list implementations have been removed and replaced with script lists. In some cases, the opportunity was taken to clarify what the script list did, e.g. the "planet" script list is now split between "galaxy_planet" and "system_planet". (This will break some mods, for which I am a bit sorry, but not very :D It was worth it, and the patch notes will give details on what changed. In most cases, a batch-replace will suffice. Also, because of script lists, a fair few count_x triggers have changed names to lose an "s" at the end, which is slightly regrettable from a grammatical point of view). Some have also had some functionalities expanded, e.g. owned_pop, owned_planet and system_within_border now all work in sector scope.

A further area singled out for improvement was references to scopes in effects and triggers, e.g. create_pop = { species = }. It turned out that there were quite significant variations as to what in that example could be, depending on the effect or trigger. In some cases, only the species was allowed; in others, perhaps species or leader or country or pop; in others, the same but not pops… In some cases, we even used something called “owner_main_species”, which worked in just those places (unlike “owner_species”, which was the same but worked everywhere…). Our solution was to go through each and every trigger and effect and enforce standardisation - with the same code functions used in each case - for any script call to a species, country, planet, leader, or solar system location. No more shall we be confused that something works in one place but not in another!

This also lets us make sure that errors are correctly (and usefully) logged each time a scripter gets one of these wrong. (N.B. for modders not in the know: the error log can be found in Documents/Paradox Interactive/Stellaris/logs/error.log). In a similar vein, error logging has generally been improved across the whole scripting language. A large number of error messages lacking essential information (e.g. file location) have been updated to include that - as guardian of our overnight testing error logs, I have gone on a personal crusade against useless error log messages. Furthermore, we have fixed a disturbing number of cases where something didn't work but didn't warn you - e.g. doing something wrong in a trigger so it is always false, or messing up an effect so it did nothing. I'm not going to promise that this will never happen anymore, but a concerted effort has been made to eliminate such cases. Modders should expect the error log to warn them of a lot more issues both during startup and during the campaign. This has also made us somewhat more effective in fixing script bugs, since many more are now caught in the aforementioned overnight tests.

[h3]Variables[/h3]

Onto something a bit different. On Stellaris, inhouse scripters and modders alike have long looked with envy upon the capabilities of the newer PDS game engines, compared to our own ability to do maths in script. We did have variables, but their functionality has been a bit more limited than we may have desired. In fact, I’ve seen some of the ways that modders get around their limitations, which have been incredibly motivating to make such horrible scripts no longer be necessary!

In 2.8, the following was possible with variables:

• You can check, set, add, subtract, divide or multiply variables against values, other variables on the same scope, or the same variable on other scopes
  
• You can export various galaxy generation settings as variables
  
• You can refer to variables in localisations, but if the variable’s value is 0, it will show as blank because the variable is cleared
  
• Variables can be used as a parameter in a handful of places, such as the count in a “while” effect
  

Quite a lot of improvements have been made since then, and further ones are planned for the near future. In the upcoming patch:

• You can also check, set, add, subtract, divide or multiply variables against different variables on other scopes
  
• There are new effects to modulo (% operator), round up, round down and round to the closest full number
  
• A new trigger check_variable_arithmetic checks the value of a variable if you’d perform some arithmetic to it in a certain way, e.g. multiply it by another value or variable (add, subtract, multiply, divide and modulo all work)
  
• New effects to export various game values to variables have been added. These are: export_modifier_to_variable (check_modifier_value trigger also exists now), export_resource_stockpile_to_variable, export_resource_income_to_variable
  
• add_modifier, add_resource, resource_stockpile_compare now have “mult” parameters where a variable is accepted. So you can scale resource costs and bonuses in effects by a variable now.
  
• Variables are no longer cleared when they are 0, but instead when you use the clear_variable effect, so they can be reliably used in localisations.
  
• Certain usages of variables now have error logging, in case you try and use one that hasn’t been set.
  

Additionally, we have started making it possible to use variables way more widely. The idea is that we want to change how simple numerical effects and triggers (i.e. ones which accept a number as the right hand side parameter and do not have any “{ }”) work:

• Effects should allow you to use a variable, and should grab the number from that variable
  
• Triggers should also let you use a variable, and should check themselves against the value of that variable
  
• Triggers should by default also let you check them against another scope for which that trigger would work. So “num_pops > from” should check if the current object has more pops than “from” does
  
• It should be possible to export the current value of a trigger to a variable via an effect, i.e. “export_trigger_value_to_variable = { trigger = num_pops variable = my_var }” => sets the my_var variable to the number of pops the current scope has.
  

Unfortunately, it only recently became possible for us to pursue these changes, and while the groundwork has been set for them, they are not yet fully implemented - finishing the Nemesis expansion and accompanying patch has rightly taken priority (the changes are not without danger: it’s a lot of lines of code that have to be modified for it). So consider this a preview for how it will look in the hopefully near future, and in the meantime, the fleet_power trigger already works in the way specified, and export_trigger_value_to_variable is in the patch, albeit working with only that trigger.

[h3]Button Effects[/h3]

Inhouse, we made the UI by assigning a function to buttons in the source code. But there’s also support for interface buttons that you mod into the game. In previous versions, these did not take the scope of the object that they were attached to, so if you added a button to a planet, it would still execute the effect on your country rather than that planet. We have fixed that for a bunch of cases: they will now be able to deduce their interface's planet, fleet, ship, system, ambient object, megastructure, federation, archaeology site, first contact site, spy network or espionage operation. (Incidentally, debug console commands like “effect …” and “trigger …” now work in those same scopes)

Disclaimer: The way it works is a tad hacky and it may be possible to confuse it by opening multiple interfaces at once. I recommend checking “is_scope_type = planet/whatever” in the allow and/or effect sections of the button effect. But the signs are that it should work with no problem in most cases, which is better than none!

[h3]More nice things[/h3]

• In most places where you could previously use logical operators such as >, >=, =
• Message types now have their own folder, so mods can add to them without overwriting the file (great for intermod compatibility, and also for modders being able to add QoL without overwriting each other)
  
• Messages spawned by the create_message effect now support using loc commands such as [This.GetName] (where “This” is the specified target of the message).
  
• Also, since we had to fix a large number of cases where there were references to the “Galactic Community” rather than the “Galactic Imperium”, [ ] locs now work in quite a variety of extra places.
  
• The effects “add_victory_score = ” and “win = yes” now exist. I’m sure no one will misuse them.
  
• Added new event types: leader_event, system_event, starbase_event, first_contact_event, and espionage_operation_event. Though mean time to happen does not work for any of them at the moment - fixing that wasn’t a priority, as it is generally better to avoid mean time to happen anyway.
  
• Hardcoded juggernaut behaviour is now tied to a ship size being a starbase that is mobile, rather than the “juggernaut” key. I.e. mod-made juggernauts are now possible without crippling bugs
  
• It’s now possible to hide a static modifier from the list of country modifiers
  
• You can check the distance of objects within the same solar system now by adding “same_system = yes” to the distance trigger
  
• There’s quite a lot of new on_actions, and you can make your own ones with fire_on_action effect
  
• And a lot more.
  

Finally, I'll leave you with the new trigger docs (as of today), which are now found in their own file down in the forum post here called trigger_docs.log, and which really speak for themselves. Also, don't forget Paradox Insider will premier this Saturday at 8 PM CET (7 PM UK, 2 PM ET, 11 AM PT) on http://twitch.tv/twitchgaming

"Hey folks!

My name is Erik Forsström and I’m the VFX Artist for Stellaris and I’ve been here since the release of Lithoids. VFX stands for visual effects, which means that I’m the guy who’s responsible for anything from small ship engine effects, to big system effects such as the nebulas that we added to the game last year. If it’s animated and it’s not a 3D model, then there’s a fairly high chance that a vfx artist is responsible for it.

What does a VFX Artist do?​
My workflow is a bit different compared to the other artists, because compared to 3D Artists I’m not working as much with 3D models.The main tool for me to use is particles, which pretty much is just flat planes that I work with to make cool explosions! I won't go into the technical details about particles, but just to give you a quick idea about the difference between us VFX Artists and others. While 3D Artists are sculpting and creating cool 3D models, I’m pretty much simulating planes and telling them which direction to travel and changing the size and color over time. That’s not to say I never do 3D modelling, but as I mentioned before it’s not my main tool as you’ll notice in what we’ll be showcasing below.

The cool and interesting stuff!​
So with that explained, time to get to the effects that we’ll be adding in Nemesis!
If we’re starting off with the ships in Stellaris, something that I’ve aimed to do is to give the different shipsets a bit more unique feeling when it comes to the effects. Some of you might have noticed that both Lithoids & Necroids have some unique ship effects, anything from ship engines to explosions. I’ve tried to make them all look at least slightly different to each other to varying degrees and to make them fit the style of the ships.
I usually try to give them some different shapes, color schemes or anything cool that I can come up with that makes it look unique and fit the style.

Click here: to see the Nemesis Titan with new effects for the perdition beam and the engines

The big effects, in other words the system effects!​
Another thing that you might have noticed is that we’ve added quite a few different system effects over the last year, such as the nebulas, space storms and the endgame crisis system effects when they’re expanding their territories. It was one of those things that I always felt that was missing while playing Stellaris, the systems felt a bit empty. With Nemesis we’ve added a few new system effects, such as for the Aetherophasic Engine Frame that we mentioned in an earlier dev diary.
When you’re upgrading it you’ll get a system effect that changes through the different stages, getting bigger and more powerful the higher the stage you’ll get. To really show it off I'm cheating a bit in the video below (by using max resources and finishing the construction instantly), and I’ll let you see how it changes and develops through the different stages.
From a fairly small effect, to a huge effect covering the system with more detail, shapes and movement in it to really give you the feeling that something powerful is going to happen in this system.

How is it made?​
System effects are one of those effects that most of the time are made with a mix of particles and 3D models, the sheer size of them requires more complex shapes then what you can get with only particles. So the effect below is created with the help of these meshes that you can see in the image below, and then I’ll apply some animated shaders on them that creates the movement of the textures that you can see in the video. Add on top of that some particles and you get a complete effect!

The meshes used for the visual effects for the Aetherophasic Engine

Click here to watch the Aetherophasic Engine Frame going through the different upgrade stages

Destroying a star​
And finally the highlight for me in Nemesis! Blowing up the stars!
It’s made of a few different parts, the chargeup that rely mostly on the animation of the Star Eater with some glow in the middle of it. And then comes the firing stage, which is a pretty big effect. As you can see it goes through different stages in strength, that helps with creating more of a buildup until the big explosion.
At first while prototyping it was at full power at once, which looked cool but it didn’t create the anticipation for the explosion. You “only” ended up looking at a cool effect for ~20s without any buildup or knowing how close it’s to firing, if you were only looking at the visuals.
So in the end we ended up splitting up the effect in different stages, and added or tweaked parts of it to make it really feel like you’re getting closer to blowing up a star.

And last but not least, the star explosion. I’ll keep this short because I think the explosion pretty much speaks for itself. But I just want to say that this is probably one, if not my favorite effect I’ve done so far in this game.
So I really hope you’ll enjoy it as much as I do!

Click here: to watch the The death of a star!

And that was all from me! Hopefully it gave you some insight of what I do, and how I do some of the things. Thanks for reading!

Next week a content designer is going to write about script improvements that’s coming in the next update!"

"Hello, my name is Simon Gunnarsson, I'm the Art Lead and acting Art Director for Stellaris. I wanted to go through our process of developing a style for a new ship series that will be added to the game when Nemesis is released. I'll go through the steps from the initial meeting with our game director, Daniel Moregård, through the visual development (vis-dev), concept art production and finally end at 3D production, that includes animation and VFX.

Initial Art Direction

For this time around, we had a player fantasy to cater to, so our mission statement became our guiding star throughout the process. We sat down with the game director that resulted in the imperial thematic direction. Which was enough for us to start doing some word associations to kick off the creative process.



The closer the top a word is, the more influence it should have in our direction. We held ourselves to these words even when we changed our visual direction in the middle of the vis-dev.

These first associations were part of the first brief we put together to the concept team. The theme invites for interpretations so it's important that we also define the initial art direction with supporting images, splitting the line between "what it is" and "what it isn't" is equally necessary.

With these things in mind, we curate an initial aesthetic that we think is worth exploring, so the concept team has some anchor to the vision. For the imperial aesthetic we wanted them to explore a bright and ornamental direction at first. We always enable our team to add their own touch to these curated directions, but also encourage them to also explore other paths.

Vis-dev
We had several people working with the vis-dev, all bringing their own unique take on the brief we gave them. This process is quite hard, closing doors on designs and actually drive the art direction forward is a difficult task, with all the viable options at hand, we have to be quite picky, and measure against the words that we came up with.

Asking questions like, is this conveying an imperial and dominant feeling, what works well with this specific design and what doesn't. These questions are crucial in driving the vis-dev forward.



Concept-art made by Alessandro Bragalini



Concept-art made by Ecbel Oueslati


Concept-art made by Mattias Larsson



Concept-art made by Simon Gunnarsson (me!)



Concept-art made by Ylva Ljungqvist

There were concerns towards the mid-point of the vis-dev. The way the light works in Stellaris could make it so that white looks quite muddy. There's a chance that white takes too much color from the light and makes it look quite weird in some occasions.

So we iterated the curated art direction into a dark aesthetic. We made it more forgiving no matter what empire color the players chose, the ships will most likely look appealing in every instance.

The new aesthetic still had to hold true towards the associated words from the beginning. So we focused on more brutalist style, dark with silver details.



Final concept-art made by Simon Gunnarsson

Style Guide
The end of the vis-dev should result in a style guide, a document that should communicate the vision and the aesthetic, with extracted details and breakdowns. It is used by the whole team, from animators to VFX so it needs to be quite descriptive.

For example, below is a breakdown of materials that 3D artists will use as a guide to creating them.



Production

The actual concept art production is the bulk of our workload. It's where we create actual blueprints for 3D artists to follow. But it's really just a linear but iterative process to get to a final result. We start with sketching some ideas, and we slowly commit more and more to certain aspects until we have a design we like, then we refine it, add materials and ultimately a final asset sheet is created.

Initial sketches



Concept artist use 3D to easier present the ship and get a better feel for the design



Laying down material patterns, starting with a broad design then adding secondary and tertiary level of material details





Finalized asset sheet, complete with materials and material ID for the 3D artists to follow


In-game final asset

The end, but not quite!

This is our process with every new ship aesthetic, but the ships have a few more stops on the road before they're truly final, both animation, VFX and audio will get their hands on these before the full process is complete!

Thank you for taking the time to read this long post, here's a Nemesis (imperial style) titan! You will hear from our VFX artist, Erik Forsström, in a Dev Diary in a near future! "

PS. If you want to see a short video of the Nemesis (imperial style) titan, scroll down to the bottom of the forum post here!