GLZelda-1-Src
GLZelda-1-Bin-OSX
GLZelda-1-PDF

Update:
Fixed the links… <_<

ZeldaGame- game assets

Once again, we will be writing up a Zelda-like animation, because the file’s on-hand and already formatted and somewhat optimized for our use. And so, if you don’t have it from following previous tutorials, here it is again:

Sample Animation Sheet

Setup

Start out by creating a new project in Torque Game Builder. I am using version 1.7.5 on my Mac, but there should be no differences between platforms or versions for this project. I’m calling mine “ZeldaGame” and including the executable, but that’s personal preference more than necessity. Once you’ve got the project created, make sure you create a new image map from the Link animation sheet above by either dragging the file into the assets pane on the right (under Static Sprites – only works on Windows), or by using the Create ImageMap button.

After creating the image map, double-click on it so that we can edit its properties as follows:

Link Image Map

Image Mode: Cell
Filter Mode: Smooth
Cell Height: 64
Cell Width: 64

This will break our sprite sheet into its individual frames, ready to be used in animations. It’s best to keep as many frames of an animation set within the same file as possible, because it will help the Torque engine to limit the number of times it is changing the texture context during the game’s execution.

Animation Naming Scheme

It is important to come up with a naming scheme for your assets and your animations. In this sample, it was fine to leave Link’s image name as linkImageMap, because it’s the only image we’re going to have. Your animation names, however, should have a structured and defined naming scheme, because it will make things much easier when you are writing the behavior (or class, if that is your preference) that will control which animation we are displaying. For this project, we will use “linkRunDirectionAnimation” for our names; link being the name of the entity, Run being the name of the object’s state (running, as opposed to swimming or dying), Direction being the direction he is running (North, South, East, or West), and Animation to denote that this is an animation resource.

We will now create four animations: North, South, East, and West. Click the Create New Animation button, and select the linkImageMap image as the base for our animation. Double-click each frame, in sequence, to add it to the animation. Change Frames Per Second for the animation to 15 (so that it looks good), and name the animation based on the direction he is going (such as linkRunSouthAnimation). Create the remaining animations, and we can begin programming our behavior.

Behave, Link!

Now we are going to write a behavior script to define the Link object’s interaction. In this project, our behavior is going to control everything about our player- it will store the object’s state, ensure that the proper animation is playing, and we will be able to edit the player’s movement speed within the editor interface. Open your project’s folder and create a new file in ZeldaGame/game/behaviors/ folder called playerBehavior.cs. You can use Notepad, Text Edit, Torsion, TextMate, or whatever your TorqueScript editor preference to write these scripts, so long as it is saved without special formatting data that may occur from applications such as word processing applications.

// Make sure the PlayerBehavior object doesn't already exist
if(!isObject(PlayerBehavior))
{
	// Create & Define the template
	%template = new BehaviorTemplate(PlayerBehavior);

	%template.friendlyName = "Player Controls";	// This is the name that will appear in the Behaviors property
	%template.behaviorType = "Player";	// This will be the category under which the behavior appears
	%template.description = "Player input for the Zelda sample";	// This will provide the user with a description of the property

	// Behavior fields will expose values to the editor interface
	// Note that, unlike the Torque Game Builder documentation's used of simply
	// "Up" and "Down", we must define "keyboard" as the source for the binding.
	%template.addBehaviorField(runNorthKey, "Run- North", keybind, "keyboard up");
	%template.addBehaviorField(runSouthKey, "Run- South", keybind, "keyboard down");
	%template.addBehaviorField(runWestKey, "Run- West", keybind, "keyboard left");
	%template.addBehaviorField(runEastKey, "Run- East", keybind, "keyboard right");

	// Bind the Movement Speed for Link
	%template.addBehaviorField(runSpeed, "Movement Speed", float, 15.0);

	// Movement Flags
	%template.direction = "South";
	%template.FLAG_RUN_SOUTH = 0;
	%template.FLAG_RUN_NORTH = 0;
	%template.FLAG_RUN_EAST = 0;
	%template.FLAG_RUN_WEST = 0;
}

In this first portion, we are actually defining the behavior template. As this is covered in the TGB documentation, I’m not going to go into too much detail- I recommend reading up if you’re unfamiliar with behaviors in TGB. Down at the bottom, though, we set some flags that we will use for checking our movement. The first, “direction,” will allow us to determine which directional animation we wish to display (North, South, East, or West). The following four are used to determine whether the associated key is being held, as we want to use prioritized animations with movement, but don’t want to lose the player’s ability to run in multiple directions.

// Called when the behavior is added to an object by the editor
function PlayerBehavior::onBehaviorAdd(%this)
{
	// Enable the Update callback
	%this.owner.enableUpdateCallback();

	// Make sure that the moveMap object exists before attempting
	// to bind keys to it
	if(!isObject(moveMap))
		return;

	// Bind our movement keys
	moveMap.bindObj(getWord(%this.runNorthKey, 0), getWord(%this.runNorthKey, 1), "runNorth", %this);
	moveMap.bindObj(getWord(%this.runSouthKey, 0), getWord(%this.runSouthKey, 1), "runSouth", %this);
	moveMap.bindObj(getWord(%this.runEastKey, 0), getWord(%this.runEastKey, 1), "runEast", %this);
	moveMap.bindObj(getWord(%this.runWestKey, 0), getWord(%this.runWestKey, 1), "runWest", %this);
}

Again, all of this is covered in the Torque Game Builder documentation. Note, however, the highlighted line. Here, we are enabling the onUpdate() callback function, which will be called every frame to allow us to update the object where needed. We will use this to check the animation against the current object state, and to update movement information.

// Utility Function - Get what our current animation name is supposed to be
function PlayerBehavior::whichAnimation(%this)
{
	return "linkRun" @ %this.direction @ "Animation";
}

// Movement Keys
function PlayerBehavior::runNorth(%this, %val)
{
	%this.FLAG_RUN_NORTH = %val;
}

// [...]

Because of their simplicity, I’m not going to include all of the movement response functions in this online sample- they each just edit their associated flag based on whether the key was pressed or released. The utility function, whichAnimation, will allow us to quickly get the animation that we are currently using. Normally, we would use an animation state variable in place of “Run,” but I’ve eschewed it in favor of simplicity.

// Player Update
function PlayerBehavior::onUpdate(%this)
{
	%standing = false;

	// Directional Animation Priority
	if(%this.FLAG_RUN_SOUTH)
		%this.direction = "South";
	else if(%this.FLAG_RUN_NORTH)
		%this.direction = "North";
	else if(%this.FLAG_RUN_EAST)
		%this.direction = "East";
	else if(%this.FLAG_RUN_WEST)
		%this.direction = "West";
	else
		%standing = true;

	// Movement
	%this.owner.setLinearVelocityY((%this.FLAG_RUN_SOUTH - %this.FLAG_RUN_NORTH) * %this.runSpeed);
	%this.owner.setLinearVelocityX((%this.FLAG_RUN_EAST - %this.FLAG_RUN_WEST) * %this.runSpeed);

	// Check the animation, and set it if it must be updated
	if(%this.owner.getAnimationName() !$= %this.whichAnimation())
		%this.owner.setAnimation(%this.whichAnimation());

	// If we're standing still, use the 'idle' frame (0)
	if(%standing)
		%this.owner.setAnimationFrame(0);
}

Here is the meat of our project. First, we create a temporary variable that we can set to mark the player as simply standing there (rather than walking in place, a la Final Fantasy). We check each of our movement flags sequentially, allowing us to prioritize which direction our player will be considered to be facing (South > North > East > West), and if none of them are pressed, we set the player to be standing (the direction variable will persist across frames, so the player will be facing the last direction he was moving). Next, we set the linear velocity -the amount the player moves each frame- in both vertical (Y) and horizontal (X) axes by calculating the value of the directional flags multiplied by the run speed (if the south and north keys are pressed together, the player will not move in that direction, for example (1-1=0=false)).

Finally, we check the animation’s name and compare it to our whichAnimation() function, and if it is not already set to the appropriate animation, we change it to such with setAnimation(). Note that these are called on the behavior’s owner, not the behavior itself – and you will want to make sure that the owner of the behavior (the object to which the behavior was assigned) is a t2dAnimatedSceneObject or a derivative of such (Animated Sprites dragged from the editor window are t2dAnimatedSceneObjects), so that the animation functions actually work. If the player is standing (%standing == true), we set the animation frame to 0, which is perfect for our idle image. You might also choose to include an idle animation, set as another animation state, if you wish to have an animated idle object.

Tying it all Together

Now, you will want to either close out the editor and re-open it, or you will want to go to Project->Reload Project in order for the editor to automatically load in our behaviors. Drag your South animation over from the editor window, under Animated Sprites, and place Link wherever you’d like. Next, select the object we just placed and go into the Edit pane. Under the Behaviors category, select “Player Controls” from the drop-down menu and click the + button the left to add the behavior to the player object.

Player Controls behavior

Now simply press Play, and use the arrow keys to move Link around. Congratulations, you’ve now got Link running around in the middle of absolutely nothing!

Welcome to my newest tutorial series: SFML Zelda. Throughout this tutorial series, we will be building a two-dimensional Legend of Zelda fan game. Before we begin, I want to say what this tutorial is and is not. The tutorial is a basic game programming tutorial, written with C++ and the SFML 1.6 game library. The series is not covering advanced game development techniques. There are many things that I will cover in this tutorial that are better handled by other means, and I encourage you to look for other resources and expand your knowledge.

Code License

All code in this tutorial series is released under the zLib 1.2.2 License (can be viewed here).

Tutorial 3 Overview

For this tutorial, I am going to be taking a different approach. There is only a minor amount of code in this tutorial, as I am instead going to focus primarily on an explanation of the system that we are designing for the game, and some of the reasoning behind the decisions that I will be making regarding it. The code will be switching us from using the standard Window class to the RenderWindow class within the SFML Graphics package, and will change our system to use an event structure, rather than relying on the task manager or debugger to kill the application instance.

SFML-Zelda GitHub Project

Table of Contents

Updated Code
System Overview

Welcome to my newest tutorial series: SFML Zelda. Throughout this tutorial series, we will be building a two-dimensional Legend of Zelda fan game. Before we begin, I want to say what this tutorial is and is not. The tutorial is a basic game programming tutorial, written with C++ and the SFML 1.6 game library. The series is not covering advanced game development techniques. There are many things that I will cover in this tutorial that are better handled by other means, and I encourage you to look for other resources and expand your knowledge.

Code License

All code in this tutorial series is released under the zLib 1.2.2 License (can be viewed here).

Tutorial 2B Overview

In this tutorial, we are going to establish the SFML Zelda project in Xcode 4. I am using a beta copy of Xcode 4.2, so there may be minor differences between our build environments, but these should be minimal. In this tutorial, we will obtain a copy of the SFML SDK and build a minor test project.

SFML-Zelda GitHub Project

Table of Contents

(I)Obtaining SFML
(II) Creating the SFML-Zelda Project
(III) Project Configuration
(IV) Test Code

Downloads
AnimationDemo Binary
AnimationDemo – Source

Setup
Go ahead and set up an XNA project. The system I’m showing here is rather simplistic, and has many areas in which it can be improved for efficiency, but this isn’t something that’s going to require a complex project setup.

How it will work
This animation system will include a very basic Finite State Machine-style animation, using a single sprite sheet for rendering. While scene objects in this sample only use a single sprite sheet per object, it could be modified so that animation data is stored outside of the scene object, which will pretty much be necessary (you’ll see why in a minute) for anything more complex than this sample.

Sprite sheets are expected to be set up with each included animation in the sheet containing an equal number of frames. Each animation state gets its own row within the sheet, with each frame of the animation taking up one column per row. Every frame must be the same size, and there is no assumed spacing or borders for the sheet or the frame. The image I am going to use in this sample is a running animation from The Legend of Zelda: A Link To The Past.

Fig 1: Sample Animation Sheet

Welcome to my newest tutorial series: SFML Zelda. Throughout this tutorial series, we will be building a two-dimensional Legend of Zelda fan game. Before we begin, I want to say what this tutorial is and is not. The tutorial is a basic game programming tutorial, written with C++ and the SFML 1.6 game library. The series is not covering advanced game engine development techniques. There are many things that I will cover in this tutorial that are better handled by other means, and I encourage you to look for other resources and expand your knowledge.

Code License

All code in this tutorial series is released under the zLib 1.2.2 License (can be viewed here).

Tutorial 2A Overview

In this tutorial, we are going to establish the SFML Zelda project in Visual C++ 2010. I have a copy of Visual Studio 2010 Professional, so there may be some minor differences between my screenshots and what you have, but the functionality and locations of settings should be exactly the same, and there will be no functional difference in the builds for our projects. In this tutorial, we will first retrieve a copy of SFML then recompile it using Visual C++ 2010. We do this because the libraries provided for SFML are compiled against VS2008, and the libraries have incompatibilities that cause problems when attempting to run the program (the program will appear to have compiled with no problems).

After we build the project, we are going to establish the Visual Studio solution for SFML-Zelda and configure Visual C++ to work with our directory structure. Finally, we will test our project setup by building a small sample project with SFML.

Table of Contents

(I) Obtaining SFML
(II) Placing the SFML Libraries
(III) Create the SFML-Zelda Project
(IV) Project Configuration
(V) Test Code

(I) Obtaining SFML

The first step to preparing SFML for Visual Studio 2010 is to obtain a copy of it. For these tutorials, I will assume the use of SFML 1.6 – if you wish to use SFML 2.0 then you proceed at your own risk. Go to the SFML Download Page and find the heading that says “C++ | version 1.6″ We are going to download the Full SDK, because we need access to the SFML source code in order to recompile it. I recommend creating a separate folder on your computer for storing libraries – I do this because I prefer to include libraries that projects depend on with the project themselves, rather than storing (as many tutorials have you do) the files in your Visual C++ include and library directories.

After unzipping the files, open the ‘lib’ folder and delete them. This will ensure that all of our library files are built against Visual Studio 2010, rather than 2008, and will allow us to proceed unimpeded. Next, open the “build,” then “vc2008″ folders, then open SFML.sln – this is a Visual Studio 2008 Solution file, and so if you have VC2008 installed alongside VC2010, you will need to ensure that you open it with VC2010. Allow Visual C++ to do its magic in updating to the new solution format, then go ahead and close the conversion log.

Figure 2.1

Next, we need to select the type of build. There should be six build types: Debug, Debug DLL, Debug static, Release, Release DLL, and Release static. The Debug and Release builds only apply to the sample projects – we want Debug static and Release static to give us libraries to build against in each configuration. First, select Debug static, then Shift-select all of the projects with the “SFML-” prefix (should be under the SFML folder, as in Fig 2.1). Right-click, Build Selection, and wait for it to complete, then do the same for Release static – we now have SFML libraries to build against!

Figure 2.2

(II) Placing the SFML Libraries

Now that we’ve got the SFML libraries compiled into our static .lib files, we can move them somewhere the engine can take advantage of them. Go into the ext/ directory that you created in the last tutorial for the project and create a new folder called “sfml-1.6.” In this folder, create two more folders: inc and lib – these will hold the SFML header files and library files, respectively. Back in the SFML directory that you compiled from earlier, go into the new lib/vc2008 folder and copy all of the .lib files over to the ext/sfml-1.6/lib directory for our project. Now go back to SFML, then go into the Include directory. Copy the SFML folder over to our inc folder, and we should be ready to create the project. (You should now have ext/sfml-1.6/inc/SFML/(bunch of headers)).

(III) Create the SFML-Zelda Project

We are now ready to create the SFML-Zelda project and begin configuring our build process. If you still have Visual Studio open from building SFML, go ahead and close the SFML solution. Otherwise, open up a new copy of Visual C++, and let’s get started. The first thing we want to do is create a new Win32 Project. For name, I suggest using “msvc2010″ for the sake of the solution and directory names, but you can honestly choose whatever you wish. Under location, you want to select the proj directory we created in the first tutorial, and uncheck “Create directory for solution,” as this will cause some disparity in our configurations (will likely just be an extra ../ in our “additional include/library files” options, but it’s nice to be on the same page). In the Win32 Application Wizard, ensure that Windows Application is selected and check Empty Project, then click Finish. Congratulations, your project has been created, and we can begin configuration. Before we move on to the next step, though, go ahead and delete the three default folders: Header Files, Resource Files, and Source Files – we’re going to have a different scheme to our project directory structure.

(IV) Project Configuration

First File

Now it’s time to configure our project. Visual C++ likes to use its default configuration – Microsoft’s a pain like that. Luckily, with a little bit of know-how it’s not all that difficult to switch to our setup. Before we configure, we need to create a blank C++ source file, so that we can access the C/C++ options in the project settings. This is where the biggest nuisance with Visual Studio comes up the most: you need to check the directory for the source file you’re about to create every time you go to create a file, or you’ll end up placing it in the wrong folder because Visual C++ is spiteful. I’ve done this a lot, and it’s annoying, but it’s the price we pay for a more efficient project directory structure.

Figure 2.3

Figure 2.4

We’re going to go ahead and create a Filter structure that matches the actual directory structure used in our project. So first, go into your src directory and create a system folder – all source and header files relating to platform code (most of which should be abstracted just fine through SFML) will go here throughout the project development. Then create a corresponding Filter in Visual Studio by right-clicking on your project, selecting Add, then New Filter (see Figure 2.3) and name it system. Now right-click on that filter and select Add -> New Item… and select “C++ File (.cpp)”. Here’s where we have to pay attention – first, name the file. We’ll go ahead and call it main.cc (I prefer the .cc file extension – it’s exactly the same as .cpp, so you can choose whatever you like, but I choose to stick to the Google Style Guidelines). This is where we’re going to end up storing our main() and WinMain() functions, so when we get to that point we’ll be good. Before you create the file, LOOK AT THE LOCATION BOX. It will likely contain something along the lines of C:\Whatever\Programming\SFML-Zelda\proj\msvc2010\ – you need to replace this with “SFML-Zelda\src\system” – and you’ll need to change the directory every time you create a file in a different folder. After this, we can begin with project configuration.

General

Now right-click on your project (not your solution!) and select Properties. Here is where we start to have some fun. The first thing we want to do is ensure that we’re making changes that affect all build configurations – debug and release. So first, in the upper-left hand corner, change “Active (Debug)” to “All Configurations” next to the “Configuration:” label.

Figure 2.5

Now we will change the output directory. This is where our executable (.exe) files will be placed when we compile our project, and where we will be placing all game media when we begin to develop the game itself. By default, General should be open and Output Directory should be a visible option – if not, select General under Configuration Properties. The default Output Directory is “$(SolutionDir)$(Configuration)\” – you’re probably wondering what these are. In Visual Studio’s configurations, you can use environment and application variables by including the variable name within $( ) – which makes it easier for us to understand and change folders. $(SolutionDir) is the directory of the .sln (in our case, SFML-Zelda\proj\msvc2010) file, and $(Configuration) is the current build configuration. We want to output to SFML-Zelda\bin, so we want to change Output Directory to “../../bin/” for this project. Because we are placing all builds within the bin directory, regardless of whether they are Debug or Release, we need to differentiate the executable names. By default, Visual Studio uses the Project name – we are going to use “Zelda” with the build configuration appended to the project name (ex: Zelda_Debug.exe). If you named your project Zelda, go ahead and use $(ProjectName)_$(Configuration) – otherwise, use Zelda_$(Configuration) to make it look nice. One thing of importance is to make sure that you DO NOT INCLUDE A FILE EXTENSION. This will be done automatically. Go ahead and click “Apply” to save your configuration settings.

C/C++ General

Next, select General under C/C++ (if this is not available, make sure you created a C++ source file and not a header by mistake). Here, we will configure the project so that we can easily include the SFML headers for our project, and we will make an easier means of including header files throughout our project without using relative include directives at every turn. Under “Additional Include Directories,” enter ../../src/;../../ext/sfml-1.6/inc – this will add our SFML include directory, and our source root, to our include paths. This will allow us to do things such as the following:

#include "Window.hpp"

#include "game/stateMachine.h"

rather than a relative include, as:

#include "Window.hpp"

#include "../../../game/stateMachine.h"

Linker General, Linker Input

Now we have to do the same thing for the Linker settings, so that it knows where to find our library files. Under Linker -> General, change “Additional Library Directories” (about mid-way through the available options) to ../../ext/sfml-1.6/inc. Then, move down to Linker -> Input – here we are going to select our static libraries. These will be different for the Debug and Release builds, so change your configuration (as we did when we first opened the configurations) to Debug.

Click the drop-down arrow and select edit, then add the following libraries (one per line):
sfml-system-s-d.lib
sfml-window-s-d.lib
sfml-audio-s-d.lib
sfml-graphics-s-d.lib
sfml-network-s-d.lib

Do the same for Release, but with the following:
sfml-system-s.lib
sfml-window-s.lib
sfml-audio-s.lib
sfml-graphics-s.lib
sfml-network-s.lib

And now we are ready to enter some test code!

(V) Test Code

Open the system/main.cc file that you created earlier and enter the following code:

#define WIN32_LEAN_AND_MEAN
#include <Windows.h>

#include "SFML/Window.hpp"

int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)
{
	sf::Window app(sf::VideoMode(800, 600, 32), "SFML Window");

	while(true)
	{
		app.Display();
	}

	return 0;
}

This will display an SFML window, though you won’t be able to do anything with it (even close it through normal means) – to close the application, you’ll want to press Shift+F5 within the Visual Studio window. To compile the project, select a Debug or Release configuration (up near the green Play button), press F7 to compile the solution, and then you can press F5 to debug the project. If a window appears, then congratulations, you’ve completed the first step in creating our SFML Zelda project!

Welcome to my newest tutorial series: SFML Zelda. Throughout this tutorial series, we will be building a two-dimensional Legend of Zelda fan game. Before we begin, I want to say what this tutorial is and is not. The tutorial is a basic game programming tutorial, written with C++ and the SFML 1.6 game library. The series is not covering advanced game engine development techniques. There are many things that I will cover in this tutorial that are better handled by other means, and I encourage you to look for other resources and expand your knowledge.

Code License

I am releasing all code in this tutorial series under the version 1.2.2 (October 2004) zLib license.

/** Copyright (c) 2011 Ken "Minalien" Murray

This software is provided 'as-is', without any express or implied
warranty. In no event will the authors be held liable for any damages
arising from the use of this software.

Permission is granted to anyone to use this software for any purpose,
including commercial applications, and to alter it and redistribute it
freely, subject to the following restrictions:

   1. The origin of this software must not be misrepresented; you must not
   claim that you wrote the original software. If you use this software
   in a product, an acknowledgment in the product documentation would be
   appreciated but is not required.

   2. Altered source versions must be plainly marked as such, and must not be
   misrepresented as being the original software.

   3. This notice may not be removed or altered from any source
   distribution.
**/

Tutorial 1 Overview

In this tutorial, I am going to cover the basic structure of our engine, and we will create the directory structure and explain my reasoning behind it. The project we will create will work on any platform for which there exists support for SFML, but I will be explaining the creation of the project on Windows and OS X 10.6 using Visual C++ 2010 (Express edition should work fine for this) and XCode 4 (Available from the Apple Developer Center if you are a registered developer, or for approximately $5 USD on the Mac App Store) respectively. Finally, I will be using the Google C++ Style Guide for my code in these tutorials. Style guides aren’t entirely necessary, but they help to ensure that coding style remains consistent across between members of a development team.

Directory Structure

(Root Directory) – I’m calling mine SFMLZelda, to differentiate it from my other projects
        bin – This is where we will configure our IDEs to place project executables on build. It will not be included in the source control if you choose to set one up (I’m setting up GIT for this)
        ext – This is where I am going to place external libraries. I do it this way because it’s easier for other developers to ensure they are using the same versions of all dependent libraries
        src – This is where all of our source files will reside, and will be broken into its own smaller directory setup for each category of source files (video, system, etc).
        proj – This is where the editor-specific project files will be placed. Each will have its own subdirectory to keep it separate from the others – msvc2010, xcode4, or whatever other editors you should choose to use.

I choose to set it up this way because it helps to keep external libraries separate (but available), keeps binaries and intermediate build data away from our source code directories, and keeps project directories separate and clean.

The next two tutorials are going to cover creation of the project – one in Visual C++ and one in XCode 4, including setting up SFML. The SFML libraries aren’t pre-built for Visual Studio 2010, so I will cover retrieving the code from the Git repository and building it for our game project. After the project is established, the third tutorial will cover the overall design concept behind our Zelda game, and then we will begin programming the project in earnest.