Captain of Industry News

Welcome everyone! Captain Filip here and I’m excited to bring you our last post on Update 1.

First of all, the release date for the Update 1 is set to the 30th of May, approximately 10am Pacific time (7pm in central Europe). If things go fine, it might hit the experimental branch on Steam a bit sooner.

To remind everyone, save files from the current version won't be compatible, but you will be able to keep playing the older version of the game using a Steam branch (ea-legacy).

We have updated the translation page with new strings from Update 1 and we would really appreciate it if folks from our translation community could help us to localize these. Thank you so much for helping us!

Now let’s dive into news about Update 1. And by the way, we have highlighted several exciting changes in our previous posts, so definitely take a look if you’ve missed them.


One major thing that was on our wishlist for a long time was to actually provide more visibility into unit storages. We already opened loose storages in previous updates. But unit storages were a bit more challenging. We have implemented a shelving system with stacked products and also added built-in signs on top of roofs. Finally, the storage units went through a significant face-lift.



Because we render just two sides of the storage (2n² items) and not the entire volume (n³ items), we saved on performance significantly while still being able to render non-trivial products. This also relies on instanced rendering, which we covered a few times before. However, we still have a way to go, such as adding LODs for some complex products.

The other thing we had to implement to make this happen is something we call product stacking. Belts, trucks, and storages all have the following rule: they provide 1 cubic meter to hold 3 stacked products. It is up to each product to decide how to utilize the space. And also, thanks to this, we can now render stacked products on belts. Below you can see different stacking strategies for different products.


And finally, we were also able to render unit products on trucks that now have flat beds instead of cargo containers. So you can quickly see what they are delivering to make sure they are not just driving with empty containers and slacking off.




This is a big topic, so fasten your seat belt. We have made lots of changes in power production.

[h2]Power rebalance[/h2]
Before we mention any power values, we need to cover one important change. We have inflated our electricity production and consumption by a factor of 4. So all power generators produce 4 times more, and all consumers consume 4 times more. We didn’t do this only because inflation is trendy these days (I wish this would be funny), but we had two main reasons: 1) We wanted more immersion as our power plants felt under-scaled. 2) We did not increase transport consumption by 4 but only by 2. This effectively halves transports’ power consumption. We couldn’t do this before as we were hitting the limit of 1 KW being our smallest unit.

[h2]Turbines rebalance[/h2]
In the real world, HP (high pressure) turbine is significantly smaller than LP (low pressure) turbine due to steam density that decreases with lower temperature. We didn't follow this principle, and on top of that, we required 2 HP turbines per 1 LP turbine. There wasn't really a need for that, we just thought that was cool. But if we have a choice to follow reality we try to do so. So we redesigned the turbines. HP turbines are 1 tile shorter and narrower. We also restored elevated pipe connectors as we had in old versions of the game, because of reasons we will cover later. And changed the HP to LP ratio to 1:1.



Besides that, we felt that turbines were already quite space-demanding. So we made steam 50% more energy dense (and more costly to make) so that turbines & mech. power generators can now have +50% output.

[h2]Super pressure turbine[/h2]
Another thing we are adding is a super pressure turbine. This new beast goes right in front of the HP turbine and consumes Superheated steam and returns HP steam. Superheated steam gets produced in one of our new nuclear reactors, so this is an end-game tech. Many of you will starve your colony to death before you even get there :)



[h2]Thermal storage[/h2]
We had lots of requests to store steam in storage tanks, and we always said no :) One of the reasons was that we wanted to do this properly even though that’s more work for us. So we are adding a new building – thermal storage. It contains molten salt, which gets heated by incoming steam which gets discharged in the form of depleted steam. Its internal heat can then be used to convert incoming water back into steam. So it is essentially a thermal battery. We didn’t introduce continuous heat loss but we added a one-time conversion loss when charging heat. It also comes with a cool animation of the hot/cold tanks moving up/down based on the heat stored.



[h2]Surplus consumer / producer[/h2]
When observing some of the backup solutions players created, we noticed that there is an important concept we were missing, which is something we call a surplus consumer / producer system. It allows marking an electricity consumer as a “surplus consumer”. At that point, that consumer will only consume power from producers that are marked as “surplus producers” which typically are solar panels (by default). This means that you can, for instance, synthesize hydrogen in cases you have an abundance of solar power. Also, surplus consumers do not complain about low power.



[h2]Large diesel generator[/h2]
Having an array of diesel generators as backup is a good idea. But with energy demands continuously growing, the starting generator was not enough. So we are adding a large generator that produces 6 times more power and provides you with savings on maintenance, workforce, the space occupied, plus an option to filter its exhaust.





With electricity changes covered, we can now dive into new nuclear energy chains. We cover nuclear in a separate section because it is beefy.

When working on this we have spent several days buried in presentations, articles, and lectures on nuclear energy, fast breeder reactors, MOX reactors, and waste reprocessing. What we came up with is based on real science, but it is simplified in order to be playable. Some of these technologies were tested in lab environments but never used on a commercial level. So we are a little bit improvising here.

[h2]Nuclear reactor T1[/h2]
We have a reactor in the game already, and we didn’t change much except the entire model got reworked :) But the recipe stayed the same. It still converts uranium fuel to spent fuel. The reactor used to generate 15 MW, but we bumped up steam density by 50% (mentioned in the previous chapter), which raised it to 22.5MW and then we inflated power production 4 times, so it now generates 90 MW.



[h2]Nuclear reactor T2[/h2]
After some time, you will be able to upgrade to a new reactor - Nuclear reactor II. Besides burning regular fuel it can also burn MOX fuel. It also provides an extra power step which allows it to produce +33% more steam. So this plant can provide you with steam worth 120 MW of electricity. It also comes with automated heat regulation if supplied with computing. However, safety cooling is still strongly recommended.



You might be wondering how to obtain MOX fuel. MOX fuel is a mix of plutonium and uranium. And to obtain plutonium, we added another machine, the nuclear reprocessing facility, which is able to separate plutonium out of spent fuel.



It also extracts reprocessed uranium, which can go back to enrichment, and also fission product which goes back to spent fuel storage. Fission product has a nice benefit; which is that after 120 years, it decays and turns into retired waste. The retired waste can then be sent to a shredder and get converted into recyclables.



However, burning MOX fuel creates Spent MOX fuel which can’t decay on its own as it’s nasty. For that, you will need the next tier of the reactor. So the TL;DR is that this new MOX reactor allows you to cut down significantly on the amount of waste you need to store long-term.

[h2]Fast breeder reactor[/h2]
The final and most advanced reactor you get is a new reactor we call a fast breeder reactor. It is, however, vastly different compared to its early brothers. A fast breeder reactor is the most advanced reactor in the game. In the research, it is actually behind the space rocket.



The fast breeder reactor contains molten fuel dissolved in molten salt so no control rods are involved. It also operates at higher temperatures which means it generates Super-pressure steam (SP) instead of HP steam. SP steam requires an SP turbine, but a single SP turbine generates the same mechanical power as HP and LP turbines combined. So it shouldn’t come as a surprise that this reactor can output steam worth 240 MW of power. Rumors say that this might be enough to power a couple of arc furnaces.

Now comes the complex bit, which is how this reactor fits into the entire uranium chain. Initially, you need to fuel it with highly enriched fuel, and there are several ways to get it.





The reactor consists of two parts – a core and a blanket. The core contains highly enriched fuel which produces heat for your turbines, but it also bombards the surrounding blanket of fuel to enrich it. The process goes as follows:

Core fuel => Spent core fuel
Blanket fuel => Enriched blanket fuel

What you also need is to build a nuclear reprocessing plant to extract fission products out of the spent core fuel and send the good fuel back to the FBR. You also need to build a chemical plant to extract the enriched fuel out of the enriched blanket fuel and refill it with more fuel. So basically, you have FBR that runs the reaction and enriches its own fuel and then surrounding facilities that continuously filter the good and bad stuff and act as a “kidney”.



This means that once this is running you can skip the enrichment phase. And secondly, you can burn & use some of the nasty stuff such as Spent MOX and Plutonium.

[h2]Depleted uranium[/h2]
This all comes with another addition which is depleted uranium. Before Update 1, the enrichment plant provides enriched uranium, and we conveniently ignored the fact that there are tons of depleted uranium that comes with it. Now it’s there. The main benefit is that it provides more motivation to create advanced reactors. Because depleted uranium can be mixed into MOX fuel. But what is even better is that it can be used in an FBR reactor to be enriched into usable fuel. We have also added the option to dump depleted uranium onto the terrain (this also happens in real life!).



[h2]Another benefit of SP steam[/h2]
Another benefit of superheated steam is that we added a new recipe that allows the creation of hydrogen from water more cheaply than via an electrolyzer. In practice, this is called the Sulfur-Iodine cycle.



And this is the new nuclear chain! It took 5 days after the launch of Captain of Industry for someone to launch a rocket, we are now wondering how many days will it take before someone has a functional FBR. Let us know when you do!



What bothered us for some time was that storage units were outperforming transports on efficiency and throughput.

To close that gap, we have reduced the throughput of storage units, but more importantly, anytime a loose or unit storage accepts products via ports, it also consumes power in the same way as belts do. But we actually made this a bit more fine-grained for each game difficulty.

Sailor (easy): Belts & storage units will not consume any power.

Captain (balanced): Belts & storage units consume power with the highest priority, but if there is no power, they still work (this was always the case for belts).

Admiral (hard): Belts & storage units will always consume power and will not work without it. But you can change the consumption priorities.

Another change is that if storages get chained together, they will now automatically unregister from truck deliveries where needed. This improves logistics performance and makes things a bit more obvious.



Speaking of transports, in the previous post we sneaked in a screenshot of one massive change: vertical pipes! :) It took some time for folks on Discord to notice it, but they did! Congratulations! Anyway, now it is official. Old blueprints will still work should your heart desire a good vintage curly pipe.



This was actually not a simple change because our transport construction and rendering system relied on non-verticality. Pipes with 90 degree corners are also tricky to texture as the “top” of the texture can move to a different side after a sequence of 90-degree turns. We have solved this by cutting such transports to multiple segments and connecting them via a ring that allows texture to snap back to the correct orientation.

We have also leveraged instanced rendering. To make it even more effective, similar transport pieces were grouped and rendered together by applying various transformations. This resulted in transport rendering being approx. 3 times faster. Huge thanks to Captain Jeremy for making this happen!



[h2]Electrolyzers[/h2]
Our electrolyzer was one of the first models we had, and it was asking for a revamp as it was looking a bit sci-fi. So we did that, and whilst at it, we also introduced tier II.



[h2]Mixers[/h2]
Our Mixer couldn't keep up with large factories, so we added tier II. And since we wanted to have it as an in-place upgrade we revamped the original model as well.



[h2]Large crusher[/h2]
To make crushing ores a bit more exciting we have added a large crusher. It takes approximately 4 times more resources but comes with a 6 times larger throughput. This should help with getting all that sand and crushed ores!



[h2]Captain office[/h2]
Our current office is a bit of a palace that can’t come early and is costly, so we relabeled it as Captain Office II. Which made space for a new Captain office I, which is a bit more humble. This office comes much earlier in the game and is cheaper. So it provides blueprints earlier than before. Captain Office II is still needed to run any edicts that are tier 2+ and also provides a passive boost on quick trading volumes.





[h2]Sand[/h2]
Silicon production now requires sand instead of quartz. Sand is no longer made by crushing rock but by crushing quartz instead. This simplifies things a bit and removes the initial dependency of Electronics 2 on quartz mines.

[h2]Gold[/h2]
Gold ore now yields half the gold and comes with increased crushing costs. You might need the large crusher here.

[h2]Changes in computing, maintenance III, research[/h2]
There was plenty of feedback on microchip production being tricky by having a dependency on computing. The biggest issue here is that maintenance III requires microchips to provide computing which is required to produce microchips. To break this loop and make initial production less stressful, we added a new type of building - a Mainframe computer.



The mainframe computer has the advantage that it does not require microchips to provide computing. However, it has super high power demands.

Another issue we have been noticing is that players got trapped in robotic assemblers being expensive on maintenance, especially maintenance III. This was initially the intention as these assemblers were supposed to produce end-game stuff and push the demands up, but it didn't combine well with the fact that they also provide upgraded recipes, so they turned out to be a trap. We made several changes to balance this besides reducing maintenance costs for the robotic assemblers.

The first one is that we made Electronics II cheaper to make. This makes Electronics III transitively cheaper as well. We also densified data-centers. So a single server rack now costs 40 servers instead of 20 but provides twice more computing. But we kept the same maintenance III requirements for the entire datacenter, which reduced maintenance costs for computing. Before, just maintaining a datacenter required 1/4th of its computing, now it is 1/8th.

All these changes allowed us to reshuffle the research tree. Electronics II now comes earlier because it does not require quartz and is cheaper to make. So Research lab equipment III now requires Electronics II. Construction parts IV also come earlier together with Maintenance II, and both are now leveraged sooner. Also an added benefit is that solar panels now come earlier. This should reduce the steepness of going into Electronics III as things are now spread a bit more.



[h2]Desalination balancing[/h2]
Reduced desalination cost by 15%.
Almost doubled the throughput of a thermal desalination plant

[h2]Contracts[/h2]
Some contracts were removed, some added and some rebalanced, either due to changes in recipe costs or just to balance them out. They say a picture is worth a thousand words, so here is a screenshot of the new contracts screen.



[h2]Recycling plant changes[/h2]
The recycling plant used to come with dedicated output ports for each recycled output. This was way too limiting if we or modders need to add new recyclable outputs. So we changed the plant to have just a single output port. This means that the final sorting has to be done via sorters - they are finally useful! :)





Besides features work, we have also focused on several quality-of-life improvements.

[h2]Combined designation[/h2]
We are introducing a new type of designation, we call it leveling designation. It facilitates mining and dumping at the same time, based on the current state of the surface. This should make building ramps and flattening terrain easier than before.



This designation is still considered to be experimental. We locked it behind a research node, and we will be evaluating how well it does and if there is a chance it could even replace the standalone mining and dumping designations.

[h2]Vehicle replacement / upgrade[/h2]
You will be able to replace a vehicle with any other vehicle directly from its UI. This should streamline your vehicle fleet upgrades. Once the replacement is requested and built in a nearby vehicle depot, the vehicle will go there to be replaced.



[h2]Blueprints improvements[/h2]
Blueprints now automatically downgrade their locked items on placement. This is mainly done to allow building blueprints with higher tiers of transports. This is just a best effort feature, we can’t always guarantee that each downgrade makes sense. Also, each locked blueprint now also lists what items are missing / needed to be researched.

[h2]New dashboards[/h2]
We are also adding new dashboards that provide a breakdown of the consumption and production of electricity, computing, workers, and maintenance.




[h2]Research locks[/h2]
We also added a feature that allows us to lock research nodes with production goals. For instance, you can’t build advanced reactors until you get experience with the basic ones.



[h2]Vehicle jobs scheduling[/h2]
Another change we made is in how we schedule cargo delivery jobs for vehicles. What we used to do is that when a vehicle got free it asked for a job. At that point, we would search through all the buffers to find a job. This was completely rewritten so that now a vehicle just registers for a new job and waits for a result. This way, we can group requests and resolve them at once.

There are two significant benefits of this new system. The first one is performance. The theoretical limit of how many jobs we can schedule increased a lot because the duration required to find a job for one truck or several of them is almost the same. The reason is that the most expensive part is to go through all the buffers in the game and build the caches, the final search is relatively cheap. And the second most visible benefit is that if there are multiple trucks that are idle we always assign a job to the truck that is the closest.



As mentioned in our previous posts, we also worked hard on graphical improvements.

[h2]Dynamic skybox & fog[/h2]
We implemented a dynamic skybox, so there are now clouds that appear and disappear based on the weather. We also added fog which is also dynamically affected by the weather. And since our horizon looks much better now, and rendering performance is relatively good overall, we have allowed even steeper camera tilt.



[h2]Forward rendering[/h2]
As we promised several posts ago, we have ditched deferred rendering. Unity’s implementation just did not cut it, and the forward rendering looks absolutely great. It comes with MSAA anti-aliasing which you can control from settings.



[h2]Loose Product Textures
[/h2]We’ve also revisited the textures for various loose products.



[h2]Terrain[/h2]
Terrain has improved a lot. First, we have created new textures for nearly all terrain materials and they look gorgeous! The terrain now uses tri-planar rendering, making textures on steep walls nice and crisp (see CD#35 for more details).

Next, you will notice new beautiful trees that come in two variants: fir and spruce. They not only look better but also use less triangles, our artist Mira really outdid themselves on these! This allowed us to place more trees on maps for more realistic forest coverage without hurting performance.

Finally, the terrain is covered with new grass, four kinds of flowers (can you recognize them?), many rocks, and other details. Take a look yourself!




Update 1 will also arrive with extra 30 minutes of new music! The soundtrack DLC on Steam will be automatically updated as well.


This is all we have for you, and we can’t wait to see you all having fun with the new update!

Welcome everyone! I am Captain Marek and in today’s Captain’s diary entry we have loads of new information about our upcoming Update 1! First, I will tell you all about our new terrain and ocean. Then, Captain Filip will follow with some new features and improvements.

Just to remind everyone, this post covers changes that are not live yet and will come in the Update 1 which is scheduled to arrive around the end of May.


As COI evolves over time, technical requirements are changing. Our terrain was originally designed to be dynamically expanding over time. New chunks of land could be unlocked as players explored new territories. However, as you might know, such a feature was never available in the game since we have decided that having all land visible and accessible from the very beginning is better and more exciting. If you ever wondered why the terrain boundary has a non-rectangular shape, this is the legacy reason for it.
Visualization of terrain chunks in the old terrain representation. Notice that the map boundary is not rectangular.

The issue is that a dynamically expanding terrain tech comes with a lot of code complexity underneath. For example, all terrain data must be stored in chunks and accessing terrain data needs to go through a chunk lookup. So many game code and mechanics depend on the terrain and need to be dealing with this complexity. This was causing not only performance issues but also complex code that is harder to optimize.

As we started to work on the map editor we realized that we need to decide whether the complex terrain tech is something that we will just keep as is, or decide to improve it. This was a “now or never” moment because the more terrain is used the less plausible a representation change would be, especially when we talk about a terrain editor that is tightly connected to the terrain. After a thorough investigation of our options, we decided to go ahead with the revamp of the terrain representation as a long-term investment in the future and longevity of COI. From the fantastic results we got, now it sounds like we made the right decision!

[h2]New terrain representation[/h2]
Before describing the new representation, let’s take a look at how the old terrain worked. In order to query a terrain property (like a height), following steps have to be performed:

1. Look up a terrain chunk corresponding to the [x, y] coordinate (hashtable lookup).
   
2. Verify that a chunk exists, if not, report failure.
   
3. Compute a local data index from the original coordinate.
   
4. Verify that the local index is valid, if not, report failure.
   
5. Return requested value from an array at the local index.
   

This might not sound like a lot, but the devil is in the details. First, there are many operations needed to be performed for the chunk lookup and coordinate conversion. Second, there are many hops to different memory locations. Let me briefly explain why this is a problem.

You might know that a CPU has on-chip caches to speedup memory access. If a requested memory address is not in a cache, the CPU has to wait for the data to arrive from the main memory (RAM), which could take anywhere from 20-200 CPU cycles. This means that accessing less distinct places in memory can speed up the code significantly. In our example, there were around 10-20 different memory locations accessed.

So what is the new terrain representation and how does it solve these issues? Frankly, it’s quite simple. We just made the terrain a rectangle and each terrain property is stored consecutively in one giant array. For example, if a terrain is 200 x 300 tiles, the height data is stored in an array of 60000 elements. The lookup is quite simple:

1. Compute an index from the [x, y] coordinate (two arithmetic operations).
   
2. Verify that the index is valid, if not, report failure.
   
3. Return requested value from an array at the index.
   

This optimization resulted in 2-10x faster terrain access! You may also ask, how many memory locations are accessed using the new approach? Two! The length of the array (for index verification) and the value itself. A huge improvement and the access code has just three lines! This might sound like an obvious way to store terrain data but keep in mind that this approach does not work if the terrain is not a rectangle and can expand in any direction.

Another benefit of the new rectangular terrain is that there are no surprising boundaries of a map that players need to worry about.

[h2]Terrain materials improvements[/h2]
We haven’t changed only the terrain data representation. Another significant change is how terrain materials are represented. Before, each tile on the terrain had two states: normal and disrupted. For example, dirt was a disrupted state of grass. Excavators left disrupted rock and ores after mining.
Example of disrupted grass into dirt and iron ore into smaller rocks in a mine.

The first issue was that the disrupted state was just a visual distinction, the two states had the same properties such as collapse angles. This for example meant that a mined rock could be dumped as steep of a pile as the mountain it came from. Or that too steep mountains started collapsing all over the place after the first dig of an excavator.

The second issue was that the disrupted state was not set per material layer but per entire tile, affecting all material layers. This meant that if for example a dirt fell on a tile with a rock and then fell elsewhere, the uncovered rock below was suddenly disrupted as well. This was especially an issue when materials were falling down from cliffs, leaving disrupted “trails”.
A trail of disrupted rock left on a mountain side caused by dirt falling over it.

To improve on this, normal and disrupted materials are now represented as separate layers. This solved all of the above problems: normal and disrupted materials can have different parameters, falling material won't leave “disrupted trails”. And as a bonus, transitions between disrupted and non-disrupted states can be non-symmetrical. For example, compost now turns into lush grass, but lush grass turns into normal dirt when vehicles go over it.

The disadvantage of the new approach is that the number of layers on terrain is higher and operations are more complex. For example, a vehicle going over grass was previously just incrementing the disruption amount on each tile it touched while traveling. Now it has to do more complex layers conversions.

Fortunately, thanks to the new terrain representation and many other optimizations, the new more complex system is even faster than the old one! A test was performed where 127 vehicles drove over grass, disrupting it into dirt in the process. Simulation time per tick went from 1.4 ms to 0.8 ms, nearly 2x faster! Sand falling from the truck no longer disrupts the rock wall underneath! You can also see the new rock texture!

[h2]Terrain physics improvements[/h2]
Apart from speedup thanks to the terrain representation, we have improved terrain physics to fall in a more natural way. Before, terrain was only allowed to fall in 4 directions aligned with the X and Y axes. This meant that terrain was preferably forming pyramid shapes when collapsing. This did not look great especially when the new stacker was dumping material.

We have improved this to use an 8-direction neighborhood when simulating terrain collapse. This is more expensive but produces much more natural circular patterns as you would expect.

Regarding performance, this is another success story. Despite more complex computations due to the 8-way neighborhood, terrain physics got 4x faster! To prevent lags, we had a limit of a maximum of 250 processed tiles per simulation tick so we increased it 4x to 1000 tiles per tick so that the maximum per-tick time budget is the same. This made large landslides so much more exciting!
A comparison between old 4-way (left) and new 8-way (right) terrain physics. Notice that the old pile has a pyramid shape.

Another improvement to terrain physics is a special treatment for thin material layers. We noticed that materials that collapse easily (such as sand or waste) slide down steep slopes way too easily, like on a water slide. This didn’t look realistic. We have improved this by biasing the layer collapse angle based on its thickness.
A trash being dumped over a cliff. Notice that on the old version it was sliding all the way down (left) but in the new version (right) a small amount is scattered on the cliff wall.

[h2]Terrain rendering optimizations[/h2]
Terrain rendering was also significantly optimized not only yielding more FPS but also saving a lot of memory! Terrain is still rendered in chunks but thanks to the fixed terrain size we were able to do a lot more optimizations.

The biggest optimization was to completely eliminate meshes representing the terrain surface. Before, each chunk had a mesh with a grid of triangles. The issue is that a mesh requires a lot of memory and is expensive to update. Instead of meshes, we save all terrain properties such as height or material type to one large texture and all the fancy vertex displacement and coloring is done on GPU.

We also implemented dynamic level of details (LOD) so that further terrain is rendered using lower resolution meshes.
Comparison of rendered terrain chunks before (left) and after LOD (right) optimization. Chunks further away from the camera are larger but have the same amount of vertices, reducing load on the GPU that has to process less vertices in total.

Finally, we use GPU instancing (discussed in CD#15, CD#29. and CD#31) so that the entire terrain including all LOD variants is rendered in a single draw-call, eliminating most of the GPU communication overhead.

To test the performance we created a gigantic map as a grid of 5 x 5 New Haven maps next to each other (area of approx 50 million tiles, or 200 km^2, or 124 mi^2).

The results speak for themselves: 9x faster rendering and 4x less memory consumed (8x less GPU dedicated memory).


[h2]New terrain size limits[/h2]
Until now the primary limitation of the terrain size was performance. As we saw in the previous benchmark, maps beyond a few million tiles squared were unplayable. Now that the performance is longer the limiting factor, how large can maps be?

Turns out that Unity won’t allow us to allocate larger arrays than 2 GB of data. This means that we had to put a cap on the maximum terrain area of 65 million tiles, that’s 262 km^2 or 163 mi^2, roughly the size of the Cayman Islands. For comparison, our largest map is currently the Insula Mortis with an area of nearly 4 million tiles.

We won’t be releasing such large maps yet since there might be other issues like pathfinding, but the potential is there!

Given the max terrain size, we have done another interesting optimization. We have reduced the size of all integer coordinates from 4 bytes to 2 bytes. This saves 50% of memory for all coordinates in memory, neat!
Array of 25 New havens used for terrain rendering performance testing. This map has an area of approximately 50 million tiles, or 200 km^2, or 124 mi^2.

[h2]Improved terrain visuals[/h2]
We are also working on a new terrain look and feel, including new textures and various props. This is still in progress so we cannot show you the final result but we have some cool things to show you.

As mentioned in CD#32, we have improved terrain rendering to handle 255 different textures, up from just 24! That’s a huge improvement and allows us to have unique textures for all dumpable products and still leave plenty of room for more new materials in the future as well as for mods.

We have also implemented what’s called “triplanar texture mapping”, significantly improving the quality of textures on the terrain, reducing stretched textures on steeper slopes. As the name suggests, this technique maps the textures from 3 different directions, depending on the normal of the terrain.
Comparison of old “top-down” texture mapping and new “triplanar” texture mapping on a limestone mountain.

We are also considering having “weathered” texture variants for rocks to distinguish between freshly mined surfaces and old weathered rock faces.

[h2]Terrain revamp conclusion[/h2]
This terrain representation change and all the improvements and optimizations were a massive undertaking. We could not possibly cover all the details and improvements that went into it but the results speak for themselves.

Unfortunately, due to the time investment that went into this, we have to postpone the terrain editor for the Update 2. We know that many of you were eagerly waiting for the terrain editor and it is still coming, but unfortunately not just yet. Sorry!


Ocean representation was improved in a similar manner to the terrain and it is now much more efficient to simulate and render, including LODs based on the camera distance.

However, the most exciting news is that we have also completely rewritten the ocean surface waves that are now simulated in realtime! Ocean is now composed of thousands of sine waves, making it look much more realistic and the waves even change based on the weather.

I won’t go too much into details of how this was done, but just to mention some key points, we use inverse fast-fourier transform (IFFT) to efficiently compute a sum of thousands of sine waves. This is done using compute shaders on the GPU. We compute 3D displacement as well as a jacobian (derivatives with respect to x, y, z) and then mix two scales of the waves into one ocean surface. If you’d like to learn more about how it’s done, here is a fantastic video called Ocean waves simulation with Fast Fourier transform detailing the motivations and all the steps.

Here are short animated gifs showing old and new ocean surface. Can you tell the difference? :)
Old ocean (any weather).

New ocean during sunny weather.

New ocean during heavy rain.


In the new version, there will be a pollution penalty for dumping waste on terrain. Freshly dumped waste will turn into “settled waste” over a few game years and during that process, it will emit pollution. This is possible due to the changes in the terrain that we mentioned above, as we are now able to track waste conversion without any performance penalty.

Another change we are doing for Update 1 is that we will no longer allow building structures directly on waste to provide you with better immersion. Also, it was heartbreaking having to watch some of you building settlements on top of a landfill :)

However, we are obsessed with waste, so we couldn’t just stop there. We know that solid burners were not the most elegant solution to the waste problem. And so we are introducing an incineration plant. The incineration plant burns large volumes of waste and produces steam to run your power plant. That’s a win-win as long as you are so heartless about burning someone’s thrown-away teddy bear for power.


You might say, that waste got enough attention and we should move to another topic. Not yet. We are adding a waste compactor for better compression and transportation. None of you ever asked for it, but we still delivered and that’s called exceeding expectations all the way! The compactor will be able to also press recyclables and individual scrap products.


But for action, there must be a reaction. And for a compactor, there must be a shredder. That’s not something we made up, these are laws of physics. And so due to that, we had to add a shredder as well. The shredder is used to shred stuff that the compactor compacted. And you might think we are going crazy at this point, but the shredder will play its role in providing some new recipes. Such as the production of wood chips or handling late-game retired radioactive waste. That will be covered in our next blog post, in which we dive more into changes in power production.



Some of you might remember that mining trucks were often driving with low volumes of cargo. This was especially noticeable for large haul trucks. This was something that puzzled us for some time. Initially, we tried a few tricks, such as that trucks will hang around the excavators until some excavator needs them again. That was usable only if there were plenty of trucks which was usually not the case. It also introduced an entirely new set of issues, such as that trucks were hanging around for too long.

We ultimately arrived at a solution known as mixed cargo, which involves excavators loading multiple products simultaneously, resulting in faster mining. Mining trucks have also been modified to carry multiple products at once. As a result, we have observed a significant increase in the speed of mining operations. However, it's important to note that mixed cargo is currently only supported during the mining process.


You may be curious about how we handle mixed cargo once it's in the trucks. We had two options: introduce a sorting facility or have the trucks sort the cargo themselves by delivering it to individual silos. While some may prefer the immersive experience of a sorting facility, we ultimately decided to have the trucks handle the sorting automatically. This is because introducing a new sorting facility concept in the early game could overwhelm new players. Another option was to enable mixed mining later on through a toggle, but that seemed needlessly complex. Of course, it's also possible that we're just saying all of this to cover up the fact that we spent our entire budget on the waste compactor!



One of the big features many of you are looking forward to is tree planting. We had this idea planted in our head and roadmap for some time but it really required some planning and preparations before we could make it happen.

We have put a lot of effort into making sure that planting & harvesting works in an automated fashion. And we also wanted to make sure we can keep using our tree harvester. It all came together and we are introducing a forestry tower. The forestry tower allows you to place and manage planting designations. We are adding a new vehicle - a tree planter that will plant tree saplings across designations managed by your forestry towers. Once trees grow enough, an assigned tree harvester will automatically chop them down. The tree planter will then plant new trees at free spots and the cycle repeats again. You can also select at what percentage of growth you want the trees to be cut. Tree saplings can be obtained by growing them on your regular farm.


Trees can be also placed manually to provide you with decoration options.


We have also removed the lumber mill from the world map that served as an infinite source of wood. As we mentioned initially, it was just a temporary remedy until we provide trees planting feature.

Another change related to trees is that we have solved the issue of trees traveling up & down with terrain becoming inaccessible. Now they just fall down and disappear.


Also, to compensate for the fact that you now need to grow saplings and block some area for forests, we made all the food in the game to be +20% more nutritious, meaning that you need 20% less farm space.

Also, we are adding a new recipe to shred wood into wood chips which can go directly to a boiler or into paper production, where paper will go to research.


We hope that some of the stuff arriving in the Update 1 caught your eye! Please keep in mind that this is just a smaller portion of the changes that are coming in the Update 1. We will try to squeeze in one more blog post before we go live with the update.

* Captain of Industry is now available on GeForce NOW.
* Fixed transport pillars placement that sometimes blocked other buildings during copy/paste and blueprint build operations.

Hello fellow captains, Captain Zuff here to announce that you can play Captain of Industry anywhere with GeForce NOW starting today!



For those who don’t know about the GeForce NOW service, it allows you to play games on any supported OS such as Windows, MacOS, or just a web browser! This is possible because the game is hosted on a remote machine and enables you to stream the gameplay in real-time with minimal latency. Note that mouse and keyboard support is required to play Captain of Industry.

To start, simply join GeForce NOW and pick a plan. Three tiers of plans are available, including a free one. Keep in mind that you will need to own Captain of Industry on Steam to be able to play it. You’ll be asked to link your Steam account when attempting to launch Captain of Industry for the first time.

Playing in the Chrome browser

Signing in through Steam will also bring over any other COI cloud-synced saved games, so you can even continue where you left off!

Thanks to NVIDIA for adding Captain of Industry to the GeForce NOW library and we welcome everyone who is interested to try it out!

* Fixed blueprint loading that in some cases did not load the library completely.