Accessibility

Table of Contents

Designing and developing Flash games for the Sony PSP

Making Flash Games for the PSP

Game Design

Knowing what the PSP can and can't do will help you make informed decisions in the design of your game.

What type of game do you want to create? The portability of the platform makes it a good candidate for casual games, such as addictive puzzle games or simple reflex games. The wide screen and mouse-like analog controls suit strategy and simulation games. However, the limited processing power available makes high-speed action or complex physics a challenge to pull off.

Another consideration is deciding how the game will flow. Ideally, the game should be structured in a way to deliver maximum impact to the player, while minimizing the drain on the processor. The PSP is perfectly capable of processing large amounts of data, displaying complicated animations, and listening for complex user input, but if you try to do all three at the same time it will tax the system and feel sluggish to the player. If possible, spread the processing, animation and input over time so they don't overlap. Each game you develop will be a bit different, but in general, the more you can separate the processing and animation step, the smoother and more responsive your game will feel.

Screen Layout is another important consideration. The drawing and re-drawing of the screen is an expensive process in terms of memory and processor resources. The PSP screen is quite big (480 x 272 pixels) in relation to the amount of resources available for the Flash Player to draw to it. Try minimizing the amount of the screen that needs to be redrawn every frame. A well placed interface bar or matte that masks off parts of the screen can help reduce the redraw area.

An example screen layout with interface bars that reduce the redraw area by 40% 

Figure 4. An example screen layout with interface bars that reduce the redraw area by 40%

Programming

  • Test early, Test often

    • When building software for any handheld device, it's important to test it on the actual device as often as possible. Performance and timing is impossible to predict without testing. Only by testing often can you get a feel for how each new element of the game is affecting performance, and optimize accordingly.
    • There are two ways to easily test your Flash files on the PSP.  The first is using a USB cable or card reader to transfer the game file to the memory card, and then opening the Internet Browser to view the file. The other way, and the one we find most convenient, is to publish the game file to a web server that the PSP can access wirelessly. Testing a new version of a SWF is as easy as hitting "reload" in the Internet Browser.
  • Code: Simplicity and Efficiency

    • When programming for the PSP, speed is king. A wise programmer will carefully balance the elegance of Object-Oriented AS 2.0 code with the low-level quickness of simplistic frame based code (see Examples below). When it comes to code that runs every frame, the need for speed is paramount.
      • Avoid expensive math operations and collision detection whenever possible.
      • Use approximations instead of complex math operations.
      • Use keyframe-based animation instead of code-based animation.
      • Instead of dynamically attaching and removing movieClips from the library, just move them off-stage or set them invisible.
      • All those old great Flash 4 & 5 programming tricks still work and still produce wonderful results, so a bit of digging through tutorial archives can be well worth the effort.
onEnterFrame = function () {
   for (var i=0; i < Bodies.length; i++)
   {
      F[i] = new Vector(0,0,0);
      var Gravity_F:Vector = new Vector(0, 9.8, 0); // g = -9.8 m/s^2

      // Calculate new force after gravity is applied
      F[i] = F[i].addVector(Gravity_F.multScalar(Bodies[i].getMass()));
   }
}

Example 1: Simulating gravity in a desktop game, using an Object Oriented approach and a custom built physics engine. This code is reusable and very powerful, but is incredibly resource hungry.

onEnterFrame = function () {
   // If rob is falling
   if (rob_state == "falling") {
      if (rob_lvl==0) // if he's hit the ground
         land(); 
      else {
      // move rob down a level
      rob_lvl--; 
      
      // draw rob at this new level
      rob._y = lvl_heights_array[rob_lvl]; 
      
      // see if he's landed on a platform
      check_for_platform(); 
      }
   }
}

Example 2: Simulating gravity in a PSP game, using some of the techniques mentioned above. This code avoids complex math and takes advantage of a finite number of world states. This type of code runs quickly on any device.

Graphics

  • Optimize for speed and size

    • When creating graphics for your PSP game, "small and speedy" is the way to go. As with all Flash games, you have the choice of using vector graphics, bitmap graphics or a combination of both. Each type has their strengths and weakness, and in "Where to Go from Here" I recommend several Dev Center articles that go in depth on the subject.
    • At Zodal, we use bitmaps for the majority of our in-game graphics. This approach works well on mobile devices with Flash Lite and we've found it works great on the PSP as well. Our artists have a cartoony pixilated style that translates well into 8-bit PNG files with transparencies. This format allows us to optimize the size of each file by reducing the color table to the bare minimum while preserving the detail of the original art. Another benefit of using bitmaps is the ability to set the quality of your movie to "Low" for a significant speed boost with very little loss of visual quality.

      Figure 5. Barrel graphic: 4 color transparent PNG, 56x72 pixels… only 551 bytes!

    • When using vector graphics in your PSP game, be sure to optimize the shapes as best as you can. Avoid gradients, alpha colors, or shape tweens.  These are all quite processor intensive to render, and you'll notice a lag in performance when these vectors are on screen.