Tag Archives: Flight Sims

This is a direct follow up to my earlier post here.

Right now my scripting efforts consist of a relatively small amount of changes. One of the very first thing I did was change what our player’s pilot character was going to be equipped with. Normally “pilots” come with an assault rifle which works a lot better for helicopter pilots than it does aircraft pilots. Our guy is stuck only with an M9 pistol, 4 magazines for it, a couple of smoke grenades, and the ever-trusty binoculars.

My biggest concern initially and what other than fine tuning the mission’s objectives originally inspired this whole excursion into scripting was communication. I felt the scenario would feel a bit more realistic if I could make the base/tower/controller/whoever be able to talk to our pilot while he was on the mission, particularly when around the airstrip and as objects changed. I also figured it would be nice to have our pilot respond – whole conversations in other words. Once I figured out how to do this it meant if I wanted to be fairly thorough with my communications, which I did, I’d have to do a lot of scripting to make trigger some of these messages.

Somewhere in here I developed my evacuation idea. After a few hours of working on it (which have included way too many tank-busting flight tests but I’m still trying to keep used to the flying mechanics and whatnot so I have an excuse!) here’s what I’ve got done:

“We now join our script already in progress.”

First off I’ve only added the escort attack chopper routines in so far. The player radios in for an evacuation. The game then spawns a helicopter and its crew in a predetermined location. We set a waypoint for the player’s location at the time they called us and head to it in seek and destroy mode. I also set a variable around this point to denote that an mission is in progress and added in a check which disallows a call if the previous mission hasn’t ended so they can’t summon 300 helicopter (which is damn fun by the way!) When the chopper gets semi close to the waypoint it kicks off a timer. The chopper will then hang around blowing enemies up or just hovering around like an idiot until it runs out at which point we’ll set another waypoint and make it active so that it can return back to its spawn site, land and then be deleted from existence. We’ve got a lot radio messages along the way too.

My next order of business is to add in some status checks for the health of the vehicle. My decision to add in radio messages meant that, in my mind, I’d need to do some scripting in order to account for some conditions in which we might expect messages but not be able to easily send them. Specifically in this case I’m going to send a message when the chopper gets damaged and when it gets destroyed.

The damage part was pretty easy. I added a trigger to check to see if the chopper had acquired a certain amount of damage yet was still alive and if so I had the chopper send a radio message to the effect that he was taking damage. I set this to run only once, so once it triggers the first time that’ll be all we get. I threw a couple of Shilkas on my test map and after playing it enough times to have them actually manage to damage it before it blew them to hell it worked perfectly.

“Runner up in the most boring screenshot of the year awards, 2008.”

The second part, checking to see if the chopper was down or not, was quite a bit harder as in the interest of more accurate radio messages I had to check if the chopper had been destroyed outright, if the chopper had been destroyed but the crew had survived, if the chopper was fine but the pilot was dead, and if the chopper was fine AND the crew was fine, but they had made an emegrency or crash landing.

To accomplish this I ended up having to add four separate triggers for the four conditions. I had considered making one simpler trigger set off a script to check the other conditions but ended up doing it this way. I also added a global variable which each of them would set on activation which they’d check so we wouldn’t get cascading messages if, say, the chopper started to crash-land, then the pilot got killed, then the chopper blew up, then the gunner died. I also used this new variable to abort the rest of the original script which meant that unneeded waypoints wouldn’t be set, invalid radio messages wouldn’t be sent, the crashed units wouldn’t be mysteriously deleted, and the “in progress” global variable I added wouldn’t be reset, therefore further evacuation requests would be unavailable.

“Another BMP-2 is sacrificed to the scripting gods.”

I think the script is pretty much done now. Next I’ll need to duplicate attack chopper script for the transport helicopter and then modify the hell out of it to take into account landing, loading, the additional waypoints, and all that fun stuff.

For those of you that don’t know 2001’s Operation Flashpoint is a brilliant, brilliant game. It is sort of the Morrowind or Oblivion of tactical shooters. Where as the Elder Scrolls games give you a sprawling, detailed world to explore and quest in filled with odd, interesting AI encounters, its open ended freedom providing a great sense of character attachment and achievement, Operation Flashpoint gives you a spawning, detailed world in which to assault towns and partake in massive tank battles filled with odd, interesting AI encounters, providing an unsurpassed feeling of player immersion and realism. It is one of the few games where I vividly remember moments, not because of some minor, scripted event, or because of what was said during some cutscene or dialog, but because of the decisions I made and the immediate consequences they had on me and the world around me. All of this is delivered with a dose of simulation love that I’d never seen before or since in an FPS game. Operation Flashpoint in several different ways transcends existing genre definitions. At its best it’s more of an experience than a game.

“A Russian T-72 rolls forward amidst a massive tank battle.”

Ok, enough swooning over it or I won’t have anything left to say when I write a real review some day. 😉

Armed Assault is a pseudo sequel to Operation Flashpoint. It is basically made by the same people, using the same engine which has been somewhat modernized with some new graphical effects and capabilities, a bunch of new objects with better textures and higher quality models, and a new single player campaign. In many ways it doesn’t deliver as a sequel to Operation Flashpoint although at the same time it wasn’t necessarily intended to either. We’ll have both Operation Flashpoint 2 and Armed Assault 2 later this year (apparently) to attempt to fill those shoes.

Perhaps the core component of the awesomesauce the fuels Armed Assault is the mission editor. Everything that happens in the game is done so in a relatively simple framework of units, waypoints, and triggers placed on a map. You can get a bit more complicated with the addition of more advanced waypoint and trigger functions, synchronization, and eventually scripting. Despite being fairly simple it is all pretty proprietary and how things work and why can feel pretty damned esoteric at times. Still you can actually do a surprisingly large amount with just the basics and little understanding of the rest. For example one of my first attempts in dabbling with the editor, the Operation Flashpoint: Elite version on the original Xbox, included only units going to timed waypoints. I don’t think I even used any triggers! Yet I had built a challenging scenario that involved the player outrunning an enemy assault on his camp and making it to an incoming friendly helicopter for evacuation, with all kinds of interesting, semi-dynamic elements and details.

“Insurgents ambush passing US Abrams tanks.”

The dynamics are certainly one of my favorite things about playing around in the mission editor and playing in the world of Operation Flashpoint/Armed Assault period. How the author of the mission intended it to work only makes up a small part of the equation. The way the AI, while quite far from perfect, reacts is varied and often interesting. It feels as if every tiny action the player makes factors in thus they might behave a little differently every time you face them. The human player himself, of course, has a fairly unpredictable nature in terms of game design and will often act in ways you would have never expected. This gives the whole experience, even when it is a simple enough scenario, a unique and personal feel. More often than not different players will have completely different stories of how they defeated the very same missions.

“An special ops team prepares to insert via MH-6 under cover of darkness.”

It is easy enough to open the editor, load a map, pick a spot that looks interesting, and plop a few enemy units down. Next you give them a few waypoints so that they move around a bit and then you’re ready to jump in the game and attempt to defeat them all. Given the slow, tactical, deadly nature of the engagements this can be a lot more fun and entertaining than it sounds providing you’re into that sort of thing. That is all I was intending to do when I started working on my A-10 mission. After all, that is about all that happens in most flight sim scenarios – you take off, fly to point A, bomb some targets, fly to point B, bomb some more, and then fly back to base. The problem is that ArmA is capable of so much more than blowing up static, armored targets. Our targets can move! Our targets can be unmanned but become manned as our aircraft is detected. Ours can shoot us down and… If we eject, they can hunt us down and finished the job once we’re on foot!

“US Army soldiers fan out to investigate possible enemy activity.”

You see, one interesting thing about flying in games that have an infantry aspect, such as this, the Battlefield series, and other, similar games, is that once you get shot down the game isn’t over. In ArmA trying to make it back to safety while avoiding patrols and possibly having to defend yourself with only the limited small arms of a pilot is an adventure unto itself! I decided I need to add in some more interesting features to compensate for this.

First and foremost, we’d need to add OPFOR units that are neither targets nor there strictly for atmosphere. If there’s a group of guys sitting around a camp fire next to a parked tank that you’re about to destroy they’re potential victims and not much else. If one of them has a Stinger surface-to-air missile, however, they’re now an actual threat. If one of them can make a made dash to a Shilka hidden in the brush 50 feet away, they’re an even bigger problem! We also need to add in patrols of infantry and light armor, maybe even the odd chopper, to the surrounding country side. These will help give the world more atmosphere, targets of opportunity, and most importantly provide downed pilots with some potential risk as already mentioned.

“An OPFOR soldier tracks an AH-64 Apache assaulting his position. The situation doesn’t look good.”

We’ve still not mentioned anything we can’t do all that easily. We could, however, make it much more complicated. We could, for instance, only have those patrols active when the player has been detected in the area but not in his aircraft. We could take that concept a step further, and send out patrols specifically to the area he was shot down in order to attempt to locate him. We could even spawn an enemy helicopter to fly to and drop some troops off in the area. Ugh… Talk about lowering the odds. 🙂

We don’t just need to do things to hinder our player however. This scenario is supposed to take place in modern times, maybe even near future. Surely our pilot would have a radio, some kind of a rescue beacon, maybe even a GPS? Why does he need to limp his sorry as all the way home? He doesn’t, of course!

“Two Russian BMP-2s rush past an exploding Russian T-72 during a tank on tank engagement.”

This is what I’m currently developing – a script to allow a pilot to request to be evacuated. It is interesting to design a system while learning the capabilities of the engine and attempting to work around them simultaneously I’ve got to say. My plan is to allow the pilot to use his radio to call back to his HQ for an evac which will spawn an attack helicopter and a transport helicopter. The attack chopper will act as an escort coming in first, engaging any enemy vehicles in the area hopefully. The transport helicopter will show up soon after, land, unload a squad of troops, and wait for the player to get in. Once he does the squad will mount back up and the chopper will return the player to base. Sounds fairly straight forward right?

Not so much. First of all, little of what I’ve described can be accomplished with waypoints and triggers alone. For one, how in the world do I make it so the friendly choppers arrive at/near the players location? I thought of an alternative, one that I might still use for some missions in the future, and that is to have the rescues available at multiple predetermined locations marked on the map and the player can select which one he’d prefer to use. This would be much easier to pull off, as I could set the waypoints on the map and have much of what needs to happen done with zero scripting. It would also add an element of adventure as the player has to hike to the pick up location. On the downside, the landmasses available in ArmA are huge and 2 or 3 available pick up points might not be adequate.

“A US Army sniper, having just eliminated his targets, prepares to exfiltrate the scene.”

We’ve also got to worry about a ton of little details. Can the player call these in more than once at a time? No? How about more than once per mission? Will the transport helicopter wait forever for the pilot to arrive or eventually depart with out him? What happens if one of the helicopters gets destroyed or disabled? Do the helicopters just appear or do they already exist and take off from some predetermined base? If they already exist, what happens if they destroyed before they’re called in? There’s quite a lot to think about indeed…

Note: I took all of the above screenshots ingame at the settings I normally play at and none of them have been modified although many do include user created addons.