Testing your Game
by Jon (Updated on 2014-01-29)
- Testing your Game
- Testing on Mobile Devices
- Printing to the Console
- Debug Draw
- FPS Monitor
- Compile Errors
- Runtime Errors
Testing your Game
Pick the Platform and press the Test Game button, or type Ctrl + Enter (or Command + Enter on Mac) to test your game.
You can also do this from the Run menu.
By default, Stencyl games test in the standalone (desktop) version of Flash Player.
Testing Standalone Games (Windows, Mac, Linux)
Testing on Mobile Devices
Print to the Console
It's often useful to record things that happen in a game during testing in a way that can be easily seen. For example...
- Telling whether a piece of logic "happened", especially if you suspect that that logic is not being reached
- Telling what the value of an attribute is. It may be different from what you think!
One quick and easy way to do this is to print these values to the console. Think of the console as a temporary text file that you can write out text to and view while the game is running.
How to Print to the Console
Use this block. (Flow > Debug)
To view the console in-game, press the ` key. It's the one below ESC.
Debug drawing is a special mode in which collision shapes are drawn as outlines. This can help you debug physics-related problems.
Debug drawing is toggled from the Run > Enable Debug Drawing menu item.
The FPS Monitor reports the framerate and memory usage for your game in the top-right corner. It can be toggled from the Run > Enable FPS Monitor menu item.
It's normal for a game to see small but continual memory increases even if nothing is happening. After a while (30 - 60 seconds), the memory usage will suddenly drop back to a baseline level. This is known as garbage collection, a time when a program ditches a bunch of memory it's holding to but has no more use for.
Compiler Errors (can't run game)
Ever seen this window? This is a Compiler Error, which is an error that happens when we're unable to build your game into a Flash SWF for testing or exporting.
In most cases, if you hit OK, we'll open the offending behavior and highlight the blocks that are at fault.
In this case, we've used the "actor inside region" block outside its context. It has to be used inside its wrapper (something that seems obvious but can easily happen if you're not careful).
What are the common causes of compiler errors?
- Using blocks outside their intended contexts, like what happened above.
- Something changed on our end, and it broke your game. (Rare)
On iOS, compiler errors are somewhat more common. In many cases, these are caused by failing to "cast" (convert) a value to text when printing it or drawing it to screen.
What can I do about them if I'm stuck?
- Drag out the offending blocks and see if the error goes away. Divide and conquer works well in isolating the issue.
- Once you've figured out WHERE the problem is, try to understand the problem. What is the error message trying to say?
- If you're stuck, ask on the forums. Take screenshots and attach your logs. (TODO: link to that article)
Runtime Errors (game errors out)
Runtime Errors are errors that happen while the game is running. They frequently lead to "freezing" of the game. If your game is freezing up, check what shows up in the Log Viewer (View > Log Viewer if it isn't open). You might see this kind of text.
Fortunately for you, a runtime error usually tells you what's going on. The first line usually tells you where the error happened. You often see line numbers (line 57), which can point you roughly towards the offending line.
What causes runtime errors?
By far, the most common cause is referring to an actor after it's been killed.
If you're stuck, ask on the forums. Take screenshots and attach your logs.
1) Come up with a testing workflow that you feel comfortable with. Don't blindly guess what's wrong. Stick to the facts and verify your assumptions by printing to the console.
2) Is your game running slowly? Read the next articles in this Chapter to diagnose the causes and come up with solutions.
3) It can tempting to "reinstall" the software to fix problems. In reality, this not only wastes time, but it can also cause more problems in the long run. Although there are circumstances where a reinstall is required, avoid the temptation and only switch to it as a last resort.
- Use print blocks to print to the console.
- Use the FPS Monitor to measure memory usage.
- Debug drawing can be useful for debugging physics.
- Develop a testing workflow that works for you.