Friday, 16 December 2011 Written by 

We know there are some modders who see the complexity and sheer number of the object definition files (ODF) in FO as a hurdle that they aren't willing to take on in order to add new content for FO. Which is understandable. We face the same problems extending Fleet Operations and therefore we currently invest a lot of time in making Fleet Operations easier to mod and maintain not only for you, but also for us.

Optec is currently rebuilding the flawed system that generates the object definition files for Armada. ODF files define all stats of every vessel, station, weapon or map object in Armada. We have a lot of these in Fleet Operations, a lot more than any other mod for Armada that I know of - and this is not a good thing.

Internally all ODFs are build from a set of 'source' files to ease up development. However we now nearly have as many source files, from which ODFs are generated, as the resulting number of actual ODFs.

The reason the system is so flawed is that it was designed for early pre-release versions of Fleet Operations 3.0. We had a lot less ODFs in use there. Things like the ranking system, the extensive use of features like mixed tech, Borg build tree and many of the special weapons which require multiple ODFs weren't in the planning at that time.

This system is now being recreated from scratch with all current and future features we planned for FO in mind. This will drastically reduce the number of 'source' files we have to manage and thus restrain the number one source of errors that went into release versions of Fleet Operations - as caused by the high quantity of files we had to work with. One important aspect of this rewrite is also to improve readability and reduce number of the ODFs, which should be especially helpful for 'newcomers' on the modding scene.

There is another aspect that complicates modding Armada and especially Fleet Operations - the Technology Tree.

Technology Trees are a key element of strategy games. In Armada the technology tree works in a very linear fashion. As a modder you can define dependencies like: shipA requires yardA, researchA and researchB to be buildable. Now to you at first that may sound sufficient. And actually, it is for many games. This is one of the simplest forms a tech tree can take. However as gameplay in Fleet Operations evolves it soon turned out to not be sufficient for where we'd like to take the game. We don't want to have just a bunch of races with static build trees, but instead want these races to have their technology interact. To achieve that we had to overcome this limitation in the past through workarounds.

Namely this is already known in Fleet Operations as 'mixed-tech'. For that, let's take a pretty well known example here: The Federation Defiant class. In Star Trek Deep Space Nine at one point thanks to an arrangement between Starfleet and the Romulan Empire the USS Defiant gets one of the Praetor's precious cloaking devices installed, operated by a soon-never to-be-seen-again Romulan officer. Now often in mods for Star Trek games you find the Defiant class has a cloaking device installed as if Starfleet ignores the Treaty of Algeron across the board. This is not what we wanted in Fleet Operations. While we thought it is cool to have a Defiant with a cloaking device, it felt illogical to have that on every Defiant class that leaves the yard. That is why we wanted a requirement to either have an allied Romulan player in the game or capture Romulan technology to be able to build a Defiant class that has a cloaking device. This is now what we already have in the game. And that brings us now back to the point: techtree wise in pseudo-code that sounds a lot like: "CloakingDefiant requires romulanAlly or romulanStolenTech". But actually in your version of 3.2.6, you won't find any line in the techtree file that represents such a requirement. It is just not possible with the very simple functionality that the current techtree of Armada provides. Instead we had to introduce these requirements within the ODF files. Now, this implementation is a bit awkward since we have techtree requirements that are set in the definition files for the ship.

This is why with the next version of Fleet Operation we'll introduce a brand new file format for the technology tree. The whole techtree system has been rewritten from scratch. All techtree related ODF commands that were previously introduced with Fleet Operations will be removed and instead can all be used in another form from within the techtree files. We won't stop there however. This is not a simple move of all commands to the techtree files. The techtree will become a lot more powerful.
Now first an example of the requirements that are now defined from within the techtree files:

  • A ship is only buildable if you play a specific race (was: buildableByOwnerRaceOnly)

  • A ship is only buildable if you have an allied player with a specific race (was: requiredAlliedRace)

  • A build button is only visible if a requirement is met (was: buildItemXAvailability)

  • You can only build a specific amount of a ship type (was done with fleetCap files)

  • Hide weapon buttons if technology is not available (was: showOnlyIfHasTech)

All of these were already possible through ODF commands. Now they are all realized through the techtree file using a different approach. This approach will look much more like of what you would expect it to in a techtree.

Now for some examples of what the new techtree will additionally be able to accomplish:

  • You can add requirements that your allied or enemy player has to build or research first before they are fulfilled. Example: Klingon player can research special anti-station torpedo if enemy Federation player has built a Torpedo turret

  • Ships can now be limited by multiple capacity requirements. Example: Veteran fighter carriers are limited both by their number and veteran limit

  • Requirements can now be AND/OR. With that you can combine all requirements you can think of: Ship requires Research A or Research B, and an enemy Federation Player with Research C. - A 'real world' example of that could be: You as Dominion player can build a Breen vessel that has a cloaking device. In order to use it, you have to research cloak first. However, if a Romulan or Klingon player captures such a vessel, then these races can make use of the cloaking device without research, since these races are in possession of the cloaking device technology anyway.

  • Since all techtree specific settings are not bound to ship object definition files anymore, alternate techtree files can be created where different (or no) capacity requirements and race limitations for a vessel apply

This is just to give you some ideas of what will be possible. And there is more planned to extend the techtree even further.

The new Technology Tree system will also help to reduce the number of redundant ODFs in Fleet Operations, supporting the idea of the simpler access to ship stats during development.
Some interesting trivia: Code-wise the new implementation compared to Armada's previous techtree is, despite its extended functionality, faster.

In Fleet Operations mixed tech will be one of the features that will profit heavily from the new Technology Tree system. Currently mixed tech is not that much fun to use compared to what we intended it to be. Depending on our time however, this change to mixed tech may or may not come with the next version.

Not only for Fleet Operations but of course for other Armada mod projects this new Technology Tree implementation will open up a whole new array of possibilities. I am looking forward to see which mod will make creative use of that first.

The techtree files now will be using XML. Usage of the old .TT files is still possible for backwards compatibility. Despite these making use of the new (faster) implementation, you cannot make use of the extended options and thus they are limited to the old plain Techtree. It is possible however to mix the new XML file format with the old .TT files by using include commands if desired. A converter from .TT to XML will be provided.

Now to show you a sample of how that will look in the game. Since it is hard to capture an actual techtree in a screenshot, I'll use the resulting tooltip and source file as a sample. This shot is from a development version taken in early July where I tested more fancy combinations of the techtree's possibilities, so...I hope no-one is going to ask if these are the final requirements for the Akira.


In the editor window on the right you see a very simple and short techtree file. It only defines the requirements for the Akira class. The Akira has defined two requirement groups. Translated into English, the Akira in this sample requires: Either an Outpost and no Storage Dock build or Starfleet Engineering and an Eraudi Yard.
Since there is no Starfleet Engineering and Eraudi Yard on the map, the second requirement group is not fulfilled. Looking at the first requirement group, we have an Outpost (so it doesn't appear as a requirement in the tooltip) but we also still have a Storage dock, which is set in the techtree file that we should not have one (mustNotHave="true"). So in order to fulfill this requirement to build the Akira class, the Storage dock would need to be disassembled/destroyed or alternatively we would have to build a Starfleet Engineering and Eraudi Yard.

I hope some of you enjoyed my technical blah. If that was not the case, don't worry. We'll come back with more, less-technical info about the new version of Fleet Operations soon.