A recent query on the SimHQ forums prompted a quick appraisal of scripted content. I originally only penned one opening story to be recorded for use in trailers and/or training mission at the start. We don't have the resources to do much more than that, and I'm not really sure more is needed (it would be nice to have more but gamers are smart and like to push in their own direction).
As the campaign is mostly dynamic there isn't much mission building needed. To break up the mission variety we came up with some simple to implement content. There's the 'deck of cards' intel-collection quest, ambient quests (short versions of campaign engine generated sorties collected whilst flying) and some scripted missions just like Longbow 2.
The deck of cards content is reasonably easy to assemble. The scripted mission content requires more of a story telling flair and using text with some recorded speech in some places we can embellish the hand crafted missions. I have a number of characters, some re-used from the opening introduction.
I'm assembling story arc ideas for the future. Cyclic has volunteered to play a British SAS officer and associate (I hope Druid will come and play too). I get to play a bad guy.
We have some content ideas I want to flesh out for the following characters...
- The "We Care" charity worker (female role)
- Italian liaison officer (no stereotypes please, Herat is transferring from Italian control at start of game)
- US Photographer
- Brit reporter
As much as I'd LOVE to include the Bermuda short wearing Camp Stone CO practising his golf drive out the back of a Chinook, it requires dedicated rigging and animation, things we can't do right now. So we need to keep it simple, limited to things that can be expressed as dialogue and moving vehicles.
Monday, 29 November 2010
Saturday, 20 November 2010
Little update on FFD and other things
Just wanted to clarify what's happening with regard to Combat-Helo atm.
The game is currently undergoing a little restructuring while it's updated to use the new version of the 3D Engine (Leadwerks). New input routines to support easier swapping of controllers, campaign data, networking has been tweaked for the dual-seat / peer to peer comms.
Fred, developer of FFD (Free Flight Dynamics engine) has been working on *new* version of his elegant blade theory simulation and is about 90% complete. Then it has to be ported to C++, the Combat-Helo implementation was parked until this is complete and then we'll look into how best interface it. I really love how FFD works, it's quite different to everything else I've seen and adaptable for any kind of vehicle that is a collection of complex forces.
I received the first processed APU audio and quite pleased with that. No time to slot it into the game yet. One feature I'd like to use from OpenAL is doppler shift, oddly missing from the LE implementation as far as I can tell. And now I have a need to queue sounds on a TSource and finding that feature lacking here too. Might have to use my own OpenAL implementation if I can't mix OpenAL API calls with LE OpenAL buffers.
The game is currently undergoing a little restructuring while it's updated to use the new version of the 3D Engine (Leadwerks). New input routines to support easier swapping of controllers, campaign data, networking has been tweaked for the dual-seat / peer to peer comms.
Fred, developer of FFD (Free Flight Dynamics engine) has been working on *new* version of his elegant blade theory simulation and is about 90% complete. Then it has to be ported to C++, the Combat-Helo implementation was parked until this is complete and then we'll look into how best interface it. I really love how FFD works, it's quite different to everything else I've seen and adaptable for any kind of vehicle that is a collection of complex forces.
I received the first processed APU audio and quite pleased with that. No time to slot it into the game yet. One feature I'd like to use from OpenAL is doppler shift, oddly missing from the LE implementation as far as I can tell. And now I have a need to queue sounds on a TSource and finding that feature lacking here too. Might have to use my own OpenAL implementation if I can't mix OpenAL API calls with LE OpenAL buffers.
Thursday, 18 November 2010
Wednesday, 17 November 2010
Mi-24v Tiger and InputMapper mk 2
Came across a DVD of the Royal International Air Tattoo 2006, a Czech Republic Mi-24V Hind (number 7353?) from the 231 Attack Helicopter Squadron had a camera strapped to the pylon. I've walked around a few Mi-24Ds at airshows but nothing as lovely as the tiger paint scheme on this one.
I'll just share a few images I grabbed.
The last image was taken by "Vojta_micek" (see his other photos here). Elements of the tandem cockpit appear modernised from what I remember. The all black theme
The Mi-24 is a fast twin engined helicopter, > 200 miles per hour. Versatile, with a small troop compartment/load area and large number of wing payload configurations.
Programming wise I've been re-engineering a lot of game internals to separate them more from the underlying 3D engine. And today that included an alternative input system. Short of using DirectX (which I have problems compiling under MinGW) there isn't a great solution for now. The SDL library falls short since it uses the Windows MMSYSTEM which only handles a few axis (6) and 32 buttons. It manages about 3/4qtrs of the axis and buttons on a new Saitek HOTAS PC joystick.
Ideally I'd use RAWHID which is a method Microsoft provide to read the raw data from any USB input device (there's a Linux library too). RAWHID would cover some exotic input devices, 3D navigators and touch devices for example but that will have to wait till version 2.0. For now I'm abstracting the input handling too, nearly finished with that.
Till now input configuration has been awkward, I wrote a quick and dirty config system last December. The cross-platform input library didn't even return a sensible name for a device on each, it was just a port number, if you unplugged or swapped them around you'd loose your input mapping. Terrible.
Now we have curve options, inversion, min/max range and device ID pulled from the Windows registry. An input monitor overlay with graph was added to help debug and test axis response. If anyone knows of a RAWHID multiplatform lib then please drop me a note.
I'll just share a few images I grabbed.
The last image was taken by "Vojta_micek" (see his other photos here). Elements of the tandem cockpit appear modernised from what I remember. The all black theme
The Mi-24 is a fast twin engined helicopter, > 200 miles per hour. Versatile, with a small troop compartment/load area and large number of wing payload configurations.
Programming wise I've been re-engineering a lot of game internals to separate them more from the underlying 3D engine. And today that included an alternative input system. Short of using DirectX (which I have problems compiling under MinGW) there isn't a great solution for now. The SDL library falls short since it uses the Windows MMSYSTEM which only handles a few axis (6) and 32 buttons. It manages about 3/4qtrs of the axis and buttons on a new Saitek HOTAS PC joystick.
Ideally I'd use RAWHID which is a method Microsoft provide to read the raw data from any USB input device (there's a Linux library too). RAWHID would cover some exotic input devices, 3D navigators and touch devices for example but that will have to wait till version 2.0. For now I'm abstracting the input handling too, nearly finished with that.
Till now input configuration has been awkward, I wrote a quick and dirty config system last December. The cross-platform input library didn't even return a sensible name for a device on each, it was just a port number, if you unplugged or swapped them around you'd loose your input mapping. Terrible.
Now we have curve options, inversion, min/max range and device ID pulled from the Windows registry. An input monitor overlay with graph was added to help debug and test axis response. If anyone knows of a RAWHID multiplatform lib then please drop me a note.
Sunday, 14 November 2010
Campaigns part 2
My previous field of work was the fascinating world of Risk Assessment. Software that monitored incidents, identified key risks and trends. It's been used as evidence in court cases and SOX Sarbanes-Oxley 404 (I kid you not) compliant. This work gave me an understanding of visualising trends and the mathematics of risk and game theory. (Moving on, William Boyd style)
One of the early games I worked on was a little ZX Spectrum number in the 80s, I did the all singing, all dancing Amstrad CPC and Memotech (unreleased) conversions of Next War. Next War was originally a very complex mathematical board game with hundreds of easy to loose cardboard counters, maps of the Fulda Gap East West Germany region, rule books and curved graphs that covered every kind of engagement you could think of. It's a rare game to track down but here's a picture I stole from a collectors site...
Cramming that into 48k was a challenge, indeed it couldn't be done on the 64k Amstrad without paging memory so it ended up as an early 'floppy disc' enhanced game or 128k model. Still surprisingly playable and I have a Blitz version half-written somewhere.
Over the months when I've sat down to sketch how Combat-Helo was going to work as a game, we knew what the conflict was going to be, the scope, how it would evolve and who the participants were. It had to be smart, never quite the same game twice. Also it had to retain the charm of the old 90's combat simulations, have a seemingly simplistic scope but at the heart would be a hidden educational agenda.
War is something that is hard to understand. Seemingly incomprehensible and I don't, (I hope I don't) make light or trivialise it in any way. What do scientists do when they don't understand something? Well, quite often they make a chart from data.
My hidden agenda with Combat-Helo circa 2002 was an accurate number crunching simulation of resources vs. the mission (originally for the Basra insurgency at that time). The mathematics of war is an interesting topic that's become better understood with the availability of information, modelling and work done by scientists like Sean Gourley (Oxford Physicist) from whom I borrowed some concepts for Combat-Helo Operation Ouroboros.
Using methods of data filtering Gourley's team identified wars/conflicts have distinct signatures from which you can make predictions. (See Telegraph article). Start by simply plotting size of attack against frequency. This line is also found in areas of Risk Analysis. These lines often comply with something known as "Power Law". Here's a graph stolen from Wikipedia.
Many natural and man-made incidents follow this power-law. Earthquakes are quite common but only a few are devestating, power-cut disruption vs population, size of craters on the moon and even the player rankings of any Call-of-Duty game. Players wanting to rank high require early adoption, more so in a hit based market, over time you'll end up in the same place regardless of game. It's one of natures rules. It wouldn't surprise me if Activision sales of these games followed the same trend, and an incentive to hike the price. This is something suggested by recent pre-order sales boasts at Activision-Blizzard.
Insurgency and terrorism follow the same curve. With a few deadly events causing catastrophic damage with many smaller acts carried through. Military planning in the real world can use this to predict the frequency of the next big attack, this is something you'll experience in Combat-Helo. By changing the slope (a polynomial expression) we can change the level of insurgency around the map, and the slope can be altered by many factors which you can influence while in the air or your skills at planning in the command tent. Not only can this be applied to COIN ops (pun partially intended) but also armoured and open warfare.
What you'll have is a reasonably realistic level of enemy activity regardless of scale.
One of the early games I worked on was a little ZX Spectrum number in the 80s, I did the all singing, all dancing Amstrad CPC and Memotech (unreleased) conversions of Next War. Next War was originally a very complex mathematical board game with hundreds of easy to loose cardboard counters, maps of the Fulda Gap East West Germany region, rule books and curved graphs that covered every kind of engagement you could think of. It's a rare game to track down but here's a picture I stole from a collectors site...
 |
| The Next War - extreme 80s board game |
Over the months when I've sat down to sketch how Combat-Helo was going to work as a game, we knew what the conflict was going to be, the scope, how it would evolve and who the participants were. It had to be smart, never quite the same game twice. Also it had to retain the charm of the old 90's combat simulations, have a seemingly simplistic scope but at the heart would be a hidden educational agenda.
War is something that is hard to understand. Seemingly incomprehensible and I don't, (I hope I don't) make light or trivialise it in any way. What do scientists do when they don't understand something? Well, quite often they make a chart from data.
My hidden agenda with Combat-Helo circa 2002 was an accurate number crunching simulation of resources vs. the mission (originally for the Basra insurgency at that time). The mathematics of war is an interesting topic that's become better understood with the availability of information, modelling and work done by scientists like Sean Gourley (Oxford Physicist) from whom I borrowed some concepts for Combat-Helo Operation Ouroboros.
Using methods of data filtering Gourley's team identified wars/conflicts have distinct signatures from which you can make predictions. (See Telegraph article). Start by simply plotting size of attack against frequency. This line is also found in areas of Risk Analysis. These lines often comply with something known as "Power Law". Here's a graph stolen from Wikipedia.
Many natural and man-made incidents follow this power-law. Earthquakes are quite common but only a few are devestating, power-cut disruption vs population, size of craters on the moon and even the player rankings of any Call-of-Duty game. Players wanting to rank high require early adoption, more so in a hit based market, over time you'll end up in the same place regardless of game. It's one of natures rules. It wouldn't surprise me if Activision sales of these games followed the same trend, and an incentive to hike the price. This is something suggested by recent pre-order sales boasts at Activision-Blizzard.
Insurgency and terrorism follow the same curve. With a few deadly events causing catastrophic damage with many smaller acts carried through. Military planning in the real world can use this to predict the frequency of the next big attack, this is something you'll experience in Combat-Helo. By changing the slope (a polynomial expression) we can change the level of insurgency around the map, and the slope can be altered by many factors which you can influence while in the air or your skills at planning in the command tent. Not only can this be applied to COIN ops (pun partially intended) but also armoured and open warfare.
 |
| Equation that predicts likelihood of an attack |
What you'll have is a reasonably realistic level of enemy activity regardless of scale.
Friday, 12 November 2010
Campaigns
This is going pretty well, planning and preparation over the months is paying off. If anything it's going too quickly as I find myself needing the games built-in editor sooner rather than later. I'm building this directly into the LE2.40 build to save time.
All your FARPS are belong to us.
Rather than have a basic game object "FARP" (Forward Arming and Refueling Point) we have "BASE" object of variable types. The structures for the base are made in the same way they are for mobile units, a list of objects expressed as offsets and rotations relative to the base location.
This is all stored in an easy to read and edit XML format.
Campaign stucture is currently set as follows:
That might give you a little insight into the 'firefighting' aspect of the "A-Side" campaign. There will be additional data to add later relating to consumables. For example, hard hit zones will be 'up for grabs' and require urgent re-supply or risk loosing ground in that zone. With limited supply levels and resources you will have to do what you can to can.
Having to hand-code some of this data atm just to get the loader and data set-up. More later.
All your FARPS are belong to us.
Rather than have a basic game object "FARP" (Forward Arming and Refueling Point) we have "BASE" object of variable types. The structures for the base are made in the same way they are for mobile units, a list of objects expressed as offsets and rotations relative to the base location.
This is all stored in an easy to read and edit XML format.
Campaign stucture is currently set as follows:
- Campaign descriptor, name, date-time start, text description
- Terrain map filename, lat and lon of mid-point.
- Faction list, text names, ID (Civilian = 0, US = 1, etc)
- Base list, name, ID, position, supply data, faction
- Base object list (optional)
- Unit list, faction, postiion, name, visibility
- Initial waypoints if any
- Trigger conditions
- Zones
- Villages, names, faction control, population, security level, intel quality, contested flags
- Family tree data
- Object list (optional)
- Map Markings, text labels, symbols, lines
That might give you a little insight into the 'firefighting' aspect of the "A-Side" campaign. There will be additional data to add later relating to consumables. For example, hard hit zones will be 'up for grabs' and require urgent re-supply or risk loosing ground in that zone. With limited supply levels and resources you will have to do what you can to can.
Having to hand-code some of this data atm just to get the loader and data set-up. More later.
Thursday, 11 November 2010
Engine upgrade progress
With a new PC build comes new responsibility.
Well, a new Intel i7 Quad Core running at ludicrous speed with an nVidia 460GTX (Palit) seems to shift millions of triangles without blinking. Certainly astonishing to see Combat-Helo over the city with all effects and TADS running at near fps cap (60hz) and only 20% CPU usage. Let the hand-brake off and it was soaring into the 90s and beginning to overheat.
It will shut down the card if left, so I'm having to find ways of throttling it. I think Star Trek Online had these issues too. Oddly, it only happens with the large map, and not the smaller test maps.
I've enlisted the help of gDEbugger, a handy tool that lets you 'freeze' and step through OpenGL programs, inspect states, frag programs (and recompile during execution), stats on state changes, bottlenecks, frame graphs, VBO composition, loaded textures and much more. I only have the trial version so it's a bit limited, so far it hasn't shed any light of the matter of the driver crashing (I assumed this was related to bad DDS files). I'm thinking there's some hardware fault on this card or a current nVidia driver problem with OpenGL4.0 cards. I'll continue to monitor, it doesn't seem to effect the other lesser computers I've been testing with.
I built simple test program in C++ and BMax to load in just the terrain (no objects) and that's all it need to crash the new build.
Lord of the Rings Online is now free to play in Europe and supports DX11 which is breathtaking with it's water effects. No other crashes except with the LE loaded map (editor loads and runs no problem). I hate these issues.
Apart from that, I've parked the cubic splines this week and have been continuing the slight re-structuring Combat-Helo to use Leadwerks 2.4, making it more modular as I go. I started last week with the new cockpit data and rolled that into one aircraft XML file.
Now I have a lot of quality audio from the airbase, it has me thinking about ways to integrate that to the avionics and helicopter classes. Trying to separate as much as I can from engine specifics to ease future portability to different rendering engines if needed. All of the instrumentation is just OpenGL, come this time next year I don't know if version 2.0 of combat-helo will be using Leadwerks 3.0 or something better suited to streaming larger terrains. But I don't want to loose the speed either. The Leadwerks 3.0 roadmap suggests great things might be possible if paged terrains can be streamed in as tiles that can be translated (for camera relative rendering). Speed and accuracy, having parts of buildings flicker slightly won't be acceptable to me in a second generation title.
For research purposes I downloaded a 3.5GB heightmap for the whole earth and parked that on my external project storage (a big cube that hums in the house, all lonesome, if only I could make it produce the eerie choir music from 2001 A Space Odyssey).
Looking through more jobs today, noticed Rockstar has opened a new office up in Edinburgh. I love that city, bloody cold but fabulous place to hang around...except for the local branch of Dixons.
Well, a new Intel i7 Quad Core running at ludicrous speed with an nVidia 460GTX (Palit) seems to shift millions of triangles without blinking. Certainly astonishing to see Combat-Helo over the city with all effects and TADS running at near fps cap (60hz) and only 20% CPU usage. Let the hand-brake off and it was soaring into the 90s and beginning to overheat.
It will shut down the card if left, so I'm having to find ways of throttling it. I think Star Trek Online had these issues too. Oddly, it only happens with the large map, and not the smaller test maps.
I've enlisted the help of gDEbugger, a handy tool that lets you 'freeze' and step through OpenGL programs, inspect states, frag programs (and recompile during execution), stats on state changes, bottlenecks, frame graphs, VBO composition, loaded textures and much more. I only have the trial version so it's a bit limited, so far it hasn't shed any light of the matter of the driver crashing (I assumed this was related to bad DDS files). I'm thinking there's some hardware fault on this card or a current nVidia driver problem with OpenGL4.0 cards. I'll continue to monitor, it doesn't seem to effect the other lesser computers I've been testing with.
I built simple test program in C++ and BMax to load in just the terrain (no objects) and that's all it need to crash the new build.
Lord of the Rings Online is now free to play in Europe and supports DX11 which is breathtaking with it's water effects. No other crashes except with the LE loaded map (editor loads and runs no problem). I hate these issues.
Apart from that, I've parked the cubic splines this week and have been continuing the slight re-structuring Combat-Helo to use Leadwerks 2.4, making it more modular as I go. I started last week with the new cockpit data and rolled that into one aircraft XML file.
Now I have a lot of quality audio from the airbase, it has me thinking about ways to integrate that to the avionics and helicopter classes. Trying to separate as much as I can from engine specifics to ease future portability to different rendering engines if needed. All of the instrumentation is just OpenGL, come this time next year I don't know if version 2.0 of combat-helo will be using Leadwerks 3.0 or something better suited to streaming larger terrains. But I don't want to loose the speed either. The Leadwerks 3.0 roadmap suggests great things might be possible if paged terrains can be streamed in as tiles that can be translated (for camera relative rendering). Speed and accuracy, having parts of buildings flicker slightly won't be acceptable to me in a second generation title.
For research purposes I downloaded a 3.5GB heightmap for the whole earth and parked that on my external project storage (a big cube that hums in the house, all lonesome, if only I could make it produce the eerie choir music from 2001 A Space Odyssey).
Looking through more jobs today, noticed Rockstar has opened a new office up in Edinburgh. I love that city, bloody cold but fabulous place to hang around...except for the local branch of Dixons.
Tuesday, 9 November 2010
AH64 sound recording
Thanks Recklezz for the stunning audio recording at Gilze-Rijen air force base. It's certainly going to transform the cockpit experience. Certainly loud too. My wife often comments, "Can't you make a less annoying game?"
A Zoom H4n, (product web page) is a mini portable recording studio capable of 24bit 96Hz and the results we're impressive. The audio will need some cleaning up, normalising to compensate for variable levels, the conditions for recording as you might imagine were less than ideal. If you need a portable audio recording solution for exterior or interior / voice work then this unit comes recommended.
Maybe Recklezz and Drummer will post a little more about their experiences with the full sized Apache simulator if you ask nicely :)
They have earned a place in the Combat-Helo hall of thanks. Cheers chaps.
A Zoom H4n, (product web page) is a mini portable recording studio capable of 24bit 96Hz and the results we're impressive. The audio will need some cleaning up, normalising to compensate for variable levels, the conditions for recording as you might imagine were less than ideal. If you need a portable audio recording solution for exterior or interior / voice work then this unit comes recommended.
Maybe Recklezz and Drummer will post a little more about their experiences with the full sized Apache simulator if you ask nicely :)
They have earned a place in the Combat-Helo hall of thanks. Cheers chaps.
Monday, 8 November 2010
Fingers crossed for good weather on Tuesday
Fingers crossed the weather is not too bad tomorrow at Gilze-Rijen air force base. Our man in the Netherlands is prepared for a day of audio recording for the Apache and Chinook.
Good luck Reck. Weather is pretty lousy here, high winds, low temps and rain, sat images and forecast is so-so. Expect wet weather and don't forget the 'dead cat' :)
Good luck Reck. Weather is pretty lousy here, high winds, low temps and rain, sat images and forecast is so-so. Expect wet weather and don't forget the 'dead cat' :)
Wednesday, 3 November 2010
To facilitate new vehicles and multiplayer
In the process of sweeping changes to how the game loads vehicles and other data. A lot of data the describes how the virtual cockpit works, where you sit, angles of views etc. was not available early on and since my long term plan is a system in which we can serve you new vehicles down the wire, even adding the Chinook was going to need a bit of fiddling around. Some data was in the object LUA, some in an external file, some embedded. It wasn't the original intention to build vehicles this way, but it was expedient at the time.
Now it's time to put things right and make a nice neat all-in-one package that's flexible (after all that is my middle name).
Another thing I wanted to do was allow the ability to tie entities to simulation variables, so a cockpit altimeter needle can be assigned to the vehicle.baroaltitude parameter. Hey does any of this sound familiar? If it does then you've done aircraft/gauge development for Microsoft FSX. While this isn't anywhere as deep, it's enough for us to be able to bundle new helicopters and even ground vehicles later on. I'll publish a list of available parameters later when I know the scope myself. MPDs and HUDs can be copied to specified entities using the name of the glass instrument output and the name of the surface you want it displayed on.
* edit*
This is pretty neat, I've now added a bit more flexibility to what we can do with the cockpit inputs. Each individual switch position may now have a delay (hold at this position n seconds before firing) and fire an additional command at that position.
* end edit*
The FFD (dynamics) data could be added too to describe how it flies/drives, that's to be look at later.
There's still a quantity of code required to determine message priority, client/server authority. but at some future time if we want to add "user roles" as a message filter to any control, this is flexible enough for us to drop that in and not rely so much on coded game logic. Filtration and authority of incoming messages are important for multi-crew vehicles in multiplayer, you need to be as lean as possible (I bake state flags into bit fields as much as practical). Not all switches need to be recorded or sent, some are vital (crew helmet positions need fast updates for the HUD and sensors), some (wipers/lights) can be delayed.
The "command" string in the cockpit switch data is sent to the messaging system, if it's a network level command it's forwarded to any needed clients via Raknet.
As our vehicles are 'portals' there isn't much physics going on for attached crews. As a gunner, your helo position comes from the pilot and interpolated, your sensor position is based this, and that in turn is relayed back to the pilot. So there is room for some weirdness but not too much I hope. The way the Apache works actually works in our favour. Since each weapon system has a designated 'crew in command', the game logic knows who's the shooter and the positional data from the client in authority is used. And if you're not targeting a visible entity (e.g tank) then you're aiming at an invisible one (a pivot). This reduces oddities caused by differences of position reported by actual and interpolated crew positions.
Now it's time to put things right and make a nice neat all-in-one package that's flexible (after all that is my middle name).
Another thing I wanted to do was allow the ability to tie entities to simulation variables, so a cockpit altimeter needle can be assigned to the vehicle.baroaltitude parameter. Hey does any of this sound familiar? If it does then you've done aircraft/gauge development for Microsoft FSX. While this isn't anywhere as deep, it's enough for us to be able to bundle new helicopters and even ground vehicles later on. I'll publish a list of available parameters later when I know the scope myself. MPDs and HUDs can be copied to specified entities using the name of the glass instrument output and the name of the surface you want it displayed on.
* edit*
This is pretty neat, I've now added a bit more flexibility to what we can do with the cockpit inputs. Each individual switch position may now have a delay (hold at this position n seconds before firing) and fire an additional command at that position.
* end edit*
The FFD (dynamics) data could be added too to describe how it flies/drives, that's to be look at later.
There's still a quantity of code required to determine message priority, client/server authority. but at some future time if we want to add "user roles" as a message filter to any control, this is flexible enough for us to drop that in and not rely so much on coded game logic. Filtration and authority of incoming messages are important for multi-crew vehicles in multiplayer, you need to be as lean as possible (I bake state flags into bit fields as much as practical). Not all switches need to be recorded or sent, some are vital (crew helmet positions need fast updates for the HUD and sensors), some (wipers/lights) can be delayed.
The "command" string in the cockpit switch data is sent to the messaging system, if it's a network level command it's forwarded to any needed clients via Raknet.
As our vehicles are 'portals' there isn't much physics going on for attached crews. As a gunner, your helo position comes from the pilot and interpolated, your sensor position is based this, and that in turn is relayed back to the pilot. So there is room for some weirdness but not too much I hope. The way the Apache works actually works in our favour. Since each weapon system has a designated 'crew in command', the game logic knows who's the shooter and the positional data from the client in authority is used. And if you're not targeting a visible entity (e.g tank) then you're aiming at an invisible one (a pivot). This reduces oddities caused by differences of position reported by actual and interpolated crew positions.
Subscribe to:
Posts (Atom)