The Making of A-10 Thunderbolt 2

Aug 16, 2010

What follows is about a little Processing demonstration (not)game that I made titled “A-10 Thunderbolt 2.” Complete final source code is provided, as is the code from incremental stages of development.

Processing

A-10 was created using “Processing” (version 2.0.2). For more on Processing, please see the last section of my previous article Platformer Game Source in Processing.

“That’s quite a bit of fun.”
-Nicholas B.

About the A-10

The A-10 Thunderbolt II, having on numerous occasions landed safely with only one working engine, one tail fin, and only one complete wing, sports a unique design that was ahead of its time when invented in the 70’s:

A-10’s are designed to destroy tanks, primarily using the 7-barrel, 600 lb. (4,000 lb with loaded drum) GAU-8/A chain gun firing 70 exploding rounds/second.

Since the airplane itself is not something that most of us come in contact with, the weapon’s relative scale can be difficult to judge from the metal nub sticking out from the nose. The plane is much larger than it looks in photographs. Here is its gun next to a Volkswagon:

These planes are built for and around that gun: to get it and its operator into the field, close enough for attack, and safely back home. It’s built to carry the enormous weight up front, to fly low and slow with great maneuverability to aim, and to survive the kind of beating that comes from flying close enough to use it. The cockpit sits in a tub of armor. The ammunition is wrapped in multiple layers of armor – to save it from being set off by enemy fire.

The A-10 also carries a varied bomb and rocket ordinance, each of which functions differently and serves a particular role in close air support. The armament is generally an assortment of guided rockets, cluster bombs, napalm, and 2,000 lb. general-purpose explosives.

About the Development

Working alone, I put this together in less than two days. The focus to do that came from the decision to have one core feature. Not “at least” one, not “as many as possible if only I had the time/resources”, but simply “one core feature”. I then made everything in support of that, building and designing around the destroyable terrain.

Just as the A-10 is built around its gatling cannon as its defining feature, this project is also built around one central feature: real-time destroyable terrain.

Despite the name, the title screen, and the player avatar, using an A-10 here was an afterthought, not the guiding concept. I built an engine that handles dynamic 2D cratering well, and needed something to tear the land apart. I considered artillery cannons, battleships, mining operations, futuristic satellite weapons, and decided the A-10 was the best fit for delivering a mixed payload at close range, traveling at a variety of speed and angles but nearly always going slow enough to be within viewing distance of its destruction to the land.

The player is never shot at, because this project is not about the plane. The endless stream of infantry, tanks, and helicopters are just there to motivate the player to shoot at the ground. Shooting at the ground, in this case, is surprisingly neat.

About this Notgame

A few years ago, I would have considered this unfinished until it had multiple levels, each with a winnable objective, and probably a limit on the number of attempts a player could take to achieve each level’s goal. By contemporary videogame design standards, this project is lacking because it does not have a story – there’s no B-movie script or formulaic drama contrived to justify why the player should be doing this.

However as soon as there are levels, it is completable. As soon as there are linearly progressing story elements, the drive may switch to wondering about what happens next instead of doing what is there to be done. I do not want to stress the player out with scary stories of torture or tyrants, nor do I want to make things up to suggest that this is anything more than a harmless toy.

If the player crashes, spacebar resets the plane with fully replenished ammunition. I’m not demanding that the player play with this in some certain way, holding back features or information until it’s played exactly the way that I play it. Nor am I chiming in with bonus points and treasures hoping to flatter my player into feeling good about what this is. It is what it is.

The player should be doing this because they like doing it, not because they are tricked into doing it compulsively, and not because they’ve been challenged into feeling like they have something to prove to themselves or anyone else before it can be put away and forgotten.

“I’ve been playing this for about 20 minutes straight. Pretty excited about it, still.”
-Andrew S.

When the player no longer likes doing this, it’s my hope that the player will simply move on, with the good feeling that the right amount of time was time spent playing with it – be that 20 minutes or 20 seconds.

The Source Code, in Stages

Install Processing (version 2.0.2), and download these 10 stages of development from the game to your Processing sketchbook folder.

(The Processing sketchbook folder is the same folder that the initial project will save if you open Processing after installation.)

The source code in that zip file has the development of A-10 Thunderbolt 2 broken up into 10 feature steps, going from just loading the sky and ground to the final, full source.

Please download the 10 stages of source code. Really. You’ll get much more out of this by looking through, running, and ideally tinkering with the source code than can possibly be understood by looking at the weird development screenshots that follow.

The heart of this article is that source code, not what’s written here. I’m giving away a model airplane for anyone and everyone to build – but this article is just the instruction manual. That source code makes up the actual kit of plastic pieces waiting to be popped apart, snapped together, and painted.

“The CBU-52 was brootal.”
-Alex J.

Stage 0 – Image Loading

The Processing source in the a10_0_imagesload folder loads 2 images – one for the sky, which is used as a background, and one for the land, which is used as the foreground. It displays them. That is all. Additional explanation about the source can be viewed in comments I added to the code in the .pde file. The placeholder land image I drew for this is psychedelic to show that the pattern of the foreground is preserved and warped, per pixel, as it slides in the steps that follow.

Note that the images are in a directory called “data” alongside the source file – that directory is where all images and sounds for a given Processing sketch should be.

Stage 1 – Making Land Fall

This example demonstrates the land collapsing smoothly. Where there is a solid pixel above a transparent pixel in the foreground image, the two pixels switch spots. Because this check is performed bottom-to-top in each column, the pixels slide smoothly down until there are no more gaps. This effect is nifty – but it’s also cheesy, predictable, and very unnatural.

Stage 2 – Making the Fall Messy

In this stage, the land crumbles with some randomness and lateral movement, making it look much more like fragmented earth. Clicking in this version cuts a perfect square out of the land at the location clicked, demonstrating that the dirt falls in unevenly.

Stage 3 – Shredding Land

This example cuts land in a ragged fashion, dicing it with thousands of holes where clicked instead of carving out a clean square. Because the density of pixels turned to zero alpha is highest near the click, doing this near or below the surface results naturally in forming craters after the foreground land settles.

Stage 4 – Making Bombs

Here, clicking drops bombs from the point clicked. Where the bomb hits land, it performs a land shred from Stage 3, which in combination with the messy fall of land from Stage 2 is beginning a form a somewhat more bomb-like chain of events.

Stage 5 – Bringing in Enemies

Tanks deploy from the right edge, and the terrain image has been edited to be less fantastical, creating simple sand dunes. The tanks check the height of the land in two locations, a few pixels apart, and by a simple trig call that information can be used to determine an angle for the tank to slant so that it aligns with the land beneath it.

Bombing near a tank will remove it from the tanks list. If the tank is within 70% of the bomb’s land shredding radius, it gets removed.

Stage 6 – Widening Land, Scrolling Camera

The world is now several screenfuls wide. Hovering the mouse on the leftmost or rightmost 15% of the window causes the view to scroll. Bombs also now cause “camera” shake now, which quickly settles but briefly jostles the view.

There are two other small changes made for this stage: an updated terrain drawing that has more variety (runway, grassy area, mountains, desert, hill with fossil under it), and a couple of changes so that the destroyable land calculations only take place within the bottom half of the window.

Stage 7 – Making the Plane

Now that there’s adequate room for flight, we can insert the airplane, and hook up keyboard controls for it. Down pulls the nose of the plane up, and up dives the nose down, as with an airplane joystick. Holding the right or left arrows act as maximum or minimum throttle, which otherwise maintains cruising speed. Bombs no longer fall from the mouse cursor, but instead drop from the plane’s current location when spacebar is pressed. At this point it’s beginning to play more like the final project, but it still looks and feels very different.

Vertical scrolling is also introduced here to keep up with the plane as it gains altitude. As with the horizontal scrolling from Stage 6, it’s simply an offset used to transform the view along an axis. As of this stage, the game now pauses when it doesn’t have keyboard/mouse focus, to save the plane from crashing while the player is not in control of it.

Stage 8 – Optimizing the Impact Craters

In Stage 7, the game is set to run up to 60 frames per second, but is unlikely to get very close to that mark. Stage 8 demonstrates an optimization trick which is based on the fact that we know something about which soil is worth checking for falls: soil near recent explosions, soil above the lowest missing pixel, and soil below the highest solid pixel. For each column of pixels we now keep track of the minimum and maximum height that soil fall could happen in, and only considered those pixels on each frame per column. This enables the game to run consistently at a much higher frame rate, even with a constant stream of bombs dropping and land collapse updates.

In later iterations we cap the framerate in the “setup()” function to 24 though – for better timing consistency between higher end and lower end computers. Without this optimization, on lower end machines the frameRate due to computation in doing land collapse checks the inefficient way could easily drag down to 15-20, dragging down the pace of play to a speed slower than it’s designed to work at. This also gives us more wiggle room to add some fancy particle effect handling and graphics in the next step without bogging down performance.

In this build, there’s a function that can be uncommented to draw as a yellow area the specific regions being checked for soil collapse during any given cycle. In previous steps, the entire bottom half of the screen would have been yellow!

Stage 9 – Particle Effects, Better Weapons

With the core of the gameplay functional, we can begin populating it with features/content (weapons) and polish (particle effects). A, S, D, and F keys now drop different types of bombs, and Spacebar fires a machinegun. Ammo is tracked in the top left of the screen. Particle effects show dust, metal, explosive bursts and flames.

Finishing Touches – A-10 Thunderbolt 2

The differences in the final version are the addition of helicopters, animated infantry, minor optimizations/tweaks, an opening title screen, and audio.

In terms of programming the audio is fairly straightforward – see the source for more details, and note the import of minim at the top of the main file. To figure out how to handle audio in Processing, I went to the menus for File -> Examples -> Libraries -> Minim (Sound) -> LoadFile/LoadSample. Sound effects were made by mouth with a mic, edited in Audacity, and music was selected from Kevin MacLeod’s Creative Commons library (free to use if you attribute the music to him).

About Notgames

“Notgame” is a term coined by Tale of Tales. Notgame is to game as non-fiction is to fiction. It’s a “Notgame” because even though it looks and plays like a videogame, it’s not a “game” – there is no way to win or lose, and there are no points or goals.

Violence Disclaimer

War is terrible. It is not my intention to glamorize warfare.

Airplanes are impressive feats of human engineering though. Military airplanes even more so, from a purely mechanical perspective.

This is just a game-like toy about military planes. It facilitates imagination. No one gets hurt. Videogames can provide a healthy and harmless way to get our fascination with wasteful and dangerous activities out of our system, moving past them after innocuously satisfying the interest, rather than building layer upon layer of repressed urges.

Modify It!

Along the lines of my violence disclaimer, I made a version that shows a tally of tax money spent for fuel, bullets, and bombs, going so far as to tack on the price of crashing! It’s included in the complete source code within the a10thunderbolt2_costs folder.

Admittedly, it’s messed up that the emphasis is on the cost in dollars, rather than human life, and that it only counts the US cost without regard for the destruction to the other side’s equipment and troops (who are civilians before and after the war) on the ground.

That’s how war works.

Creating this modification was mostly a pretty simple matter of digging for sources to estimate costs, doing some basic arithmetic to find average values, and inserting a line of text on the bottom of the screen. Instant political commentary. It probably won’t change anyone’s mind about warfare, least of all immediately or dramatically – it’s only a toy – though having another way to look at this sort of scene (as a rapid drain of a government’s limited financial resources) might potentially affect how a person thinks about the next battle they see in a movie, videogame, or international news report, or discussing this artifact itself could prompt a very real discussion between friends about politics that might not have otherwise happened.

Note too how the inclusion of that one line of text at the bottom seems to drown almost everything else out. In terms of technical components, this is an addition, and a minor one at that. In terms of design and user experience however, this is a significant change in the overall effect – more of a replacement than an addition, taking away from other things the amount of attention that it draws to itself.

The land cratering and explosions no longer draw the most attention. Even though there are no repercussions for the price growing astronomically, after the inevitable initial experience of unloading everything on the first turn or two, we’re perhaps less likely to continue experimenting wildly with the weapons or kamikaze the plane every turn, if not thinking with conscience about war costs then at least thinking tactically about more efficient use of the resources available. The mood turns less playful, shifting for the interator from feeling like a kid with a toy plane to thinking instead like an adult blowing 4 years of high college tuition with every AGM-65 Maverick dropped. Let loose with everything the plane is carrying, and there vanished half a million dollars.

Politics, like many adult issues, are loud. They’re distracting. They own attention when raised – it’s the classic reason for keeping politics and religion out of friendly dinner table banter. Adult issues easily dominate tone, even when barely present.

What other kinds of modifications can you come up with? Replacing a few graphics and twiddling some numbers could easily make it a game with a plane other than an A-10 – an F-16, maybe? Rewriting the movement mechanics could put the player in a helicopter or tank. Without changing code: drawing a destroyed cityscape in the background and modifying the foreground to look like cement rubble would also give it a very different overall effect. Add enemy jet fighters, SAM sites, AA guns, or maybe allied soldiers and helicopters coming in from the left that add a risk of friendly fire. Whatever you’d like. You can turn it into a game – add lives, a loss condition, a win condition, points and so on – or you can do as I did, modifying it to make a particular statement.


Questions?



Learn and practice team game development with Gamkedo Club.
Membership worldwide. Professional support. Proven process.




Subscribe by e-mail to receive weekly updates with Gamkedo.Community interviews and YouTube training videos for game developers!



7 Comments

  1. […] there are plenty of resources on the web to learn about these areas of math. When you spot them in sample code, don’t gloss over how they’re being used – they’re often at the core of how […]

  2. […] the A-10 Thunderbolt II (write up on how it works) game into 10 stages of development, I explained the pieces over a 3 hour period. In hindsight, […]

  3. […] The Making of A-10 Thunderbolt II – Side view plane game, with dropping bombs on tanks and real-time destroyable […]

  4. […] Involvement: All (solo project), except music (creative commons) HobbyGameDev entry on the implementation […]

  5. […] A-10 Thunderbolt II – Costs Edition, my aim was to change the meaning of the game simply by displaying 1 new number on the interface […]

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.