Make Games: An introduction to Game Development

Hi Folks,

today I'm back with a new topic from my main hobby right now: developing computer games. Ever since I was a young boy, playing his first games on PC, I ever wondered how these cool games I enjoy playing are made. It took me nearly 15 years to come to the point that I actually know most of it in theory, and some ( better call it basic ) aspects of game development in practice right now. I will cover these basic topics in a series of articles here in this blog over the coming months. This will be the first and most theoratically article about it, but it's one of the most important articles, trust me ;-)

In the beginning you have the wish to make computer games, and you already have a good idea for a cool video game, but you have no clue how to start it, right? So was I. But the internet has the solution ;-) I found a very good article over at www.gamefromscratch.com which covers these very first step, which I call: "Get your tools". Look up the article I want to be a game developer for this step and come back here later, to use your tools.

"Hey Serious IT Guy, which language/engine/library did you choose?"

Short answer: C++ with SFML (and SDL).

Long answer: I first evaluated all languages I'm already familiar with and are cappable of creating games. These are C/C++, Java and C#.NET. Then I thought about my goals, and one goal is platform independence. I'm a big Windows AND Linux fan, so I want to make games for both platforms. This reduces the available languages to C/C++ and Java. ( I know C#.NET can be used under Linux, but it's not that good and no standard btw. ) I know Java really good, and it is actually not that bad as everyone states, but security issues arise very often with the Java Runtime Libraries. That left C/C++ alone, and the guy over at gamefromscratch.com clearly says NOT to start with C++. I've worked with C/C++ since university for over ten years now, and I know that C isn't that bad either, but it's a trip back to the stoneage, so I choose C++ (and didn't regret it btw. ;-) )

So, the language question is answered, that leaves the graphics library. I  couldn't really choose between SDL 2 and SFML 2.1 without having a closer look on both. Nothing gets you closer to a library than actually working with it, right? SDL 2 is maintained by a Valve Software employee Sam Lantinga, and incorporated in famous titles like Team Fortress 2, Left for Dead 2, DOTA 2, and many many other indie titles on Steam or Humblebundle. SDL 2 is written in ANSI-C and can be used natively in C++.

SFML 2.1 is maintained by Laurent Gomilla and isn't used in a project of wider scale, the homepage doesn't mention a reference to a publicly available title using SFML. It is written completely in C++, and makes heavy use of objects and static member functions, which makes it easier to use.

After reading about both libraries, SDL seems to have more functionality, but SFML seems to be more easy to use. So C++ and SDL is used by Valve, and what the pros use must be good, right? No it is not right, it is better to start easy, and learn the principles of game development without the hassle of a complex engine/library, and then advance from there and learn a "better" engine/library. So I started with C++ and SFML 2.1.

The last part in our tool chain which is missing, is very obviously a compiler ( and/or an IDE ) to get our code up and running. Here we have even more options than in the language question, but if broken down, it all comes to personal taste. From my standpoint there was only one real deal: C++11 compatibility. On Windows there are two serious alternatives here: Visual Studio 2013 and MinGW. Use what ever you like more, I use Visual Studio 2013 Express, because I know Visual Studio since Version 2003 now. Since Version 2013 C++11 is ( nearly ) fully implemented, so that's the way to go for me.

On the Linux side, there was only one real choice for me: GCC with Code::Blocks IDE. Since IBM left Eclipse development, Eclipse IDE becomes worse and worse with every release, and Code::Blocks offers a SFML and SDL project template out of the box. GCC is the defacto-standard for Linux compilers, you can't do anything wrong going this way. On Ubuntu ( I use 13.10 atm ) you can't install the SFML Packages via apt-get, because you end up with version 1.6 libraries if you do so, and we need version 2.1 of the library. So you have to install the 2.1 files manually. ( I will cover this in a seperate blog post about starting development on Linux )

Although supported by SFML, I will not cover Mac OS, because I don't own a Mac, and I don't like Apple products. If you want to know about this, ask Google ;-)

So finally here we are with our tool chain:

Windows:

- Visual Studio 2012 Express

- SFML 2.1 / SDL 2

Linux:

- Code::Blocks IDE

- GCC

- SFML 2.1 / SDL 2

So after the 10 ton mammoth has been cleared out of the way, we can finally start developing games, yeah! I will not cover how to setup SFML on Windows in Visual Studio, as there is a very good guide already existing. Please check it out here.

I have created a simple demo application for you, which shows you two basic concepts of games: the main loop and event handling. Check it out:

#pragma once
#include "SFML/System.hpp"
#include "SFML/Window.hpp"
#include "SFML/Graphics.hpp"


int main( ) {
 sf::RenderWindow window( sf::VideoMode(800, 600, 32), "Simple graphics with SFML" );

 sf::RectangleShape rectangle;
 rectangle.setPosition( 400.0f, 300.0f );
 rectangle.setSize( sf::Vector2f( 50.0f, 30.0f ) );
 rectangle.setFillColor( sf::Color::Yellow );
 rectangle.setOutlineColor( sf::Color::Red );
 rectangle.setOutlineThickness( 3.0f );
 rectangle.setOrigin( rectangle.getSize().x / 2, rectangle.getSize().y / 2 );

 
 while( window.isOpen() ) {
  sf::Event currentEvent;
  while( window.pollEvent( currentEvent ) ) {
   if( currentEvent.type == sf::Event::Closed ) {
    window.close();
   } else if( currentEvent.type == sf::Event::KeyPressed ) {
    switch ( currentEvent.key.code ) {
     case sf::Keyboard::Up: {
      rectangle.move( 0, -5.0f );
      break;
     }
     case sf::Keyboard::Down: {
      rectangle.move( 0, 5.0f );
      break;
     }
     case sf::Keyboard::Left: {
      rectangle.move( -5.0f, 0 );
      break;
     }
     case sf::Keyboard::Right: {
      rectangle.move( 5.0f, 0 );
      break;
     }
      case sf::Keyboard::Escape: {
      window.close();
      break;
     }
     default:
      break;
    }
   }
  }

  window.clear( sf::Color::White );
  window.draw( rectangle );
  window.display();
 }
}

So what we do here? First we create a simple graphics window with a resolution of 800x600 pixels. After that we create a simple rectangle and set some of its properties. Then we run a while-loop with the condition "as long as our window is open". This is our very first game loop. That's it, a while-loop that runs as long as the application isn't terminated by the user. Within the game-loop is a second while-loop, the event loop. It polls the windows event queue for any new events, and if they're any, it looks up the type and acts accordingly. If the user clicks the close window button, the application will close the render window which then terminates our game-loop ( while( window.isOpen() ) ) and then exits our application. If the user hits Escape the same thing happens.

If the user uses the arrow keys he can move our yellow rectangle around the screen. With every keypress the rectangle is moved by 5 pixels in the corresponding direction. Note that the move()-Method uses coordinates relative to the current origin of the entity, while setPosition() uses global coordinates. I use a switch statement to poll which key was pressed.

If there are no more pending events in the queue, the event-loop terminates and our game loop continues operation. We clear the window, thus eliminating all pixels from the previous frame and setting them to white. If you use clear() without a parameter, the window is set to black.
After the window is cleared we can then draw new content to it. We draw our rectangle and then finally call the display()-method which puts all contents on the screen.
The result looks like this:



Not very spectacular, right? ;-) I know, but it will get more exciting in the next chapters. Note that you can move the rectangle out of view, because we have no collision detection nor a moving camera view. These things will be covered later.

Puh, this was a rather long one, but if you made it until the end, you are now ready to use your tool chain to develop games with SFML. Play around a bit with our demo application to get familiar with the SFML namespace members, e.g. try to draw a second entity ( a green cirle maybe ) to the screen and move this one with W-S-A-D. Until next time.

return EXIT_SUCCESS;