ASE, Master Warning and Master Caution

Sales brochures are always a good place to start when you want some screenshots of avionics (that and Google images).

ASE or Aircraft Survivability Equipment - is the name given to a suite of devices that interact, they act as the ears of the aircraft. Our combat game mechanic relies on paranoia, avoid being painted by SAM radar, pinpoint enemy launch systems before they spot you, and eliminate them using your stand-off missile capability.

Listening for enemy radars and presenting this information to the crew is the job of the ASE page. This has inputs for controlling active decoy systems such as the IR Jammer, flare package and radar jamming equipment.

ASE page from sales brocure

My version is looking similar, I can't quite fit everything on as I made the decision a while ago to increase the symbol size by 20% to make MPDs readable in the upright position for typical screen resolutions. The Autopage logic is going to be fun but perhaps not as much fun as the flare dispenser programming. The logic for flares should allow for salvos, interval between salvos and flares per salvo. This should look awesome with the Leadwerks engine lighting. I'm guessing flare programming ends up on the ASE UTIL page in concordance with other page types.

My take on the ASE Page

ASE alongside AIR SURV mode, no rings

I can't tell what the range circles are in scale. Will figure that one out shortly but I'm going to go out on a limb and say 2km per ring....or it's arranged by type with the biggest threat on the inner rings. Easy enough to try both. After trying the ASE with range circles alongside the Air Radar mode it looks confusing. For now I'll leave the rings off the ASE page.

To test the radar detection I'll have to script some radar entities, we don't have any model assets for radar units other than the SA-9. They may end up as deadly green cubes for now. The symbology appears to be the same as the TSD, easy enough.

This just leaves what to do with the symbols for different states. Time to crank out Longbow 2 to get a refresher. I'm looking for:

• Radar non active
• Active Radar (uh oh)
• Tracking Radar (about to have a bad day)
• Launch Tracking (bad day)
• Laser warning (LWR)
• Small Arms Acoustic signature

I realise the final one is a bit of stretch but I'm interested in how well this works after reading about UK Apaches fielding acoustic sensors that not only picked out small arms fire but determine the direction. If it's like equipment tested elsewhere it should be able to determine what weapon is being fired. Useful in a support role. And perhaps too much like voodoo.

WAC

More warning tones have been added to the cockpit which are part of the WAC warning and caution system. These audio warnings go off at a regular 5 to 10 second interval until you acknowledge them by pressing the appropriate warning lamp. The Z and X keys have been mapped to the warning and caution ack switches accordingly. If it does it's job it'll have you swearing at it every time it goes off, something the wife can join in with too (and I speak from experience).

Very happy with the team who are finding time to squeeze in what they can especially over the holiday period. Sérgio has been working hard on a new web site and forums for Combat-Helo. No eta on when it goes live. When it launches this blog will be migrating to the new site. To date, my personal dev blog has had nearly half-a-million views, golly.

I'll be sad to see this go but the new site will have everything under one roof. News, updates and forums. Not just for Gunnery but everything we have planned beyond.

Alpha testing will start soon. That's quite a big thing for me. It represents letting go of something I've been really protective about (paranoid even?) for years. More than a few nights crying on sofas with the stress of juggling workloads and expenses. Looking forward to getting a chunk of outstanding work items done over the holidays. If we can cross off a few more big ticket items early next year we can then focus on content.


And now for something slightly different.

Unigine Helicopter Demo

I cant post a blog update this week without mentioning the other amazing thing I saw. Everything I ever wanted in an engine. This week Unigine released video footage from their CIGI compatible Rescue Helicopter demonstrator at I/ITSEC 2003 Orlando Fl. The level of detail is pretty amazing. A physical cockpit with instrument integration, multi screens (client server based) and a totally immersive simulator. Just watch it. And if you've watched it already, watch it again. Kudos to the team that put this together.

The Washington state dataset is about 60GB. Yikes. Not that you really need this level of detail everywhere. I've had a look through it when playing around to take some screen-shots and you can tell there's a lot of data that's been imported from geophysical databases. I look forward to seeing a GROME plugin to export terrain tiles for this engine in the near future. It looks like it should be pretty compatible in terms of workflow and how the tiles are exported. I'm guessing World Machine was used (it was used in the creation of The Valley demo and benchmark).

Letters are powerful. For example, the letter "H" can attract helicopters.*

* Joke stolen from Milton Jones

New guys and the sprint continues

New Focus

Waaaaaaaaaaaay back at the start of this project we promised a kind of game that was Longbow 2 with trees. Between then and now that goal mutated to the point where it almost forgotten. Word of advice, nail your mission statements to the wall. If you ever loose focus it's there in front of you.

I'm still trying to figure out how to make a gunnery range fun and failing. I can create a set-piece, and ultimately that's all it feels like it is. Other than learning how to operate sensors and weapon systems, as a game it's not thrilling me yet. It's educational to a point but on the whole Farming Simulators have more grab value. We can do interesting things, it's just finding that right approach using what resources we have. A comment was made about how LB2 had real "pucker factor" as you never knew what was on the other-side of a hill. And that pretty much nails where we need to go with Gunnery. As if I'd forgotten. Well....I had. To this end we will add point to point exercises to our existing range map then later we will offer our Herat map populated with static enemy armor and SAMs.

New Guys

The team has expanded thanks to the contributions of Sérgio and Mack. Sérgio takes on the role of webméister and social media guru due to his experience and infectious enthusiasm (not to mention blunt honesty which is welcome reality-check).

Mack is better known for being one of the more awesome contributors in the classic Leadwerks dev scene. He's been reviewing some of my code and offering a shoulder to cry on every-time I hit another engine related brick-wall. Welcome aboard chaps.

Together with Fred, Dave and myself we've got a good crew with drive, honesty and commitment to help get us where we want to be. And even beyond that.

New Stuff Wanted

I've identified a couple of additional model assets we need:

• SA-10 launch vehicle and clam shell antenna.
• Hospital Tent

Range script amendments are in progress. More fixes this week.

I've partially re-built the range map using GROME just so I can bake experimental color maps for the Leadwerks terrain base layer. This is an attempt to add variation and color tone. Dave pretty much did an awesome job with the tools at hand and seriously hard to improve upon. Roads have been a major PITA since Leadwerks road objects are a very simple implementation that only work on tiny maps. They rebuild at run-time during a Leadwerks Update() using a script which results in a 90% drop in performance until they are complete. Ideally we want to save these out as meshes instead of re-building them, this is how we currently implement roads, as exported meshes. Very fast and performance friendly. It's a trade-off between speed and aesthetics. The goal is to keep the FPS between 30 and 60 on a middle of the range gaming PC.

Fred is lending his flight dynamics skills to re-factor the flight model code. Hellfires are getting a wep page make-over.

Not so new Screen-Shots

Gratuitous screen-shots shown on Google+ earlier follow:

The CH-47D is back as a prop

Apache spawning points on the base

Hey it's virtual Google Glass. ReadyTime not yet used.

I DoF my hat to you sir!

In need of some re-design work

Fire in the hold! Literally

I got a mug just like that. Maybe you can too in the near future ;)

Till next week....(additional updates may appear here)

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.

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.