Game & Code

During my first sprint to learn game programming, a large chunk of the time was spent learning C++, or trying to compile and install different pieces. Definitely not fun stuff. Because I use Python at work, I decided to give Python game development a shot. First step is to get a hello world example up and running -- it was surprisingly easy so we're off to a good start.

See it in Action

This wonderful ball will bounce around the screen.

Making it Happen

I downloaded this binary. If the link expires, you can find the full list here.

After successfully downloading, run the installer.

I'm a huge fan of Sublime Text 2 as a text editor. Download it.

Paste this code into SB2.

Additionally, download the ball graphic, save it as a gif, and change the source code to reference .gif instead of .bmp

Save the file as ~/GameDev/python/ball.py

Run the script with F7, or fn-F7 on my keyboard.

Looking at Sprites and Groups

Beyond the initial install, I played around with sprites and groups a bit. In past SFML projects, textures became sprites, which were stored in an Object Manager, and then om->draw was called which would draw all objects in the container. Using the example source code above, here is how we could modify it to achieve a similar result.

Polish is also the hardest part, and easiest to skip. Push yourself at this stage.

Now that the menu system is nearly complete, the next step is to get a tile map going. This process has involved quite a few iterations, and I believe there are still more to come. Ultimately, we'll end up with a map or background that is redrawn every frame.

Different Types of Tiles

Common tile formats include orthogonal (square), isometric (diamond) and hex. A few examples, and a intro to tile based game can be found on wikipedia. I've decided to go with isometric tiles for two reasons: I found a nice tile pack that happened to be isometric, and depth is easier to create.

First Attempt: Hardcoded Sprites

To get my feet wet without having to add more infrastructure code, I loaded up 100 sprites in a loop.

for(int x = 0; x < 100; x++) { ImageObject *bg = new ImageObject(); bg->LoadFromTextureSheet(texture, sf::IntRect(0, 0, 64, 32)); bg->SetPosition(x*64, 0); std::stringstream key; key << x << "bg"; _OM.Add(key.str(), bg); }

Then, back in the main loop, a single call to _OM.Draw() would successfully display 100 tiles to the screen. It's great that it sticks with the central Object Manager concept, but there are two significant problems.

Extremely slow.

Not easy for designers to work with.

Second Attempt: Only One Sprite

The first problem to tackle is speed. While 50 sprites may load fine, 2000 sprites made my computer chug. The logical fix is to start with one sprite, and change its position multiple times per frame.

for(int x = 0; x < 10; x++) { sprite->SetPosition(x*64, 0); sprite->Draw(); }

That sample code would draw 10 tiles across the top of the screen. This instantly fixed performance issues, but introduces another problem.

Our concept of an Object Manager that is responsible for drawing every frame is now broken. sprite->Draw() needs to be called outside of _OM->Draw().

Still not easy for designers or level editors to work with. 

Third Attempt: Using an Array

Because solving the Object Manager concerns would take a large refactor, I moved on to trying to make things easier for designers. Using an array would present a basic visualization of what the map is supposed to look like. Sticking with one sprite, we could make a map like this:

char worldmap[5][5] = { {'A','A','A','A','A',}, {'A','A','A','A','A',}, {'A','A','A','A','A',}, {'A','A','A','A','A',}, {'A','A','A','A','A',}, };

Iterating over that array will draw a square of our one tile. This is progress, but we're still left with two issues.

The 'A' is a hardcoded reference to our one tile. When we have more than one, how do we make dynamic aliases?

We're still drawing outside of the Object Manager.

Fourth Attempt: Using Aliases

Let's head back to how we load our tiles. The basic approach is to iterate over the sprite sheet and load images in by increasing x*64 each iteration. That works, but how do we know the name of the tile once it is loaded into the Object Manager -- we have no way to reference it. Some sort of collection is needed so that we know exactly what to load from the sprite sheet.

struct Tile { public: int x; int y; int width; int height; sf::String alias; }; std::list _mapTiles; Tile desertA; desertA.alias = "A"; desertA.x = 0; desertA.y = 0; desertA.width = 64; desertA.height = 32; _mapTiles.push_back(desertA);

In the sample code, a list of map tiles is created. Each tile is a struct that contains coordinates, size and an alias. The alias is used as the key in the Object Manager.

std::list::iterator it; for ( it = _mapTiles.begin(); it != _mapTiles.end(); it++) { ImageObject *bg = new ImageObject(); bg->LoadFromTextureSheet(texture, sf::IntRect(it->x, it->y, it->width, it->height)); _OM.Add(it->alias, bg); }

Using this approach, we can now create a second sprite with an alias of 'B' and use 'B' in the array. But, as always, we still have two concerns.

This becomes quite verbose. If we have 100 sprites, we need a list of 100 variables crated. The creation of tiles structs should be dynamic somehow.

Still manually drawing outside of the Object Manager.

Fifth Attempt: External Files, Software Tools and Classes

I'm done for tonight, but there is still plenty more to research about drawing tiles. The list for now is:

Load Tile info from a JSON array.

Load map array and Tile info from an external JSON or XML file.

Learn to use Tiled, and import from one of the supported exports.

Contract artwork

Art, music, and more at graphic river

Chipmunk 2D physics engine

I decided to switch gears a bit tonight and setup version control with Github. Having backups to revert to is always great. Especially so when you veer off into experimental code. Also, it is always nice to publish source online so that others can learn by example. And finally, switching between my laptop and desktop will now be super simple, and not require me to email code back and forth.

See it in Action

If you remember from my lessons learned, I'm working on a splash and menu screen. That code can now be seen online. There is a ton of refactoring to come, so don't start copy / pasting anything just yet.

Getting Started

Getting Xcode to work with Git and Github has a few quirks, but is pretty straightforward. Here are the initial steps I took.

Xcode 4 comes with Git support from the get go. So, when you created your project, if you didn't disable Git, your project is already under local version control.

Create a free Github account.

Download the Github for Mac client.

Install and open the client. Type in your credentials. 

Don't add any local repos yet.

.gitignore

Xcode contains a bunch of user specific files that we don't need to share with the world. To prevent those from being versioned, we need to add a .gitignore file. In Xcode, add a file at the project level and name it .gitignore. Then, paste the contents found here into the file and save.

Folder Structure

When working with Xcode, you can add a New Group by right clicking, but not a New Folder. Visually, they look like the same thing. However, a group is just a concept while the actually files still live at the root. This doesn't scale well, so we'll want to use actual folders. Let's set up the Resources folder as an example.

Left click on Resources folder icon.

Open the right pane (Utilities window).

Locate Identity -> Path.

Relative to Group should be the default selection.

Right under that, notice Resources, and then a clickable icon to the right.

Click the icon to bring up a file browser.

Click New Folder in the bottom left, and name it Resources.

Hit Choose.

Repeat those steps each time you create a New Group.

Adding a Local Repository

Head back to the Github client, and also open up Finder. In Finder, browse to your project path. Drag the entire project into the Github droppable area. Nothing visual happens to indicate success, but if you click on My Repositories you should now see it listed. Double click to jump in to that repository. All of your code should be listed under Changes, and the ignored files should not be there. Click Commit to stage the code and get it ready to be pushed to Github.

Creating a Remote Repository

I've spent about 20 hours over the past week starting to work with real code. Because first impressions, or complications in this case, are hard to remember, I've documented the trouble spots I ran into. If you're a beginner, these tips may save you a few hours. Regardless, I would highly recommend reading, and then coding, the Game From Scratch tutorial. The rest of this post will focus primarily on that tutorial. After spending time with it, I feel I have a much stronger grasp of not only how a game works, but more importantly the code design patterns used. In the end, working with efficient, reusable code is much more important than learning how to load a sprite.

See it in Action

Splash Screen and Menu in full glory!

Watching the video, you can see I made the scope of the project even smaller. The end goal was to create a splash screen that fades in, and a functional menu system. No game logic yet. While the task sounds easy, plenty of hurdles were encountered.

Learn About Xcode 4

I spent a decent amount of time just reading about Xcode 4 to see how others use it, and to find any tips I should be aware of. There is still plenty to learn, but I found a few favorite ideas.

Command - Shift - o : Quick file open.

// TODO : Comment will show up in class browser.

Command - ] or Command - [ : Toggle code indentation.

Opening Game.cpp in split screen mode will place Game.h in the second screen.

Includes

The tutorial is primarily geared towards Windows users, so be aware of the includes at the top of files. We can start by removing any include to stdfax.h. After that, look for missing includes -- for example, Game.h needs to be included at the top of Splash.cpp.

Changes in SFML 2.0

A few things have changed between SFML 1.6 and 2.0. For a complete list, see this explanation. In regards to the tutorial, the main changes that affected me are:

sf::Window::GetEvent is now sf::Window::PollEvent

sf::Rect is now (left, top, width, height)

Event Handling in the Game Loop

The sample code provided looks like this:

while(!IsExiting()) { while(_mainWindow.GetEvent(currentEvent)){ switch(_gameState) { case Game::Playing: { } } } }

The problem with that example i that the switch will not be entered unless an event is triggered. So, nothing will happen until you move your mouse, or hit a key. To fix this, move the switch outside of the event handling.

while(!IsExiting()) { while(_mainWindow.GetEvent(currentEvent)){ } switch(_gameState) { case Game::Playing: { } } }

The above code will enter the switch on every frame.

Handling _gameState

When I began working with _gameState, I tried to modify the variable directly within the splash screen code. Instead of passing it around, or making it a member variable of a class, return a boolean or enum from splash screen and handle it back in Game.cpp. Have a look at my main menu code as an example.

void Game::ShowMenu() { Menu main; Menu::MenuResult result = main.Show(_mainWindow); switch(result) { case Menu::Play: { _gameState = Game::Playing; break; } case Menu::Exit: { _gameState = Game::Exiting; break; } case Menu::Nothing: {break;} } }

Game.cpp appears to eventually become just a switchboard that manages the different screens.

Fade In / Out Animation

My first attempt at an animation was severely flawed. Instead of incrementing the alpha property by 1 each frame, I tried to start an infinite loop during one frame to essentially freeze the game and finish the animation before returning back to the loop. In theory, this should have worked even though the approach is not ideal. However, when nesting whiles with each calling renderWindow.Display() I noticed some performance issues and freeze ups. In the end, I just refactored to the proper approach and everything is working as expected. Each frame, this is called:

sf::Uint8 Splash::FadeTextIn(sf::RenderWindow & renderWindow, sf::Text & text) { sf::Color color = text.GetColor(); color.a++; text.SetColor(color); return color.a; }

And then renderWindow.Draw(text) is called afterwards. For a side note, I was encountering problems in every loop that did not have event handling in it. See this discussion for more information.

Variable Scope

Variable scope is a concept I don't fully understand yet in C++. To illustrate my confusion, let's look at an example loading a text object. The code looks like this:

sf::Font font; font.LoadFromFile(ResourcePath() + "sansation.ttf"); sf::Text text(playButton.phrase, font, 30); text.SetPosition(playButton.x, playButton.y); text.SetColor(sf::Color::White);

Now, if we throw that code into a loadText function that returns a sf::Text object, the project will build. However, at run time, a bad access error will be thrown on the sf::Fontobject that was used to create the sf::Text object. I worked around this by declaring the font as a member variable in my header file, which I believe opened up the scope to all functions. However, I am still unsure of the proper way to handle this.

Wrap Up

I arbitrarily decided to begin my gaming adventures with sprites. Loading and using images seems like a pretty common operation with games, so why not. Basic understanding of sprites tells me that a few things will have to happen.

Create or download an image

Create a sprite sheet

Load the image as a texture

Display the image as a sprite

I started out by firing up Pixelmator, ready to convert the super cool image in my head to a digital format. Because I have no skills with photo editing, or art in general, this proved to be a difficult and time consuming task. Seems like it would be easy to get stuck here in an unproductive place, so I just grabbed an image from google search.

Next up, a sprite sheet. Basically, one image that contains a bunch of images on it. We'll slice and dice the sheet up once it is loaded into memory to display the individual images. Much to my surprise, there is a clean, simple app to help us out -- Zwoptex. Update: TexturePacker is an equally great tool for this. Creating the sheet is as straightforward as selecting the images you want to include, and hitting publish. 

Copy over the published result into your Xcode Resources folder to bring it into the project. Then, we'll load the image as a texture.

sf::Texture texture; if (!texture.LoadFromFile(ResourcePath() + "war_sprite.png")) return EXIT_FAILURE;

After that, create a new sprite from that texture.

sf::Sprite sprite(texture); sprite.SetSubRect(sf::IntRect(0, 0, 82, 94));

Notice the IntRect object being passed in. The parameters are left, top, width, height. If we look at the directory we published our sprite to, there is a .plist file include with the image. Opening that up reveals multiple settings, including the location of each image on the sprite.

textureRect String {{0, 0}, {82, 94}}

Zwoptex trims out any whitespace on the images, so this .plist file saves you the time of trying to manually figure out where an image started and ends. Lastly, draw the sprite to the screen.

window.Draw(sprite);

Introduction

SFML is a great, light weight library to help manage assets in a game. When looking for a game engine / builder, I wanted to find something that provided minimal assistance so that I could learn as much as possible. Some builders provide software that contain editors and level generators with drag & drop GUI ease -- I wanted to avoid those for now. The goal is to learn what is actually happening, and not have software do it behind the scenes. SFML seems to fit those needs.

See it in Action

It's boring, but we'll get a window with an image, font and sound when we're done!

Getting Started

Before beginning, make sure Xcode is up to date. This tutorial is based off of Xcode 4.2.1. If you don't have Xcode, the easiest way to get it is through the App Store. Of course, you can always use your own editor, but since I'm an Apple fanboy I'll be using Xcode exclusively.

Next, we have to download SFML. I went with 2.0 because it is well documented, and actively being worked on. Since I'm not releasing anything to production, I can tolerate stability issues. With that in mind, head over to the Github repo. You can pull down the source, or download it as a zip.

Compiling SFML with CMake

Now that the source is downloaded, our first step is to compile it with CMake. This a bit annoying because it is yet another piece of software to download, but understandably the developer does not want to manage every type of install. Fortunately, a step by step walkthrough is provided.

First, go ahead and download CMake. During the install, choose to add the command line links if you are prompted. Go ahead and launch CMake, and then switch over to the walkthrough linked to above. Hop down to the section on Configuring your SFML Build. For steps 1 and 2, I created custom paths:

/Users/username/GameDev/SFML /Users/username/GameDev/SFMLBuild

Browse to whatever paths you would like to use, and select them. Then, click Configure as suggested. I received a prompt asking me to specify the generator --  leave the default unix makefile and native compilers selected. Changing to Xcode caused quite a few permission issues for me when trying to install. Next, check off every box except the DOCS. Make sure you scroll down and get INSTALL_XCODE4_TEMPLATES as well. Click Configure one more time, and if that works, click Generate. At this point, confirm you have files in the SFML Build path above.

Building SFML

Because I'm relatively new to C++ and builds, this section is magic to me. Follow along with the walkthrough if you're comfortable. Or, if you're like me, copy from a forum post that works. Open up terminal, and go through the following steps. Before starting, make sure you have a /usr/local directory.

cd GameDev/SFMLBuild make clean sudo make install

After the third command, you should be prompted for your password. Type it in and hit enter. From there, build progress messages should start appearing.

Jump Into Xcode

Our hard work is about to pay off. Open up Xcode, and select Create a New Project. The next menu should have a list of project types on the left, like so:

Application

Framework & Library

...

Other

SFML

If you don't see SFML on the list, it means that you missed a check box in the CMake section above. Fear not, for the templates can be manually installed as shown in the README. Now, create a SFML Application, give it a name, and we're working with a sample application. Click Run in the top left, and a lovely window should open as seen in the See it in Action section above.

Open Game Art - You can get lost here for hours.

Spell Icons - Think of buffs / spells in an MMO.

Lost Gardens Collection - Free art released over time.