This post is a portion of Part 3 in my on going series about 2D Game Development using the Allegro 5 library. These posts are in course order. You can see all of the posts in this course by clicking the “2D Game Development” button at the top of this site.

• Part 3.0: Player Input and Events
• Part 3.1: Keyboard Input Part 1
• Part 3.2: Keyboard Input Part 2
• Part 3.3: Mouse Inputs in Allegro 5

In this section we will be looking at interaction between the software and the player. These events and inputs form an important portion (half, actually) of the User Interface. It can even be argued that a game without user inputs is just a movie. Thus, when developing a game, there is a scarcity of topics more important than this. Before we dive straight into the code, however, it is important to understand where game development and user inputs have come from.

The Procedural Approach

In days of yore, game loops were much simpler. The basic procedures of check-for-input, update, render were repeated over and over and a constant rate (or in some poorer games, a non-constant rate). This is the approach I like to call the “procedural approach”. The premise was that the loop would be cycling so fast (the game standard is 60 cycles per second, or 60 fps) that controls would feel responsive. In actuality, the loop would be constantly chugging along, and the player hoped that it just so happened to be checking for inputs while a button was being pressed. Otherwise, the command may be missed and the controls would feel unresponsive as a result. Even harder was testing for situations where the player would press, release, and press a key again very quickly. Without clever programming, some of the more precise inputs may have been missed. In all honesty, if handled well this approach can be completely adequate and feel very responsive to the player. If absolute precision is your goal though, there is a better way.

The Event Driven Approach

Many modern game libraries (and software libraries for that matter) allow for event driven programming. Allegro 5 is no different. Let’s say that receiving a piece of mail is an input (an event), then going to go check the mailbox is a “procedural” way of checking for said input (event). You could check the mailbox a hundred times a day for an input that will only happen once. Instead, what if you could have the mailman tell you when he drops the mail off. That way, you don’t have to check the mailbox and you will know the second your mail arrives (no more mail sitting there waiting to be stolen, Dave I know it was you). The latter way of dealing with the mail is what I like to call an “event driven” approach. In event driven programming, we don’t check for user input. Instead we just let the computer tell our software when the user has done something. We save ourselves from having to check and we know just as the user presses a key. Better yet, since we are monitoring events, we are able to see when keys are pressed and with keys are released for better, more accurate inputs.

More About Events

Events themselves are not restricted completely to user inputs. As a matter of fact, there are many types of events that can be fired by many different objects. For instance, clicking the red ‘X’ on a window is an event fired by the display, a timing event can be setup to fire off ever fraction of a second, and internal diagnostics can push information to the user via events. All of these things are what make the event system so robust. With events, it is possible to make functioning software that just “waits” to handle incoming data.

Getting in Line

Much of event driven programming is waiting around. Unlike the procedural counterpart which is just chugging away, and event driven system rests until there is something needing done. Much like the teller at a bank is waiting for a customer to get in line, so too is the software waiting for an event to get in line. In this case, that line is called an event queue. Event queues work on a “first come first serve” basis. Events are read from the queue and handled as they arrive. As a result, the beginning of an event driven game loop usually involves the checking of the queue, and if nothing is there, the waiting for the queue to fill.

In future videos, we are going to look at using the keyboard and mouse in conjunction with the event system built into Allegro 5 to make capturing user inputs a snap.