More bug fixes

When Comments go bad

More progress to report this week (will update weekly till we release). The broken input functions are no longer broken and the Apache is now airworthy. I'm to blame for not paying attention to how I use comments in code. (I'd hard coded the device index during a debug session a long long time ago and commented out working code...for some reason.) I know at least one person who will be disappointed by my use of comments. There's a school of thought that suggests comments serve no practical purpose in source code. Code should be written to be fully understandable without comments in the first place therefore comments have no place in a source file. Not sure I fully agree with this but since I got stung by commented code it's one I'll look at more carefully in future. Another lesson learned.

Next up to fix...stores

Now that controllers are working again it time to go back to the stores to finish implementation of the rockets and Hellfires. My effects for building destruction are simple at best, could certainly use more pyros, especially on the gas station.

The soft-particle shaders are darker than they should be. That's one to investigate (possible suspect is missing terrain layer which might be used to modify the particle color). In which case it's just an art problem.

Macklebee (aka Mike) from the Leadwerks community has graciously donated some of his time to go over the Apache LUA script. He found a number of issues as well as some oddities in the Leadwerks engine. Since Leadwerks 2.51 isn't being supported anymore we'll have to try and find ways to work around them. These include joints that spawn at the world origin and creep towards their set location. Another problem seems to be having aircraft joints in contact with the ground when spawning them. Any collisions that occur before joints are set creates numerous problems. Seems the trick is to set the vehicle mass to zero during initialization, wait for a *single* physics update and THEN set the vehicle mass. This should fix the problem. 

Mike is welcome to code review everything from now on.

Work Items this week...to fix:

• Rocket ballistics
• Hellfires and MFD pages to finish
• Bobup-mode HUD
• Crew event speech
• Assorted polishing issues (particles, range events, rain/weather)

Facebook

I'm now a regular visitor to our Facebook presence if you want to engage in idle banter or ask questions that don't involve release dates (as according to my wife I exist in a separate space-time continuum) then please stop by https://www.facebook.com/CombatHelo

Parting thanks

Finally I want to thank again Macklebee and Klepto2, both from the Leadwerks community. Mack for his help with some bugs and Klepto2 for assistance with his extended NET DLL which exposes and adds much needed functionality in the Leadwerks engine. 

More updates soon.

Update on the Audio

Adding crew speech is a lot of fun. It adds so much to the feel of flying. At the same time it's quite labour intensive and I've discovered a lot of short-comings that I hadn't anticipated.

For example; pilot voice types. You have one set of recordings so you only have one pilot. But what if I want more, or modders want to add different voices for front seat and back seat? Then I need to pass not only the phrase but also a pilot ID or index. And what if the phrase is something that is repeated....a lot? And it's repetitive to the point of annoying? So a single phrase may have a choice of multiple speech samples. All of this needs to go into a small data file. But I'm not doing that now, instead I'm keeping this simple and allow room to 'big it up' later.

I added a frame-hook when the TGameAudio class is instantiated. The hook listens for any crew speech that's been cued or playing. When it detects that speech is ready or completed it also plays background static and a roger bleep effect. I'm pretty sure internal comes doesn't have a tx bleep but you often hear background noise. I added a tx bleep to test it and it sounds better than I expected. I now need to find someone with a Californian or a Texan who can supply me with a never-ending flood of phrases, there's always room for more or even variations. At an average of 7k of memory per phrase there's room for more.

Final audio is saved as an OGG file at 8,000 samples.

Another sprint

We're on another development sprint.

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.

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.

Bi-annual update, I'm almost joking. (title was: Hell hath no Fury...)

"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.

Data Export - Debug and Multiplayer Ops (using xRTML)

Another quick update.

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.

New sprint cycle - Data extraction

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 :)


Enough chatter. Back to the sprint.

Book Plug and moving on.

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.

Now available from Amazon US: http://amzn.to/UCXeQH
And in the UK: http://amzn.to/12GRoRZ

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.

You can also buy direct from the publisher which may still have it at the pre-order discount here:
http://www.packtpub.com/grome-terrain-modeling-with-ogre3d-udk-unity3d/book

GROME is a product of Quad Software and available here:
http://www.quadsoftware.com/index.php

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.


p.s. Thanks again all.