November update - blocking scenes and adding some wow to a firing range

*update 27-11-13*

Fixed some start-up logic. Systems should now operate when the correct bus voltage and power src is switched in. This is mostly all automatic in the Apache. Once the APU is up, everything should be available (except FCR which I'm guessing is a huge draw), once main engine power is above 84% the generators take over and APU can be switched off.

There's no logic for tripping the generators (currently) so no need for manual intervention. There are two switches above the radio knobs in case that changes.

The cockpit view now responds to g-forces which greatly adds to the feeling of flight. Rising and descending is met with a small amount of corresponding head movement. Subtle yet feels totally natural.

* end *


First a shout out to followers in Hungary http://t.co/RfjN93a2Pe I have no idea what you're writing about us since I don't speak the language but I'm going to assume it's all nice things (or grumbles about release dates). Either way, don't tell me.

It's been a week of relatively good progress. I fixed some nagging MFD issues I spotted during the live Twitch.TV feed (all relating to a single method that gets the AirState). The game loading is much more slick and professional (it feels faster). Currently I'm expanding the audio functions to accommodate ATC and Range Officer speech chains.

On the whole Gunnery isn't quite the game we set out to make, it's a mere hint of what we wanted to do. Having eaten my fair share of humble pie and admitted the Afghan campaign is a bridge too far, Gunnery seems like a natural milestone. The vision in my head of a working live-fire range frequented by gunships from nearby airbases seemed reasonable. Trying to make it entertaining and leave everyone wanting more is going to be a tricky one. Just how much "wow" can you add to a training field? The simple narrative has you preparing for what is to come using lightweight story telling and names that will carry through to later games. No direct to camera speeches or lip synced models here.

I've been blocking out some set pieces to create a sense of constant activity on the range. New dialog will be required to handle it, audio goes a long way to create a sense of a living world. Additionally everyone will be able to edit and load XML based mission files that will spawn objects to shoot at (and some can shoot back).

A blog feels naked without a pic, some of these I posted on Facebook recently. Two of these show attempts to create interesting looking events around the airfield. The idea is to have training flights from off-map bases arriving, then lining-up for the days exercises. You are encouraged to hover taxi around without hitting anything. (horrible run-on sentence corrected)

There will be the live-fire component, flight school grading and score sheets. Exercises will use cannon, rockets and Hellfire missiles (both laser and radar guided). Still working on those, no video yet.

Guess what engine we're using?

Winter wonderland - real-time changes to vegetation

Ultimately what we set out to do back in 2009 was create Longbow 2 with Trees. When Gunnery is released we will be close to realizing that goal. In some ways that seems an easier destination than the real-time dynamics of the campaign we wanted to stage around Herat. However we have the Herat theater Dave built awaiting me to do something with it.

That's it until next week (but I expect o lot of you are playing with new XBOX's and Playstations anyway).

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.