 |
Useful variables and objects
|
 |
There are some variables and objects you will need to work with when adding
new code to the game engine. First, the control variables:
int gameState,pressedKey;
boolean refreshScreen;
pressedKey contains the ASCII code of the key
that is currently being pressed, or 0 if none. It comes in handy when requesting
user input during the presentation.
In each animation frame, the applet performs some kind of task. gameState
is the variable that specifies what the applet is supposed to be doing. If it's
equal to 1, we're in the middle of a game session and the applet should keep track
of the player and the prisoners, update the timer, etc. Other values corresponds
to other things. The main loop, run() contains a
switch(gameState) statement that should be pretty much self-explanatory.
I haven't used refreshScreen much. If it's set to "true", it means the
applet should draw the main graphics buffer onto the screen at the end of each
animation loop. Right now it's always set to "true", but it is conceivable
that some programmer might want to turn the updating off while preparing, for example,
a presentation screen that takes more than one animation frame to draw, just to make
sure the applet won't display any half-finished graphics.
Then the graphical objects:
Image farBuffer,nearBuffer,mobiles[];
Graphics farBG,nearBG;
I work with two so-called graphics buffers, nearBuffer and
farBuffer . The former is exactly the size of the game screen and gets
copied to the visible applet area at the and of each every animation frame, unless
refreshScreen is turned off.
farBuffer is the secondary buffer, which contains the background
during a game session. In the main game loop, it gets drawn onto the
nearBuffer , which then has the moving objects (player, prisoners, etc.)
drawn onto it, before that one is itself drawn onto the visible applet area.
But the farBuffer also contains a full set of the blocks that
are used to construct the dungeon. The reason for this is that whenever the player
leaves a room and enters another, the farBuffer needs to have its entire
game screen background updated, block by block, in much less than one second.
That's well over a hundred image drawing operations and
the ordinary drawImage method isn't fast or reliable enough to handle that,
so I'm letting the applet use copyArea instead, which copies rectangular
blocks of pixels from one place to another within the same image. This
is much faster.
As a consequence, there is no need to store the background building blocks as
individual images. I only do that with the mobile objects. Those are kept in the
array mobiles[] , where mobiles[0] is the mobile object
that comes first in ordinary reading order, mobiles[1] is the second, etc.
Note that this also means that background building blocks cannot be directly drawn
or accessed the way typical images would. I've written a special method for that,
called drawBlock(int num, int x, int y) , which draws block number "num"
at the co-ordinates (x,y) in the farBuffer .
nearBG and farBG are just the Graphics objects
associated with nearBuffer and farBuffer .
|