As I look ahead to this year, I have several posts planned around game development in ActionScript 3 (Flash). So, I thought I should post a brief explanation about why I’m STILL developing games in AS3. After all, isn’t Flash dead? Aren’t we all living in a brave, new HTML5 world? Here are a few of the reasons why I’m developing in AS3:
As of this post, HTML5 <canvas> support is still inconsistent across major browsers. Admittedly, the main issue is Internet Explorer, but they still have a HUGE market share and can’t be completely ignored. For most of our <canvas> projects at work, we still end up building a Flash backup. If you’re targeting desktop devices for your games, publishing to Flash gives you a bigger market share than HTML5 <canvas>.
HTML5 <audio> support is pitiful. In some browsers (*cough* Mobile Safari *cough*), it barely works at all. Then there are issues with preloading sounds so they are actually available when you need them.
After my recent post about using Flashpunk to build a Flash game, I started working on a game project and quickly became frustrated with some of the shortcomings of Flashpunk. I found myself hacking the core Flashpunk engine so much that I thought I’d try Flixel and see if it worked better for me. I’m glad I did. Flixel has a lot of nice features built in that Flashpunk does not. After working with it a bit, I was able to hack together a small platformer in my free time over a few days. So, here are my thoughts on the Flixel and Flashpunk engines as well as the source code for my Flixel “game,” which is actually an interactive birthday card for my awesome wife.
First, click the image below to check out the Flixel game that I made last week (give it some time to load – there’s no preloader). You may need to click on the Flash stage to give the game focus.
I spent less than 15 hours on the whole thing and that includes coding the game, creating the artwork and even hand-coding the tilemap text file. The game has some issues, but I was rushing to get it done before my wife’s birthday and I’m pretty happy with how it turned out. Here are some things I would have changed if I had time:
Clean up the artwork. Most of the art was slapped together pretty quickly in photoshop and could use some serious polishing.
Add some sound effects
Optimize the graphics. Most of the screens use large bitmaps that should have been chopped up into smaller images.
Add a preloader
As for the eternal question of which is better Flixel or Flashpunk? Honestly, it’s a matter of personal preference, but I really prefer Flixel. If you want to build a basic platformer or top-down shooter, you could code the basic game in a day or two and spend more time building levels or creating graphics and sound. It just feels more fleshed out than Flashpunk to me.
My frustration at needing to hack the Flashpunk engine didn’t go away when I started using Flixel, however. The game that I’m trying to build requires me to hack the core of the Flixel engine too. The downside of Flixel is that the AS3 code in the Flixel engine is much more opaque than Flashpunk. Flashpunk’s code will be more familiar to most Actionscript developers, so it will feel more comfortable. In fact, I’m still working out some of the details of what I’m trying to do in Flixel and it is not as simple to tweak the Flixel engine as it was to modify Flashpunk.
Also like Flashpunk, Flixel has had a major revision at some point and a lot of the API was changed. If you are following a tutorial and the code isn’t working for you, it is probably for the older version of Flixel.
In case you missed it, you can download the source code for my Flixel game here. There is a lot of helpful code in there including how to set up scrolling, tilemaps, and collectibles. Feel free to take my code and build on it. I replaced the character sprite sheet because I want to use it again.
I was digging through some of my old files the other day and found this interesting game prototype from a few years ago, when Augmented Reality was the latest buzzword. I had seen some experiments with it, but I was curious to see if the AR Markers could be used as game controllers. Could you create a driving game where the AR Marker acted as the steering wheel? Or, could you even create multiplayer games that used multiple markers?
I started playing with the Transmote FlarManager and decided to try to create an air hockey simulation using 2 AR Markers and the APE physics engine for Flash. My game prototype can be seen in the video below.
This turned out to be a lot more challenging than I expected and I was pretty disappointed in the results. As you can see in the video, the performance of the Augmented Reality tracking is fairly weak. I also had to hack the physics engine quite a bit to get what I was looking for. Here’s the rundown of what I learned:
The Augmented reality tools are fairly clunky and require a lot of resources. That’s why most of the cool experiments you see use stationary AR Markers sitting on a tabletop. It’s too difficult to keep up with moving markers.
The Transmote FlarManager library tracks multiple markers, but it is not able to differentiate them. In other words, it can only tell that there are 2 markers on screen in my game. It can not tell which one is player 1 and which one is player 2. In this case, it really doesn’t matter. You score a point in air hockey when the puck lands in a goal – which player touched it last is unimportant. But, in many games, knowing which player acts on an object is crucial. I also tried the Squidder FLAR Actionscript library and had the same results.
APE (Actionscript Physics Engine) is a set of classes I have used before and I find it useful for simple physics-based games. The syntax makes a lot more sense than Box2D if you don’t know C++. But, for this game, I needed a Dragable Circle Particle, which is not a standard APE class. Luckily, someone smarter than me created one here. I adapted it and then created a FlarCircleParticle for my prototype.
This prototype has a lot of overhead. It uses the basic AR toolkit for Flash, the FlarManager, Papervision 3D, APE Physics, and more. So, on every frame, I’m capturing the webcam footage, trying to locate multiple AR Markers, using Papervision to calculate the positions of the players, and then running a physics simulation before drawing it to the screen. That’s a lot of work for Flash. For optimization, the Papervision probably needs to be removed and a 2D AR Marker locator needs to be created.
In essence, this experiment is a failure, which is why I never finished it. The FlarToolkit and FlarManager just aren’t capable of what I needed. I don’t consider it a waste of time, though. You need to be willing to take chances with game prototypes… and you need to be willing to give up on prototypes that just aren’t working. Very few great game ideas work perfectly on the first try, but an interesting failure can spawn a lot of great ideas.
If you want to try my prototype for yourself, download the markers and click here to test it out. The source code for this Prototype can be downloaded here. Feel free to take it and play with it. A word of warning: I built this several years ago and I hacked it together pretty quickly, so the code is a bit of a mess. If you are able to create anything cool with it, I’d love to know about it (and a shout out for wasted potential is always nice). Some links to resources you might need can be found below. Good Luck!
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.
As of this post, HTML5 <canvas> support is still inconsistent across major browsers. Admittedly, the main issue is Internet Explorer, but they still have a HUGE market share and can’t be completely ignored. For most of our <canvas> projects at work, we still end up building a Flash backup. If you’re targeting desktop devices for your games, publishing to Flash gives you a bigger market share than HTML5 <canvas>.