Goodbye, GFORGE. Hello, Terragen

Oh, dear. GFORGE no longer works for me, not in Windows XP and not in a DOS cmd box within Windows XP. Rather than drag out my old Windows 98 laptop to try that, I downloaded a free copy of Terragen, which does a similar sort of thing.

Unfortunately, Terragen doesn't output in a form that POVray understands as a height field.

But after much googling, I discovered For Export Only (FEO) which is a set of plugins for Terragen, including one that creates a BMP file that POVray understands.

Ah, well. No-one said it was going to be easy.

Sprite rocks.

Next task is to devise a number of rock sprites. I'll try several of these GFORGE terrain maker files.

Aide-memoire for the Junk navigation map

This entry is PROVISIONAL. It will be updated as necessary.
Route S start -> F finish * = defined

  W   X   Y   Z
1 * - F   * - * 
  |       |   |
2 *   * - *   *
  |   |       |
3 *   *   S   *
  |   |   |   |
4 * - *   * - *

Y3 Start. Sprite rocks stbd 
   Sprite cone port
Y4 Open sea. Sprite cone stbd
Z4 Rocks 2 + pylon on port - visible from cockpit port, bow port and cabin port
Z3 Sprite rocks port 
   Sprite cone port
Z2 Sprite rocks stbd 
   Sprite cone port
Z1 Sprite rocks port and stbd
   Rocks 3 + pylon fwd - visible from bow fwd only
Y1 High Rocks fwd - visible from bow fwd only 
Y2 Rocks 2 stbd
X2 Rocks 1 fwd. Visible bow fwd only
X3 Girders
X4 Open sea. Sprite cone port.
W4 Rocks fwd.
W3 Open sea. Sprite cone stbd.
W2 Wreck port. Sprite cone stbd.
W1 Rocks 1 + pylon on stbd - visible from cockpit stbd, bow stbd and cabin stbd
   Jade on stbd bow - visible from bow fwd only
X1 Finish. Jade fwd - visible from bow fwd only 

Rocks at sea

One of the sets of rocks I've been developing for scenery purposes. The texture used is Cork, which appears as a nice arid island. Note the shadow of the junk's sails on the sea in front. In use, there will be a pylon with guidance 'traffic lights' on the island.

Back in harness

Having been distracted for several months by, for example, two editions of Mythaxis Magazine (worth a read), a golfing holiday, a new palmtop computer, new books and so on, I made a restart, two nights ago on my POVray creations.

In fact, though I only hinted about it, I made a plan for the first part of the game that involved a bit of varied scenery. At first, I was envisaging sprites to supply even static scenery. Now, I'm more inclined to a mixture of sprites and static images.

In the original post, I reproduced my notebook pages here. Totally incomprehensible, I'm afraid. I removed them.

The plan is to gradually reveal the route to be followed by indicating previous and next positions by traffic light style markers on shore or on buoys. The map is gradually revealed on the screen in the cabin. When the problem has been solved, the player can go straight to the destination, but the first time he has to either guess it or work it out by following the route.

POVRAY woes

In rendering the junk final images, I've encountered problems with ropes and the cabin textures. It only needs time, as ever. Even on my quickest machine, rendering takes hours per scene, and every time I get a rope position wrong, it has to be done again. I think I'll use cylinders and tori to get the anchor positions right, before final render. We're getting there. At least I'm working on it virtually every night now.

I've embedded the instructions for multiple renders in the junk.pov code. In the past it's always taken forever to remember how to do it.

KFI and KFF are the initial and final frame nos (each scene's file label is appended with frame no, which corresponds to scene no)

KI and KF are the initial and final clock values which I use to change the scene no.


// "animation" command line string (paste in empty command line box above)
// +KFI100 +KFF102 +KI0 +KF2

// comment out next line if animation in force
#declare scene=100;

// comment in following line if animation in force
// #declare scene = clock+100;

MP3 player

An interruption - I may have found a suitable mp3 player (by Neolao) to substitute for the rather awkward MIDI player in the Javascript. (Note to self - see samsung/notino/bridge)

Starting to Build the new version

Now working on changing BridgeData.java to include the junk section.

Had to re-discover the build route - it's more than a year since it was last changed. I've improved the build environment, and installed up to date JREs.

Every time I start a scene, I trip over something I've forgotten, but it's progress, constant progress.

The Junk Puzzle

Yup. Got it now. I've devised a 16 point maze - not really a maze, because there's many ways through it, and when you've solved it, you can go straight to the end next time you play. Each point in the grid, let's call it, has its own ID lights, and a different set of scenery around it, viewed from the junk. There are ten positions on the junk, bow, stern, facing various ways, and there is a different scene visible from each of these junk scenes, depending on the ID of the current point in the grid.

So... the scenery is delivered by sprites rather than background, and the 160 possible visible scenes are reduced to ten with different sprites at each location.

Each point in the grid indicates the adjacent IDs and the navigation system allows the player to move to whatever ID he favours.

It's quite a lot of code, but it saves masses of scene files. Instead of 160 scenes, we have just the 10 on the junk, the background sprites being imposed on an empty sea/sky.

Feverish Activity behind the Scenes

Over the last few weeks, I've concentrated on a variety of articles on the junk - table, chairs, a bucket etc.

The next stage is to build it into a new version of the example game, but that will involve some new work on the Sprites, to give the water a more realistic appearance.

I also have to re-write the BridgeData module to control the new scenes.

I am a little conflicted on the "Junk Puzzle" - i.e. how to get from the initial scene of being on the junk to getting to the island. It mustn't be too obvious - the player should have to think about it - but I don't want it to turn into a maze.

Work re-commences.

I returned to this project yesterday. I am designing the navigation system for the junk, one that uses coloured buttons and a map to lead the user round a number of locations at sea. The view outside the cabin and from the deck has to be consistent, with the appropriate angles of buoys and the island. These will have to be installed as sprites, so that we don't have to make a scene for every viewpoint.

The cabin of the junk, from which navigation takes place, looked so stark that I'm installing a carpet in it.

I still haven't figured out how to organise the puzzle. I don't want just a maze or point and click shooting gallery. There has to be some substance to the puzzle that looks soluble but isn't too easy.

__________________________________

Once I get the navigation in place, I'll do another test version. Watch this space.

Odd Comments

Odd Comments
Just a little side issue here. I keep getting comments on the blog that I can't publish because the commenter's name and comment are rendered in a font that my browsers (none of them, and I have many) cannot render. If you are not having your comments published, then this is the reason.


Break in Transmission
The recent pause was due to an extended period of working abroad without access to my code and Povray sources. Normal service will be resumed shortly.

Latest Junk Picture

I just finished this little beauty this morning. Note the ropes and the pylon. It took FIVE HOURS, THREE MINUTES AND TWO SECONDS to render! That was with a number of time-wasting options enabled, particularly the Rope functions.

Pylons

I'm going to have pylons in the water for the junk to use in navigation. These pylons will have a sort of road map on them, leading to the island.

Things are moving much faster for me now. There's a thrill of anticipation that I'll soon have a second working example with much more substance to it.

Strategy Again

I am finding my slow pace of development irksome. I have today been thinking of strategies to get another short example game out quite quickly.

Among these strategies are:

Complete the first section of the game quickly, without further refinement, and forgetting the next section.

So:
- Junk
- Dockside doors
- Elevator

I'll just get on with that.

Comments on POVray techniques

Following up on the comments in the previous post, I should point out that I can optionally apply a grid to any scene. The grid is a series of cylinders, set 5 units apart and centred on the origin of the scene. That gives me an accurate measure of where to put an item. I build the item and rotate it at origin, then move it to the desired location.



The animation (which I may use for a multi-render batch file), briefly, works like this:

"POV-Ray supports an automatically declared floating point variable identified as clock (all lower case). This is the key to making image files that can be automated. In command line operations, the clock variable is set using the +k switch. For example, +k3.4 from the command line would set the value of clock to 3.4. The same could be accomplished from the INI file using Clock=3.4 in an INI file.

If we do not set clock for anything, and the animation loop is not used, the clock variable is still there - it is just set for the default value of 0.0, so it is possible to set up some POV code for the purpose of animation, and still render it as a still picture during the object/world creation stage of our project.

The simplest example of using this to our advantage would be having an object which is travelling at a constant rate, say, along the x-axis. We would have the statement

translate <clock, 0, 0>"

Green Shoots of Recovery

Last night, I dusted this project off, improved the staircase algorithm, and added a staircase to the Jade island.

One of the problems is the length of time each render now takes, even for a minor adjustment. However, once some new component is settled, I think it's probably going to be possible to set up a batch rendering job to produce all the renders anew, every time a significant component is added.

I have decided to inch the project forward in its incomplete state, adding as many of the individual stages of the game as possible, even based on an incomplete background picture.

For example, if a new bridge, building or piece of furniture is added to the island, then I might have to re-render a number of backgrounds later, and I might have to modify the positions of sprites to an extent, but better incomplete scenery at this stage rather than incomplete gameplay.

Update

Like most bloggers, I sometimes take time off from blogging.

I have had a number of interruptions, including a trip to Barcelona, work on Mythaxis and (guiltily) replaying Myst III - magnificent scenery.


I haven't been totally idle, though. Since I last blogged, I have refined the Junk and modified a spiral staircase algorithm to give me swooping stairways. I'll post some examples real soon now. And Christmas hols are coming up. I should get some more design done then.

Reporting completion on the Junk

It's been a slowish business, but I'm now reasonably happy with the junk. After all, it's only a platform for transport and a piece of furniture to view from afar.

As a sprite, it'll be viewable at various sizes and seen from left or right, but not animated.

I'll do a separate animation of the waterline splashing along, so it appears to be moving, and calculate speeds / sizes for various manifestations of it.

Yet More Junk

The latest version of the junk and its dinghy (which shares the junk's hull shape) sans ropes, but ropes will appear soon, thanks to Chris Bartlett's Rope macros and "after-sales support".

Benjamin Roux has also volunteered to help with the project.

More Junk

Got the masts and sails in the junk. Had some difficulty with the decks, because patches are not 'real' shapes and differences, intersections etc don't work the way you'd expect. Solving it by fitting a deckhouse and then painstakingly filling in the areas left with boxes and polygons, which will lead to a more authentic final appearance. The picture here is hull, deckhouse, mast and sails.

Junk

Put together the hull for a Chinese Junk, using 3 bicubic patches (actually 2, because the port and starboard hull sections are mirror images of each other.) The view is of the transom (rear end) of the boat. I took the measurements for the hull profile from a design on the internet.

Next, the decks and masts.

A Few Extra Plot and Image Points

I envisage a sea cave that the boat can sail into, but only when the portcullis across its entrance has been raised. So the player is at a land entrance to the cave, and can raise the gate from there, but the dock in the cave is only reachable by the boat sailing in.

Also, I started to devise a new spiral staircase function where the steps were not connected at the centre. I realised yesterday I could use an existing spiral stair function, and cut the centre out of it by differencing with a cylinder. I'd still have to add vertical struts on the edges for realism - a staircase can't just hang in the air - but the main job will be done.

Fan animation. I observed how a fan opens. The rearmost blade of the fan stays still, and only the top blade is showing. The top blade flips out, pulling the next and the next and so on.

I suspect the best way to create the images for this in povray would be in reverse. Start with the open fan as an array of blades, coat the array with the image, then for subsequent frames, pull the top blade back over the one underneath it, then pull them both back over the third, and so on, until the fan is closed. I'm not entirely sure this is possible, though.

A Bit of a Brain Dump

I haven't posted very much lately, partly because I was getting out the next issue of Mythaxis, but I have been thinking about it a lot. I have decided to start the game on a boat - a Chinese Junk. The boat can transport the player to various locations around the island as necessary, and I would use a chart table below decks to direct the boat to the destination.

The boat will also contain a number of useful items - including a fan to transport the player back to the junk, or summon it.

I already have a boat in povray. I just have to elaborate it a bit.

In thinking about this, I realised we must have a rocking effect for the scenery when on deck. I considered using an array of g2d rotated images for this, but I think it'll be easier just to pre-rotate the images in Paint Shop Pro and load them as sprites. I can arrange that they not be the whole size of the applet window by placing static sprites of portholes, sails, deckhouses etc to frame the background which will be a lower priority sprite.

I was briefly worried about fan management, because there are several fan functions, which I solved by having a hot spot on the open fan, and by having a special room for open fans.

• pick up (closed) fan - double click when fan not carried
• drop (closed) fan - double click when fan carried
• open fan - single click when in inventory 'room' only and fan is closed
• close fan - single click (not on fan hot spot) when in inventory 'room' only and fan is open
• use fan - click on hot spot on open fan

Sounds complex, I know, but I think it'll be natural. I may remove the restriction on opening the fan only in the inventory. Fan animation is going to be fun!

I have come to the conclusion that I have to fill out the game in povray before I do any more gameplay. I just keep realising that the game isn't rich enough without a good deal more articles in it. The game's going to be small enough without looking impoverished. So the next big push is scenery.

I still haven't bitten the bullet of music in mp3, but I'm not too worried about that.

Break in Transmission

A whole month since I've had time to concentrate on The Game, but watch this space...

Version 1.1 now available

A zipped version with all the fixes to date is now available.

The original (lame) example now runs on 1.1 code.

Both of these can be accessed via:

http://amazonsystems.phpzilla.net/

What Next?

I think I have reached a suitable point at which to preserve the current state of the code. So I'll upload version 1.1 in due course.

Next stage will be new artwork, followed by a new puzzle, then the music problem must be solved.

Scale and Flip facilities

I have now added scale and flip facilities, to allow the same image to be used for a sprite at different sizes and reversed.

Different scale in x and y direction is possible, invert, mirror and all three.

In the diagram:
1. Normal sprite
2. 75% scale on both x and y axes
3. 75% scale on both x and y axes plus mirror
4. 75% scale on both x and y axes plus mirror plus invert

Priority

Having a little trouble with the priority of sprites, but nothing desperate yet. I have a feeling that monkeying with vector elements is the cause of the problem. I may have to try a different approach to sorting the sprite list.

(later) Schoolboy error. I was using insertElementAt() instead of setElementAt().

Thus - the Vector of Sprites appears in slist:

//      This is a sinking sort. On first pass, the highest
//      priority sprite arrives at the bottom. On second,
//      the next highest arrives at second bottom, etc.
//      Sprites of the same priority remain in their
//      original sequence with respect to each other.
    for (ii = 0; ii< slist.size()-1; ii++)
    {
        for (jj = 0; jj < (slist.size()-ii-1); jj++)
        {
            spare1 = (Sprite)slist.elementAt(jj);
            spare2 = (Sprite)slist.elementAt(jj+1);
            if (spare1.getPriority() > spare2.getPriority())
            {
                slist.setElementAt(spare1, jj+1);
                slist.setElementAt(spare2, jj);
            }
        }
    }

Gull motion bug fixed

I was dissatisfied with the original gull motion (see 30 December 2008 entry). Found out what it was today.

The previous table had the gull stopping for an extra beat at zero deflection. Now deflection goes from +3 to -3.

Important bug solved

Sorted. The solution was to drop anything being carried into the limbo room before doing the Restore. The bug was caused by the clash of an object being simultaneously carried and restored to an uncarried situation.

Also, and in connection with this bug, I added the "limbo" room to the system. All adventures need a limbo room in which to store objects that aren't anywhere else. For example, a sprite that has been destroyed, or has not yet been revealed can be left in there where it will do no harm until such a condition arises whereby the game writer decides to put the object back in play. "limbo", like "inventory" becomes a compulsory scene in the system, because it is referred to in the RestoreGame function by name.

After another sweep through the code to pick up any other anomalies or improvements, I'll publish version 1.1 in both source and runtime.

Important bug

I've found a bug that sometimes, on a restore, leaves a sprite lying on every scene, a sprite that cannot be picked up. I can't reliably reproduce it. I thought at first that if you started a new game and restored a situation in which you were carrying a sprite, then it happened, but it doesn't seem to be that. Ho-hum... The position it occupies on the restored scene and all other scenes is the same as its original (i.e. game start) position. Later (much later, days later) I stumbled upon the bug again and can now reproduce it. It happens if I put the key in the inventory, then exit the inventory and save. Then I enter the inventory and pick up the key and restore. Now I can reproduce it, it should be simple to fix!

Development problem solved

I was finding that new versions of the code were not being acknowledged in Firefox, so that even if I made a change, it kept the old code.

Discovered that you have to bring up the Java console and type x to clear the classloader cache. At first, IE didn't seem to have the same problem, but that was probably because I restarted IE every time I tested it.

Anyway, to be on the safe side, I clear the classloader cache every time now.

And using mousePressed() instead of mouseClicked() works a treat. The mouse response is very much better now.

Development system

Over the last few days, I've set up a simple development system using command line calls to javac etc. I've installed EZ Document Safe to keep the sources and versions in order.

The good news is that the original code still compiles and runs.

I have found out why the mouse click doesn't work so well. If you drag the mouse a little when you press, you don't get a Clicked event; you may or may not get a Dragged event; you may get both; and it all depends on the JRE platform, the timing and how far it was dragged. There's a certain amount of discussion on SunWeb about the matter, and I used a test application to see what was going on.

I've devised a new system which ought to work on all platforms. I'll try it soon.

I have also downloaded JLayer, an mp3 player. It works in free-standing mode, but I don't know how it'll fare when I try to incorporate it into my code. I may just run it in a separate applet like the current midi ones.

Some Story and Setting Outlines

Chinese Myst - Ideas

Major features :
o 3 mountains, each with a different character
o Bridges which need to be deployed
o Stairways and paths
o Pagodas, elevators, secret compartments and passages
o Monastery
o Nothing that's inappropriate technology, so use water power, clockwork, rope and pulley, steam etc.
o Locks, Puzzle locks, trapdoors
o Parts to fit in a matrix or jig-saw
o Logical puzzles

Despite appropriateness of technology, allow a little magic - tiny dragons, animated statues, self-igniting candles, ghost, fireworks, distant events in a crystal ball or animated picture or model. Also the fan is the equivalent of the Myst book (teleport mechanism).

Temple dogs, vases, chest of many drawers, lamps, screens, nested objects, musical instruments, cabinets, boxes, gong, water clock, teapot.

? Boat travel ? Aerial Runway

No language or writing, but perhaps some simple symbols.

Tiny model of the game world.

The Objective

(i) Must be revealed without verbal description so it could be demonstrated in a picture or a fan.

(ii) NOT the following hackneyed objectives:
a) Lord of Evil - destroy him... NO!
b) Imprisoned Princess - free her... NO! NO!
c) Save the Planet... NO! NO! NO!
d) Find the Ultimate Treasure... NOT AGAIN!

(iii) Well, perhaps a treasure hunt with trophy case. Collect seven treasures. The empty trophy case at the beginning, the filled one ends the game. A picture shows how the trophy case should look.

Parallel Development

I've now described the original game, and delivered the sources for public consumption. Next, I shall embark on a new generation of the game.

Writing this game all by myself is going to be a bit of a challenge and a trifle lonely. Three threads have to be handled:

• Engine code development
• POVRay images development
• Story development

Frankly, I could do with some help on any of the threads.

First, I'll set up a new code development and test environment. I don't even know if my 2003 code will still compile and work if I recompile it with an up-to-date Java. Most of my early development took place on J++, which, despite its shortcomings, was a pretty friendly development environment. Latterly, I was using the Sun bare bones development system. I flirted with Borland JBuilder for a while, but it was more trouble than benefit.

Returning to POVRay

I no longer have the POVRay source I used for the example game, but the current (2008) version is not so very dissimilar, so I have stored that at http://amazonsystems.phpzilla.net too.

The whole of the game world is contained within the single source file China3.pov. Quite near the beginning of the file, you can choose a scene number. The approximate aspect covered by the scene number is described in a comment.

The islands are described by the height file Output.tga.

What you get is a terrain marked out in triangles. I have given it a jade texture, which seems to suit the angular effect. Some of the textures I have specified are rather simple and will be altered for final rendering, as they take too long for testing if complex.

The world is not very rich in variety as yet. I intend to add details such as trees and other plants, stones, and various "natural" features. Other scenery will include tunnels, stairways and buildings. I have included a bamboo object to use as building materials, with the bamboo.gif file for texture.

The game itself will require buttons, levers, doors, bridges, mechanisms and no end of cunning stuff, but often, though they may be designed in POVRay so that they match the surrounding illumination and background, they will be delivered in the game as sprites rather than as scenery, so that they can move.

Public access to Bridge files.

I eventually settled on phpzilla.net, which provides 5 Gigs free storage (at the expense of a little banner advertising on web pages and a few splash pages which inconvenience me, but not the user). You can see the address in my links listing in the sidebar.

Public File Access

Although, by the time you read this, the problem will be solved, I felt it worthwhile to air the alternatives I am considering.

Since we may finish up with quite a lot of data, especially images and mp3s, I am reluctant to host them at my base website - amazonsystems.co.uk.

At first, I thought humyo.com the ideal situation for the public airing and sharing of files. I set up a Bridge account and uploaded some data files to it. However, it developed that files stored there were not freely available to web users who did not have their own humyo account. A possible solution is to set up a "guest" account at humyo, an account with read permission for the Bridge account, and publish the username and password on the blog, so anyone could have access. The downside of this is that the huge filestore (10 Gigs) on the guest account would be tempting to spammers, pornographers and other time-wasters. You can be sure they would not fail to exploit the space in some horrid fashion, and I would get the blame.

A "public" Gmail account could be used. Ideally, the data could be held as attachments to bogus emails (this usage of Gmail is quite common). Again, unfortunately, such an account would be open to abuse.

In either of the above instances, I could deliver the keys of the accounts only to those who requested them, but this would discourage casual surfers and people of a suspicious disposition, without protecting me from those who pretended an interest only to gain access to the online storage for their own ends.

The ideal medium for public data is webspace, and I am confident of finding some free webspace somewhere. I am already using a few such sites for various fringe projects, but all have rather small webspace quotas for free users. I may finish up paying for extra webspace on my own site. Sigh.

Panic over

The stricken site - Carfilhiot - has now been repaired. I had a MySQL backup of the site which was in Nucleus, and foolishly decided to convert it to WordPress manually, rather than use a conversion utility. This had the advantage of enabling me to check links and make small corrections, but it was time-consuming in the extreme, and I have only just finished. Work got in the way, too.

Tomorrow, I'll get started on a few more ideas I'm contemplating for the game system.

A Little Pause

Some cretin hacked into one of my other sites, and installed a php bulk mailer, presumably in the laudable aim of extending the world's reproductive capabilities. Since I believe that the world is already over-populated, I made haste to trash the whole thing, and I'm rebuilding it. Back to game development soon.

The Graphic Environment of the Game

Using PovRay, a free ray-tracing package, I've built the island environment in which the game plays. You only see a fraction of it in the sample game, and even that is badly textured.

The basic terrain was mapped out using GFORGE - producing a height model which PovRay accepts and builds into a surface.

The scale is not vast. At the left of the plan above, you can see the L-shaped landing stage in brown, which is 2.8 metres wide.

A bonus of this construction method is that the interior of the surface is hollow, and so if a tunnel is driven into the rock, it reveals a cavern, the full height of the mountain. It is necessary to conceal the fact that the mountain is paper-thin by never showing the actual edge of the hole!

The development plans I have so far are :

• a "trophy room" type of ending to the game, in which, once all the collected items are brought to the room, the game ends
• a door with a maze lock
• an elevator worked by water power which the player has to set working by moving valves
• boats
• bamboo stairways and structures
• trees and vegetation
• lots of odd items
• a control centre on the left hand peak which lifts and lowers bridges and generally opens and closes pathways.

I intend to concentrate on a rich environment that is a pleasure to be in, as opposed to a simple puzzle.

The Display Manager

Finally, we come to the DisplayManager - the last item in the list of
Java classes.

The DisplayManager handles the graphics, using an off-screen buffer and
a clean version of the background. At each frame change, the previous
dirty rectangles are cleaned by writing the background into them, and
then the sprites are copied to the off-screen buffer, and the new dirty
rectangles redisplayed.

In a paint() call, only the dirty rectangles are displayed. In an
update(), the whole screen is written.

I think an unnecessary DirtyRectSet is defined in Bridge. Priority is
not being taken into account in sprite write sequence. There may still
be some confusion as to when an update and when a full redisplay takes
place.

/**
 *
 * DisplayManager.java
 * @author    Mark G. Tacchi (mtacchi@next.com) 
 * @version    0.8
 * Mar 28/1996
 * Heavily modified, with permission, by Gil Williamson 2003
 *
 * DisplayManager provides optimized screen display. Images are drawn to
 * an offscreen buffer and blitted out to the display.  If images are close
 * to one another, they are coalesced and blitted as a single image.
 *
 * A read only cache is kept which represents an untainted background image.
 * This is used in the optimization algorithm as a source for a clean
 * background.
 *
 */


import java.awt.Rectangle;
import java.awt.Graphics;
import java.awt.Image;
import java.awt.MediaTracker;
import java.util.Vector;
import java.awt.Cursor;

public class DisplayManager extends java.lang.Object
{
    private Image    background;
    private Image     offScreenBuffer;
    private DirtyRectSet    dirtyRects = new DirtyRectSet();
          
    /**
    *  A reference back to the Bridge this manager is servicing.
    */
    protected Bridge owner;

    public DisplayManager(Bridge theOwner) 
    {
        owner= theOwner;
    } 

    /**
    * Set the background image to the specified image.
    */
    public void setBackground (Image theImage)
    {
        background= theImage;
        int width = background.getWidth(owner);
        int height = background.getHeight(owner);
        offScreenBuffer= owner.createImage(width, height);
        offScreenBuffer.getGraphics().drawImage (theImage, 0, 0, owner);

        dirtyRects.addRect (new Rectangle (0, 0, width,height));
              
    }/*setBackground*/

    public void refresh(Graphics g)
    {
                //gil temp
        Rectangle r = new Rectangle(0,0,640,480);
        dirtyRects.addRect(r);
        paint(g);

    }
      
    /**
    * Display changed portions of screen.
    */
    public void paint(Graphics g)
    {
        DirtyRectSet flushRects;
        Graphics osb;
        
        if( offScreenBuffer == null )
            osb = null;
        else
            osb = offScreenBuffer.getGraphics ();
              
        //
        // clear background behind actors...
        //
        dirtyRects.drawImage (osb, background, owner);

        flushRects= dirtyRects;
        dirtyRects= new DirtyRectSet();

        //
        // draw Sprites
        //
        Vector slist = owner.bridgedata.getCurrentSprites();
        for (int ii = 0; ii< slist.size(); ii++) 
        {
            Sprite sprite = (Sprite)slist.elementAt(ii);
            // Zilch sprites do not get drawn
            if (sprite.getClass() == Zilch.class) continue;
            Rectangle r = new Rectangle(sprite.getExtent());
            dirtyRects.addRect (r);
            flushRects.addRect (r);
            Graphics g2= osb.create (r.x, r.y, r.width, r.height);
            Image imageii = sprite.getCurrentImage();
            g2.drawImage(imageii, 0, 0, owner);
            g2.dispose();
        }
        flushRects.drawImage (g, offScreenBuffer, owner);
      
    } /*paint*/

} /*DisplayManager*/

DirtyRectSet - Dirty Rectangle Set class

DirtyRectSet is the class that collects all the bits of the image that
have been changed and therefore need replacement. It saves processing
time on image update.

Rectangles are added in ascending sequence of x coordinate, and there is
a collapse() method that enables rectangles which are rather close to
each other to be amalgamated. "Close enough" is defined by GLUE - i.e
within GLUE pixels, the rectangles overlap.

The drawImage method is immensely subtle - so subtle that it always
takes me some time to figure out exactly what it's doing. Importantly,
though, it seems to work.

 
/** * * DirtyRectSet.java * Mark Tacchi Mar 15/1996 
* * * Slightly modified by Gil Williamson 2003 */

import java.util.Vector;
import java.awt.Rectangle;


public class DirtyRectSet extends java.lang.Object 
{
   private Vector rects;
   public DirtyRectSet() 
   { 
       rects = new Vector();
   }
   public void addRect (Rectangle r)
   {
          int size = rects.size ();
        for (int index = 0; index < size; index++)
        {
            Rectangle curr = (Rectangle)rects.elementAt (index);

            if (r.x > curr.x)
            {
                rects.insertElementAt (r, index);
                return;
            }
        }
        rects.addElement (r);
   }

   final int GLUE = 64;

   final private boolean closeEnough (Rectangle r1, Rectangle r2)
   {
         boolean result;
      r1.width += GLUE;
      r1.height += GLUE;
      r2.width += GLUE;
      r2.height += GLUE;
      result = r1.intersects (r2);
      r1.width -= GLUE;
      r1.height -= GLUE;
      r2.width -= GLUE;
      r2.height -= GLUE;
      return result;
   }

   public int getSize()
   {
       return(rects.size());
   }
   
   public Rectangle getRect(int index)
   {
       return ((Rectangle)rects.elementAt(index));
   }
   
   public void empty()
   {
       if (rects.size()>0)
       {
           rects.removeAllElements();
       }
   }
   
   public void collapse ()
   {
        int index = 0;
        if (rects.size () < 2)
            return;
        Rectangle r1 = (Rectangle)rects.elementAt (index);
        Rectangle r2 = (Rectangle)rects.elementAt (index+1);
        while (true)
        {
            // collapse R1 and R2
            if (closeEnough (r1, r2))
            {
                r1 = r1.union (r2);
                rects.setElementAt (r1, index);
                rects.removeElementAt (index+1);
                if (index+1 < rects.size ())
                    r2 = (Rectangle)rects.elementAt(index+1);
                else
                    return;
            }
            // go to next pair
            else if (index+2 < rects.size ())
            {
                r1 = r2;
                r2 = (Rectangle)rects.elementAt (index+2);
                index += 1;
            }

            // done
            else
            {
                return;
            }
        }
    }

   public void drawImage (java.awt.Graphics g, java.awt.Image img,
                    Bridge owner)
    {
        collapse ();

        for (int i= 0; i< rects.size (); i++) {
            Rectangle r = (Rectangle)rects.elementAt(i);
              java.awt.Graphics g2 = g.create (r.x, r.y, r.width,
              r.height);
              g2.drawImage(img, -r.x, -r.y, owner);
              g2.dispose ();

        }
    }

}

The BridgeData class

The BridgeData class varies from game to game. The first part defines all the scenes, zones and sprites. The second part has a number of service routines that deliver the information to calling methods.

There are a couple of method names that I would change for the sake of clarity, specifically:
setCurrentScene() and getCurrentScene(), which really should be called: setCurrentSceneName() and getCurrentSceneName().

// This is the class that defines all the scenes, zones and sprites
import java.util.Vector;
import java.awt.*;
import java.applet.AudioClip;
import java.net.URL;

public class BridgeData extends Object
{
    private Vector scenes;
    private Vector sprites;
    private Scene scene;
    private String currscene;
    public String startup = "waitintro";
    protected Bridge owner;
    public BridgeData(Bridge theOwner)
    {
        owner = theOwner;
        scenes = new Vector();
        sprites = new Vector();
        // Put scenes in here
        //inventory
        scene = new Scene ("inventory", "inventory.gif");
        scene.addZone(20, 20, 80, 80, "", Cursor.CROSSHAIR_CURSOR);
        scenes.addElement(scene);
        //waitintro
        scene = new Scene ("waitintro", "instr.gif");
        scene.addZone(238, 176, 164, 124, "intro", Cursor.CROSSHAIR_CURSOR);
        scenes.addElement(scene);
        //wait
        scene = new Scene ("wait", "hourglass.jpg");
        scenes.addElement(scene);
        //intro
        scene = new Scene ("intro", "china.jpg", "c12");
        scene.addZone(100, 310, 70, 60, "dock", Cursor.CROSSHAIR_CURSOR);
        scenes.addElement(scene);
        //dock
        scene = new Scene ("dock", "dock.jpg", "ara");
        scene.addZone(200, 210, 100, 70, "doornbox", Cursor.CROSSHAIR_CURSOR);
        scene.addZone(0, 0, 640, 60, "dockup", Cursor.S_RESIZE_CURSOR);
        scene.addZone(0, 0, 60, 480, "dockback", Cursor.E_RESIZE_CURSOR);
        scene.addZone(580, 0, 60, 480, "dockback", Cursor.E_RESIZE_CURSOR);
        scenes.addElement(scene);
        //dockback
        scene = new Scene ("dockback", "dockback.jpg", "ara");
        scene.addZone(0, 0, 60, 480, "dock", Cursor.E_RESIZE_CURSOR);
        scene.addZone(580, 0, 60, 480, "dock", Cursor.E_RESIZE_CURSOR);
        scene.addZone(200, 210, 100, 70, "intro", Cursor.CROSSHAIR_CURSOR);
        scenes.addElement(scene);
        //dockup
        scene = new Scene ("dockup", "dockup.jpg", "ara");
        scene.addZone(0, 430, 640, 50, "dock", Cursor.S_RESIZE_CURSOR);
        scenes.addElement(scene);
        //doornbox
        scene = new Scene ("doornbox", "doornbox.jpg");
        scene.addZone(0, 430, 640, 50, "dock", Cursor.S_RESIZE_CURSOR);
        scenes.addElement(scene);
        //Put sprites in here
        RippleA ripplea = new RippleA("ripplea", "intro");
        sprites.addElement(ripplea);
        GullA gulla = new GullA("gulla", "intro", 480, 40, 0);
        sprites.addElement(gulla);
        GullA gullb = new GullA("gullb", "intro", 370, 200, 78);
        sprites.addElement(gullb);
        GullA gullc = new GullA("gullc", "dockback", 80, 50, 12);
        sprites.addElement(gullc);
        GullA gulld = new GullA("gulld", "dockback", 150, 200, 78);
        sprites.addElement(gulld);
        // Put carryables here
        GoldKey goldkey = new GoldKey("goldkey", "dock");
        sprites.addElement(goldkey);
        Zilch dockkeyhole = new Zilch("dockkeyhole", "doornbox");
        dockkeyhole.setPosition(200, 240);
        URL addr = owner.getCurrentUrl("sounds/rooster.au");
        dockkeyhole.addAudio(0, owner.getAudioClip(addr));
        sprites.addElement(dockkeyhole);
    }
    public boolean collide(String spritename, String hitter)
    {
        if (hitter == null)
        {
            return true;
        }
        else
        {
            if (spritename.equals("dockkeyhole") && (hitter.equals("goldkey")))
            {
                Sprite found = getSpriteByName(spritename);
                if (found != null)
                {
                    AudioClip auclip = found.getAudio(0);
                    auclip.play();
                    return true;    
                }
            }
        }
        return false;
    }
            
    // Above here are game-specific functions
    // Below here are general purpose functions
    public Scene fetchScene(String a)
    {
        int ii;
        if (scenes == null)
        {
            return null;
        }
        for(ii = 0; ii < scenes.size(); ii++)
        {
            scene = (Scene)scenes.elementAt(ii);
            if (a.equals(scene.name))
            {
                return scene;
            }
        }
        return null;
    }
    public Scene fetchCurrentScene()
    {
        return (fetchScene(currscene));
    }
    public void setCurrentScene(String name)
    {
        currscene = new String(name);
    }
    public String getCurrentScene()
    {
        return(currscene);
    }
    public Vector getSceneSprites(String sceneName)
    {
        Vector local = new Vector();
        Sprite temp = null;
        for (int ii = 0; ii < sprites.size(); ii++)
        {
            temp = (Sprite)sprites.elementAt(ii);
            if (temp.scenename.equals(sceneName))
            {
                local.addElement(temp);
            }
        }
        return local;
    }
    public Vector getCurrentSprites()
    {
        return getSceneSprites(currscene);
    }
    public Vector getAllSprites()
    {
        return sprites;
    }
    public Sprite getSpriteByName(String name)
    {
        Sprite temp;
        for (int ii = 0; ii < sprites.size(); ii++)
        {
            temp = (Sprite)sprites.elementAt(ii);
            if (temp.getName().equals(name))
            {
                return(temp);
            }
        }
        return null;
    }
}

The Scene and Zone classes

The Scene and Zone classes. The comments say it all. The Scene is the equivalent of the "Room" in adventure-speak.
I can see a future need for a method that changes the destination of a zone. It would be of the form - change the destination of the nth zone in the scene which points to scene A to scene B (the normal value of n would be zero - i.e. the only zone).

// Scene class - this is the background to a scene and includes:
// the Zone class - a Zone is a rectangular area within a scene, 
// usually for the purpose of enabling the player to click at
// a portion of the scene in order to move to another scene.

import java.util.Vector;
import java.awt.*;
public class Scene extends Object
{
    public String name;       // Text name of scene        
    public String imagename;  // image file name for scene
    public String songname;   // text song name
    private Vector zones;     // list of zones within the scene
    
    // Zone Class
    public class Zone extends Object
    {
        public Rectangle rect;       // extent of zone
        public String destination;   // text name of destination scene
        public int cursor;           // cursor to display while in zone
        public boolean cursoron;     // whether cursor displays
        public Zone(Rectangle r, String d)
        {
            rect = new Rectangle(r);
            destination = new String(d);
            cursoron = false;
        }
        public Zone(int x, int y, int w, int h, String d, int Cursor)
        {
            rect = new Rectangle(x, y, w, h);
            destination = new String(d);
            cursor = Cursor;
            cursoron = true;
        }
        public boolean inZone(int x, int y)
        {
            if (rect.contains(x, y))
                return true;
            return false;
        }
    }
    public Scene(String n, String in)
    {
        name = new String(n);
        imagename = new String(in);
        zones = new Vector();
        songname = new String("");
    }
    public Scene(String n, String in, String song)
    {
        name = new String(n);
        imagename = new String(in);
        zones = new Vector();
        songname = new String(song);
    }
    public void addZone(int x, int y, int w, int h, String d, int e)
    {
        Zone z = new Zone(x, y, w, h, d, e);
        zones.addElement(z);
    }
    public String getDest(int x, int y)
    {
        int ii;
        Zone tz;
        if (zones == null) 
            return null;
        for (ii = 0; ii < zones.size(); ii++)
        {
            tz = (Zone)zones.elementAt(ii);
            if (tz.inZone(x, y))
                return tz.destination;
        }
        return null;
    }
    public int getZoneCursor(int x, int y)
    {
        int ii;
        Zone tz;
        if (zones == null) 
            return -1;
        for (ii = 0; ii < zones.size(); ii++)
        {
            tz = (Zone)zones.elementAt(ii);
            if (tz.inZone(x, y) && tz.cursoron)
                return tz.cursor;
        }
        return -1;
    }
}

RippleA - rippling water sprite

Here is RippleA, intended to simulate rippling water. It can be seen on the first page of the sample code.

It uses the Sprite.increment() method to change the image at any given time.

It isn't very realistic - perhaps a slower (setCommonTime())

public class RippleA extends Sprite
{
    public RippleA(String spriteName, String Scenename)
    {
        super(spriteName, Scenename, "ripplea.jpg", MULTIPLE, 
           4, UNMOVING, NOACTION);
        setCommonTime(1);
        setPosition(0, 360);
        setSize(640, 120);
    }
    public void tick(long ticks, int mousex, int mousey)
    {
        super.increment(ticks);
    }
}

The Zilch sprite

Zilch is a sprite which is invisible and only serves to detect hits in the part of a scene in which it has been placed. There is an example of this in the original game where the keyhole of the door is covered by a Zilch to enable the audio clip when the gold key hits the keyhole.

public class Zilch extends Sprite
{
    public Zilch(String spriteName, String Scenename)
    {
        super(spriteName, Scenename, "zilch.gif", SINGLE, 
            1, UNMOVING, NOACTION);
        setSize(50,50);
    }
}

The Gull sprite

Another sprite, the gull, which is treated differently from a gettable sprite like the key. It moves in a sort of spiral, using its "phase" to decide where it is on its circle, and in choosing a suitable frame. The phase has 96 possible values and deflect is used to determine the x position with respect to start. Meanwhile, the y position just goes up and down in a vertical range. If you look at the sample game, you will see how they smoothly pass over the scenery and even over each other.

There is a certain jerkiness in the animation of the Gull at certain phases - it is not refected in the smooth animation of the animated gif (see right). I think it probably has to do with the calculation of position versus phase and may be improved with a different set of deflections. It is a subject worth revisiting.

Several GullA sprites can coexist; they simply require different start posiitions and phases.

They don't require save and restore code, because they are restored as part of scenery restoration.

import java.awt.Cursor;
import java.awt.Rectangle;
public class GullA extends Sprite
{
    int [] deflect = {70, 70, 69, 68, 67, 66, 64, 62, 59,
        57, 54, 50, 47, 43, 39, 35, 31, 27, 23, 19, 15, 10, 5, 0};
    boolean up;
    private int startx, starty, phase;
    private final int MAXPHASE = 96;
    public GullA(String spriteName, String Scenename, int StartX, int StartY, int Phase)
    {
        super(spriteName, Scenename, "gull.gif", MULTIPLE, 
            24, UNMOVING, NOACTION);
        startx = StartX;
        starty = StartY;
        phase = Phase;
        setPosition(startx+640, starty);
        setSize(28, 27);
        up = false;
    }
    public void tick(long ticks, int mousex, int mousey)
    {
        int coeff = 0;
        increment(ticks);
        phase += 1;
        if (phase >= MAXPHASE) phase = 0;
        setFrame(phase/4);
        Rectangle r = getExtent();
        if (phase < 24) coeff = deflect[phase];
        if ((phase > 23) && (phase < 48))
        {
            coeff = -deflect[47-phase];
        }
        if ((phase > 47) && (phase < 72))
        {
            coeff = -deflect[phase - 48];
        }
        if ((phase > 71) && (phase < 96))
        {
            coeff = deflect[95-phase];
        }
        r.x = startx + coeff;
        if (r.y < 28) up = false;
        if (r.y > 250) up = true;
        if (up)
            r.y -= 1;
        else 
            r.y += 1;
        setPosition(r.x, r.y);
     }
}

The Gold Key sprite

This is an example of a gettable sprite. All it really has is its initialisation, most of which it inherits from the Sprite class, and the save and restore code.

I can't help feeling that a lot of the save and restore stuff could be in the parent class too for movable / gettable sprites.

import java.util.Vector;
import java.awt.Point;
public class GoldKey extends Sprite
{
    public GoldKey(String spriteName, String Scenename)
    {
        super(spriteName, Scenename, "goldk.gif", MULTIPLE, 
            2, GETTABLE, NOACTION);
        setPosition(100, 400);
        setSize(40, 20);
        addValidDrop("inventory", -1, -1);
        addValidDrop("dock", 100, 400);
    }
    public String saveMe()
    {
        String mysave = getSavePrefix();
        mysave = mysave.concat("[" + scenename + "]");
        mysave = mysave.concat(posSave());
        mysave = mysave.concat(gotSave());
        mysave = mysave.concat(">");
        return mysave;
    }
    public boolean restoreMe(String restoreString)
    {
        String search = getRestoreContent(restoreString);
        int start = search.indexOf("[");
        if (start != -1)
        {
            start +=1;
            int end = search.indexOf("]", start);
            if (end != -1)
            {
                scenename = search.substring(start, end);
                start = search.indexOf("[X", end);
                end = search.indexOf("]", start);
                Point p = posRestore(search.substring(start, end+1));
                setPosition(p.x, p.y);
                if (search.indexOf("[NOTGOT]") != -1)
                {
                    if (dropSprite(scenename))
                    {
                        return true;
                    }
                }
                else if (search.indexOf("[GOT]") != -1)
                {
                    getSprite();
                }
            }
        }
    return false;
    }
}

The Sprite Class

Creatively speaking, the sprites (a term stolen from early video games) constitute the interest in the game, against which the backgrounds can be viewed as mere scenery. So I have defined a class, called (unsurprisingly) Sprite, from which all sprites descend. A sprite is an item that is superimposed on the background of a scene. It may be able to be carried by the player, it may move on its own account, like the birds in the example game. It may be a piece of the scenery that can be manipulated by the player. It may be invisible, and have no image, but only an extent. Contact between player cursor and sprite and between sprite and sprite can be detected. A sprite can even be invisible (strictly, transparent). Each sprite is associated with one or more image files to give it one or more representations and/or animations. The parent Sprite class includes a number of variables common to all sprites and a number of default methods that can be overridden in Sprite's descendant classes.
Here is the basic sprite class.

import java.util.Vector;
import java.awt.*;
import java.applet.*;

public class Sprite extends Object
{
    // Statics
    public static final int UNMOVING = 0; // Never relocates
    public static final int MOVING = 1; // Can relocate (move() function)
    public static final int GETTABLE = 2; // Can be picked up 
    public static final int NOACTION = 0; // Unresponsive to mouse
    public static final int ACTIVE = 1; // Responsive to mouse (act() function)
    public static final int SINGLE = 0; // Single image file (furniture)
    public static final int MULTIPLE = 1; // Multiple numbered files
    public static final int AGIF = 2; // Animated Gif 
    public static final int NOANIM = -1; // No Animation


    // Static-ish - set up at Constructor 
    private String spritename;
    private String basefile;
    private String suffix;
    private String currimage;
    private int filetype;
    private int noframes;
    private int movetype;
    private int actiontype;
    // Parametrable-Static defaulted at Constructor but alterable
    private int scale;
    private int priority;
    private int frametimes[];
    private boolean got;
    private Vector images;
    private Vector audioclips;
    // For gettable sprites
    public Vector validscenes;
    public Vector positions;

    // Immediate
    public String scenename;
    public int cursor;
    public boolean cursoron; 
    private int frame;
    private long prevtick;
    private Rectangle extent;
 
    // Maximum constructor for a Sprite
    public Sprite(String spriteName, String sceneName, String fileName, int fileType, 
        int noOfFrames, int moveType, int actionType)
    {
        // text name of sprite 
        spritename = new String(spriteName);
        // text name of 'home' scene
        scenename = new String(sceneName);
        // text name of image file(s)
        basefile = new String(fileName);
        int c = basefile.indexOf('.');
        suffix = new String(basefile.substring(c));
        basefile = new String(basefile.substring(0, c));
        // file type single, multiple or animated gif
        // (animated gif not yet implemented)
        filetype = fileType;
        // number of image frames in the sprite set
        noframes = noOfFrames;
        // movement type (can it relocate?)
        movetype = moveType;
        // action type (whether responsive to mouse)
        actiontype = actionType;
        // the images can be scaled for perpective etc.
        scale = 100;
        // priority determines which sprite is drawn first
        priority = 1;
        // enables variable speed animation 
        frametimes = new int[noOfFrames];
        // set all the frame times to 'no animation'
        setCommonTime(NOANIM);
        // x pos, y pos, width, height
        extent = new Rectangle(0, 0, 0, 0);
        // for special cursor 
        cursoron = false;
        // whether being carried 
        got = false;
        // for Gettable sprites
        validscenes = new Vector();
        positions = new Vector();
        // ?caches for images and audio clips 
        images = new Vector();
        audioclips = new Vector();
        // specify which sprite image to use
        setFrame(0);
        addCursor(Cursor.DEFAULT_CURSOR);
    }
    public void addAudio(int serial, AudioClip au)
    {
        audioclips.insertElementAt(au, serial);
    }
    public AudioClip getAudio(int serial)
    {
        AudioClip au = (AudioClip)audioclips.elementAt(serial);
        return au;
    }
    public void addImage(int serial, Image im)
    {
        images.insertElementAt(im, serial);
    }
    public Image getImage(int serial)
    {
        Image im = (Image)images.elementAt(serial);
        return im;
    }
    public Image getCurrentImage()
    {
        Image im = getImage(frame);
        return im;
    }
    public void relocate(String sceneName)
    {
        scenename = sceneName;
    }
    // USUALLY OVERRIDDEN EXCEPT FOR NON-ANIMATED GETTABLE ITEMS
    public void tick(long ticks, int mousex, int mousey)
    {
        prevtick = ticks;
        if (got)
       {
            // displace Sprite from carrying cursor
//***perhaps make displacement parametrable***
            setPosition(mousex+30, mousey+30);
        }
    }
    // Usual call for animated  sprites at tick()
    public void increment(long ticks)
    {
        if ((ticks - prevtick) >= frametimes[frame])
        {
            setFrame(frame+1);
            prevtick = ticks;
        }
    }
//*** rather suspicious of this ***
    public int setPriority(int pr)
    {
        if (priority > 0)
            priority = pr;
        return priority;
    }
    public int setScale(int sc)
    {
        if ((sc > 0) && (sc <= 100))
            scale = sc;
        return scale;
    }
    // Set all the frame times to a single value
    public void setCommonTime(int frt)
    {
        for(int ii = 0; ii < noframes; ii++)
        {
            frametimes[ii] = frt;
        }
    }
    // Set the position
    public void setPosition(int X, int Y)
    {
        extent.x = X;
        extent.y = Y;
    }
    // Set the size
    public void setSize(int X, int Y)
    {
        extent.width = X;
        extent.height = Y;
    }
    // Get the extent
    public Rectangle getExtent()
    {
        return extent;
    }
    // Set the current Frame
    public void setFrame(int frameNo)
    {
         if (frameNo < 0) 
        {
            frame = noframes-1;
        }
        else if (frameNo >= noframes) 
        {
            frame = 0;
        }
        else 
        {
            frame = frameNo;
        }
//*** Not sure this is sensible if we're cacheing images ***
        Integer x = new Integer(frame+1000);
        String ser = new String(x.toString());
        currimage = new String(basefile +
            ser.substring(1) + suffix);
    }
    public int getFrame()
    {
        return frame;
    }
    public String getCurrentImageName()
    {
        return currimage;
    }
    public String getName()
    {
        return spritename;
    }
    public Vector getAllFilenames()
    {
        Vector vec = new Vector();
        for (int ii = 0; ii < noframes; ii++)
        {
            Integer x = new Integer(ii+1000);
            String ser = new String(x.toString());
            String sb = new String(basefile + 
                ser.substring(1) + suffix);
            vec.addElement(sb);
        }
        return vec;
    }
    public void addCursor(int c)
    {
        cursor = c;
        cursoron = true;
    }
    public void removeCursor()
    {
        cursoron = false;
    }
 
// All the Gettable stuff
    public void getSprite()
    {
        if (movetype == GETTABLE)
        {
            got = true;
//*** Note when a sprite is being carried its image changes to image 1 ***
//*** I don't think there's any check on the range
            setFrame(1);
        }
    }
    public boolean isGettable()
    {
         if (movetype == GETTABLE)
        {
            return true;
        }
        return false;
    }
    public boolean isGot()
    {
        if (got)
            return true;
        return false;
    }
// Overridden if a click is significant 
    public boolean hitBy(String hitter)
    {
        return false;
    }
    public boolean dropSprite(String Scenename)
    {
        if (got)
        {
            for(int ii = 0; ii < validscenes.size(); ii++)
            {
                String scene =
                    (String)validscenes.elementAt(ii);
                if (scene.equals(Scenename))
               {
                    got = false;
                    Point point = 
                        (Point)positions.elementAt(ii);
                    // -1 means anywhere - inventory page etc.
                    if (point.x != -1)
                        setPosition(point.x, point.y);
                    setFrame(0);
                    return true;
                }
            }
        }
        return false; 
    }
    public void addValidDrop(String scene, int xpos, int ypos)
    {
        validscenes.addElement(scene);
        Point point = new Point(xpos, ypos);
        positions.addElement(point);
    }
    public boolean isHit(int hitx, int hity)
    {
        if (extent.contains(hitx, hity))
        {
            return true;
        }
        return false;
    }
    // overriden for Sprites about which saving/restoring has 
    // some relevance other than position 
    public String saveMe()
    {
        return null;
    }
    public boolean restoreMe(String savestring)
    {
        return true;
    }
    // used by Sprites which saveMe()
    public String getSavePrefix()
    {
        String saver = new String(spritename + "<");
        return(saver);
    }
    public String gotSave()
    {
        if (this.isGot())
        {
            return ("[GOT]");
        }
        else
        {
             return ("[NOTGOT]");
        }
    }
//*** I wonder if this causes trouble on restore when it's got ***
//*** There is a situation where a gettable sprite is marooned on restore
    public String posSave()
    {
        Integer X = new Integer(extent.x);
        Integer Y = new Integer(extent.y);
        String saver = new String("[X" + X.toString() 
             + "Y" + Y.toString() + "]");
        return saver;
    }
    public Point posRestore(String restoreString)
    {
        int X, Y;
        X = 0;
        Y = 0;
        int start = restoreString.indexOf("[X");
        int end = restoreString.indexOf("Y", start);
        if ((start != -1)&&(end != -1))
        {
            String temp = 
                restoreString.substring(start+2, end);
            try
            {
                X = Integer.parseInt(temp);
            }
            catch (NumberFormatException e)
            {
                X = 0;
            }
            start=end + 1;
            end = restoreString.indexOf("]", start);
            if (end != -1)
            {
                temp = restoreString.substring(start, end);
                try
                {
                      Y = Integer.parseInt(temp);
                }
                catch (NumberFormatException e)
                {
                    Y = 0;
                }
            }       
        }
        Point p = new Point(X, Y);
        return p;
    }
    public String getRestoreContent(String restoreString)
    {
        String search = getSavePrefix();
        int start = restoreString.indexOf(search);
        if (start != -1)
        {
            start += search.length();
            int end = restoreString.indexOf(">", start);
            if (end != -1)
            {
                search = restoreString.substring(start, end);
                return search;
            }
        }
        return null;
    }
}

There are definitely some areas for expansion, modification and improvement here, despite the fact that it largely works already. In particular, the areas marked with //*** will reward further study.

The Save / Restore and Mouse actions

Today, we complete Bridge.java with the Save and Restore processes, and the Mouse actions.

Only one save is stored, in a cookie, by the Javascript shell. Whatever state has most recently been saved can be restored as many times as desired.

The static state of the game does not vary much. The state of play is largely determined by the positions of all the sprites. Each sprite is requested to supply its save data.

    /* The save process is done in three stages, to prevent
        deadly embrace and similar problems with the HTML/Javascript and
        the applet.
    
        First, the Javascript sets a saveFlag.  Then, when the code is at a good
        stage to do the save, the actual save data is built. Finally, every
        few seconds, the Javascript checks for a save string in the applet.
        Normally this returns an empty string, but in this case it returns
        the save data.    */
    
    // Called from Javascript
    public void doSave()
    {
        showStatus("doSave"); // gil temp
        saveFlag = true;
    }
    // Called from Javascript
    public String getSave()
    {
        String newsave = new String(saveString);
        showStatus("getSave" + newsave); // gil temp
        saveString = new String("");
        return newsave;
    }
    // Called from tick()
    public String saveGame()
    {
        String save;
        String chunk;
        save = new String("game");
        save = save.concat("currscene<"+currscene+">");
        save = save.concat("popscene<"+popscene+">");
        save = save.concat("songname<"+songName+">");
        Vector slist = bridgedata.getAllSprites();
        for (int ii = 0; ii< slist.size(); ii++) 
        {
            Sprite sprite = (Sprite)slist.elementAt(ii);
            chunk = sprite.saveMe();
            if (chunk != null)
                save = save.concat(chunk);
        }
        return save;
    }

In a similar way to the Save process, game restore takes place as a result of a flag set by Javascript and a subsequent detection of that flag in the tick() method.

    // Called from Javascript
    public void doRestore(String restoredata)
    {
        showStatus("doRestore" + restoredata); // gil temp
        restoreFlag = true;
        restoreData = new String(restoredata);
    }
    // Called from tick()
    public boolean restoreGame(String restore)
    {
        int start, end;
        String save;
        String chunk;
        String restscene;
        showStatus("restoreGame" + restore); // gil temp
        start = restore.indexOf("currscene<");
        end = restore.indexOf(">", start+10);
        if ((start == -1)||(end == -1)) return false;
        restscene = restore.substring(start+10, end);
        start = restore.indexOf("popscene<", end);
        end = restore.indexOf(">", start+9);
        if ((start == -1)||(end == -1)) return false;
        popscene = restore.substring(start+9, end);
        start = restore.indexOf("songname<", end);
        end = restore.indexOf(">", start+9);
        if ((start == -1)||(end == -1)) return false;
        songName = restore.substring(start+9, end);
        Vector slist = bridgedata.getAllSprites();
        for (int ii = 0; ii< slist.size(); ii++) 
        {
            Sprite sprite = (Sprite)slist.elementAt(ii);
            sprite.restoreMe(restore.substring(end));
            if (sprite.isGot())
            {
                isHolding = sprite;
            }
        }
        currscene = changeScene("wait");
        thisscene = bridgedata.fetchCurrentScene();
        displaymanager.refresh(getGraphics());
        currscene = changeScene(restscene);
        thisscene = bridgedata.fetchCurrentScene();
        return true;
    }

Finally, in the Bridge Applet, we get to the Mouse control area.
There are four basic tasks for a click.

• If the mouse is clicked in a scene change zone, the scene is changed.
• If a sprite is being held, and it is clicked on another sprite, then a collision may be detected and acted upon.
• If a double click is made, a sprite may be taken or dropped.
• If the click is made on a sprite without a held sprite, that counts as a collision and may result in an action.

    // Find out where the mouse is.
    public void mouseMoved(MouseEvent e) 
    {
    mousex = e.getX();
    mousey = e.getY();
    }
    // What happens on mouse click
    public void mouseClicked(MouseEvent e) 
    {
        Vector slist = bridgedata.getSceneSprites(currscene);
        int multi = e.getClickCount();        
        String dest = thisscene.getDest(e.getX(), e.getY());
        // Zone click takes priority
        if (dest != null)
        {
            if (dest.equals(""))
            {
                if (popscene != null)
                {
                    dest = popscene;
                }
            }
    // Wait process
            Scene waitscene = bridgedata.fetchScene("wait");
            waitscene.songname = songName;
            currscene = changeScene("wait");
            thisscene = bridgedata.fetchCurrentScene();
            displaymanager.refresh(getGraphics());
            currscene = changeScene(dest);
            thisscene = bridgedata.fetchCurrentScene();
        }
        // Click one sprite with another
        else if (isHolding != null)
        {
            for (int ii = 0; ii< slist.size(); ii++) 
            {
                Sprite sprite = (Sprite)slist.elementAt(ii);
                if (!sprite.getName().equals(isHolding.getName()))
                {
                    if (sprite.isHit(mousex, mousey))
                    {
                        bridgedata.collide(sprite.getName(),isHolding.getName());
                    }
                }
            }
        }
        
        // Pick up sprite
        if (multi >= 2)
            // Double Click behaviour
        {
            if (isHolding != null)
            {
                boolean success = isHolding.dropSprite(currscene);
                if (success)
                {
                    isHolding = null;
                }
            }
            else
            {
                for (int ii = 0; ii< slist.size(); ii++) 
                {
                    Sprite sprite = (Sprite)slist.elementAt(ii);
                    if (sprite.isGettable())
                    {
                        if (sprite.isHit(mousex, mousey))
                        {
                            sprite.getSprite();
                            isHolding = sprite;
                        }
                    }
                }
            }
        }
        // Click a sprite when not holding
        else
        {
            for (int ii = 0; ii< slist.size(); ii++) 
            {
                Sprite sprite = (Sprite)slist.elementAt(ii);
                if (sprite.isHit(mousex, mousey))
                {
                    bridgedata.collide(sprite.getName(),null);
                }
            }
        }
    }
    public void mouseDragged(MouseEvent e) 
    {
    }
    public void mousePressed(MouseEvent e) 
    {
    }
    public void mouseReleased(MouseEvent e) 
    {
    }
    public void mouseEntered(MouseEvent e) 
    {
    }
    public void mouseExited(MouseEvent e) 
    {
    }
}
//End of Bridge

The Bridge Applet - Part 3

Now we come to the changeScene function.

• It makes sure this is a valid scene name;
  
• If the player is carrying anything, it relocates the object in the new scene;
  
• Displays the hourglass cursor;
  
• Fetches the image for the new scene and all the sprite images;
  
• Tells bridgedata and displaymanager about it;
  
• Flags a song change.

I don't understand the comment which appears to imply that time is saved in subsequent visits to this scene because the data is cached. It looks as though the sprite images are remembered during a scene, but if the same sprite is encountered in a subsequent screen its data is reloaded. Having thought all the way round this, I conclude it's the best strategy. But the way it's implemented is silly, isn't it?

    // This function collects the scene and any sprites
    // It also reads in the Images for the background and Sprites
    // this time only. Once the scene changes, the images are assumed to be 
    // present.
    // Returns the scene name.
    public String changeScene(String sceneName)
    {
        Scene scene = bridgedata.fetchScene(sceneName);
        if (scene == null)
        {
            showStatus("No such scene:" + sceneName);
            return currscene;
        }
        // Deal with any carried items
        if (isHolding != null)
        {
            isHolding.relocate(sceneName);
        }
        currCursor = Cursor.WAIT_CURSOR;
        setCursor(Cursor.getPredefinedCursor(currCursor));
        MediaTracker tracker= new java.awt.MediaTracker(this);
        URL address = getCurrentUrl("images/"+scene.imagename);
        backcloth = getImage(address);
        tracker.addImage(backcloth, 0);
        Vector slist = bridgedata.getSceneSprites(sceneName);
        int serial = 1;
        for (int ii = 0; ii< slist.size(); ii++) 
        {
            Sprite sprite = (Sprite)slist.elementAt(ii);
            Vector sfnames = sprite.getAllFilenames();
            for (int jj = 0; jj < sfnames.size(); jj++)
            {
                String fn = (String)sfnames.elementAt(jj);
                URL addr = getCurrentUrl("images/"+ fn);
                Image im = getImage(addr);
                tracker.addImage(im, serial++);                
            }
        }
        try
        {
            tracker.waitForAll();
        }
        catch (InterruptedException e)
        {
            showStatus("Scene Load Media Tracker Interrupted");
        }
        // cache images with sprite        
        for (int ii = 0; ii< slist.size(); ii++) 
        {
            Sprite sprite = (Sprite)slist.elementAt(ii);
            Vector sfnames = sprite.getAllFilenames();
            for (int jj = 0; jj < sfnames.size(); jj++)
            {
                String fn = (String)sfnames.elementAt(jj);
                URL addr = getCurrentUrl("images/"+ fn);
                Image im = getImage(addr);
                sprite.addImage(jj, im);                
            }
        }
        currCursor = Cursor.DEFAULT_CURSOR;
        setCursor(Cursor.getPredefinedCursor(currCursor));

        bridgedata.setCurrentScene(sceneName);
        displaymanager.setBackground(backcloth);
        songName = scene.songname;
        songFlag = true;
        return sceneName;
    }

Straightforward function to create absolute url from relative url.

    // Form url from relative string and base
    URL getCurrentUrl(String relative)
    {
        String urlstr = codebasestr.concat(relative);
        try
        {
            URL urlurl = new URL(urlstr);
            return urlurl;
        }
        catch (MalformedURLException e)
        {
            showStatus("Error" + urlstr);
        }
        return null;
    }

Here is the function that is called by Javascript when the Inventory button is clicked. It sets a flag to request a scene change to the Inventory.

I remarked earlier that a change to Inventory ought not to take place if the current scene is already Inventory. I could duplicate this test here.

    // Called from Javascript
    public void goInv()
    {
        showStatus("goInv");  // gil temp
        if (!currscene.equals("inventory")) invFlag = true;
    }

    // Called from Javascript
    public String checkSong()
    {
        String noSong = new String("none");
        showStatus("checkSong");  // gil temp
        if (songFlag)
        {
            songFlag = false;
            return(songName);
        }
        return(noSong);
    }

A Little Pause

I've stopped the flow of Java code while I cogitate over a few things, and consult references. I had to fetch all my old Java books out of the garage attic, and one thing led to another.

As a result, it seems that I will implement music via a Java-driven mp3 player thread, rather than the rather lame MIDI implementation in Javascript.

I am also torn about the possibility of cacheing images rather than downloading them every time. This is such a difficult one, I've got to contemplate the consequences.

Update(), Paint(), tick and the TickTimer Thread

The (Container) method update() may be called, and the default action includes background clearance. We override this to call just the DisplayManager.paint() function.

    // Bridge.update() is called when repaint() has been suggested
    public void update(Graphics g)
    {
        displaymanager.paint(g);
    }

Another overridden Container method

    // Bridge.paint() is called when a complete refresh is necessary
    public void paint(Graphics g)
    {
        displaymanager.refresh(g);
    }

This is the tick() function, the heartbeat of the applet. This is aimed to be called every nth of a second, and all the sprites and the cursor are dealt with.

I'm not sure about dodging out altogether if cursor is in WAIT state.

If the current scene is already inventory, we should ignore an inventory request.

The zone cursor selection should take place before the sprite cursor selection, surely.

    public void tick()
    {
        int thisCursor;
        // If the current cursor is "hourglass", do nothing
        if (currCursor == Cursor.WAIT_CURSOR) return;
        // Check for flags from Javascript
        if (invFlag)
        {
            invFlag = false;
            popscene = currscene;
            currscene = changeScene("inventory");
            thisscene = bridgedata.fetchCurrentScene();
        }
        if (saveFlag)
        {
            saveFlag = false;
            saveString = saveGame();
        }
        if (restoreFlag)
        {
            restoreFlag = false;
            restoreGame(restoreData);
        }
        thisCursor = Cursor.DEFAULT_CURSOR;
        Vector slist = bridgedata.getCurrentSprites();
        for (int ii=0; ii < slist.size(); ii++)
        {
            // get all the sprites
            Sprite sprite = (Sprite)slist.elementAt(ii);
            // tick them
            sprite.tick(ticks, mousex, mousey);
            // cursor them
            if (sprite.cursoron)
            {
                Rectangle r = sprite.getExtent();
                if (r.contains(mousex, mousey))
                {
                    thisCursor = sprite.cursor;
                }
            }
        }
        int zc = thisscene.getZoneCursor(mousex, mousey);
        if (zc != -1)
        {
            thisCursor = zc;
        }
        if ((thisCursor != currCursor) && (currCursor != Cursor.WAIT_CURSOR))
        {
            currCursor = thisCursor;
            setCursor(Cursor.getPredefinedCursor(currCursor));
        }
        repaint();
    }

Ticktimer runs as a separate thread, attempting to call tick() n times a second. It uses System time in milliseconds. If it misses any ticks, it figures out how many ticks it has missed and increments the variable ticks accordingly. Some activities, especially sprite movement, care that the ticks have jumped, others just ignore it.

    class Ticktimer extends Thread
    {
        private long interval;
        public void run()
        {
            while (true)
            {
                timenow = System.currentTimeMillis();
                interval = timenow-timewas;
                if (interval > FRACTION)
                {
                    interval /= FRACTION;
                    ticks += interval;
                    timewas += (interval*FRACTION);
                    tick();
                }
                try
                {
                    sleep(((FRACTION-1)>0)?(FRACTION-1):(1));
                }
                catch(InterruptedException e)
                {
                    return;
                }
            }
        }
    }

Bridge Part 2 - init() start() stop()

Here's the init() function, called by the browser or applet viewer to inform this applet that it has been loaded into the system.

    public void init()
    {
        // Establish the path (URL) of the applet itself
        codebasestr = getCodeBase().toString();
        // Clear the area into which Save data will be copied
        saveString = new String("");
        // Clear the Save flag
        saveFlag = false;
        // Clear the item that indicates a Sprite is being held by the player
        isHolding = null;
        // Set up a class instance for the scene data
        bridgedata = new BridgeData(this);
        // Set up class instances for display stuff
        dirtyrectset = new DirtyRectSet();
        displaymanager = new DisplayManager(this);
        // No music right now
        songFlag = false;
        // Set the initial scene 
        currscene = changeScene(bridgedata.startup); // returns scene name
        thisscene = bridgedata.fetchCurrentScene();  // returns scene class instance
        // Initialise the loop timer
        timerRunning = false;
        ticks=0;
        // Set Mouse interrupt functions
        addMouseMotionListener(this);
        addMouseListener(this);
        // No inventory entry now
        invFlag = false;
    }

The start() function, called by the browser or applet viewer to inform this applet that it should start its execution. start() and stop() may be called repeatedly during the applet's existence as the page it is on drops out of focus etc. All we do here is to start the timer if it is stopped, and to create a new timer if there isn't one already. This means we can halt operation and restart, effectively freezing the game time. I'm not sure we should call timer.start() unless we have just created it.

    public void start()
    {
        if (!timerRunning)
        {
            ticks++;
            timewas = timenow = System.currentTimeMillis();
            timerRunning = true;
            if (timer == null)
            {
                timer = new Ticktimer();
            }
        }
        timer.start();
    }

The stop() function, called by the browser or applet viewer to inform this applet that it should stop its execution. It is called when the Web page that contains this applet has been replaced by another page, and also just before the applet is to be destroyed. Apparently it isn't safe to stop() a timer, so we just flag it as suspended. I think we ought to check this flag in the tick() function or in the ticktimer, which we don't currently do, otherwise ticks will just keep going ad infinitum even if we wanted the timer to freeze.

    public void stop()
    {
        timerRunning = false;
    }