Category: Actionscript/AS3 Page 3 of 8

Fast Game Prototyping with Flashpunk and Minimal Comps

On January 18, 2012

In Actionscript/AS3, debugging, Flash, Game Development

The proper way to build a game in Actionscript (or any other language) is to create a quick prototype and test the gameplay. Then, if the gameplay is good, you refine it. If it isn’t working, you go back to the drawing board and create another prototype. Large game companies often scrap ideas that aren’t working when the prototype is tested.

In reality, it oftens takes so much time to get the basic mechanics working that you would never consider scrapping it, even if it isn’t really a good game. But, it doesn’t have to be that way. Two issues that slow down game development are:

#1: Dealing with basic input/output, collision detection and all of the “simple” things that you need to make a game function. Coding these elements takes hours and has very little to do with making your game awesome.

#2: Fine tuning your game. There are usually several inter-related variables that need to be adjusted. The (slow) way to do this is to make an educated guess, set the values, publish and test. Then, adjust the variable values and try again.

The good news is that there are solutions to both of these problems. The solution to problem #1 is Flashpunk. It’s an open-source AS3 framework for building pixel-based 2D games. It handles a lot of the basic animation, collision detection, keyboard input and other issues so that you don’t have to do it. It’s a pure Actionscript-based library that compiles in FlashDevelop, which is free and open source, so you don’t even need the Flash IDE. I whipped up a sample “game” in Flashpunk below. This only took me a few hours, including the learning curve.

"But, I'm making an "immersive 3D RPG for iPhone" you say? So what? You can still use Flashpunk to do some quick gameplay demos and make sure that your basic gameplay is actually fun. Once you get the hang of Flashpunk, you can whip up a simple game demo in less than a day. It may save you a lot of time down the road. Go here to get the source code and then work through the tutorials. You can be making games by the end of the day.

Now, if you tried my game demo above, you are probably saying "this sucks! I can't even jump up to the platforms!" That's where my second time saver comes in. Minimal Comps is a set of basic Actionscript3 components that can help you with your prototyping. In the game above, I've added a game tuning panel made with Minimal Comps. To see it, right-click on the stage and choose "Show Testing Console." This will open the panel with several options. The first button toggles the collision hitbox visibility. If you make the hitboxes visible, you will notice a bug that I left in the game when you move the character to the left. By changing the values in the textfields, you can adjust the game gravity and jump velocity until the gameplay works and feels right. Minimal comps makes it easy to set up this testing panel for tuning your game in real time.

Prototyping in Flashpunk with Minimal Comps for real-time game tuning is a super fast way to test out a game concept. It'll help you spend less time on the annoying part of game development and more time doing graphics and level design. Good Luck!

As always, you can download the source code for my sample here. It's a pure actionscript project, so there is no FLA. If you use FlashDevelop, you can simply open the project file and start modifying things. If you use FlashBuilder/Flex, you're on your own. Here are a few random things you might want to know:

- It is important to note that Flashpunk does not make the game for you. You still have to write all of the code for your gameplay, so you must have some basic Actionscript 3 skills and some idea of how to code a game. If you don't want to code a game, you should stick with GameMaker.

- The documentation is not awesome for Flashpunk. The forums are a great place to get answers to your questions.

- Flashpunk classes are useful even if you want to build a game in the Flash IDE, but you will need to modify the way they are used. You may want to try them out in a pure AS3 project first, so you will know how they work.

- My sample "game" is not optimized. Feel free to use the source code as a basis for your own game setup, but a lot of things need to be changed to optimize the code. I've sprinkled a lot of comments in the code to help you out.

- This is not my original idea. It is a compilation of good ideas from the sources listed below. I just put them together so I could give you some source code.

Emanuele Feronato: Creation of a platform game using Flashpunk

Photon Storm: Flash Game Dev Tip #5 - Configure your games in real time

How to use minimalcomps (GUI API) with flashpunk

In case you missed it above, here are the source files for this post.

Vizzy Flash Tracer: get trace statements from compiled SWFs

By Andy

On November 19, 2011

In Actionscript/AS3, Flash

When you are trying to track down a bug in a SWF, it’s a common practice to add trace statements to the FLA. By tracking various values in the program, you can usually find the bug. Unfortunately, it only works reliably when you publish the SWF from the IDE. There are cases where this isn’t feasible. For example, if you need to see whether or not flashvars are being received correctly by your SWF.

This is where Vizzy Flash Tracer comes in. It is a standalone program that runs beside your browser and displays the trace output of your SWF. It can pick up the trace statements from a SWF running on a remote web server, which is perfect for testing things like flashvars or communication between a SWF and javascript. Simply fire it up, navigate to your web page, and watch the trace output. It has been indispensable for tracking down bugs in my Flash applications.

Debugging with Vizzy is more reliable and faster than Flash’s own remote debugging (which often crashes the browser). It’s already become an indispensable part of my debugging toolkit. In case you missed the link above, you can download it here.

If you are having trouble getting it to work correctly, check out this page of the wiki. I have also noticed that Vizzy locks up sometimes when I have Photoshop open. So, you may have to close photoshop to do your debugging.

Flash AS3: How to hide public properties, methods, and classes in your ASDocs

By Andy

On September 13, 2011

In Actionscript/AS3, Flash

ASDocs are a great way to create an API for your AS3 classes. If you work on large projects with multiple developers, good documentation can be a big time saver – the other developers can access the public methods and properties of your classes without having to wade through your code.

I recently had an assignment building some animated components in Flash for a large Flex development project. Each component contained a dozen or so classes with a number of public methods and properties. Realistically, though, the Flex developer only needed to access the public methods and properties of a single container class for each component. The other classes just cluttered up the API with useless information. I also wanted to hide the references to stage instances in my component interface. While they are technically public properties, I didn’t want the Flex developer to reference them directly, so they shouldn’t appear in the API. Luckily, there is an easy way to hide things in ASDocs. Simply add the following comment above anything you want to exclude from your ASDocs:

/** @private */

This will exclude the element that follows from your ASDocs output. This can be used to hide a single property like this:

/** @private */
public var timeDisplay_mc:MovieClip; //this is a stage instance

Or it can be placed before the class definition to exclude an entire class from the ASDoc output:

package com.wastedpotential {
    import flash.display.MovieClip;

    /** @private */
    public class InvisibleClip extends MovieClip {

        ...stuff goes here...

    } //end class
} //end package

It’s a really simple way to clean up your API reference and hide all of the public elements that you don’t want other developers to have access to. I don’t bother creating ASDocs for many projects, but having a clean, useable API reference for large multi-developer projects is essential.

Flash mystery error 1046: InstanceInfo

By Andy

On August 8, 2011

In Actionscript/AS3, debugging, Flash

I was working on a Flash component today and it started throwing this exact error at me after I cut-and-pasted some of the designer’s assets into the FLA:

1046:Type was not found or was not a compile-time constant: InstanceInfo

I couldn’t figure it out. I didn’t have any symbols, actionscript, or instance names of “InstanceInfo.” I wasted nearly an hour tracking down this issue only to find out that it was another damn TLF Textfield BUG! Does anyone actually use the TLF Textfield? It’s nothing but trouble for me.

Enough ranting. The problem was that the designer had accidentally created a few TLF Textfields in a separate FLA, which I pasted into my FLA. Unfortunately, my document was set to publish to Flash 9, which doesn’t support TLF Textfields. The really annoying thing was that I didn’t get a warning from Flash when I pasted in the assets and the IDE gave me a cryptic and useless compiler error.

Luckily, the fix is simple. Open up the publish settings and click on the Flash tab. The IDE will then finally flag the TLF Textfields as a problem and show you a warning popup. If you want to change your publish settings to Flash 10, click “cancel” when the popup appears. If you want to keep your settings where they are, click “ok” and flash will convert your TLF Textfields to Classic Text. Save your FLA and you’re done!

I’ve been to busy to post much here lately, but I thought that this might actually save someone else a small headache.