How to keep Your Actors From Going Off Screen

A common question that I run in to all of the time on different Stencyl related forums and blogs is, "How do I keep my character from leaving the screen?".

We all need this feature for different reasons, at different times. Some may need to stop the player actor from leaving just the sides of the screen. This works for side to side shooters like Galaga, where the player is fixed into a single Y position and can only move on the X axis. Then there are others who may need to set boundaries for left, top, and right, but leave the bottom alone, for pitfall style games where you want your player to be able to fall in to traps or large holes.

My instance was a little more complicated than this. I am making a game that scrolls vertically. The player sprite starts at the bottom of the scene, and moves to the top of the screen. The scene is about ten times bigger in height than the standard 15 tile layout. This entails some challenges and obstacles to overcome.

First off, the default screen position is X=0 and Y=0. That would mean that the default screen position is aligned with the top left corner of the scene. Well, this doesn't do us any good, because our players roughly 5,000 pixels further down in the scene! This simple problem can be solved with the addition of a camera.

How I solved this problem was to create a "Dummy Actor" that the camera would stay centered on. Placing the Dummy on the very bottom layer of the scene, under the background, makes him invisible to the player, but the camera will still follow him through the scene. I simply drew the dummy actor down at the bottom of the scene, right in what would be the dead center of the screen in a normal sized scene. I then drew the player actor about five tiles down, but two layers up, above the background image. Now, using a few blocks of code, we can make the dummy actor move through the scene and the camera will follow him the whole way. Since all this Dummy Actor will do is move through the scene at a set pace while the camera follows, for ease of use, I just attached these blocks in the actors events opposed to creating a separate behavior.

Now, we have our camera. If you were to test your scene at this point you would see that the camera does in fact scroll northward to the top of the scene at the pace that you set the dummy actor to move. The problem with this is that with the camera moving rapidly, but the player actor being stationary without input, it is very easy for the actor to fall off the bottom of the screen and become in active.

In order to fix this little dilemma of ours we need to incorporate some screen boundaries to stop our player actor from exiting the screen. If you followed the crash course tutorials on stencylpedia, then you should know how to set boundaries for the X position, but I will include the code anyways for those slackers out there who didn't follow those specific tuts.

Setting the Y boundaries can be a little tricky depending on the type of game that your creating. I know when I first started using stencyl, figuring out this whole boundary thing after adding a camera to the mix was a migraine headache in the making. But, with a little persistence I was able to come up with this:

There's a few very important things to note about these blocks. One is that when you get to the Y coordinates, you don't want to use Y(on screen). You want to just use Y. The reason for this is that you will be using the Y coordinate of the camera as a starting point. The scene is 150 tiles at 32 pixels per tile. That's 4800 pixels for the height of our scene. What we did here, is we used Y of the camera to find the top boundary. That one's easy. Next, we used Y of the top corner of the camera + the screen height to find the bottom border.

Voila! We now have boundaries that our player character can not exceed! This method works well for Y scrolling games, like Aero Fighter, but the same might not be true for other types of games. In the next tutorial, I will show you how to modify this script to fit other game types. Until then, Cheers!