Creating the dungeon
First of all, there are the two methods
The former is currently empty. It's supposed to, I presume, load an array of integer
data corresponding to the full dungeon layout, over the network. That's only done
once, during initialization.
The latter is meant to copy that data into the dungeon array
before each game session, so the player always starts from a "fresh" dungeon (with no
broken doors or escaped prisoners). In my test applet,
map with data from a couple of constant arrays.
During a session
gameState (see the variable information page) tells the main
loop what to do depending on its value. My test applet has plenty of "dummy"
implementations of things like the introduction screen, the after-death screen, the
run-out-of-time screen, etc. The code for that should be inserted in the corresponding
places in the
switch(gameState) statement in the
method. Just don't touch cases 0 (preparing game session), 1 (running game) and 6
(the player death scene). I've used the convention that if there are some major
screen changes, one value does the proper drawing and then lets another value take over.
case 9: // Initialize presentation
nearBG.drawString("Press SPACE to start",160,100);
case 10: // Presentation screen -- wait for SPACE
gameState 9 clears the screen and writes the text "Press SPACE to start".
Then it changes itself to 10, which in the next loop iteration means waiting and
listening for the SPACE key to be pressed, and if so change to state 0, which will
then prepare for a game session.
Timers and counters
I decided against using constants for tweaking and tuning this part, since I didn't
know if the customer would accept a simple red-and-yellow rectangle for displaying the
remaining time. I assumed they'd want to replace it with something a little more in
style with the rest of the graphics.
resetGame() contains one section of code for drawing the
necessary things at the top of the screen. It currently looks like this:
// Timer and saved prisoner counter
Most of it will need to be replaced, I suspect. Later on, the
method contains this code section for updating the timer bar:
i=(247*timer)/timeLimit; // Update timer bar
It checks if the pixel length of the timer bar has changed since the last game loop.
If so, it "nibbles away" one more little part at the right end of it. (The figure 247
is the current initial (maximum) length of the timer bar.)
Sounds and extra graphics
Well, I put in a currently empty method called
loadSounds() to make
sound implementation easier. But since I don't know what sort of sounds the game
should include, I wouldn't know where and when to activate them. The programmers
will have to determine that on their own, by studying the comments in the code.
I'd suggest modifying the method
loadGraphics() so that it loads
an additional graphics file containing a proper logo and other things that will make
the game more interesting.