Table of Contents Source Code Article Two
Every program that has ever been created can be reduced to three key phases: input, processing and output. Sometimes, it seems so obvious that we miss it.
Input comes from humans in some form or another. It may be mouse-clicks, key presses or data like numbers, names, etc. Without humans, there is no need for a computer, much less a computer program.
Processing takes that human input and cooks it in some, pre-determined way.
Output is the result of processing and it is usually presented in some fashion.
Let’s take, for instance, the following program:
#include "iostream.h"
int main( void )
{
int a = 0, b = 1;
int c = a + b;
cout << c;
return 0;
}
When you compile and run the code, your inputs are the numbers you’ve assigned to the variables a and b when you were entering the code. Your processing is the arithmetic - adding the two variables a and b and storing the value in variable c. Your output is drawing the value of variable c to the screen.
You may be asking: what does this have to do with writing a game? Well, a game is based on exactly the same principles - only that the input, output and (especially) the processing phase are much more complicated.
Normally the program flow in an RL can be broken down into the following sequence of events:
1. Draw the game world to the screen
2. Wait for the user to input his/her command (move north, attack, etc)
3. Process the changes as a result of the user’s move and update the game world
4. Repeat
Can you see the sequence of events occurring here?
1. Output
2. Input
3. Process
4. Repeat
As you can see, there are only two real differences:
1. You start with the output phase first
2. You repeat the process almost indefinitely.
To word it the differently – you present a situation to the player, the player evaluates it and decides how to act and the game reacts to the player’s action. The trouble comes in the details but that is essentially the fundamental framework of any game.
To actually show how this works, let’s create a very simple “game” in which the user controls a character on the screen and can move it around. All we require is a means to draw text to the screen and to get keyboard input from the player.
To do this, we require the following header files:
ExtendedWin32Console.h - for console output with color and explicit text positioning
conio.h – for reading input from the keyboard
Note that ExtendedWin32Console.h is a very simple console I/O library written for this guide. When you start making your RL for keeps, I would recommend upgrading to something with much more features, like ‘curses.
The first thing we should always do when the program runs is to clear the screen of any junk that was there before. It’s a good practice to get into. The code for this is here:
console.Clear();
Much like how iostream.h would give you access to the cout object, by including the file ExtendedWin32Console.h gives you access to an object called console, which behaves like a very simple version of cout. Don’t worry, it’s not as complicated as it seems.
Right, now that’s out of the way, we can move on. Remember how the program flow for games repeats? We’re going to need a loop somewhere in there, so we might as well add it now. Let’s make it an infinite loop since we don’t know how we will terminate it.
while( true )
{
// Output
// Input
// Processing
}
So putting it all together, the code should look something like this now:
#include "conio.h"
#include "ExtendedWin32Console.h"
int main( void )
{
console.Clear();
while( true )
{
// Output phase goes here
// Input phase goes here
// Processing phase goes here
}
return 0;
}
Alright, it’s starting to take shape!
The first and most important thing is to show the player what’s going on. It’s not much of a game if all you see is a blank screen.
To do this, we need to draw the player’s character on the screen. In homage to Rogue, we’ll use the “AT” symbol, @, to represent the player. But it’s not enough to simply throw it at the screen, we need to make sure that it’s in the right spot.
Regardless of the operating system involved, in console mode the screen is divided up into a grid, much like graph paper or a chess board. Only one character can occupy one tile at a time. This is grid perfectly suited to console-based games as it gives a sense of space and distance in your game.
What we need to do now is to determine on what square tile on the console the player is at. To do this, we need to make sure we record the player’s position in some sort of variable. Since the screen is two-dimensional, we’ll use an (X, Y) coordinate system to indicate position.
int nPlayerX, nPlayerY;
Where the nPlayerX variable determines how many tiles from the top-left of the console the player is at horizontally and the nPlayerY variable determines the vertical offset from the same corner.
We need to initialize these variables this so that the player starts at a definite location (rather than whatever garbage data was residing at their addresses). A console screen by default usually is 80x25 characters big, so let’s gun for something in the middle.
int nPlayerX=40, nPlayerY=12;
Now all we need to do is get the computer to draw the ‘@’ character at that precise location on the console. To do that we need the following code.
// Output phase
console.SetPosition( nPlayerX, nPlayerY );
console << '@';
This makes our total code look like this.
#include "conio.h"
#include "ExtendedWin32Console.h"
int main( void )
{
console.Clear();
int nPlayerX=40, nPlayerY=12;
while( true )
{
// Output phase
console.SetPosition( nPlayerX, nPlayerY );
console << ‘@’;
// Input phase goes here
// Processing phase goes here
}
return 0;
}
Pretty straightforward, right?
Now we have drawn the player’s character to the screen, we can now let the player decide what to do.
The conio.h header file describes a very handy function called getch() which does two things:
1. Waits for the user to press a key
2. Returns an ASCII character representing the key the user pressed
These two things do exactly everything we need to do for this phase. All we need to do is save the key that the user pressed so that we can process it later.
char nKey = getch();
Doesn’t get much easier than that. So now our code looks like this:
#include "conio.h"
#include “ExtendedWin32Console.h”
int main( void )
{
console.Clear();
int nPlayerX=40, nPlayerY=12;
while( true )
{
// Output phase
console.SetPosition( nPlayerX, nPlayerY );
console << ‘@’;
// Input phase
char nKey = getch();
// Processing phase goes here
}
return 0;
}
With input and output done, all we need to do is process the key the user pressed. In this case, we’ll say that the arrows on the number pad move the player around. If we keep NUMLOCK on, then the possible values of the nKey variable are:
• ASCII CHARACTER ‘2’ – DOWN • ASCII CHARACTER ‘4’ – LEFT • ASCII CHARACTER ‘6’ – RIGHT • ASCII CHARACTER ‘8’ – UP • ASCII CHARACTER ‘Q’ – Exits the program
Movement occurs by incrementing or decrementing the coordinate variables nPlayerX and nPlayerY. The question is, which way is up? How do we move left? To figure this out, take a look at the following picture. It contains two characters, each put at a different coordinate.
The second character is down and to the left of the first, but according to the coordinates, it is (-10, 5) away. Using this, we can determine the following:
1. To move up, decrease the y-axis coordinate by one (nPlayerY--)
2. Consequently, to move down, we add to the y-axis coordinate (nPlayerY++)
3. To move left, decrease the x-axis coordinate by one (nPlayerX--)
4. Consequently, increment the x-axis coordinate to move right (nPlayerX++)
Using this in our program is easily handled by if or switch statements. We’ll use a switch statement as it’s a little cleaner to look at. Pay close attention to the increments and decrements here.
switch( nKey )
{
// Move down
case ‘2’:
nPlayerY++;
break;
// Move left
case ‘4’:
nPlayerX--;
break;
// Move right
case ‘6’:
nPlayerX++;
break;
// Move up
case ‘8’:
nPlayerY--;
break;
// Quit
case ‘Q’:
case ‘q’:
return 0;
break;
}
Putting it all together we get the following:
#include "conio.h"
#include “ExtendedWin32Console.h”
int main( void )
{
console.Clear();
int nPlayerX=40, nPlayerY=12;
while( true )
{
// Output phase
console.SetPosition( nPlayerX, nPlayerY );
console << ‘@’;
// Input phase
char nKey = getch();
// Processing phase
switch( nKey )
{
// Move down
case ‘2’:
nPlayerY++;
break;
// Move left
case ‘4’:
nPlayerX--;
break;
// Move right
case ‘6’:
nPlayerX++;
break;
// Move up
case ‘8’:
nPlayerY--;
break;
// Quit
case ‘Q’:
case ‘q’:
return 0;
break;
}
}
return 0;
}
That's pretty much it. Compile and run the code and see what we’ve got. The first thing you notice is the following effect:
It keeps on drawing the same character all over the place!
This is actually to be expected. We're drawing things to the screen, and moving around, without ever once erasing anything. This can be fixed by adding a simple, one line command at the beginning of the output phase, resulting in an output phase that looks like this:
// Output Phase
console.Clear(); // <-- The fix is here
console.SetPosition( nPlayerX, nPlayerY );
console << ‘@’;
Basically, we wipe the entire screen clear and draw the player in the new position. Save, compile and run the fix and see how things work now.
If I have done my job, you should now be getting comfortable with structuring your code, and have begun to get your feet wet with the whole concept of drawing to the console and receiving user input.
There are a few ignored problems with this example, the most blatant to the experienced developer is that there is no code to prevent the user from moving off the screen which can lead to data corruption, program crashes and other major errors. Before you move on, I would recommend playing around with this application to make it do the following:
1. Limit the user to only moving within the screen itself.
2. Adding diagonal movement.
If you can do these things, you are getting the hang of things quite well. Also, it may help to play around a little and try messing things up to see what happens.
Table of Contents Source Code Article Two