Collapsing Structures

Since this recording was made, rubble models have been restored so the ground level debris is looking as it should.

Just a few more FX states to add (fire and flammables where indicated) and then pretty much 98% of game entities (other than trees which we can't do anything about) should be destroyable to some degree.

With visual settings turned up a notch

Night fishing

I'm in deconstruction - Structure Removal

Structures database is now installed. Currently going through the damage functions making sure structures can take enough of a beating from thirty mike mike. Materials having different properties require slightly different effects. Some entities will explode, some crumble, some give off secondary explosions. Fuel storage tanks when ignited should destroy any nearby lightweight vehicles or structures.

For testing I got make a new fast loading playground and recreated some scenes from a golden oldie, Novalogic's Comanche Maximum Overkill. Again forgive my programmer art/map design skills, they do what I need them to do.

Far too much fun. I'll get the bulk of this finished over the weekend. Some of the effects I want to achieve is a simple building collapse into dust (vertical movement into the ground masked by emitters and covered with a rubble mesh). I put in a few chimney stacks to see what I can do with those.

The gas station (we call them petrol stations or BBQ centres) is going to be a little tricky as like a lot of the more complex models in Combat Helo, they are reduced to single meshes for performance reasons. We had a discussion about blowing holes in mud compound walls and making them persistent, meaning a damaged wall will stay damaged for the duration of the campaign. What makes this tricky is that these walls are 500 instances. Internally the graphics card has one wall and draws the same geometry many times in different places. And variation in such structures has to be handled at the vertex shader level using some parameter that is unique to each of these 500 wall copies. With the Leadwerks engine you have two things you can vary, the vertex colour, and vertex alpha (one thing if you want to be pedantic). So we're going to implement a vertex shader to put 'breaches' into wall sections based on bit patterns in the mesh colour.

The idea being, rather than the literal approach in FPS games (hole at the position of missile impact) we'll adopt a tactical approach. A tactical breech will occur at a fixed location but enables a point of entry/escape in what would otherwise be static geometry. Functionally the same.

Scoring

Scoring (yes post mission scores just like in the old days, when I didn't have grey hairs) are going to be calculated from the structure values of buildings/vehicles along with realism settings and mission difficulty. With deduction for ordinance expended and mission outcome.

Also I want to finish up the player edit dialogue this weekend (dedicated to getting the closed beta ready in August).

Have a fun weekend.


*update* AD has been working on special destruction objects.

Quick update

I added ADs new vehicle database, he added some fields which will be great to use later. Some of the effects didn't scale correctly when using the data so I'm in a process of tweaking the effect elements as I come across them.

And just this minute I took delivery of the structures database so will begin adding that now. Buildings will have to collapse into a lot of dust and smoke, not so much fire. We have some rubble models that I'll try and blend in with the building destruction.

Manuals, key bindings and more

Organising the key bindings and adding missing functions. Adding these to the game manual as I go. Six down, about 100 to go....*sigh*

*update* Now up to about item 30 in the command list, new combos and logic for snapping to MPDs and back again. Much smoother and logical command key flow. Shneiderman's Golden Rules of Interface design serve as helpful guidelines for putting together any kind of software interface. The main ones being reduce short term memory load (by chunking), consistency in command grouping and short-cuts for advanced users.

The vehicle database is now being loaded, still to do, put in db lookups where needed (during damage updates and effect triggers). I'll finish that in the morning and hopefully we'll have the structures database ready to include soon after. That will stop things like barns and roads exploding. I promised a video of some pyrotechnics and this will go some way to make it a bit more logical. No video till I'm done with this weeks job schedule, also I want to do a more cinematic weapon cam.

Headtracking with padlock view is quite a powerful way of gunning targets, look at an object, hit padlock, line up as required and rain down some 30mm till either you overshoot or the target is destroyed.

Gobed - Game object editor

A tool to let us tweak settings in game on the fly has now been passed to AD for setting up all the necessary data for the firing range. I have a very busy week ahead putting in a number of features needed to get the game ready for the first closed beta testing.

I got the go-ahead to start updating the flight model with the current FM code from the test-bed, it feels very stable, Fred added a function to write out data for analysis, so even if the instrumentation is faulty there's some virtual flight recorder data to examine. HTR has proven to be a predictive flight model, behaviour in the flight model being later observed in a real helicopter. Looking forward to getting this bedded down. I'm sure there will be a lot of tweaking to do later.

The official web site still has a mid 2011 release date on it which I think is a little optimistic unless you consider closed beta a release (unless it escapes). Someone needs to take these dates around the back and given a good seeing to with a cricket bat.

AD proposed we call the firing range Operation Kickstart which prompted a round of YouTube viewings of the BBCs Junior Kickstart programme and the amazing antics of champion Dougie Lampkin.

Achievements - the things you didn't know

While putting some of the player recording keeping together I was debating adding achievement records. While you might think they are throw-away pop-ups, even to the point of being annoying, what you might not know is that in the console world these systems are rather sneaky ways of gathering information about player habits.

They tell a publisher how long people play games, what mode of play they prefer, how far they progress, what sort of game mechanics they adopt and much more. This data is automatically uploaded and can be mined for all kinds of information that go some way to shaping the sort of games that get made.

It's all good clean data that's of more value to the likes of SONY and Microsoft than it is for bragging rights.

Oh, I just unlocked an achievement, "Time Waster - For blogging instead of  getting on with some real work". Hope my boss doesn't see that one.

Player profiles

Following on the work to add more of the elementary game components, player profile data is loaded at launch. This stores career values like:

• Name
• Rank
• Squad patch
• Last map loaded.
• Flight time

Not much else yet. Tomorrow I'll finish off the kill counts, score etc. That needs to go into the class dealing with weapons fire I think, need to chew on that. My early diagram says player kills are registered post flight as part of the mission debrief but it's possible for the player to avoid the debrief in an open ended environment.

I stole eight US division patches (1st Cav, 1st Infatry, 2nd Infatry, 10th Mountain, 21st Cav, 82nd Airborne, 101st Airborne), there will be a few more to go in.

Fixed some command console issues, also I like to have the '/' slash key ready to take a command so fixed that up. Currently it's the only way to set altitude bugs till I get a working Keyboard Unit into the cockpit.

Also added some fade in/out callbacks for special effects and scene/mode transitions.

I will try and encrypt player data to prevent casual 'cheating'.

Horse before the cart

Just to show the standard game menu which has only just been added. You'd think it would be one of the things you might put in first?

A quick tour, of the game start-up. The client application will load the last session map (or default) and position the camera over your last location (base object if that data marker is available). If no base data is present it defaults to the player start location as written out by our map editor.

Currently there is no campaign data for the firing range (never needed it till now) so no helicopter or pad information otherwise those pads would be populated by Apaches or Chinooks.

On the main menu we have the thumping background music as previously heard in earlier videos and a Predator drone style orbit camera with desaturated video and video line effects going on. We could probably put in some HUD effects for extra presentation points even moving the camera focus from target to target across the map (e.g. below).

My aim was to try and pay homage (rip off?) the old Janes style base menu screens which were spatially compressed to fit many base features into a 640x480 screen. When you do this in 3D it looks ridiculous if you have to PLAY in it. But what will be added later is a shortcut, click on the hangers or aircraft to jump to that location (after triggering the first menu item).

I have the campaign save state to do so once that's done the first option in the menu should change to  "Continue". Selecting the first option will always zoom you down into the player controller (little guy) who's still looking a bit strange (cuboid with a ball for a head).

Also fixed, Apache weapon hot keys, broken Apache exit (slight co-ordinate mis-calculation).

Audit time

After a quick review of what's to do prior to closed beta release for the firing range...this is a subset of a larger list but represents the most significant.

• Initial user settings and hardware detection / configuration.
• Overhead menu for options and mission loading.
• Progress bar scene load (game will appear to hang when in fact it's still loading data).
• Manual cockpit view panning and seat adjustment (offset).
• Crew model adjustments.
• Advanced flight model update.
• Landing gear dynamics.
• Exotic rockets warheads.
• Stores jet.
• All human crew speech (recordings), will substitute with text messages for now.

I skipped a ton of small changes, things like missing command key assignments which can be done quickly in a a couple of passes.

The tools for the databases I fell down on, I gave them to someone to fix but they didn't do it, that's my responsibility for not pushing as hard as I should have.

The timing is good since starting this Monday I now have a longer working day. Working to crunch favours my personal work style; Just-in-time panicking. There's a ton of things I'd love to improve but for now it's just good enough and there will be time to perfect these things later.

There's some obscure avionics logic bugs that are hard to track down, modal lockouts relating to weapons mostly, if I had to do it again I'd use bit fields instead of nested IFs.

Screen-shot of the day

Shouldn't blow stuff up in your face. Player damage is being recorded by not yet actioned.

G940 now with LED control

Today I added some code to apply any OEM specific support in our DirectInput controller DLL. Here is a desk photo of the G940 throttle unit with the buttons cycling through each colour (green, amber, red, off). I had some link issues with Logitech's supplied LIB and I hope it's just confined to the debug symbols (turning them off fixed the link error).

Tempting to program a game of Simon for it.

The force-feedback functions are done but it's worth mentioning that there's a gulf between a powered joystick and simple force-feedback. What I'm finding is that the range of powered motion doesn't always match the full range of motion in the joystick. Those mechanism are typically designed to apply force sensations for gaming purposes. I had high hopes that such devices could simulate a force-trim system but not all devices are created equal. They can approximate to varying degrees.

If you're in the market for a new HOTAS and considering one of these for a helicopter simulation then I suggest a forum search for Black Shark players and the G940. I'm personally torn between non-FF and this device. The lamp buttons are kind of cool but presently there's no way to link them to game values.

In Combat-Helo, the virtual cockpit data contains information about switches that are considered lamps, there's logic to switch lamped buttons on events. This is an obvious place to add a hook for a devices 'lamp' list to illuminated cockpit switches. And I could add some fake ones for RWR warnings, it should be quite quick to implement that way.

Finally I'm able to map the funny guarded "arm" switch on the Saitek X65F with this new wrapper, that joystick has 50 mappable buttons alone, never mind the POVs and axis. It works fine alongside the G940.

Other news. It's almost time for another progress video. There's some niggling issues with the rocket aim to sort out, when I'm happy with the rockets I reckon it's time to show off some firepower.

If you have some cool non standard hardware device that we can support in Combat-Helo then email richard at tricubicstudios dot com.

DirectInput - Logitech G940 support

Logitech have been really great in offering some hardware support, enabling me to add force-feedback into Combat-Helo. So thank you to Logitech for that.

Force-feedback support was not planned for first release. We were not using DirectInput, I had spent a  time working on improving a cross platform library which on the Windows platform used SDL (Simple Direct Media Layer). This has a number of caveats, namely support for limited number of axis per device and originally only 16 button support (which was extended to 32). Some throttle axis were not recognised under SDL due to the way the manufacturers drivers sample down the input mapping to fit the Windows Media library which SDL uses. If a HOTAS has 16 axis and you can only choose 5, some are going to get missed. It was going to be a problem later and I knew it.

Two things were going to happen, either I had to write a DirectInput interface or wait for the Khronos group that oversees the OpenGL specification to introduce their own cross-platform input/haptics library. Since the latter didn't look like it was happening anytime soon the former seemed inevitable.

Then someone on SimHQs forums asked a question about force-feedback support and in particular drew my attention to the G940. Let me quickly explain something about how helicopters with flight control systems work....

The cyclic (joystick) control commands the main rotors to provide more lift in the direction you move it (keeping it simple here, there's a whole can of physics whoop-ass behind this). To maintain a forward airspeed you might be required to physically hold the cyclic in one position for a length of time. With normal PC joysticks, those with strong self-centring springs this is impractical. Not only is it fatiguing to hold something against a strong force for any length of time it's not terribly realistic.

Since I tried to design the game to be adaptable to be playable on a wide variety of controllers, from XBOX 360 joypads (twin thumbsticks) to full floor standing cyclic replica controls (such as those created by Komodo Simulations Ltd.) a common solution was to implement a software trim system that was invisible to the end user. Auto-Trim would covertly position the virtual helicopter cyclic back to the centre position over time and part of the advanced flight model (AFM) provided by the HTR flight physics engine.

Then there's the manual trim option for joystick hardware that can provide either an electric clutch or force-feedback to hold the stick in place. This is where we run into problems using a library like SDL. It doesn't work too well here either.

It was the last straw. Time to make the change. Sadly I've been here before, MinGW (among the fastest compilers made) hates me and never liked compiling DirectX headers and linking the 3rd party libraries. So what I did was create a DirectInput interface using a DLL in VisualStudio2010. Now all advanced hardware is being detected, including 3DConnexion's Space Navigator 3D mouse which is a brilliant navigation device.

As it happens...

The provided software for the G940 installs an SDK for accessing extended features of the hardware.

What extended features? The split-throttle unit has 8 LED buttons (as it happens there are 8 bits in one byte). A small library is provided to Get/Set the red and green LED status as two single bytes. If both red and green bits are set you get orange. And you can remove the caps and put your own legends under them. Seems like a good idea to add warnings/status light mapping to these switches.

I'm just stoked that the problem of full input mapping is sorted. I'll be adding more of the force-feedback functions to the DLL over the next few days among some of the other avionics features that are currently being finished.