Rapid Implementation (UAV Game)

Dec 28, 2010

Earlier this month, Remy Karns, a student at UC Berkeley, called me for help with implementing his 3 page design document.

7 hours later, I had UAV Game made based on his spec (play in Flash, no download/install required). UAV is short for Unmanned Aerial Vehicle.

I wrote an article about this game for the Newsgames Blog, though that one has a journalism angle. In contrast – and fitting with this blog’s purpose – this post instead focuses on the game’s rush development.

Foundation Code

Rather than memorize the details of how to handle keyboard/mouse input, basic graphics, sound playing, and framerate timers in each programming language, I prefer to start with a source file that’s little more than an image being loaded and shown, a sound being loaded and played, and a little input being taken, so I can duplicate and rearrange. In this case, I started from the example code that I put together for ActionScript 3 – Motion Tutorial, removing aspects I wouldn’t be needing.


In order to make isometric building art, I turned on the grid in my image editor, then drew using diagonal lines that went 1 tile vertically for every 2 horizontal tiles.

That 1:2 ratio works since sin(30 degrees) = 0.5. The simplicity of this is part of what makes isometric a popular way to fake 3D.

Likewise, for the moving AI targets, I set their vertical movement to only have their horizontal speed. For the burnt crater graphic that gets drawn after the explosion, I first draw a circle from overhead, then scaled it to half height.

For distance checks, such as determining which guys are within the blast radius, I doubled the Y offset.

      // note/reminder: mouseX and mouseY on the
      // sprite are relative to its position
      for each(var tempGuy:Guy in guys) {
        var dx:Number = tempGuy.mouseX;
        var dy:Number = tempGuy.mouseY*2.0; // Isometric
        var distanceTo:Number = Math.sqrt(dx*dx+dy*dy);

        // design doc indicated blast radius twice scanner range
        if(distanceTo < SCANNER_RANGE*2) {


I found the music from Incompetech.com, Kevin MacLeod's massive collection of his Creative Commons Attribution music (free to use if he's credited).

Although "Movement Proposition" was the first result listed for Aggressive in the Feel links, as I always do I selected it from narrowing down about a dozen "this might work" picks that I downloaded while searching for options.

The song was already fairly repetitive, and only needed for a background loop, so I used Audacity to trim it. The game is only intended to last a few plays, so keeping the loading time from becoming too large a part of the total time spent with the game seemed worthwhile.

Sound Effect

The only sound effect used in the entire game is the explosion, which I borrowed ready-made from an older game project I created years ago.

Hiding the Edges

Since this was developed in a rush, I was lazy about culling off-screen sprites (a surprisingly common shortcut for Flash swf files). Instead, to address this, I set up a sprite layer with white rectangles, the same dimensions as the screen, covering each direction outward from the screen. This technique doesn't hide everything if the window is scaled impractically narrow, but it works fine for common window sizes/ratios.


Particle Effects

The particle effects I created for Everyone's Platformer were close to what I needed, though those were developed to draw to a bitmap layer, rather than using the Sprite children hierarchy that the rest of this program was being built around. To account for this, I created an extra bitmap layer the same dimensions as the screen, cleared it each frame with transparency, and just drew the explosions to that new layer. I set up that bitmap layer between the action graphics and the HUD information.

As with all other movement, I reduced vertical speed to create the illusion of isometric perspective. In addition to this, I gave the explosion a more upward bias in the random y-velocity of each particle, to look more like a ground blast.

Font Embedding

The design required several screens where text would be the focus - prompting the user to guess about the consequences of the attack. The default font wouldn't do.

I chose Bank Gothic for its associations with professional, modern, military action.

To support embedding fonts, I added this argument to my command-line AS3 compilation:

(In addition to the usual "-static-link-runtime-shared-libraries" argument.)

Without that "-managers=flash.fonts.AFEFontManager" bit, fonts that are otherwise properly embedded in the AS3 code become invisible, which can be maddening to debug since nothing done to the code itself can fix it, and there's no feedback on the error other than the text not showing up.

Building Collision Detection

To prevent characters from walking through buildings, I rearranged the expression used to distribute buildings on the isometric grid. This converted a character's position in world space into coordinates relative to the nearest building (with the building in the top-left corner of that coordinate space), meaning a couple of comparisons were all that were needed to check collision with the nearest building. If collision was detected, that character then checked in each of the 3 available alternative directions to find one which wouldn't overlap, changing its movement to that direction and immediately taking an extra step to avoid showing the collision.

      if( overlapsBldg(x,y) ) {
        if( overlapsBldg(x-2*xv,y) == false ) {
          xv *= -1.0;
          x += xv;
          y += yv;
        } else if( overlapsBldg(x,y-2*yv) == false ) {
          yv *= -1.0;
          x += xv;
          y += yv;
        } else if( overlapsBldg(x-2*xv,y-2*yv) == false ) {
          xv *= -1.0;
          yv *= -1.0;
          x += xv;
          y += yv;

Classes Used


- The wandering individuals. Variables on the characters tracked whether the individual was a target, follower, dead, frightened by explosion, etc.


- Each individual particle.


- Managing all particles.


- For putting "Loading" text on screen before the download is finished. I slightly modified this file from the "AS3 with Preloader" project option from FlashDevelop so that I can use it without FlashDevelop.


- All other functionality, including input, camera, text, menus, buildings, game logic, scoring, timer, etc. In the interest of finishing quickly, I didn't compartmentalize those things into different classes, which means the code came out a bit scary, but it also spared time flipping between files or over engineering abstraction/interfaces. Many of these elements were only touched in a few functions, making it possible to keep the relevant parts of the file nearby or in mind at any given time.

Deviations from the Document

There were a few ambiguities or conflicts in Remy's design document. Most of these I sorted through on the fly, though when I wasn't quite sure I clarified through short e-mails while working on other parts. The core concepts and overall instructions survived the translation into gameplay. My changes included:

  • Left click fires instantly, instead of holding then releasing with an option to cancel.
  • The control scheme described was different in a couple of places, due to changes in planning during Remy's design process. The camera control system I wound up implementing was clarified through e-mails to be the type intended.
  • Followers were made yellow, rather than "white with red tinge". This served the same purpose of making civilians blend in with civilians while still giving some differentiation. The blend described on paper though ("white with red tinge") is pink, which seemed inappropriate for the setting and character.
  • I used a rectangular reticle instead of the circle described in the document, since the rectangular reticle is characteristic of UAV cameras.

Effects of Unspecified Tuning

Although I followed the scoring described in the document to the letter, I discovered during development that two things not outlined specifically had a significant impact on what the scoring rewards:

  • Crowd density
  • Rate at which civilians turn into followers

The more dense the crowds, the more likely civilian casualties were. The faster civilians turned into followers, the sooner the player could shoot while killing only followers (worth 20 points each per kill accurately reported) instead of civilians (worth negative points even when accurately reported, just not as negative).

To further complicate matters, these two unspecified tuning terms had an effect on one another: crowd density increased the relevance of the conversion rate.

If I made the crowds very sparse, the player could fire and hit only the target, without concern for whether nearby civilians had converted (since there wouldn't be enough bodies of either type nearby). If I made the civilians rapidly convert to followers, acting quickly would rewarded (time affects score), but if civilians are dense and convert slowly to followers, waiting for the conversions could outweigh the time bonus lost waiting for that conversion.

The Impact of Tuning on Meaning

For more on this project from a design and experience angle, check out my post about it over on the Newsgames blog: UAV Game: Differing Interpretations.

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!


  1. […] more article is completed but not yet posted, in connection to the UAV Game. Check back at the JAG blog soon for that one, or subscribe to the blog’s […]

  2. […] Involvement: programming, art, addl. technical design Newsgames entry about UAV Game’s meaning HobbyGameDev entry about developing UAV Game […]

  3. […] time is given, players are able to complete the objective before feeling any time pressure. Here, tuning in the game’s design was the reason for the time not initiating a rushed behavioral heuristic. The designer intended for […]

Leave a comment

Comments Form
  • Your email will not be used for any purpose other than to update you in replies to your comments. Your website address will be shown as a link from your name with your comment. Your profile photo is auto-magically provided by Gravatar.

All contents Copyright ©2017 Chris DeLeon.

Site production by Ryan Burrell.