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.