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 5


doFollow
Für Solidarität und freie Bildung

Blogroll

Aktionsbündnis gegen Studiengebühren AStA Uni Kiel

World of Warcraft

(Ein Troll für alle Fälle)



 
Published by on o'clock

Stellaris


Here are all the episodes of "Stellaris YouTuber War "

Category:  Stellaris

0 Comments


 
Published by on o'clock

Stellaris

Hello everyone and welcome to another Stellaris dev diary. Today's dev diary is about some changes coming to ground combat and armies in the 2.0 'Cherryh' update. This will be the last dev diary before we take a break for the holidays, so there will be no diaries in the next week or the week after that. Stellaris dev diaries return on Thursday January 11th, 2018.

Defense Armies and Fortresses
Constructing Defense Armies have always been largely a meaningless exercise in Stellaris. While they are useful for reducing Unrest and occasionally might be able to beat off an unprepared attacker, the fact that a planet is capped on how many armies can be defending it while the attacker is *not* capped on how many armies are attacking, coupled with the general weakness of defense armies, means that defending a planet against a ground invasion is generally an exercise in futility and will at most delay an attacker by a few weeks. However, if we solved this by just making defense armies a lot stronger or capping the number of attacking units, the result would turn every invasion of a backwater colony into a big affair - something that is not particularly desirable when a war can involve several different actors with hundreds of planets between them.

For this reason, we have decided to rework Defense Armies into something that is actually useful, but requires a significant investment of resources to muster more than a token defense. Instead of being directly buildable by the empire, defense armies are created from certain buildings. The capital building will produce defense armies depending on its level, as will some other planetary uniques like Military Academy. If you want a planet to be well defended, however, you will need to construct Fortress building on its tiles. Fortresses require a pop to work them, do not produce any other resources than a small amount of Unity, but provide a significant amount of defense armies to protect the planet. Armies spawned by Fortresses are also impervious to orbital bombardment, and will not be able to be killed without first ruining the building itself. The armies generated by a building have their species and type set by the pop working it, so a Very Strong Battle Thrall will produce several powerful defense armies if placed on a Fortress, and special pops like Droids will produce their own variants like Robotic Defense Armies rather than the normal ones. Fortified worlds will also be able to be fit with an FTL inhibitor (the exact way they get them is not yet determined) that prevents enemy fleets from leaving the system unless the world is captured, which allows for the creation of Fortress Worlds to protect strategically important systems.
(Building icon is a placeholder)

One more important change related to Defense Armies is a change to Unrest: Armies on planets no longer reduce Unrest directly. Instead, to handle a planet with high Unrest, you will need to construct Fortress-style buildings or take other measures (such as using Edicts) to reduce the planetary Unrest. This means you cannot simply capture a planet and then spam a dozen defense armies to immediately zero out the Unrest. As part of this, we will be balancing certain events and effect to ensure newly captured worlds do not instantly defect back to their former owner.

Finally, as part of all these changes Defense Armies have received a general buff and there are several new technologies that unlock additional tiers of forts and various improvements to Defense Armies' combat ability, meaning that they will grow stronger alongside the invention of new, more powerful assault armies.

Assault Army Management
A major aim of our changes to armies is to reduce the amount of unnecessary micromanagement of armies. For this reason, and to make Assault Armies' role more explicit, we have decided to change Assault Armies to always be based in space. Whenever not directly engaged in an invasion, Assault Armies will now always automatically embark onto their transports, ready to be used to invade another world. We also aim to fix the minor but immersion-breaking bug where transport fleets are giving endlessly increasing sequential names whenever they land and embark again.

Combat Width, Retreating and Collateral Damage
Another change to ground combat is the introduction of new mechanics in the form of Combat Width. Combat Width is determined by the size of the planet, and decides how many armies can be taking and receiving damage at the same time: For example, if 20 assault armies invade a world held by 10 defense armies with a combat width of 10, all 10 defense armies will be immediately engaged in battle while only half the assault armies will be able to deal and receive damage, with additional assault armies joining the fray as the armies in front of them are destroyed. This means that it is no longer possible to take a well defended world without losses by simply throwing a hundred clone armies at it: If you wish to minimize losses (and thus War Exhaustion), you will need to invest in expensive, high-maintenance elite armies.
(Interface not final)

We've also added the concept of Collateral Damage: As armies fight on the planet, civilians and civilian infrastructure is caught in the fighting. Each time an army deals damage in battle, it will inflict a random amount of Collateral Damage, which increases Planetary Damage similar to Orbital Bombardment (see below) and can lead to the death of Pops and the destruction of buildings and tiles. Some armies will deal more Collateral Damage than others: For example, Xenomorph armies are highly destructive and cost-efficient, but will wreak immense havoc on the planet, potentially leaving it in ruins in the process of capturing it for your empire.

While working on combat mechanics we also took the time to change the way Morale Damage works, making it something that is suffered by both sides (instead of just the loser) and making the effects of it more gradual, so that armies suffer a drop in combat efficiency once they are <50% morale, and then another, sharper drop when they are broken (0% morale). This should make certain armies, such as Psi Armies, highly effective against low-morale opponents like Slave Armies, but less effective against an unfeeling army of Droids. Finally, we've also tweaked the damage-dealing algorithm so that damage is less evenly spread among combatants, making it so that even an outnumbered force can destroy regiments and inflict war exhaustion on the enemy.

Finally, we have made some changes to retreats. When an attacker retreats from a ground combat, there is now a significant chance that each retreating regiment is destroyed while attempting to return to space, making retreat a risky endeavour and eliminating the tactic of simply send in the same army again and again in wave attacks, instead making retreats something you do in order to preserve at least some of your army in a poorly chosen engagement.

Orbital Bombardment Changes
Finally, again in the interest of reducing the micromanagement needed during war, we've changed the way orbital bombardment works. Fortifications have been entirely cut from planets, so that there is no need to bombard lightly defended worlds before going in with the ground troops. Instead, we have added a requirement that planets cannot be invaded if there is a hostile Starbase in the system, so that transports cannot snipe worlds that are protected by defensive installations present in the same system. Orbital Bombardment, instead of being something you have to manage and wait for in every single planetary engagement, is now something you do to soften up a particularly well defended target, or simply to wreak havoc on the enemy's planet and drive up their War Exhaustion.

As a planet is bombarded, the fleet will deal Planetary Damage, ruining buildings and killing Pops. Bombarding fleets will also do damage to armies present on the planet (unless those armies are protected by a Fortress), and over a long enough time can decimate a defending force, though doing so will likely cause heavy damage to the planet and may delay the attacker long enough that the owner of the planet has time to build up their forces or inflict enough war exhaustion to force a peace. The rate at which the planet is damaged can also be slowed with the construction of buildings such as Planetary Defense Shield, further dragging out the process.

As part of these changes, we've consolidated the Bombardment Stances into the following:
Selective: Deals normal damage to armies/buildings and light damage to pops. Cannot kill the last 10 pops.
Indiscriminate: Deals heavy damage to armies, buildings and pops. Cannot kill the last 5 pops.
Armageddon: Deals massive damage to armies, buildings and pops. Can turn planets into depopulated Tomb Worlds with enough bombardment. Only available to certain empires such as Purifiers.

Attachments
Finally, on the topic of attachments, we have decided to cut them entirely from the game. We discussed a variety of ways to improve the way you assign them, but ultimately decided that we already have so many types of armies and not nearly enough combat mechanics to justify a significant investment of UI time that could go towards something like the Fleet Manager instead. The technologies that previously unlocked attachments will be changed to give other effects, such as direct buffs to certain army types.

That's all for today! As I said, we're now going on hiatus, so I'll see you again on January 11th with a dev diary about... well, that's a secret, actually. You'll just have to wait and see!

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 new interface functionalities for navies in the 2.0 'Cherryh' update that we collectively call the Fleet Manager. Please note that the interfaces shown in this dev diary are early WIP versions that have not yet seen an artist's touch, and will look very different in the finished product, meaning that feedback on their look/layout is pointless at this stage. Thank you!

Fleet Manager
The fleet manager is a new interface accessible from the top bar, that as the name implies, allows you to overview and manage your navies. The fleet manager lists all fleets in your empire, filtering away small splinters that are in the process of being merged into another fleet. Each fleet has something we call a Fleet Template, which is a stored configuration of what that fleet *should* look like. Fleet Templates keep track of not just ship sizes (such as corvette or cruiser) but also of individual designs, so a Fleet Template might be set up to contain 10 Torpedo and 5 Interceptor-class corvettes alongside a mix of Picket and Gunboat style Destroyers, for example. Templates can be edited directly through the Fleet Manager without needing to build ships, by for example deciding to add another 5 Interceptor-class corvettes to the above listed fleet. Templates can be created directly without making a fleet first, and then reinforced to create the actual fleet. We are also planning to add template duplication and copy/paste functionality in order to be able to quickly set up a new fleet or make your fleets conform to a desired standard.

Whenever a fleet is missing ships that are listed in its Template, the option exists to Reinforce that fleet, which can be done either from the Fleet Manager or directly from the fleet view itself. Issuing a reinforce command will start production of as many missing ships as you can afford at your current amount of minerals, which will be automatically distributed among appropriately placed shipyards and sent to join and merge with the fleet once finished. In addition to the ability to reinforce fleets individually, there is also a Reinforce All button, which will attempt to reinforce missing ships in all fleets up to the amount you can afford with your current level of minerals, and can be used to fully replenish your navy in a single click if you have enough resources on hand. The Fleet Manager also offers the option to Retrofit ship designs. Let's take the example of the mixed Interceptor and Torpedo-class fleet above, where you have 10 Torpedo and 10 Interceptor-class ships. If you decide that you no longer need the Interceptors, you can use Retrofit to easily switch one class to another, selectively upgrading the Interceptor-class ships into Torpedo-class ships.

Home Bases
Also being introduced along with the Fleet Manager is the concept of Home Bases. Each fleet will be able to have a Home Base set, with any friendly upgraded Starbase being valid as a Home Base. This is where the fleet will return when the Return Home order is issued, gets slight priority for actions such as reinforcing (though the focus is on distributing production sensibly rather than always using the home base), and is intended to tie into other fleet mechanics planned for Cherryh that we are not quite ready to talk about yet.

That's all for today! Next week we'll be continuing to talk about Cherryh, on the topic of armies. 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 two topics: Technology in the 2.0 'Cherryh' update, and the release of the Humanoids Species Pack that is coming out today and will be available for purchase around 15:00 CET.

Humanoids Species Pack
We already covered the details of the Humanoids Species Pack in Dev Diary #95, so rather than repeating myself, I am simply going to post the changelog, along with a short excerpt on the new prescripted empire, the Voor Technocracy, that we modeled on the 'loading screen aliens' and which are coming in the species pack along with the portraits, ships, city graphics, new advisor voices and music.

On the Voor Technocracy:
The Voor were once a carefree people. They evolved during an extended interglacial period, in the lush, temperate woods on their homeplanet Hiverion, where resources were plentiful. But as the planet began to revert back to a glacial state, they too had to transform to survive. The harsh climate hardened the Voor and gave rise to an authoritarian technocracy bent on dominating its surroundings through scientific advancement and the acquisition of new technologies.

Soon they had conquered their homeworld, but survival came at a steep price for the Voor people who lost autonomy of both their bodies and minds in the process. To guarantee their submission, their brains were forcibly enhanced with crude cybernetic implants, transforming them into willing instruments of science.

The Voor's deep-seated contempt for inferior intellects coupled with their need to control make them unwanted neighbors. This is unlikely to bother them, however, as what limited interest they take in other lifeforms is primarily of a scientific nature. Secretive and calculating, the Voor prefer to observe the world through the lens of a microscope, carefully plotting out their next step on the path to supremacy.
Click to expand...
That's it as far 1.9 and the Humanoids Species Pack goes. I'm personally very happy with how Humanoids turned out, and I hope you'll enjoy using it for your Stellaris empires as much as I am. On to the Cherryh update!

Technological Progression
In the 2.0 'Cherryh' update, we have made a number of changes to progression when it comes to technology. First of all, we have expanded on the number of technologies that empires start with. Rather than only starting with one type of weapon and no defensive or auxiliary utilities, all empires now start with basic Red Lasers, Mass Drivers, Nuclear Missiles, Deflectors and Armor, as well as a basic aux slot component in the form of Reactor Boosters that was covered in last week's dev diary. The reasoning for this is that we wanted to eliminate false choices and have some depth to ship design and counter-design available immediately on game start, rather than having to unlock several basic technologies before you could even start to vary your designs. With missiles moving to a dedicated torpedo slot (also covered in Dev Diary #96, this also means that the Torpedo/Missile Boat corvette layout is also immediately available.

Secondly, we have decided to increase the number of tech tiers in the game to make technological progression a more consistent experience. For those that do not know, each technology currently belongs to a tier between 1-4, with a certain number of tier 1 technologies being required before you can research tier 2 technologies in the same field, and so on. However, because the 4th tier is only used for end-game technologies like Mega-Engineering, this means that technologies with more than 3 steps such as reactors, shields and armor are spread haphazardly over the tiers, and it's not uncommon to have Cold Fusion research come up as available immediately after researching Fusion, for example. To better fit the tiers to the technologies we have, we have decided to increase the number of tiers to 5, with the tiers looking roughly like this:
Tier 1: Basic Early Game Tech (Fusion, Automated Exploration, Robotic Workers, etc)
Tier 2: Advanced Early Game Tech (Cold Fusion, Destroyers, Planetary Capital, etc)
Tier 3: Basic Mid Game Tech (Antimatter, Cruisers, Wormholes, etc)
Tier 4: Advanced Mid Game Tech (Zero Point Power, Battleships, Empire Capital, etc)
Tier 5: Late-Game Tech (Mega-Engineering, Ascension Theory, Repeatables, etc)
We have also added a large number of new technologies to the game, both in the form of techs that handle new features (like Wormhole Stabilization and Space Trading) and to improve on existing ones, like a line of techs for each ship hull (Corvette, Destroyer, etc) that improves hull points and construction speed. Additionally, we have changed the general progression of ship components so that each upgrade is now more significant. For example, blue lasers now offer approximately 30% higher damage than red lasers, rather than a mere 10-15% as in the current live build. This should mean that focusing on technology is now an actual valid alternative to simply massing ships, though we still want to avoid the tech-as-only-viable-path-to-victory problem that many 4x games suffer from. Finally, we've also added some new highly advanced 'tier 6' technologies to Fallen Empires that cannot be researched normally and are only attainable by scavenging the wrecks of their ships.

Another thing that is changing in 2.0 'Cherryh' is tech costs and the tech penalty. Because of the new Starbase system and the fact that planets are no longer needed to control space, we felt that the old tech penalty based entirely on planets and pops was overly punitive and strongly encouraged having as few planets as possible and relying on space-based resources instead. For this reason, we have changed the Tech and Unity penalties to no longer be based on pops, but rather purely on the number of owned planets and systems, with each owned system and colonized planet adding to your tech and unity costs, and planets overall having less on an impact on tech costs than before. We have also raised the base cost of techs, particularly high tier techs, to compensate for the lowered penalties and slow down late-game tech progression so an empire doesn't have all technologies unlocked within the first century. This should not be taken as playing 'tall' now being unfeasible, just that it is no longer strictly about keeping few planets, but rather limiting the number of systems you expand to in order to benefit from lower tech/unity penalties and the ability to maintain a high ratio of upgraded starbases.

That's all for today! Next week's dev diary will also be about the Cherryh update, talking about a little usability feature that we call the Fleet Manager. 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 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

Stellaris

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

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





News in category "Stellaris" - Page 3

Page 3 of 5