I hope your tool chain is all setup right. In that case we move along and actually write some code. We will use the same code from the earlier chapter and add more things to it as we go along. The code does very little as yet, but our short piece of code (first.py) has some important and core concepts that are central to most games. More complex games are built around these basic core concepts.

#!/usr/bin/python

from PySFML import sf

# Initialize the game components.
window = sf.RenderWindow(sf.VideoMode(800, 600), "Test Application")
text = sf.String("Hello Game Development")
running = True

# Start our Game Loop
while running:

    # Get the input from the player as an event.
    event = sf.Event()
    while window.GetEvent(event):
        if event.Type == sf.Event.Closed:
            # The player wants to quit the game.
            running = False

    window.Clear()
    window.Draw(text)
    window.Display()
window.Close()

Game Loop:

The first and foremost term to introduce is the game loop. A game loop is just a fancy name given to a looping control flow statement which runs continuously until a boolean condition remains True. In our case the game loop is a while loop and the boolean condition is simply the variable ‘running’. The loop runs as long as running remains True. When running is set to False, the loop exits, effectively ending the game.  As you must has guessed the game loop is where the game action actually takes place. It’s where the shots are fired, enemies are killed swords are slashed and magic is unleashed!

Input:

An Input typically occurs when the player/s wants to interact with the game and do so via a input device. An example of an input-device is a keyboard but there are other fancier input devices like Joysticks, Keypads and many more.

Event:

Events are what makes a game interactive. An event is not to be confused with input. An input can cause an event, however events are not limited to input alone. There are other instances which can generate events. For instance, in-game interactions between game elements can also generate events. An event can be external or internal is origin. A player pressing a key on a keyboard is an example of an externally generated event. A mine going off because an NPC tripped it’s fuse wire is an internally generated event.

Action:

Actions can occur in response to events. For example — If the player pushes the arrow key (event), the in-game player character moves forward (action). Here the player pressing the arrow key generates an event, which executes the move forward action. It is not necessary though that every event generate an action. Sometimes events may generate no action at all and are completely ignored. For instance, a player pressing a key that is not mapped to any action will discard that event and simply not create any action.

Resource:

Any data or file required by the game to run and simulate the game is generally called a resource. Images, sound files, data files are all examples of resources. A resource is usually not a piece of code, though it’s not a hard and fast rule. Many games use scripts which may also be considered as a resource. A game can have a large number of resources. A large game can have resources that are several Gigabytes and that number increases with every generation.

Before we proceed further, lets look at our code (first.py) and see where all these new terms fit in. The program begins with the creation of a window. This is where the game contents will be drawn. PySFML takes care of the nitty-grittys of creating the window and isolates us from unnecessary platform specific issues. After that the ‘text’ and ‘running’ are created and initialized. The point to note here is, line numbers 6-8 in the code serve as an initiation routine for our game. Most games have, and sometimes can have a lengthy initiation process. The initiation process of the game is also the place where the resources of a game that are on the disk get loaded. Reading from the disk or any storage medium is always a slow process and it’s because of this, games usually initialize and load resources before the game loop starts. The ‘Loading…’ screen seen just before the start of a game is where the initiation and loading of resources take place. For very big games where the data per level is in several Megabytes, resource loading can take place on a per level basis.

Coming back to our code — The Game Loop begins on line 11 and the very first thing we do is check for user input. Again, PySFML abstracts away the input checking code internally and goes a step further by directly building an event queue. All we have to do is check if an event that we are interested in, is in the queue. That is exactly what we do on line 16. We check if the player tried to exit the game by closing the window. If he did, we set running to False. That’s our action in response to an event. The next few lines of code draw the text on the screen, and we will come to drawing and what those 3 statements do in later chapters. For now take my word for it. Also, remember the game loop runs continuously till the player decides to quit, so the things explained in this paragraph happen repeatedly while the loops runs.

The code in first.py displays a text, but that isn’t what a game is about. A game is usually about moving things, smashing, shooting, colliding. Our current code is no fun! So lets move on then! Yes, we will get to shooting, colliding, smashing later on, but for now lets keep things a bit more simple (for the sake of learning). Lets make the text move, or should I say scroll. Look at the code below. Lets call it (anim.py)

#!/usr/bin/python

from PySFML import sf

# Initialize the game components.
window = sf.RenderWindow(sf.VideoMode(800, 600), "Our First Animation")
text = sf.String("I am a priece of Scrolling Text")
x = 0.0
y = 30.0
running = True

# Start our Game Loop
while running:

    # Get the input from the player as an event
    event = sf.Event()
    while window.GetEvent(event):
        if event.Type == sf.Event.Closed:
            running = False

    # Update the position of our text.
    x = x + 0.3
    if x > 800.0 :
        x = -400.0
    text.SetPosition(x,y)

    # Draw the text.
    window.Clear()
    window.Draw(text)
    window.Display()

# Close the window and end the application.
window.Close()

If you run the code above, you will see a scrolling piece of text instead of a static one, and that brings us to the last thing that we introduce in this chapter. The update routine. The update routine updates the game elements. In our case it updates the position of the text, but update is not specific to entity or element position. Our small little update routine starts at line 22 and does nothing but change the position of the text on the screen. However, an entity or an element within a game can update a lot of things including it’s position, state, behavior in an update (as we will see in later chapters).

Well there you have it! Our small little animation! Now, lets go over the things we have understood from our small animation and build an outline of our game — We start off with Initiation, then we move on and begin our Game Loop. In the loop the first thing we do is check for User Input. PySFML saves us the trouble and gives us Events directly. If there is a quit event, we take the appropriate Action and set our loop state to quit. If not, we Update the position of our text, Draw the text and loop back again to test for user input.

So our outline will be something like this:

InitializeGame

while Running :
        CheckForUserInput
        BuildEventQueue
        if Required.Event in EventQueue :
               TakeAction

        UpdateGameEntities
        DrawEntities
CleanupAndClose

There you go. You have now understood the basic layout of a computer game. Yes, most games even the AAA ones follow this simple outline.

In the following chapters we will start diving into more complex programming constructs like OOP. We will take this simple framework and make it an Object Oriented one. It will eventually allow us to add more complexity, richer interactivity, more game elements and far more than just one line of scrolling text.

Note: Games needn’t be modeled using events and actions, but it is often easier and more intuitive to do so. Some games use polling instead of events. Polling is where the game-engine polls inputs instead of receiving events from them. While this works with input, in-game interactions are often cumbersome to design using polling. Whichever way you look at it, (polling or events) it’s still pretty much the same thing.

Downloads

1. anim.py