The Development Process and Systems Explained

I have spent the last few weeks designing a web-game called Iso-Sim. The essential concept is simple, to have the player attempt to keep a Nuclear Reactor sustaining power generation while multiple components are failing. Of course, with any game design project, execution matters far more than the concept, and this project was ready to put itself on a guillotine and execute itself more often than not. From failed subsystems to confusion on difficulty balancing, this project required full time work to get ready in time, and I am excited to be able to share the development process of the game.

First, there are multiple types of reactors. For simplicity's sake, I chose two different types to analyze and design my game around. First were the Boiling Light-Water Reactors, which boil water in a reactor vessel to produce steam and spin a turbine. This is one of the most simple types of reactors, but it ended up being the most complex for me to design. The basic principle of the game revolves around pumping water through various machines that transfer heat to various places, but early on I decided that the heat would be moved through multiple fluid tanks that were interconnected. A mistake, to say the least.

Countless times fluid would magically disappear from the loop whilst shifting into other containers, and at times heat simply would not transfer. Headache after headache, I spent months attempting to perfect the Boiling Water Reactor. In the end, I decided that trying to shift fluids around was a pointless endeavor and reworked the design to use the Pressurized Light-Water Reactor design. This system pushes water over the reactor, which is kept under pressure to prevent it from turning into steam. This water is then pushed through a heat exchanger, which in turn boils another water loop that runs the turbine and cools through a Cooling Tower. The Tank System also includes pumps, which normally function at 500 Liters a second, but when the water heats to a certain temperature, the pumps begin to slow down. They can be fixed, but that requires constantly monitoring the pumps. Finally, the first overly complex system has been put into place.

Next was to expand upon the Reactor vessel itself. At the time, it was more or less a space heater and not a mess of neutrons and explosions. First was to design fuel rods that produced neutrons and would generate more based upon the generation of neutrons, making a chain reaction. This was simple enough, but a reactor doesn’t just have one fuel rod, and not all the neutrons are contained within the rods. I decided that they would contain 85% of the neutrons generated, and that 15% would be “exported”. Among those 15%, only 10% would actually reach the two other fuel rods, increasing the number of nuclear reactions within their fuel pellets. This is important, as two other components of this fuel rod assembly, the Control Rods and Neutron Shields, would act as absorbers of neutrons, removing them from the system. If you set them to absorb half of the neutrons, the reactor would become stable and not produce more or less heat. By releasing some of these neutrons to the abyss, that stable location would actually end up decreasing the total heat generated. In this system, there are three of the fuel rods, control rods, and shields. The control rods would absorb the neutrons within the individual rods, preventing further neutron generation, and the shields would prevent neutrons from reaching the other rods, preventing social reactions. The only parts left to make were a SCRAM button, the Safety Control Rod Axe Man, which would drop the control rods and shut down the reactor. The reason that someone would want to shut the Reactor down is the infamous problem of a Meltdown. When over 2000K, the Reactor will begin taking damage. Once it reaches 4000K, the entire Reactor will melt, causing the game to end. With a finished vessel, next was to design the Cooler.

In a real reactor, heat is removed through a series of Cooling Towers, which pump cold water from a basin into a condenser, turning the steam to water and thus forming more cold water to push back through the heat exchanger, cooling the reactor. This power plant is envisioned to exist inside a suburban basement, so a skyscraper is not expected to fit. What could fit, though, is a series of car radiators with fans blowing over the hot steam, condensing it to water. This is, of course, ridiculous, car radiators couldn’t bring heat down from 1500K steam, but this is a video game, and liberties can be made. There are ten fans, providing 5K of cooling each, resulting in 50K of maximum cooling capacity. This means that, as long as the reactor is kept at approximately 50K of heating, the thermal system will stay balanced. The main issue is that, over time, the fans will begin to fail. At first slowly, but as more fail the failure rate increases, which can only be fixed by increasing the number of fans. This will also reset the failure rate. Three complex and quick failing mechanisms are done, three more to go.

Next would be the Turbine. This is a much simpler machine, when the Turbine’s water loop is over 373K, steam at a ratio of (Water Heat)/37.3 will be pushed into the Turbine. This will begin to increase the speed of the Turbine, while Friction works against it to slow it down, eventually causing it to reach an equilibrium of Steam to Friction. If it were to spin too fast, the centrifugal forces will begin to tear it apart, causing damage to the rotor. Once broken, it is game over. The purpose of this spinning motion is to power an electrical Generator, which handles the Power and Score of the entire game. If sufficient steam is not supplied, it will simply flow through the Turbine, resulting in no power generation.

The final two machines are the Heat Exchanger and the Generator. The Heat Exchanger, as something with no moving parts, has no mechanical failure points. To force one in, I took the one metric that it keeps track of, the heat of it, and used that against it. Once the exchanger breaches 1000K, the efficiency of it drops slightly. This will just make the reactor more annoying to operate at higher temperatures. The Generator is similar, because the Turbine that powers it has failure points, it does not need to fail on its own. Instead, the Generator produces the power necessary to fix parts and activate the reactor. The power is ultimately very cheap, so it isn’t something that the player necessarily needs to worry about. On the other hand, the Score value it keeps must be maintained, otherwise it will drop. The score is determined by the power generation minus 100MW, meaning that if the player can not sustain at least 100MW of production, their score will decrease. The only time that this process ends is either when the Reactor or Turbine fail, or if the player were to SCRAM.

There is one last component, whose function is simply to alert the player to current issues. The ALARM will show warnings involving the reactors overheating, the pumps failing, or the turbines spinning apart. This exists largely because I don’t expect the player to read every single number to understand every single failure point, I only expect them to keep track of what they are looking at.

While this is the final product, there were concepts for other features early on. Namely, this game was supposed to be similar to the famous PaperClip Simulator, with an upgrade system that would be managed through the amount of power generated. I decided when transforming this into the Pressurized reactor it is now that I would scrap this idea to better focus on making the game functional. In its current state, the game is technically even playable on mobile devices! That doesn’t mean it is a great experience, but it is a possibility! I would love to revisit this game in the future and add countless new features to it, but for now I have made a functional simulator of a basement nuclear reactor, which is honestly more than I thought I would be able to do. I even had time to design a favicon for the browser tab!