Posted February 09, 2024 by StephanRewind
I would lie if I said that I didn’t slack a bit during the Christmas break. Still, I progressed on the tactical chart, and on my understanding of where I think the game should go. A few nasty bugs needed squashing, which I like to do as soon as possible, when the code is still familiar.
The game so far
Additionally, a few controls and animations needed fine tuning. There’s a good argument for putting all the basics quick and dirty, before polish, but I like to go as far as I can with the task at hand. Putting a check mark on an objective allows me to better focus on the next section of the game. That’s not to say that I won’t come back to further tweak/add, but if I can limit this to an extent then I ‘m all for it.
Got rid of the bouncy dialogue box animation, which felt tonally wrong
Doing this gave me confidence in the 10 m/pixel tactical chart, which flows well enough that it’s best to put the 60 m/pixel scale on the back burner, and focus on the chart U-boat controls. No point in saturating the game with redundant features. Lean is always better.
Furthermore, I’d rather have one scale fully functional first, and then jump to the Torpedo Data Computer. I must get a sense of the complete combat experience as early as possible. Later on, if the need for an additional scale remains, there will be time.
The 60 m/pixel scale, to be done later
With combat being played in turns, it makes sense to control the U-boat from the chart, where the player gets a clear overview of the situation, and movement can be immediately assessed in the turn based context. The exterior view is great for immersion (and it’s essential to spot and tag ships), but that’s the extent of its role. it’s too unreliable for any other purpose. When it comes to situational awareness and tactical planning, the chart takes over.
Tactical chart
The icon wheel in place for the ships works well, so controlling the U-boat should use the same system. I spent time thinking about the best way to organize the orders around the icons wheel, and came up with two main rules:
1/ orders should be organized by function, and limit the amount of menu diving.
2/ when applicable, they should follow the same logic and flow as enemy ships.
The first rule implied that the I break down the orders in groups related to specific aspects of commandeering a U-boat. In my mind, engine power and heading are related, since they control the boat on the planar dimension. Orders relative to diving control the boat on the depth axis.
Command wheel for enemy ships
Regarding heading and speed, it can all be managed with one system. Once the command is activated, a faded U-boat token, similar to the ships ones, shows the projected position of the submarine at the beginning of the next turn. The course is represented by a line. The camera centers on the projected position. The controls are trivial. Left and right on the directional pad change the heading by increments of 10 degrees. Up and down adjust the engine power: stop, one third, standard, and full.
Course change
Based on the U-boat’s depth, the appropriate propulsion system is engaged. Surfaced, the faster diesel engines are used, and the game switches to electric motors when submerged. The speed results from three factors: the power level, the depth (and by extension the propulsion system used), and the U-boat type. So by pressing left/right and up/down on the pad, the player can simultaneously order engine power and heading, and see the result for that turn.
The captain gives the order
The chart presentation may feel abstract, like moving a piece on a board. So once the player is satisfied with the course, the A button validates and a dialogue box opens with the captain giving the order to the crew. It’s part of the fantasy, and I hope that this way the player feels that navigating the boat is the result of them, as the captain, giving orders, as opposed to something like playing chess.
Now to follow the same idea regarding diving. Except that in this case, up and down cycle through the depth, from surface, to periscope depth, and then down in increments of 20 meters. Once the desired depth is set, press A and watch the captain order his crew.
Ordering the dive
I’ve had a special order in mind for some time. To explain this I must segue into U-boat technology. Aboard a blind submersible, the depth of the ocean floor is a critical bit of information, for obvious reasons. Back in the 1940’s nautical charts already had water depth measurements, which crews partly relied on to determine their safety margins. It wasn’t a concern for open sea operation, much deeper than any U-boat crush depth. Even the Mediterranean can go as deep as 2000 meters, and the Atlantic Ocean averages 4000 meters, with abysses far below. The Battle of Atlantic was fought mainly in deep waters, as opposed to the Pacific, which is dotted with shoals, coral reefs, and various shallows that were poorly mapped at the time.
Numbers show water depth
However certain missions (mine laying, spy infiltrations) required U-boats, even in the Atlantic and the Mediterranean, to sail close to the coast, or through narrow straits, like Gibraltar. Other potentially shallow areas included Iceland and the Baltic Sea, or around Great Britain, (for instance if you were crazy enough like Günther Prien to try and get into Scapa Flow, which he successfully did). One remembers the scene in the film Das Boot where U-96, sinking into the Gibraltar strait, runs aground right before reaching crush depth, and the wonderful line from the Captain: “God threw a shovelful of sand beneath our keel”.
Das Boot
However rare, these high tension situations could make great gameplay, in part because of the technology involved; in shallow, poorly mapped areas, U-boats resorted to a device called the echolot, akin to a sonar, which measured the depth of the water. The emitter sent an impulse, which bounced back on the ocean floor toward the boat. Then the device calculated the distance based on the time elapsed when the impulse hit the receiver.
On June 27th, 1941, U-123 was depth charged for 11 hours and escaped by diving to 199 m, below the range of British depth charges
The drawback was that any enemy vessel in the vicinity could hear the impulse. And so the dilemma becomes: either dive blind at the risk of running aground, or take the chance of revealing your position, which, in U-boat warfare, can lead to catastrophe. Now in reality there was two devices. A silent one that could only measure up to 125 meters, and one that sent an audible impulse (a ping), for deeper measurements. This level of detail goes too far for Atlantic ‘41, so I’ll compound the two devices into one for simplicity sake.
The Echolot icon
The idea is to give the player the ability to use the echolot, with all the risk involved. It will be only necessary for advanced patrols in difficult, shallow coastal waters or straits, but the order will be available at all times.
The alternative is to look at the chart itself. I’ve added a water depth in the bottom right corner of the chart. The catch is that the chart only gives the sector's average and doesn’t inform on shallow banks. Worse: potential navigation errors mean that the information could be wrong. If you remember, I mentioned in a previous log how precise navigation required good weather for taking a daily astronomical fix. Which means that long stretches of bad weather will have consequences on the ability to dive safely in coastal areas and inside straits. In that case, it's up to the player to either rely on the chart, or risk the echolot.
Wassertiefe: water depth (Thanks to Nils for the help with German)
However this means one additional command to fit into the icons wheel. I thought the best was to bundle everything into a diving order, activated with the right directional pad (since left is for heading/power). Once the command is activated, Up and down on the pad cycle through the diving depth, while left asks for the echolot. However there’s a significant risk of the player activating the order by mistake, in particular when they’re not yet familiar with the UI. And considering the danger of its use, this could lead to frustrating mistakes.
U-boat orders
One thing that makes me mad is being punished for the developer’s mistakes, in particular confusing controls. It’s the duty of the game to protect the player from inadvertently making dangerous decisions or mistakes, either because the rules are obscure, the UI is unclear, or in the case of action games, the controls are clunky or unresponsive. It taints the experience with a feeling of unfairness and distrust in the game.
That doesn’t mean holding the player’s hand. Quite the opposite, I think it’s crucial to let them take risks and even make mistakes, as long as they were not mislead on the situation, the stakes, or by the rules. In other words, I love challenging games (and I’ll develop that in great detail in future logs), but only if they’re fair.
Real life ways of safe guarding against mistakes
On the other hand, I always felt that great controls, clear UI, and logical rules earn the trust of the player. This trust is vital to the success of the game, but it’s difficult to achieve. I mentioned how a polished interface addresses every detail, from readability, to flow and consistency. But that’s just one brick in the edifice. Not screwing the player over bugs, confusing choices, broken balance, cheating AI, or arbitrary rules is another.
The confirmation dialogue
In this case I can think of two ways to prevent the echolot order to be activated by mistake. They’re not mutually exclusive. First, add a confirmation screen. In fact, I think that every instantaneous and irreversible command in the game should allow the player to back out. It affects the flow of the UI, but it’s a small price to pay for piece of mind. I can’t count the games I cursed for not having a confirmation on Skip Turn. I don’t want that for Atlantic ‘41.
Second, take it out from the diving command, and give it a unique icon in a sub layer of the wheel. In other words, press right to activate ‘diving’, then press a specific direction to ask for a sonar depth impulse. The actual diving order would be part of this same sub layer, under its own icon. So, right for ‘diving orders’, then right again for ‘dive’. But this would add a step to every diving command, including the ones the player uses frequently. Instead, let’s have everything rarely needed under the same sub command. Something like ‘orders’. That way, diving remains immediately accessible on the first layer of orders, while echolot is protected as part of the sub layer.
The Chief Engineer announces the result of the Echolot
This leaves me with three more slots for future commands, such as ordering complete silence on board, or firing debris through the torpedo tubes as decoy (more on this in the future).
That may be more detail than you want to read. What I hope to convey is how much care I try to put into every aspect of the controls. It’s arguable that any number of solutions would work. But it’s worth weeding out the less elegant ones. I mentioned this in the past; the difference may seem negligible, but the stacking of dozens of minor nuisances amount to a miserable experience. I don’t know if I will succeed in making Atlantic ‘41 a game that the player can trust, but it’s always on my mind.
Calling the Echolot a second time skips to the result
One last example: since the ships ‘course’ icon is on the left pad, that’s where I put the heading/speed for the U-boat. On a subconscious level, I want to train the player’s brain in thinking “left is course”. In the same idea, under ‘orders’, the echolot is assigned to the right pad, because it relates to diving, which is on the same direction on the main layer of the wheel.
I can draw a parallel with button assignation in action games. Thoughtful designers try to give each button a consistent function throughout the game. Careless developers change buttons Willy-nilly depending on the context; for instance in an action game: on foot, left bumper is block, but board a vehicle, and that same button becomes brake, while the vehicle shield has been assigned to B. It would have been better to use B or the left trigger for the brake, leaving the shield on the left bumper. That way, that button remains associated to ‘protection’ in the player’s mind, both in an out of the vehicle.
Icons following a logic structure
The intent wasn't to do a lecture on control design, but this question is dear to me, because it’s at the core of the relationship between the game and the player; how you build the trust.
With that, enough with the chart. As the gameplay deepens, I will add more features. At this point there’s enough to control the boat, and it’s time to move on to the basic implementation of the third major component of the engagement gameplay: the TDC. The goal is to put in place all the building blocks for a basic combat sequence. I may briefly update on added features in the chart as they become necessary (like the potential 60 m/pixel scale), but I want to keep certain parts of the game under wraps for the player to discover.
I’ve gone in great detail over the implementation of the chart, so it might be a good time to change the lens and go back to broad concepts. I've been asking myself: how does one translate a complex real life, real time situation into a simple, technically limited, turn based video game sequence?
The concept of turns goes back a long time
The use of turn based may be misleading in the case of Atlantic ‘41, as it implies units activating (to employ the traditional wargame term) one after another during the turn; a ship moves, fires if needed, then it’s up to the next one, and so on. Even though I’ve enjoyed many games designed with that system, I was concerned about the way it represents battles as a sequence of actions, rather than an ensemble of simultaneous events.
The usual turn based works well when things occur in a rapid succession, like a skirmish. The turn order simulates units initiative; the quick ones act first, while the slower are forced to react. Naval battles involved large scale maneuvers, but they unfolded slowly, over hours. Quick reaction wasn’t a factor, and for the U-boat, initiative came down to the element of surprise, and to invisibility.
Atlantic Chase has an interesting system where the real position of a ship is unknown
One alternative was to treat all enemy ships as a single unit, taking their turn at the same time. But that’s a partial fix. If we consider that a turn is 10 minutes, and we let the U-boat go first, then the it must act before knowing what any of the ships will do. It’s like being blind for 10 minutes. If the ships act first, then it’s like the U-boat must watch the events unfold and then react after the fact, and that’s not much better.
Reading U-boat logs and wartime accounts, it appears that the U-boat always add the initiative. It was the aggressor, and it initiated the confrontation. But because of their slowness and vulnerability, U-boats had to remain one step ahead, intercepting enemy ships courses, rather than running after them. The game design needs to reflect that fundamental aspect of U-boat warfare.
Attack logs help to understand the nature of U-boat warfare
What seems a good solution came to me from “Into the Breach”, which I would rank as one of the best turn based strategy games I’ve played these past few years. From the authors of the revered “FTL”, it introduced me to the concept of delayed action. The idea is simple and elegant: all the enemy units announce their intention for the next turn. The player then gets a chance to thwart the enemy’s plans before they unfold.
Into The Breach
I think this system does a good job at simulating simultaneous events. Seeing in advance the enemy actions gives the player the opportunity to react to everything happening that turn, not just to one unit. It’s like a glance at the next turn. But before actions are resolved, the player must commit to their own decisions, which prevents them from exploiting the sequential nature of the traditional system. For instance, you can’t just wait to see if your forward tubes torpedoes will hit before deciding if you’re going to commit the aft tube. You can’t wait to see if you get spotted before diving away.
The enemy ships must also commit to their plans, and they announce them (at least the movement), but their actions are resolved after the U-boat’s, which simulates their initiative disadvantage, as previously discussed. In other words, once everybody is set on what to do, U-boat attacks and movement are resolved first, which could disrupt the enemy's actions.
Orders can be changed as long as the turn doesn't advance
It’s not a perfect system, because it’s impossible to represent a real time battle into a series of turns, but it feels more accurate and it's easy to understand in the context of Atlantic ‘41. From the player’s standpoint, all you must remember is this:
1/ The time is frozen until you decide to advance the turn. All units will follow their determined course.
2/ Almost all U-boat actions will also happen when the turn advances. So orders can be changed at will until then. (Except for a few exceptions, like the echolot, which gives you instant water depth information, and thus can’t be reverted. But these orders all have a confirmation message.)
3/ When the turn advances, actions are resolved, U-boat first. Whatever happens, ships must execute their planned moves and can only adjust their strategy on the following turn. So for instance if a ship detects the U-boat, it can’t fire depth charges on that turn.
Since we’re on the topic of the rules, I want to share another dilemma: how much of the inner workings of the mechanics should the player be exposed to?
Like many old school PC simulation and wargames fans, I started with boardgames, tabletop wargames, and pen and paper role playing games. They offered realistic settings, (somewhat) sophisticated narrative, and (sometimes) deep character interaction, at a time when rudimentary computers just learned to play Pong or Solitaire. As technology evolved, the balance of power shifted, and videogames now surpass their ancestors on almost every level, including realistic simulations and complex wargames. They even reinvent social interaction with online gaming and persistent worlds.
Ambush. Still one of my favorites
However, computer games have inherited their DNA from their analog parents, which is obvious in the way many PC wargames and simulations operate as a fundamental level. Below the surface, even high octane action RPGs still roll for hit percentages, evasion, damage mitigation, etc... characters still have stats, perks and skills. Loot and experience are still at the core of progression. Simulations still ask the player to balance resources and expenses. Under the hood, simulation and strategy videogames function like fast, automated boardgames.
Even a game like Total War has the traditional underlying maths
But even though mechanics are now managed by the computer, many designers still make the choice to expose them to the player. Item descriptions explain in detail all the mathematical stats, perks, bonuses, which allows players to calculate everything down to the digit. In-game encyclopedias document every feature and rule with extreme precision. I can see two main reasons for that.
The min-maxer dream
First, designers feel sometimes obligated to transparency, as to dissipate any suspicion of cheating or arbitrary outcome. Second, a large proportion of these videogame designers come from the same boardgame school, from which they developed the love for translating any imaginable situation in a set of rules, calculations, and statistics. The most obsessive and dedicated members of this group are referred to as min-maxers. No doubt that you’re familiar with the term that comes from their deep understanding of game systems, which they optimize to their advantage.
All Dungeons and Dragons players remember these
Now I wouldn’t consider myself a min-maxer. Far from it. But I must confess a love for numbers. I appreciate rules when they elegantly describe a situation and its resolution. There’s something appealing to the idea of understanding how a system works, and how to take advantage of its synergies and interlocking rules. But digging deeper, even the most basic games have rules. Sports have rules. They’re the essential framework to the enjoyment of the player, since they describe the challenge and define the conditions of success or failure.
Anyone who’s played even the most basic family board-game knows the thrill of the moment when an entire game rests on a specific die roll. It’s simple and effective.
This was the long way of explaining why I was tempted to expose all the statistics and mechanics of the game. Every calculation, odd, damage, statistics etc. But I’ve decided against it for a few reasons.
The first is practical; the Playdate isn’t exactly what you would call a friendly platform when it comes to reading, and I can’t see how anyone would enjoy studying walls of tightly packed numbers on its tiny unlit screen. In the end you have to compose with the limitations of the platform, and Atlantic’41 may already rely too much on text.
This is about as much text as the game should display at one time
Second, I’m concerned that showing the math changes the way people interact with the game. It’s difficult to ignore available information, so the instinct is to obsessively check every statistic, make comparisons, evaluate options, analyze the maths. It could turn the experience into a crunching numbers exercise closer to filling your taxes than commandeering a U-boat.
Looking at the moon phase over reading visibility stats
For instance, when selecting a target, if given the hitting odds, the player will browse every ship and simply choose the ones with the better odds, instead of understanding the factors that affect them. It shifts the focus to numbers, which become a crutch. It also turns the game into a very abstract experience which goes against the immersion. You don’t look for the moon in the sky to evaluate visibility, at the waves for how much concealment they offer to the periscope wake. You just select the best number. It would partly render moot all the efforts I've put into making the game a visual experience. My hope is that over time the player gets a feel for the best course of action by studying the lighting and weather conditions, the position of the target, and all the factors that a real captain had to take into account.
Available data
It’s not to say that they’re aren’t numbers, but they’re limited to the realistic available data. Wind, target speed and angle on bow, time, cloud coverage etc...But you don’t get any of the numbers that the game uses under the hood to simulate the world.
Finally, the problem with stats is that they slow down the pace of a game that is already slow by nature, in particular for min-maxers who won’t be able to resist their impulse of optimizing every decision. It turns a videogame into a board game, in which you crunch the numbers and read the rules, instead of enjoying the experience and immersing yourself into the world.
Das Boot: mood and tension
In conclusion, I think that the turn based system with delayed action, combined with a simple and accessible set of commands and limited statistics will strike the right balance for the game. I have other ideas about the end of turn sequence and how the resolution of actions will be handled, focusing on the tension and the mood, and hopefully enhance the feeling of being aboard a real U-boat, instead of playing a boardgame. But this will be for another log.
Next time will be dedicated to the implementation of the TDC, which is the last big interactive chunk of the engagement gameplay, before I tackle the end of turn sequence.
So as usual, more soon.