HobbyGameDev - Formerly GameDevLessons.com

What follows is about 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”. For more on Processing, please see the last section of my previous article Platformer Game Source in Processing.

Play It First

The finished project is available at http://a10thunderbolt2.com/. It’s playable online – no download or install required. Due to a bug in Apple’s latest Java update, Processing apps (including this one) run slowly in Google Chrome for Mac.

“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, 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 runs at 15 frames per second. After an optimization in Stage 8 that numerically keeps track of the minimum and maximum height that soil fall needs to be considered at any given frame for each column, the game can run 35 frames per second easily, even with a constant stream of bombs dropping. The framerate is capped in the “setup()” function to 24 though – for better timing consistency between higher end and lower end computers.

In this build, the yellow area shows the region being checked for soil collapse on 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).

Getting the Word Out

My final step was to publish the game online, setting up a page to frame it over at a10thunderbolt2.com. I registered the domain through StartLogic, track visitors to it by adding a bit of StatCounter code to the page, and typed up the page using plain HTML. I then posted it to Twitter and Facebook to see if friends had feedback or ran into performance/compatibility issues with their OS/browser/system combination.

This is a valuable part of the hobby videogame development process! Making something cool, only to hide it in a folder on a hard drive, or to release it blindly to the world without any idea of whether it’s going to work on other people’s machines, misses out on some of the most rewarding parts of hobby videogame making. It also denies countless others a good time that could be given by just an extra hour or two of effort on the part of the developer.

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:

A-10 Thunderbolt 2, showing costs of fuel, bullets, and bombs
(If this doesn’t load after running the original version, try restarting the browser. Due to weirdness in how Processing handles memory, occasionally it’s necessary to quit the browser after several Processing apps to get another one to work. To my knowledge there’s nothing I can do to work around that – although if you have suggestions, please let me know.)

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 matter of digging for sources, doing some arithmetic, and inserting a line of text on the bottom of the screen. Instant political statement. It probably won’t change anyone’s mind about warfare, least of all immediately or dramatically, though having another way to look at this sort of scene (as a rapid drain of resources) may affect how a person thinks about the next battle they see in a movie, videogame, or international news report, or what topics come up when talking about politics.

Note too how the inclusion of that text seems to drown almost everything else out. In terms of technical components, this is an addition. A minor one. In terms of design and user experience, however, this is a significant change in meaning – more of a replacement than an addition.

The land cratering and explosions no longer draw the most attention, because they take place while the cost is changing. Even though there are no repercussions for the price growing astronomically, we’re less willing to experiment wildly with the weapons, or kamikaze the plane every turn. The mood turns less playful, mindset shifting from feeling like a child with a toy plane to thinking like an adult about 4 years of high-priced college tuition expenses blowing up with every AGM-65 Maverick. Let loose with everything the plane is carrying, and there goes half a million dollars.

Politics and adult issues are loud. They’re distracting. They demand of attention. They dominate tone. (This is, of course, why people are discouraged from bringing up certain topics at the dinner table.)

What kind 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?

Permalink: http://www.hobbygamedev.com/int/the-making-of-a-10-thunderbolt-2/

Posted in:

Intermediate, Vol. 17

Tagged with:

Author's Games, Game Dissection, Sample Code