Today was trying to work around Leadwerks 2.5 / Newton bugs. Mostly commands that you think should do one thing but don't. It's the little things that really annoy as you can't fix them. This is the danger of using off the shelf engines.
Case in point; the problem of LE:SetJointStiffness, failure of the ability to set this results in the undercarriage being dragged like elastic at high speed behind the aircraft. Using joints also totally breaks interactions of the computed flight dynamics on the aircraft body. To be fair the docs do say this command is NOT supported. If you need it you're left having to re-factor your ground dynamics implementation along with how to build the art assets. Fortunately when we looked at this last time Dave did some work on separating parts of the Apache gear and I think I have a solution this time.
Using a raycast suspension will solve the problem. If it doesn't I'll be sure to let you know.
This development cycle is likely to last through the end of the year, getting "Gunnery" released will be a big milestone for us (if only to prove that this project is real). It has much more potential which we've talked about at some length in this blog. I had to scale-down the planned features as it isn't possible to realistically implement the campaign and some avionic components. Gunnery will be a firing-range sandbox showcasing the AH-64D Block II(ish) but we will patch in some method where users can hack in missions. I will continue to add more features to the cockpit, multi-player will come as a patch after release (or we can delay release while we test and refine MP). No firm decision yet.
The Future
The questions comes; what do we do after Gunnery? Given that LE2.5 is limiting what we wanted to deliver, the next iteration of the engine Leadwerks 3+ was something of a step backwards in terms of capability (except on a superficial level). It looked promising but there's nothing in it for projects like ours at a time where we need to up our game. As a professional software engineer and tester I find myself looking at quality and bang per buck more objectively and find a lot of engines wanting. There's some good stuff coming out of Unity development if Unity was actually usable for non-trivial games. It needs more efficient large world handling that doesn't suffer from large heap fragmentation.
Unity has some really great plugins for terrain these days. Check out this plug-in called Mega Terrain from MegaFiers (who also make a really nice Max Terrain plug-in):
If only it was so easy to pull in this data into applications like GROME or World Machine. I do like the virtual table-top presentation in this video.
Parting shots
I had no idea we had such a following on Facebook, I'm not a big Facebook fan so I've never paid it much attention. It's hard to check around all the time, generally I'll post the odd snippet on Google+.
One of the things the team talked about this week was how to switch to a more modular design and how to collaborate more efficiently over the internet. I'm a fan of Google+ Hangouts so we'll arrange something in the near future.
Finally a couple of random screen-shots without which this post would look really bland.
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.
"Normal people believe that if it ain't broke, don't fix it. Engineers believe that if it ain't broke, it doesn't have enough features yet."
Just to be clear, currently my personal priorities are family, work, house and combat-helo (in that order). I do apologize for that but that's the way it has to be until such time I'm freed from another urgent project (which has a firm drop-dead date in October).
The good news is, after all this time I'm still stoked when I execute Combat-Helo, it's always a treat when I get time to sit down and tinker with it. So what's been happening?
Recently I completed running auditions for the gunnery range crew and range officer voices; this turned out better than expected. The samples I've put in into the game already greatly contribute to the experience, I thank those who downloaded the script samples I put up on Google+ and sent in samples. Once I've got the cockpit audio triggers added I'll put up a new video with some of the neat new camera footage (more on that in a sec). I hate posting blog updates without anything interesting to show or talk about.
In this blog update I wanted to surprise everyone with fully working Hellfire code and a video to go with it. The plan was to finish this feature for a recent flight-sim show. A family health emergency meant all of that had to be cancelled, hotel rooms and everything. But here's a tantalizing screen-shot of some of it...(with DOF and totally unrealistic rocket motor plume) I don't normally turn on all the fancy post-effects for screen-shots but I reckon you chaps deserve it.
Adding seasonal effects
Get ready for a white-out
The Hellfire cam is a nice addition (added totally for the purpose of making cool video). It's dynamic in that does the whole wobble and tries to frame two entities in context (borrowing code from the flypast and internal MFD framing view).
As for the Apache's primary weapon system, the Hellfire missile, this can hit targets beyond the game-engine's current visual range (oh for a dedicated and scale-able terrain engine) which only highlights the problem we've always had with terrain scale. I can fix it but it means a huge delay on top of something that's already delayed. Not going to do that.
The Apache needs three new MFD functions to implement PFZs and some control changes for the Hellfires. Nothing challenging, just man-hours. One page was to be a laser-code page, however on closer inspection of the video footage this turned out to be a "shot-list" (which isn't useful except to add to flavour to the aircraft).
I've had time to tweak some of the visuals and add Afghan grasses from Pure3D which blend well with the desert textures. The game menus are awaiting a nice makeover. The design of the flight-line interface will really pop and should be a great blend of the thematic modern 3D gui and old-school multi-menu using existing base assets.
When will it be ready? When it's polished enough to release (fixed glaring controller bugs, training missions and speech added, not to mention the stupid Leadwerks/Newton joint stiffness problem which I can't fix - I don't know how but it's vital).
As usual, all hate mail, suggestions and offers of large sums of money to pay for dental work can be submitted in the comments below.
Update - This weekend I implemented some environment updates. Dynamic vegetation and snow effects. Thanks to Shadmar's mesh shader modification it's possible to apply gradual snow coverage to a material. Since the environment class also supplies atmospheric pressure and temperature values to the flight model, this should translate into variable handling characteristics depending on weather conditions as well as some visual variation for gameplay. Should be fairly easy to modify the FLIR shader to compensate for the snow coverage too.
Thanks to Sergio's efforts we have a working prototype for a potential online 'war-room'. Using XRTML and a proxy application dubbed RTCH (Real Time CombatHelo interface?) which listens on a local port. Combat-Helo and tools pushes data in and out of proxy. The proxy communicates with the XRTML server farm which distributes data to and from all listening browser pages. We'll be working on a HTML5 Canvas tool so we can render more complex data such as vector graphics. This potentially allows players and their friends access to their game sessions - in real-time - through a browser. I've also sent aircraft and avionic "state" data from the helicopter which would allow for browser based instrument repeaters. By adding code to certain base classes that use "reflection" I can now view debug data remotely which is going to be a huge time-saver for me.
This has been created as a development aid and proof-of-concept. With such a system, players across the world don't even need the game running to participate in planning and execution.
Just started on Mission editor and Event Manager
Nexus 7 Google Chrome being updated by game data real-time.
The proxy app could also be interfaced with FSX via SimConnect and pushed to browsers in the same way.
Over the coming week, mission code and mobile units will be migrated from the test modules into the game so I can begin integrated testing.
This week saw me starting on a new sprint cycle of development (I've been contaminated by Agile "terminology" at work). I fixed some outstanding shader bugs and will be updating how the game launches this week. After a bit of an absence from the main build, coming back to Combat-Helo's cockpit was "wow", someone should really finish this and ship it. What more inspiration do you need?
It also highlighted the problem in that I couldn't remember how to operate the sensors, accidentally stowing and powering off the FCR in an attempt to switch back to ground FCR mode :/
I've never been happy with the stand-in grunt to run around in first-person mode to get to game functions, jumping back to the original design of the 'gods eye' view of the base, this seems both faster, more intuitive and (lets face it) a lot less work.
xRTML Debugging
To speed up development I'm integrating some remote debugging features in the form of IBTs xRTML (Extensible Real-Time Multiplatform Language) technology courtesy of "Spac3Rat" and technology evangelist (also known as Sèrgio). I was finally persuaded by a combat-helo moving map demo he wrote and sent to me. Much impressed by this map in a web-browser (works on tablets too) I've added JSON functions to combat-helo which will push out pretty much anything we want from my instance of the game. So all flight model, AI and waypoint data will eventually be pushed, just to see how far it will go.
SpaceRat's browser based real-time data app
One of the problems I've had during development is getting at simulation data while the game is running. Mostly this is a display issue, real-time watching of HTR and sensor variables on screen tends to make everything hard to see. Putting it onto a kneepad real-time seems like a win-win as this can be used in the released game for all kinds of cool stuff I can leave end users to play with.
I hope to bring you a link so you can watch test flights around the map in real-time in Google Chrome real soon. Won't be thrilling but at least you'll know when I'm working, or not working :)
My book was published on the 18th of Feb. This is a companion guide to anyone wanting to learn how to use GROME. It also covers plugins and scripts for exporting to other game engines. GROME is kind of like Photoshop for terrain.
I want to quote from the forward at the beginning of the book as it's addressed (in part) to you guys:
Finally, a big thank you to the simulation community, SimHQ, and various individuals that continue to be supportive in the face of my endless and annoying prevarication and distractions (of which this book is but one of them). Sorry! Art is never finished, only abandoned.
It uses the Graphite Engine which comes as an SDK with every GROME license. Streaming and paging comes as standard, originally designed for use in an MMO.
Now that project is over and done with, Combat-Helo development will now resume in earnest. Watch this space.
Crazy amount of work with three crunch times on the go. I just sent the final parts of my book, Grome 3 Terrain Modelling for Ogre3D, Unity and UDK (or whatever order it ends up in) to the publisher "PackT". Publication won't be too far away. Thanks to awesome technical review work at the guys over at Quad Software (www.quadsoftware.com) they kept me busier than I'd hoped :)
There was a CombatHelo development blog update scheduled to be auto-published in 2 days time but I've now delayed this till mid-February. Since I'll have time to complete some more development work this seemed prudent (as I didn't complete the AI material in the blog after falling ill over Christmas). I've once again trimmed the game feature list, removing the first-person on-foot component (until the Afghan campaign). Currently the game is going to feel like an in-depth Novalogic'esque production but manageable given current time constraints.
If you don't follow my occasional ramblings on LinkedIn or Twitter, I'll be spending the next few months focused on assembling playable build which I'll be taking down to the Weston Super-Mare flight-sim show this May. Although I should warn that I'm only going there to hang-out with my pals from Komodo Simulations and just soak up the atmosphere (and maybe a few brewskies).
Parting shot: When you put crew speech into a game, annoyingly it means the crew models have to lip-sync otherwise it looks weird.
