I’ve been back on land for a couple of days, and I’m going back to
sea tomorrow. The last voyage was an interesting one, but I won’t go
into details on a public post like this. Keeping the voyage plan (and
even the existence of the voyage itself) from our passengers was an
important part of the program.
There’s not much to say, then. I’ll be back in about a week, with
another post to confirm my safe return.
On the Duties of the
Clergy is the first audiobook that I’ve had to abort halfway
through. It’s not the speaker (who sounds a bit like a European Sheng-Ji Yang),
but the subject matter that is stopping me.
I suppose that I expected something more like a procedual manual of
clerical rituals, or an in-depth discussion of a clergyman’s duty to his
people, but the book opens with an in-depth defence of Christian virtue.
Unfortunately the defence of these virtues is based solely upon biblical
citations. These grew tedious and I chose not to continue.
This is a weakness of audiobooks, I guess. They are incredibly
difficult to skim. Speeding up the sound files is an option, but makes
momentary lapses in attention even harder to recover from.
When we were at Port Davey, we lost a couple of lines over the side
and they got sucked into the propeller. Fortunately, they broke fairly
cleanly and didn’t rip anything away. Regardless, there was some
underwater work to be done. Another crew member and I have dive tickets,
so we hired some gear and got to work. Someone had a waterproof camera,
so I can share pictures.
I’m back from the Port Davey trip in one piece. Once again, the
Tasmanian landscape has proven resistant to my camera, so I’ve only put
up a few photos.
We motored west, along the southern coast of Tasmania and had a
fairly easy (that is, only a bit bouncy) trip into the port. We’d spend
about a day at each of several anchorages and then move to the next
one.
Our guests were able to go ashore and explore. Sometimes a couple of
extra crew could go along with these expeditions. I tagged along on a
trip up the Davey Gorge.
As I read, I was reminded of my experience reading Dracula: the
case of Jekyll/Hyde is well known in pop culture, so I knew what was
going on a lot earlier than any of the characters did. While writing
this post, I just realised that it’s probably what inspired Dr. Bruce
Banner/The Incredible Hulk as well. I feel a bit stupid for not noticing
that sooner.
The story is a morality tale about the importance of self-restraint.
The mental image I had of Mr. Hyde when I started reading was mainly
based on the movie The
League of Extraordinary Gentlemen: a man who becomes a hulk-like
monster by means of a potion. Stevenson’s original is a lot more subtle:
Hyde is a man like any other, except that he gives off an impression of
unwholesomeness despite having no obvious deformity.
The original story is surprisingly sad. I’d recommend reading this
one: it’s short and there are subtleties in the original that have been
lost in the popular image of the character.
There is a character trait I like to call “intellectual godmode”. It
is a feature where one character operates at a level far beyond that of
his peers, but it’s more than just being smart. It’s an ability to see
details, understand motivations and race through deductions in a way
that looks plausible on paper, but the other characters (and the reader)
have little hope of keeping up. When done well, it creates a feeling of
“I could do that, if I thought faster/observed more/knew more”. When
done poorly, the reader cries foul and loses suspension of disbelief.
Ender Wiggin has it. Sherlock Holmes has it. On that note, I have
finally finished reading A Sherlock Holmes
Omnibus. (I don’t remember how I got it into a format that my Kindle
liked, so it’s just the HTML version.)
The stories are extremely formulaic. Holmes often has everything
figured out right from the start, calling the problems “simple” and
“elementary” (although he never says “elementary, my dear Watson”).
Because the stories are almost entirely written from Watson’s point of
view, he never sees the details or draws the inferences that Holmes
does. The reader, therefore, doesn’t have a fighting chance of puzzling
things out until Holmes reveals all, and the result can feel like a
cheap trick. Even in the two stories written from Holmes’ perspective,
the details are kept from the reader until the end.
Even so, the stories are enjoyable. When Holmes reveals what he has
deduced, the inferences look plausible. It’s an entertaining world that
he lives in, where even the villains act like gentlemen. Once cornered,
the criminal will usually tell all and go away quitely. Very few stories
end without a tidy resolution.
The verdict? Read three or four, and keep going only if you enjoy
them as much as I did. You’ll have a good enough idea of what happens,
anyway. Then go and play Evil Sorceror’s Party,
as knowing the source material makes the Cyroq Ohms/Watt-san dialogue
even more enjoyable.
Before I start hacking away, I really need to think about what the
data model for an individual board is going to look like. In ZZT, each
world consisted of multiple 60x25 boards with links between them. I
intend to relax the 60x25 restriction, allowing boards of arbitrary (but
fixed) size.
I will probably store the contents of each board as an array, for the
following reasons:
It’s simple. When I consider anything more complicated, the twin
principles of YAGNI and “do the simplest thing that could possibly work”
both seem to apply.”
Access and update for a given coordinate are fast.
Object density will be fairly high, so there won’t be a lot of
wasted space.
The next question to answer: what goes into each board cell? My first
though was to have a background of arbitrary character and
foreground/background colour, with a possible object on top. That hits a
wall when passages are considered.
For those who don’t remember, a ZZT passage is an object, that when
touched, transports the player to a destination board (either to a
passage of the same colour, if it exists, or to the location of the
player object on that board). I want to keep multiplayer in the back of
my mind as I write Z+, so a player cannot instantly disappear into a
passage if it’s occupied by someone else. Therefore, I will replace the
inert background by second layer of objects, to represent things like
floor spikes, passages, lava and so on.
This means that each board has two layers of objects: foreground and
background. I am strongly against adding more layers - simplicity is a
design goal!. So long as it is cheap to create and store inert objects
(that is, objects without code), I see no problem with this approach.
Solid walls were going to be objects without code anyway.
Well, I’m on duty today, while everyone else has their precious day
off. I spent a good chunk of the afternoon making a new thump mat for
the main sheet. Here’s what it looks like:
I’m not exactly sure what I did. I copied the pattern from the other
thump mat that was already there. Once the first turn is finished, it’s
just a matter of following the line around and around the knot. That’s a
little easier said than done, as it involves moving a surprisingly large
amount of rope through the overs and unders.
As you may have gathered from the posts on Z+, I have returned safely
to Hobart from my voyage. I head out again on Friday. Voyaging’s a good
deal of fun, but a lot of work. Everything is a big production. Getting
in/out of bed? Big production: Carefully spider across the dry store
(compensating for roll, of course). Eating dinner? Big production:
feeding 3 watches means food is served on a strict schedule and
carefully rationed. Dropping/weighing anchor? Big production: the anchor
needs to be carefully controlled by adding and removing lines, the chain
needs to be hosed clean when raising it and someone needs to climb onto
it to get it back on deck:
Some other highlights, in bullet form:
Climbing the rigging to gasket sail in 25kt winds and a
noticeable roll. I assume a veteran mariner would laugh at that, but it
was quite tough for me. It was my job, however, and it got
done.
Celebrating something (possibly a different climb, I forget) by
changing to a fresh pair of socks ahead of schedule.
A pod of about 100 dolphins rocked up one day and played around
the ship for a while. They’d just jump out of the water, surf the bow
wave and generally muck around. Later that same day, a couple of whales
turned up and came within a couple of metres of the ship. You’d never
get that close on a whale-watching voyage.
It’s going to be pretty busy for the next few weeks, but hopefully
I’ll get time to continue writing.
Z+ will need to read and write world files. I think the correct
option is to pack all the data into a single file and document the
format. I considered using zipped directories with a custom extension,
but decided against it. zziplib would let me use
a renamed zip file as a world file, but it makes it very difficult to
write out world files. Making a world a directory (like OSX app bundles)
seems to be the backwards option. All it does is open the risk of losing
pieces of the world when sending it around.
What I will probably do is write a sequence of tpl records to a file. If
necessary, I can compress files with zlib.
Because tpl records are self-delimiting, I can just spew out a sequence
of them to a file descriptor and read them back one at a time. It also
has support for storing binary blobs, so if I decide to allow the
embedding of sound files, that becomes quite easy.
I’d like to follow the ZZT model of using the same format for world
and save files. It means one less file format to document. On the
downside, it means that storing assets in every save file creates a lot
of duplication. I could not embed assets and instead use bloopsaphone for
sound, I suppose, but that’s another consideration for another time.
I have made a decision with respect to the layout of the Z+ UI.
This the variant that was suggested me in an email, and I agree. I
however now think that a permanent message area is overkill, and will
probably make messages appear for only a few seconds (with a possible
scrollback).
It’s not worth thinking any further about this until I get some basic
implementation going. I think the next thing worth looking at is the
file format.
