Sea Power News

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 -

[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