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.