Hello Everyone, both new fans and those of you that have stuck with us over the years!

It’s been an incredible month for us and we have been watching all of the coverage videos that have been put out with the same intensity you guys have! We’ve been taking on what people say and are genuinely excited to have people playing this labour of love.

Anyway, now what you all came for. Today is the day we finally stop keeping you in the dark and reveal the scheduled release date. We’ve been impressed with the people on Discord tallying all the dates that we’ve said no to, but given we’ve changed the date in the last few weeks, that effort was futile (As most of us are European-based, Noah and Ben kindly reminded us that we should avoid certain dates).

Sea Power | Naval Combat in the Missile Age releases to Early Access on November 12th

Early Access Approach

Sea Power will be entering Early Access with a broad amount of content, namely:

• Over 20 Scenarios: Including both historical and fictional encounters
• Steam Workshop Support: Share missions with others and try to do better than your friends
• Mission Editor: An intuitive and flexible tool to recreate any conflict of the 60’s to 80’s Cold War era around the entire globe
• Massive Cold War Arsenal: over 150 naval units, more than 60 aircraft, 130 weapon systems, and 50 different ground objects
• Dynamic Campaign (Alpha): An evolving theatre-scale campaign that we target adding in Q2 2025, with improvements and polish added throughout our Early Access development phase. This will be linked to Steam Workshop so that you can create and share new campaigns too

We’ve chosen Early Access to get this labour of love out there, so that it can support its own continued development, and to get input from you! We have a lot of exciting plans for what we want to achieve over the coming months, especially with the dynamic campaign system. There will be more units coming and improved AI enhancing the game even further.

What we’re up to in the next Month

In the last week we’ve got Steam Workshop integration working, so you will be able to share mission packs from Early Access release day. There are already some tremendous mission packs going up from the guys who have been making YouTube videos, so you can put your money where your mouth is and show them how much better you’ll be at their scenarios! During EA, we will expand this to other aspects of the game so that you guys have an incredibly flexible world-scale sandbox to play in.

In the next month we are going to be focusing on preparing everything we can for Early Access launch, polishing the mission editor, tweaking behaviours and improving UI. We are listening to your comments and watching the videos too. We have also added new tools for managing the vessels in your formations in the last couple of weeks, in direct response to helpful community feedback. We also plan to get proper station behaviours into formations before you get your hands on the game.

We look forward to seeing as many of you as possible joining us and enjoying our hard work, now in just under a months’ time.

Game Recap for Newcomers – Dynamic Campaign, Strategic Depth, and Immersive Cold War Realism

For new players who have recently joined our community, we thought it would be useful to give a quick recap on the scope of Sea Power: Naval Combat in the Missile Age.

The game brings a mix of strategic and tactical depth in realistic naval engagements across multiple global theatres including but not limited to the North Atlantic, Persian Gulf, Gulf of Tonkin and the Mediterranean. Players will control ships, submarines, and aircraft, balancing the needs of local tactical combat missions and strategic theatre-scale operations.

The game’s attention to detail and historical authenticity includes advanced ship and weapon physics, sensor modelling and dynamic weather systems, all combined with richly detailed 3D graphics that bring the Cold War Gone Hot scenario to life. The entire planet is your combat playground – so our hope is to provide you with a near-endlessly replayable, mod-friendly, experience for many years to come.

Our small but super hard-working team have accumulated many years of naval simulation game experience. Our experience with designing the core gameplay of Cold Waters (and modding it until it very much broke!) has heavily influenced how seriously we take the quality and polish of Sea Power.

Get ready for an adrenaline-fueled Cold War experience and thanks for joining us on this journey!

The Triassic Team (Nils, Martin, Mek, Ivan, Daniil, Ben, Matt, Noah, Victor and Ian)

We really need to thank all of you for your incredible passion and support for what has become a massive project over the last few years. We know the wait has been longer than you anticipated, it’s been a long time coming for us too! Thank you for sticking with us and we can’t wait to get the game into your hands very soon!

To celebrate today’s announcement of the November 2024 release, we have partnered with the incredibly talented J.P Ferre (after obsessively watching his DCS content) to prepare this all new ‘Release Announcement trailer’. All the footage is recorded in the game, and we hope after the little teaser last month it is a fun sneak peek of what’s around the corner.

Early Access Approach

Sea Power will be entering Early Access with a broad amount of content, namely:

• Over 20 Scenarios: Including both historical and fictional encounters
• Dynamic Campaign (Alpha): An evolving theatre-scale campaign that will grow throughout our Early Access development.
• Mission Editor: An intuitive and flexible tool to recreate any conflict of the 60’s to 80’s Cold War era around the entire globe.
• Massive Cold War Arsenal: over 150 naval units, more than 60 aircraft, 130 weapon systems, and 50 different ground objects

We thought long and hard about Early Access, but we hope that it will allow us to foster continuous improvement together with you in this amazing community, with regular development updates and community feedback shaping the game’s future.

It would really support us if you could wishlist us on Steam, if you want more informal updates come and join us on MicroProse’s official Discord [link]. We tend to chat on a less broadcast basis there, and some of you might enjoy the nerdy places the history corner explores.

It’s been massively important for us to ensure a stable and content-rich experience from Day 1 of Early Access. We really hope that the Mission Editor in particular allows your creativity to go wild (Steam Workshop integration is a planned feature, we want you guys to share your missions!). You’ll be able to create your own ‘take’ on historical Cold War era encounters or simply recreate famous battles from beloved Hollywood blockbusters. One Ping Only Pleash Vashilly!

We will have a wide array of pre-made historical and fictional Scenarios to dive into this November, with an early ‘Alpha’ version of the Dynamic Campaign also available for early playtesting and ongoing feedback.

November Roadmap

On day 1 of Early Access launch, we are going to share a production roadmap which will outline upcoming features and content for the Early Access period. It will cover off both short-term, mid, and longer-range plans. Our ongoing development will incorporate your ongoing feedback, while driving towards our intended feature goals.

Game Recap for Newcomers – Dynamic Campaign, Strategic Depth, and Immersive Cold War Realis

For new players who have recently joined our community, we thought it useful to give a quick recap on the scope of Sea Power: Naval Combat in the Missile Age.

The game brings a mix of strategic and tactical depth in realistic naval engagements across multiple global theatres: including the North Atlantic, Persian Gulf, Gulf of Tonkin and the Mediterranean. Players will control ships, submarines, and aircraft; balancing the needs of local tactical combat missions and strategic theatre-scale operations.

The game’s attention to detail and historical authenticity includes advanced ship and weapon physics, sensor modelling and dynamic weather systems, all combined with richly detailed 3D graphics that bring the Cold War atmosphere to life. The entire planet is your combat playground – so our hope is to provide you with a near-endlessly replayable experience for many years to come.

Our small but super hard-working team have accumulated many years of naval simulation game experience, and our experience with designing the core gameplay of Cold Waters (and modding it until it very much broke!) has heavily influenced how seriously we take the quality and polish of Sea Power.

Get ready for an adrenaline-fueled Cold War experience and thanks for joining us on this journey!

The Triassic Team

The entire team of Triassic Games wishes you a fantastic start into the year 2024 also on behalf of the crew of this Orel carrier:

Here some screenshots from the Kiev airgroup attacking a small US escort group:

We want to do some more regular screenshot and video updates of the progress of what we’re doing and apparently “News” are the most appropriate way of doing so as we cannot embed screenshots in forum postings as it seems.

There will be more dev diaries coming as well but we want to push some news with less text and more screens as well! Hope you like it!

We’re trying to be better at dev diaries and we hope you appreciate the info. Today we will be talking about aircraft in Sea Power and how they work behind the scenes.

The first thing to say is that Sea Power is not a flight simulator, it is focused around Naval Warfare in the Missile Age, but aircraft are a vital component of that. Because of that Sea Power does not give you direct control of flying individual aircraft like DCS or Flight Simulator but instead allows you to task single aircraft or formations to complete objectives and the pilots and squadron leaders will sort that out for you. Because Sea Power isn’t a traditional flight simulator we are able to play a little bit fast and loose with the physics of the aircraft that you see in the sky, which is sorely needed given the number you might have!

Flight Model

A traditional flight simulator implements a flight model with normally 6 degrees of freedom and will use complex analysis methodologies like the Blade Element Model (X-Plane famously uses this method) which I barely remember from University. These methods produce reliable and interesting flight dynamics but are computationally quite intense! Here for example we can see the model for a single element of a blade, imagine doing this for 40 to 50 elements per aircraft!

To save your computers from a fiery death Sea Power instead mainly (but more on that in a moment) implements a 3 Degree of Freedom model. Happily in the team we have access to people who have been trained in both Physics and Air Vehicle Systems, if you saw our interview with Subsim a number of weeks back we mentioned how nice it was to have a variety of backgrounds in the team and this is one of the places where this really really helps!

The model itself is based on the one described in this paper by Dr. Lesley A. Weitz and allows us to have a simple but rapid simulation for most of the flight envelope. The model allows us to provide control inputs based solely on Altitude, Heading, and Velocity values which means we can skip the weightier implementations using Unity’s physics system.

Additionally, as Dr Weitz has been kind enough to provide us with a set of control laws and dynamics in a set of pseudo-code algorithms a lot of the significant work is done for us, this gives us a solid base on which to build.

Part of that building has been implementing semi-realistic thrust and lift modelling to our model, at the very core of this is a model of the atmosphere. Sea Power makes use of the International Standard Atmosphere (ISA) as defined in this resource kindly provided by NASA. The ISA defines how the atmosphere changes around us and helps explain why the outside air temperature at 30,000 ft is significantly below 0C.

Alongside the temperature the pressure of the atmosphere significantly reduces with altitude, dropping from approximately 101.3 kPa at sea level to near 0 kPa at 30000m. Because the atmosphere nearly follows the ideal gas laws the density of the air reduces at the same time, this allows us to model the impact of altitude upon our aircraft.

Now for those of you that are familiar with this stuff I apologise but for those that aren’t welcome to the wonderful world of aerodynamics, operational analysis and propulsion physics. It almost makes me nostalgic for University again. Density has an important impact on our aircraft in two primary ways.

The first way is Dynamic Pressure, dynamic pressure is a measure of the energy in the air that impacts upon something, the force you feel pushing against your hand out the window of a moving car is Dynamic Pressure. We calculate it as dynamicPressure = 0.5 * density * velocity * velocity and it is important as both the Lift and the Drag of an aircraft depend on the product of dynamic pressure and lift and drag coefficient respectively. Fundamentally what this means is that the faster you go and the higher the air density the more lift and drag you get out of an aircraft.

The second way drag impacts an aircraft is in the amount of thrust you can get out of its engine. Propulsion was one of my favourite modules at university and I have dug into my university notes to provide you these charming (yes that is my handwriting, can you tell why I am an engineer?) diagrams of the sections of a turbojet engine and a turbojet engine with reheat.

We use diagrams like this to visualise the propulsion cycle of the engine, shown in this diagram from NASA, which allows us to do a load of fancy derivations to arrive at a really simple equation for the thrust of an engine T = massFlowRate * (exhaustVelocity – inletVelocity) if we make a bunch of assumptions about the nature of life, the universe, and everything we can say that the Mass Flow Rate is the product of the inlet area, the velocity of the aircraft, and the air density. This means that thrust is directly linked to altitude! The equations get more complicated as we go to different engine types but the core of the problem is the same, Force = mass * acceleration, Isaac Newton to the rescue!

All of this leads us to something that looks pretty good and is computationally fairly simple (which is good as we can check the values with hand calculations) which we use for the majority of the life of an aircraft.

The details above allow us to force our aircraft to generate contrails, engine smoke, and tip vortices based upon the performance that you are demanding from them at a given moment.

Different States

However this doesn’t cover all scenarios, while the aircraft is not airborne we use a different controller for motion.The ground based controller is a really simple Newtonian system based upon the good old equation F=ma. We tend to ignore a lot of the realities on the ground in favour of getting you in the air quickly!

However the simple formula Isaac Newton gave us does not cover such trivial realities as navigating your way around an airbase, for that we use defined taxiways to allow you to watch your aircraft drive around on their way to the runway.

The same also applies to aircraft carriers, where the taxi paths are described in such a way as to allow unlimited possibilities (I know someone is already planning to launch their Vipers from the Battlestar Galactica). We have made sure to include details like opening and extending hangars and even oddities like the vertical elevators on the

Moskva-class Helicopter Cruiser.

Takeoff is another situation where the normal flight model does not apply. Seapower supports, at present, 5 different types of takeoff: Normal, Catapult, Skijump, VTOL, and Helicopters. Each of these methods has its own system that allows us to provide realistic looking behaviour without risking the flight model getting horribly confused and smashing all of your shiny F-14s into a thousand tiny pieces.

These unique states exist throughout the flight control system and allow the aircraft to behave in a manner that is appropriate to the moment that they are in.

State Machines

A moment ago I referred to something called “states” this leads us to a really important concept for Seapower, and lots of games in general! This is the “Finite State Machine”. A State Machine is a way of creating a system that transitions through behaviour in a repeatable and reliable way when certain conditions are satisfied.

FSMs are used throughout Seapower to drive systems across a range from torpedo homing to aircraft landing, they are an incredible tool, if you want to learn more I recommend this video: Unity Bots with State Machines – Extensible State Machine / FSM – YouTube

Conclusion

At this point my ramblings have hit about 7 pages in Word so I think I better stop and get back to coding. We are really looking forward to getting this game to everyone who is out there waiting for it. We really can’t wait for you to see the effort and dedication that has gone into this across the last few years.

Here are two more videos showing landings on a carrier and on an airfield:

Today, we’ll be talking about how units in Sea Power handle sensor detections and communicate that information to one another.

Sea Power takes place at the dawn of computerized combat information systems and digital datalinks. The Naval Tactical Data System (NTDS), Tactical Datalinks (TDL), New Threat Upgrade (NTU), and AEGIS in the US and the Soviet More (Mope) family of systems were in the process of revolutionizing how battlespace information was managed. Where once a detection would need to be manually placed on a plotting table and laboriously updated, a computer could ingest, maintain, and communicate that information across the rest of the force.

Sea Power uses a simplified system based on our best understanding of how real sensor systems work to provide you with a view of the battlespace that is, we hope, remarkably true to the view a task force commander would have while orchestrating combat today.

In the real world, there are three major intermediate representations between the raw sensor output and the combat information display:

• Plots describe the presence or absence of a detectable object at a given position and time, according to a specific sensor, not what the object may be or any of its history. Sea Power does not simulate the plot stage of detection.
• Tracks describe the presence of a specific object at a given position and time as seen by one sensor; tracks are formed out of plots by aggregating “close” results that likely came from a single target through a process referred to as track extraction.
  
  Tracks are the lowest level of sensor output in Sea Power. A Sea Power track is comprised of several optional sensed properties including:
  • Heading and bearing from the sensor
  • Altitude
  • Measured velocity
  • Side
  • Environment (e.g. surface or air)
  • Class
  
  A track need only provide one field; all others may be missing. For example, a passive sonar is only able to tell you what the environment, class, and bearing of a target is, but cannot figure out what the range or the true operator is (if there are multiple different countries who operate the same class).
• Vehicles are built out of multiple tracks and denote the presence of a target as well as its history; a vehicle represents all information that is sensed about a target at a given time combined with the historical information that has been accumulated about the target since it was first detected.
  
  Vehicles are constructed by combining tracks over time by taking the best quality or most recent data. A vehicle in Sea Power consists of the current best estimate of the target’s position and velocity as well as all of the other track parameters.

Sea Power’s vehicle combination approach is straightforward. Working over each track provided to the system, we determine the world-space position of the sensor by combining the heading and bearing information provided by the track. This is then augmented with the other state information from the track, giving preference to whichever has the lowest error. The process is repeated until all tracks have been ingested.

In the above example we are synthesizing a vehicle representing an SH-2F Seasprite helicopter detected by both radar and Electronic Support Measures (ESM). The radar can determine that the target is an aircraft and provide a relatively precise position. Meanwhile, the ESM system is having problems: the target is emitting using a LN-66 radar, but this radar is used on both the SH-2F and the Adams-class DDG (among others). The ESM system also only resolves a low-quality bearing and no range information whatsoever. The vehicle combination system merges these results by selecting the radar’s positional fix, since it is the most accurate, while determining that the target is an SH-2F by picking the ESM-derived type that is consistent with the radar-derived kind (for a DDG is not going to be flying unless something has gone very wrong).

Sea Power only performs this vehicle combination process locally; it does not attempt to merge tracks from sensors on different platforms to further refine results. For example, if two radar tracks are produced by two different units on diverse bearings then Sea Power will not use that information to further refine the vehicle position estimate. This lack of fusion matches the limitations of era Combat Management Systems (CMS), though you may have heard that a number of nations are working on a capability to do just this. However, we need to show you (and the AI) a representation of “all that is knowable to you” somehow.

In order to be able to give you a minimap that is useful, we provide a force-wide sensor picture. This overall sensor picture is constructed by combining each of the vehicles produced by each unit into a “best estimate” picture for every target that simply picks the highest-accuracy solution for each vehicle property. This best estimate is the sensor picture that’s shown to you on the minimap and is used by the AI to make tactical decisions for all but submerged submarines. You’ll be pleased to know that this approach is based on what data is publicly available about the TDL systems that have been in use throughout the world since the dawn of the missile age.

Here we see a simple (variable time compressed) example of vehicle synthesis in action. The detection sequence, against a hostile Kinda-class RKR, goes as follows:

• Initially, our positional fix is derived from target motion analysis based on passive sonar from two Oliver Hazard Perry-class frigates, one of which is on screen and the other of which is to the north of the shown area.
• The A-7 then is able to get a visual (non-identifying) contact on the ship, giving us its position far more accurately than TMA can, but not its identity.
• This is further refined by the aircraft once it gets close enough to identify the target.
• The plane then overflies the Kinda, losing sight of it…
• Which causes the visual positional fix to time out, causing the best positional solution to become the one from target motion analysis. The visual target ID is retained even once the positional source changes.
• In the interim, the TMA system has reinitialized its target fix based on the visual contact so its uncertainty area resumes where the visual fix left off.
• Then the A-7 turns around and re-acquires the visual track, locking down the target position…
• Which is then lost once it flies past the target, again reverting to the TMA solution.

This example shows how the plotting system will take the best available fix and synthesize that with past information to show you an accurate sensor picture. We aren’t doing sensor fusion, as mentioned, so we’re merely taking the best available fix rather than trying to bolt them on top of one another. However, there’s an exception to this rule: the aforementioned target motion analysis system.

Religiously adhering to our “no sensor fusion” rule would give us a serious inaccuracy. Era TDL systems allow anti-submarine warfare platforms to share bearing-only tracks to allow for multi-platform target motion analysis. In turn, by getting multiple different units to report bearings to the same target, TDL-equipped ASW platforms could triangulate a target’s position and thus estimate its position and velocity. We, too, allow this by implementing a model of TMA based on a Bayesian target state estimator, whose uncertainty region is shown as the ellipses in our plotting example. We’ll dive into more depth as to how this system works in a future update, so stay tuned!

In this part of the dev diary we’re diving deep into the underwater realm to look at new additions regarding torpedoes and acoustic countermeasures in Sea Power made recently.

First, let’s discuss the torpedoes. In Sea Power, a torpedo can use both passive and active sonar seekers, detecting targets using our acoustic model. Torpedo acoustic detection is modeled just as other types of sonar in the game are, considering how much noise a target makes, how that noise is transmitted to the torpedo, and the torpedo’s own ability to detect said noise. Noise produced or reflected off of a target is dependent on the aspect and distance to the target, as well as the target’s type and class. Transmission then depends on the local speed sound profile (SSP), alongside layer and surface duct effects, controlling how much of the generated noise can get to the torpedo’s position. Finally, each torpedo has its own detection threshold. Wake homing torpedo guidance, as originally developed by the Soviets in the 1960’s, is to come soon.

Active and passive torpedoes use proportional navigation guidance to intercept a target detected by their sensors, allowing them to efficiently close with a target faster than a pure-pursuit approach would. This is particularly important in crossing or head-on engagements, where simple guidance requires torpedoes to engage in time (and fuel!) consuming stern chases, improving effectiveness.

With these newly en-lethalized torpedoes, one might hypothesize that submarines and surface ships are dead meat. Not so! Submarine and surface ship skippers in Sea Power will be able to exploit the very same acoustic model as a defense via sonar countermeasures, producing false targets to defend themselves against torpedo threats.

Countermeasures against acoustic homing go back as far as acoustic homing itself. The development of acoustic self-guided torpedoes by Germany in WW2 went hand in hand with the invention of the first acoustic countermeasures, such noisemakers and towed false targets. Post-war, and beginning in the 1960s, a new kind of sonar countermeasures, the self-propelled torpedo-like decoys was developed. Based on the ideas started with the WW2 era “Sieglinde” German noisemaker, these were equipped with a small electric motor allowing them to present a more realistic acoustic and motion profile to an attacking torpedo.

Even simple noisemakers evolved considerably since the end of the war. Originally, noisemakers were devices filled with chemical compounds that, on contact with sea water, react to produce tons of bubbles and noise. This air and sound creates both a plausible active and passive target for the simple acoustic homing torpedoes of the time – but as acoustic homing technology improved, so too did the countermeasures. Modern noisemakers now produce mechanical noise and even can jam active sonar with false high frequency acoustic pulse. These are relatively compact but short-lived devices that can be launched either from small torpedo tubes on a submarine (usually positioned aboard the hull) or from on deck countermeasure launchers on a surface ship.

Self-propelled decoys exist in Sea Power as well: decoys such as the MG-44 are essentially torpedoes with no warhead and reduced speed, substituted for equipment designed to imitate a submarine. Using narrow and broadband noise emitters, preprogrammed movement patterns, and even active sonar jamming, these decoys provide an even more realistic false target than their unpowered brethren. Today, Sea Power implements these as mobile noisemakers, using the aforementioned logic, but we plan to expand on this further.

In Sea Power the noisemakers have high noise and active sonar reflection parameters assigned to them, usually greater than can be expected from a real target, thereby presenting a torpedo with a shiny big acoustic signature to home on. Counteracting this, each torpedo also has a chance to recognize the false target and reject it based on the respective tech level parameter. The more modern and sophisticated the torpedo is, the higher its level of countermeasure rejection is, but each countermeasure also has a countervailing tech level. Thus, the electronic protect versus electronic attack continues the age-old shell and armor struggle in Sea Power.

Anti submarine warfare

Let’s start with submarines which are a major threat for every task force. Since WWII many weapon systems have been developed to attack that hidden danger. One of the successors of the quite successful hedgehog (a forward-throwing-anti-submarine weapon) was the RBU-6000 (Реактивно-Бомбовая Установка) which is a Soviet anti-submarine rocket launcher. It fires salvos of up to 12 unguided depth charges in a horseshoe-shaped pattern to maximize the probability of a hit.

Here you see a Kresta 2 class cruiser attacking a Sturgeon class submarine:

Those rocket propelled depth charges are quite effective having a hit ratio of about 80%. Beside classic torpedoes there is another interesting option to attack submarines: torpedoes which are fired using a missile launch. One famous example is the ASROC (which stands for Anti-Submarine ROCket), here on a Spruance class destroyer. The attached MK 46 torpedo will start a spiral search after entering the water, going up and down within its search window to actively seek for a submarine:

Sound effects

To create a convincing atmosphere for the entire environment it’s crucial to add proper sound effects and music. Propagation of sound is a quite complex matter, there are doppler effects, sonic absorbtions and reflections, different dampening parameters for different frequencies based on the distance to the source of sound and even more.

For our game Sea Power we want to create an environment that feels realistic. The Unity implementation of the sound engine already allows for some basic behavior, like simple volume fading of a sound source based on distance as well as some filters and doppler effects. But we wanted more! Take an aircraft with a jet engine for instance. Depending on your observer position such an aircraft will sound different from the engine intake than from the engine exhaust. To show that effect, here’s a short video about how that will sound in Sea Power for a jet engine…

…and a turbo prop engine…

So far so good but there’s another aspect of sound for such aircraft. You know how it sounds when there’s an aircraft far away. More often than not you can hear its kind of growling sound but cannot see it.
As you can see, our own sound system allows for aspect sound effects additionally to the already pretty nice Unity sound features. Combined for an aircraft it looks and sounds like that:

A good usage for filters is the water itself, you already heard it in the video above where the submarines were attacked.

That’s it for now. Actually our plan is to roll out more dev diaries with interesting topics in a shorter interval to not let you wait for too long! So this shouldn’t become another months break till the next one!

/Martin

As previously mentioned in the very first dev diary, we use publicly available Digital Elevation Data that comes in 30 arc second resolution, which works out to about 1km per pixel. There is a 90m per pixel SRTM (Shuttle Radar Topology Mission) available, but this dataset is known to be noisy, doesn’t cover the polar regions at all, and would severely increase the size of the game on disc. One of the issues with the raw data is that coastlines end up jagged, and very low coastal areas end up a mess of artefacts. Again, maybe acceptable through a periscope, but awful when seen from high altitude:

Nils and Martin tried several code-based approaches to fix the coastlines, but in the end the solution turned out to be some manual editing of the raw data in photoshop and a much better interpolation function:

To solve the problem with featureless scenery, we elected to use publicly available landclass data employed as per-tile splat maps, with elevation being used to determine onset of permanent snow and the upper tree line – which is also modified by latitude, so you will find that in Norway, mountains show snowcaps and vegetation ends much lower than in the Vietnamese highlands, which are forest-covered. The farmland and vegetation differ between regions, and Przemek has been painting some really nice fields to fly over, and the vegetation system was adapted to differentiate between ‘wild’ vegetation and agricultural areas, so where there is farmland we can now have nice hedgerow landscapes where appropriate:

The final features to be added to the scenery are waterbodies such as lakes and rivers, and cloud shadows on the terrain. We’d like to think the final result looks better than what we had before:

We also took the step to implement ingame terrain and scenery editing tools. These allow us (and you!) to edit the terrain heightmap and place scenery objects at runtime, aiming for what you see is what you get. Note that the editor UI will be reworked in the style of the game UI prior to release:

But that’s not all, folks!

We’ve also implemented our radar model, and I will let Martin take over from here on:

Being a former radar operator who worked both with Soviet search radars (P-35) and later RRP 117 (a variant of the US AN/FPS-117 Long Range Solid-State Radar) this felt like coming home!

Proper sensor modelling is one of the most important topics for any war game as it makes the difference between survival or loss of your own units. As real sensor computation is pretty time consuming we decided to go with a model using so called RCS values (Radar Cross-Section). Those RCS values basically measure how detectable an object is by radar. It depends mainly on factors like material, the size of the target and the angle to the radar transmitter plus some other things I don’t want to go into detail here. Every object in game will have such a RCS value.

Radar image creation

So how is that radar image created using RCS?
For every search radar on any vessel/aircraft we collect all RCS values of objects which are in range. In range means here the radar horizon based on the height of the radar plus the height of the target plus minimum and maximum reachable height values for the radar itself.

These raw RCS values are now altered depending on the distance to the target where the reflected energy is multiplied with 1/distance². Additionally the heading of the target in relation to the radar transmitter is taken into account – the so called target aspect. Meaning that a broadside ship will reflect more than a bow/stern angled one. The used frequency band is another factor taken into account, especially when it comes to things like OTH (over the horizon) radars which use low frequencies which obviously comes at the cost of accuracy.

Now all these radar echoes are filtered in a way that the radar resolution is taken into account. There are two main factors:
a) the beam width which is responsible for the angular/lateral resolution
b) the pulse length which is responsible for the range/axial resolution

The axial resolution will be always the same, no matter how close the target is while the lateral resolution depends on the distance as well due to the beam width. At larger distances the lateral resolution becomes worse.

Using that information the previously collected radar echoes are now clustered/merged into “real” radar echoes that each particular radar system would see. That means that it’s very possible that your radar just shows one new contact where there are actually a cluster of 2 or 3 real contacts. Launching a Harpoon at that contact could lead to the situation where the active radar seeker of the Harpoon suddenly sees more than just one contact when closing the range. In that case it will use the brightest echo as the target which might not be the one you actually wanted to hit!

Data link

In your task force you will have data links so all sensor imagery of all your taskforce units will be combined into one sensor image. This has the big advantage for you as some of your units could be within the radar resolution to distinguish between close together contacts, so the limitations of just one radar will be resolved that way. This is done automatically for you so you will always see the best possible sensor image of your entire task force – of course based on your EMCON settings. Yet it could very well be that you cannot resolve all real targets or even see all of them.

Here’s an example of how you will see contacts on the minimap. You can see two contacts initially and then a third one appears which actually was there all the time but too close to the right one.

As you can see as soon as the new contact moves close to the left one it is now recognized as just one. But as there already was a known contact it’s now visualized in grey and the last movement is extrapolated for another 30 seconds. If it doesn’t re-appear after that time, that contact is considered to be lost.

Outlook

That’s it from the active radar side. Active sonar will be handled kind of similar, even though there are some different parameters like speed of sound and thermal layers. Passive radar and sonar will play an important role as well as ECM to jam your enemy.

Thanks for reading, more to come soon!

First off, we set out early on to make a game that was based around cinematic, external views and this in turn necessitates having a believable environment as a backdrop for our ships and aircraft, and there are multiple ways to go about this, and which solution to choose is largely dependent on some key requirements set forth by your gameplay. The easiest solution and one favored by many games is to simply use high-resolution digital photography mapped on a hemisphere. It is a very old-school approach but it is very fast to render and can look very convincing. This is the approach I used in Atlantic Fleet and Cold Waters, where I spent considerable time sourcing the best-looking skies I could find.

In the case of Sea Power, it quickly became apparent that this approach didn’t cut it, for various reasons:

• In our game, combat takes place over hundreds of miles, with supersonic aircraft and missiles. Using a static panorama sky texture in this context means the illusion quickly falls apart as the clouds will very noticeably follow the camera as it moves over the ocean at high speed. It is possible to fake cloud movement with some clever UV manipulation (World of Warships and The Last of Us use this approach) in the shader, but again this does not work if the camera has to travel over vast distances.
  
• Aircraft in Sea Power may routinely operate at high (30.000ft) altitudes. This is clearly above most cloud cover, but this is not possible with a static backdrop.
  
• You will quickly find the same skies being repeated over and over if you play the game for an extended time. If you want more variation, eg: Night-Twilight-Dawn-Morning as opposed to just Night-Dawn-Noon you have to source complete texture sets for those times of day as well. If you have also need different cloud covers like in Cold Waters or Atlantic Fleet, the number of sky textures required grows exponentially.

So very early on in the development of Sea Power we decided that we wanted a dynamic sky system with a day-night cycle. The first thing we did was to write up a few key requirements:

• It had to look as good or better than the static sky textures.
• It had to be cheap to render.
• It had to work with the IBL lighting solution we use.
• It had to have clouds that could be seen from above and below.
• It had to be easily art-directable.

Our proprietary sky system uses a texture-lookup approach to seamlessly blend the sky as the time of day changes. The sky colors are provided in a panorama format for a given sun elevation interval, and then blended at runtime. There are quite a few different colors which all have to be set at any one time in the game, and having everything in a lookup-texture means that it can easily be edited in an image editing program such as Photoshop, significantly reducing the time it takes to tweak the look of the environment. The use of a panorama format means that one can very easily source colors from stock photography or other sources. Additionally, our system features accurate positions for the sun and moon based on time and geographical location, together making for a rather convincing result:

Clouds are an important component of any sky, and they can become surprisingly complex. We decided early on that we would have to be able to fly through the clouds, so this implied some sort of volumetric solution, and initially we did use a 3rd party raymarched solution, but this was slow to render and was incapable of creating attractive, fluffy clouds. We elected to use a classic billboard approach where clouds are clusters of billboards (basically 2d quads always facing the camera). This is fast to render but the end results provides for 3-dimensional, volumetric clouds. For creating the clouds, we use lookup-textures where each channel defines the size, height and type of clouds to use. This approach means the clouds are easily art-directable by an artist using an image editing program, and it is hence possible to author an arbitrary number of cloudscapes. To light the clouds, we use two sets of two colors and modulate based on the sun direction. We also project high-altitude clouds directly onto the sky, to create the multi-layered effect commonly seen on skies in real life.

We provide three basic types of non-inclement weather:

Clear skies:

Scattered clouds:

Broken clouds:

Overcast clouds:

Overcast conditions are once again complicated by the fact that aircraft may operate above it. Obviously lighting conditions are much different below the overcast layer as opposed to above it. Overcast clouds attenuate and scatter the direct sunlight, resulting in a much softer ambient effect where a clear sky has very defined lit and shadow areas. Our solution is to have an additional lookup-texture with the overcast values, and blend between then based on the camera height. The effect is convincing and eliminates the need for complex realtime shadow-casting solutions which could quickly become expensive.

What better way to illustrate the effect than shoot a missile through the clouds:

As an artistic choice to make the overcast conditions a little more visually appealing, we retain some sunlight to act as a key light, and we let the sun shine through at the horizon during sunrise and sunset:

In the game, weather impacts sensor performance and detection as well as flight operations, so our environment system also renders inclement weather in the form of precipitation and lighting:

Hope you have enjoyed this post. Coming posts will focus more on gameplay mechanics, so stay tuned!

– Nils –

This time I’m going more into detail about how the world is populated – in this case with a lovely Spruance class destroyer and a Seasprite helicopter which always lets my heart beat faster when I see one!

Construction

First of all before before even having objects in the scene we have to construct them. Here’s kind of a small outlook how modding could work:

Beside the common resource files like meshes, textures, materials and so on every object in the game will have its own initializer file. That initializer file contains the description for the mesh itself, materials, physics values, sounds and optional things as launch platforms like the Spruance class destroyer has. To continue with the Spruance it would have entries for the composition of the model like:

NumberOfSubModels=44

SubModel1=Deck
SubModel2=Undersides
…
SubModel15=SPS_40
…

That doesn’t mean that all those are single meshes. They all belong to the main mesh to reduce the number of drawcalls. With that SPS 40 as an example it is defined like:

[SPS_40]
Mesh=usn_dd_spruance_sps_40
ResourcesMaterialFolder=ships/materials/
Material=usn_sps_40
Position=0,0.4067,-0.04316

which is responsible for the visualization of that radar:

Of course as the SPS 40 is a sensor system it has its own sensor entry in that file looking like:

[SensorSystems]
NumberOfSensorSystems=5

…
[SensorSystem2]
Type=Radar
SystemName=SPS-40
Mount=SPS_40

Sensors and Weapons

The entry SystemName refers to another file which contains the info for all sensors, weapons and so on but I don’t want to go deeper here and hope you get the idea. So everything is configurable using those files when it comes to physics and behavior. The internal coding part is flexible enough to create any arbitrary object out of those files of course with given meshes and textures which can be modified or added (with some work involved) as well.

Animations

Part of these files are animations and and state machines too. Animations can be either mesh based animation clips or “code based” animations. The former are predefined and just played while the latter ones involve some code behind with then performs actions like translations and rotations.

An example for the animation clips would be the unfolding of the main rotor of the Seasprite and moving the gears up while the hangar doors (or weapon hatches on some vessels) are animated via code. Of course this is defined in those ini files as well so it’s easy to add almost every behavior one could think of. I don’t want to clutter this diary with more ini file stuff but feel free to ask if you’re interested how this currently works.

State Machines

Kind of the last ini based feature are state machines for vessels like the Spruance for instance which have helicopters or other units. To stay with the Spruance this state machine defines what happens when you launch a helicopter with spawning the Seasprite in the hangar, opening the doors, taxiing the heli out to the take off position, powering up the engines, doing some pre flight checks and engaging the rotors to finally hand over the controls to the helicopter AI for a take off. So all of that is not hard coded but configurable!

Ok enough of words, if you made it till here I’d like to show you this in action (this is still WIP, e.g. the sounds are not final):

Still here? Good! One final thing to mention is that all moving objects need some guidance where they shall move too. The obvious choice are waypoints of course. When giving an order to any vessel or aircraft they will move there and … then what? Well if it’s the final one there will be different behavior. Vessels and aircraft won’t just stop (which would be catastrophic for the latter anyway) but they will perform kind of “race track loops”. Helicopters on the other hand can hover and will stop which looks like that:

(take note of that white disc which makes the waypoint visible. Isn’t that beautiful art? Now you can see how happy I am to have Nils and Przemek on my side because otherwise … well you don’t want to see more programmers’ “art” for sure!)

So that’s it for this dev diary, I’ll better get back to coding now and hope you’ve enjoyed it a bit!

– Martin –