Ahoy, everyone. Captain Marek here with more information about trains—our most anticipated feature coming in Update 3. This time, I will tell you all about the train track, design, and history. I also have some train concept art waiting for your feedback.

A quick announcement before we begin: This week is the Sim Festival on Steam, and we are celebrating all things simulation, so if you are on the market for more simulation games, definitely check it out!

We are collaborating with a designer on concept art for our train models. Our goal is to make our trains look like they were created by engineers who have seen trains before but didn't have access to any blueprints—in essence, reinventing them from scratch. This approach ensures that our trains have a unique look and don't resemble any existing models too closely.

Here are four concepts for a diesel train. One design is smaller and more modest, while the other is more "chonky." We are considering offering two of T1 diesel locomotives. The bigger one could be a powerful hill-climber with a lower maximum speed, perfect for tackling steep grades. They are all 10 meters long.

Second is a design for our modern steam engine. We are still not sure whether steam trains will be an option at the end, but we are trying to see how that would look so here are two variants. The first is more rounded which is a classic for steam engines, the second one is more rectangular.

Let us know which one you like and why. And if you have some examples of real-world locomotives that we should take some inspiration from, share them too!

Design work for trains, especially train tracks, dates back to 2022, when we first started exploring the idea of trains in the game. This work was then put on a back burner because we had more important things to work on, but this year, we're developing it further.

In the early prototype, we were already considering a key aspect of train track building: Do we want discrete or continuous train tracks? By “continuous,” I mean tracks that can be freely constructed using curves and are not limited by the grid. Discrete tracks would be individual, pre-defined, grid-aligned pieces.

Discrete (left) vs. continuous (right) train track example

We’ve been playing and studying many games with continuous track building. I enjoyed making nice and smooth train tracks, which allowed for any direction and turning radius and offered great freedom in designing railways.

However, I also remember times when creating intricate train track crossings with continuous rails was fiddly and frustrating due to imprecise collision detection and bad snapping. For example, building a segment from A to B was impossible, but the same segment from B to A was suddenly okay.

The advantage of discrete tracks is that they provide precise and repeatable construction rules, making it easier to design complex tracks consistently, especially when the palace is tight, and each tile matters.

Captain of Industry is a grid-based game, and continuous elements often clash with other grid-based mechanics, such as collision detection, copy/pasting, and blueprints. While implementing continuous tracks is technically possible, we decided to go with discrete pieces.

Discrete track pieces have to be predefined, and they will ultimately determine what is possible to build. The question is, should we have fewer simpler pieces and allow their combinations to form more complex crossings, or provide a reasonable set of crossings and not allow tracks to cross?

Complexity-wise, having a set of predefined track pieces that cannot cross each other would be much better. It would allow us to make the tracks as regular entities and have existing game systems handle things like construction, collision detection, collapse, etc. Even our 3D artist was excited about the option of being able to model each switch and crossing manually to make them look more realistic (I guess he is still trying to increase his work security as if that’s even possible) so we investigated this option.

Our 3D artist referred to this picture when pitching how beautiful our crossings would look if they could be modeled manually. In case you didn’t know, these are called railroad diamonds, and you can learn all about them in this video.

So, we started designing different kinds of track pieces and intersections, which went quite well. Every track piece is represented by a curve that must start and end at a grid point, and its end direction must be a multiple of 45°. This would give us an 8-way rail network. We also prepared a similar set for double-track crossings.

The initial set of discrete train track pieces for 8-way travel. The black line is the center curve that needs to start and end on a grid point. Track ties and rails are omitted for simplicity.

An extended track set of double-track crossings.

Note that we can use 90° rotation and flip (reflection) to get all the other orientations that are not shown here.

Next we wanted to consider adding a less tight radius. And then there was a UI issue of how to let players select the correct piece.

And as if this was not enough, we were actually thinking of supporting more than 8 cardinal directions. Having the train network only able to do 45° increments felt too restrictive and not visually satisfying. So we did some prototypes and it turned out that a ratio x:y of 1:2 and 2:1 (27°) is possible and it would allow the track to be laid in 16 directions.

A prototype of half-circles using 16-directional pieces.

And this was the final nail in the coffin for non-overlapping track pieces. It would be completely infeasible to enumerate all the previously designed crossings now with respect to the 27° tracks.

So, we scrapped all these prototypes and went back to the drawing board to design a minimal set of pieces that could be used to build all the previously designed intersections and more. Fortunately, it didn’t take too long to arrive at this set:

A minimal set of train track pieces (initial version). Using this set and allowing for 90° rotation and flip, it is possible to build in all 16 cardinal directions, and all previously shown crossings can be composed of these.

Seeing such a small set of tracks was so satisfying compared to the previous sea of pieces, despite being on the hook for custom collision detection to allow their overlap.

This set of tracks was really powerful. The new 16-th of a turn allows for things like shift-by-two-tiles without any additional pieces, and adding a straight piece allows for shifting by any number of tiles. The only special piece needed is shift-by-one-tile.

An example of shift-by-two-tiles being composed by two 27° turns.

Having 16 directions is fantastic, but it presents a problem regarding turns. Remember, every piece needs to start and end on a grid point. Now, let's think about turns.

Pop quiz: If you draw a circle on a rectangular grid with a radius of, say, 14, how many integer coordinates (grid points) will the circle intersect exactly? Hint: It's going to be at least 4, right? At 0°, 90°, 180°, and 270°, where the point is precisely 14 units from the center. Are there any more? Maybe at 45°? Nope. There are no more exact intersections. The x and y coordinates of a point at 45° will be r * sin(45°), which will never be an integer.

This means that snapping a circle to 8 grid points at 45° increments along its perimeter will result in distortion. Even worse, if we snap a circle to 16 grid points, it will become what we call a “potato” shape. How much of a potato shape you get depends on the radius. Some radii are lucky, resulting in relatively little potato-ation. But some are unlucky, where the perfect circle happens to go right in between grid points, resulting in a true potato.

An example of snapping a circle to 8 and 16 points around its perimeter to the integer grid. Notice that for a radius of 14 units, the distortion is not as bad as for a radius of 18.

From the above diagram, you can see that more grid-aligned subdivisions result in greater distortion. We are still considering offering both 45° and 27° segments to provide a choice between flexibility and smoothness, depending on the player's preference. We might even add 90° turns for completely distortion-free turnarounds. Would you want to use them?

Comparison of 8 (left) vs. 16 (right) subdivisions of a circle. The 16-way is noticeably more potato-shaped but offers twice as many connection points for potential forks.

We examined all even radii from 14 to 30 to determine which worked best when divided into 16 grid-aligned segments. About half of the tested radii were acceptable, but we aimed to limit the available radius options to 2 or 3 to reduce the number of unique train track pieces. Ultimately, we selected 14, 22, and 30 tiles. This decision was made in conjunction with slope constraints, so keep reading to learn more.

Grade (slope) was important when designing the train train pieces. Dynamic terrain and work with elevation are two of the great features of Captain of Industry, so we need tracks to traverse different heights. As explained in the previous Captain’s diary #44[www.captain-of-industry.com], we decided to go with the steepest slope of 1:8 (12.5% grade), which is on the steeper side but works well in the game. We also decided to include less steep grade options of 1:16 (6%) and 1:24 (3%) to increase depth in the railway design and mechanics (some trains might be too weak to climb steep grades). There were other reasons for these grade options that will be more apparent after you read about grade-turns, but let’s not get too ahead of ourselves.

Slope on straight track pieces is relatively simple, we need 3 types. First is a “ramp start” piece that changes the slope from flat to the 12% grade. Second is the “ramp” piece that just continues this slope. And the third piece is the “ramp end” that starts on a grade and ends flat.

One trick that we use is that the ramp-start and ramp-end pieces increase elevation by only 0.5 tile, while the ramp piece has a delta height of 1 tile. This seemingly arbitrary rule has two benefits. First, the ramp start/end pieces can be only half as long since they don’t need to go as high, saving space. Second, this eliminates a fourth piece that would start and end flat but change elevation by one tile. We can now compose this piece from ramp start and ramp end.

Example of how ramps ending at half-tile heights make ramp start/end pieces shorter and eliminates the up-by-one-tile piece.

To hit the target grade of 1:8, the ramp piece has to be 8 tiles long, which is easy for the 0° piece, but the 27° and 45° straights have to be approximated. The 45° piece length is √2=1.41 and the closest we can get to 8 is by doing 6 * √2 = 8.49. The 27° piece has a length of √5=2.24 and the closest we can get to 8 is by doing 4 * √5 = 8.94. This means that the diagonal ramp pieces’ grade is not exactly constant 12.5%, but it fluctuates a little. Fortunately, this is not too noticeable.

And finally, the endgame boss of the train tracks discretization, the curved slopes. As we established in the previous chapter, sloped pieces need to have a length of 8 (or close to it) in order to conform to the standard slope of 12.5%, but the radius dictates the length of turn pieces, and not every radius is suitable due to the “potato-shape” issue.

Our tightest radius in the game is 14 tiles since train and wagon models would start intersecting in corners and it would look too unrealistic to have tighter turns. If we do some quick math, a circle of radius 14 has a circumference of 88. If we want to have 16 subdivisions, that’s 88/16 = 5.5. Well, that’s nowhere near 8, 5.5 distance would result in a grade of 18%. To make matters even worse, our 16 subdivisions are actually not even; they are 27° and 18°, not twice 22.5°, so sloped curves at the 16 subdivisions are a no-go, regardless of radius.

But wait, there's still hope! Let’s consider the 8-way circle subdivision resulting in 45° segments. They are all the same length, and it’s 88/8 = 11. Bummer, that’s also not near 8, but maybe we could make this work since it would be beneficial to have sloped curves. To make a turn of length 11 conform to the 12.5% grade, we need to start at that grade exactly, and then make it slightly less steep, but end right at the 12.5% again. This makes the ramp turn a little “wavy” but turns out it’s not that bad, so we went with it.

Example of 14-tile radius ramp turn that is slightly uneven due to the segment being too long for its slope. Don’t mind the floating track, it’s work-in-progress.

There is actually a way to eliminate the arc length issue. We could simply match the grade to the arc length. For example, our segment is 11 tiles long; we could make it a grade of 1:11 (9%), resulting in a perfectly smooth ramp-turn. The disadvantage of this approach is that it would no longer be possible to connect other pieces to it as it has a unique slope. For example, you could not attach a piece with a different radius. We considered having unique grades to remove slight waviness but ultimately decided against it and to keep a standardized set of grades to maximize track piece compatibility.

And now, after all these explanations, I am finally ready to fully explain why we chose turn radii of 14, 22, and 30 tiles. 14 is the minimum that still kind of works with slopes, but see what happens for the next one. The arc length of a 45° segment with radius of 22 tiles is 138 / 8 = 17, which is pretty much two times 8! This means that the ramp turn of 22 tiles will climb two tiles up at the grade of 12.5%. Even better, it will climb one tile at the half-slope of 6%.

We can do similar math for the radius of 30 tiles and the 45° segment has length of 23.5, which is three-times the standard grade! We can do a ramp turn that climbs three tiles up at the standard grade or one tile up at third-grade. And this is not a coincidence. Now you can fully appreciate why we have slopes of 1:8, 1:16, and 1:24 with radii of 14, 22, and 30 tiles.

Here is a handy table that summarizes the curved slopes support:


Finally, let’s enumerate all the unique train track pieces that we currently have (subject to change).

• [3] three straights, at 0°, 27°, and 45°
  
• [3] 45° turns, one for each supported radius of 14, 22, and 30 tiles
  
• [2 * 3] 27°/18° turns, one for each supported radius of 14, 22, and 30 tiles
  
• [3 * 3 * 3] ramp-start, ramp-continue, and ramp-end for all three grades for all three directions
  
• [2 * 5] 45° ramp turns (enumerated in a table above), we need two variants of each, one from ramp up and one for ramp down
  
• [4] shift by 1 tile, one for 0° and 45°, and two kinds for the 27°/18°

If you sum it up, this results in 35 unique pieces! And don’t forget that all pieces can be rotated by 90° and flipped, resulting in even higher numbers.

All track flat track pieces laid out in a pattern we internally call the “sun”. Note that this does not include straight and curved ramps.

Many players were asking us how train tracks would be constructed. We are working on an automated tool that works similarly to the conveyor/pipe construction tool by searching for the best path to the cursor. This diary is getting a little too long, so we will tell you more about this tool in one of the future entries.

An example of an automated track laying tool snapping to an existing rail.

In conclusion, we’ve developed a grid-based train track system that supports 16 cardinal directions, three curve radii, and three grades. The tracks can be freely connected to form complex intersections and train networks. If you’d like to learn even more about the topic of trains in Captain of Industry, you can watch our live-stream recording where I go into more detail. All discussed chapters are time-stamped for easier navigation.

We'd love to hear from you on our Discord if you have any questions or feedback about this topic. I am also streaming (nearly) every week on Saturdays at 10:30 PDT on YouTube and Twitch[www.twitch.tv], so you can also reach out with questions there.

Next time, we will talk about how we handle signaling (train traffic rules); we are actually working on signal-free train routing, so stay tuned!

Captain Marek out.

PS: Captain Marek will be in Tokyo around the 14th of August, conducting research on high-speed trains. If you want to hang out and talk trains (or anything else), shoot me a DM on Discord!

* Fixed main menu UI scaling to always be able to see the start game button even if the UI scale is greater than 100% on small screen resolutions.
* Fixed screenshot capture in photo-mode to include bloom.

Ahoy everyone, Captain Marek here! Since the release of Update 2 in April, we've been busy stabilizing the game, fixing bugs, and planning our next steps. In today's diary post, I'd like to wrap up the Update 2 chapter and give you a sneak peek at what's coming in Update 3. So, let's dive in!

Update 2 was a great success! Since its release, we've reached nearly 6,000 concurrent players, surpassing the numbers from Update 1. Our new COI Hub website is thriving with hundreds of maps created using the brand new map editor, and nearly a thousand blueprints have been uploaded so far. We greatly appreciate all the support and feedback from the community!
We’ve also seen some fantastic builds that you all share with us. Here is an awesome screenshot from a save shared by Reddit user PontusOverlord. He made this lovely organic build on the Armageddon map.

A save from PontusOverlord titled: “After 80 hours, my Spaghetti Island has finally reached space!” (Notice the rocket launching in the distance!)

Finally, I have an interesting statistic to share with you. Below is a pie chart showing map popularity based on games played in May 2024. The most popular map is Armageddon, accounting for 34% of all games played, followed closely by New Haven with 30%. Interestingly, over 15% of games are played on community-created maps. The standout among these is “All-in-One” by Undying29[hub.coigame.com], which creatively combines all built-in maps into one large island and is played by 3% of all players. Around 5% of players are still playing on legacy pre-Update 2 maps.

Relative map popularity in May 2024.

What is your favorite map? Would you like to have any of the less popular maps changed or improved? What kind of map do you wish to have to play on? Let us know!

Enough of Update 2. Now let’s switch tracks to the Update 3 and see what’s coming! In Captain’s diary #40[www.captain-of-industry.com] we already teased a prototype of roads – the #1 requested feature for Captain of Industry[ideas.captain-of-industry.com]. Since then, we have developed this prototype a little further but had to drop it from Update 2 due to time constraints.

By doing this prototype, we’ve learned that implementing roads is a very complex task as they need to interact with all the other game mechanics such as dynamic terrain, blueprints, copy/paste, path-finding, etc, which makes their implementation labor intensive.

Another challenge comes from the grid. Captain of industry is a grid-based game and all entities need to conform to the grid in some way. For example, we can define all road pieces to start and end on the grid, so that they can be easily connected together. However, with this system, making a two-lane road that has end-points aligned to the grid while keeping a smooth turning radius is complex, especially for roads at 45 degrees. The picture below demonstrates this issue.

Left: 45-degree double-lane road, where the outer lane does not end on the grid (see the red dot). Right: Both lanes end on the grid, but the resulting road piece has a jagged edge, causing many issues down the line, especially in 3D rendering.

This is actually a more significant issue than it might sound from this one example, but it adds to the list of issues we must solve to make roads a reality.

With all of this in mind, we decided not to invest further work in roads for now because there are more exciting game features that we could be working on instead. Choo-Choo! Hop on the hype train! 🚂

That’s right! After long deliberations, we’ve concluded that trains are more exciting than roads for several reasons.

First, while roads are great for organizing truck traffic, they don’t introduce fundamentally new mechanics to the game. However, trains bring a new mechanic: long-range high-throughput transportation. As maps are getting larger and larger, the need for long-range transportation is growing, and we’ve seen so many playthroughs on the Armaggeddon map that were just begging for this type of transportation.

Second, train networks can be made extensible, unlike conveyor belts or pipes. Connecting a new location to a train network can provide access to all destinations within the network, making trains more versatile and easier to build than, say, tier 4 conveyors.

Third, trains will help alleviate pressure on truck logistics, freeing trucks for mining or local logistics. Roads wouldn’t solve this issue; in fact, they might make it worse by encouraging players to build highways for long-range truck deliveries, requiring even more vehicles.

And let’s be honest, trains are awesome! Who doesn’t love trains? They are the lifeblood of any industrial empire, offering unmatched efficiency and capacity. Picture a powerful locomotive chugging through scenic landscapes, connecting factories with mines and ports. It’s a sight to behold!

Rest assured, our work on trains doesn’t mean roads are off the table; it just means trains will arrive sooner.

Before I tell you how trains will be implemented in Captain of Industry, let me preface this with a short personal story (feel free to skip for the train features below).

When I was a kid, my parents let me occasionally play games on their computer. The computer was running DOS, and I had no idea what was going on (I was 8 years old). An older friend helped me install two games on it: SimCity 2000 and Transport Tycoon Deluxe, and gave me the exact characters to type into the console to launch them. These games were my very first exposure to gaming and I was hooked!

To this day, I remember that my favorite TTD scenario to play was the “Mega Rail 1960”, a custom map where you start as an already developed company along 7 AI competitors. There was this aggressive pink AI that was always messing with me. The screenshot above is from OpenTTD[www.openttd.org] which can still load the original TTD scenario files!

Since then, I’ve enjoyed many games with trains. I've played games such as OpenTTD, Railroad Tycoon, Chris Sawyer's Locomotion, Cities in Motion, and even more recent ones like Mashinky, Factorio, or Sweet Transit. Yet, OpenTTD is still the most enjoyable train sim in my eyes. I just love that you can create the most efficient train network with things like priority merges or pre-accelerated trains joining a main line.

The point I am trying to make here is that I love games with trains and I care deeply about making things right. There are some games out there that implement “trains” just for the hype, but they are so heavily restricted that it’s sometimes just a point-to-point delivery with very little depth to it.

Since I played so many train games, I also have quite strong opinions about certain mechanics and features regarding trains and how they should work. We are even attempting to innovate here, but I am getting ahead of myself. Let’s talk about the features.

We are passionate about trains and have dedicated considerable time to designing them to be both easy and intuitive to use while maintaining our high standards for realism. In the following sections, I'll explain how we decided on various features.

Please note that any presented information is subject to change.

The very first decision was that trains should not be too far in the research tree. The earliest logical spot for trains is actually right after the steel research since train tracks, locomotives, and wagons all need steel – and a lot of it! Fortunately, steel comes right after Research 2 so getting to trains should be relatively quick. We are still thinking whether train buildings such as depot or stations should require Construction parts 3 (probably yes) and whether locomotives should require glass similar to T2 vehicles (probably yes) so feel free to let us know what you think.

The proposed position of train related unlocks in the research tree.

The second decision was about the types of wagons. Captain of industry has three major groups of products: unit, loose, and fluids (liquids and gasses). We already have three types of transport, three types of storage, three types of cargo ship modules, so it should be no surprise that we considered having three types of wagons.

On the other hand, we have just one type of truck that automatically adjusts to the cargo, so the decision is not as clear cut as it might seem.

We feel that trains are usually made for specific purposes, and three types of wagons make sense in this case. Having more wagon types also makes the trains more visually interesting and recognizable.

It needs to be said that we are still considering making a special universal wagon type available as a toggleable difficulty setting for players who don’t want to be bothered by matching wagon types. Which camp are you on? Universal or specific wagons?

Prototypes of three types of wagons.

Our 3D artist has shown enthusiasm for creating more types of wagons to enhance the visual appeal of our trains. While he might be joking about wanting job security by working on wagons all year, the idea of specialized wagons for items like logs or steel is worth considering for the future. We’d love to hear your thoughts on this! Would you be interested in using highly specialized wagons?

We plan to have a modularized approach where each station block will be the same size as a wagon, allowing players to build any station size they want. Each wagon type will have a matching station module. This is a similar approach to cargo ships. Train stations will have ports for conveyor belts and pipes, and each station can load or unload.

The third decision we faced was about the lengths of locomotives and wagons (train cars in general). We had two options: either make all train cars a fixed size, ensuring each one has the same length, or allow variable lengths, where each train car can have an arbitrary length.

While variable lengths are more realistic and offer more freedom in 3D modeling, we ultimately decided against this option. We chose fixed train car lengths to ensure that loading and unloading stations align perfectly with the train cars, avoiding any alignment issues and simplifying the overall gameplay experience.

Initially, the train car length of 7 tiles (14 meters) was chosen. It’s quite realistic, even though it’s on the lower-end of real train sizes, but any longer wagons were taking too much space in the early game. Our artist has made some mocks of this size, and we’ve been experimenting with them for some time.

Initial prototype with 7-tile train cars. Trucks for scale.

Many things in Captain of Industry scale over time, and we felt trains should scale as well. Having the same 7-tile locomotives and wagons for the entire game felt a little underwhelming during testing.

Thus, we decided to revisit the 7-tile long train length decision and made new prototypes with the size of 5 tiles (tier 1) and the size of 10 tiles (tier 2). Since T2 is twice the length of T1, the station alignment is preserved, but locomotives and wagons can undergo substantial upgrades. These sizes are also quite realistic. It felt awesome to see large locomotives pulling long trains as an upgrade, so we kept this and tossed the 7-tile trains. We also considered length pairs of 6/12 and 4/8, but these were too big or too small, respectively.

Prototypes of tier 1 and 2 wagons. The idea is that T2 will have ~3x more capacity.

Next, let’s briefly discuss the turning radius. Typical freight trains have a minimum turning radius of around 100 meters (300 feet), equating to 50 tiles in-game. While we strive for realism, such a large turning radius would make trains very difficult to use, which is not our intention.

On the other end of the spectrum, some grid-based games feature trains that can turn very tightly, with radii as small as 2-10 tiles. For example, in OpenTTD, trains can make a 45-degree turn on a single tile. While convenient, this would not work in Captain of Industry.

After extensive testing with our 5 and 10 tile wagons, we found that the smallest usable turning radius is 14 tiles (24 meters). Though still quite tight, this radius prevents train cars from clipping into each other during turns. Therefore, we've chosen this as our tightest option for now.

Additionally, we wanted to offer more turning radius options for situations where space is less of a concern. We decided on radii of 14, 22, and 30 tiles. The plan includes implementing maximum speed restrictions on tighter turns to enhance realism and encourage players to build smoother turns. The relatively large gaps between the available radii make them easier to distinguish, and we can maintain a smaller number of unique rail pieces.

An early mock of various train car lengths on various turn radii. The radius of 16 tiles was not chosen because it does not form a good circle when composed of 45-degree segments.

The final feature I wanted to cover today is the slope (grade). Take a look at the picture below, what slope would you choose with regard to realism and gameplay convenience?

These are four different slope options from least steep to steepest. Which one would you choose?

Now that you've chosen your favorite slope, let's dive into the details. Slope #4 is a 1:4 ratio (1 unit up for every 4 units horizontally), which matches the terrain designations. Vehicles can also drive up this slope. Slope #3 has a 1:6 ratio, making it slightly less steep. Slope #2 is a 1:8 ratio, half as steep as #4. Finally, slope #1 is the least steep with a 1:16 ratio.

The slope of train tracks is typically measured in grade percentages, calculated as the quotient of the slope ratio. Our gentlest slope, 1:16, translates to a grade of 1/16 = 0.0625, or 6.25%. In real life, freight trains rarely traverse grades steeper than 3%. Interestingly, the limiting factor is not the locomotive's raw power but the insufficient friction of the locomotive’s wheels, which can cause them to slip. It's not uncommon for freight trains to stall on steep slopes, especially under adverse conditions like rain.

In the game, the 1:4 slope is the most convenient since it matches vehicles and terrain designations. However, it appears too steep visually, to the point it breaks the immersion. We decided on a 1:8 slope (12.5% grade, #2 in the picture) which, while still steep, allows trains to change elevation levels within a reasonable distance. To support this new slope, we are considering adding 1:8 terrain designations. Additionally, we’re exploring less steep slopes for players who prefer a more realistic experience, specifically 1:16 (6%) and 1:24 (4%), which is really close to the real grades for freight trains. Our new configurable game difficulty, introduced in Update 2, could include options to enhance train realism.

There were other constraints to the slope related to track piece lengths in turns, but more about that some other time.

• Trains will be available near steel in the research tree.
  
• There will be three train car types for three major product categories: unit, loose, and fluid.
  
• Train stations will be modular, with one module for one wagon.
  
• Trains and wagons will have two major tiers. T1 will have 5-tile train cars, while T2 will be twice as long.
  
• Train tracks will have a minimum turning radius of 14 tiles and larger radii will also be available.
  
• Maximum grade (slope) of train tracks will be 12.5% (1:8), half as steep as what vehicles can drive on now.

There’s still much more to discuss regarding trains, including train track mechanics, train stations, train physics, and traffic control with semaphores, but I'll save those topics for next time.

I hope you enjoyed this in-depth look into our train design process. We’d love to hear your thoughts on Discord and Reddit. I will also be live-streaming this weekend on YouTube and Twitch [www.twitch.tv]so feel free to bring some questions there (subscribe to get notified). And that’s all for today, Captain Marek out.

* Fixed a rare issue resulting in corrupted save file error regarding missing IResolver dependency.

* Fixed a rare issue on load showing errors like "Failed to resolve IMapCacheManager".

* Fixed vehicle path-finding that was sometimes not being able to find the shortest path and was returning longer ones.
- On average, the length of paths taken by trucks is 4% shorter and takes 15% less steps to find.

v0.6.4
* Added map-data-cache feature that speeds up game loads by around 2x (more speedup for weaker CPUs).
- New Haven map load went from 12 to 7 sec, Armageddon from 30 to 15 sec (on i9-13900 CPU).
- This was achieved by loading cached map data instead of generating terrain from scratch.
- Map cache is created and saved on the first game load so speedup will be only noticeable on subsequent loads.
- All games that share the same map version will share its cache.
- At most 5 map caches are stored at one time.
- This feature can be disabled with --disable-map-cache launch option.
- This change also reduces the probability of game crashes due to high CPU load on systems that are sensitive to this.
* Improved saving algorithm of terrain tile data, reducing raw save file size by ~2x. The effect on final compressed file size is smaller, around 15% savings.
- This change resulted in significant memory and time savings during saves and made map cache smaller and faster to load.
- Map data cache of the Armageddon map went from 160 MB to 66 MB (before compression).
- This change also reduces the chance of encountering out-of-memory errors during game saving when the system is low on memory.
* Settlements can now have custom surfaces which cover the original paths.
* Game speed is now saved.
* Spam-clicking the start game button no longer makes the in-game escape menu unclickable.
* Fog now renders properly for liquid evaporators and vehicle particles.
* FPS limit was removed from the loading screen to eliminate idle time where the game is waiting for the next step but the renderer is also waiting for the next frame due to the FPS cap.
* Improved visuals of dust particles on terrain and behind vehicles.
* Vehicle dust and exhaust particles now do not spawn when the camera is too far from them.
* Vehicles now spray water instead of dust during rain.
* Dust behind vehicles is now emitted even on concrete surfaces in small amounts.
* Fixed excessive dust emitted when the mega excavator was turning in-place.

Map editor
* Optimized the "Writing generated data" step which used to take up to 60 seconds on large maps, now it’s nearly instant (speedup of over 1000x).
* Fixed missing reference list of noise functions.
* Fixed error window that did not show errors when first displayed.

* Single-copied lifts now go back to the first construction phase if placed down while holding Ctrl.
* Custom surfaces can no longer be placed under water.
* Fixed a rare terrain generation issue during game load that could result in map being loaded as brand new without any terrain modifications.
* Improved bush textures to make them more visible against grass.
* Slightly increased sun shadows intensity.
* Added checksum save file verification before loading a game to detect externally corrupted files.
* Further work-arounds for saving issues on mac when playing via CrossOver.
* Fixed arithmetic overflows that could occur with extreme settings of terrain features in the map editor.
* Fixed rare path-finding when the goal was hard to reach and exactly at 10 tiles height difference.
* Fixed jitter on fluid cargo module pipes.
* Fixed camera rendering distance when loading its position from a saved slot.
* Fixed ocean rendering that could have cracks where it was possible to see under the ocean.
* Fixed a rare vehicle depot state where it believed that vehicle should be upgraded but vehicle itself did not intend to be upgraded.
* Fixed that pressing Enter on the main screen kept opening new window instances.
* Windows no longer accept input when in fade-out transition.
* Fixed farm popup that was showing locked crops.
* Fixed tree harvester that could be showing "no tree to harvest" when out of fuel.
* Fixed rare issues with inability to instantiate Audio Manager.
* Fixed glass on highest greenhouse tier.
* Fixed smoke particles that were showing square artifacts in rainy weather.

* Added a workaround for Mac users using CrossOver who were experiencing `IOException: Success` on game save. Bug was reported to the CrossOver team.
* Step limit of the vehicle path finder now scales with its internal job queue size. This helps to restore logistics quicker when it gets overwhelmed.
* Added console command `set_max_steps_per_tick_for_vehicle_path_finder` that allows manually increasing the PF processing throughput (only for extreme players).
* Vehicle navigation jobs now show more info about where they go.
* Additional fix to the You Shall Not Pass map back-start to have immediate access to trees.
* Leveling designations now show colors correctly on designations not ready to be fulfilled.
* Fixed sandstone non-corner edges.
* Fixed surface vertical faces to show correct surface type.
* Fixed ocean coastline that was sometimes jagged.
* Fixed blast furnace 2 preview that was all white.