The weeks since the last devlog may have been among the most challenging since I began working on Atlantic ‘41. And yet I merely needed to implement automated enemy behavior, based on a handful of simple rules. I’ll come back on the specifics, but the first task was to make the ships behave in a way consistent with convoy procedures during the battle of the Atlantic, and divided into two main axises: the civilian ships, and their military escort. 

Then I needed to convey enemy activity to the player for each turn. I’m still working on that, and I’ll go over the results in the next log. But first...

A Balancing Act

Enemy’s logic isn’t complicated; in essence a bunch of board game rules; conditions, equations and rolls. The maths never goes above junior high school arithmetics and trigonometry. But I quickly realized two things: 

1/ Rules written on paper rarely work as is, and the system needs many tweaks as you discover edge cases and exploits.

2/ Testing the gameplay is incredibly time consuming, in particular when you lack rapid prototyping and game design editing tools. 

An information splash screen now indicates the beginning of each turn

I couldn’t find any decent way around the first issue. Experienced game designers may be able to devise flawless systems on a white board, but my theory always breaks in practice. I was able to anticipate on a few, but mostly my way to find problems was to run into them. The second issue requires to set aside time and resources to build proper content editing and gameplay testing tools. I don’t have these resources.  

Atlantic ‘41 sits in an awkward middle ground. It’s big enough to make hand typing data inefficient and tedious. But it’s too small to justify developing proprietary tools.

Constants for balancing  the deck gun sequence. All design tweaks happen directly in the code editor

I decided to brute force my way without looking back. I never meant to build an engine and a suite of tools for multiple games. I may have ideas for one DLC, or a few free updates at best, but I’ll cross that bridge when I get there. In addition to that, tools are useful for shared content, but I work alone, so the inadequacy of the workflow won’t bother anyone.

In the second devlog dedicated to enemy ships, I described the core systems controlling their behavior. Feel free to refer to it for a detailed explanation; In simple terms, a convoy can have two states: 

. Normal operations where ships don’t break formation and sail a common heading at slow, fuel saving speed. 

. Alerted state, where ships follow specific rules whether they’re part of the defenseless ships or their military escorts. In this state, what I’ll refer to targets try to escape as quickly as possible, while the hunters buy them time by harassing, and if possible sinking the threat.

Think of the convoy alerted state as the alert mode in Metal Gear Solid, when soldiers leave their patrol routes

There’s a few other special cases, but we don’t need to worry about that for now. In order to react, enemy ships need the ability to spot a surfaced U-boat, or to detect it when submerged. I was more worried about the detection algorithms than most other aspects of development, for their potential game breaking effect on gameplay.

Not to mention the difficulty of balancing gameplay and historical accuracy (to a certain degree).

My go to reference for U-boat logs

I went back to reading U-boat attack logs and other reference material, to get a sense of the main components at play; visibility distances, weather, sea conditions, equipment etc...I mentioned in the Cranko! interview how much I enjoy research. For anyone building a game set in an historical context, there’s genuine excitement in the idea of simulating everything. Unlike a board game, where rules must remain manageable by the player, there’s no limit to how sophisticated the calculations can be under the hood of a computer game. Or so I thought. 

In his war diary, Carl-Gabriel Graf von Gudenus recorded 260 depth charges dropped on his U-427 Type VIIC, on 29 April 1945

I had long planned which parameters would dictate visual and sound detection rolls. But the more I was researching the topic, the more I went down the rabbit hole, adding more and more modifiers to the equation. But there’s two issues with that approach. First, it becomes very hard, if not impossible, to balance the difficulty.  I knew that I wanted the game to reflect the unforgiving nature of U-boat warfare. But the reality was too unfair. In many cases, in particular toward the end of the war, U-boats were sitting ducks. No amount of experience or skill could save them. A good balance requires tweaking every parameter of the equation. Beyond a dozen turns into a nightmare. You need clear and understandable levers to steer the gameplay. 

Some of the console data I use for debugging and balance

The other side of that coin involves the player. I explained in previous logs why I hide the maths to the player, and why I don’t communicate anything with numbers. Players with access to the system’s maths are tempted to crunch numbers before every action. Even without a min maxing obsession, numbers make the game more predictable. You lose the uncertainty of whether you’re making the best decision. Not to say numbers are bad. They make the experience more “gamey”, which is fun too. They’re a different kind of games, more about statistical optimisation. 

“Caves of Qud”  is a great game making heavy use of numbers

Here’s another reason: For testing and debugging purposes, I display all the stats in the simulator console. But I noticed how knowing the odds creates strong expectations on the result. And consequently, it can build frustration. I mentioned this in a past log, but I was shocked at how poorly our brain understand statistics.

I use visual representation of probabilities to help me balance the game. Here, base surface detection probabilities for day and twilight situations

If I tell you “you have 4% chances of being detected”, you think “I’m almost guaranteed to be safe”. The reality is that you should think “I’ll get detected on a regular basis.”. On a 90% hit rate, you think “I’ll rarely miss.”. You should think “a hit is far from guaranteed.” 

You’ll throw your hands up if you miss a 90%  hit twice in a row, but the reality is that it will happen a lot more often than you think. Without wrong expectations given by numbers, I found easier to accept unlucky streaks.

Finally, numbers somewhat hurt the immersion. 8/100 hull points is undeniably more precise than “Critical hull condition”. But in real life, things don’t have a number attached to them. A captain would judge the hull by the dents and the tears. He would listen to it squeak and crack. But he never knew how close the boat was to the breaking point.

Base surface detection probabilities / night 

Now apply that to the detection rolls. The player never gets a “visibility” or a “noise” number. They can’t watch these numbers go up and down as they take action or as the situation evolves. But even though they don’t need to know how the maths work, they must understand what affects their chances of being spotted or heard. Ideally, despite being unable to control everything, they must still trust their power over the outcome.

This becomes a problem when the player’s options aren’t obvious to them. This means limiting the simulation to what the game can efficiently communicate to the player without numbers. When you can’t rely on numbers to tell you what does what, the game needs to convey that information another way. I plan to have an always available contextual in game manual from the home menu. In addition to that, officers will share knowledge or information on occasion. 

Base periscope depth detection probabilities / day and twilight

For instance, I’ll explain that torpedo attacks have better chances to succeed from the surface than from periscope depth; from the low vantage point of the attack periscope, it’s more difficult to acquire precise data required for an accurate firing solution. The player doesn’t need to know by how much surfacing increases their firing roll. What matters is that you should attack from the surface whenever safe to do so.

Furthermore, the player is taught that a surfaced boat is roughly as difficult to spot at night than its periscope being during the day, except at full moon. Anyone can put two and two together and understand that they should prefer night surface attacks, except on clear full moon nights. They don’t need visibility numbers of hit rates. Like a real Captain, they merely need to know what are the benefits and the risks associated to each strategy.

Base periscope depth detection probabilities / night

The player has agency over the majority of the parameters in any given situation. For instance when escaping hunters, it’s best to be as quiet as possible. They can dive below the layer where the water temperature changes and disturbs ASDIC waves. They can lie on the bottom, which is the ultimate hiding place. But all these options have risks. For instance you don’t know how deep the temperature layer is. There’s more chances to reach it in shallow waters. But deep dives always imply more stress on the boat and on the crew. So depending on the hull’s integrity and the crew’s cohesion (a concept unique to Atlantic’41, which is a mix of morale, experience, and stress. I’ll explain in a future log), it may be better to dive deep to throw off the hunters, or it may not be worth the risk.

The game simulates more subtle factors, like how a U-boat silhouette is more visible against the brightest part of the sky at dawn and dusk

There’s also a few things that the player has no direct control over. One example is the negative modifier from being previously detected. This simulates the hunters adjusting their fix on the boat’s location after they’ve found it in the first place. Reading authentic war logs, it struck me how bad often turned into worse in a cascading sequence of events, which all started with the boat being initially detected; the boat is hit by depth charges, the resulting failures impede its capacity to evade the pursuers, leading to more hits, and so on.

An escort ship often laid a pattern of 9 to 10 charges

Adding this modifier to the roll emphasizes the importance of not putting yourself into this potentially death loop. Hopefully after a few close calls, the player will learn that lesson, and be more cautious or strategic. I’d like for the game to be this constant push and pull, gut feeling decision making, always within fuzzy parameters. Rather than pressing buttons until the numbers give you the best odds, you must evaluate the problem and maximize your chances. The more you play, the more accurate your read gets on any situation. 

In “Das Boot”, the navigator keeps count of exploded depth charges

To sum up: for every aspect simulated, I would think of three things:

. How much does that parameter weight on the chance of being detected? (either spotted or heard)

. How do I convey the state of that parameter? (For instance, you read range on the TDC gauge, sea condition in the situation report, noise is inferred from the power of the motors etc...)

. Are there always both risks/drawbacks and advantages to each aspect of a situation? For instance, reducing range both increases your chances of hitting and being spotted. Rigging the boat for silence reduces noise but prevents loading torpedo tubes (since it’s a noisy activity). Sailing away fast increases the area hunters have to search, but it produces more noise.

The damage report is an approximative visual assessment

Balancing all these aspects turned more difficult than I had anticipated, but also fun. Finally, it felt like getting into the nuts and bolts of the experience, molding it into the right combination of fun, stressful, rewarding, exciting, and everything you expect from a game. But as I implied earlier, I stumbled on several problems, most of them consequences of the turn based system. The following are some examples of that.

Sequential Versus Contemporaneous

This part may read dry but it illustrates the deceiving complexity of game design, even the simplest systems. Early on I wanted Atlantic ‘41 to be turn based. The concept originates from board games, to give players equal opportunity for action, independent from time.

One of the oldest forms of turn based strategy

But even when computers are able to simulate real time situations, many video games still prefer the turn based approach. Reasons may vary, but for me, they are:

. Real time games, in particular real time strategy, are stressful. The player is under constant multitasking pressure. I’ve always hated time pressure, in any game, and RTS is the ultimate form of time pressure. I want to enjoy the game at my own pace.

. Because turn based systems require less input from the player, individual decisions tend to have more weight. Real time games demand more micro management. They tend to be more tactical, and less strategic.

. Real time is not suited for large scale battles of slow moving units, like naval battles. In that case, the game gives the player the ability to compress time. But to me, time compression can be distracting, and even turn into a chore.

“Atlantic Chase” has unique turn based mechanics

The slow pace of U-boat simulation makes it a perfect candidate for a turn based video-game, yet to my knowledge  it’s not been done. The problems I encountered made me wonder whether others had tried before me. But I think that the issues were more due to my own inexperience than the theme’s incompatibility with turn based.

I suspect that my problems are well known among board game designers. It comes down to the difficulty of simulating a real time situation into a sequence of fixed events. In life, multiple things happen simultaneously, and people react accordingly; all events and actions bounce off one another, resulting in a complex, often unpredictable outcome. But turn based systems treat time as a sequence of time slots (turns or rounds), and resolve events and actions in isolation, within each turn. 

Even the venerable “Silent Service” was pseudo real time

Herein lies the issue. The sequential nature of turn based systems makes difficult to program dependencies. All events and actions are locked, with no opportunity for the player to adapt their strategy until the turn is resolved. It’s difficult to explain, so I’ll give examples of the conflicts I encountered, and the solutions I came up with.

Regardless how you approach turn based, it’s always an abstraction of real time. So the most important decision is what events and actions should be grouped and resolved together, and the order in which these groups take place. But regardless the approach and the game, there’s always a compromise. Sometimes, all units for each side activate in whichever order they choose, then the opposite side takes its turn. Sometimes units from both sides follow an order determined by a speed or initiative value. Wargames often have sides taking alternate actions, going back and forth within a turn in a more elaborate order. One side moves, then it’s the opposite side, then the initial side attacks, the opposite side resolves routing or other defensive actions etc...

The “Great Battles of History” series (Here “Great Battles of Julius Caesar”) have very complex turn orders

Coming up with Atlantic ‘41 turn order took some trial and error. To reflect the stalking nature of U-boat warfare, I wanted the player to elaborate their strategy based on the predicted behavior of the enemy. In that I was partly inspired by the brilliant “Into the Breach”. Once the player commits for that turn, everything is resolved without interruption until next turn. I like this system because it’s relatively fluid, easy to understand, and it gives the initiative to the U-boat.

I love the turn based mechanics of “Into The Breach” 

When the player activates the next turn command, events are resolved in this order:

. U-boat attacks (torpedo or deck gun).

. U-boat dives.

. Enemy ships move (following course chosen at the end of previous turn).

. Enemy ships attack.

. U-boat moves (following course chosen by the player during their interactive part of the turn).

. Enemy ships roll for detection and determine their course for next turn.

Not all steps happen every turn. It all depends on the situation. The turn order matters for a number of reasons, and conflictual situations forced me to break it down that way. For instance, I wanted the U-boat to have the initiative, and give it the opportunity to take down ships before they even got a chance to detect it.

The game gives attack initiative to the U-boat to encourage the offensive

However, even though the U-boat attacks and dives first, it has to move after the ships. Otherwise, since ships declare their move intentions ahead of the turn, with a turn representing 10 minutes, the U-boat would be able to constantly run away from pursuers, without them ever getting in range of depth charges. 

Detection Conundrum

Detection mechanics were among the trickiest things to figure, and not just because of all the situational parameters to consider. Unlike an attack, which happens at a specific moment, detection can occur anytime during a turn, men on watch constantly looking or listening for signs of U-boat presence. But the turn based code doesn’t simulate the world in real time within a turn. And yet the detection probability can vary wildly over the course of the turn, driven for instance by the distance between the boat and the ships.

The dark circle shows the ASDIC detection range. The light circle is the visual detection range

The solution was to average the detection into one roll, which takes place at the end of the turn. Rolling for detection before the ship’s attack wouldn’t allow the player to react to detection, which is unfair and unrealistic. The situation is well illustrated in “Das Boot”; While attacking a destroyer in choppy seas, the captain scans for the target in the attack periscope. The destroyer is suddenly revealed behind a wave, sailing at full speed toward the boat. The captain yells the dive order just in time to avoid the submarine being rammed.

One of the most tense close calls in “Das Boot”

The game must give the same chance to the player, and that’s why the detection roll must happen last. At the beginning of the new turn, the player gets to see if any ship intends to ram the boat, or fire its guns at it. If the player doesn’t dive on the next turn, their chances of survival are slim, but it’s the result of their own mistake.

The course of the destroyer leaves no doubt that the U-boat was spotted

One last edge case example: Initially I was resetting the detection state per ship at the start of each turn. Doing this, a ship could spot the U-boat one turn, and then “forget” about its existence the next turn. Now if you imagine a man on watch duty spotting a periscope, they would keep track of it with goggles and sound the alarm. The hunting ship would flood the area with powerful searchlights, giving little opportunity for escape to the submarine unless it dives. It’s unlikely that once spotted on the surface, a U-boat would be able to lose their pursuers, unless maybe in heavy seas. In game, I made sure that any ship spotting the U-boat gets automatic detection in subsequent turns (unless in stormy seas), up until the boat dives, at which point the detection state is reset.

Later in the war (and in the game), radars make the U-boat more vulnerable to detection, even at night and in bad weather

That’s just a few of the various issues I had not anticipated. The experience gave me greater appreciation for the complexity of games I’ve played my whole life. Even a simple game like Atlantic ’41 gave me headaches, and I can’t imagine the skill and experience involved in programming “Into the Breach”, which many players wouldn’t even describe as “deep” or “complex”. I’m looking forward to Edmund McMillen “Mewgenics” upcoming release. Watching gameplay videos, I marvel at the amount and difficulty of the work produced by Tyler Glaiel, the main programmer on the project. Not to mention that he built the engine from scratch...

“Mewgenics”

I know that this log wasn’t the most exciting read, but it’s part of the reality of making Atlantic ’41. Even a small turn based game is a big scope for a sole developer with limited programming experience. Technically, a good chunk of the enemy’s AI is now behind me, but I expect many changes and tweaks once testers get their hands on the game. With that done, I’m inching closer than ever to having a fully playable engagement.

Work in progress of the in game control room, at line art stage

But at least the next log should be more entertaining, with lots of graphics, sounds (at last!) and a new sequence conveying the life aboard during enemy activity. It will be the opportunity to implement iconic U-boat action moments. You’ll get to listen to the familiar ASDIC pings from the heart of the control room, moments before depth charges rattle the boat. Alright I may oversell this, but eh...

More soon.