Last time I left you halfway through the implementation of the diving sequence, which is now complete, at least in its basic structural form. It can go through an entire dive, with the Chief doing the following:

. Announces the start of the dive.
. Gives flavor technical instructions to the crew.
. Calls the depth at regular intervals.
. Signals the successful end of the dive.

Where we were last time

Before going further into the plan for the sequence, in particular the various possible incidents, a few technical aspects of the implementation. In the previous log, I was concerned with the toll of real time bitmap rotations on the CPU.

The points making the pointer shape

But even before I could try that, it occurred to me that I didn’t need it; the gauge pointer is a simple flat shape, which can be drawn as a polygon. Turns out the SDK has effective geometry libraries, from 2D primitives to polygons. They render fast and manage dithering patterns in a way that allows effects otherwise difficult to achieve in bitmaps (more on that later). In fact, I love the Playdate polygons, without which I would have never been able to make the  various cloud systems for the exterior views. 

Polygon clouds

Drawing the pointer as a polygon lightens real time calculations, since the cpu doesn’t have to handle the rotation of every pixel in the image. All it needs are the rotated coordinates of the polygon points, from which a new shape is drawn. To my knowledge there’s no function to rotate polygons in the SDK, but that gave me the opportunity to brush up on my long forgotten trigonometry. 

20 points vs 1357 points to rotate (I counted them)

That method is the best of both worlds. It draws incomparably faster and it’s much lighter in memory (you store the coordinates of less than 20 points, instead of at best, every pixel of the pointer, or at worst all the pre cached variants). Not only that, but since the polygon is redrawn based on a limited amount of points, it preserves the shape’s integrity. The pointer looks always nice and sharp, instead of turning into a cloud of jittery pixels. 

Much cleaner polygon rotation

But the benefits don’t stop there. I was hoping to give a cast shadow to the pointer, to give it more depth, and reinforce the idea of a single light source coming from above the dial (see the previous log for more about the lighting in that sequence).

Doing this is trivial: all I need is a second polygon, offset by a few pixels from the main one. Since it’s translated after the rotation, it creates the illusion of a fixed light source.

On the right, the dithering of the polygon is unaffected by the rotation

Normally though, this would be an issue, as the shadow is dithered. Patterns cause all sorts of flickering when moved, which would ban the camera shake. But the beauty of polygons is they act as masks, revealing a fixed pattern; the shadow looks always perfect, regardless of any amount of rotation or translation applied, since the dithering is untouched.

I’m glad that I was able to make this work, as the pointer is the main focus of the sequence; the player’s gaze is fixed on it as they track the progress of the dive. And the rendering is so light that I was able to make the dive plane indicator rotate as well, with its own shadow, and ample cycles left to draw the dialogue boxes (and additional effects as you’ll see below), without coming close to busting the 20 ms cap to draw a frame (to maintain 50 fps). Note that the diving plane indicator is for flavor, but that secondary animation helps making the sequence feel more polished, in particular when the pointer reflects the changes ordered by the Chief.

The dive planes pointer reflects the changes ordered by the Chief

The most observant may have noticed that I changed the appearance of the depth gauge. It used to display the depth in tens of meters, to avoid three digit numbers. But someone from a group of Discord U-boat experts, who offered their generous help, observed that the gauge looked like the shallow depth gauge, which was another instrument that measured depth under keel up to 25 meters. The new gauge is closer to the real one, at the price of less readability. I find the trade off acceptable though, in particular because the Engineer calls the depth at regular intervals during the dive.

The new depth gauge

Anatomy of an Effect

I explained last time how I was counting on camera shakes for collisions and depth charges feedback. However it became apparent that it would be mere part of the solution; it required not only on additional effects, but a structure of events timed with precision.

In a previous log I went over how pauses were of great effect to emphasize an action or an event. And this goes for damage feedback. The viewer needs time to register the effects, to process what happened. Looking at various games and film sequences, I began to understand how visual effects are broken down into a sequence of events, each with their own timing and visual signature.

A camera shake alone doesn’t convey the accident

Taking the boat hitting the bottom as case study:

First, a split second, powerful visual cue, to mark the moment of impact. A white flash is known an effective; don’t reinvent the wheel. It works for shock, but doesn’t give the impact a sense of direction. I thought of how FPS solve this problem by overlaying a red shape on the side of the screen from where the hit comes. 

White flash to mark the impact

I drew a few triangle shapes, and animated them procedurally, with the amplitude of the animation dependent on the power of the impact. Timing is crucial here too. The shape appears instantaneously and morphs down concurrently with the white flash fading. This simulates the initial shock dissipating.

Polygons give a direction to the impact

At the same time, the camera shake kicks in, with the intensity fading as well. Timing was important too, so that the shaking lingers after the white flash and the vector shapes are gone, the boat settling at the bottom after running aground. However the timing was still off, the captain immediately reacting to the collision with his request for a damage report. It didn’t feel like he had time to process what just happened, and neither did the viewer.

Polygons animation plus white flash

Running aground should feel disruptive, and nothing better conveys disruption than stuttering and  flickering. 

I watched the various scenes in “Das Boot” where they get depth charged and noticed two things:

1. The lights onboard start flickering, and eventually go out under the violence of the shock.

2. There’s a moment of silence right after the worst of the attack, while the crew attempt to compose themselves. Then the light comes back, and they begin to assess the damage.

Lights flicker but the timing still imperfect

I prototyped the same structure: right after the impact, as the camera still shakes, the screen starts to flicker black, to eventually go dark. Then a pause. Even after the lights come back, I noticed how effective was an additional short pause, giving time to the commandant to recover before asking for the damage report.

Pause after the lights come back

Now the whole event had weight and meaning, albeit needing more clarity as to what actually happened, in spite of the spiky bits at the bottom of the screen. I tried having the commandant state that the boat hit the bottom, but it felt forced, like bad exposition dialogue. 

Instead I placed a short sentence after the screen goes dark. Normally I try to avoid text descriptions. However this helped to convey time passing before the crew gets back to their senses and begin to figure what happened; an homage to the silent movies text cards that I don’t dislike for Atlantic ‘41.

Final effect with proper timings

Of course sound, which I haven’t discussed, is a crucial resource. But I want to make sure that visual feedback alone does the job. Not only is this indispensable for accessibility reasons, but sound is often the fifth wheel on portable platforms. Whether the player is commuting, or playing outside,  and the ambient sounds cover the game, or they don’t want to bother people around them, there’s multiple reasons why they may have to play without sound on. I’ll still make every effort to offer impactful sound effects, but for the reasons mentioned, it would be a mistake to rely on them. 

Stronger impact when the boat is beyond control

This covers the practical aspects of the sequence, even though I’ll most likely come back for more effects illustrating the various incidents encountered during the sequence. Which leads me to the next topic.

A Plethora of Troubles

I’ll describe here my ideal version of what diving incidents could look like in the final game, knowing that at this point I only have a skeleton version implemented. I hesitate to go too far at this point, for two reasons: first, I’m concerned about the scope of the game, and my ability to finish it within my life time. 

U-664's crew abandons ship. August 9, 1943

But more importantly, it’s difficult to gauge of the impact of complex features on the flow of the game. There’s a point of diminishing return when adding features, in particular for a game destined to be played in short sessions on a portable console.

In this case, interruptions or incidents could put too much focus on the diving sequence. Yet that sequence is just one of several per combat turn. And combat itself is a mere portion of the entire game loop, which has the player managing the life aboard the boat, and navigating the various sectors during a patrol. And a complete patrol doesn’t even cover the entire campaign, which is comprised of many patrols linked together by rest and refit sequences.

U-625 depth charged by a Sunderland aircraft on 10 Mar, 1944

The game could become too heavy and cumbersome to enjoy, which would force me to go back and make difficult and painful cuts. But for the sake of this log, I’ll explain what form the diving sequence could take in its ultimate version.

Incidents are divided into four main groups. When an incident happens, it will be taken to its conclusion, with no other incidents occurring for that dive.  Here are the problems that can interrupt normal operation:

1/ Running aground
Hitting the bottom of the ocean stops the dive for obvious reasons. In a few cases, damage can result from the contact with the ocean floor, leading to breaches and flooding. This is more likely to happen during crash dives or when the boat sinks out of control. There’s also a chance of injuries due to people losing balance, banging their heads, or objects falling. After the initial shock, the crew settles the boat which sits at the bottom until surfacing. 

“Das Boot”

2/ Crush depth
Past 200 meters, the boat is subjected to immense water pressure, which can result in hull damage and flooding, and can cause other mechanical issues. The deeper the dive, the more likely something goes wrong with the boat, up to imploding and killing everyone onboard. Extreme depth can also lead to injuries when rivets pop under pressure and hit people.

A clock damaged by a rivet popped under pressure. (“Das Boot”)

3/ Failures from damage
These happen as a result of being hit by aircraft torpedoes or bombs, or ship guns and depth charges. Diving planes could get stuck into full down position, preventing the U-boat to stop its dive. Damaged pumps make surfacing impossible as they can’t flush out water from the ballasts. Hull breaches can cause flooding, which weights the boat down. Screws can get torn and cripple the boat. Several consequences: 

“Das Boot”

/ the damage prevents the boat from functioning optimally and reach the desired depth, but nothing worse. 

/ Or the boat gets out of control and starts sinking until the crew manages to stop it. Once the boat is under control and at neutral buoyancy, it’s stuck at that depth until repairs make surfacing possible. Sometimes, there will be no choice but to surface immediately (to vent the boat for instance). 

/ As the worst case, the boat keeps sinking beyond control, until it hits the bottom or gets crushed by the deep. If it’s saved by the ocean floor, it must be repaired to surface again.

4/ Freak incidents

These are weird, unpredictable incidents due to a faulty mechanical part, or human error. Like the failures from damage, they can have various consequences, from mere scares to U-boat loss, and anything in between. The difference is that these problems are much more rare and chaotic. Some of them are more difficult to fix due to their rare and bizarre nature. It could be something as simple as a wrench stuck into a valve, and yet hard to diagnose and fix before it’s too late. Freak incidents can be of human nature, including mental breakdowns and rookie mistakes; crew members endangering the boat by their reckless behavior or inexperience. 

Mental breakdowns are part of incidents (“Das Boot”)

As I mentioned in the previous log, I see the diving sequence as the opportunity to create these dramatic situations where the boat remains unable to surface for a long time. The fate of the crew hangs onto luck, and their ability to make the critical repairs before they run out of air or the atmosphere is saturated with carbone dioxide, or before the boat becomes irremediably stuck.

As the result of a mistake, or from enemy attacks, the boat can enter into a cycle of events that cascade into one another, which can lead to the situation becoming more and more hazardous as time passes. The suspense builds up as the crew enters a battle for survival, while the enemy sometimes negates any of the progress made with additional depth charges. 

Flooding aboard U-96. (“Das Boot”)

This sounds bleak and unfair, but that was the reality of U-boat warfare, and I would love for the game to translate these situations. From a practical standpoint, each turn would go through the efforts made by the crew, with the Chief making its reports, until either the boat gets back under control, or it’s game over. 

It may feel strange that the player doesn’t have any agency in this gameplay. They would just sit idle for a while, hitting the next turn command and watching the events unfold. But that also reflects the reality. If you remember “Das Boot”, which is similar to other cases I read about, the commander sits there, waiting for the Engineer’s reports. His job done, (or having failed at it, depending how you look at it), He’s now powerless. All he can hope for is to try and maintain order and prevent panic.

Batteries repaired aboard a Type IX boat

To be clear, the small incidents, easily fixed, will be the most frequent. U-boats were able to sustain heavy punishment for long hours. Major damage should be rare, but can’t be expected to be repaired within a few 10 minutes combat turns. In these cases, the convoy will run away, and the escort eventually leave the area, ending the combat sequence. The game will then switch back to the navigation/daily routine slower pace of one hour turns, following the same structure of subsequent rounds of repairs, until the boat manages to surface or sinks.

Damaged torpedo tubes could cause water to flood inside the boat. Here on U-505

That’s the plan for now at least. At the moment I have half of the events implemented: crush depth and hitting the sea floor. Failures and freak incidents are still to come. 

Damaging Numbers

It’s often the case that development doesn’t comply with the plan, in particular when it comes to the order in which features are implemented. I had in mind that U-boat damage management would come quite late in the cycle, but the diving sequence exposed its importance; unless you know what kinds of systems can be damaged, it’s difficult to code the possible incidents and their consequences.

A prototype of the TypeVII schematic view for damage maintenance

Vice versa, until you know all the situations featured in the game, it’s difficult to build an appropriate damage system. I can feel my lack of experience in these chicken and egg situations, how I struggle to figure out the most efficient blocks to build first.

Mechanical failures for instance; the equation to determine the likelihood of a failure depends on many variables that haven’t been implemented yet, like crew experience or U-boat type. And I may want to add other parameters later like the Engineer’s perks. So I need to come up with basic versions of the rules, which can work as is, but that can be expanded with additional variables. Problem is, the base variables may not work with features yet to implement. 

I get the sense that I need to level all the main features at the same time, even in incomplete form, and add new levers and parameters to play with one at a time. Then, over time, a puzzle will form, with the pieces interlocking properly. I realize that I must accept to have unfinished bits lying around for a long time before a game emerges from these chaotic snapshots. 

This goes against my nature, as I like to call something done and not go back to it. But cramming the dive sequence with tons of complex mechanics before I get a sense for the loop would be ill advised. Still, I was confident enough that crush depth and running aground would be part of the game.

The damage view in Silent Service 2

I’ll explain the latter, as a demonstration of the approach.

Hitting the bottom of the ocean wasn’t as dramatic as pictured in “Das Boot”, at least not always. The shock was softer on a sand bed than when colliding with rocks. In the film, dive planes are stuck in a full down position, which puts the boat in a steeper pitch than it would be in a controlled dive. They try to reverse the engines, but the submarine’s momentum, along with the fact that it gets heavier as it descends, make it collide the seabed with unusual violence. 

Depth charges

This situation is simulated in the game. For various reasons, the crew can lose control of the boat during a dive, resulting in a similar case. Whenever the submarine hits the ocean floor, the commander fist makes a contextual comment and asks for damage, which is given by the 1st Officer.

The Commander asks for a damage report

Damage is calculated as follows:

1/ If the boat was under control when it ran aground:
. There’s a 20% chance of 1 point of flooding (due to a breach in the pressure hull or any of the hatches). I’ll explain how flooding works in a future devlog.
. There’s also a 20% chance that a crew member suffered a minor injury. Same as flooding, more details to follow (of course these specific numbers are subject to change with play testing)

2/ If the boat hits the sea floor while beyond control:
. The chance of flooding climbs to 35%, and up to 3 points. Then any one of the following systems has a 10% chance of damage (only one system per incident)
Any torpedo tube
Ballast pumps
Fuel tanks
Screws

 Up to 2 members of the crew can suffer injuries:
Minor injury: 35%
Severe injury: 10%
Critical injury: 5%
Death: 1%

Damage report given by the 1st Officer

This can create suspenseful situations, with the tables turning on you when you thought everything was fine, and vice versa. Like in reality, hitting the sea floor, albeit unpleasant, can save the boat from certain destruction, giving the crew a chance to regain control of a desperate situation, and maybe repair and surface.

But if you take into account water pressure, resting on the sand 280 meters deep may kill you as surely as a well timed depth charge. Instant death may have been thwarted, but a new race against the clock starts for making the repairs necessary to surface. Take too long, and the boat could get crushed, or become too heavy with flooding for ever being able to rise. Or salt water could spill into the batteries, creating deadly chlorine gas. In this situation, the boat must surface and be vented before the crew dies of asphyxiation.

I couldn’t resist the homage to “Das Boot”

As I mentioned earlier, other types of incidents will be added as the game takes shape, but the priority now goes to building all the main features, for a basic playable loop.

Trying to figure all this out fills me with renewed admiration for master game designers like Sid Meier, who made complex games like civilization feel so clear and enjoyable for the player. But this is all good lesssons for the future, regardless of how it may feel at the moment. 

The complete diving incident sequence

Before I close here's a last minute change to the light flickering effect. I was concerned that it may look like a bug, so I replaced the pitch black screen with an overlaid image simulating an isolated light bulb off screen. This prevents the screen from turning entirely dead, and separates the text card.

The overlaid image

The lights don't all turn off

I’ll end the log here and save the deck gun attack sequence for next time. We’re finally due for action.

More soon.