I’ve had a strange few months; a rather long trip abroad, personal stuff, and annoying code maintenance and clean up stalled the project. It’s nothing unusual, happened on long projects, and this is my longest to date. That explains the delay for this log. 

Ordering a deck gun attack

I streamlined the logic, got rid of redundant code, and laid the foundation for easier implementation of new features. It’s the most complex project I ever did, and I don’t want to paint myself into a corner with a structure too rigid and difficult to scale. Doing this now, before the game gets too large, will save me a lot of time later on. One thing is certain: a real programmer would have a heart attack at the sight of my spaghetti code. But you learn as you go. Hopefully the next one will be cleaner. 

I find that setting up small achievable daily steps mitigates the feeling; I focus on one thing at a time and try to block thoughts about high level objectives. Varying tasks also helps; drawing assets or making sound effects, even if they’re not immediately useful.

The reference 3D model

Turns out I needed the deck gun sprite for the surface attack sequence, which was a welcomed diversion. The first challenge was to find an adequate reference. U-boat naval guns are complex pieces of machinery, with lots of unusual overlapping shapes. This makes them difficult to draw, in particular under the right perspective. And there aren’t many quality photographs available, let alone from the needed angle, right behind the gun (safe to assume that these guys had something else on their minds than taking pictures.)

Luckily, I was able to find the exact type of canon on a 3D marketplace. And yet reality doesn’t always look the best; even the high resolution 3D model is barely recognizable as a cannon from this point of view, and it doesn’t make for a pleasing shape (granted that’s not its function).

Hard to see a canon from this perspective

Now to exert the right amount of artistic license and find the balance between historical accuracy and effective visuals. First thing was ditching the sights, which occluded the barrel. The barrel itself was increased; the realistic scale felt tiny under that perspective. 

The real gun looks weirdly off balanced, with large parts weighting on the left side. Asymmetrical designs are interesting, as long as they maintain an adequate level of balance. I tried to find that sweet spot, where the gun doesn’t stray too much from what the purists would expect but looks “cool” enough for everyone else. 

From the reference to the game asset

There was also the question of size: making the gun an impressive presence but leaving enough space between the barrel and the horizon line. One concern was the impact of that additional large sprite on the CPU workload, in addition to the smoke effect (more on that below), in particular on the already demanding exterior view. But a few optimizations and tricks allowed me to remain on target, around 50 fps with rare dips in the mid 40s.

Rapid Prototyping, Not

One of the aspects that drew me to the Playdate turns out to be its main problem. Namely, old school development. Unless you use Pulp, which imposes too many limitations for a game like Atlantic ‘41, it’s hands on; everything needs to be coded with a limited (and I don’t mean this in a negative sense) set of functions: draw an image, or a polygon, play a sound, draw some text etc. And all the logic is taken care the old fashioned way, with tables, operations, conditions... and even though we used to code at a lower level (Assembly in my case back in the 90’s), in principle you get the same advantages and disadvantages. 

Failed hand drawn smoke

On one hand, there’s not many closed box shenanigans, on which you don’t have control. The flip side, you don’t benefit from node trees, asset drag and drop, and other animation tools making prototyping a breeze. I felt this in particular as I was trying to make a gun smoke effect. 

Coming from a 16 bit background, my first instinct is to draw effects frame by frame, as you would do in traditional animation. But with a few exceptions, this hasn’t worked for me on Playdate. Unless you draw simple flat shapes, 1-bit rendering is hard and time consuming. You deal with evolving dithering patterns, either to simulate lighting or opacity. Simple shapes like the ocean waves can work, but they’re the exception.

A terrible, quickly abandoned attempt with polygons

When it comes to more complex animations, like smoke, it’s hit or miss for me, and more miss than hit. I don’t have the skill or patience to pull off this work in 1-bit, and my sprites tend to look stylized (not to say cartoon), which isn’t the direction set for the game. 

Unless you can quickly paint individual frames with evolving dithering, the animation feels choppy and unfinished, which, combined with the relative simplicity of the drawing quality, makes hand drawn animation stand out like a sore thumb.

Starting from touched up real live footage

To be fair, I could animate in Blender, and use custom shaders to render in 1-bit. But this introduces a whole other set of challenges. In particular, you don’t get pixel perfect control, which I find important at limited resolution. My smoke sprite will fit in 100 square pixels, at which diffusion and other  traditional conversion algorithms don’t always yield good results. Not to say that I couldn’t program dedicated shaders to force my own dithering patterns, but, considering my limited Blender knowledge, the amount of upstream work seems counter productive.

Final smoke animation

Over time, I’ve developed a technique where I combine hand drawn  rotoscoped shapes on individual layers in Photoshop, which I use as masks for dithering patterns. These dithered shapes, moving and morphing, blend with the use of multiply (or screen) mode. This is quite the hassle, as it involves tedious frame by frame work on each shape.

The animation must then be imported and tested on platform, with often disappointing results. I dream of a 1-bit animation tool that would allow to do this work with the convenient features of classic video editing software, and send the result in real time on Playdate. I’ve considered writing it, but I’m slow enough as it is with the progress on the game without getting deep into frontend development.

Barrel recoil added. The animation still lacks energy

But somehow I always come back to that idea, as it would allow to focus on drawing and animations, while leaving the heavy lifting of shape transitions and dithering to the Playdate. And you could even imagine generating the required shapes and patterns at run time, instead of saving rendered frames, thus saving storage space on the device. 

Final fire animation with smoke, muzzle flash, barrel recoil, white flash, and camera shake

But I digress. In this case I ended up rotoscoping over a combination of two smoke puffs clips. An effective trick was to translate the sprite, as if the smoke was drifting away in the wind. Since I already have a wind force parameter (from previous work on weather), it was easy to hook it up to the speed at which the smoke moves. I noticed that even slow translations help to give a much smoother look to animations, as additional frames result from the blending of the smoke with the background.

A Double Edged Sword

Studying U-boat deck guns, I learned that they were medium caliber cannons, with decent power and fast rate of fire. An experienced gun crew could fire between 15 to 18 rounds a minute. A type VII submarine (by far the most common), carried a reserve of 220 rounds. This means that in game, the crew could exhaust 180 shells within a 10 minute combat round. 

Now this poses several problems. First, no one wants to sit there for 10 minutes watching the gun fire dozens of rounds. Second, it seems weird to let the player spend most of its ammunition in one single combat round (in particular since the game is not in real time, and it’s a simulated 10 minutes). It’s difficult to find proper accounts of the usage of deck guns aboard U-boats. But it doesn’t seem likely that they would spray the target Willy nilly without concern for efficient fire and saving ammunition.

8.8 cm SK C/35 naval gun shell

And there’s the question of retaliation. Around 1941, the allies began to equip their vulnerable merchant ships with deck guns of their own. Firing from a higher, more stable vessel, they had better odds of hitting the U-boat than the other way around. U-boats, lower on water, were at a disadvantage. Quickly, it became obvious that U-boats often lost a deck gun engagement, which motivated the Kriegsmarine to remove all deck guns from their Atlantic boats from June 1943, as more Q-boats (decoy freighters equipped with hidden deck guns) lured them into lethal skirmishes.

The 6-inch gun, main defensive armament of a merchant ship

The game already has a system of hidden weapons. When attacking a merchant ship, the player doesn’t know if it embarks a concealed cannon. In this situation, one can imagine that if unspotted, the U-boat would get the chance to fire a number of rounds before the opposing crew has the time to scramble into action. Then combat would turn into a fast evolving, chaotic exchange of fire, where a lucky shot from either side could turn the tide.

The 1st Officer gives the firing order

For the game’s purpose, I needed a system that grants a slight edge to the U-boat as they surprise the enemy, and then give a retaliation opportunity to the target, thus informing the player that they’re not defenseless. At this point, the player can decide if they want to push their luck in a subsequent combat round, or, as it’s wiser (unless the target is unable to keep fighting at the end of the first exchange), break off the attack and dive to safety before things go sideways.

Given all these various requirements, I came up a system:

When ordering a gun attack, the commander must commit 50 rounds (or whatever is left) on a single target for that combat round.

Shelling commences

When the gun attack sequence starts, the cannon is centered on the target, ready to fire. For various reasons, but mainly clarity, I’ve decided to only display the targeted ship during that sequence.

Shelling commences, with every shot fired two seconds after the previous one hits or misses. A shot spends five rounds, so that the player only has to watch ten shots. In other words, five shots are combined into one. successful hits are shown as little explosions on the target, from one to five per shot. The target also blinks. I don’t love this videogame convention for a simulation, but it’s a clear visual feedback understood by many players. A miss makes a splash in the water. 

The time it takes for shells to cover the distance to the target is simulated

Sound will be a big component of the effect, and part of me wants to get it in as soon as possible. But I’m not yet at a point where I have a solidified enough idea of the sound direction for the game, nor the experience to produce the quality I’m hoping for. I’m afraid of doing too much throwaway work, and stalling the project to get a good grasp on sound doesn’t seem right either. Still, I realize that you can’t treat sound as an afterthought, so the moment may come soon when I must attack the problem heads on.

I’m also considering implementing place holder sound, until I’m confident enough in my abilities to produce the final assets. It will allow me to at least figure potential memory, performance, or timing issues.

Reporting damage of the attack

At the end of the sequence, the 1st Officer gives a sum up of the attack, with the number of hits and the damage sustained by the target. Any decisive hit (sinking the target) signals the premature end of the sequence, with the 1st Officer congratulating the gun crew.

Once all 10 shots (50 rounds) are fired (or the crew runs out of ammunition, whichever comes first), if the target is armed and has the ability to fire (it’s not disabled or sinking), it has a chance to retaliate a number of shots, based on its class and armament. 

Running out of ammo

From civilian ships, these rounds have a slightly lower chance to hit, accounting for the fact that even though they fired from a better position, freighter guns were manned by poorly trained civilian sailors (sometimes even passengers). However, they can still inflict severe damage to the U-boat and the crew, fully exposed on the deck. 

Retaliation by warships is a lot more lethal, as they can pound their enemy with high caliber cannons at a high rate of fire, manned by seasoned crews. If the U-boat has a decent chance against a freighter, it will be lucky to survive one combat round head to head against a destroyer. 

Rare outcome against a warship

The Chief then gives a damage report, which can impact the hull,  deck gun, anti aircraft gun, periscope, torpedo tubes, dive planes, fuel bunkers, rudders, radio, bilge pump, hydrophone, diesel engines, or electric motors. It can also create leaks, which flood the boat every turn. I will explain the consequences of every type of damage in a future log. Any hit on the center section of the boat can harm or even kill a member from the three men gun crew, as well as the 1st officer in command of the attack.

A ship in critical shape can’t organize its defense. Time to seize the opportunity

That system gives a bit more weight to the deck gun attack. It gives the opportunity to disable the target before getting fired back at, but only if able to land a few good hits. The system also simulates that tense moment when the crew discovers that the target has offensive capacities, but lets the commander decides if he wants to pursue the attack in a successive round. From a visual standpoint, the rate of fire is close to real time, which gives a good sense of what a real gun attack would be, albeit condensed.

Where is The Data?

It’s difficult to gather reliable data in large enough quantities to devise realistic calculations for hit percentage and damage. Deck guns were used marginally, even at the beginning of the war, and almost always on defenseless merchant ships. It’s close to impossible to know the effect of a U-boat deck gun attack against armored warships, because commanders knew it was suicidal to get into a gun fight with them.

British sailors during a deck gun drill

I found a few accounts of U-boats unable to dive, driven to the last resort of using their gun against escort vessels, and it was almost always over quickly. No reliable statistics can be drawn from these rare engagements. However, we know the factors coming into play when calculating hit percentage:

Range is the main one, for obvious reasons. The deck gun can reach a theoretical distance of almost 12 km, but it was barely effective beyond point blank range. Accounts tell that guns on larger escort ships were able to hit about 50% of their shots at 1000 meters. But their cannons had better targeting systems, and they fired from a more stable position. 

Loading a deck gun aboard a merchant ship

This brings us to the second important parameter: weather. U-boats constantly rocked on anything but calm waters, which made targeting all the more challenging. Other contributing factors include visibility (harder to hit at night), target speed and size, and crew experience (or rather what I call cohesion, but I’ll come back to this important distinction in a later log). 

I use spreadsheet editors to visualize the math. Here, base hit rate according to distance to target

The great thing about computer tactical simulations is that complex equations, taking into account many parameters, remain instantaneous and invisible to the player, as opposed to board games, where difficult rules can slow down the game and generate mistakes. For instance, in Atlantic ‘41, roll modifiers are calculated through linear interpolation, instead of jumping values at defined thresholds, as it’s the case in boardgames tables and charts.

This signals the start of retaliation fire

The player may not register the most subtle rules consciously, but after a while they may feel them, and even take advantage of them with experience. For example, I programmed the hit rate to increase over the duration of the deck gun sequence, simulating the men fine tuning their aim; one little detail that may have a critical impact at the right moment. 

But something remains clear: the usage of the deck gun attests of its poor effectiveness, as it was almost always trained on isolated, crippled ships, to finish them off and save precious torpedoes.

The size of a torpedo next to the deck gun helps understand its destructive power

In terms of damage, the typical 88 mm deck gun was a powerful weapon in theory, but it faced large ships, sometimes armored. It took many lucky shots to sink a freighter like the Liberty class. 

With this, I must use my best judgment to come up with a sensible equation. What matters is for the gun to be much less powerful than torpedoes. For reference, the deck gun fired a shell weighting about 12 kg, while an electric torpedo carried a 250 kg warhead. That’s close to 25 times more explosive power, even though a fair comparison of the energy produced must take into account the much higher velocity of the gun projectile (50 km/h versus 2500 km/h).

The distance to the target determines whether the crew can see its armament

Besides, a torpedo creates a large breach into the hull below the waterline, while the gun scatters damage across the emerged part of the target ship. A shell could theoretically start a fire in the ammunition depot, and create a chain reaction, but that’s one shot in a million.

Most records show that it took scores of gun shells to do the job of a single torpedo. I found testimonies often mentioning more than 50 shots fired at an already torpedoed ship, and it would still not sink.

Thankfully, it’s a miss

Like for every other aspects of the game, this is a mere starting point; play testing and feedback from U-boat experts will help fine tune what happens under the hood. The goal is for the game’s deck gun to have limitations comparable to its real counterpart, so that players will naturally draw the same conclusions as real U-boat commanders, and limit its use to similarly low risk encounters.

Retaliation hits have a similar graphic treatment to what I did for when the boat runs aground. The intensity shows the difference between superficial and major hits.

The gun must only be effective when spending multiple shells at short range, and the U-boat must quickly feel overpowered in a surface battle, because of its less stable position on water and its lack of protection. As much as it would be fun to take down a battlecruiser with the deck gun, this won’t be possible in the game, even if somehow the boat had time to fire its entire stockpile of 220 rounds (which it won’t have).

The direction of the impact hints at which section of the boat was hit

A Degree of Uncertainty

Now if you’ve followed my logs, you know that life aboard a U-boat was hazardous at best. I wrote about how minor diving incidents could turn into catastrophic situations. Operating a complex and unpredictable machine like a U-boat was dangerous in itself, but the added stress of battle made any procedure a challenge, even for the most experienced and skilled officers. And I look for every opportunity in the game to convey the constant risk of a fatal blunder, and the impact of luck on the lives of these men.

Oops...

A few sad and interesting stories about deck gun attacks offer a chance to explore that idea. The most terrible, and more common than one would think, describes sailors forgetting to remove the waterproof muzzle protector in the heat of battle, resulting in the gun barrel to explode, injuring or killing the operators. Failing to secure back the muzzle cap before diving would have less severe consequences for the men (except an uncomfortable exchange with the commander), but could damage the gun and even make it inoperable for the duration of the patrol. 

Weather could be a serious obstacle to using the deck gun

Because of how little the boats raised above water, the deck was often washed over by breakers, even when surfaced. The tower wasn’t high enough to offer decent protection against the wrath of the North Atlantic, especially during winter storms. This made surface attacks (torpedo or gun) difficult in rough seas. Many men failing to secure themselves to a life line have been lost at sea. In the game, the possibility of a crew member thrown overboard rises in bad weather; a fact that any good commander will take into account before ordering a surface attack.

From that picture, easy to imagine how dangerous the deck was in bad weather

I haven’t implemented all these scenarios yet. My hope is that these rare events help to attenuate the rigid structure of the game, where every section follows a predictable sequence. 

Something important: I don’t mind specific incidents being so rare that many players will never encounter them; there’s something magical about being surprised by a game you thought knowing through and through, even after dozens of hours of playtime. These moments reinforce the sense of a living, open ended world, where anything can happen. The rarest they are, the more precious they become in the player’s memory.

The result of firing the gun without removing the waterproof muzzle cap, here aboard U-105, May 23, 1941.

But this comes at a price, with time and effort spent on features only ever seen by the most dedicated players. I’m still at a stage where I need to focus on getting the core loop functional. Spending too much time in implementing many rare exceptions in one part of the game may hurt the others. My plan is to go over the various parts of the game in multiple passes, each time evenly adding a layer of exceptions and details.

I understand that this log was a long time coming, but I should now be able to get back to my regular schedule of an update every six weeks. Next time will have us come back on a few of the recent improvements I made to other parts of the game, and discussions about u-boat damage and crew cohesion. After that, if all goes well, we’ll get to fire torpedoes; a major moment in the life of any submariner, real or imaginary. I’m a bit anxious about the stakes of that sequence, but excited as well.

So as usual, more soon.