The back and forth on the deck gun attack sequence got me thinking that even simple features can bite back without proper preparation.  Normally I spend time laying down a rough plan ahead of making assets and writing code. But there’s always a level of discrepancy between what you imagine and reality. Even experienced developers need prototyping and iteration, which is difficult without dedicated tools.

I don’t have much way around this, short of being even more granular in planning. So I was a bit worried about repeating the same mistakes for the torpedo attack sequence, even though it seems easier on paper.

Morbid Visual Feedback

First I should talk about animation, because it took a big chunk of development time. Specifically about the torpedo explosion. Archival footage shows how powerful these detonations are. It’s not surprising, considering the 250 kg explosive charge. Torpedoes are so destructive that they didn’t need to hit the target’s hull. In some cases, a torpedo was set to glide several feet below the keel, where the magnetic detonator would trigger the charge, which would split the ship’s backbone. 

HMAS Torrens Under-Keel Torpedo Explosion

As terrible as it is, a spectacular explosion is the essential visual feedback to a successful torpedo attack. Sound will play an important role, but it’ll come later. We’ve seen how painful changes can be, as they can affect both code and assets. I can rework graphics quickly enough, but my lack of experience in the sound department might make changes hurt. My plan is to implement sound when a self contained section of the game is playable. For instance when having the engagement loop.

Torpedo hits a Japanese submarine

Previous experience with the gun shell water splash taught me that hand painting would likely yield poor results, so I looked for reference footage. It would take ages to find a sequence from the period with the proper angle and quality, but watching many of them helped me to selecting a few modern clips which, combined and manipulated, would make an animation with the right characteristics.

Explosion references

I edited the lighting and contrast of the footage, and cut down the number of frames to 40. I find that number to be high enough for short, smooth animations, but not too heavy in memory. Less frames would require to slow down the frame rate too much in order to convey the massive scale, which would make the animation look choppy next to other assets running at 50 frames per second.  

Atmospheric perspective as distance increases

After that, it was sampling down, rotoscoping and clean up, then 1-bit conversion, followed by individual frames touch up. I had to repeat the whole process three times; since there’s no real time in game scaling (which would look messy on such detailed assets at the Playdate resolution, and also tank the frame rate), I broke down the visual range into three sets of sprites. Consequently I need three explosion sprites, for distances below 2000 m, between 2000 m and 4000 m, and beyond 4000 m.

All the assets needed for one ship..

Doing this also helps me to creating a sense of atmospheric perspective, as I bake haze into the sprites. As distance increases, objects get lighter and lose contrast and detail. The flip side of that workflow is that it complicates the process of drawing assets, which all have to look consistent with one another into one specific range. And it increases the workload significantly.

Three scales for explosions

The day and night cycle stacks another level of complexity,  elevating the number of variants needed for each ship, land mass, and effects. Assets need to be legible against a wide range of backgrounds, due to the varying weather and lighting conditions. I find this to be one of the hardest challenges in 1-bit. In the case of the explosion, the solution was making sure each frame contains a mix of dark smoke and bright fire. The fire ensures readability against dark backgrounds, while smoke does the heavy lifting under bright conditions. Realistically, the smoke looks a bit too bright at night, but I don’t mind it, as we can imagine it lit by the fire. Besides, a darker value read poorly.

Final explosion

I’ve learned to dread these effects, and this one was no different. All accounted for, it took me several full days of work to get it right. No doubt, someone more skilled or with a clever workflow could bring that down to a day or less. But I’m happy enough if I can make it work, even after long hours. The upside is that I used the time to think about the torpedo sequence, both from a presentation and standpoints.

Form and Function

Structurally, the sequence is simple; all the orders regarding target and tubes selection are given by the player during their turn, based on the tactical information provided to them. The torpedo attack sequence is passive, merely a way to communicate the outcome of decisions made during the interactive phase. 

Assigning tubes 1 and 2 to a target

In that sense it’s similar to the deck gun attack sequence, which I exposed at length. And both sequences have the same goals. One, to communicate successes and failures, and update the situation. Two, to get the player immersed and reinforce the game’s themes.

The communication aspect is straightforward, all taken care through the officer’s dialogue. Regarding the torpedo sequence, it’s the captain’s responsibility. As the boss, he’s in charge of ordering fire, and updates the crew about what he sees through the periscope. For surface attacks, he stands on top of the conning tower, looking through the UZO.

The captain sums up target and torpedo data

I’m glad to have spent time to lay down a plan and let it simmer while I was working on the explosion animation, because I realized that the sequence had to communicate more information than I initially predicted.

For instance, have the captain sum up each target’s data, including class, range, angle on bow, speed, and behavior. The game’s low graphic fidelity doesn’t convey any meaningful information about the ships, which makes difficult for the player to know which target they’re looking at, in particular since they don’t have control of the camera during the sequence.

“Greyhound” - Aaron Schneider - Turning into the torpedo

In life, sometimes a torpedo was spotted by a ship’s watch. If this happened early enough, the vessel would try an evasive maneuver, often turning into the torpedo as to offer less surface, and, worst case, hoping that it would bounce off the bow. That sudden course change revealed the important fact that the torpedo had likely been spotted. The game simulates torpedo detection, so target’s evasion attempts are communicated during the torpedo sequence.

Realism, for lack of a better word, made me decide early on in the project to never show anything that the crew members couldn’t see from their perspective (no torpedo camera, or underwater shots of the U-boat). I also didn’t want to give any information to the player that they couldn’t realistically have access to. 

Torpedo magnetic detonator

I debated whether I should inform the player of duds. Submarine technology was still in its infancy, most of it inherited from the first World War. Torpedoes were temperamental, in particular leading up to 1942, before the advent of the T3 electric torpedo and their more reliable detonators.

So should I tell the player if a torpedo failed, or if it missed? Research taught me that crews had several tricks to figure what happened in most cases. Sometimes, they could hear the impact of the dud through the hydrophone, or they could see a splash from the impact. Sometimes the torpedo would veer off course and explode prematurely. Deduction also helped; a sudden change in behavior of the target could indicate a dud’s impact. Successful torpedoes could betray a dud inside the same salvo. Given all this, I elected to inform the player of duds, without going into the details about how the determination was made.

Torpedo is a dud

Besides giving adequate information, the sequence needs to fulfill its other goal: immersion and theme.

There’s many classic WW2 submarine images, but one is iconic; it’s the captain, pocket watch in hand, waiting for the moment of impact. Without modern telemetry and tracking systems, there was no better way to know when the torpedo had ran its course. The stopwatch makes a great thematic device, and a nice opportunity to build anticipation before resolving each torpedo.

“Das Boot” - Wolfgang Petersen - The stopwatch

The problem is that a steam torpedo traveling at 40 knots (75 km/h) takes 50 seconds to cover 1000 meters. Big games let the player manage the wait with time compression. They can also pass time watching the torpedo camera, or do other things around the boat. Atlantic ‘41 has none of that.

Thankfully, recycling the time skip from the deck gun sequence allows me to jump ahead to the last five seconds before impact. At this point, I display the stopwatch on screen, ticking away the few moments before impact.

A work in progress shot of the watch, before I moved it to the bottom of the exterior view 

I don’t like adding too much clutter on screen, but the watch works with the all analog direction, and it’s effective at building suspense. Sound will play a part there. I’m thinking of lowering the ambient sound and increasing the ticking sound as the countdown progresses. Initially I thought of having a full shot of the stopwatch before switching to the exterior view, but the cut was jarring and broke the flow of the sequence.

Final stopwatch implementation

I programmed the sequence with place holder math for the hit and detection chances, to get a sense for it. All the necessary information was conveyed to the player, and even without sound, the ticking clock to each torpedo impact did what I was hoping; create a sense of anticipation. The explosion was powerful and satisfying, even though a mere “the target is sinking.” didn’t feel like the appropriate reward, but I’ll come back to this next time.

But there was a problem.

A Momentary Time Lapse 

The deck gun sequence had only one time skip, but the torpedo sequence has multiple, two per salvo, which highlights its shortcomings. I liked the stopwatch suspense, but the time skip held the sequence back.

Besides lacking visual interest, I couldn’t tell if the fade registered for what it was. Maybe it wasn’t as obvious a visual cue as I had imagined. Experience taught me that when I’m not sure if something works, it means that it almost certainly doesn’t. 

Former time skip

First instinct was to add a clock, showing the time advance. But a few minutes barely show on a clock. Plus, it meant displaying the clock twice, once during the fade to black, and then on screen for the last seconds. The whole thing felt clumsy. Text was barely clearer and not more elegant. A few days passed without a good solution coming to mind, until I watched one of my old favorites, The Time Machine, directed in 1960 by George Pal, based on the novel by H.G Wells.

“The Time Machine” - George Pal

One of the most iconic scenes shows the inventor testing his machine. He travels slowly at first. Failing to see any change, he thinks of a malfunction, until noticing that the clock in the room reads over an hour ahead of his pocket watch, and a candle is shorter by a few inches. He then decides to push his luck and accelerates. Now the candle melts down in a few seconds, a snail races on the ground...The faster the machine travels, the crazier everything looks.  The director shows the time acceleration, and that’s what I had to do.

Clouds and waves parallax acceleration

Now in spite of having a sensible technical path to the effect, things rarely go as planned. For once though, concerns didn’t materialize. Following a principle explained by Into the Breach developer Matthew Davis, I built up the effect one step at a time, determined to stop at the simple possible solution. I started with a time scale value, ramping up as the screen fades to black, then back down on the fade in.

That value served as translation multiplication factor for waves and clouds. The parallax acceleration in the sky and on the ocean looked a lot better than I had hoped. After tweaking the acceleration curve and the timing of the fade, no doubt remained that this was the right way.

Final new time skip with animation frame skip

I was even tempted to stop there, unsure if the eye could register that the waves animated at normal speed. But the programming was simple enough, and I’m glad I tried. The waves skipping frames complete the look by adding the stroboscopic quality of real video time lapse. 

Then I applied the same acceleration to remaining animations, like the U-boat bow wake, the reflection of the sun, and clouds moving in front of the moon. It’s amazing how a simple idea can be so effective. The final effect gives me a lot more confidence in the torpedo sequence (and will benefit the deck gun attack). While still being turn based, the game now has more grounded and dynamic relationship with time, which is what games using time compression benefit from.

Ruling the World

Underneath the visuals lies the brain of the game. It turns all the parameters describing the current situation into variables, and injects them into equations which determine the outcome. The maths aren’t difficult; basic arithmetic and statistics that we’ve learned in sixth grade.

Tables from the board game “Ambush”. One of my favorites

The program determines the probability of any action or event from a set of main parameters. Then this roll is increased or decreased by a number of modifiers, which can be fixed, calculated, or picked from a table. It’s a proven system familiar to boardgames and pen and paper rpg fans. But boardgames must limit the number of parameters, unless they become so complex that they’re unplayable. In video games, we can be as granular as we want and simulate many nuances of reality. It’s and exciting prospect. However this comes at a price in development time, as I was about to learn.

I may have struggled with this more than any other aspect of development. There’s two pain points regarding so-called realistic simulations. It’s the tricky balancing act of building a set of rules and mechanics that feel “right”, in terms of playability, while remaining within the range of historical experience.

A precious source of information

First, even experts don’t always have hard historical data, and they don’t always draw the same conclusions when they do. Something as simple as the average probability of torpedo hits based on distance to the target can’t be documented accurately. In spite of the reputation of German commanders for detailed attack logs, many were incomplete or inaccurate. Additionally, the staggering loss rate of U-boats poked giants holes in the data, when patrol logs sunk with the boats. Consequently, the few documents compiling and analyzing this material are hard to find and partially reliable. 

Studying the field manual given by the Kriegsmarine to U-boat captains help understand U-boat warfare tactics

Keeping with the torpedo example, the range is only part of the equation. To get a more accurate figure on the probability of a torpedo to hit its target, you should add to this:

. The type of torpedo. Steam torpedos were faster, which increased their accuracy at long range.

. Periscope / surface. A good solution required precise measurements of the target’s distance, angle on bow and speed. The data resulted from observation, which was more difficult from the low vantage point of the attack periscope.

. Day / night. Measurements fed into the TDC depended on visibility, which made night attacks less likely to succeed.

. Sea conditions. Large swells washed over the periscope, hindering observation. Surfaced, the boat rocked and rolled in heavy seas, which impacted calculations, but to a lesser extent.

. Observer skill and experience in recognizing targets, and estimating their speed.

. Target speed and behavior. Zig-zagging was recommended in U-boat patrolled areas. By randomly changing course, the target could throw off the firing solution.

. Torpedo failures. Torpedoes were notoriously unreliable, particularly early in the war. The firing mechanism sometimes failed to detonate the charge, or the torpedo propulsion died, or its gyroscope would break and send it off course.

Data about the influence of track angle on target speed estimation errors

That’s only a few of the variables, which means that a good simulation should not only take them into account, but more importantly, do it in a way consistent with reality. For instance, we know that the track angle (the angle at which the torpedo hits the target) had a lot more impact on the result than the target’s speed.

I imagine that experienced simulation developers have access to more resources, like consultants and scholars. And they can rely on previous work. But being a U-boat fan at best, and working by myself on my first simulation, I find that this is one of the most difficult and time consuming tasks. And simulation mechanics being at the heart of the gameplay makes it all the more stressful. I mentioned that Atlantic ‘41 won’t pretend playing in the big leagues like UBOAT, but I still want the game to remain believable to fans of more serious games. 

UBOAT. The reference U-boat simulator

But sticking to real numbers, even when possible, can’t be the whole solution. The second difficulty in building the math comes from player’s expectation. 

Men in the U-boat service almost never got a fair fight, and a game set on offering a fully historical experience would make for an unfair and punishing game, in particular late war.

A few anecdotes show how little success crews had, when they managed to survive. Timothy Mulligan states in his book Neither Sharks Nor Wolves: “The history of the type VIIC U-boat in microcosm can be seen in the fates of twenty-five VIIC and VIIC/41 boats…one of their number sank an American destroyer and a British steamer and a second sank an American merchantman. The rest sank nothing, and only five even had the opportunity to fire torpedoes at targets.” 

“Neither Sharks Nor Wolves” - Timothy P. Mulligan

Add to this that by 1943, only but a few of the U-boat aces had not been killed or captured. Even they couldn’t escape the new detection systems and weapons available to the allies.

I knew early on that a U-boat simulation would have to be challenging; it’s one of the aspects that drew me to it. Last thing I want is for Atlantic’41 to play like a mobile arcade game. There’s something exciting in overcoming difficult odds. The hardest it is to hit a target, the better it feels when it happens. But there’s a limit beyond which it would only appeal to a handful of the most dedicated gamers. And only WW2 hardcore fans know the extent to which U-boats lost their encounters. 

The sinking of U-118 on June 12, 1943

I tried to find a balance that makes the player always feel on the edge, but without robbing them of all chances, like it was late in the war. I think the important is to get an experience that remains within the confines of what a U-boat fan would expect; it should be a tough, even a very tough challenge, without sinking to the un winnable odds that late war crews faced.

HMS Ark Royal listing. HMS Legion rescuing the crew

Besides torpedo hit and detection rates, I should mention damage. Patrol logs show the extreme range in damage inflicted to the targets. Mere merchant ships would sometimes refuse to sink, even after three or four hits. The opposite could happen. For instance the H.M.S Courageous, a 224 meters, 24,000 tons aircraft carrier capsized and sank in 20 minutes, killing 519 of her crew, after being struck by two torpedoes. And a single torpedo made the aircraft carrier H.M.S Ark Royal take water and list so fast that his captain ordered the crew to evacuate. Hours later, she finally sank, from that single torpedo.

You “might” sink HMS Hood with two torpedoes

The variations are explained by the fact that military vessels carried weapons, gun powder and fuel. A lucky shot igniting that combination could lead to devastating chain reactions.

I want the game to reflect these oddities. The damage is rolled on a table that covers a wide range of damage points. The roll is weighted so that both negative and positive extreme rarely happen. I like the idea that the player can expect average damage, but it’s never guaranteed. Bad luck can waste precious torpedoes on an easy target. As a flip side, the last torpedo of a bad patrol can sink a prestigious prey. It spices things up, and it’s historically plausible. 

I Feel Cheated 

Testing the math made me aware of a problem explored in several GDC post mortem and developers talks: probability perception.

As I was “playing” the game, several times I missed four to five hits in a row on a 35% hit rate. Even as high as 50%, the results felt skewed against me. So much so that I began doubting my code. After all, the Lua random function is not “true random”. To be sure, I programmed a loop which rolled 10 torpedoes at 50% hit rate, and compiled the results. 

Full moon nights make easier for the enemy to spot torpedoes

Several runs gave me suspicious reports, around 30% hits, which confirmed my doubts. I then increased the loop to 100, 1000, and 10000 shots. The higher the sampling, the closer I got to 50% hits.

I should have expected this. There was nothing wrong with the code. The probability of odd rolls remains high for a small number of them. Only over time do the numbers even out. Knowing that I could trust the algorithm, I played some more, and felt cheated nonetheless. As I mentioned, the phenomenon has been studied and documented by professional gamblers and game designers; we have an inherent bias toward victory, which makes us incapable of trusting odds.

Missed an easy shot

Even knowing about it, I couldn’t help but doubt the results, which shows how strong the feeling is. It’s the “why does the toast always fall on the wrong side?”, or “Why chicken always cross in front of the car?”. In both cases, the answer is: they don’t. But we tend to focus on the bad experiences, and see patterns where they don’t exist, in particular when they affect us negatively.

Sid Meier told in a keynote how he solved the problem: lie to the player, so that the results meet their biased expectations. In his games they resorted to several methods. They would display a lower rate than the one used in the code (i.e a 50% displayed rate would roll against 70%). Or they would weight the rolls to compensate for bad streaks.

GDC 2010 Sid Meier keynote: “Everything You Know is Wrong”

With all due respect for this legendary designer, I don’t want this for Atlantic ‘41. First, I don’t like the idea of cheating the player. If the odds feel stacked against them, I’d rather be open about it. The other concern is setting in motion a cascade of hidden corrections, which turn the rules into an incomprehensible and broken mess, in which you keep overcompensating for the exceptions created by the last patch. It’s hard enough to come up with balanced rules, so I think the simpler, the better.

I already explained in a past log why I didn’t want to show any numbers in the game. At least not the ones used for resolving events and attacks. This perception bias is another one. Hiding the stats avoids setting wrong expectations. But it shouldn’t allow the game to cheat or feel inconsistent. I’d like the player to build their own empirical estimate of their odds, built on consistent results over hours of gameplay, instead of being lured into the wrong mindset by numbers, either positive or negative. After all, a real U-boat captain couldn’t put a number on anything, he just got a feel for the risks he faced and his chances of success, acquired by facing many similar situations.

The favorite sentence of millions of gamers

There’s two kinds of gamers, which we can crudely described as the ones who think difficult games are off putting, and the ones who think a game can never be hard enough. Both views can be nuanced but if I had to make a choice, I would rather put myself in the latter.

But rather than wondering if a game is too hard, I think that a better question is: does the gameplay feel fair, the rules clear, and the outcome reliable? Players get frustrated when they don’t understand what they’re supposed to do to win, or when the game behaves inconsistently, preventing them from benefiting from what they learned. It’s the difference between being beaten square by a better trained fighter, or by one pitching sand in your eyes and kicking you in the groin.

Pretty much...

If the math works, it will produce consistent results, creating recognizable patterns that the player should be able to notice over time and take advantage of. Nearly always missing the target in storms tell you that such weather is too penalizing. Having your steam torpedoes often detected during the day tell you to keep them for night time. Tutorials, or rather a good old fashioned manual, will take part in teaching the player as well.

When video games had manuals

If it all works, the player should develop the same behavior that real successful U-boat captains adopted during the war, making the game a faithful recreation of the actual experience, if not in detail, at least at high level.

Testing will help fine tune the mechanics and rules, but I’ll need various types of testers; U-boat and ww2 buffs will apply what they know from history or other games and tell me if the game follows their expectations. And casual players will experience the game without preconceptions. Over time, the patterns they observe should teach them effective tactics, and their play style should evolve to match the advanced gamers. At least that’s the plan.

Darkest Dungeon disclaimer

Over the last years, games like Darkest Dungeon were introduced with short disclaimers warning about their difficulty, and explaining that it was part of the learning experience. Others like Tynan Sylvester’s Rimworld, even went as far as telling the player how to apprehend the experience, not necessarily as a mere game in which victory is the only objective.

As a player I’ve found this useful, if anything not to feel too bad when I kept getting whooped. I’m considering doing something similar for Atlantic ‘41, to educate players on how near impossible it was for a U-boat Captain to survive the entire conflict, and why they shouldn’t expect to win most campaigns. Not just that, but to make them appreciate the idea of fighting a superior force. 

Kaboom

I will close the log for now. There’s several things to talk about next time, before we get to what I expect will be the most difficult part of the design: programming the enemies artificial intelligence, and hopefully get to a point where we can finally play a full engagement in rough form.

More soon.