Flights of Fantasy

Little departure from the usual post. I want to engage in a little "what if", or Flight of Fantasy.

Which also happens to be the name of Chris Lampton's book on programming flight-simulations in C++ way back in 1993. It also happened to be a pretty good book on learning C++ and VGA graphics back then. I still have my copy here on the shelf.

Christopher Lampton, Published 1993

Fair warning; this might be a lengthy blog post so I'll break it up into two sections. You can skip past the first part which is a glance at my experiences with middleware and the disconnect between it's creators and their user base. Then I'm going to talk about some new technology I've been playing with and why it's brilliant.

Part 1 Game Engines and User Stories

I started the re-boot of Combat-Helo at the end of 2009 using the best bang-per-buck game engine you could buy at the time. Progress was reasonably swift using Leadwerks 2.1, the deferred rendering engine was only in two AAA games at that time. It surpassed Unity3D with it's superior vegetation performance and lighting. With delays in development and my necessary shift from full-time to only part-time development (thus causing more delays), technology has moved on...a lot.

Apps and mobile devices exploded (a sentence that will no doubt get flagged by some NSA bot). This had an effect on middleware development with everyone rushing out mobile support. Unity3D now sports Android and iOS publishing (btw Apple's developer license requires you advertise your app by placing the iOS/Apple before their rivals). Esenthal, Monkey, AGK and so on down the scale going from good to bloody awful.

Leadwerks ended development of the engine we use for Combat-Helo with version 2.51 which was a blessing and a curse. A blessing as we experienced problems related to ongoing culling and 'fixes' causing delays of weeks. The curse, broken Newton physics functions and much needed features. It was an interesting lesson in how reliant your project can be on the whims of individuals during development. Not just middle-ware, but also community members too. I'm still a supporter of the engine, it has a good object structure and great for prototyping something. Good for small projects and demos, it still delivers good bang per buck (even though you can no longer purchase version 2.x).

Moving on, Leadwerks has since re-launched with a brand new new engine dubbed...Leadwerks 3. As was the trend, the focus was squarely on mobile devices with only the promise of a PC deferred renderer sometime later. Since other game engines chasing the lucrative middleware market had much richer feature lists, it was only sensible that Leadwerks re-focused on what it did best; desktops. Presently the team is working feverishly on completing Linux and PC versions of a new high-end renderer. However a renderer does not a practical game engine make, and while it's creator insists it's a game engine (it is, sort of) it is also playing catch up. While there is support for animated meshes, the developer is expected to bring a lot more to the party unless you want to make more than simple demos and games. And this is something I'll touch upon shortly, as it's kind of the whole point of part 1.

Other engines of note include Esenthal which is better suited (but not restricted to) to RPG like games. All reports are that the chap in charge of development provides excellent support and is open to feature requests from users. I know some fellow indies have migrated to this engine and achieving in days what took weeks elsewhere. Frankly, if it takes you more than a couple of hours to make something move along a track and perform some trigger event logic I wouldn't consider it a modern game engine (more of an API).

The latter is quite telling and raises an important point about developers who design, code, tools and middleware they don't really use. And I mean "use" in the sense of using them in the way they are supposed to be used and not in any trival sense. The biggest culprit I'm talking about here is...Microsoft.

Microsoft have a history of knocking out some technology in what some would describe as a half-baked fashion, until they need to use it in house. They now have a special internal team devoted to using their technologies in projects of realistic size instead of the trivial examples only required for documentation purposes. We call this activity "User Stories" and is part of Agile Methodology (a development method that's gaining popularity).

Unity3D is a prime example of what happens when you have user stories shaping your product. Pretty much everything someone needed for a project was reviewed and improved. Developers tend to have a lot more experience and knowledge of shortcomings in middleware than its creators by simple virtue of spending more time on that activity.

Now I've spent a lot of time creating modules for a combat simulation, if I had to do this all over again (especially if YOU had to do it from scratch), here's my advice. Pick something that can deliver the following:

• double precision floating point math
• fully flexible shader and lighting system
• animation blending and tween classes out of the box
• AI navigation and path finding
• Multi-threaded rendering and streaming of geometry
• Vegetation layers
• 8+ layers of terrain texturing
• No cascaded shadow maps
• Actor level scripting
• Native code for plugins (for headtracking or other gadgets)
• Support for n terrain (or world) objects
• Volumetrics of some sort (fog/clouds)

And as it happens there are engines out there that not only do ALL of the above, but do it well. For a price more suited to small working studios than indie developers.

Part 2 - What if...

I'm currently working on completing a flyable version of Combat-Helo - Gunnery (a prologue). When you hear developers in interviews say "all the hard work is at the end of a project?", that's totally 100% true. Right now I'm pecking away at a mountain of our own creation but everytime I touch it, it's small improvements, it's quite cathartic.

What if we made Combat-Helo as a DCS World mod? "Yes I'd love to, but I can't". That's different from "I won't". I'm always on the look out for a LUA developer I can trust to take on the work as I'm not technically capable of doing all the LUA coding required, I'm not that good, it's hard enough to keep track of how our helicopter works internally never mind doing that on top of someone else's API (especially when I'm learning a new one).

Looking around at other technologies available right now, what if money was no object for a theoretical Combat-Helo 2.0 project? What would I use? I would be have to choose the aforementioned Unigine. By simple virtue of having everything I need to make large environments using our existing assets.

Let's take a simple User Story: "Import an Apache Hull in it's native FBX format"; Without crashing or grinding of gears or any arguments. In a matter of minutes without leaving the editor it was possible to import sections of a complex Apache model and generate interacting hull physics without any problems. When time is your premium asset, anything that reduces it is well worth it. But it goes further than that, if you want a complex model with articulated sections for landing gear and control surfaces, you can assemble it in a provided tool (OpenFlight format import is provided too). Then add the whole entity into the scene. Job done. Oh, I actually did some of this already.

Physics hull of the Combat-Helo Apache resting among ground clutter.

So that's my fantasy, that one day we'll have a second or third generation of Combat-Helo that allows us to spank tanks across large areas of operations in lush detail. Maybe it will look similar to this.

Unigine - made for lush outdoor environments

CH Gunnery may not be a looker by modern standards but I hope when you play it you'll be left wanting more (in a good way).

What if I didn't spend an hour writing this and fixed some controller bugs instead? Hmmm.