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!
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):
https://youtu.be/1UjqTkqVcwk
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:
https://youtu.be/0fzCs697J80
(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 -