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?

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.

Catch-up

What time I've spent on the project since November has been spent on Povray, which doesn't lend itself to blogging. But Christmas, another issue of Mythaxis, and a bit of home improvement took priority at various times. We now have a couple of animated junks, an advance on Rock design, and a cave.

On Jade code, plans are afoot to distinguish between animated and static images for the same sprite. Also, it's now clearer how to restore configurations which are changed as a result of user action. e.g. where zone destinations have been altered, or resources used up, or doors opened.

Composite Sprites (contd.)

Oh, and I might well have persevered with composite sprites had I not encountered the SAVE / RESTORE implications.

Composite Sprites

I was planning a new Class - a composite sprite - which would enable a number of sprites to be considered as a cluster which always moved together, but might have different schedules - e.g. a static main sprite, such as a boat, with animated bow wave, only when moving, and an animated flag which might wave or droop.

My first draft of this class quickly showed me the error of my ways, as the coordination of the multiple sub-sprites would be extremely difficult, due to scaling and flipping, for example. Especially scaling.

Unless.. the multiple subsprites were co-located - i.e. had the same position (which is a CENTRE position), even if this meant they had a lot of transparent content in them.

Once you do that, however, there's no longer any need for a composite class. You just mirror certain characteristics of the main sprite (position, scale etc.) on the subsprites, eliminating the need for a composite class.

Easier still, make the main sprite and the principal subsprite as a single sprite with all the necessary animations - say, the boat and its wake, and use a separate sub sprite for each of the other animations required.

So, long story short, no composite sprite class.

Another Idle Month

I've done no more on Jade in the last month - Real Life intervened.

I'm now ready to start setting up a more satisfactory demo version with some interesting action, so I'll be working in Povray a lot - a condition that isn't conducive to much reporting from me.

I'd like again to appeal to anyone who wants to collaborate on the Povray side. I'd be delighted to share the load and the credit with you.

Meanwhile, and this is the problem with me, I've seen another possible use of the Jade engine and I keep thinking about that instead of getting on with what I should be doing!

(below) Junk sprite with bluescreening.

Example Game

For the morbidly interested, I have uploaded the current Alpha version of Jade as Jade.apk, available from http://amazonsystems.phpzilla.net.

This is a "game" with just six scenes, and very little to do except pick up a candle and drop it, but the music and sound effects are there, and the options.

Try it if you dare. Actually it is very benign as alpha versions go. Other than its own running space and private data, it only uses the media player, and surrenders or pauses that whenever it loses focus.

It works for me on my Android Xoom, but I'm interested in the behaviour of other platforms.

From left to right the options are Quit, Restore, Save, Music On/Off, Inventory, Pause.

Double tap to pick up and drop the candle.

---

Sparing no expense, the source is also available at the same address.
http://amazonsystems.phpzilla.net

New Touch protocol in place

For once, it took more time to flowchart this than it did to implement it, but I can now reliably detect click, longpress and double click. I've changed to double click for for pick up and drop. It seems to cause less finger trouble.

The next activity is definitely the prototype game. I've got all the elements I need in the engine now, I think. I just have to use these capabilities to write an acceptable mini game.

I've been a little disappointed by the appearance of some of my backgrounds on the Xoom. I'll experiment with less compressed jpg files.

A Hesitation

I must get on with a new edition of Mythaxis, so I'm pausing a while.

I still have to sort out Music/Sound Effects. I'm also uncomfortable with the feel of long press as I've implemented it, so I'll have another go at that when I return.

Music Design Unsuccessful

Well, my sound implementation was not a great success. Some of it worked, some didn't, despite close monitoring on debug that the right things were being called with the right parameters. Specifically, setLoop didn't seem to work, nor did pause nor autopause. Most of the problems were with the background music and ambience sounds. The simple sound effects were fine.

I note a lot of such mysterious problems on Stackoverflow, and I may change policy here.

Also, I think it should have been a class rather than a method, and I'll re-write it like that. I may also have to use the MediaPlayer for longer music and the Soundpool just for immediate sound effects. We'll see. MediaPlayer is facility-rich, but seems rather complex to use.

Music Design Revised

There was no need for a separate thread to do the music. Once the sounds are loaded, it's a low usage thing, and I'll call it with the ticks.

Some Progress and a Design for Music and SFX

The Progress:
I realised I hadn't accounted for save and restore of holdable items. If it's already held, then all we need remember is the sprite that's being held. This can be achieved at the top level, where the player's current location is remembered. If, however, the sprite has been picked up and dropped away from its home screen, then the scene and x y have to be remembered. Code to do this is in test.

Design for Music and SFX:
It's currently my plan to use the SoundPool facility. This allows you to store a number of sound files with the application and also allows several channels to play at once. In this case, I would use one channel for the theme music or soundscape (e.g. birdsong, waves, wind etc.) of each scene, and another two for individual sound effects.
I think I can put this in a thread, which first loads the sounds, then is wakened up every 200 ms, say, which checks a variable in JadeView for each of the sound channels. Once it has started the channel, it sets the variable to "done". It can then see the next sound request when "done" is replaced. If the soundscape is unaltered, it just continues to play.

More on Cursors and Pick up & Drop

Cursors still have a few glitches. They tend to linger longer than they should. I shall try to make them only appear on screen when a touch is taking place - i.e. between ACTION_DOWN and ACTION_UP.

I implemented  Pick up & Drop using (as recommended by Android Developers) Long Press, rather than Double Click, which I had planned. So far, the Long Press seems too short at 384ms. It will be tuned.

I went for the complicated option - a gettable sprite that is also animated and scaled. That bit works fine

Useful Stage Reached

I've now done all the Menu items as follows:
Quit : finishes the game
Music On/Off : tweaks the music flag, though no music is currently implemented
Inventory: enters the Inventory scene (which cannot be saved)
User Save/Restore : uses 4 possible local files to save/restore any position
 also:
Android Save/Restore :  to deal with situations where Android OS does something outside the game's control - e.g. Change orientation; Pull a different Activity into foreground; Destroy game for lack of resources.
In this case,  the game saves its current position with the Android's own memory of the game, and restores it when the game is restarted.

All tested on both the PC-based emulator and on a Xoom device.

Save and Restore

I think I've done all the necessary stuff for life-cycle save and restore. Tests so far are encouraging, but there are a number of life-cycle incidents I'm not able readily to reproduce on the emulator. It'll take a test on real hardware to make me comfortable.

Next task is doing the user save / restore options. Then I'll implement the QUIT function.

The GUI

Having further considered the matter of the GUI, I've decided to base it all on sprites, rather than a special screen. It is probably neater, and certainly more efficient. So another carefully designed backdrop hits the wastebin.



So, what's still to do?

• Scale, flip and mirror on sprites;
• Cursor;
• More detailed touch control;
• Pick-up and drop;
• The save / restore for Android OS operations. The game has to be revivable if it is re-oriented, de-focussed etc. by the user.  It's an Android preoccupation;
• Similarly, and, I hope, using the same compression technology, the user save / restore;
• Music,which I hope to implement by using the built-in MP3 player;
• The Jade game itself, for which I have a lot of scenery and virtually no plot;
• The various delivery activities to get it to Beta Test and Android Market.

In short, still a lot to do, but the worst is over, I think. Actually getting a limp-mode game on screen has been an achievement. This time, as opposed to the original applet-based software, I've compartmentalised the code so that it will be easy to expand the game, or even base another game on the same engine.