tutorial.txt

乒乓球游戏程序

Core routines
*************

The first step
==============

The first step in writing a game my way is to get the game
engine running.  It won't do much yet, but once we have the
core routines working we can start adding on new modules and
features.

The code in this chapter initialises Allegro, selects a
graphics mode and then appears to do nothing until you hit ESC.
It is actually continually polling the ESC key (in the input
module) and calling the display module's `display_update'
function, which does nothing but wait for a VBI using `vsync'.

Basic game implementation
=========================

The heart of any game is a loop, which continually updates all
the objects (i.e. it allows them to move).  Since games are
interactive, we also need to get input from the user so the
player's object can be moved, and we need to display something
to let the user know what's going on.  So the three main tasks
are input, processing and output.  The output includes audio
(sound and music).

In the simplest case, then, our main loop just does these three
things on each cycle.  This is what we will do here, but note
that it has disadvantages -- often the display code is rather
slow, and (worse) varies greatly between systems.  You really
don't want the game speed to depend upon the display, nor upon
the speed of the computer running the game.

There are a number of solutions to this, the simplest of which
is to reduce the game speed to one that all (reasonable)
computers can manage.  This is what we'll be doing here; by
calling the `vsync' function each time through the loop (within
the display code) we're restricting the speed to around 60
cycles per second.

This is only a partial solution; the game speed could still
vary from system to system, and if we miss a VBI (i.e. the
game/display code takes too long, or we're running under an OS
like Windows 95 that occasionally preempts us just before the
VBI) then the game will wait until the next one, resulting in a
little freeze in the action; you might notice this happening in
a few chapters' time.  In later tutorials we'll look at better
solutions, but for now this is the way it will stay.

The module structure
====================

At this stage the module structure is very simple.  In fact we
will always try to keep the relationships between modules
simple.

The `main' module exists as an entry point from the operating
system. It handles one-off initialisation and shutdown, and
calls the `game' module to run through the game once.

The `game' module is the backbone of the actual game.  It will
call subsidiary modules to do the actual work.  The game loop
is in this module.

The `input' module will be responsible for getting input from
the user.  At the moment it does very little though; it just
checks whether the ESC key is being pressed and, if so, sets
`game_end_flag' in the `game' module, causing the game to end
after the current cycle.

Lastly we have the `display' module, which will be used to
write to the screen.  No other module should write directly to
the screen while the game is running.  At the moment this
module just sets the video mode and draws a border, then waits
for a VBI every time it is told to update the display.

Header files in this program
============================

As mentioned earlier, in general there is one header file for
each module.  Most of the header files are pretty routine --
they just declare a few functions that will be called by other
modules.  I'll mention a few things here though.

First there's the issue of global variables.  As I said
earlier, I have no objections to using them where necessary.
One aspect of this though is that they have to be declared
somewhere.  If you make a header file called `globals.h', which
will be included by all other modules, then if it is modified,
every single component of the program needs rebuilding.
Obviously this is undesirable, so you only want to put really
elementary things in there, that will require a complete
rebuild anyway.  Other things should be split between other
shared header files.

The only global variable in this program so far is the
`game_end_flag' variable, defined in `game.c'.  This variable
needs to be accessed at the moment by the `input' module, but
in the future it might be used by other modules as well to
signal that the game should end.  Because it is only needed by
some of the modules I put its declaration in `gamevars.h',
which these modules can include.  The `main' module doesn't
care about this variable, and the modules that do care about it
don't need to know about the `game' module's interface in
`game.h', so this arrangement works well.

In short, avoid telling modules things they don't need to know,
and don't be afraid of using many header files to declare the
variables occuring in one source file.