Furniture Sprites

Started implementing Furniture sprites, discovering, incidentally, that if a sprite's image cannot be found, Jade crashes. Must fix that.

Though Furniture sprites are INACTIVE (i.e. don't react to touch or collision), they sometimes have to be moved to and from Limbo, so their 'home' scene and location are remembered. Initially, I set up special variables to remember these, but it occurs to me that I could use a single Dropzone for the purpose. Saves coding.

Re: Switches, Conditional Scenes and Use of Inventory

Switches:

I had thought I might have to implement a new class - Switches - to enable recognition of new conditions (e.g. Rocket already fired) and to give a handle to Save and Restart. However, I am now sure that Sprites themselves will be sufficient, either by detecting the the presence or position of a Sprite, or by creating a Zombie Sprite whose Position data can be used to indicate a state. The Zombie would be saved and restored like a carryable or movable Sprite. The Zombies would be in the Limbo scene (which is unreachable by players), and would never need to be drawn in real play, though inspection by developers of the Limbo scene would aid debugging..

Conditional Scenes:

I have now implemented  a function in JadeData that inspects every destination scene before a scene switch, and changes the destination scene according to current game conditions.

Use of Inventory

Hitherto, if a carried sprite was dropped, and there was no specific dropzone on that scene, it was dropped into Inventory. I'm changing this so that Inventory drops only occur if there's a specific location in Inventory specified in the sprite dropzones. Otherwise, no drop will take place.

A Few More Topics

Coding:

• Background transitions: It should be easy to slide one background over another, one doDraw() at a time.
• Sprite scale, flip and mirror: Must do some experiments with this, but it looks as if a single bitmapFactory call with a suitable matrix could do the whole modification on a Sprite  image.
• onPause and onResume: A save string could be attached to the Bundle, just to restore the current state. The deliberate saves (by User) would use the same save string format, but stored in a local file.

Game:

• Lighting the Rocket: A candle in a cave.

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 

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.

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.

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.

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.

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.