Sea Power News

Hello, everyone!

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.

Dear readers, first sorry for the long pause between the dev diaries. We know it's been a while and it's overdue. This time we want to cover anti-submarine warfare and sound effects more in general and this time with some more video footage instead of too much text. Enjoy!

[h3]Anti submarine warfare[/h3]

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:

[previewyoutube][/previewyoutube]

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:

[previewyoutube][/previewyoutube]

[h3]Sound effects[/h3]

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...

[previewyoutube][/previewyoutube]

...and a turbo prop engine...

[previewyoutube][/previewyoutube]

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:

[previewyoutube][/previewyoutube]

[previewyoutube][/previewyoutube]

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

Originally we had designed the game around a compressed-distance concept where 1nm = 1km. While the intent was for faster gameplay, we quickly found some issues particularily pertaining to the speed with which engagements happen at modern speeds. This approach also necessitated some internal recalculations particularily as we use a global world with longitude/latitude coordinates for reference, and generally became rather confusing, so the decision was made to scrap distance compression altogether and simply make the world 1:1 scale. We originally had a rather short draw distance, and this had the unintended side-effect of making our environments look a lot more bland due to the fact that terrain features are now spread out over twice the distance. The solution was to increase draw distance two-fold, and it became necessary to rethink the way we approach our terrain.



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.

[h3]Radar image creation[/h3]

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!

[h3]Data link[/h3]

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.

[h3]Outlook[/h3]

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!

Previously our programmer Martin talked about how the terrain is created. This time we want to talk about the environment and how we went about creating it:

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:

[previewyoutube][/previewyoutube]
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 -

Hello and welcome back to the second part of the dev diary series! In the first one we covered mainly the terrain and how it is created using real world DEM data.

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!

[h3]Construction[/h3]

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

[h3]Sensors and Weapons[/h3]

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.

[h3]Animations[/h3]

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.

[h3]State Machines[/h3]

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):
[previewyoutube]https://youtu.be/1UjqTkqVcwk[/previewyoutube]

Still here? Good! ːsteamhappyː 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:
[previewyoutube]https://youtu.be/0fzCs697J80[/previewyoutube]
(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 -