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

News in category "Stellaris" - Page 2

Page 2 of 4


doFollow


 
Published by on o'clock

Hello everyone and welcome to another Stellaris development diary. Today's dev diary is about the 2.0 'Cherryh' update, and will delve into the long-awaited topic of Doomstacks, combat balance and some changes coming to ship design and components.

Doomstacks
'Doomstacks', the concept of rolling all your ships into a single stack in order to be able to beat your opponent's single stack has long been a popular discussion topic on these forums. It's a fairly common design problem in strategy games owing to the principles of force concentration outlined in Lanchester's Laws: A larger force engaged with a smaller one will not only win the battle, but take disproportionately less casualties. In other words, if a 13k force engages a 10k force (all components being equal so there's no other factors at work), the 13k force will not only win, but will inflict far more than 1.3x the casualties on the inferior force that the superior force inflicts on the lesser force. This, combined with the high decisiveness and lethality of combat in Stellaris (and many other strategy games) means that bringing an inferior force to battle is always a no-win situation: Not only will you lose tactically, you will also lose strategically, as whatever damage you inflict on enemy is outclassed by the damage they inflict on you in turn.

Many people have proposed solutions to Doomstacks. Some have been simple, others complex, but what most of them have missed (and the reason we have taken so long to address this) is that there is no one solution. It is a complex problem with multiple causes and problems, and the only way to begin to address it is to tackle those problems individually. To that end, what the Stellaris designers did was break down the Doomstack issue into its component problems, and then create solutions for those problems. I will now list the problems we identified, as well as our solutions to them.

Problem 1: Disproportionate Casualties
Disproportionate Casualties is the problem we talked about above: Engaging a larger force with a smaller one is virtually always a losing proposition because of the disproportionally greater casualties taken by the smaller force. Naturally, a larger force should more powerful, but the fact that a force twice the size will annihilate the enemy while barely suffering any losses makes combat and warfare far too pain-free when you have the advantage in numbers. For this reason we have decided to introduce something called the Force Disparity Combat Bonus. The Force Disparity Combat Bonus is applied when a smaller force is engaged with a larger one in battle ('force' being every ship engaged on one side of a battle, regardless of how many fleets and empires are involved on each side), and gives a bonus to the firing speed of all ships belonging to the smaller force. As an example (example numbers only, likely not final numbers) a force that is half the size of the enemy might gain a 50% bonus to its firing speed, representing the fact that the smaller force has an easier time manuevering and targeting the larger enemy force. The larger force is still more powerful and will likely win the battle (unless the smaller force has a significant technological advantage), but will almost certainly suffer losses in the process, making it possible to force an enemy to bear a cost for their victories even when they have overwhelming numbers.

Problem 2: Decisive Battles
In Stellaris, fleets that are not ordered to make a manual retreat will fight to the death. Combined with the disproportionate casualties problem, this means that wars are often decided in a single battle, with the loser being at best diminished to the point of no longer being able to offer effective resistance. It also encourages excessive caution in warfare as every minor skirmish turns into a bloody battle of annihilation. To address this problem, we have introduced the concept of Ship Disengagement. Rather than always fight to the death, ships can now flee battle and survive to fight another day. In combat, any ship that takes hull damage while already below 50% health will have a chance to disengage from battle, depending primarily on the amount of damage inflicted, and secondarily on the ship class (smaller ships have an easier time disengaging than larger ones). A ship that disengages will instantly leave the battle and can no longer attack ships or be attacked, though it will still show up in the combat interface, with an icon clearly indicating it as Disengaged.

If a fleet engaged in battle contains only Disengaged ships, it will be forced to make an Emergency FTL jump and become Missing in Action, limping home heavily damaged. However, if the combat ends without the fleet making an emergency FTL jump (manual or forced), the Disengaged ships will rejoin the fleet at the end of the battle, damaged and in need of repair certainly, but otherwise normally operational. The intention with this feature is that generally, more ships should Disengage than outright be killed in battle, making it so that an empire that loses a battle can pull back, repair their ships, and stay in the fight rather than having to replace every ship involved in a combat loss. In addition to the factors mentioned above, the chance for a ship to Disengage is also affected by various modifiers such as terrain (see Dev Diary #92 for details on Galactic Terrain), War Doctrine (more on that below) and whether the ship is in friendly territory or not.

Problem 3: Lack of need for Admirals
Though not directly related to Doomstacks, one of the issues we identified and wanted to address was the fact that empires generally only need a single Admiral, regardless of whether it is a small empire with a handful of corvettes or a sprawling empire with hundreds of ships. To solve this problem, we have introduced the concept of Command Limit. Command Limit is a limit on how large any one individual fleet in your empire can be (right now it's a hard-cap, though we might change it into a soft-cap), and thus how many ships an admiral can give their combat bonuses to. Command Limit is primarily given from Technology and Traditions, Admiral Skill does not impact it. The reason for this is that we do not want a fleet's command limit to suddenly drop due to the death of an Admiral or other temporary factors that would force frequent and annoying reorganizations of your fleets. Note that Command Limit is not meant to solve the problem of Doomstacks itself, but combined with the other changes (and the FTL changes that makes it so it's harder to cover your entire empire with a single fleet) it should naturally encourage keeping several fleets, as it is now possible to skirmish and fight delaying actions without risking the entire war in a single battle. As a part of this (and the FTL changes) we have also made it so that fleets that are following other fleets will now jump into FTL together, making it possible to have fleets following each other without becoming 'decoupled' as they travel across multiple systems.

We believe that these changes, together with many of the other changes we are making (Starbases, FTL rework, etc al) will naturally change the way wars are fought away from Doomstack primacy. Certainly, there will still be wars decided by large-scale engagements of both sides' navies, and certainly it will sometimes be advantageous to keep all of your fleets in one place. But this should no longer be the only way to play, and there should be many new tactical and strategic opportunities available to players in how they use their navies.

Moving on from the topic of Doomstacks, we're next going to cover some changes coming to the ship designer and the way ships are built.

Ship Reactors
The first and possibly most significant change is that we have changed the way Ship Power works. Instead of reactors being a component like any other, requiring a fiddly excercise of swapping reactors for shields/armor and vice versa, each ship now simply has a reactor with a certain power output depending on ship class and technology. For example, a starting Corvette has a Corvette Fission Reactor, outputting a measly 75 power, while a Zero Point Battleship Reactor gives you a massive 1550 power to balance between weapons, shields and Aux utilities. To add a little bit of flexibility into this system, we have created a new line of utilities called Reactor Boosters that go in the Aux slot and provide some extra power for the ship, allowing smaller power deficiencies to be addressed without needing to downgrade components. Basic Reactor Boosters are available directly at the start of the game, and better ones can be researched as you improve your reactor technology.

Armor, Shields and Hull
Armor has always been a somewhat problematic mechanic in Stellaris. Originally, Armor was a direct damage reduction (where 1 armor negated 1 damage from any shot), but this effectively resulted in high-armor battleships being completely invincible, so we changed it into the percentage-based reduction system that is currently in the live version of the game. However, we couldn't simply map 1 armor to 1% damage reduction, as you once again ended up with invincible battleships and barely armored corvettes, so we created a formula for mapping armor to damage reduction that pretty much nobody understands, but largely can be broken down into 'put some armor on your cruisers and battleships, ignore it on corvettes and destroyers'. Add to this the fact that you can still get very high damage reduction numbers on bigger ships, and you begin to understand why plasma has frequently been the dominant weapon in the combat meta.

To address this issue once and for all, we have decided to rework Armor to work more like Shields and create a more direct trade-off between the two. Each point of Armor is now effectively one extra hit point for the ship, forming a new health bar between Hull and Shields. Armor generally offers the same amount of extra 'health' as Shields of the same level, but unlike Shields will normally not repair itself over time, instead requiring the ship to head to a Starbase for repairs to restore its armor. However, Armor has the advantage of not costing any power, and is a more reliable protection, as unlike Shields it cannot be bypassed by missile weapons. Different weapons will do differing amounts of damage to Armor, Shields and Hull (for example, Autocannons shred shields and hull, but are very weak against Armor), and there are new components and resources that reward specialization (by for example making you choose between boosting all armor OR shields on a ship), making it so that specialized ships are more effective but vulnerable to other ships built to counter them. Finally, the direct effectiveness of Armor and Shields relative to hull has been increased, and a ship can now have Armor/Shield hit points directly comparable to its hull hit points.

Missiles and Hull Damage
Missiles, even with the buffs they were given in Čapek, occupy a bit of an odd spot in Stellaris, with no particular role of their own other than simply being somewhat more efficient weapons that are hard-countered by Point Defense. The one exception to this is Torpedoes, that have their own dedicated slot and purpose (bypassing shields and destroying heavily armored ships), but even that slot has the rather ill-suited Energy Torpedoes that aren't Torpedoes at all but just a regular energy weapon, resulting in even more confusion and diffusion. In Cherryh, we've decided to make all missiles more similar to Torpedoes, making it so that the Torpedo slot is the only slot in which you can put missile weapons, and making it so that all missiles bypass shields entirely. In addition to this, we've also made a change to ships that have taken hull damage: Damaged ships will have their speed and combat ability reduced, all the way down to a ~50% reduction when they are nearly dead. This means that missiles, unless stopped by PD, are now a weapon explicitly for softening up the enemy by damaging and reducing the effectiveness of their ships, slipping through shields and wreaking havoc directly on enemy armor and hull. It also means that empires that want to invest heavily in the power of missiles will need to use designs and ship classes that can pack torpedo slots, instead of simply putting missiles on everything that would normally mount a different weapon. There are still different missiles with different roles: Torpedoes are slow and inaccurate but excellent at punching through armor, while Swarmer Missiles are poor against armor but wreak havoc on hull and (as before) are ideally suited to overwhelming enemy PD. Energy Torpedoes have been removed from the Torpedo slot and now instead a Large slot weapon, the equivalent of Kinetic Artillery for Energy weapons.

Combat Computers
Another change to ship design in the Cherryh update is the reintroduction of choosing combat computers for your designs. Rather than there being Corvette, Destroyer, Cruiser etc combat computers, there are now four broad categories with their own tactics:
Swarm: Ships with Swarm computers charge at the enemy and make 'attack runs' on the enemy, similar to strike craft
Picket: Ships with Picket computers advance forward and engage the enemy at close range
Line: Ships with Line computers remain at medium range and fire at the enemy
Artillery: Ships with Artillery computers hang back and fire at the enemy from maximum possible range

As we still do not want one ship class to be able to fill every possible role, we have still restricted which computers are available to which classes (for example, Corvettes can choose Swarm or Picket) but there is always at least two choices available for your design.

War Doctrines
Lastly for today, I just wanted to mention the introduction of War Doctrines. This is a new policy that becomes available once the Interstellar Fleet Traditions society technology has been researched, and allows you to pick an overall strategic military doctrine for your fleets based on how you intend to fight. For example, the Defense in Depth doctrine gives a bonus to ship combat ability inside friendly territory, ideal for defensive wars, while the Hit and Run doctrine increases the chance of your ships Disengaging from combat and the time you need to be in battle before using Emergency FTL, perfect for players that want to use raiding or skirmishing tactics.

That's all for today! Next week we're going to be talking about technology in Cherryh, and how tech tiers and progression is changing. December 7th also happens to be the release date of the Humanoids Species Pack, so you can count on us saying something about that as well. See you then!

Source: 1 ]

Category:  Stellaris

0 Comments


 
Published by on o'clock

Humanoids Species Pack
Over the last year or so, and especially in the last few months, there has been a lot of clamoring for more portraits and another ship-set like the one we added in Plantoids. Because of the amount of coder and content designer time we're putting into the major overhauls in the Cherryh update, we ended up with a lot of extra art time, and so we decided to oblige. Back in the Heinlein update, we added a bunch of free humanoid portraits that proved to be immensely popular - close to half of games started is with some variant of humanoid. Combine with there seeming to be a demand for a more 'classic western sci-fi' ship-set with sleeker lines and curves than the Mammalian one, and the design for the Humanoid Species Pack was born. Our artists have been quietly working away at it behind the scenes, and now it's almost ready.

So what's in the Humanoid Species Pack? Here is the feature list:
- 10 new Humanoid portraits
- A completely new ship set inspired by classic western sci-fi
- A new city set for Humanoids
- A new pre-scripted empire, the Fanatic Authoritarian/Materialist Voor Technocracy, with a portrait inspired by the 'loading screen aliens' from our own official art
- 3 new advisor voices offering alternative takes on existing ethics, based on the United Nations of Earth ('Dignified Xenophile'), Commonwealth of Man ('Disciplined Militarist') and Voor Technocracy ('Ruthless Materialist'). Samples from each of the new voices has been attached to the bottom of this post.
- 3 new music tracks that are remixes of classic Stellaris songs

Of course, the 5 Humanoid portraits that are already in the base game will remain free and available to everyone.

The Humanoids Species Pack will come out on December 7th, 2017 and will cost $7.99 US dollars or your regional equivalent. For those who want to buy it right now, pre-orders are available through the Paradox Shop. To pre-order, follow this link.

Next week we'll get back to talking about the Cherryh update on the topic of doomstacks (for real this time).

Source: 1 ]

Category:  Stellaris

0 Comments


 
Published by on o'clock

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

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

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

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

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

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

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

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





News in category "Stellaris" - Page 2

Page 2 of 4