Ship Systems: Thermal Management


Impeller Staff
Staff member
Hey Mercs,

Last post we talked a bit about our art process, if you have not seen it check it out, our Art Lead Remco made a hell of a post. I promised in the state of the game post to talk about some of the systems that make our ships fly and how they’re unique in the space combat genre. So for this week I decided to start with the one I am the most excited about: Thermal Control Systems. I can honestly say that my excitement over thermal systems is directly proportional to the work I had to put into it to make it work. I hope you got your fill of pictures last post, because we are ignoring them and going into a giant wall of text about dense subject matter. We even have gifs of text.

Armor Section Thermal Logging

  1. Blah blah blah game subject to change, nothing is final

  2. Starfighter Inc is a hard science fiction game. We attempt to be as scientifically accurate as we can, and make it fun. We admit that we occasionally take liberties and deviate from what science tells us. This only occurs when we deem it necessary for the game to be stronger, better optimized, or more fun. If you see a glaring science error it is most likely that we looked at the science and said, “Nope, that is super unfun or hard to do” and moved on.
**********DISCLAIMERS DONE**********

Now the Fun Stuff
Every module in our game has to worry about heat. Some have to worry a little extra. A select few break out in hives when we talk about it. Jokes aside heat is very important to manage in our game as it can do a lot of harm to your ship when managed improperly. Our chief science officer Zach El Hajj explained how the thermodynamics actually work and consulted on the how it might work in the game, because surprise surprise, I am a game designer, not a physicist. There is a lot of math involved. This required a lot of simplification, a game engine cannot run complex math simulations on a per frame basis and still have a smooth frame rate. We came up with a formula that we’re pretty happy with. This formula is the upper level formula that occurs every thermal update cycle where each piece has a lot more complex math going on. I will now go into what all of the pieces do so you can understand our thermal model a little better.

Q = Qgen + Qexchange + Qline + Qambient + Qweapon - Qmloss

Q is the variable that we use for heat, or energy, in our thermal system. When we were looking at the thermal system we needed to figure out what unit we would do our math in. Originally we did it in joules. We have a lot of things that calculate out in megajoules and some things in joules and everything in between. Because we started in joules and had such large fluctuations we ended up having insanely large or small numbers that were close to unusable in some cases. So during the Ships 2.0 push we looked at all of the math again and figured out that we could move up to kilojoules and lose no precision, but get all of our numbers in a much better state. This is what we are using now, and it makes a lot of our math much cleaner.

This part of the formula goes over how much heat the module generates when it is active. Simply put, every module has a variable called WasteHeat, this is how much heat it generates while in use. So when a laser is firing or a sensor is active it pulls more power and thus generates more heat. There is some other math we do here to make sure that we follow the flow of power and conserve energy but that is the gist of this part of the heat update cycle.

This part of the formula is our simplified version of conduction. Every module when initialized as the ship is spawned figures out what modules are close enough to it to conduct heat to and from and makes a list. Every cycle the module compares its current temperature to the temperature of the modules on that list. If any of those modules are colder than it is, the module will give some of its heat to the colder ones. If the module is colder than modules on it’s list, the module ignores them because it will get heat from those modules when they update. The amount given or taken is determined by all sorts of variables like material type, surface area, and distance. All of the heat given or taken is added together to get the Qexchange for that cycle.

The line in Qline refers to the heat lines that travel between modules on the ship to the nearest radiator to facilitate heat being transferred to external radiators. These are hyper-conductive lines designed to take heat away from important things to the radiators or heatsinks. They have a max amount of heat they can transfer in a cycle and we programmed them to only transfer heat 1 way, otherwise the radiators could give heat back to the ship, which is not a desired outcome. These lines are not modeled, thus they cannot be damaged in combat. We briefly considered it but decided that modeling them and keeping track of them would be nearly impossible in our game. We are clearly up for a challenge in getting the science right, but this was beyond what is reasonable for a game engine. We calculate all of the heat that leaves a module via a heat line for the Qline for that cycle.

Qambient only works if the module is flagged as “external”. This is a variable that we can set based on where that module is located on the ship. Basically, any module flagged as external can radiate heat into space during its update cycle. Recently on the state of the game post we had a comment asking about how we handled this and if we did it as if we were in space as opposed to the atmosphere. We very much did. We actually went the extra mile and made sure that every module in the game has a material associated with it. Every material has a lot of different values that we use to determine everything from heat transference to projectile penetration.

The most important one for Qambient is emissivity or how easily the material can transfer energy. For simplicity, we use spectral rather than specific emissivity. This allows us to assume it is roughly constant (rather than changing with temperature), but more importantly, lets us use emissivity for both radiative release and absorption. This is a drastic simplification that leaves out a lot of interesting phenomena - you could get materials that emit more than they absorb at a certain temperature and wavelength, or vice versa, which would mean you'd have to tailor your armor and radiators for specific laser wavelengths and temperature ranges.

However, doing so would require vast amounts of material data that is not readily available. Where you are located in space is also important because a direct line to the sun can mean a significant change in temperature which decreases how much energy can be radiated away from the ship. Since the game currently takes place around Saturn, 9-10 AU from the sun (average distance is 1.4 billion kilometers), this has a minimal effect, but as our missions move closer to the sun it will become much more important. All that being said, Qambient is the amount of energy transferred into space during the update cycle.

This one is pretty easy, all energy transferred to the module from a weapon firing on your ship, or exploding near it. Weapons will have their own post, so I will not go too deep into them here, but I will list potential sources: lasers, explosions (nuclear and non-nuclear), and kinetic impacts. Because weapon heat can come in at different times that do not line up with thermal cycles, they are cached until the next cycle and then dealt with.

I will discuss melting and sublimation of metals in space a little later, but this section occurs when the module loses heat to one of those processes. If the metal melts off the module then the heat in what melts off is also gone. This part of the formula calculates that.

Module Thermal Data Page on Dev MFD
All of this is calculated every thermal cycle. We add up the total energy transferred, positive or negative, and convert it into a temperature change. We decided to not make it run every frame, because it would make computers cry. We also broke it up into multiple sections so that the most intensive calculations did not all run at the same time. All of this allows us to use the complicated heat model along with everything else that is going on and maintain a smooth frame rate. We also made sure that we can track heat more effectively. We do not follow every joule as it moves through the ship, but we can look at every thermal cycle to make sure that we are getting the right numbers, this also means that we can give that info to the player. Another part of ships 2.0 includes a display update that allows us to give you that info and quickly understand what is happening to your ship. That is going to be its own dev blog later when we have all of the systems ironed out.

Thermal Effects
The effects of heat are different in space. For instance, without pressure nothing melts. It can vaporize, soften, sublimate, and with a little help from vapor pressure melt. Vaporization, out-gassing, happens all the time just in amounts that are so small that they are not worth worrying about. As a module heats up the amount of vaporized material increases. So we do a bit of that. The metal softens as it approaches and exceeds its melting temp. That changes how effective that material is at preventing projectile penetration, we also calculate that. We want players to work together in awesome ways and having someone soften the tough shell of a heavily armored enemy for the other person to nail that spot with a rail gun sounds pretty cool to us. Sublimation is where the metal goes from solid to gas, that just removes a bunch of mass, which is something we very much keep track of. So melting can occur in space, the out-gassing can cause a build up of gas around the object enough to cause some material to melt. We do a little bit of that as well.

Melting is one of those areas where we bend science a bit to make the game more fun. So the bending occurs where if your ship is accelerating it will rarely have enough pressure to allow for melting. We decided to allow it. Play testing showed that lasers were a lot of fun to use, but their effects were hard to really notice. This is less prominent in ships 2.0 because the HUD gives better feedback, but the problem persists. This stems from basically having to raise the temperature of a module to sublimation temperatures before any noticeable damage occurs, and since the hotter a module is the harder it is to raise the temperature, this occurred so infrequently that players never noticed when it did. It also meant that you would think everything is fine, and then your ship would explode. None of this is good gameplay and melting fixes these problems. If the module can melt then the effects of using a laser become more apparent. “That thing I was shooting lost X kg of mass from melting and that was all me”. Melting also bends science in that we do not calculate and simulate semi-fluid metals on a moving ship in 3D, because ... well, it’s really freaking hard and we assume that you don’t have access to NSA grade supercomputers to run the necessary computational fluid dynamics! We talked about it for a bit, but quickly decided it was not worth pursuing.

How it affects the player
Now that all of that is out of the way let’s talk about what this all means for the player. First of all: Heat Matters. It did not use to, but very much does now. Heat moves through a ship as organically as we can manage with a limited simulation. It is actually really cool to watch. We had to sit down and come up with how to score a “heat death” kill. There are ways, *cough cough* destroying the heat engine of a ship *cough*, that will cause a ship to melt from the inside out. But how do you score that? We are still ironing out the details, but basically all mass lost from melting caused by the ship melting itself goes to the player/s that destroyed the heat engine.

Simulated Reactor Shielding Failure While Output is at 100% (Time lapse x10)
Second: Players will have to make smart decisions when it comes to thermal management. This applies to more than just avoiding enemy lasers, that is an easy decision. When you are customizing your ship you need to look at your power consumption, because power = heat, and what weapons are all firing at a time. Players will need to understand that if they are firing 16 lasers and have their sensors active that they may be cooking their ship without any help from the enemy. We want every system in the game to enable players to make decisions about how they want to play. “Do I want the more efficient or more powerful laser?” “Can I afford to enable my CIWS lasers for protection while my ship is so hot?”

Armor Mesh Thermal Overlay

We really wanted to capture the essence of how thermal energy moves and reacts, and we think we did a pretty good job. We do not think that there are many other games that go to this level of detail, though if you know of any others besides Children of a Dead Earth please let us know so we can take a look at them. There are places where we had to pull back on the science for optimization and gameplay, but we always try to keep it to a minimum. This is one system of many on our ships that seek to replicate real life as closely as we can get within reason. We will examine all of them in future Dev Blogs. Those systems, how they interact, and how they affect players are what we believe sets us apart from the competition. Let us know what you think in the comments below.


New Member
so glad to hear you guys are sticking with the hard science... even though a few rules had to be "Bent" to allow "FUN"..... so few game developers have the intestinal fortitude to make a decision and then follow through with it.


Impeller Staff
Staff member
so glad to hear you guys are sticking with the hard science... even though a few rules had to be "Bent" to allow "FUN"..... so few game developers have the intestinal fortitude to make a decision and then follow through with it.
Thanks, It has been a source of pain for us in a lot of ways, but so worth it when it all comes together.