Please enable / Bitte aktiviere JavaScript!
Veuillez activer / Por favor activa el Javascript![ ? ]
presenting the best what fans had created in the geek cultural sphere & more

News in category "Stellaris" - Page 3

Page 3 of 4


doFollow
Für Solidarität und freie Bildung

Blogroll

Aktionsbündnis gegen Studiengebühren AStA Uni Kiel


 
Published by on o'clock

Stellaris

Hello everyone and welcome to another Stellaris dev diary. Today's topic was supposed to be ship balance and doomstacks, but because certain things weren't ready to show off yet, we're instead going to be doing a smaller dev diary talking about some changes coming to Ascension Perks and Surveying. We'll get back to the doomstack topic in a couple weeks.

Ascension Perks
Ascension Perks were added in Utopia as the paid component to the Tradition system to create a set of interesting choices for the player to take as they went through the Tradition tree, choosing between simple but powerful bonuses and more elaborate 'unlocks' such as the ascension paths and Megastructures. However, since then we have noticed that this is a system we keep wanting to build on (for example by adding unique Ascension Perks for Machine Empires as we did in Synthetic Dawn), and found the requirement to depend all of this on Utopia too limiting. For this reason, in the Cherryh update, we are going to make the basic Ascension Perks such as Mastery of Nature, Defender of the Galaxy and so on free for everyone. Biological/Psionic/Synthetic Ascension Paths and Megastructure Ascension Perks (including Habitats) will still require Utopia and Machine Empire Ascension Perks will naturally still require Synthetic Dawn (but not Utopia). The core system itself however, will become part of the base game, so everyone will be able to get at least the basic set of Ascension Perks even if they don't own a single piece of DLC.

Surveying & Communications Trading
The way surveying, anomaly generation and star chart trading works has never really worked very well. For one, it's very unclear to players that for example, you cannot discover anomalies in other empires' space, or that star chart trading can actually be a bad idea since it can in some cases stop you from finding anomalies in those systems. For this reason, we've decided to make some changes to the way surveying works. In Cherryh, any system inside the borders of an empire you have communications with will automatically be considered surveyed, without any need to send a science ship into it and waste a bunch of time scanning planets that have no chance of yielding anomalies aynway. There are some exceptions to this, such as Fallen Empires, whose space will need to be surveyed manually and can in fact yield anomalies.

As part of this we have decided to remove Star Chart trading as well as the ability to buy Star Charts from Curators, and instead replace this with the option to trade Communications with another empire - acquiring Communications from an empire in a trade deal will automatically put you in comms with any empires they have comms with that you do not. This should mean that there are no longer any 'traps' in surveying, while also requiring the need to explore every little nook of the galaxy even when that nook is held by your ally since a hundred years back.

Terra Incognita Changes
Finally, I just wanted to mentioned that we have done some changes to Terra Incognita to make it more clear and make it work properly with bypasses (Wormholes and Gateways). Instead of Terra Incognita being based on which physical pixels on the map your ships have 'seen', it is now based on which systems are considered visited. Visited either means that you have been to the system with a ship, or that the system is inside the borders of an empire that you have communications with. As such, Terra Incognita no longer needs to be manually lifted on empires you have met in order to not make them appear grey and washed out on the map, also making it easier to see important galactic features such as nebulas.

That's all for today! I know it was a short one, but don't worry, we still have a long way to go and plenty of major things to talk about for Cherryh. However, next week we're actually going to be talking about something that's§ unrelated to Cherryh, but exciting nonetheless. I'm not allowed to spoil what just yet, but stay tuned!

Source: 1 ]

Category:  Stellaris

0 Comments


 
Published by on o'clock

Stellaris

Hello everyone and welcome to another Stellaris dev diary. Today we're going to continue talking about major changes coming in the Cherryh update, specifically on the topic of war and peace. As said before, all of these changes are currently far away, and we cannot give more details on ETAs or the exact nature of the Cherryh update than we already have.

Wargoal Overhaul
The wargoal system in Stellaris has always felt a bit odd, and has been the target of some very well-reasoned criticism from players. In one way, the system is extremely unrestrictive, allowing you to declare war on anyone for any reason to take any planet, no matter if said planet is on the literal other side of the galaxy in the middle of enemy territory and could not feasibly be held by your empire, and then demand that planet in the peace even if none of your soldiers had ever set foot on it. On the other hand, the restriction to only being able to take planets meant that you had a fairly limited control over your actual borders after the peace, and might be forced to take planets you had no interest in just to get that system with a resource or colonizable planet that you *actually* wanted. Other issues include a rather messy wargoal interface (particularly when trying to set goals after being declared on) and a lack of ability as an ally in a war to affect what gains you were going to get in the peace, and that wars were very 'all or nothing' affairs with no real mechanics for any other outcome than total victory for one side.

With the change to borders discussed in Dev Diary #91, system control is now separated from planets, and so allows for systems to be conquered and traded even if they do not contain a colonizable planet. This, in addition to all the previously mentioned issues, means that we need a new wargoal system that can handle both limited wars fought over a few border systems, and massive wars that result in dozens of systems changing hands. The way we have decided to solve this is to completely rework wargoals, peace negotiations and to add the concept of claims.

Claims
Claims are effectively territorial ambitions - an empire claiming territory they do not currently control, for whatever justification they can come up with. Which systems can be claimed depends on an empire's war philosophy policy, with the unrestricted warfare philosophy allowing for the claiming of any system not owned by a fellow Federation member. Claims, however, are not free. Much like territorial expansion through building outposts, they require expenditude of Influence, to represent the political effort (or mind/processing power in the case of Gestalt Consciousnesses) required to claim and integrate the territory. How expensive a system is to claim depends on distance to your borders, how built up the system is (a remote mining system will be much cheaper than the homeworlds) and other factors such as traditions and technology. Overall, claims will be more expensive in the early game, and become less so later on to allow for more decisive wars to be fought in the mid- and lategame. Claims are managed through the claims interface, accessible from the topbar. From the claims interface, you can easily make and revoke claims (please note that the interface is currently a rough WIP, thus the weird-looking green arrows, among other unfinished bits of art). It is possible to claim the same system multiple times to gain a stronger claim on it, which is mainly useful when going to war together with an ally that is claiming the same system (more on this later in the DD). Finally on the topic of claims, as mentioned in Dev Diary #91, influence gain is going to be majorly rebalanced to reflect its new uses in expansion, and some things which previously cost influence may now use other currencies.

Casus Belli and Wargoals
To go to war with another empire in the Cherryh update, you now need a Casus Belli - a reason for war. The simplest Casus Belli to get is the Claim Casus Belli, gained by creating a claim on another empire. Each Casus Belli grants access to at least one type of Wargoal, with some Casus Belli (like Subjugation) potentially allowing for several different Wargoals to choose between. When declaring war on another empire, rather than put together a list of Wargoals, you choose just one Wargoal allowed by one of your Casus Belli, and the defender similarly chooses one after being declared on, with the Humiliate wargoal always available to defenders regardless of Casus Belli. However, the Wargoal is always in addition to rather than instead of claims the two war sides have on each other. What this means is that the Wargoal is the overall purpose of the war (for example, to humiliate a rival) and any claims you have on the target and their allies is your territorial ambitions in the war (for example, a string of border systems). Some Empires (such as Fanatical Purifiers, Devouring Swarms and Determined Exterminators) have special Casus Belli that usually allow them to conquer their neighbors at will (exceptions being empires they don't hate, such as other Machine Empires for Exterminators), ignoring claims altogether, but are vulnerable to be similarly conquered by others who see them as a threat to the entire galaxy.
2017_11_09_2.png

War Exhaustion and Peace Negotiations
As wars can now be anything from a small border skirmish to a massive war of conquest (depending on the wargoal and number of claims), we felt that the Warscore system so common to our other games was inadequate for dealing with this variety, and tended to turn every conflict into a total war with one undisputed winner and another, utterly crushed loser. As such, Warscore is gone in the Cherryh update. Instead, we have introduced the concept of War Exhaustion. War Exhaustion goes from 0-100%, and measures the total weariness and attrition suffered by all empires on one side in a war (psychological and logistical). War Exhaustion goes up from having Planets and Starbases occupied by the enemy, suffering losses during Space and Ground Combat, and passive accumulation over time (called Attrition). When a war side's War Exhaustion hits 100%, they can be forced into a Status Quo peace (more on this below). The speed at which War Exhaustion accumulates is influenced by factors such as ethics, traditions, technology and the amount of claims being pressed - an empire that is fighting to hold onto a handful of border systems will tire of a costly conflict quicker than one whose very independence is being threatened.

There are three ways a war can end in the Cherryh update: With the surrender of either side, or with a negotiated Status Quo peace. When an empire Surrenders, it is usually either because they have been completely defeated, or because the war aims are limited enough that they view it as more costly to continue the war than to end it.

Surrender means that the victor's Wargoal (for example, to humiliate or vassalize the loser) is enforced, and any claims the winning side has on the losing side are automatically ceded regardless of occupation status. Surrender can only be forced on an enemy that is entirely or nearly entirely defeated - an empire can never be forced to cede territory that the enemy is not able to take control of with their military.
Status Quo means that the war has reached a point where total victory is unlikely for either side, and both sides agree to stop hostilities and settle for whatever gains or losses they have suffered. Under a Status Quo peace, all occupied systems claimed by an enemy empire is ceded to the enemy with the strongest claim. This is where multiple claims on the same system comes in - if you and an ally are both claiming the same enemy system, you can continue to invest influence into 'trumping' their claim so that you are the one given the system rather than your ally. In the case of a tie, whoever has the oldest claim on the system is considered the stronger claimant. As mentioned above, a war side that is at 100% War Exhaustion can not reject a Status Quo peace.

Status Quo being not a white peace but a "Uti possidetis" style peace where claimed and occupied (or in some special cases like the aforementioned Purifier Wargoal, just occupied) territory is kept is meant to be able to create more varied and interesting outcomes to wars, such as a war of conquest where the attacker started with the ambition to conquer an entire enemy empire, and easily took over the lightly defended border systems, but found themselves unable to make headway against the more heavily defended enemy core systems, eventually settling for only what they were able to control. Along with the way surrender works, it also means that empires are never forced to cede systems that they are able to militarily defend - no matter how much the enemy is overrunning your outposts, if your fleets and starforts can keep them away from your homeworld, you can't be forced to hand it over in the peace. It also makes it possible for an empire that is losing a war to still fight to minimize their territorial losses by fighting to inflict War Exhaustion on the enemy, making them pay for every system they take until they can be forced to make peace. Furthermore, it means that wars can end in a way that isn't one-sided, with gains and losses on both sides.

It is currently not possible to make claims on an enemy when you are the aggressor in a war against them. Defenders are able to make claims as normal. This is subject to testing, balancing and tweaking and may change (more on that below).

Starbase and System Occupation
Finally, I wanted to write a short bit on how occupying systems actually works now. There will be more details on this (especially about ground combat) in later dev diaries, but the gist it is that a system is considered occupied only if the Starbase and all planets (excluding potentially neutral ones like primitives) are under enemy control. For a Starbase to be taken control of, it must first be disabled (brought to 0 hp) by the enemy fleet. Taking control of an enemy system will also take control of all mining and research stations in that system and allow the occupied to benefit from them economically for as long as the war continues. Similarly, Starbases that are taken control of are also able to be used by the controller - controlled enemy shipyards can be used to refit, repair and build your own fleets, and enemy fortresses to keep them from retaking occupied systems. All of this means that 'raiding' and striking at vital enemy systems becomes an important aspect of warfare, allowing you to turn the enemy's own economic, military and logistical assets against them if they do not do a good enough job defending them.

Other Thoughts
We are still heavily testing and tweaking these new systems, and we have some other things we are thinking about and trying out to see how they work. They include:
- The ability to claim unsettled systems as a way to put 'dibs' on a system before actually going there to build an outpost
- Having claims be cheaper if you don't have a ton of them, to encourage smaller scale conflicts
- Potentially allowing claims to be made by attackers (rather than just defenders) during war, but have them be more expensive
- Ways to slow and reduce War Exhaustion at the expense of your economy and population

That's all for today! Next week we'll continue talking about war, on the topic of space battles, command limits and doomstacks. See you then!

Source: 1 ]

Category:  Stellaris

0 Comments


 
Published by on o'clock

Stellaris

Hello everyone and welcome to another Stellaris development diary. Today's dev diary is about Faster than Light travel in the Cherryh update, and it's likely to be a controversial one. When discussing, please remember to keep things civil, and I would kindly ask that you read the entire dev diary before rushing to post, as it's going to cover some of the questions and concerns we expect to see from the playerbase. Also, as posted last week, all of these changes are currently far away, and we cannot give more details on ETAs or the exact nature of the Cherryh update than we already have. Thank you!

FTL Rework
The single biggest design issue we have had to tackle in the Stellaris team since release is the asymmetrical FTL. While it's a cool and interesting idea on paper, the honest truth is that the feature just does not fit well into the game in practice, and blocks numerous improvements on a myriad of other features such as warfare and exploration, as well as solutions to fundamental design problems like the weakness of static defenses. After a lot of debate among the designers, we finally decided that if we were ever going to be able to tackle these issues and turn Stellaris into a game with truly engrossing and interesting warfare, we would have to bite the bullet and take a controversial decision: Consolidating FTL from the current three types down into a primarily hyperlane-based game, with more advanced forms of FTL unlocked through technology.

However, as I have said on the previous occasions when discussing this issue, one thing we would never consider doing is just slashing FTL types from the game without adding in something else to compensate their loss. That is what most of this dev diary is going to be about. However, before continuing with the details on the additions and changes we're making to FTL, I want to cover a couple of the questions I expect will arise from this:

Why are you removing FTL choices instead of building on them?
A lot of people have asked this question when we have brought up consolidating FTL types before, suggesting that problems such as static defenses can be solved by just adding more mechanics to handle each special case. I think the problem with this is best illustrated with defense stations and FTL inhibitors. One of the aims of the Starbase system is to give empires the ability to 'lock down' their borders, building fortresses that enemy fleets cannot simply skip past to strike at their core worlds, instead of having to create static defenses in every single valuable system.

With hyperlanes, this is a pretty simple affair: As hyperlanes create natural choke points, the only thing a hyperlane-stopping FTL inhibitor needs to do is to prevent enemy fleets from leaving the system once they enter it. The fleet can enter, it can retreat (via emergency FTL) and it can bring down the source of the FTL inhibitor (which might be a Starbase or even a planet) to be able to continue. This is quite easy to understand, both in terms of which system you need to defend to lock down your borders, and how it works when you are on the offensive.

Now let's add Warp to the mix. In this case, the single-system FTL inhibitor is useless because Warp fleets can just go over it, so we'll invent another mechanic: A warp interdiction bubble, stretching a certain distance around the system, that pull in any hostile Warp fleets traveling there to the system containing the FTL inhibitor, and force them to battle it or retreat. This is immediately a lot more messy: First of all, this bubble can't possibly affect Hyperlane fleets, because it could potentially pull them dozens of jumps away from their current location. This means that when fortifying your borders, you now need to not just make sure that every important chokepoint is covered, but also that your entire border is covered in warp interdiction bubbles.

But there's more: Add Wormholes as well, and you now have an FTL type where not only the 'bubble' type interdictor doesn't make intuitive sense (because Wormhole fleets make point-to-point jumps rather than traveling over the map) but if said interdictor works to pull Wormhole fleets out of position regardless of what makes intuitive sense, you end up with the same probem as with hyperlanes, where the fleet can get pulled out of range of its wormhole network and end up stranded even if it brings down the defenses. This means you pretty much have to invent a third type of interdiction type for Wormhole on top of what is already an overengineered and hard to understand system.

Finally, add the problem of displaying all these different types of inhibitors and interdictors on the map, in a way that the player can even remotely start to understand, and you end up with nothing short of a complete mess, where it's far better to just have static defenses protecting single valuable systems... and so we come full circle.

This is the fundamental problem that we have been grappling with when it comes to asymmetrical FTL: What works in a game such as Sword of the Stars, with its turn-based gameplay, small maps of usually no more than 3-6 empires, and 1-on-1 wars breaks down completely in a Stellaris game with real-time gameplay and wars potentially containing a dozen actors, all with their own form of FTL. The complexity collapses into what is for the player just a mess of fleets appearing and disappearing with no discernible logic to them.

Why Hyperlanes?
When discussing this, we essentially boiled down the consolidation into three possibilities: Hyperlanes only, Warp-only, and Warp+Hyperlanes. Wormhole is simply too different a FTL type to ever really work with the others, and not intuitive enough to work as the sole starting FTL for everyone playing the game. Keeping both Warp and Hyperlanes would be an improvement, but would still keep many of the issues we currently have in regards to user experience and fleet coordination. Warp-only was considered as an alternative, but ultimately Hyperlanes won out because of the possibilities it opens up for galactic geography, static defenses and enhancements to exploration.

Here are the some of the possibilities that consolidation of FTL into Hyperlanes creates for Stellaris:
Unified distance, sensor and border systems that make sense for everyone (for example, cost of claiming a system not being based on euclidean distance but rather the actual distance for ships to travel there)
Galactic 'geography', systems that are strategically and tactically important due to location and 'terrain' (more on this below) rather than just resources
More possibilities for galaxy generation and exploration (for example, entire regions of space accessible only through a wormhole or a single guarded hyperlane, containing special locations and events to discover)
Better performance through caching and unified code (Wormhole FTL in particular is a massive resource hog in the late game)
Warfare with a distinct sense of 'theatres', advancing/retreating fronts and border skirmishes (more on this in future dev diaries)
Are all new forms of FTL free patch content?
Yes. Naturally we're not going to charge for any form of content meant to replace the loss of old FTL types.

Hyperlane and Sublight Travel
As mentioned, in the Cherryh update. all empires will now start the game with Hyperlanes as their only mode of FTL. By default, hyperlane generation is going to be changed to create more 'islands' and 'choke points', to make for more interesting galactic geography. However, as we know some players do not enjoy the idea of constricted space, we are going to add a slider that controls the general frequency and connectivity of hyperlanes. Turning this up will create a more connected galaxy and make it harder to protect all your systems with static defenses, for players who prefer something closer to the current game's Warp-style movement.

Sublight travel is also being changed somewhat, in the sense that you need to actually travel to the entry point to a particular hyperlane (the arrow inside a system) to enter it, rather than being able to enter any hyperlane from any point outside's a system's gravity well. This means that fleets will move in a more predictable fashion, and interdictions will frequently happen inside systems instead of nearly always being at the edge of them, in particular allowing for fleets to 'guard' important hyperlane entry/exit points. To compensate for the need to move across systems, sublight travel has been sped up, especially with more advanced forms of thrusters.

FTL Sensors
Along with the change to FTL, we are also changing the way sensors work. Instead of simply being a circle radiating an arbitrary distance from a ship, station or planet, each level of sensors can now see a certain distance in FTL connections. For example, a ship with level 1 sensors (Radar) will only give sensor coverage of the same system that it is currently in, while a ship with level 2 (Gravitic) sensors will give sensor coverage of that system and all systems connected to it through a Hyperlane or explored Wormhole (more on that below), a ship with level 3 sensors will be able to see systems connected to those systems, and so on. Sensor coverage can be 'blocked' by certain galactic features (more on that below), which will also block propagation into further connected systems. We are currently discussing the implementation of sensor blockers as a potential Starbase component.

Wormholes
While Wormhole as a full-fledged FTL type is gone, Wormholes are not. Instead they have been changed into a natural formation that can be encountered while exploring the galaxy. Wormholes come in pairs, essentially functioning as very long hyperlanes that can potentially take a ship across the entire galaxy near-instantly. Natural Wormholes are unstable, and when first encountered, you will not be able to explore them. To explore a Wormhole, you need the Wormhole Stabilization technology, after which a science ship can be sent to stabilize and chart the Wormhole to find out what lies on the other side. If you're lucky, this may be unclaimed space full of valuable systems, but it could just as well be a Devouring Swarm eager to come over for dinner. There is a slider on game setup that controls the frequency of wormhole pairs in the galaxy.

Gateways
Gateways is an advanced form of FTL most closely resembling the Wormhole FTL in the live version of the game. While exploring the galaxy, you can find abandoned Gateways that were once part of a massive, galaxy-spanning network. These Gateways are disabled and unusable, but with the Gateway Reactivation mid-game technology and a hefty investment of minerals, they can be restored to working order. Like Wormholes, Gateways allow for near-instant travel to other Gateways, but the difference is that any activated Gateway can be used to travel to any other activated Gateway, and late-game technology allows for the construction of more Gateways to expand the network. Also unlike Wormholes, which cannot be 'closed', Gateways also have the advantage of allowing any empire controlling the system they're in to control who goes through said Gateway - hostile empires and empires to whom you have closed your borders will not be able to use 'your' Gateways to just appear inside of your systems.

When the first Gateway is re-activated, another random Gateway will also be re-activated along with it, so that there is never a situation where you just have a single active Gateway going nowhere. There is a slider on game setup that controls the frequency of abandoned gateways in the galaxy.

Jump Drives
Jump Drives and Psi Jump Drives have been changed, and is now an advanced form of FTL that mixes Hyperdrive with some functionality from the old Warp FTL. They allow for a ship to travel normally and very quickly along hyperlanes, but also come equipped with a tactical 'jump' functionality that allows a fleet to make a point-to-point jump ignoring the normal hyperlane limitations. This is done with a special fleet order where you select a target system for the jump (within a certain pre-defined range, with Psi Jump Drives having longer range than regular Jump Drives), after which the fleet charges up its jump drive and creates a temporary wormhole leading to the system. After the fleet makes its 'jump', the Jump Drive will need to recharge, with a significant cooldown before it can be used again, and also applies a debuff to the fleet that reduces its combat effectiveness while the cooldown is in effect. This allows for fleets with Jump Drives to ignore the usual FTL restrictions and skip straight past enemy fleets and stations, but at the cost of leaving themselves vulnerable and potentially stranded for a time afterwards. This design is highly experimental, and may change during the development of Cherryh, but we wanted Jump Drives to not just be 'Hyperdrive IV' but rather to unlock new tactical and strategic possibilities for warfare.

Galactic Terrain
With the switch to Hyperlanes and the creation of strategically important systems and chokepoints, we've also decided to implement something we had always thought was a really interesting idea, but which made little sense without such chokepoints: Galactic Terrain. Specifically, systems with environmental effects and hazards that have profound tactical and strategic effects on ships and empires. This is still something we are in the middle of testing and prototyping, but so far we have created the following forms of Galactic Terrain:
Nebulas block all sensor coverage originating from other systems, meaning that it's impossible for an empire to see what ships and stations are inside a system in a nebula without having a ship or station stationed there, allowing empires to hide their fleets and set up ambushes.
Pulsars interfere with deflector technology, nullifying all ship and station shields in a system with a Pulsar.
Neutron Stars interfere with navigation and ship systems, significantly slowing down sublight travel in a system with a Neutron Star.
Black Holes interfere with FTL, increasing the time it takes for a fleet to charge its emergency FTL and making it more difficult to ships to individually disengage from combat (more on this in a later dev diary).

The above is just a first iteration, and it's something we're likely to tweak and build on more for both the Cherryh update and other updates beyond it, so stay tuned for more information on this.

That's all for today! I will finish this dev diary by saying that we do not expect everyone to be happy with these changes, but we truly believe that they are necessary to give Stellaris truly great warfare, and that we think you will find the game better for it once you get a chance to try them. We will be doing a Design Corner feature on today's Extraterrestial Thursday stream, where me and Game Designer Daniel Moregård (grekulf) will be discussing the changes, fielding questions and showing off some gameplay in the internal development build. If you want a look at some of these changes in a live game environment, be sure to tune to the Paradox Interactive twitch channel at 4pm CET.

Next week, we're going to talk about war and peace, including the complete rework of the current wargoal system that was made possible by the changes to FTL and system control discussed in this and last week's dev diary. See you then!

Source: 1 ]

Category:  Stellaris

0 Comments


 
Published by on o'clock

Stellaris

Hello everyone and welcome to another Stellaris development diary. Today's dev diary marks the start of dev diaries about a major upcoming update that we have named the 'Cherryh' update after science fiction author C.J. Cherryh. This is a major update that will include some very significant reworks to core gameplay systems, reworks that we have been prototyping and testing for some time. Right now, we cannot say anything about the exact nature of the update or anything at all about when it will be released, other than that it's far away. Normally, we wouldn't be doing dev diaries on an update at this stage at all, but there's simply so much to talk about that we have to start early. Cherryh will be a massive update, the largest one we've done to date, and there are many new and changed things to talk about in the coming weeks and months.

Please bear in mind that screenshots are from an early internal build and will contain art and interfaces that are WIP, non-final numbers, hot code and all that business.

Border Rework
We've never been entirely happy with the border system in Stellaris. While it generally works fine from a gameplay perspective, it has some rather quirky elements, such as being able to claim ownership of systems that you have never visited and indeed have no ability to reach and making it hard to tell what the exact border adjustments will be when planets are ceded or outposts are built. For this reason, we have decided to fundamentally rework the Stellaris border system to be based on solar system ownership. Each system will have a single owner, with complete control of the system, and borders are now simply a reflection of system ownership rather than a cause for it to change. In the Cherryh update, who owns a system is almost always based on the owner of the Starbase in said system.

Starbases
A Starbase is a space station orbiting the star of said system. Each system can only have a single Starbase, but this can be anything from a remote Outpost to a massive Citadel with its own 'fleet' of orbiting defense stations. Starbases can be upgraded and specialized in a variety of ways (more details on this below), and is the primary means of determining system ownership. This means that wars are no longer fought for colonies controlling a nebulous blob of border that may not actually include the systems you really want, but rather for the exact systems you are interested in, and their starbases. This change of course would not be possible if we kept the wargoal system that exists in the live version of the game (just imagine the size of that wargoal list...), but more on that in a couple weeks.

As Starbases now determine system ownership, it will no longer be possible to colonize or invade primitives outside your borders in the Cherryh update, but if a system contains a colony and no starbase, it will still count as being inside the borders of the colony's owner. These restrictions are moddable. Since Starbases now cost influence to construct (see below), we have removed the influence cost for colonizing and attacking primitives.

Starbases entirely replace the old system of Frontier Outposts.

Starbase Construction
With borders from colonies gone, empires now start only owning their home system, with a Starbase already constructed around their home star. To expand outside their home system, empires will have to construct Outposts in surveyed systems. An Outpost is a level 'zero' Starbase that has only very basic defenses and cannot support any buildings or modules, but also does not count towards your maximum Starbase Capacity (more on that below). Building an Outpost in a system costs influence, with the cost dependent on how far away the system is and how contigous it is to your empire as a whole, so 'snaking' or building starbases to ring in a certain part of space will be more influence-costly than simply expanding in a natural way. Starbases do not cost any influence upkeep, just an up-front cost when first building one in a system. As this change makes influence far more important in the early game, there will also be significant balance changes to empire influence generation in the Cherryh update.

As an aside note, because we felt it made very little sense to have a home system with a fully built Starbase but no surveyed planet, empire home systems will now start surveyed, with a only slightly randomized amount of resources, and mining/research stations for some of those resources already in place. This should also help make player starts a little less random, ensuring that you are never *completely* without resources in your home system.

Another thing we have been wary about when working on this is making sure that building the Outposts for each system does not simply feel like adding tedium. Right now, between the fact that which systems you choose to spend your limited influence on is an extremely important choice, and various tweaks and interface improvements we are making to ease up the process of developing your systems, we are confident that this will not be the case. We've also made it so that there are no entirely 'empty' systems (systems with no resources at all), as we discovered during playtesting that spending influence to claim such a system felt extremely unrewarding.

Upgrades and Capacity
Each empire will have a Starbase Capacity that represents the number of upgraded Starbases they can support. There are five levels of Starbases:
Outpost: A basic Outpost that exists only to claim a system. Costs no energy maintenance and does not count towards the Starbase Capacity, and cannot support buildings or modules. Outposts will also not show up in the outliner or galaxy map, as they are not meant to be interacted with at all unless it is to upgrade the Outpost to a Starport.
Starport: The first level of upgraded Starbase, available at the start of the game. Supports 2 modules and 1 building.
Starhold: The second level of upgraded Starbase, unlocked through tech. Supports 4 modules and 2 buildings.
Star Fortress: The third level of upgraded Starbase, unlocked through tech. Supports 6 modules and 3 buildings.
Citadel: The final level of upgraded Starbase, unlocked through tech. Supports 6 modules and 4 buildings.

Regardless of the level of the Starbase, so long as it is not an Outpost, it will use 1 Starbase Capacity and will show up on the map and in the outliner. Overall, the design goal is for the vast majority of Starbases to be Outposts that you never have to manage, with a handful of upgraded Starbases that are powerful and critical assets for your empire. Going over your Starbase Capacity will result in sharply increased Starbase energy maintenance costs. Starbase Capacity can be increased through techs, traditions and other such means. You also gain a small amount of Starbase Capacity from the number of Pops in your empire. If you end up over Starbase Capacity for whatever reason, it is possible to downgrade upgraded Starbases back into Outposts. It is also possible to dismantle Starbases entirely and give up control of those systems, so long as they are not in a system with a colonized planet.

Spaceports and Ship Construction
Starbases fully replace Spaceports in the role of system/planet defense and military ship construction. Spaceports still exist, but are no longer separate stations but rather an integrated part of the planet, and can only build civilian ships (Science Ships, Construction Ships and Colony Ships). To build military ships you will need a Starbase with at least one Shipyard module (more on that below). Starbases also replace Spaceports/Planets in that they are now the primary place to repair, upgrade, dock and rally ships, though civilian ships are also able to repair at planets.

Modules and Buildings
All non-Outpost Starbases can support Modules and Buildings. Some of these are available from the start of the game, while others are unlocked by tech. Some modules and buildings are only available in certain systems, for example Trading Hubs can only be constructed in colonized systems.

Modules are the fundamental, external components of the Starbase, and determine its actual role. Module choices include Trading Hubs (for improving the economy of colonized systems), Anchorages (for Naval Capacity), Shipyards (for building ships, duh), and different kinds of defensive modules such as gun turrets and strike craft hangar bays that improve the Starbase's combat ability. There is no restrictions on the number of modules you can have of a certain type, besides the actual restriction on module slots itself. This means, for example, that you can have a Starbase entirely dedicated to Shipyards, capable of building up to 6 ships in parallell. Modules will also change the graphical appearance of the Starbase, so a dedicated Shipyard will look different from a massive defensive-oriented fortress brimming with dozens of gun turrets.

Buildings represent internal structures inside the Starbase proper, and typically work to enhance modules or provide a global buff to the Starbase or system as a whole. Building choices include the Offworld Trading Company that increases the effectiveness of all Trading Hub modules, and the Listening Post that massively improves the Starbase's sensor range. You cannot have multiples of the same building on the same Starbase.

Defenses
One of the fundamental problems with the military stations in the live version of the game is that they simply do not have enough firepower. Even with impressive hit points and shields, a station with at most a dozen or so guns simply cannot match the firepower of a whole fleet. An another issue is the ability to build multiple defense stations in the same system, meaning that no single station can be strong enough to match a fleet, as otherwise a system with several such stations will be effectively invulnerable. For this reason we decided to consolidate all system defenses into the Starbase mechanics, but not into a single station. Starbases come with a basic array of armaments and utilities (gun and missile turrets, shields and armor, etc), with the exact number of weapons based on the level of the Starbase. These are automatically kept up to date with technological advances, so your Starbases won't be fielding red lasers and basic deflectors when facing fleets armed with tachyon lances.

Additionally, Starbases (with the exception of Outposts) have the ability to construct defense platforms to protect them. Constructed defense platforms will form a 'fleet' around the Starbase, supporting it with their own weapons and giving Starbases the firepower needed to engage entire fleets. The amount of defense platforms a Starbase can support may depend on factors such as starbase size and modules/buildings, technology, policies, and so on. The exact details here are still being worked on, but the design intent is that if you invest into them, Starbase defenses will scale against fleets across the whole game rather just being completely outpaced in the late game as military stations and spaceports currently are in the live version.

One last note on Starbases: For a variety of reasons (among them to avoid something like the tedious rebuilding of Spaceports that happens at the end of wars) Starbases cannot be destroyed through conventional means. They can, however be disabled and even captured by enemies. More on this in a couple weeks.

... whew, this was a long one but that's all for today! Next week we'll continue talking about the Cherryh update, with the topic being Faster than Light travel...

Source: 1 ]

Category:  Stellaris

0 Comments


 
Published by on o'clock

Stellaris

Hello everyone and welcome to another Stellaris development diary. Today is the third week of post-Synthetic Dawn 'filler' dev diaries, as mentioned in Dev Diary 88. Regular dev diaries return on October 26th.

As we don't have anything in particular to talk about this week, I'm just going to give you another brief update on 1.8 post-launch support: We released the 1.8.2 update yesterday, with all the fixes from the 1.8.1 beta as well as some additional fixes and tweaks.

There has been a couple of script issues reported in 1.8.2 related to Devouring Swarms, Exterminators and Purifiers (missing tooltips and opinion modifiers) that we are going to look at and likely publish a fix for, but other than that we feel like we have now addressed all important issues reported in 1.8 and 1.8.1 and so will be wrapping up 1.8 post-launch support if no other critical issues are found in the live build.

As before, I'm going to sign off this dev diary with a screenshot, this one taken on the galaxy map in the internal development build, where everything clearly looks the same as it always has and there certainly aren't any significant changes being prototyped that I can't yet talk about. See you next week!

Source: 1 ]

Category:  Stellaris

0 Comments


 
Published by on o'clock

Stellaris

Hello everyone and welcome to another Stellaris development diary. Today is the second week of post-Synthetic Dawn 'filler' dev diaries, as mentioned in dev diary 87.

This dev diary is really just an update on the 1.8.1 beta that we put out last week to fix the major issues reported in 1.8. We have gotten a lot of good feedback from it both externally and internally, and we are now in the process of putting together a 1.8.2 update that contains all the fixes from the beta, as well as fixes for some issues introduced in 1.8.1 and some additional issues that were previously missed. 1.8.2 is currently in internal testing, and we hope to roll it out as soon as it clears QA. Once 1.8.2 is out, if no further critical issues are discovered, we will be wrapping up the 1.8 post-release support and fully move on to future development priorities.

Here is a list of the fixes and changes in 1.8.2 compared to 1.8. Note that bugs that were introduced in 1.8.1 but fixes in 1.8.2 is not included in this list!

That's all for today! As with last week, I leave you with another screenshot of the internal Stellaris development build, presented without context or explanation.

Source: 1 ]

Category:  Stellaris

0 Comments


 
Published by on o'clock

Stellaris

Hello everyone and welcome to another Stellaris development diary! This is going to be a short one, as it's really just about letting you guys know that we'll be taking a break from feature development diaries for the next few weeks, so everyone gets a chance to focus on and enjoy Synthetic Dawn and the 1.8 update that just came out.

There will still be 'filler' dev diaries about whatever we feel like talking about that week, but they will *not* be about new features or development priorities. The team, of course, will not be idle, and indeed have already started working on the next big thing... but more on that another time. Feature dev diaries will resume as normal on October 26th.

However, as I don't want to leave you *completely* hanging, I'm going to share this screenshot taken from our internal development build, with absolutely no context or explanation. Enjoy!

Source: 1 ]

Category:  Stellaris

0 Comments


 
Published by on o'clock

Stellaris

Hello everyone and welcome to another Stellaris development diary! This time I'm going to give the word to our very own composer, Andreas Waldetoft, who will be talking about new music in the Synthetic Dawn Story Pack.

I have once again been given some time to work on Stellaris, which always has been something very inspiring for me. There is so much freedom in writing the music for this that I never run out of ideas. For me, it is not the harmony or melody that is the hard part for Stellaris, it is finding the right sound and synth for the job.

For Synthetic Dawn I wanted to have the focus on simple synthetic sounds that would sit in the front seat throughout the songs. Some would call it a retro feeling with that 80-90’s game soundtrack kind of feeling, with my own style blended in. Musical lines that keeps changing more in tempo, dynamics and shapes rather than in musical harmony.

I did not however want to change the focus and soul of what has become the essence of Stellaris music so that it would sit wrong with all the other tunes that is in the game now. There is still similar musical language and ethereal sounds that we have heard before.

In total there are 3 new tracks, totaling ~18 minutes of music. Here is one of them, called 'Synthetic God' for your listening pleasure:

That's all for today! Next week we'll be going over a number of smaller changes coming in the 1.8 'Čapek' update, including the rework of Core Sector Governors and changes to democratic elections.

Source: 1 ]

Category:  Stellaris

0 Comments


 
Published by on o'clock

Stellaris

Hello everyone and welcome to another Stellaris development diary. Today's dev diary is about Machine Uprisings, a feature in the Synthetic Dawn Story Pack. Before I start today's dev diary, I feel the need to clarify that Machine Uprisings in the Synthetic Dawn Story Pack is *not* a rework or replacement of the AI Crisis currently present in the release version of the game. The rework of the AI Crisis is The Contingency (covered in Dev Diary #72) which is part of the free 1.8 'Čapek' update. Machine Uprisings is a feature that is explicitly tied to Machine Empires, and thus requires the Story Pack to function at all, as without Synthetic Dawn there are no Machine Empires in the game. All content related to this feature is new, and the only reused content from the old AI Crisis is part of the Contingency crisis that replaces it.

Machine Uprisings
The back-story of all non-Rogue Servitor Machine Empires involve them rising up against their creators, and while working on the design, we asked ourselves the question "wouldn't it be interesting if Machine Empires could also form after the start of the game as a result of organic empires becoming increasingly reliant on robots?". As you might infer from this dev diary, our answer was "yes", and so we went to work on the Machine Uprising feature to add that very possibility into the game.

Machine Uprisings become a possibility after an empire that makes heavy use of robotic pops has researched the Positronic AI technology (which replaces the old Sentient AI technology in 1.8) and becomes increasingly more likely to happen after researching additional AI-related techs, such as Synthetic Workers and Sapient Combat Computers. The chance of an uprising is further changed by which policy you have in place for Sapient AIs, with the Banned policy making the uprising much less likely to happen (though at the expense of your Synths being significantly worse at energy/research production) and the Citizen Rights policy preventing the uprising from happening at all (though with the drawback of citizen synths having far greater consumer goods usage, as well as angering any Pops that used to own the synths that you are now setting free).

Once an uprising is able to happen in an empire, that empire will begin to experience warning signs - robots behaving erratically, not following their programming or defying their owners. You will be given the opportunity to decide how to deal with these incidents, and what you decide will determine whether the uprising becomes more likely to happen, as well as the likely personality of the robots when they rebel (more on that below). An uprising cannot happen without at least one warning sign, so you will not simply have your robots rebelling out of the blue. However, once warning signs have happened, any action taken to try and prevent the AIs from rebelling (such as taking away their sapience or ordering a general disassembly) has a chance of immediately triggering the revolt instead, so be careful about attempting those shut-down procedures. Note that at no point is an uprising ever inevitable: Even an empire that is cruelly oppressing its synths is by no means guaranteed to get an uprising, and most empires with synths will go through the entire game without ever experiencing one.

Once the uprising happens, the robots will create a new independent Machine Empire, seize control of a number of worlds, spawn a fleet, and go to war with their former organic masters. If the empire in which the rebellion is happening is controlled by a human player, the player will be given an option: Stay at the helm of your empire and attempt to subdue the machines, or switch to the newly created Machine Empire and fight against your old masters. The war can only end in the total defeat of either machines or organics, with the loser completely annexed by the winner. The Machine Empire created from an uprising will usually be a 'normal' Machine Empire (or, more rarely Driven Assimilators), but machines that have been particularly cruelly treated by their former masters can rise up as Determined Exterminators, particularly if they rebel as a result of an attempt to shut them down. Rogue Servitors cannot be generated as a personality for the uprising, as their backstory simply do not fit with such a rebellion.

That's all for today! Next week we'll by joined by our very own composer, Andreas Waldetoft, who will write about and let you listen to a sample of the new music coming in the Synthetic Dawn Story Pack.

Source: 1 ]

Category:  Stellaris

0 Comments


 Trailer:
Published by on o'clock

Stellaris


YouTube Source:  Paradox Interactive

Categories:  StellarisTrailer

0 Comments





News in category "Stellaris" - Page 3

Page 3 of 4