If you’re like me, you use Firefox or Chrome as your browser of choice for development. They’re both pretty web-standards compliant and they have nice developer tools. So, your javascript code is working perfectly and you test it in some other browsers…
It silently crashes in Internet Explorer! If you are using IE9, you hit F12 to look at the developer tools and track down the error, but it suddenly starts working perfectly! No Errors! You close the developer tools and it fails again. Huh?!
This is a common IE issue. Internet Explorer does not have a javascript console by default, so any calls made to the console will throw an error and crash the program. If you open the developer tools, then the console works and it stops throwing the errors. There are 2 basic solutions to this issue:
1) Comb through your code and remove all calls to the javascript console. Usually the problem is some random console.log() statement you added for debugging and forgot to remove.
2) The more elegant solution is to add some code that will stop the console from throwing errors in IE. Here is a snippet of code I often include at the top of my projects to fix the problem:
<script type="text/javascript">
try {
console //does the console exist?
}
catch(e) { //if not...
console = {}; //create a console object for IE
console.log = function() {}; //add a log method to the new console object
//add other console methods here if you need them
}
</script>
Note that this code only fixes console.log() calls. The javascript console has other methods that may need to be added to this script too. If you do some Googling around, you can probably find a nice little polyfill* that you can include in all of your projects that will take care of all the console functions.
*If you don’t know what a polyfill is, don’t feel bad. It’s basically a piece of code that inserts non-native functionality into javascript. In this case, the polyfill doesn’t actually do anything except prevent IE from throwing errors.
Disclaimer: there are some other javascript peculiarities to IE, so this may not be your problem, but ruling it out is a good place to start.
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.
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.
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 wasanother 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.
