Another Aide-Memoire Post

Now Spring is here, I find any free time gets gobbled up by gardening, repairs, golf and other chores. The trouble is that, though programming progresses steadily, images take lots of time.

However, there is an upside to tedious activities, namely that I can think about Jade while I'm doing them. Unfortunately, many of my most brilliant thoughts tend to vanish before I get time to implement, or even record them. So, I've taken to scribbling these gems of wisdom on any convenient sheet of paper or cardboard, and I'm getting them down in writing before they get rained upon.

Additional images required:

Junk:

• Stationary - no sails, Animated - raise sails - May be the same view from junkhie
• Moving off - May be the same animation varied only by size
• Seen from sea level

Rocket (from junkhie):

• Lift off
• Graceful parabola

Furniture:

• More furniture for views from junk (distant junks, gulls, already provided). Perhaps purloin scenes from the Povray library
• A few oddments for the interior/deck of junk
• Arrows on pylons (no need for binoculars in close-ups - use a single background and bounce)

New Uploads

I've uploaded the latest versions of the game (jade.apk) and the Java source (jade.zip) to the code repository for the project

Let me have any feedback on the game you care to send me.

Some of the style of the Java code is, I confess, rather untidy. It's been through quite a number of different generations of compilers and build engines since its first origination in 1993, and I'm tidying it up as I go along.

Android Studio: Don't do it this way, do it that way.
Me: Oh, get a grip. It works, doesn't it?

Timing of the Loop

The animation problem represented by the rocket (mentioned in the previous post) led me to start tinkering with the Ticktimer() thread. In particular, the amount of sleep() I give it. Allowing the timer less sleep (reducing from 80ms to 16ms) gave the animation a superb boost, and the jerky animation disappeared altogether. Of course, the emulator with debug (on PC with Android Studio) still moves pretty slowly, but running on a naked Android device is highly efficient.

Pretty soon, I'll have to implement a "disable touch response" system, so that the user can't do anything during an animation that has to run to completion.

Using a Rocket

Built a set of images for a runaway firework, but it didn't work so good, not because the images were wrong, but because the animation was extremely staccato and jerky.

Back to the drawing board...

Multiple Sprite Interaction

Found, and solved, a number of problems associated with swapping a pair of sprites as a result of interaction with a third. It was all to do with the sequence in which events took place, and was surprisingly complex. Now, it looks like a piece of cake, but it took me a whole day and some rearrangement of basic code to accomplish. Still, a nice challenge.

Problems with Conditions that Affect Multiple Sprites

Came across a problem today, concerning, really, the behaviour of one sprite dependent on another. This isn't something that can be resolved in the sprite's code, because no sprite is conscious of another sprite's existence i.e. it can't access another sprite's context. All such arbitration has to take place in the module that instantiated the two sprites.

The particular case is when the rocket launcher already has a rocket in it, and the user tries to put a second rocket in the launcher.

Later: The state of background sound off is not preserved over a Save Restore.

Later still: A new test version of Jade is available via the link in the left hand column.

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.

Rocket sprites

Built and tested the carryable rockets. Also need the 'dummy' rockets in the distant view. These will be 'furniture' sprites.
After long contemplation, decided that the furniture sprites, though they tend to be static, should also be MOVABLE, so they can be shoved into Limbo, as will happen with the dummy rockets. So probably type is an irrelevant attribute of Sprite, but I'll leave it there for the time being. The other attribute - GETTABLE, however, is significant, as is ACTIVE.

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.

Progress

Created a bunch of new scenes, all to do with the subterranean caves.

Now need to design the code to allow change of Exit as a result of user action. For example, if the candle is present, the cave backgrounds are illuminated, so the destination screen might be different. Or to have the junk present.  Also necessary to record the change so that a runtime save / restore can recreate the changes.

At the End of Another Long Gap

Since my last post - more than a year ago - matters have been largely stationary, due to an extended project with no connection to this, but which tied me up, with barely the time to do my Mythaxis business.

You haven't missed much. I made some performance improvements, added a cursor which follows the touch and stays where the last touch lifted. The major change happened after a painful time with Eclipse, on upgrading desktop hardware, then wifi problems, only finally resolved last week when when I migrated the project to Android Studio.

For a while last year, I was unable to work on povray because of remote accessibility, which I needed. So, I've moved onto the rocket cave in povray, and will be extending the game and the engine real soon now.