The first thing we are going to need to do is plan our game. From experience, we know that tic-tac-toe has a 3×3 grid, where you place X’s and O’s. So, we know that we will need 3 graphics, one for the grid, one for the X, and one for the O. We don’t need multiples of the X or O, because we can draw them in the program as many times as we like. Lets eliminate this first step. Our grid is going to be 600×600, and our X’s and O’s will be 200×200 (1/3 of the area).

Now that we have our images, we are going to need a way to load them into our program. Open up CApp.h and make some modifications. Remove the Test Surface, and add three new surfaces.

Also, open up CApp.cpp and make some modifications. Remove the Test Surface again, and add the three new ones again.

And, you guessed it, open up CApp_OnCleanup.cpp to make some modifications there too. Just like before, get rid of the Test Surface and add the three new ones.

Now that we have the surfaces setup, lets load them into memory. Open up CApp_OnInit.cpp, and make some changes. Get rid of the test surface (again), and load the three new ones. Be sure to put the correct filenames. Also, change the dimensions of the window to 600×600, the size of the grid. This make sure we don’t have any blank space around the window we aren’t using.

You may have noticed a change I made in the filenames. I added ./gfx/ before the filename to specify which folder the graphics are in. As games begin to grow it’s very practical to have all the files in one folder. Because of such, from hereon, all images will be put in the gfx folder.

Now, let’s get the grid showing up on the screen. Open up CApp_OnRender.cpp and change the test surface rendering to make the grid render.

Try compiling your program, and if successful, you should see the grid show up. Remember, there are basically 5 steps to using a surface: declare it, set it to NULL, load it, draw it, and then free it. It’s good practice to learn all these 5 steps now, because later on if you neglect one of these steps if can cause problems. For example, neglecting to set a surface to NULL can cause undefined behavior, or neglecting to free a surface can cause a memory leak.

You may have noticed something odd about the graphics we are using, the X and O contain a pink background. There is a reason for it, we are going to implement transparency onto these surfaces. Basically, wherever there is pink, it will show through; we will make the pink color transparent. SDL offers a simple function to do this, SDL_SetColorKey. To implement this, open up CSurface.h so we can add a new function.

Now, to implement this function, open up CSurface.cpp and add the function:

Notice 3 extra arguments being passed besides the surface. These are the 3 color values that we want to make transparent, it doesn’t have to be just pink. For instance, it we wanted red to be transparent it would be 255, 0, 0.

This function first checks to see if we have a valid surface. If so, we set a color key (transparency) for a color. The first argument is the surface to apply the color key to, the second is some flags telling SDL how to perform the operation, and the third is the color to make transparent. The flags being applied are basic, the first tells SDL to apply the color key to the source (the surface being passed) and the second tells SDL to try to use RLE acceleration (basically, try to make drawing later on faster). The third argument is a little bit more complex; we are using SDL_MapRGB in order to create a color. SDL_MapRGB takes a surface, and your requested color (R, G, B), and tries to match it as close as it can to that surface. You might be thinking why this is useful. Not all surfaces have the same color palette. Remember the old NES days where there was only a few colors that could be used? Same idea here, SDL_MapRGB takes a color and matches it with the closest color on that surface palette.

Lets apply this new function to our surfaces now, open up CApp_OnInit.cpp and make the following changes:

Everything for the surfaces should be set. The next thing we have to do is figure out a way to draw these X’s and O’s. We can’t just draw them everywhere on the grid because they won’t always be in the same spots. What we are going to have to do is make an array of 9 containers, the values in this array will tell us the values for each cell on the grid. So, spot 0 would be the top left, 1 would be the top middle, 2 the top right, 3 the middle left, and so on. Create this array by adding it to CApp.h:

We know that each cell can have three possible values: Empty, X, and O. These tell us what is currently in that cell. To make things a little neater than having 0, 1, 2 as values, we’ll use an enum instead. If you are umfamiliar with how an enum works, try finding a quick tutorial on them. Just know that GRID_TYPE_NONE = 0, GRID_TYPE_X = 1, and GRID_TYPE_O = 2. Go back to CApp.h and add the following underneath the Grid array:

Note, up to this point I have been displaying practically all the code when I am referring to different files. From hereon, I expect you to know where code goes. Most of the time I will tell you where to place it by, and sometimes I might display all the code.

Now that we have a way to know what a cell is, we’re going to need a way to reset the board. Let’s create a new function at the bottom inside of CApp.h called Reset.

Open up CApp.cpp and add the following function just before int main:

This loop will set every cell in the grid to GRID_TYPE_NONE, meaning that all the cells are empty. We’re going to have to do this at the very beginning when our program is loaded, so make a call to this function within the CApp_OnInit.cpp file:

So far so good. The next thing we are going to have to do is make the ability to place X’s and O’s on the screen. Lets create a new function that will handle this. Open up CApp.h again and add the function just below Reset.

Now, open back up CApp.cpp and add the function:

This function takes two arguments, the first is the cell ID to change, and the second is the type to change it to. We have to conditions here, the first is to make sure we don’t go outside the bounds of the array (if we did it would likely crash our program), and the second is to make sure we passed an appropriate type. Simple enough.

Now, let’s implement a way to draw the X’s and O’. Open up CApp_OnRender and add the following code just after the grid:

This is a little bit more complex than we have been used to so far. Firstly, we are looping through each cell in the grid. Next, we are translating that grid ID over to X and Y coordinates. We do this in two different ways. To find X, we take the remainder of i to 3. This will give us 0 when i is 0, 1 when i is 1, 2 when i is 2, 0 when i is 3, and so on. We multiply it by 200 because each cell is 200×200 pixels. To find Y, we divide by 3, this causes Y to be 0 when i is 0, 1, 2, Y to be 1 when i is 3, 4, 5, and so on. We then multiply that by 200 as well. I encourage you to really try to understand what is going on here because this sort of method is used for tile based games.

Next, all we have to do is check the cell type, and then draw the correct surface at that cell.

Now that we have our surfaces drawing, we’ll need a way to communicate from the user to the computer. We’ll use mouse events for this. When the users clicks a cell it will set the cell appropriately. We are going to need to overload one of the CEvent functions for this. Open up CApp.h and add the following function just below OnEvent and next to OnExit.

Now, open up CApp_OnEvent.cpp and add the function:

First, we are doing the reverse of what we did with translating to X and Y from an ID, this time we are translating to an ID. We then make sure that that cell hasn’t already been taken, if it has, we return out of the function. Next, we are checking which players turn it is, set the cell appropriately, and then switch turns. CurrentPlayer is a new variable to specify whose turn it is, so we’ll need to add this. Open up CApp.h and add the variable below the grid array:

Also, set the default value for this variable in CApp.cpp:

Try compiling the program and you should have a mostly working version of tic-tac-toe. Congratulations!

This is where you take the rest of it yourself. We have a solid foundation for our game, and most the work done. I encourage you to take this a step further. Try adding a “X Won”, “O Won”, and “Draw” at the end of each game (extra images here). Think, how are you going to check who won (a function for this purpose would fit well)? Try adding a way to reset the game after it’s done. If you are brave, try to add some generic AI that will play against the user. And if you are even braver, try adding the ability to play player vs. player, or player vs. computer.

When you are ready, and have a firm grasp of this tutorial, move on to the next lesson to look at frame animation.

SDL Tutorial – Tic Tac Toe – Tutorial Files:
Win32: Zip, Rar
Linux: Tar (Thanks Gaten)

If you haven’t caught on, each tutorial builds off the previous, so we’ll be using the code from the previous lesson. In order to track all these events and throw them into nice functions, lets create a new class. Create two files called CEvent.h and CEvent.cpp. These two files will handle our events, and call the appropriate function. CApp will inherit this class, so when we need to catch an event we simply override a function.

Open up CEvent.h and add the following code:

Pretty hefty class right? Alright, open up CEvent.cpp, and add the following code:

Lots of code, but all the SDL events should be covered. What we basically are doing is taking an SDL_Event pointer, and switching through the types, and then calling the appropriate function. It just looks like a lot since they are quite a bit of events.

Now that this has been all setup, let’s jump over to CApp.h and link the two together:

Everything should compile just fine. We have the event class setup, now lets actually link events to our new class structure. Open up CApp_OnEvent.cpp and edit the following function:

We’re passing the Event structure to our class now, it will take care of the correct function calls. Now when we want to check for an event, we override the function. Since we got rid of checking for the SDL_QUIT event, lets use the function instead. Open up CApp.h again, and add the following function:

The OnExit function handles the SDL_QUIT events. Now that we have the prototype, lets define what it does. Open up CApp_OnEvent.cpp, and add the following:

Recompile, and try it out. You should be able to close the application just like before.

I encourage you to look through some of the various events that we can check. Later on we’ll use some of these events in our games, but for now try to familiarize yourself with them.

Jump on over to the next tutorial to take a look at creating our first game, Tic-Tac-Toe.

SDL Events – Tutorial Files:
Win32: Zip, Rar
Linux: Tar (Thanks Gaten)

In these tutorials we will be referncing to CodeBlocks as our IDE of choice, with gcc and mingw for compilation. If you wish to use another IDE and compiler that is up to you, but it may be harder to follow along if you have limited experience with linking libraries. If you wish to download CodeBlocks, you can do so for free at http://www.codeblocks.org (download the one including the mingw package). We recommend you use the stable version, unless you want to spend the extra time and use the nightly builds.

These tutorials will be heavily centered around SDL (Simple DirectMedia Layer), a 2D cross-platform graphics library. This library is going to allow us to draw fancy graphics to the screen, and do all sorts of fun stuff that allows us to make a game. You’re going to need to download this library at http://www.libsdl.org; be sure to download the Mingw32 tar file under “Development Libraries” and “Win32″ and the zip file under “Runtime Libraries” and “Win32.” If you are using Visual Studio download the appropriate version instead of the Mingw32 file. Once downloaded, we recommend you put the .dll found in the zip in your system32 folder. This way whenever we open an SDL application it can find the dll file it needs.

Open the tar file now (the one that was listed under “Development Libraries”) and decompress the contents to a folder (such as C:\SDL). Now, open up CodeBlocks so we can change some settings. Click “Settings” on the menu bar, and then click “Search Directories” tab. You’ll need to add C:\SDL\include to the “Compiler” tab, and C:\SDL\lib to the “Linker” tab (change C:\SDL to wherever you decompressed the files to). Once done, click Okay.

Start a new “blank” project, calling it whatever you want. Save it some place. Click on “Project” on the menu bar, and then click on “Properties.” A dialog will open; click on the “Project’s build options…” button on the bottom right. Click on the “Linker Settings” tab and add the following to the list under “Link libraries”:

mingw32
SDLmain
SDL

The order is important, so use the arrows to rearrange the list until it matches what is shown above. If you are having a little trouble figuring out what we are doing, we’re simply “linking” code together, or, in other words, we’re taking the SDL code and combining it with our own. We do this by using the include files to compile, and the lib files to link. And once done, our code is put together to make one application.

Click Ok twice, and you should be all set to go!

Let’s create two new files called CApp.h, and CApp.cpp; these will serve as the core for our program. First, open CApp.h and add the following code, in here is where our tutorial will really begin:

Now, open up CApp.cpp and add the following code:

The CApp class is setting the stage for our entire program. Let me step aside to take special note of how games are typically setup. Most games consist of 5 functions that handle how the game processes. These processes are typically:

Initialize
This function handles all the loading of data, whether it be textures, maps, NPCs, or whatever.

Event
This function handles all input events from the mouse, keyboard, joysticks, or other devices.

Loop
This function handles all the data updates, such as a NPCs moving across the screen, decreasing your health bar, or whatever

Render
This function handles all the rendering of anything that shows up on the screen. It does NOT handle data manipulation, as this is what the Loop function is supposed to handle.

Cleanup
This function simply cleans up any resources loaded, and insures a peaceful quitting of the game.

It’s important to understand that games are one gigantic loop. Within this loop we find events, update data, and render pictures. Thus, the basic structure could be thought of as:

Each iteration of the loop we do something with data, and render accordingly. Events are extra, as a means for the user to manipulate data as well. In that sense, Events aren’t required to make a game, but are needed when you want the user to be able to manipulate data (such as move a NPC to the left).

Let’s clarify this idea with an example. Say we have our Knight, the hero of the game. All we want to do is simply have him move around. If I press left, he goes left. We need to figure out how to do this within a loop. Firstly, we know we want to check for events (keyboard events). Since Events are a means to manipulate data, we also know we’ll need some sort of variables to modify. Then we can use these variables to render our Knight appropriatly on the screen. We could have:

This works because each loop it checks if the key is LEFT, RIGHT, etc., and if so, we decrease or increase a variable. So, if our game is running at 30 frames per second and we press LEFT, then our guy would move to the left 30 pixels per second. If you don’t understand the game loop, you soon will. Games need them to function correctly.

Going back to our conceptual code (the 5 functions), we can add these additional pages to our project:

CApp_OnInit.cpp
CApp_OnEvent.cpp
CApp_OnLoop.cpp
CApp_OnRender.cpp
CApp_OnCleanup.cpp

Go back to CApp.h, and add the following functions and variables:

Go through each of the 5 files we just created and create the function themselves:

Now lets go back to our CApp.cpp code to link all of these functions together:

You’ll notice some new variables, but let’s look at what is happening first. First, we try to Initialize our game, if it fails we return -1 (an error code), thus closing our program. If everything is good, we continue on to the game loop. Within the game loop we use SDL_PollEvent to check for events, and pass them one at a time to OnEvent. Once done with Events, we go to OnLoop for move data around and what not, and then render our game. We repeat this indefinitly. If the user exits the game, we proceed to OnCleanup cleaning up any resources. Simple enough.

Now, lets look at SDL_Event and SDL_PollEvent. The first is a structure that holds information about events. The second is a function that will grab any events waiting in the queue. This queue can have any number of events, which is the reason why we have to loop through them. So, for example, lets say the user presses A and moves the mouse during the OnRender() function. SDL will detect this and put two events in the queue, one for a key press and one for a mouse move. We can grab this event from the queue by using the SDL_PollEvent, and then passing it to OnEvent to handle it accordingly. Once there are no more events in the queue, SDL_PollEvent will return false, thus exiting out of the Event queue loop.

The other variable added, Running, is our own. This is our exit out of the game loop. When this is set to false, it will end the program, and in turn exit the program. So, for example, if the user presses the Escape key we can set this variable to false, quitting the game.

You should be able to compile everything so far just fine, but you may notice you can’t exit out. You’ll probably have to use the task manager to end the program.

Now that everything is setup, let’s start by creating the window our game will be drawn in. Jump over to CApp.h and add a SDL surface variable to the code:

I suppose now would be a good time to explain exactly what a SDL Surface is. An SDL Surface is anything that can be drawn, or drawn to. Say we have a blank piece of paper, a pencil, and some stickers; this paper could be called our display “surface.” We can draw to it, put stickers on it, or whatever. The stickers we have are also surfaces; we can draw on them and put other stickers on them as well. So, Surf_Display is simply our “piece of blank paper” that we will draw all our stuff on.

Now, lets jump on over to CApp_OnInit to actually create this surface:

The first thing we need to do is start up SDL itself, so we can access its functions. We are telling SDL to Initialize everything it has; there are other parameters you can pass, but understanding them at this point is not important. The next function we use is SDL_SetVideoMode. This bad boy is what creates our window, and our surface. It takes 4 parameters: The width of the window, the height of the window, the bit resolution of the window (recommended to be 16 or 32), and then display flags. There are quite a few display flags, but the ones shown above are fine for now. The first flag tells SDL to use hardware memory for storing our images and such, and the second flag tells SDL to use double buffering (which is important if you don’t want flickering on your screen). Another flag that may interest you now is SDL_FULLSCREEN, which makes the window go fullscreen.

Now that our display is setup, lets cleanup a little bit to make sure everything works smoothly. Open up CApp_OnCleanup.cpp and add the following:

The first thing we do is free the display surface, basically freeing any memory. Once that is done, we quit out of SDL. You should take note that in this function is where you would free other surfaces as well (probably before the Surf_Display). This keeps all your code centralized to the function its performing.

To keep things tidy, lets also set the Surf_Display pointer to NULL on the class constructor. Open up CApp.cpp and add the following:

Try compiling your code, and watching it work. You should have a nice blank window popup. You’ll notice you can’t close it though, so you’ll need to use the task manager to do so.

Now that we have a window all setup, we’re going to need a way to close it. Open up the CApp_OnEvent.cpp file, add the following:

The SDL event structure is broken down into types. These types can range from keypresses, to mouse movements; what we simply are doing here is checking the event type. The type above we are looking for is the request to close the window (i.e., when the user clicks the X button). If that event happens to take place, we set Running to false, thus ending our program. Simple enough. We’ll look more into events in a later lesson.

Now, you should everything setup, and a good structure to work with later. It may be a good idea to take this project and turn it into an “SDL template” within CodeBlocks. I won’t go over how to do that, but feel free to Google it.

Once you have a good idea what’s going on with the code we covered in this lesson, jump over to the next game tutorial lesson to learn more about SDL surfaces.

SDL Tutorial Basics – Tutorial Files:
Win32: Zip, Rar
Linux: Tar (Thanks Gaten)