As the Mark I is about to be release, we think it’s time to speak about the game development and future releases, especially about cockpits.
This is the first truly technical post about a game element, everything may not be totally clear. We’ll do our best to write about future improvements and content updates. We are selling an early access game so it’s the least we can do.
In the Mark I version, only Marcel Gaston’s plane, the “Rorqual” has a cockpit, here the image:
As we can see, several 3D gauges are present. When I first created the cockpit system I told myself: “come on, it is an arcade game, every plane cockpits will have the same gauges, it will be simpler that way.”
Except today I’m doing another cockpit, for another plane and I don’t want to use the same ones.
Here is the first cockpit system as it were initially designed:
- On-board instruments are modeled in a 3D modeling tool.
- The same goes for the rest of the cockpit.
- Instruments are positioned in the cockpit, also in the 3D modeling tool.
- An export script generates a .gauge file containing the list of the instruments and their positions.
Here is what the .gauge file looked like then:
Let’s take as an example the following line :
RPM 1 [0.366772,0.0351799,4.15318]
This means that a rev counter (RPM) is going to be positioned at the coordinates between brackets. The number following the instument name, here “1”, means that the rev counter is for the engine “1”.
This system is quite alright but has already a limitation: if I’m doing another cockpit with an instrument oriented different way, I can’t: orientation is not included in the .gauge file.
So I’ve modified the export script in order to include orientation as a quaternion:
The example above is not very convincing because none of the cockpit instruments are oriented. But it could position any instrument, anywhere, with any orientation.
By the way, if we don’t want to use the same instruments for every cockpits, how can we do that? Having different cockpits is a thing, but if they all look alike, it’s not so interesting anymore.
Here’s come the most important modification I’ve had to do. Initially, every instrument was coded in C++, with its own class. For example, here’s the altimeter class:
C++ is great, but in order to add a new instrument type, or just use an instrument with another look, I need either to add a new class, or expose a whole lot of parameter from an existing one.
A typical case is the throttle: on some aircrafts it rotates around an axis, on others it slides. How to do it? Add a parameter to know the kind of throttle? Do the same for its travel? Add parameters like crazy in order to get a generic but horribly long and complicated C++ code? And what about the modding?
Another example: the first aircraft’s instruments has instruments with international units, i.e. meters. If I want to make a new cockpit with instrument labeled in foot, I’m doomed.
Definitly, it is not the right solution
Out in-house game engine features lua scripting. We have not developed a lot of things in lua, favoring the C++ so far. Let’s use lua scripts to code instrument! If anyone would want to add a cockpit in the game, he could do anything he wants.
So here’s a .gauge file line now:
defaultAltitude 0 [-0.013462,-0.05001,4.15774] [0.0,0.0,0.0,1.0]
defaultAltitude means that the instrument behavior is defined in the defaultAltitude.lua script file.
Which looks like :
The code is almost the same, but the possibilities are totally different. Thus for every new cockpit being made, it is much simpler to add a specific instrument, in its behavior or look.
For future modders, it is a big feature, they will not be constrained by a fixed instrument list from the developers (us).
In order to conclude this post, here’s a new cockpit render (wip). As you can see, the instruments are the same than on the “Rorqual” one, but you can imagine that everything I just mentioned has not been for nothing !
