Jul 21, 2023

Developer Insights #21 - Rockets' Red Glare

Kerbal Space Program 2 - mikey

In aerospace, a recurring joke is that every discipline considers their part of the project the most critical to mission success. Propulsion – obviously without engines you’re getting nowhere! Mission analysis? Where will you go without an actual mission? How are you steering your rocket without guidance, navigation, and control? Electrical and life support – obviously key. Pulling off a successful space mission is really a massively interdisciplinary undertaking.

It's that way with KSP2 as well. Different community members have varied perspectives on what features we should add or improve next. As KSP1’s modding community proves, there are thousands of possible features, and dozens of possible approaches to each feature. That’s a lot to take in. One gameplay system that we have heard a lot of enthusiasm for is thermodynamics, and thermodynamics is very dear to my heart.

In this dev blog I’m going to go into the design of the thermal systems in KSP2. It is rather long, but it is a complex topic worthy of discussion, and the community deserves a good analysis of what we’re doing, where the core challenges are, and where we are making specific design choices for interesting gameplay.

Thermal Challenges

In Kerbal Space Program 2, we try to introduce prospective rocketeers to the edges of various space disciplines. A lot of this skews towards mission planning and vehicle design but making sure we touch on many of the core spaceflight challenges is important. Heat management is one of the more underrepresented challenges in spaceflight, which is too bad, because it’s pretty…COOL.

We're aiming to have a much larger scope of thermal gameplay elements when compared KSP1 – we need to be able to surface new and exciting challenges that range from the mundane (don’t dunk a Kerbal in an active volcano) to the exotic (fitting a few thousand square meters of radiator to your interstellar vessel) to the really hardcore (building a functional mining colony in the shade of a mountain on a tidally locked planet really close to a star!). This all comes from the vastly increased set of environments we have under construction, parts you’ll use, and missions we want you to fly.

What this fundamentally means is that for KSP2, we have had to redesign the entire thermal system from scratch. This system needs to do a few things right that we felt couldn’t be accomplished by the KSP1 thermal model:

It must feel authentic and model the core challenges of heat for spaceflight, atmospheric flight and colony building.
At the same time, it should have an appropriate level of abstraction so that it is teachable in the same way that other KSP systems are, such as fuel and power flow.
It must be predictable, plannable, and stable enough so that players can feel confident planning missions and building vehicles or colonies in contexts that involve heat.
It needs to work at different scales – we need to handle a single heat producing part at 1x time warp, and we need to handle 50 heat producing parts at 10,000,000x time warp.

These are big challenges – and they don’t even include the technical challenges of making the system stable and performant throughout the whole game.

Diving Core User Stories

In designing a system for KSP2, we often want to get a sense of the physics and reality that relate to a system. These can inform the user stories we want players to grapple with when playing the game. There are three core areas of heat management we want to deal with:

Generation and removal of heat using parts on a vessel or colony
Reentry and atmospheric heating on planets with atmospheres
Environmental heat sources and sinks (oceans, etc.) that can affect vessels and colonies

I'll start out by examining some of the physics and reality behind these three stories.

[h5]Avoiding Meltdowns[/h5]
In everyday life, almost every useful process generates some level of waste heat. Your computer generates waste heat when it plays KSP2, a nuclear reactor making electricity generates waste heat, and even your body generates excess heat. A good rule of thumb is that the more exciting the piece of tech you’re running is, the larger the waste heat generated, and there are some really cool pieces of technology we’re looking at for use in KSP2.

When things heat up, we need to get rid of the excess energy somehow. Not getting rid of it results in consequences, like nuclear meltdowns.

The three common processes that move heat around.

There are three processes that can do this: convection, conduction and radiation. Convection is a very effective way of dispersing heat, using atmospheric or fluid currents to move heat away from a heat object. Conduction is also efficient and relies on two objects touching – heat will flow from the hot to cold object. Radiation is the least effective way of dispersing heat and relies on the tendency of hot objects to emit photons, which carry away heat energy.

Heat in space is a real problem. You might think that it is cold in space – after all, it is very high up, and dark, which we associate with cold. Seems reasonable. Trekkies among the audience may be familiar with a famous line from Star Trek II – “it is very cold in space”, which reveals that though Khan has a great flair for the dramatic, his grasp of thermodynamics might not be all that great. Specifically, without air or another medium, the only way we can get rid of heat is through radiation, using heat radiators.

An astronaut servicing a thermal control radiator on the International Space Station and a large KSP2 interstellar vessel with several radiators in its midsection. Credit: NASA

For KSP2, we want to pull several specific user stories out of this idea of heat transfer:

Parts on a vessel or a colony should be able to generate heat. These could include engines, drills, factories, and power generators.
Players should be able to make use of the three processes of heat transfer to cool vessels. That could be by using radiation with radiator parts in space, using the local atmosphere's convective abilities on a planet, or possibly using conduction to treat an asteroid as a heat sink.

These stories are not completely unfamiliar to veteran KSP1 players – drills and ISRU units generated heat that needed to be removed with radiators, and our three heat processes were simulated with great accuracy for focused vessels. However, we need to expand this to handle much higher fluxes, expand the range of parts that can generate heat, and most importantly, improve how all of this is communicated to the player.

[h5]Slightly Singed Landings[/h5]
When spacecraft reenter the atmosphere, they travel at such a high velocity that the compression of the air in front of the spacecraft creates extreme heating and is liable to damage or destroy the spacecraft. Special flight paths can be used to reduce the heating, and special materials are used to withstand extreme temperatures – often through ablation, where the material burns up slowly during reentry events, and in doing so carries away the heat.

The ESA spacecraft Jules Verne burning up in reentry. Credit: NASA

This is an integral and important part of spaceflight, so definitely something we want to represent in KSP2. We can collect a few more smaller user stories from this.

Travelling in atmospheres at high velocities should cause vessels to heat up
Players should be able to use occlusion to protect parts on vessels from reentry heating
Players should have access to specific parts that are more effective at mitigating heating than others

Reentry stories: you should really add a heat shield.

Again – this is a similar set of things to KSP1, but we go up in scale again. With more exoplanets, higher velocities and more varied types of atmospheres, we increase the scale of the challenge we need to consider.

[h5]Exoplanets? More Like Exothermic Planets![/h5]
Aside from reentry, we also need to think about environments. Traveling through the KSP2 universe will expose your Kerbals to everything from somewhat pedestrian to exotic environments, with situations like:

Close proximity to a star
Infernal, glacial, or "just right" atmospheres
Heated or molten ground
Icy or frozen planets

These are all things that, when sending probes or Kerbals to another planet, we would like the player to consider. We want to build interesting puzzles that require clever use of parts, innovative use of the environment, and clever mission design to solve. This means that all that heat transfer stuff from earlier should be influenced by environments. A cold planet might give you a useful bonus to run your mining drills. A lava planet should give an extra interesting colonial challenge.

We can extract another set of user stories from these environmental considerations:

Parts exposed to strong solar illumination should heat up
Immersion in atmospheres and oceans should heat up or cool down parts
Proximity or contact with surface features should heat up or cool down parts

Environmental stories. I'm a designer, not an artist!

These user stories are another core expansion of KSP1. In particular, the interaction between the part 'layer' and the environment 'layer' is going to have a much larger effect. More on this later.

[h5]Smaller, Simpler Problems[/h5]
But wait – there’s more!

Parts should have a variety of thermal parameters to make them easier or harder to use in select thermal situations (heat up at varying rates, explode at different points)
Parts exposed to engine exhaust jets should heat up

We can’t neglect the little stuff. When designing this system for interesting gameplay, we need to think about how we'll represent the range of thermal properties we want for parts. So parts should have some different heat tolerances, some different heat limits. Oh, and we want engine exhaust jets to generate heat. Can’t have you pointing a torch drive at a colony with no consequences!

[h5]Putting It Together[/h5]
Let's recap. From the above set of thermal user stories, we want to have a thermal system in KSP2 that will let us:

Create parts that generate and remove vast quantities of heat, via the three physical heat removal methods
Simulate atmospheric entry and mitigate it with heat shields
Model a vast set of environments from cold to hot and have those directly feed into the two previous bullets
Provide appropriate variation in thermal part behaviors

We can check these stories against the four design pillars of KSP2 to make sure they fit well. Our thermal stories are strongly focused towards Realistic space flight and Exploring new planets, but I have to give a shoutout to Building cool and unique rockets, because I can't resist a bad joke.

In addition, the thermal system needs to be predictable and plannable. More on that in a bit.

Consider a Spherical Cow in a Vacuum

Something I touched on earlier is that the KSP2 thermal system needs an appropriate level of simulation and detail. The level of detail we build into any system depends on the user stories. If the system is too detailed, we may build something that is difficult for a player to understand or too difficult for us to tune, creating undesirable edge cases and making it impossible to fill those user stories. If it is too simple, we might compromise our realistic spaceflight pillar and make things too easy for the advanced player.

I like the metaphor of a spherical cow in a vacuum – if we needed to analyze a cow for some reason, we could assume the cow was a sphere and assume it was in a vacuum. This is a fairly simple situation to analyze physically. This may however lead to an oversimplification of the problem. I can describe our search for a good thermal system as a search for the right geometric approximation and environmental context for our cow. Should it be cylindrical? Composed of several boxes? It probably shouldn’t model all the contours of a real cow in a grassy field because that would be very complex.

This cow is exchanging energy with its local environment!

The right thermal model for KSP2 has a good blend of realism, hits all our user stories, and is simple enough for players to understand and engage with. The right level of simplicity also allows us to build good intuitive tools to help players understand, in a nutshell, when their vessel or colony may overheat and how to solve it.

[h5]Determinism vs Simulation[/h5]
A common trade in simulation type games is the level of determinism versus simulation. The more simulation in a game, the more the game relies on lower-level rules to drive gameplay. A good example of this in our thermal context is a heat radiator. Determining how a radiator performs could be approached in a very simulation-centric fashion:

Define the usable area of the radiator
Determine the temperature of the radiator in response to various factors (each of which might also need to be simulated)
Use physical relationships such as the Stefan-Boltzmann law to model the amount of heat removed by the radiator

A radiator with a few of the parameters that might be needed to physically simulate it.

This simulation approach provides a high precision approximation of radiator heat rejection. However, it does require more design and computational work, as we need to figure out that temperature value, and we now create additional challenges of teaching the players about the radiator’s area, the radiator’s temperature, and how the two combined feed into the physical relationship. The latter is harder if the relationship is complex (here it is somewhat complex – heat radiation is proportional to temperature raised to the power of 4). In addition, we may create simulation-level inconsistencies – is this too detailed compared to other things that are simulated in the game? That’s a lot to unpack.

Alternatively, a simpler deterministic method could be used. We might just define the amount of heat removed by the radiator:

A radiator with a single deterministic flux value, informed by physical relationships.

This is evidently a lot less complex for a designer to manage and a player to understand. Often, we can mix the two approaches – in this example we could use physical relationships to guide what value we set. For example, we make the values for heat removal chosen related to the surface area of the part and derive them from ‘typical’ temperature relationships but never directly show this to the player. This has some advantages – for example decoupling gameplay from visuals, so we have more flexibility to work on these separately.

KSP1 erred on the side of the simulation in this trade. In the KSP1 thermal model, all vessel parts calculated their own energy exchanges (via convection, conduction, and radiation) with the environment as well as other parts, calculated internal sources of heat, tracked up to three different temperatures, and required considerable frowning at KSPedia to start to understand in a way that you could engage with the system.

The KSP1 simulation-focused thermal model, as shown by the in-game KSPedia.

For KSP2, we’ve made the decision to rely on what I’ll call a 'reality-informed deterministic model' with fewer moving parts. This model is still complex enough to hit all the user stories I’ve defined earlier so as not to compromise our commitment to reality, but will use a reduction in complexity to achieve much better player comprehension.

[h5]What's Changed[/h5]
Given the above, where are we modifying the simulations?

Simplifying temperature values: We want to avoid having a player interact with three different part temperatures when planning missions and playing the game. One is ideal.
Part high resolution thermodynamics: We don't have a lot of user stories that benefit from simulating conduction between parts or intrinsic simulated thermal emission. A lot of the time this reduces to equilibrium in KSP1, particularly at high time warp factors. In addition, if we want this simulation to apply to vessels in the background, we need to simplify things. It’s hard enough computing thermodynamics for 500 parts on a vessel – imagine if we wanted to crunch fancy thermodynamics on 50,000 parts on 100 vessels! This has to scale effectively and be performant.
Simplifying environmental interactions: Similar to the previous bullet, the level of interaction between the environment and a given part can be simplified. The ex-thermal physicist in me is pretty sad that we won’t be modeling the differences between longwave and shortwave radiative transfer in low Kerbin orbit - but I’ll get over it.

Shape of the Solution

Given all the above, we have designed a rad system. More puns, yeah.

KSP2’s thermal system will use a model based around managing heat fluxes – the amount of energy applied to something over some amount of time. Every process we want to model boils down to applying a heat flux to a part. This flux can be positive, causing a part to increase in temperature, or it can be negative, causing a decrease. Here is a sampling of fluxes we care about from our user stories:

Positive flux from things going on in a part, such as drilling, resource production, and powerful engine reactions
Negative flux from things going on in a part, like heat radiators and other heat sinks
Positive flux form stellar sources in sunlight
Positive or negative fluxes from warm or cold atmospheres, fluid bodies, or surfaces
Positive fluxes from high velocities in atmospheres (reentry)

Using this model, we can sum up all the fluxes affecting a part and communicate a single value to the player. If the sum of all fluxes is positive, the part heats up. If it is negative, the part cools down. In the absence of any fluxes, a part is stable. If the part’s temperature increases above its maximum, well, you get an explosion. I’ll illustrate with a few cases!

Thermal system in a reentry context.

Let’s look at a reentry case – a capsule with a heatshield travelling quickly into the atmosphere. Here, we have the presence of a Convection flux on both parts, as we have an atmosphere, and a Reentry flux, as we’re moving fast. The capsule is being occluded by the heatshield, and the heatshield is getting a positive flux. It is heating up and the capsule is not.

Thermal system in an orbital context, with a part.

Let’s look at another case of a 3-part spacecraft in orbit around Kerbin. In the first image, we have a idle spacecraft doing nothing. No fluxes. Nothing changes. In the second image, the engine is firing and generating a positive flux, so it is heating up. There are otherwise no fluxes. In the absence of anything else happening, the engine part will eventually explode.

A more complex ship makes for a more complex example.

Now, let’s add radiators to the mix. Here I haven’t labelled all the parts, but we have an ion drive spaceship with a nuclear reactor. In the first image, the radiators are not working and the reactor is on. The reactor part is heating up as it outputs 200 kW of heat flux and will eventually fail. In the second part, we’ve thankfully extended the radiators, and they’re each pulling 100 kW of heat flux from the reactor. Everything is balanced and nothing will explode.

A zoomed out example, with a colony!

As a last example, let’s make it complicated (I’ve simplified the doodle though). Here’s a colony in an atmosphere. The cooling tower is using 2 MW of heat flux, the reactor is making 2 MW, the factory is making 1 MW, and we’re using the water as a heat sink to dump 2 MW of flux. We have a nice little negative flux and our colony is happy because the engineers considered the environment. It’s a great story because it starts to show you where you might end up with advantages and disadvantages in terms of colony placement. If that water was lava, this would not be a good thermal situation 😉.

We can see how this system is plannable too. Although there are a lot of details, a player technically only needs to know what the net heat flux is on their whole vessel. No matter how many different parts are making heat, and no matter how the environment is configured, each part just contributes a single number to the situation. Add them all up – if it is positive, you have a problem. If it is zero or negative, you don’t.

The second part of this is how we define relevant fluxes. Instead of having a very complex environmental model where we specify every possible flux and simulate them for every possible source, KSP2 assumes that every part has some level of ability to self-regulate in an average thermal environment. Kerbals build tough!

Positive fluxes will only start to appear in well defined abnormal situations that correspond to our user stories and the puzzles we want players to solve – the user stories from before:

As your vessel approaches a star.
When your vessel reenters the atmosphere at high speeds in a fiery plume.
When a part is doing something that creates a large excess of heat. We're not considering small heat sources like cryocoolers and capsule life support systems.
When you point your fusion drive at your orbital colony.

We’ll apply negative fluxes at times where you might expect useful temperature drops in response to intuitive situations:

When your vessel is floating on an icy ocean or flying in a frigid atmosphere.
When a part is doing something that removes heat, like running a heat radiator.

Using these two concepts, we can work through all the user stories we defined in the previous sections and reduce the things we need to communicate to a player to effectively two values: the net heat flux on a part and the temperature of a part. The former is something you want to make as close to zero as possible, and the latter is something that tells you how close you are to critical failure.

A word on temperatures and maximums – there is a relationship between the temperature of the environment and the temperature of a part. Typically, you simply can’t bring a part into an environment it hasn’t been designed for – if you try to take a part with a low heat tolerance (let’s say it breaks at 500 K) into a 600 K atmosphere, you’re going to be in trouble regardless of the local heat fluxes. In this case, you’ll need to use creative solutions, like cargo bays.

[h5]Timewarp and Loading[/h5]
A core requirement we have on this system is for it to work well in timewarp and provide consistent behavior at high and low timewarp levels. Similarly, we have to consider how the system behaves on vessels that are unloaded. This work supports colonies and interstellar vessels.

For interstellar vessels, or anything else on a long burn, we expect players to want to timewarp at very high levels during long burns using engines that generate a lot of waste heat. In short, we need to make sure that when you do this, there is consistent, stable performance from our thermal system. If your vessel can take the heat at 1x, it should take it at 10,000,000x – this may seem obvious but leverages very specific requirements on the technical solution.

For colonies, we also need to handle these timewarp levels but also bring a focus to things working in the background. In KSP1, a number of systems only worked on vessels you had loaded – things didn’t always calculate in the background (especially thermal), because there wasn’t a lot of need for them. To fit our user stories we need to have a strong picture of the concepts we want to present to players. Again, consistency is a requirement. If I want to produce resources at a colony, or run delivery routes, I want this to be seamless regardless of whether I am actively observing the colony or not. Resources should be produced while I’m doing other things. This again leverages requirements on thermal mechanics: since most complex colony functions like resource processing are going to produce heat, we need to account for that heat in production calculations and be able to do the math when we’re not observing the colony.

Our flux-based system fits these requirements very well. In the absence of any additional flux, temperatures don’t change, so we can simplify a lot of these calculations or ignore them completely. When flux is involved, we’ve specifically designed a mathematically simple system. I like to think of this in terms of timewarp. If your vessel’s giant interstellar engine produces 100 MW of heat, and you have 1000 MW of radiators, we can make some solid assumptions:

As long as your radiators are running, your engine will never explode.
If your radiators are not running, your engine will more or less instantly explode at any medium-to-high timewarp level.

Even so, making sure things are stable and comprehensible is a large technical challenge. Comprehensible means we also need player tools to enable system interaction though, so let's talk a bit about planning.

[h5]Planning for Success[/h5]
I mentioned before that a key improvement we absolutely need for KSP2’s thermal mechanics is plannability. The system that I’ve outlined here gives us an appropriate level of detail to do that. Just like you can check your vessel’s thrust-to-weight ratio and delta-V, you will want to check your vessel or colony’s thermal performance.

We have a number of tools and concepts that we’re investigating as part of this effort, from UI tools to part-based approaches. We’re excited to iteratively work through the final solution through Early Access and consider the best of the community’s feedback to make flying vessels into Kerbol as exciting and predictably awful for your Kerbals as possible.

Development and Deployment

Because we're in early access with a specific roadmap, it doesn’t make sense for us to try to cram a system of this complexity into a single update, particularly with the huge rash of user stories we want to cater to. We’re going to deliver functionality iteratively where it is most appropriate in the roadmap. Here’s how things are looking right now, though we will refine this roadmap dynamically so heat problems appear at the right times.

By the time we get to our first roadmap update, for example, the user stories around reentry heating become very relevant, because the puzzle of returning science experiments to Kerbin is much more interesting if they can burn up when returning. That means that reentry heating takes the first priority of all of our user stories, and you can expect that to arrive before or with this update.

Similarly, dealing with radiators and parts that generate heat isn’t something that becomes exciting until we introduce actual heat generating parts, likely as we move towards the second roadmap update. These start to show up when we introduce more advanced propulsion systems and power sources like nuclear reactors. There’s a nuclear reactor in the game right now, but you’ll notice it has integrated radiators – a nice sidestep to the problem. Larger reactors will be separate and need their own radiators! This is where we’ll also need to bring in a first cut at some planning tools.

By the time we introduce some of our exoplanets and Kerbals go Interstellar, we want those environmental heat user stories to be fully fleshed out. That’s when we can expect to deliver advanced environment heat and even more planning tools to help your build cooler colonies and vessels. Overall – if we have a lava planet, that lava planet should be a thermally bad place to be.

I hope you’ve found this writeup to be informative and indicative of the direction and challenges KSP2 needs to deal with when implementing thermodynamics – I’ve enjoyed writing it.

Jul 21, 2023

SUMMER DREAMHACK Tournament

Star Conflict - Super Glix

Attention, pilots! We invite you to participate in the summer tournament from our friends — “SUMMER DREAMHACK”!

This time, the main feature of the tournament is that it will be held on ships of 4-6 ranks, which will not only allow new players to participate in team-oriented battles, but also allow experienced players to test their skills in limited conditions of low ranks.

Don’t forget about the reward, which this time will depend on the number of registered teams: the more, the better! Follow this link and register your team. We wish you good luck!

Tournament terms

Main tournament conditions

Tournament system: Double Elimination, lower bracket — Bo1 (up to one defeat), upper bracket — Bo3 (up to 2 defeats);
Tournament format: 5х5 (1 reserve);
Game modes: Beacon hunt, Beacon capture, Domination;
Self damage: enabled;
Friendly fire: enabled;
Available ships: ⁠premium + ES 4-6 ranks;
Available missiles: ES only;
Available modules, weapons and ammunition: ES and the list of allowed equipment;
Banned: Ghost, premium and craft ammunition.

Registration period:

Registration deadline: August 4, 18:00 UTC;
Stream of tournament bracket: August 4, 19:00 UTC.

Tournament matches period:

August 5, 15:00 UTC;
August 6, 15:00 UTC.

The tournament will be streamed live on this YouTube channel.

Registration

To register your team, you need to follow this link and send an application message using the following example:

Team name - Game nickname (captain) - Game nickname (captain’s assistant) - Game nickname - Game nickname - Game nickname Reserve: - Game nickname Preferred server — EU

Important:

By registering for the tournament, players agree to the General regulations of tournaments;
The application for registration is submitted as one message with the ability to edit it before the end of registration;
Changes of nicknames are forbidden until rewards are received;
Nicknames and the name of the team must be “readable” and understandable to the tournament team;
Visually similar nicknames and team names are forbidden.

Matchmaking

Tournament Administrator creates a fake lobby in the “Custom battle” mode in 20-25 minutes before the match starts, and then sends invitations to the captains of the teams participating in a particular round.

In the created lobby, team captains do the following steps:

Ban one map with a game mode in the right queue order;
Pick one map with a game mode in the right queue order;
Ban ships in order of priority.

After completing the steps above, the Tournament Administrator creates a lobby in the “Custom battle” mode with the map and mode picked by the captain, and invites teams.

The system described above works in parallel: during the ban-picks of the teams of the first tournament round, another Administrator already sends custom battle invitations to the teams of the second round, etc.

The minimum number of teams for the tournament is 8.

Bans and picks of maps and modes

Upper bracket:

The first team to ban maps and modes is the one placed higher in the bracket;
Captains ban maps with mode from the list below;
The team that is lower in the bracket chooses a map with a mode, spawn side and server for the first round, the team that is higher in the bracket choses the server for the second round;
The third map is played in case of a draw on the previous two, the spawn side is random, the RU server is in priority;
The server is set to EU if there is a choice between RU and US (NA).

Map pool:

The Source: Beacon capture;
Lava Spines: Beacon Hunt;
Dreadnought debris: Beacon Hunt;
PB-42: Domination;
Excavation site #6: Beacon Hunt.

Lower bracket:

Game mode: Domination;
Map: random from the list;
Spawn side: random;
The server is selected from teams preferences; RU server is in priority, but if there is a choice between RU and US (NA) then EU is set.

Map pool:

Northern mining station;
“Northstar” Crash Site;
“Pilgrim-11”.

It is forbidden to pick a map with a mode that the opponent has already picked.

Bans of ships

Each team can ban 2 ships for a single round;
The tournament Administration requests bans from the team captains by a message in the “Room” chat;
The first team to ban the ships is the one placed higher in the tournament bracket.

The order of ship bans:

Team A Captain — 1 ship
Team B Captain — 1 ship
Team A Captain — 1 ship
Team B Captain — 1 ship

Important:

The time to ban a ship is 1 minute. If after 1 minute there is no ban, the slot remains “empty”;
If a captain didn’t accept an invitation to ban ships and maps with modes, slots remain “empty’;
A team can ban no more than one Engineer;
It is forbidden to ban ships that are already banned or not available in the tournament.

Prize pool

Progressive prize pool system: the more teams, the higher the reward!
There is an ability to exchange the reward for the special Tournament points (the equivalent is in brackets).

1-st place:

Galactic Standards:

8/10/12/16 teams: 10000/12000/15000/18000

Ship (20 points):

1 pcs. (except Seeress, Confessor, Typhon, Nordstorm and Ellydium ships)

Equipment (20 points):

1 pcs. (except Seeress, Confessor and Ze’Ta unique equipment)

Premium license (10 points):

30 days

Pattern of choice (20 points):

Infinity
Inevitable
Ellydium Metal

Title of choice:

Overmind
Princess
Rock star
Ghost

2-nd place:

Galactic Standards:

8/10/12/16 teams: 8000/10000/13000/16000

Ship (20 points):

1 pcs. (except Seeress, Confessor, Typhon, Nordstorm and Ellidium ships)

Equipment (20 points):

1 pcs. (except Seeress, Confessor and Ze’Ta unique equipment)

Premium license (5 points):

7 days

Pattern of choice (20 points):

Inevitable
Ellydium Metal

Title of choice:

Princess
Rock star
Ghost

3-rd place:

Galactic Standards:

8/10/12/16 teams: 5000/7000/10000/13000

Ship (20 points):

1 pcs. (except Seeress, Confessor, Typhon, Nordstorm and Ellidium ships)

Premium license (5 points):

7 days

Pattern of choice (20 points):

Ocean
Ellydium Metal

Title of choice:

Rock star
Ghost

4-th place:

Galactic Standards:

8/10/12/16 teams: 3000/5000/8000/11000

Ship (10 points):

Craft 1-15 ranks — 1 pcs.
Premium 1-15 ranks — 1 pcs.

Premium license (1 point):

1 day

Monocrystalls:

500 pcs.

Pattern (15 points):

Ocean

Title:

Ghost

BONUS

For two rounds played by the team in the tournament, each player of the team receives:

Screened battery:

8/10/12/16 teams: 200 pcs./300 pcs./400 pcs./500 pcs.

Processing block:

8/10/12/16 teams: 200 pcs./300 pcs./400 pcs./500 pcs.

Insignia (PvE points):

8/10/12/16 teams: 500 pcs./700 pcs./800 pcs./1000 pcs.

Galactic Standards:

8/10/12/16 teams: 800/1000/1200/1500

For each round of the tournament bracket passed by the team, each player of the team receives:

Synthetic polycrystal:

8/10/12/16 teams: 5 pcs./10 pcs./12 pcs./15 pcs.

Galactic Standards:

8/10/12/16 teams:800/1000/1200/1500