Sea Power News

Dear readers!

Another small update about what was going on the last two weeks.

We had a visit from Frazer (MicroProse) and came together with Nils and me (Martin) in Munich to show our game to Fritz and Alex from GameStar:



We also started some internal (closed) beta so things are coming along nicely. Still some way to go but we're getting closer!

Quite some work was done regarding aircraft, here the MiG-21 Fishbed:



And land based installations, KS-19 and S-60 flak over Thanh Hóa province claimed another Corsair:



Vietnam war era dogfighting:



That's it for this time. We're preparing some more footage as well as game play videos and new trailers within the coming weeks.

/Martin

As already announced in our happy new year news we want to show more stuff on a regular base. Mainly screenshots but also videos will come soon. And of course there will be another dev diary which is already in progress!

This dev update will be aircraft related. We recently added the B-52G, here showing some weapon launches:



Defenders. Attackers. Depends which side of reticle you find yourself on.
MD500 family WIP - right now manned by brave ubiquitous soviet heli pilots, awaiting proper crew and more detailing:



Tale spin: We worked on quite some aircraft AI, having contrails and finally some action:



And finally some (boring) stats of our game. Beside all those shiny screenshots here are some nerdy numbers (yes I love numbers). Our project grew quite large over time... Above 400k lines of code so far. Those values for estimated costs are using some formula based on the complexity, I could look them up if someone is interested.
Just to clarify: Those are NOT our real costs. They are just estimates done by some (not our) algorithm:



That's it for today, y'all have a great start into this week!

/Martin

Dear all!

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!

/Martin

Hello Everyone!

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!



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.



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.



[previewyoutube][/previewyoutube]

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.



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



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:

[previewyoutube][/previewyoutube]

[previewyoutube][/previewyoutube]

Hello, everyone!

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!