Happy Holidays

I somehow managed to hit "publish" instead of save earlier. I apologize for the curiously abrupt email if you are among those that elect to receive updates in this fashion.

Let's try again.

Yesterday I was in my living room having family time, up on our wall sized projector screen I was browsing YouTube for a number of classic helicopter games. These included DI's Apache Longbow, Gunship 2000 and Jane's Longbow. Since it's the end of the year and it's the popular thing to do a little retrospective, here's some Longbow themed naval gazing followed by a little project update.

Let the old games begin

Starting with Gunship 2000 from my old chums at Microprose. This was a sequel to Gunship, offering a choice of three helicopters, the Apache, Blackhawk and Cobra.

Gunship 2000 "Do a barrel roll"

I remember having the Amiga version, only experiencing the superior PC version later. Some of you younger folks might be looking at this and thinking it's total crap. But imagine you hadn't seen a 3D patchwork landscape with filled polygons before. Ever. Some simulations had a basic mountain (pyramid) or two but this was starting to look interesting. There's a lot going on, apart from the hideous teeth grinding sound effects of the day. There's a battlefield, mission structure and a menu screen that my step-son said looked like "Theme Hospital" (meaning the clinically white base office).

It's hard to go backwards. You can't go back to these games anymore than you can revert to using a one button joystick. Evolution of game controllers and the complexity of combat simulations go hand in hand. Early versions taught us the language of these games and a generation has grown with them.

We have adopted more complex controllers and games. We demand more from them, expect more from them. At the same time we appear to have lost what was fun about these games. It's not not to see whimsy in the 'action themed' intro for Gunship.

The Nintendo Wii was successful as it reset the clock for gaming. Everyone including grandma could pick up the controller and understand it. You didn't need to be taught how to use a joypad or have any previous gaming experience. Is it possible to reset the clock for combat simulations? Apparently so, we are already seeing this, and they have proven to be very successful examples. World of Tanks and War Thunder are not deep combat simulations but they are teaching a new generation about the language of military simulations. A proportion of this generation will want more complex experiences, or at least different ones (we're so easily bored today).

Moving on....

Post Gunship 2000 in all it's VGA glory we had Digital Intergration's Apache Longbow. This was more like a real helicopter with authentic looking symbology. The format for Apache Longbow and the successor Hind remained mostly unchanged in games that shared their DNA, Enemy Engaged - Apache Havoc and Comanche Hokum.

Apache Longbow contained a training scenario which is similar in concept to Combat-Helo Gunnery. Hand on my heart, I swear this was unintentional. It was Dave's idea, maybe my subconscious remembered this aspect of DI's game. This is a video game approximation of a live fire exercise. A video is presented below. The fidelity of the flight model still stands on it's own. Smooth.

DI Apache Longbow Training Mission - Fort Hood

DI's games were more serious, throwing out the jingoism and had more in common with current dry simulations. Less game, more pain. Today, most of the hi-fidelity simulations come from eastern Europe and out of Russia. And it has to be noted, the best middle-ware too. Something to do with the higher education system, I just had a Russian friend stop by for two days (he's currently attending a game degree course at Abertay university and something of a math prodigy). His description of how they teach mathematics in Siberia made the hairs stand up on the back of my neck. It sounded more like "know everything" or you're out, only the mentally fittest survived. He then proceeded to diagram an algorithm for personal happiness which I totally failed to comprehend. Must be a Russian thing. Just give me some cheese and a glass of Port (I'm easily pleased).

Jane's Longbow 2

Time to review some Longbow 2 footage. A great game in the day (1996/7) and one I continue to reference as the ideal balance between difficulty and replayability. Sure it's lacking ground detail. Everything we would love to fit into Combat-Helo is here. This is our aim, a stand-alone simulation game. While we'll have some basic live fire exercises for the firing range, I want to squeeze in a "point-to-point" scenario, a random placement of air defense units and a primary / secondary target. There's a nice area of hills on the gunnery range ideal for this.

Here's a trip down memory lane, the "instant action" mode in Longbow 2.

It still contains a good balance of difficulty and replay-ability. The multiplayer (when it worked) added a huge thrill. Dual-seat co-operative play, multi-ship flights and different mission roles. Plus you were never very far from mission objectives. Campaigns could be played cooperatively spread over days or weeks.

The avionics of the Longbow were significantly reduced in complexity, even allowing missions to be mostly flown on autopilot. The rich pool of radio transmissions that played in the background from both ground forces and AI flights made every game a rich "combat" experience. Even if you just stat idle at the FARP you were reminded that there was a real battle going on out there. And you mattered. You could go and find those guys sending out those maydays and help them out. Or not. It was up to you. So much depth in such a "small" package, not many combat simulations today have been able to come close to this. Some games script it, but it's scripted and it shows.

Hardware Of The Year - The Year of the Oculus?

The most talked about hardware of the year has to be the Oculus Rift. Despite it not yet available as a commodity item everyone was talking about it. Being a victim of VR technology in the 90s I'm still on the fence. Convenience still trumps quality in all sectors and the reasons why VR didn't explode 20 years ago have not changed that much. I suspect like Kinect, it will sell like hot cakes but not get much use in the home.

I keep getting emails about Oculus support in Combat-Helo. Short answer, no. That's mostly down to Leadwerks Engine and not having a dev kit. I don't see a compelling reason to get one for flight simulations, when I play a sim I'm often looking at keyboard and switches. I own a MIG welder and welding goggles for really serious PC repair (and bodywork), it's a pain having to flip them goggles up and down all the time. Guess I need them goggles with an automatic LCD plate. I've seen a simple WWII sim working really well with these so I guess it's down to what you can comfortably learn to do on your HOTAS.

We've been looking at Unigine recently with a couple of other engines for a post Combat-Helo Gunnery project which do support Oculus. If it's easy to do we'll do it. Simple as that.

CastAR from Technical Illusions is a slightly different story. Often overlooked as it's not as sexy as VR, despite being fully capable of VR. With head tracking built into a simple pair of glasses and two micro-projectors your natural vision is not impaired, you can see all your keyboard and joystick controllers. Making your visible screen bigger is as simple as adding more retro-reflective material around your cockpit space, painting MFDs onto a physical cockpit layout. I'm just spit-balling here as I've not seen how good the native resolution is going to be. MFDs will need 512x512 resolution minimum and has to be readable from 2 to 3 feet away.

NaturalPoint should take a tip from these new Kickstarter projects for their TrackIR consumer division. My LED Antlers have been laying withered and broken on my desk for 2 years. Hear that NaturalPoint? How about adopting some new technology that's compatible with your DLL? You can buy these things called "accelerometers" in chip form that cost next to nothing. You can ditch the whole IR baggage and call it TrackER.

In terms of hardware released this year the LeapPad was both exciting and disappointing. LeapPad is a small mysterious black rectangle that sits on your desk with nothing but a micro-usb cable running to your PC. It uses three IR LEDs and two angled cameras to read gestures in it's field of view. The smart stuff is all done in software so it's a fairly inexpensive add-on. My experiments for integrating it into a simulation cockpit were not great. Limited by it's field of view and only from below, basically pointing a finger at an MFD was all I managed before giving up in frustration. As a virtual pilot I want to hold my hand in a vertical position to perform hand gestures, rather than a horizontal position for playing air piano. To do that I'd have to mount the device on a nearby wall or stand.

Saitek made us raise a collective (no pun intended) eyebrow with the announcement of a new HOTAS. The X55 pictured below.

I don't have the inside scoop on this, it was a real (but nice) surprise. Since I LOVED utterly the metal build quality of the X65F but hated the force sensing (for helicopters they don't work). So I've been using my tried and tested X52 just because of it's movement. This X55 looks like it's the best of both worlds, the same flexible all-round no cross-centering spring movement with the metal build. It comes with extra gizmos that are perfect for manual start-ups, adjusting cockpit lighting, symbology adjustment.

Work update

Keep running into silly things that slow you down. Recently the tail wheel assembly of the Apache. We got the springy suspension working but the model hierarchy for tail wheel articulation isn't correct. The crew limbs couldn't be animated as we need them in a T-pose to apply the bones. Also I think the crew scale is slightly wrong. Check this pic out....

Crew scale against cockpit

Winter is coming. One of the lasting impressions I have of my early combat gaming comes from the original Microprose M1 Tank Platoon, the cold winter landscapes juxtaposed with flying HEAT rounds and burning wrecks. It provided a welcome change of scenery. A few weeks ago I started applying a snow shader that uses the up normals on a model to apply a snowy texture. It's a lot of work to go through every model material definition to update them. The results of this shader applied to the M1 tank is shown below.

Once applied you can set the snow coverage in real-time from 0% to 100% by setting a shader uniform. This almost never made it as a feature.

It presented a small problem for vegetation models since Leadwerks creates billboards which are generated on a first use basis. Once you apply a snow texture to a model you need to update the billboard. Fortunately you can get access to Leadwerks vegetation billboards like this (where the index 0 is the vegetation layer 0-15).

TTexture tex = leadwerks.engine.TVegetationLayer.billboardtexture[0]

With a little shader magic this allows real-time manipulation. You can see a glimpse of these experiments in an unlisted "Thank you" movie I sent to the team on Christmas day (I'll link that at the bottom of this blog). Oh to have an engine that does all this stuff for you.

Right now we're wrapping up additional game effects such as flares. Mack came up with a pretty tight working concept after watching some of the impressive air show displays where Apaches equipped with flare dispensers go 4th of July crazy. From these videos he got a feel for how they behave in flight, coming up with a working prototype. Just like our 30mm shell ejection we're using physical bodies for flares so they bounce off objects roll around. Pretty neat. The Leadwerks particle effects won't win any awards.

So while I'm supposedly finishing off the ASE gear, I've also been tinkering with the landing gear dynamics that Mack fixed up. It's easy to get distracted when nobody is looking over your shoulder.

This devs test map - random screen-shot

Next on the list is adding the AI to get AIRDEF units to search and destroy. Mack is back on figuring out how to tackle the damage modelling. He's got some ideas on swapping out child objects in the vehicle hierarchy. It's the sort of fudge you get used to with Leadwerks.

By way of a thank you and Merry Christmas to the team I sent them this short music video containing just some cockpit g effect footage and tree billboard tests.

Happy holidays from "Mossie" (or Mossy if you're from the wetlands). You'll have come across this chap on our Facebook page.

And happy holidays from me and the rest of the team at Combat-Helo. Here's to finally shipping in 2014.

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.

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.

Book end

Finally, time to post.

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.