This is Part 1 of a three part behind-the-scenes development series I’m planning for Wizard’s Tower, my free game for Windows Phone. Part 1 will focus on the physics that drive the gameplay. Part 2 will focus on how the levels were created in GLEED2D, a free, generic level editor. Finally, Part 3 will focus on how the animation was created using Anime Studio Pro 8.
First, the download link for Wizard’s Tower.
I also have a pay version here, without advertisements, for .99 cents.
Wizard’s Tower is a physics-based puzzle platformer. Unlike conventional platformer games where the player has direct control of the hero (left, right, jump, attack), in my game the hero moves and reacts to the environment by himself. It’s up to the player to manipulate the environment to get the hero safely through each dungeon level. I figured this kind of gameplay would be more touchscreen friendly because I wouldn’t have to worry about the imprecise nature of a virtual onscreen thumbstick and virtual jump/attack buttons. I have used a virtual thumbstick and buttons before, in previous games, and they worked great, but for this kind of platforming game I think it would cause more grief than anything. Pictures are worth a thousand words, but video is worth a million words, so take a look at the gameplay video below to see what I mean. Remember, the hero is moving autonomously, only reacting to the manipulations performed by the player.
Great, now we’re up to speed on the mechanics of the gameplay. Now let’s dive into how it was done.
Everything in the game is driven by physics. The movement of the hero, the movement of the critters, anything that falls, anything that jumps, and all collision detection is done using the Farseer Physics Engine. Check out their Windows Phone app to see some of the things it’s capable of doing. Virtually nothing in my game is moved around by explicitly setting X and Y coordinates of the sprites, as a non-physics game would do. Everything is being simulated in realtime.
FPE has a lot of different code classes that can be used to create things. Wizard’s Tower began with a couple days of research to figure out how – and if – I could make this game work using FPE. This would not be my first game to integrate physics using FPE. I’ve used it before in my Zombie Circus games in order to drive the ragdoll physics behavior of the zombie clowns when you toss them around and blow them up. In those games, however, the movement of the zombies as they walk across the screen was done using conventional positioning of the X, Y coordinates of the sprites.
Because of the nature of the platformer I was imagining – jumping around, falling, bouncing off obstacles – I knew that the game would have to be completely driven by physics. The first task in creating Wizard’s Tower was getting a character to move around by himself and react to the walls and floors of the dungeon around him. To this end, I used FPE to generate various physics Bodies with Joints constraining them together in order to build the hero character.
Everything in FPE that is simulated is called a Body. A Body can be either Static or Dynamic. A Static Body does not react to forces. In other words, a Static Body does not move when something hits it. As you can imagine, Static Bodies are perfect for being used as floors and walls. A Dynamic Body does react to forces applied to it. A Dynamic Body will also react to gravity, and fall. It will bounce or roll when it hits another Dynamic or Static Body. In Wizard’s Tower, the dungeon floors and walls are Static Bodies, and the hero Body is Dynamic. More about the significance of this will be covered in Part 2, when I talk about parsing the level data into the physics engine.
FPE has a system for “pinning” one Body to another using Joints. A Joint is a constraint mechanism that “pins” one Body to another in a special way. There are several different kinds of Joints in FPE, each of them eliciting a different behavior. For the player’s hero, I decided to focus on using a box pinned to the center of a circle using a Revolute Joint. As its name implies, one body is pinned to the other in a way that allows them to spin freely and independently.
Revolute Joints have a unique property which allows them to have a motor speed, causing the Body using this type of Joint to rotate under a specified power. Imagine pushing on the gas pedal, and the wheels of your car turn. Perhaps you can already see where I’m going with this. The circle I mentioned above would be my “wheel” that quite literally drives around the dungeon level.
A Joint requires two different Bodies to function, so I couldn’t just have a wheel rolling around the level by itself. That’s why I pinned a Box Body to the center of the wheel. Since I didn’t want the Box and the Circle colliding with each other, I set them to ignore collisions with each other using FPE’s “IgnoreCollisionWith” method. Other than providing a second Body to pin to, the Box Body is a dummy with no other function. See my original proof of concept video below. Notice the Circle Body behaves like a single wheel off of a car or bike (unicycle?), with the Box Body pinned to the center of it. The goblin sprite image is simply drawn at the position of the Circle Body as it rolls around the level. At this early stage of development – literally the first evening – I had no graphics of my own, so this goblin I used is not mine.
When the hero is on the inclined bridge, notice how the Circle Body doesn’t slide down, even at that steep of an angle. That’s because of the extremely high Friction value I’m using (float.MaxValue). By trial and error, I set the Revolute Joint’s “MaxMotorTorque” value so it would be strong enough to roll up a steep floor. Since I also have objects in the game that can be pushed, the motor torque had to be strong enough for that, also. To make the Circle Body move left or right, I just set the Joint’s “MotorSpeed” to a positive or negative value.
The code to set up the Circle Body, Box Body, and the Revolute Joint pinning them together is quite simple.
At this point, I had movement down. Next was to handle jumping, which you can also see being demonstrated in the proof of concept video above. One line of code took care of jumping. Since this is being simulated with physics, you can’t set the position coordinates manually. Instead, you have to apply a force or impulse to the Body. In FPE, forces and impulses are used to push and/or spin Bodies around in the World. In this case, I opted to use the ApplyLinearImpulse method in the FPE framework to launch the hero up into the air. ApplyLinearImpulse takes a Vector2 as a parameter to specify the force and direction to apply the impulse.
FPE also has an ApplyForce method which can be used to push things around. What is the difference between applying a force and applying an impulse? Good question! A force affects the velocity of a body over time. An impulse is applied to a Body instantly. Since I needed the Body to react as soon as it reaches a Jump Node in the game, I chose to apply an impulse for an immediate change in speed and direction.
Movement? Check. Jumping? Check. One last thing the hero needs to react to – hitting a wall and turning around. Since the hero is not being controlled by the player, he has to be able to think for himself, and that means turning around when he hits a wall or other obstacle. I needed a way to determine when something hits something else.
The FPE framework simulates a World object on every frame of the game (at 30 frames per second). When you create Bodies, Joints, and other physics entities, they are added to this World object that you create during game initialization. You can see this in the code sample above – each Body and Joint creation method has my game’s World object as the first parameter. That way, the World knows about these entities and simulates them accordingly. The World object itself also has a number of callbacks that can be subscribed to in order to “trap” when certain events occur.
These callback events are akin to your game code putting an ear to the wall and waiting to “hear” when something happens. In my case, I needed to subscribe to the World’s ContactManager.PostSolve event in order to “hear” when things collide with each other. Much of the game is based off of things colliding and reacting accordingly. For example, when the hero enters a spike trap or lava pit, he must die. When a moveable block is pushed over a pressure plate, it needs to trigger something. When a chandelier hits a critter, the critter must die. All of these events are detected when Bodies collide with each other, and it all happens during the World’s PostSolve event.
Great, I can detect when things collide, but how do I distinguish what collided with what? Bodies that are created and added to the World can be assigned a CollisionCategory. Wizard’s Tower has 14 different collision categories that get assigned to various physics Bodies in the game. The Bodies that make up the hero (remember the Box and Circle?) are assigned a Collision Category of Cat3. Again, this can be seen in the code block above. The border of the level is assigned a category of Cat1. During the PostSolve event, I can peek into what the Collision Categories are of the objects that just collided with each other. If one Body is Cat3 (the hero) and the other is Cat1 (the level border), I know the hero just hit a wall. All I have to do now is multiply the Circle Body’s MotorSpeed by -1 to reverse it in the opposite direction of whatever it was just traveling in. That’s literally all there is to it.
Below is just a small piece of my PostSolve event to show how I’m testing the collided objects against different Collision Categories to figure out what just collided.
Movement, jumping, and turning around against a wall – mission complete for my initial research into making a physics driven puzzle platformer. This concludes Part 1. I hope you join me for Part 2 when I explore creating the levels for Wizard’s Tower, and continue explaining the role of Farseer Physics in turning that level data into a physically simulated world for the hero to move around in.Tweet