1. Sea Power
  2. News

Sea Power News

Dev Diary #3 - Environmental Considerations

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 -

Dev Diary #2 - Let there be a ship ... and a helicopter

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 -

Dev Diary #1 - Hello World

[h3]Hello World[/h3]
Greetings dear reader, my name is Martin, I'm doing the programming for our game Sea Power and want to take the opportunity to start a dev diary here to keep you guys informed about what we're currently working on. And yeah, that's why there is this "hello world" reference. ;) Some of the stuff I'm going to post is pretty technical, but I hope it's not too boring to read.

As this is the first entry it might be a good idea to first introduce ourself and tell a bit about what we've done so far.

We're a team of 3 guys from Sweden, Poland and Germany: Nils is our lead designer and was responsible for the well known game Cold Waters. He's been into 3d graphics and game development for almost his entire life. Przemek worked on Atlantic Fleet and Cold Waters as well and is creating awesome 2d and 3d artwork for it. And then there's me, Martin, who's putting together all that stuff with some gluing code.

Ok, so going back in time... Around the beginning of 2019 we started to work on Sea Power using Unity as our development tool. Our first goal was to create some realistic terrain without the need to handcraft every single place on earth. Luckily there is free available radar height data as well as underwater landscape data available. So the first steps were to create an engine that uses this data to create the terrain. As in modern combat the areas can become pretty large it was clear that it wouldn't make sense to have the entire area in memory all the time so I started to implement it as a streaming terrain engine which finally allows to visit every single place on earth and create the terrain meshes in the background on the fly procedurally.

[h3]Terrain Creation[/h3]
First comes the raw height data. We're using GTOPO30 data which has a resolution of 30 arc seconds. This leads to a longitudinal and latitudinal resolution of about 1km per grid point. As this is pretty low res, I add 4 more grid points for every data point from the original data which leads to this result:



As you can see this needs some work to remove the steps. In the next step bilinear interpolation is applied:



Ok, smooth now, steps are gone but beside having more vertices we gained little compared to the original resolution. That's why in the last step some Perlin noise is applied which let the height mesh look more natural:



That's the more technical mesh creation part, where terrain chunks in a size of about 50x50km are created around the players location. As this looks rather boring we now need some texturing to make it look like a landscape. As our engine supports different biomes we do a lookup in a biomes texture now where every pixel equals to one terrain chunk. The pixel color defines the biome texture set to use, seasons are in as well:



After all this looks much better already. It still misses vegetation which is created in the next step. The vegetation is set based on slope and height of the terrain plus uses a distribution texture:



So that's it. In the next step there will be objects placed like ports, towns and so on, but more on that later!

[h3]Summary[/h3]
Here's an overview how all stages work, even with some intermediate you'll never see in game (e.g. lower left):


And finally some shot from about 20kft. This is a part of Japan:


Hope you liked to get some insight into our development. I'm going to show more things we're working on. Stay tuned!

- Martin