Imagine spending months or years creating a game, only to have several remarkably similar games appear on the market at the same time.  If your source code is leaked or stolen, you could easily find yourself in the position of competing for income with your own work.  Languages like C++ are compiled into machine code, but a major downside of Actionscript is that your source code is maintained virtually intact in your released SWF.  While the few flash decompilers out there are admittedly very buggy, the opporunity exists for a dastardly thief to spend minimal effort to produce a game very similar to your own.  Legal options are often available, but its much easier to avoid the expense and hassle by protecting your code.  This is why SWF obfuscation tools exist.

I evaluated Kindisoft’s secureSWF, Amayeta’s SWF Encrypt, Ambiera’s irrFuscator, and LockLizard’s Lizard Flashguard.  Based on the level of security features, ease of use, and stability, the tool I’ve chosen for this task is secureSWF.  It offers several good features, and the ones I found most useful are:

• renames identifiers
• uses several techniques to obscure code flow
• encrypts strings
• optimizes code
• has build process integration

Obfuscating Actionscript is a pretty complex task and secureSWF handles it well – my SWF ran perfectly with adjustments to all security settings.  Here are the results of my rough performance comparisons:

no security
plain SWF: 211k , 37fps

default settings
secure SWF: 293k, 35fps
40% larger, 6% slower

custom settings – disabled “control flow obfuscation”
secure SWF: 244k, 37fps
15% larger, no performance loss

Tweaking the settings for less aggressive encryption can give better size and performance, but I consider the small performance hit to be a mandatory cost of business for creating a mid-scale game using Actionscript.  If you have a lot of high quality original source code that you want protected, I highly recommend Kindisoft’s secureSWF.

Finally it’s time to show some progress with a new tech demo. This demonstrates the integration of physics into the Jetpack game engine, along with some live-cached graphical effects and Thing grouping (the moving platform). Note this is just a test of the physics engine and does not reflect what the final game will look like. Please report any problems you experience, and if you like the progress, please digg this post!

Earlier in the project I put some time into writing my own physics engine, but I decided to try a 3rd party library for physics and I’ve been very happy with the result. I am reluctant to use 3rd party code because when I’ve tried in the past I spend more time working around limitations, bugs, and poor documentation, than if I had simply written it myself. But in this case, using the 3rd party physics engine box2dflash has turned out to be excellent. The API was much better than I expected, the docs have some quirks but are substantial, and the community is large. The result is way more functionality than I would have ever achieved, with a lot less work on my end.

While doing some minor optimization checks by selectively disabling certain features, I noticed a significant slowdown was being caused by alpha changes (translucency). Strangely, if the graphic contains translucency but you don’t alter the alpha, there is no slowdown. So I implemented a smart per-object cacheing system – in this case, alpha is applied and the graphic is drawn to a cache, and future changes in alpha trigger a cache refresh. This is useful for any property that doesn’t change too often, like a rotated object at rest – render the rotated version to the cache, then all future frames will render the cache without rotation. Using this technique and the box2dflash physics engine, on a typical machine I’m able to get 100 balls interacting (each with 2 translucent graphical objects), plus all the level blocks, and maintain an average 40fps. Using Flash as a platform will not be a problem.

The next tech demo will be a control test – binding user input to commands, passing those commands to a Thing’s state machine, applying forces/motion based on the current states, and activating graphical representations of those states. In other words, running around. To be updated on future Jetpack developments, please register on JetpackHQ!

Update

This is a little jerky at times mainly because the code that lowers the frame rate under high load isn’t currently functional.  It’s trying to hog the processor and the browser isn’t having it.  This will be fixed in a later release.

I’ve never created a project roadmap because I didn’t see the point in a single-person project, but now that I’ve tried it, I highly recommend it. I’m sure I didn’t think of everything, but just having clear milestones really makes it easier to see how close you are to your goals. The roadmap I made helped me decide to have 6 milestone releases: Pre-Alpha 1, Pre-Alpha 2, Alpha, Beta, Limited, and Full release. Each release serves as a milestone and each has a different set of work to be accomplished, both on the game and the website. Having a roadmap showed me how surprisingly close I am to the first release – and how most of the work will come after that. While all this is subject to change, the roadmap up to Pre-Alpha release 1 includes:

• [DONE] basic physics: integration with Things (like sprites), collisions, gravity, friction
• control: ability to move an Entity around the world via input, limited by physics
• basic tile behavior: ladders, gem removal, etc
• start adding creatures: rolling ball, spring
• basic AI: possibly 3rd party
• triggered sound effects: probably just using placeholder sounds
• basic menus: nothing fancy, just enough to do basic actions
  
• game info panels: for displaying status and debugging info
  
• Pre-Alpha release 1

Pre-Alpha 1 will be a very rough draft but playable, with only the basic elements in place.

Pre-Alpha 2 will add a basic editor, basic web integration, more creatures & tiles.

The Alpha release will have most features of the game in place, and a fully usable editor.  The best user-created missions will be chosen for use in the game.  Pre-ordering will be available.

The Beta release will have most features of the game completed, and most bug fixing and gameplay tweaking will be done.  A lot of mission creation work remains.

The Limited release will be feature complete, but web-only.  Most of the website features will be in place.

The Full release will be downloadable and add support for platform specific items like full screen, joysticks, etc.  Most of the development will switch to the website.
 

Back in July 2008, there was quite a bit of work done that I didn’t have time to discuss or demo (last year I put the project on hold for 5 months to work on the Obama for America campaign website – and ended up adding another 5 months because of talks with potential publishers).  I did spent some of that time working on the website back end, so a lot of that is done as well.

What’s Done

• input handler: command bindings > state machine > entity (command stream input for the state machine could eventually be: an AI, a network player, or demo playback)
• world cycle: graphics & basic physics – auto adapting frame rate independent from game tick, client-render-prediction-capable
• animation system: vector & bitmap, automatic cacheing, adapts to frame rate
• original map import: to faux-3d tiles, layered parallax rendering
• basic gui & menu system
• asset loading & management system
• flash platform: source encryption system, security wrapper, preloader
• website: improved template/page module system, nice request routing system, smooth deploy system

What’s New

Physics Engine

I’m tinkering with the Box2d physics engine for ActionScript 3, and I’m very impressed with its power and flexibility. It has many more features than I need, and I’m just hoping it turns out to be fast enough on slow computers. We’ll be able to have much more realistic effects without any extra work as long as this library turns out to be fast enough. I’ll be releasing a demo soon.

Refactoring (warning, serious programmer-speak ahead)

In the last couple weeks, I’ve refactored a good chunk of the code to accomodate some ideas I’ve been exposed to – the benefits of dependency injection and service locators.  These  two patterns may seem to be at odds, but I think each has benefits in different circumstances.  By focusing on using DI as much as possible without major inconvenience, I have increased the logic and readability of my code.  By falling back on a service locator to avoid bending over backwards to be 100% DI, I’ve kept the code clear and the configuration centralized.  The result is, the code is a lot better organized and easier to work with.

I’ve also decided to abstract the platform.  Initially I didn’t bother, since Actionscript is so intertwined with Flash/Flex, and I’m only targeting one platform, but I think abstraction is worth it for two reasons: logical code separation and future portability.  The basics like Math functions I’m leaving in place, but I’m wrapping input devices, graphical objects, and certain platform-specific functionality like event handling.  It makes the code a lot clearer to have most of the obscure Flash specifics in one place, and it will be that much easier to port the code if it’s ever needed.  Also, it brings a great feeling of inner peace to look at code and not see a single reference to MovieClip.

After what seemed like several good leads, unfortunately we haven’t been able to arrange a publishing deal. It isn’t all bad news: now I’ll be working on Jetpack again and retain creative control, and we will finally start to see more progress (development has been on hold for several months as it seemed likely that a 3rd party would be taking over and starting from scratch). I am only able to work part time though, since I’m not independently wealthy. I’ll be sticking with the web version initially – I may look into independent development and publishing of console versions later.

JetpackHQ finally has an official front page.  It’s basically just a teaser for what the site will contain.  Since it will change later, I’ll reproduce it here:

In other news, we are currently looking into publishing a version of Jetpack on portables and console systems.  I’ll post more information when an agreement is reached.

I’m putting the project on hold for 4 months in order to work on the website of a certain unnamed presidential candidate.  The chance to contribute was too compelling to pass up!

On another note, we are looking into a Nintendo DS version of the original Jetpack.  If you have connections in the video gaming industry and know a publisher that might be interested in such a project, let me know.

Here’s a test of the new particle smoke system I’ve been working on for the Jetpack exhaust. This one uses 400+ separate smoke particles, but in the game this number will have to be reduced for speed. I would also like the smoke to flow along the floor, but this might be too taxing on the collision system, and I might have to just make the particles disappear when they hit the floor. Whatever we end up with, I think it will look pretty cool.

This requires Flash 9 – please let me know if you have any problems getting the example to run!

There’s a delicate balance to reach between side of visual appeal & character complexity, and the side of level quality. That balance is achieved by selecting the proper scale. I’ve decided that the tiles should be one of 3 sizes: 30px, 32px, or 36px. Since the game resolution will be 800×600, adjusting for an extra wall and the status panels gives us corresponding usable level sizes of: 26tiles * 17tiles, 24tiles * 16tiles, or 22tiles * 15 tiles. (The original Jetpack’s levels were 26tiles * 16tiles).

As I’ve stated before, Jetpack 2 will not scroll, so the scale must be kept small in order for the levels to have proper complexity. However, missions will consist of multiple levels/rooms, so puzzles can span several rooms. We also want to appeal to the average casual game player, and a quick look at the most popular casual games reveals that they typically have a much larger scale. Copying what’s popular is an easy choice – but not necessarily a correct one.

Below are drafts of the different scales at the actual size they will appear in the browser (in the downloadable version this can be full screen). Included are some everyday household objects for detail reference. Keeping in mind the balance we need to achieve, weigh in on which you prefer!

36px tiles = 22×15 levels
We give up 4 columns and 1 row from the original Jetpack, but we get a significantly larger scale.
 
 

32px tiles = 24×16 levels
Levels are 2 columns smaller, characters are slightly larger.
 
 

30px tiles = 26×17 levels
Levels are about the same size as Jetpack 1, small scale characters.
 
 

A rough example of the center-less tiles that allow for more detailed levels

I’m pretty much committed to not doing any scrolling in Jetpack 2. That creates a different type of game, and I haven’t done everything I’d like to with the single-screen style yet. But I want to give the whole screen life, so I’m investigating the possibility of scrolling just the background, while keeping the foreground still. This will create a slightly odd parallax effect. The background would move very slowly to the left as the player runs right.

I wasn’t sure quite how to do this, but it reminded me of Rastan, so I fired up MAME to see how they did it. It looks pretty good in Rastan, but of course that is a scrolling game. Will it look good in Jetpack? You be the judge.

Since I’m still waiting on SWF encryption to protect my source code, I can’t publish a working demo, but try to picture the background moving in this remix of level 1.

[somehow I lost this image... sorry! if you have it, please let me know]

Note these are all programmer graphics, and will get much better once I find an artist!