Monday, September 30, 2013

Creating our Media Manager - Part 1

Hello again,

This is the second hands-on post of our journey to SpaceRock Miners. We are going to start modeling the game: we should have an initial class model for the Output block by the end of the post.
I must say that I decided to license this under the MIT license. It basically allows you to use it for whatever you want, however you want, given that you follow one simple requirement; it doesn't even require attribution. Read it here.

From this point on, I am assuming you read the previous post and successfully achieved allegro compilation. Also, you must have a basic grasp on C++ as well as understand the basics of Object Orientation. I'd like to emphasize that this tutorial has an intermediate level of difficulty, so it may be overwhelming for some of us. If so, go around the web studying Object Orientation, Modeling and programming.

The Media Manager Class

Our goal here is to create a functional Media Manager that can control our window resolution and state (fullscreen, windowed, border-less windowed [...]) as well as rendering and playing sounds. Based on our initial and simple architecture (found here) we'll need at least two classes and a interface:
  • A media_manager class that issue the basic commands, like draw, play sound and update, to the System block; it is part of the Logic block.
  • A media_system class that will implement an interface between the media_manager and Allegro itself, in order to decouple our game from Allegro as much as possible; coupling is never good if you can avoid it.
  • A allegro_media to manage all the actual drawing, rendering, resizing [...]. Highly coupled with Allegro. Will implement the System portion of all our graphical needs.

 Looks easy, doesn't it? Still, these classes will have a lot of stuff in them. Stop and think for a second: what do we need it to do for us?
  1. Draw Sprites, static and animated, rotated and scaled;
  2. Draw a parallax scrolling background image;
  3. Draw the User Interface (Health Bar, Score [...]);
  4. Play Effect Sounds;
  5. Play the Background Music;
  6. Control the Resolution and Type of display we want;
  7. Update the display for every frame.
This small list shows us that we need some more classes: one for Sprites and one for the User Interface. The User Interface needs one more thing: Text; what takes us to the next class we need, one for Text and Fonts in general. I'll be leaving the sounds out for now, and add it later.

The Sprites needs Bitmaps, that are the images themselves which, as do the fonts, need to be loaded from disk, so we need some way to do it.

All of these classes need their own interface for system access, so I guess 8 more classes on the way: 4 interfaces and 4 system block classes. But my guess is probably wrong and it'll take more classes.

An interface is really simple to implement, it is basically a list of functions; while the system classes are where we actually implement these functions. In a sense, an interface is not a complete class, but since we are using C++ it is a class and is declared as one.

What a Mess!

This is getting bigger and bigger, ain't it? I think that if we go straight to our IDE and start to mash our keyboards it'll get even worse. What should we do? We should plan. Plan our Manager classes in advance, so we can think of what they'll need (system interface functions that the manager will use) and how they'll interact with the other classes (their own interface, that the manager will provide).

How do we do that?, you ask me. This is called modeling, and is something really simple to explain but hard enough to make big companies hire specialized professionals to do it for their big programmer nightmares games. Everyone learns as they do. A classic case where the necessity to know something teaches it to you. The more you do this, the better you do this.

We will use an Open Source UML tool called ArgoUML. I am not going to talk about UML since I am not very experienced with it myself. In addition, my posts are already 3x bigger than I wish they were (megamoths!). Still, there are plenty of resources on UML over the web, feel free to look it up!

Media Manager and the Output block

Based on this initial overlook, these are the classes we are going to need for the Output block:
  • mediaManager - the manager itself;
  • sprite - represents a simple animated 2D sprite;
  • userInterface - a class to construct our user interface in order to render it;
  • text - a class to draw texts and manage fonts;
  • drawable - represents anything drawable;
  • entity - a base class for every entity in our game (player, comets, stones, triggers, anything);
  • drawableEntity - a class that derives from both, entity and drawable;
  • playable - a class that represents any sounds;
  • playableMusic - an specialized playable that represents background music, allowing for different volume and other special features.
These are (for now) the classes I'll use for the Output block of our first project. This System-Output-Logic architecture is really good for small projects like this one, but not ideal for medium or big ones. When we finish this, we can experiment with another architecture.

In order for these to work, we'll need the system block to actually do everything they need it to, like allocating memory, loading sound/image files, render stuff. The Logic block will actually use these classes to output to the player the current game state. I may need to change, add or remove one or two, as I model the whole game and any problems along the way.

The programming necessary to all these classes alone can be quite big. For this reason, I won't be able to go over every line of the code or function explaining it. Still, I'll try to keep all the code decently commented and formatted, while explaining the functions and classes; it should be enough. The point of this guide is not for you to read and compile the result project on your machine; it is for you to create a project with the same (or higher) complexity and write it yourself! If you want to use the same architecture we are using here, go ahead, but I would recommend you to try and create one for your project or, at least, make sure you understand why we need the classes we are using.

System block, the base for all our media

There's no way to program anything 100% decoupled from the operational system we are working. Even with java and other interpreted technologies we will face some differences between platforms; C++ is no different. Even though the language itself is cross-platform, the environment isn't. As cross-compiling is something I, personally, find hard to use and sometimes frustrating, I simply set up my environment for all the necessary platforms.

"Why are you blabbing about that?", you ask me; well, we are about to enter the part where it gets harder to keep the code 100% cross-platform. For this project, I aim to make a game that is completely platform independent at source level. Even though it may even end up cross-platform, this block will be highly tied to Allegro 5. If we ever need to port this for, say, SDL, we'd need to rewrite a lot of code in here.

All classes of the system block that messes up with media will include some allegro headers. The classes here will be significantly more complex than the ones up there in question of number of lines, complexity and burnt neurons. It was expected, since the sprites will actually be rendered in here, as well as loaded, deleted, [...], you got it. The same with the music, sound effects, UI...

In short, for now, we'll need one system level class for every high level output class that involves media, here's a list for the media related system classes:

  • sysSprite - Renders the sprites, animates it, loads from disk, deletes it, does everything sprite-related. Maybe we can even use it to draw our UI;
  • sysText - manage text, but at the system level, loading, drawing to an offset...;
  • sysPlayable - our system level sounds.

These will be significantly harder to code than the ones up there. The classes here are more complex due to the fact that they actually do the work. The ones up there are mere interfaces for our game, through which it tells the platform what, where and how to render a sprite or what sound and how to play it.

The first classes we will build will be the sprite and sysSprite, but how?

Class Attributes, what goes where?

I assume all of you have made a simple "animated sprite" prototype where you can draw a cute animated sprite somehow; maybe even translated horizontally, speed it up or down, this kind of stuff. So I ask, what attributes does a sprite needs? To start off with the right foot, I'll list the ones I'll be using.

High Level class:
  • std::string anim_current; - the animation being drawn for the sprite; (IDLE, FLYING, [...])
  • sysSprite* renderer; - See Below;
  • int frame_current; - Stores what is the current frame;
  • int frame_delay; - Stores the time since the last frame started, so we know when to swap to the next frame;
  • float scale; - Stores the scale factor for rendering; (0.1x, 1x, 10x ...)
  • int dir; - Defines the direction of the animation; (want an asteroid rotating on ccw? no problem.)
  • int rotation; - Stores the actual rotation of the sprite, so we can draw rotated sprites with ease;
  • bool translate_horizontally; - Rotates the sprite horizontally if true, not really useful for our game.
 System Level class:
  • std::multimap<std::string, std::pair<int, ALLEGRO_BITMAP*> > anim_list;
Wait, what?, I'll explain.

The high level sprite class is supposed to be created 1-1 for every entity using them. For an example every asteroid on our little game will have its own instance of the sprite class, with its own "current frame", its own rotation, et cetera. This way, we avoid the problem where every asteroid would be moving in a synchronous manner with every other one like a lame choreography. This is why we need all of them to have its own state.

Scaled, Rotated, doesn't matter, similar sprite objects share only one sysSprite instance.

The system level sysSprite class is supposed to have only one instance for every different sprite. Every similar sprite would need an instance of a sprite class object but all of these sprite objects would be linked to a single sysSprite object. This saves us from wasting memory and cpu by loading the same sprite image several times.

We should use a similar approach to the sound system.

Now that you (hopefully) understood the relation between the sysSprite and sprite classes, it gets easier to understand that sysSprite std::multimap. It is nothing more than a matrix, a matrix that stores a string on the first column (animation names like IDLE, FLYING, [...]) a number on the second (the duration of a given frame) and an allegro5 bitmap (the image itself) on the third.

This way, whenever we want to play the idle animation for our spaceship, we'll be able to simply go through the frames of the spaceship's sprite where the animation is called IDLE. Of course, string isn't necessarily our best approach, but I opted for it over simple numbers so they get a little clearer for us to understand.

But still, do you see the problem arising here? We'll need to have a structured way to store animated sprites; we'll probably need a similar solution for the sounds in the game. I don't know about you, but I smell XML.

Next step: create the sprite and sysSprite classes and test them. What'll we need? Aside from a lot of patience, we'll need an Allegro 5 project properly linked and tinyxml. If you don't have tinyxml, no problem, get it here. A little playing around tinyxml would do good for us as I don't plan to spend too much time on it, explaining it and how to use; but, if you prefer, you can ignore it and program a custom file parser using fopen: your call. I recommend tiny-xml.

I hope to finish the sprite class on our next entry,
Over and Out.

Thursday, September 26, 2013

Creating the Code::Blocks Project and Linking Allegro 5 (MinGW)

 Hello again,

This is the first post where we'll talk about a real IDE project, adding a library and linking it. Following, we'll write a code snippet to try and compile the project and see if it compiles well (0 warnings) and works as intended.

From this point, I'm assuming you've properly installed Code::Blocks and MinGW (with MSYS)  as well as downloaded the Allegro 5.0.10 binaries for our MinGW.

If you want to make sure your installation is as expected, take a look at this other post about it.

Creating the Workspace

Before everything, we should create our workspace. It is up to you how you handle your directories, but a good directory configuration can save you time.
I've been using this configuration for quite some time now and I feel really comfortable with it. I have no problems when formatting my machine or synching it with my second one. It has some more directories than those I'll be listing here, but they'd be useless for us, so I'll simply omit them for now, for simplicity's sake.

  • C:
    • GameDev
      • Projects
        • Game1
        • Game2
      • Libraries
      • Resources
Note that no folder should have spaces or special characters, since this leads to problems over the entire process of developing the software. One other point is that the folder GameDev can be copied and pasted on any machine and the relative paths of our project files will still be intact. If you wish, you can add sub-folders inside Libraries to hold different platform builds (Win32, Linux, OUYA [...]). The Resources folder is where I put everything related to documentation: game design documents, technical design documents, libraries manuals [...].

Code::Blocks will save everything a project needs inside its own folder. It may not always be the best solution, but it works; Microsoft VS does it and no one complains, so I guess we'll be fine.

Creating the Project

Now open up Code::Blocks click create a new project on the welcome page. You'll see a list of project templates, some functional, some not; since we are using Allegro (and there's no template) go for an Empty Project. I'll be calling our prototype Spacerock Miners, as a reference to asteroid mining. Since we should not have spaces on our project path, let's call the project SpacerockMiners without the space.

When you're finished with the wizard (nothing really complex about it) you'll be left with a blank project without any files. Go to New -> File... -> C/C++ Source and create a main.cpp for us to test our compiler.

Add a hello world code to test the IDE, the project and the compiler.

Build and Run it. You'll see that Code::Blocks opens the console and prompts the message. If your build did not work, you'll probably have to troubleshoot your compiler/IDE interaction.

Linking Allegro

Now that our project is up and the compiler is tested and working we will test our library. To do so, we need to link it to the project, include its headers and run a simple test code to see whether is working or not.

If you are following this guide, you should decompress allegro 5 in our Libraries folder. This means that the Libraries should have a folder called allegro-5.0.10-mingw-4.7.0 (or simply allegro5 if you want to rename it) with a bin, a lib and an include folder in it.

Note - MinGW installation under Windows.
It is possible to install Allegro on your MinGW if you build it yourself. It does take longer than downloading the binaries, but saves time when creating projects and build configurations. You would not need to add any .a files under linker options, for example. After you successfully configure your Allegro build with CMake, run mingw32-make to see that allegro is built. Right after your make command finishes, issue a mingw32-make install command, and it will install Allegro making our linking easier. Still, this guide will assume you downloaded the binaries.

You can however install the library manually, by copying your .a files to your MinGW folder.

Let's go back to our main.cpp and include an Allegro header, as well as some test code. As of here, I must warn you guys that we may need some .dll files. If you are on an Ubuntu computer, you'll probably have no problems linking, compiling nor running; If on a Mac, I have no idea whatsoever (sorry). Moving on, we have to add our Allegro files to our project linker options.

For this guide, we'll use something called Static Linking for Allegro. This will save us from having to copy the dlls to every project folder we create (release and debug) or to our main system dll folder. More information on this here: Allegro - Static and Dynamic link.

One annoying thing about complex libraries is that the order with which you add the files matters. Also important is that we'll use the -static-mt-debug.a files, they are the ones that carries both Allegro and standard C statically, so we clean all needs for dll files; needless to say they are for the debug build, if we ever need a release build we'll link it properly.

As the Allegro Library is modular, we don't need to always add all of these; linking acodec is only necessary if we are going to use sounds. The order of the files and the brief description are available here: Allegro manual. As we are making a simple Hello World program we'll only be adding two files: the core and the primitives library.


These are the only files we need to link now.

First things first, open C::B and open our Spacerock Miners project. On the top menu, click Project -> Build Options... You'll see that this window has six tabs, specially: Compiler Settings, Linker Settings and Search Directories. The other three are not important for us now.

Select the DEBUG build on the list on the left (should have only SpacerockMiners, Debug and Release).

On Compiler Settings,
Go to Other Options and add this:
`pkg-config --cflags --libs allegro-5.0 allegro_primitives-5.0`
Go to #defines and write this on the text area:
Notice that, on the option `pkg-config, that's not an apostrophe, but a backtick; as in `, not '.

 On the Search directories,
  • Add Allegro's include folder under the compiler tab;
  • Add Allegro's lib folder under the linker tab.

On the Linker Settings,
Add the two allegro modules we need:

additionally, as we are going to generate a self-sufficient application, we'll need to add other .a files from MinGW directory. So click Add and go to your MinGW/lib folder (probably C:/MinGW/lib). Now copy and paste the white text below on the filename and hit ok.
libgdiplus.a; libuuid.a; libkernel32.a; libwinmm.a; libpsapi.a; libopengl32.a; libglu32.a; libuser32.a; libcomdlg32.a; libgdi32.a; libshell32.a; libole32.a; libadvapi32.a; libws2_32.a; libshlwapi.a
You can also add file by file. More information here.
Now we have configured our compiler and linker options, we should be able to compile Allegro5 code. I'll add a sample code here for you guys to test and get started.

This is a simple code that creates a window and draws an ugly red triangle. It closes 3 seconds after it opens.

If you can compile this, you've done it!

In case you encounter errors, try repeating the steps for a new project. You can find other guides on this on the allegro wiki, such as this one here. If you can't find the .a files, you have not built the library. In this case, download the binaries from and decompress them inside our Libraries folder.

That's all for today, I'll probably update this guide once or twice.
Over and Out.

Tuesday, September 24, 2013

What makes a game;

and the not-that-easy road to out first playable prototype.

Hello again!
Today we are going to talk about what makes a game and our next steps towards our first prototype. This is the first post of the real game making; that btw consists of planning and developing. First things first, we are going to start with the planning. I'll try to make a concise series of posts, try to go through it all while making the games and prototypes.

Guide Level: Intermediate,
For those who know a little C++ and knows a little Object Orientation or, at least, Data Structures.

A game is... well, everyone knows what a game is; hard to explain. Still, what are the components of an average computer or console game? Since this is a game programming blog, I'll talk about the way I see a game: as a software.

Any game, on high level, can be modeled as three integrated main blocks: System, Logic and Output.

Simplistic high-level model of a game.

In this model:
  • The System block is responsible for anything related to the OS and Hardware, where most platform-specific code comes in. Ideally, when porting your game to other platforms, this will be the only block that would change.
  • The Logic block is the game's logic itself, the inner workings, rules, simulation. It depends on the System block to handle tasks like creating timers and managing memory; and also depends on the Output block to gather input and update the game multimedia layer.
  • The Output block prepares the Interface and Sounds to be played by the System block, as well as gets input from the player.
As you can see, both the Logic and Output blocks depend on the System, but the system does not depend on them. In a sense, it can be said that both the Logic and Output blocks are part of the System block; but I like to separate things as much as possible.

To know which block will end up more complex is really game-specific, as simple tiled RPG's would require a good Logic block, but small System and Output blocks. A war FPS, on the other hand, would need tougher System and Output blocks, in order to give the game the realism and precision it requires, the Logic would basically respawn players, do physics simulation and ragdolls.

It is useful to model your game in order to create a good software architecture. A bad architecture would kill your development, requiring lots of time consuming fixes and changes, so in the end you can have an acceptable result. The model you'll choose, is entirely up to you, but try not to overcomplicate; specially when we just started, too much effort to do things the right way can halt our progress.

Let's Start!

We'll start by choosing a simple prototype project, one that can be done. "What's a prototype?", you ask me. Well, by prototype I mean a really basic game, that is far from complete, but illustrates its concept. Prototypes can have a single level and no sound, awful graphics and still be used as a concept showcase.

Our first prototype will be a space game inspired on the classic Asteroids. First thing we should do is actually design our prototype (duh). We'll not be creating a Game Design Document (GDD) or a Technical Design Document (TDG) or we would be killing flies with bazookas.
In our game, we will control a spaceship flying through multiple asteroids and try to destroy as many as possible. We can destroy them with our gun or, differing from the classic, colliding with them. That's the basic idea of the game.

  • WASD controllable, no more turning around and accelerating;
  • Pointer shooting, shooting with the mouse will be really easier;
  • Ranged and Collision focus bar, to add a minimum of customization;
  • Hull Integrity bar, no more instant deaths, but no respawns either;
  • Asteroid Integrity bar, asteroids will have different resistances.

Simple enough, this is our prototype. Let's now think on our model now, for a second.

This game has little need for user interface, it's just a ship, its projectiles, asteroids and a hull integrity bar. The input is 5-buttons, 4 directionals and shoot. Piece of cake here.

The game logic needs some basic physics simulation, respawning of asteroids is pretty easy tho. Still, if we add a focus bar, we'll need a better physics simulation.

Light weight rendering, timed sounds, some timers, nothing too hard.

Basic Architecture

As I said before, trying not to overcomplicate, let's define the following structure:
  • A Media Manager to manage the window, rendering, sounds, etc;
  • An Input Manager to detect the player's input;
  • A game world, with these two components:
    • A physics world, to keep all the positions of our entities;
    • A data world, to manage everything other than physics. 
  • A game manager, to wrap them all together and interface them to system specific code.
As you can see, it is not easy, but doable (I hope!).

So, as you probably realized by now, our System is our Game Manager, our Logic is our Game World and our Output is, both, the Media and the Input Managers.

Note: the media manager will be really dependent on the System block, so we'll need to create an interface class inside the System block to interface it with the OS and Hardware while keeping them decoupled.

What's coming next?

Since this is a programming guide, I simply jumped over all the design process. Still, I can't jump over the process of creating the project with Code::Blocks. Following, we should build and properly link our libraries and start the programming. Probably create the media manager and, following, the input manager. The game world comes next, I guess it'll be the hardest part of the guide. Lastly the game manager.
Once the game manager is up, the game prototype should be all up and ready.

What'll we need?

I will be using Allegro for this prototype, but it really saddens me that they still have a mandatory requirement of DirectX SDK. This SDK isn't installing properly on lots of machines since they try to rollback your runtime files, the system forbids it, halting the installation (S1023). It requires the complete removal of all Visual C++ runtimes, which we will need to reinstall right after. Tedious process. I recommend downloading the binaries if you do not want to go through all the trouble to install the DirectX SDK.
The binaries and source code are both available here:
We'll be using Allegro 5.0.10, If you'll be using the binaries, get the them for MinGW 4.7.0 .

I will rebuild Allegro here since I need to confirm it is as I remember.

Maybe, we can integrate Box2D to manage the game's physics. Still, given the simplicity of the game, it would be too much. Box2D would be used just as an initial tutorial.

Answering the question, we will need Code::Blocks and MinGW, along with the Allegro 5.0.10 binaries for our version of MinGW, 4.7, and maybe Box2D built and working, but this one is not certain yet.

Over and Out.

Monday, September 23, 2013

Box2D Build - MinGW for Code::Blocks (Windows, or not)

Our first step on to creating anything on game development is to make sure everything we need is ready for us to start mashing our keyboards. This means we need our IDEs and compilers working fine and our libraries are all just waiting for us to use them.

For this to happen, we need to:
  • Download the Source Code;
  • Get the binaries for our library; two ways:
    • Download Binaries for our compiler; or
    • Build it ourselves.
  • Include it on our project:
    • Set search directories and link it properly.
So, today, I'm going to give you a basic step-by-step guide on how to build Box2D, a C++ engine for simulating 2D rigid bodies physics.

"Why Box2D?",

you ask me.

Well, Box2D has been around for longer than I study game development (Sep, 07); it is stable, reliable, platform independent... I really see no reason to use any of the other engines in the market. Specially considering most of these engines were built over Erin Catto's algorithms. Some will even require you pay hundreds (even thousands) for a license, nonsense. Box2D is open source and released under the zlib license, that is a really permissive license allowing anyone to use, even for commercial projects, free of charge, with no additional requirements. More info on the license can be found here. As a note, Box2D does not require attribution (such on it MIT license!), so, if you actually do it, you're basically stating that you are awesome.

Examples of games built with Box2D are Crayon Physics Deluxe, Wold of Goo iirc; and Angry Birds (give it the credit already!).

On top of that, Box2D has the largest number of examples one can find. There use guides all over the internet, some are even in video (I don't really like video guides for programming). This way, even if you are one of the unfortunates following this blog ( Hi Bxn ^^, Hi Mom !! ) you'll not be stuck with my future horribly terrible guides on using it!

The problem with Box2D is that they, for some reason, do not consider MinGW and Code::Blocks professional enough. So, if you are not using the industry standard MS Visual Studio or XCode there'll be no IDE/Compiler project ready for you to use. That's why we need to do this the "hard" way; which is not that hard. There are some community created projects for it, but they are unofficial, not being included with the source nor kept up-to-date. Still, it is good for us beginners to really understand how compiling and linking works and how to build something outside of our lovely IDEs. This is just the perfect opportunity for an introductory challenge!

What Exactly are we doing?

First things first, let me just briefly (and probably wrongly) explain what we are doing here. Building a C++ library, such as Box2D, Allegro or any other, means we transforming the source code into a linkable file, that we can then use in our own projects, after we compile them. "Wait, What?"

Basically, we are compiling and linking the library, so it is ready to use. If we "copied and pasted" the library's functions to our project, made the necessary changes to the #includes and etc, we would be using it without previously building it. It would probably work, the library would compile along with your game after every "Clean" order. The problem with integrating the library with code editing is that it would be a tedious task that would take a really long time, and in the end deliver the same results; not worth it. We could also configure our projects to build our libraries along with our own code, but, given you are not modifying the library, it is just a waste of time, since it would need to be rebuilt with after every Clean order.

Building Box2D for MinGW and Code::Blocks

From this point forward, I am assuming you have already installed and configured MinGW and Code::Blocks properly, and does not have two MinGW conflicting folders. If you need, check this other post on how to install them.

As of today (Sep 2013) Box2D latest release is version 2.2.1, available at or google code.

Step 1 - Download the source code. or
Step 2 - Download and install CMake.
"Why use CMake if Box2D has prebuild4?", you're asking me. I don't know how to do it with prebuild4, simple as that. Tried it threee times, and hit threee different problems. So I just decided that there was no advantage over building with CMake, that I rarely hit any errors. If Box2D drop CMake support anytime soon (what I doubt, btw), I'll make a separate guide for premake; if I can figure it out.

To start the building process, it is wise to save your source code on a convenient place. Your directory structure doesn't have to be complex, but it should be convenient. In a following post, I'll talk a little about the directory structure for development. For now, I'll be using X:\GameDev\Libraries directory. Decompress Box2D there and you'll have the X:\GameDev\Libraries\Box2D_v2.2.1, and all of its subfolders.

Step 3 - Generate the MinGW Makefiles using CMake.
But how exactly?

  • Open CMake;
  • Define the folders;
  • Hit Configure;
    • The log should show "Configuring done" and Options in red;
    • Check the boxes that start with BOX2D;
  • Hit Configure (2nd time);
  • Hit Generate.

Go ahead and open CMake-gui. You'll see this window right here:

CMake Folders, Source and Build.

Note that I inserted two folders on the text boxes on the top of the window. The first box must be the base directory of Box2D and the second should be the Build folder.

Important Observation:
Inside of this folder X:\GameDev\Libraries\Box2D_v2.2.1 there must be a folder called Build. If you find another folder named Box2D_v2.2.1 instead, see if you can find the Build folder in it; if you do, choose this one for the first text area, and its Build folder for the second.
After setting up your source and build paths, hit Configure for the first time. If you haven't set your compiler, you'll see a dialog where you can select which one you wish to use (image); MinGW for this tutorial.

CMake Compiler Selection.

Choose your MinGW and press Finish. This is what you should see:

Configure should generate this output. The red stuff is not an error list, it's our build options.

Notice that CMake makes a test for a working compiler. If you fail this test, your compiler is not set up properly, check the bottom of the post.

Moving on, every one of these lines with a checkbox/text area is a build option. If yours are not red, but white, it just means that they have been loaded from a cached configuration, but it's fine; if that's case, it is a good idea to clear the cache, just click File -> Delete Cache on CMake; click Configure again.

I'm going to check all the boxes that starts with BOX2D and hit configure a second time.
Now hit Generate.

What we did was setting everything up for us to finish the building process with MinGW. In the end, your CMake should look just like this:

No error messages.

If you had any errors, try deleting the cache and repeating the process. Make sure the test CMake does with your compiler return a "-- works" result on both, gcc.exe and g++.exe.

Step 4 - Make.
Using the console.

Open your console and travel to the Box2D Build folder. In our example, the command would be:

C:\> X:
X:\> cd GameDev\Libraries\Box2D_v2.2.1\Build

If you don't know how to open the console, hit Super (aka Windows key) + R and type cmd, hit Enter.

On the console, once you found Box2D build folder, where we just set everything up using CMake, issue the following command:


If we did it all right, this is what you should see:

If it worked, under your Box2D_v2.2.1\Build\Box2D you'll find a file called libBox2D.a .
These .a files are exactly what we were trying to achieve!

Want to have some fun? Now that we did all of this, under Box2D_v2.2.1\Build\Testebed you'll find the Testbed.exe. Take a look on how Box2D is awesome!

This library is now ready to be used on Code::Blocks and MinGW. Actually, it is ready for use with any IDE that uses your installed MinGW, not necessarily C::B.

Downloading libBox2D.a and other .a files

For all of you who can't build it or are just too lazy to do it, I'll upload the .a files. But just try to build them yourselves, Ok? Knowing how to build libraries is really a necessary step on Game Development with C++.

I do not recommend this download to anyone, under any situation.

And that's it for today; over and out.

Troubleshooting CMake compiler test

May be this message exactly or something similar.

If this happens, you can try these steps:
  1. Add an environment variable called MINGWDIR with value C:/MinGW
  2. Add the cmake install folder to the windows Path environment variable.
There are lot's of guides on how to do this, but the basic procedure is
  • right clicking  on My Computer (or equivalent)
  • click Properties
  • Advanced Tab -> Environment Variables
There are going to be two lists, you should add the MINGWDIR on the bottom list. Edit the Path also on the bottom list. Restart your machine and try again.

Always remember to click Delete Cache under the File menu between tests.

If all of this does not work, try reinstalling MinGW and CMake and restarting the machine. If you still have any problems to make this work, I advise you to search possible solutions on the web and post on dev forums.

Friday, September 20, 2013

Code::Blocks - Install IDE, a C++ compiler and set it all up.

Aaaand it starts!
The first guide will be on Code::Blocks, a fantastic IDE that takes a lot of work off our shoulders, like any other IDEs do, but this one is free, open source and was designed for C++.

To start up, let's go check their download page:

You'll notice they have an installer for several OSs. If your OS counts with a repository, like Ubuntu does, all you need to do is install C::B through the software centre; and it will be piece of cake configuring the installation (it'll be automatic).

For you guys that use windows for your programming needs, you can go ahead to the C::B download page and get an installer file. There'll be two options, one with MinGW in the end of the file name and another without it. The difference is that one comes with the MinGW bundled in C::B while the other does not.

Step 1 - Download the latest binary release installer for C::B without MinGW on it's file name.
As of now, the file you are supposed to download is called codeblocks-12.11-setup.exe
Not codeblocks-12.11mingw-setup.exe

So, you got the file without MinGW. "Why download the one without the compiler if there's a bundled installer?" You'd be amazed on how many times I stumbled on this bundled compiler along my little journey. The best thing I done was starting to download MinGW separately, easier to update, maintain... This is specially true if you have any other IDEs that use MinGW.

This takes us to our next step.

Step 2 - Download the latest MinGW release installer from their own website.
From here:
The file at the time of this writing is called mingw-get-setup.exe

This installer is only around 84kb sized but don't be fooled. It is a web installer. It'll download everything necessary later. Later? Actually, if you are following the guide, it'll do it now.

Step 3 - Install MinGW.
The installer will look just like this:

Notice that I removed the shortcuts. Well, I see no use for them.
When you click continue MinGW will download itself and automatically install its base, the C++ compiler g++ and the Objective-C compiler.

After the download completes, it'll open up a window where you can tell it to install any additional packages you may need; I like to install the g++ documentation, just in case.

Here's a list of extra packages you should install:
  • msys-base
  • most up-to-date autoconf, automake and autogen bin packages (mingw32 and msys)
  • (optional) zlib, lua and other libraries
Specially msys-base, without it you'll have a hard time with some libraries. Installing libraries through here makes our lives easier, since they wont require linking nor building.

Sorry for the big images, but the reduced ones won't cut it.

If you don't need any extras or have already installed them, just close out of this window and MinGW is installed and working.

Now, it is wise to add MinGW to window's system variables, if it was not added automatically.
To do so, press "Super" (aka Windows Logo) + Pause Break and go through Advanced system settings -> Environment Variables... and then check if you have a MinGW entry there (image below).

If there is no variable called MINGDIR on your list, press New... and add it manually. Notice that c:/mingw is my install folder, if you installed it somewhere else, adjust it.

Now we have everything we need to compile g++ code. The hardest part is over.

Let's go ahead and set up our Environment, our IDE, Code::Blocks.

 Step 4 - Install Code::Blocks.

The installer will look like this:

As you can see, I removed the Shortcuts. I hate shortcuts.
The installation is pretty straight forward, there's no bloatware, not toolbar or McAfee uselesscan tool (Yeah Adobe, Oracle, Code::Blocks is way above you!).
Just hit next 'til success!

Once installed, run the IDE and it'll prompt you for a compiler. As we are using MinGW, you should choose GNU GCC Compiler. If it simply did not prompt you, go to Settings -> Compiler...

Verify that the compiler has probably been automatically selected. If it was not, select it manually.

And that's it for our installation!

You can try and compile a small Hello, World! program.

 #include <iostream>  
 int main () {  
   std::cout << "Hello world!" << std::endl;  
   return 0;  

Create a Console Application project, hit Build and Run and this is what you should have:

Until the next post!
Over and Out.

Thursday, September 19, 2013

About the blog


This blog was created by Dejaime Neto, to teach the very basics on game development to anyone who wants to learn.

If you are wondering what the name of the blog means, it's just as stupid as you thought.
Build and Run (aka F9) + Run and Gun = Build and Gun.
Gimme a break willya? I'm a programmer, not a marketeer!

The Blog

I am one of those crazy dudes that believes it is not worth paying for something that is just slightly better than an Open-Source or Freeware alternative, if better. That said, I will always use free resources, IDEs, libraries, tools. This is specially good for beginners and hobbyist, since, as me, they probably won't want to spend USD$ 500 microsoft asks for visual studio, to name one. On top of that, I see no point on teaching game development using a demo version of such, as many many books and online resources do, since if you ever get to something you think is releasable you'll have to pay for the license in the end.

As this is a personal blog, a personal project and thus written by a single person, try not to believe everything in here. Programmers, including me, always tend to be absolutely impartial when evaluating tools and languages. That said, I'll talk a little about myself :
I am a mechatronic engineering student and hobbyist game developer. My engineering background allowed me to learn C, C++ and very little Assembly. Picked up a bit of Java along the way, but didn't like the trade-offs; maybe I'm a control freak or smth. As of scripting languages, my favorites are Ruby and, specially for games, Lua, Brazilian like me. My favorite game development books are Game Coding Complete 4thEd by McShaffry and Graham and Programming Game AI by Example by Mat Buckland, both beginner books, if you have already been introduced to C++.


Why bother building up a web blog if you won't be adding any monetizing like ads, referral links [...] ?
It's simple, actually.
I believe that one doesn't know something until they are able to explain it. That's what I'm doing here. I'm putting my own knowledge to test, trying to bring up articles, tutorials and posts on the subject of game development, allowing me to diagnose my own strengths and weaknesses. In the future, I want to build sample open-source games and prototypes, really simple ones, since I learn a lot by sample code; specially complete and finished games and prototypes code. This would put my own skills to check once again, see if I can actually praxis what I know.

You don't know if you can do something until you try. I'm trying, at the risk of worldwide embarrassment. And I hope you'll do the same.

I can also train my english at the same time! win-win-win-win situation!

Blog Content

So you ask me: "what does one find here?"; that's and easy to answer question! (easier said than done)

Used IDEs:
Primarily Code::Blocks, for C++ programming.
 Used Libraries and Engines:
Box2D, for C++. The best 2D Physics library out there;
Allegro, SFML and SDL, my favourite game development libraries;
Boost library, to do all the heavy lifting for us not-so-experienced programmers; and
Maybe in the future:
Torque2D, a complete game engine, now open-source;
Haxe, the most cross-platform engine I've found.
Used Languages:
C++, for everything, since it is cross-platform and the most powerful language I've used. I'll be using some C++11 features, so remember to set the -c++11 compiler flag.
Lua, if we ever get to a point where we can use script on a game prototype.

Ok. Now you know what I'll use. All that's left is to know how I'll use all of this stuff.
My initial idea is to accomplish 3 main goals over the next years:
  1. Teaching Content: Enough for a reader to come in here and learn all he needs to know to build a simple game, from ground up to releasable state;
  2. Games or Prototypes: Actual games or prototypes, even if really simple, that you can play, understand, and read its source code. It would be a great way to learn things like setting up IDEs, configuring them, Linking libraries, etc;
  3. Higher Level Game Engine (HLGE): This would be the blog's child, that'd mean the blog had actually paid off and all our hard work was not for nothing! The HLGE would be a higher level engine that incorporated Box2D physics, rendering (probably with one of the 3 libraries listed above or maybe OpenGL directly), that maybe I make a post in the future explaining it further.
 As you can see, I am setting my expectations really, really, high. So, please, If I fail to accomplish any or all of these, please don't throw stones at me, throw burgers! At least that would make me less sad over my own failure.

If, after reading this, you feel all motivated and stuff (what I doubt, btw), and you want to help me accomplish this dream by making it part of your own dreams too, contact me. I must warn you that I am, as of now, a terrible programmer, and this will certainly slow me, us, down.

You can reach me at dejaime <at> .

Thank  you for your interest!
Dejaime, over and out. 

This blog is proudly hosted by Blogger, Google, free of charge.