Search Results for: hadean lands

Hadean Lands release 2.1.0

I have updated the Mac/Win/Linux version of Hadean Lands on Steam. These are small UI changes, mostly inherited from the past year's worth of Lectrote updates. The gameplay has not changed, and save files will continue to work undisturbed.

The same UI changes have gone out to and the Humble Store. (Last week, really.)

  • In the journal window, you can now sort items by name or by date (the order you discovered them in the game).
  • Added two new color themes: Sepia and Slate.
  • Changed the "Reset" menu item to "Reset Completely" (to match the in-game command for completely starting over).
  • Changed the "Close Window" menu item to "Close Game" for the main game window. (Except on Mac, sorry. The Mac's menu bar works poorly with this app framework.)
  • Fixed a slight size miscalculation in the status window.
  • Updated the Electron app framework to 1.4.16.


Posted in Zarfplan | Tagged , , , , | Leave a comment

Making navigation work

I've been playing a bunch of mobile games this spring (for no reason except that I played a lot of PC games over the winter) and I keep thinking about navigation.

Here's a navigation scheme which is common in casual first-person adventures: you always face forward. In every room, there's some number of exits, plus one invisible exit behind you. So you can go forward in various directions (unless you're at a dead end), and you can go back (unless you're at the start). If you bang the "back" button enough times you'll always return to the start room.

I don't know if this scheme has a common name; I'll call it forward-and-back. Examples that I've played recently: The Frostrune, Agent A, Facility 47.

(I'm distinguishing forward-and-back from the common scheme of third-person adventures, where the room contains several exits but they're all visible and the character avatar walks from one to another. That's different; it has no sense of "forward" or "back", although it may have a sense of "left and right".)

Forward-and-back has some obvious advantages. The player always has the same orientation in every room, so the game only needs one image of each room. (Important for a low-budget game where the backgrounds are hand-illustrated rather than rendered from a 3D model.) If the player gets lost, they can smack "back" button until they're not.

The scheme doesn't really support complex 3D environments, or puzzles based on 3D environments. You can't move your viewpoint around to understand 3D relations within a room, and 3D relations between rooms are usually obscure. (The "forward" direction is usually different from one room to the next!) So the scheme has limitations, but okay, every scheme has limitations.

But after playing a bunch of forward-and-back games, I have a complaint. I always feel lost. Or, no, "lost" is wrong. I always know where I am. I have a mental map (a tree, of course). I usually remember what's behind me and what rooms are ahead. But moving around is a somewhat laborious process. These games always involve lots of running back and forth, and the running around takes effort; it doesn't feel automatic.

Compare this to the parser IF navigation scheme. IF compass directions take a lot of crap ("artificial", "unintuitive" -- here's the most recent of many threads on the subject). But, by dooley, if I want to get across Hadean Lands I type "N <enter> N <enter> W <enter> W <enter> W <enter> W <enter> S <enter>" faster than I can think. (Even in a game like HL which supports "GO TO GARDEN", I usually use the compass directions.) Thus, when I'm working on a puzzle, I'm always working on the puzzle. Even if I have to run around, I have no sense of being interrupted by the busy-work of navigation.

What's the difference? Why do six clicks in a graphical adventure feel like more work than six keyboard inputs in a text adventure?

My current theory (certainly overgeneralized): the forward-and-back scheme doesn't give you enough context to think about long journeys.

For the journeys in HL (and other parser IF), I plot out the entire course before I start typing. I enter the commands without reading the responses, or reading just enough to verify that I'm on the right track. (An unexpectedly locked door will stop me, but I might overrun by a few commands before my fingers stop.) But in the forward-and-back games, I can't do this. I enter a room, look around, pick out the right door, click it, and repeat. I can't click-click-click across the game world.

Of course the game designers want to give me context. They post signs; they make buildings visible in the distance. But this is rarely consistent, and it usually only signposts the next room -- not the destination of my journey. If I'm standing at a fork in the road, I have to visualize the world map, think about the next room, and then remember what the path to it looks like. That's the extra step.

Okay, that's a hypothesis. Let's test it against some other game schemas.

In the classical first-person adventure, all movement is "forwards", because you can turn around within a room. The original Myst had clunky slide-show turns, but the genre soon upgraded to 360-panning views (Myst 3) and then to fully 3D worlds.

Now, running around these adventure games is never trivial. There's always a lot of clicking (or holding the "run" button). It can take time. But it doesn't require much thinking, because (once you've learned the map!) you just orient yourself and go. The game gives you the context to look around, to build the entire world map in your head. You see the fountain across the lawn, but you recall that the clock tower is visible down the fountain path, so it's ahead and on the left, so... and the next several steps are clear.

(I am, of course, speaking from the privilege of my own head! I have excellent spatial perception and visualization skills. So this whole analysis may be bunk to you, but I have to work this out for myself first...)

Here's Submachine 1. This is a first-person view, but most of the navigation is up-down-left-right rather than forward-and-back. The world falls into a regular grid (or a few regular grids joined by "ahead" doors). Result: easy navigation! I can click-click-click around the world.

(Then the author makes the later Submachine games really big -- scores of rooms -- which makes the navigation harder again. But at least the difficulty buys me more game.)

In Seltani, my hypertext MMO/MUD, I struggled to make Myst-like physical environments accessible in text. It almost worked -- but traversing large Ages is laborious, even for me. Even the worlds I created! I enter a room, look around, pick the right hyperlink...

Isn't this where we came in? Navigating in Seltani feels exactly like navigating a forward-and-back graphical game -- at least to me. I can learn an area well enough to click the links faster, but it never gets fast; I can never click-click-click through the world. And I think the problem is the same: not enough context, no way to visualize the entire space. It's the feeling of trying to cook dinner without my glasses.

Here's a map of the area described above. Better, right? If I ever redo Seltani, I'll add clickable maps to all my Ages.

Finally, an odd case. Vignettes is a puzzle game with no physical space at all. You "explore" by transforming objects using Escherian perspective tricks.

I played a bit. Then I put the game down and said "Nice concept, but the navigation is terrible!" Is there navigation? Well, there's a map, as we see above. The map shows known, nearby transformations: from the fire hydrant, we can reach the trashcan and the pillcase.

But again: not enough context. The game challenges us to find every transformation, but the map never shows us the whole world -- not even the known world. Missing links are shown as question marks, but only the nearby ones. If the local zone is complete (as above), how do we run across the world to a new one? The map gives us no help. It's not even a clickable map; we have to redo every transformation to explore, even the known ones.

(Added frustration: one-way links. If you're trying to move across the map, you can fall down a chute and land back where you started.) (And even more: the chest metaphor lets you jump instantly across the world, but only to a region that you've completely mined out! It's useless for reaching incomplete regions, the ones you need to reach to finish the game.)

(For all this complaining, I did pick Vignettes back up and finish it. The map is small enough to be playable despite its faults. But I nearly had to draw a paper map to finish -- the unforgivable sin of a mobile game.)

So what qualities make a game truly navigable? I say:

  • the game must let you understand the entire shape of the world;
  • the game must let you apply that knowledge to move across chunks of the world without stopping to think.

There are plenty of strategies for each point. A large-scale map with "click here to jump" buttons will always solve the problem, but it's not the only possibility. The designer may not want jumping; they may want to preserve the experience of continuous movement. Or they may not have the resources to implement the jump button. (At worst, it can require implementing all your lock-and-puzzle logic twice, which is a minefield of potential game bugs. Ask me about Hadean Lands...)

A large-scale map without interactivity will help if the player can connect map features to game-world features. (This is where my Seltani district map falls short; map symbols don't match up well to text.)

(A player who draws a map is certain to understand the shape of the world! But asking the player to draw a map is pretty much unjustifiable if the game has any graphical capability at all. Grumble at these modern times or embrace them, as you like, but that's where we are.)

In a graphical environment, being able to see from one area to another is good; being able to look around and see the world from many angles is also good. Both together give the player a great deal of context. Regular grids, top-down views, and consistent viewing angles all help the player make sense of the world.

And finally, all these concerns apply even to completely abstract maps which have nothing to do with physical space. A limited horizon and inconsistent directions will leave a player feeling lost, even in a skill tree or a branching plot diagram.

Posted in Zarf on Games | Tagged , , , , , , , , , , | 4 Comments

Hadean Lands on sale this week!

You may have noted that Steam has launched its Thanksgiving sale. It's not Black Friday yet; I dunno, maybe it's Purple Wednesday. They don't tell me these things.

Anyhow, Hadean Lands is part of this sale. My first Steam sale! Until Nov 29th, you can buy the game for 35% off. Exciting times indeed.

While you're at it, you might want to nominate your favorite text adventure for the Steam Awards. Interactive fiction winning such an award in the braoder gaming market? Sounds unlikely, doesn't it? I guess we'll find out!

We do not neglect other platforms! I've applied the same 35% discount to Hadean Lands on Itch.IO, the Humble Store, and the iOS App Store.

(Yes, the iOS version has a lower base price. That's just the way things are right now.) (Also note: due to the way Apple prices bundles, the "Zarf's Interactive Fiction" bundle is not available this week.)

...Oh, and since somebody is going to ask: no. The Steam DLC Solo Adventurer Pledge Certificate is not discounted. Discounting the certificate would only make it less valuable. Sheesh.

Posted in Zarfplan | Tagged , , , , , , , , | 2 Comments

Alchemy game notes, circa 2003

Here's a bit of a thing. I happened to look at my "game design" folder, which is of course full of random snippets of text dating back years. The oldest file is from 2003:


Research: enter a book "room", use standard IF search techniques to explores, find "exits" to other pages or other books. Books can be hidden in "real life", or just not indexed in the library. Similarly, a section of a book might not be findable until you find a reference elsewhere, and search for it.

(Library is a real-life room; the books you're familiar with are pulled out, handy. Reading one enters the book "room".)

Alchemical operations form a deep skill tree. As you perform operations successfully, they're added as single action. ("distill alcohol", "resublimate thiotimoline"). Lots of room to explore. Operations have logic, but also exceptions.

Time limit? If you screw up, or take too long, your supplies and tools are restored to their original state -- new day begins -- but you retain your skills. Maybe even get pre-made supplies of stuff you're very familiar with.

Operations take particular amounts of time? So there's an optimization problem, even for skills you've learned. (Ameliorated by pre-made supplies.)

No idea what the story looks like. Something about the reason why you are taking this alchemical test and have an infinite number of retries.

That's all I wrote back then. It's old enough to have MacOS-Classic line breaks instead of Unix/OSX line breaks.

When I started planning HL in mid-2010 I started a new notes file, but I left the old one in place. Obviously some of that old stuff went out the window. Although now I like the idea of books as environments which you "enter" to do research. Maybe I'll try that again someday.

For more fun, here's a snippet from the 2010 notes file:

Planetary types: (A marcher doesn't normally visit these, but they're familiar from the academy and from sailor's stories. The protagonist has never seen one before; he's only visited Gaian lands, and rarely left the Retort except in inhabited places.)

  • Gaian lands: where people can live.
  • Hadean lands: rock, little or no air, "night" sky. (The Moon, Mars.)
  • Helian lands: like Hadean lands, but with a big honking sun. (Mercury.)
  • Erebian lands: like Hadean lands, but covered in ice and with little sun. (Pluto, etc.)
  • Thalassan lands: oceans (of something) and atmosphere. (Titan, probably.)
  • Aeolian lands: only clouds visible. (Jupiter, but also Venus.)
  • Hermetic lands would be fairyland or Atlantis. Places populated by the Wise. The term is from popular fiction rather than science.

All of that is canon, but it's only briefly referred to in the released game.

I'm holding onto the domain as a placeholder. For what, I don't know yet.

Posted in Zarfplan | Tagged , , , , | Leave a comment

Hadean Lands, two weeks in

So, Zarf, how did that launch go?

Pretty good! Hadean Lands has been on sale on Steam for sixteen days now. And three hours. (Am I counting the minutes? Not really, but it's fun to check.)

In that time it garnered several articles about the DLC certificate, notably from Kotaku and (Those two articles interviewed me a bit on the subject.) Emily Short posted a stellar writeup of the game on Rock Paper Shotgun, and I also got a very nice review on ExtremeTech. And of course many other people said positive things.

Thank you!

Extra props to RayganK, who is leading a crew through HL on his Twitch channel. This is very cool! And... Twitch works very badly for me, for some reason, so I've only seen bits of it. They're two sessions in. Good hunting, folks.

But really, how is it selling?

I won't get into hard numbers, but... HL sold a fair number of copies in the first three days. Then the Steam summer sale started, which took the wind out of the sales. Or maybe it was just a three-day launch spike; it's about what I expected either way.

Then the nice reviews appeared, which led to several more days of good sales. Yay! At this point we're settling back down to the long-term tail rate, but I don't yet have an idea what that is.

And yes, to answer the obvious question, I've sold some certificates. A few. Not nearly as many as I've sold copies of the game. That's fine; I worked a lot harder on the game.

Other news?

This past weekend I posted a small update. (Also available on Itch and Humble.) It doesn't affect the game content, but adds some UI features:

  • "Full Screen" menu option. (F11 on Win/Linux, cmd-ctrl-F on Mac.)
  • "Find..." and "Find Next" menu options (ctrl-F/G or cmd-F/G). These let you do a simple text search in the story window. Note that the scrollback is not infinite -- sorry.
  • In the "Preferences" dialog, there is now an option for "Other Font..." This lets you enter the name of any font installed on your system. (Although you have to type it in rather than looking through a list. Enter the name as you would see it in a CSS file -- the game's display engine is HTML, after all.)
  • In the Alchemy Journal window, the list of rituals now shows "(*)" to mark rituals that you've learned but not yet tried. (Same as the RECALL RITUALS command in the story window.)
  • Fixed a bug where a formula description in the Journal window might not be updated when it should be.

(Due to the nature of Inform 7, I will probably never update the game content of the Steam release of HL. Any change would inevitably wipe everybody's save-game positions, and that just isn't acceptable for a Steam game.)

And that's the current color of the ritual bound, as it were. At this point I've done everything to Hadean Lands that I ever planned to, and more; it is entirely and completely shipped.

(Except for that bit of the KS reward that I still owe a few backers... yes, I know.)

I'm finishing up a contract project this month, and then it's back to thinking about Designing A New Game. Since I'm a game designer and all.

Posted in Zarfplan | Tagged , , , , , , | 4 Comments

Hadean Lands is now up on Steam

You can buy HL on Steam. That is the whole blog post.

Posted in Zarfplan | Tagged , , , , , , | 6 Comments

Hadean Lands: update available on Humble and Itch

Hey! I am back from Balticon, and so it's time for the HL release train to rumble into motion. Here's the first stage:

I have posted a new release of Hadean Lands to my Humble Store and Itch.IO pages. This is the new Lectrote-based app, for MacOS, Windows, and Linux, with autosave and integrated map and journal windows.


Bug reports are very welcome. Any bug I fix before the Steam launch is a win.

This release includes both a native app and the bare HadeanLands.gblorb game file, so you can play HL on any Glulx interpreter. (But you don't get the dynamic map and journal if you play that way.)

If you have saved games from the original (2014) release of HL, they are not compatible with this release. Sorry! I've stuck the original HadeanLands-2014.gblorb in the package too, so if you really want to go back to your old save files, it's possible.

(The differences between the current 2016 release and the old 2014 release are small. A few typos, a couple of fixes for obscure ritual corner cases, some improvements to parser disambiguation.)

Here's the important announcement: On June 20th, the price is going up! When HL launches on Steam -- that's June 20th -- it will launch at a price of $12 US. On that day, I am raising the price on the Humble and Itch stores to match. (The iOS version will remain at $5.)

This means that you have three weeks to buy the new version of the game at the old price. Think of it as a secret preparing-for-Steam sale.

Obviously, it's not a secret secret that the game is still available for $5. This is the Internet and you're reading it. But it's a fine line between "I underpriced HL when I originally released it" and "you're jacking up the price on us, you jerk." I don't want to get into that argument on the Steam store page for HL. My position there is "This is a $12 game." Keep it simple, keep it focussed on the Steam launch.

Okay, what else is going on...

If you've looked over the Steam store page you've probably noticed the DLC! Yes, Hadean Lands will have DLC, and no -- I'll spill the joke right away -- it's not extended game content. It's the Hadean Lands Solo Adventurer Pledge Certificate. That is, you can pay extra money for a certificate that you sign promising not to look at hints. Purely optional, I assure you.

The certificate will only be available through Steam. I've put up a detailed explanation on the DLC page. So far, comments are running 100% for "clever idea"... okay, that's 100% of one comment. Still, a positive response. Might even make me some extra money.

Speaking of commentary, Hadean Lands was discussed in three Xyzzymposium posts recently:

(These posts discuss the nominees for the XYZZY Awards in those categories for 2014. HL won all three of those categories that year, along with Best Puzzles.)

Posted in Zarfplan | Tagged , , , , , , | 7 Comments

The irritating case of Hadean Lands pricing on Steam

(Cases that are "curious" are as overdone as things "considered harmful". This one is just a nuisance, but I still have to solve it.)

When I started planning HL for iOS, I figured that I'd charge $5. It wasn't a casual-tiny price, it wasn't full-on-desktop-game. (2010 was early in iOS history but we could already see what "race to the bottom" meant.) I wrote up the Kickstarter page and offered $3 as the basic backer pre-order level -- "a $5 value!" So that was pretty well locked in.

During development I decided to release the game for Mac and Windows as well, but I kept the $5 price point. I'm not sure I had any hard logic for this beyond "I don't want to think about it." With a dash of "nobody will complain if it's the same price everywhere." I've had a couple of limited-term sales, but HL has basically been $5 since it launched.

Now I'm (slowly) approaching a Steam release. Scary! And worth revisiting my old assumptions. Should I raise the price?

(I'm not lowering the price, don't be silly.)

The good example on everyone's mind this week is Stephen's Sausage Roll, which launched with a $30 price-tag and an equally brazen attitude of "I'm worth it". Or, more, precisely: "Do you want this particular kind of puzzle? Are you going to jump up and down on it until your knees catch fire? If so, I'm worth $30 to you. Everybody else, just walk on by."

Also, as my friend Chris noted: "if this was a $5 game i'd just put it down and say 'whatever, too hard' [...] but being invested means i have to play it." Buying a game is buying into the game. We all know this, but the difference between $5 and $30 really throws it into the spotlight.

So maybe this all describes Hadean Lands too? Parser IF is niche appeal in a nutshell. Maybe I should kick it up to $7 or $10 on Steam. Or more?

I asked around my IF friends, and several of them said sure, they'd pay $10. Of course, they all own the game already, so it's not exactly a useful sample!

Many factors collide here.

  • What price? Dare I go beyond $10?
  • Do I also raise the iOS price?
  • Do I also raise the Mac/Win price? (On Itch.IO and the Humble Store.)
  • I'm adding the journal and map features (which exist on iOS but have never been seen on Mac/Win). I could say it's an "enhanced version" because of that.
  • I'm also fixing some minor but long-standing bugs. It's probably asinine to call it "enhanced" on that account, though.
  • I really don't have time in my schedule to extend the game in any way (beyond the journal and map UI).
  • When it comes down to it, will Steam users come after me in a torch-bearing mob for raising the price of an already-released game? Or is "new to Steam" good enough?

(But one major point of the "I'm worth it" strategy is to signal to the torch-bearing mob to go elsewhere, because they wouldn't be interested in the game to begin with! SSR has a delightfully high rating on Steam, because it's only purchased by people who want it.)

Comments? Opinions?

Posted in Zarfplan | Tagged , , , , , , , | 17 Comments

More progress towards Hadean Lands on Steam

Here's a work-in-progress shot of Hadean Lands on MacOS. I'm using an extended version of Lectrote, with HL's map and journal windows added in. (The iOS release of HL has always had these, but not the Mac/Win releases. Until now!)

Yes, two different windows are titled "Map of the Marcher". I'll fix that.

(Background: Lectrote is a new interpreter for Glulx IF games -- meaning most recent Inform 7 games. It runs on Mac/Win/Linux, and it supports all Glulx features except audio. I still have a "beta" label on it, but it's been stable for people so I think it's about ready to 1.0-ify.)

Once this is ready, I'll soft-launch it as an update for existing HL users (people who bought the desktop version through Itch or Humble, plus Kickstarter backers). I'll also post the process of turning your Glulx game into a Lectrote app like this.

In other news, I was interviewed on another podcast! Guy Hasson of Blind Panels talks to me about pretty much the entire history of IF. Plus other stuff I've done.

Posted in Zarfplan | Tagged , , , , , , , | Leave a comment

Lectrote now autosaves; Hadean Lands is that much closer to Steam

I've been steadily updating Lectrote, my new cross-platform(*) IF interpreter. In the past month it's gotten icons, a preferences dialog with font and color options, and -- most exciting from my point of view -- autosave.

(* Cross-platform meaning that Lectrote runs on Mac, Windows, and Linux. The interpreter only runs Glulx games, not Z-machine or TADS or any other format.)

Autosave means that if you close the game window (or quit the interpreter) and then open it again, you will find your game where you left off. You don't have to use the SAVE or RESTORE commands unless you want to keep multiple save points.

As I wrote last month, autosave is a bit of a nuisance. I spent February getting it all polished up and tested. And then the tests revealed some obscure low-level bugs in the iOS implementation of autosave. Turns out my iOS Hadean Lands app was failing to store one VM table, and therefore running about 50% slower than it should have. Whoops. Good thing I wrote tests, right?

Lectrote on the desktop seems to be adequately speedy for most games, including Hadean Lands. So that's the last big technical barrier to creating a really nice HL app for Mac/Win/Linux...

I don't mean to imply that a Steam release is coming this week. It will still take some time to adapt Lectrote to a single-game interface. Naturally I will document this process! I want to make things as smooth as possible for any author who wants to release an Inform game as a Mac/Win/Linux app.

(The iOS process is, er, not very smooth. This is mostly because Apple's process for the iOS App Store is baroque, to say the least. I'm not planning to put HL in the MacOS App Store, so it should be simpler.)

I'll also see if I can include the extra dynamically-updating windows from the iOS version of HL: the clickable map and the alchemy index. In theory, these aren't too hard to set up -- I can copy the logic and contents right over from the iOS app. In practice, theory sits on the curb and laughs at you when you say things like that. So we'll see.

But the end is in sight. Give me another couple of months.

Once I have a working HL app, I will release it as an update for the existing Mac/Win/Linux versions of the game. If you have downloaded HL from the Humble Store or Itch.IO (either as a purchaser or a Kickstarter backer), you will be able to download the new app and try it out. If no horrible bugs turn up, I'll start preparing the Steam release.

Posted in Zarfplan | Tagged , , , , , , | Leave a comment

Introducing Lectrote, an interpreter

Today I posted the beta of Lectrote, a new IF interpreter application for Mac, Windows, and Linux. This is both more and less exciting than it sounds!

If you're familiar with the IF scene, you know that there are several applications which can be used to play these games. Zoom (Mac), WinGlulxe (Windows), and Gargoyle (multiplatform) are the most commonly used. And then there's Quixe, which is a Javascript-based interpreter used on and other web sites.

When I was looking to release Hadean Lands as an app, I found that none of these were really what I wanted. Zoom is unmaintained and buggy; WinGlulxe is weird about scrolling; Gargoyle has problems on hi-res displays. (I'm summarizing, it was a long messy story.)

Quixe had the UI that I wanted -- no surprise; it's the one I wrote the UI for! -- but it wasn't really meant to be used as an app. It exists as a web page, or a component of a web page. Also, it's slow. So I put it aside and went with Gargoyle.

However, the long messy story didn't end there! A few weeks ago I was gazing over the endless cycle of dev-tools and noticed Electron. Electron lets you wrap up a Node.js tool as a standalone app for Mac, Win, and Linux. And Node.js is, well, I don't really know what it is but it's a web thing. Seems ideal, right? Stuff Quixe's web page into Electron and we're done.

It wasn't quite that easy. Node.js has full filesystem access (unlike a web page), so I had to extend Quixe's load/save system to deal with ordinary files. (So you can exchange save files between Lectrote and other interpreters.) But that was still pretty easy. I stuck the IF postcard in a menu, too.

And now you can try it.

So what does this have to do with getting Hadean Lands onto Steam? Well, it's a very simple tweak to drop a Glulx game file into Lectrote. Then you've got a Mac/Win/Linux app that plays a single game. And it looks nice and the text layout is pretty and you can adjust the font size without editing a text file.

I haven't done that yet. I'll have to adjust the menus -- knock out all the support for opening multiple games.

More important, I'll have to add autosave. Right now, if you're playing a game and you close the window, your game is gone. Hope you typed SAVE! That's okay for an interpreter (used by IF habitués), but it's not ideal. It's really not acceptable for a Steam standalone game release.

Autosave for Glulx games is a bit of a nuisance, but I got it working on iOS. I will get it to work with Quixe. It will just take a few more weeks.

...oh, and then there's the speed. I mentioned that Quixe is slow, right? It's faster than it was but it might not be fast enough for Hadean Lands. If you own HL for Mac/Win/Linux, try it! In particular, try loading a mid-game save file and typing a command which requires many stages, like GO TO BAROSY.

(If you don't own HL, may I remind you that it's on sale for the next two days? I probably don't have to. But I do it anyway.)

Anyway, I may try plugging a different Glulx VM into Lectrote to speed it up. I can probably run RemGlk/Glulxe as a subprocess of the Node.js server... We'll see.

For now, Lectrote is a multi-platform interpreter app which has the UI I want, and that's a good start.

Posted in Zarfplan | Tagged , , , , , , | 8 Comments

Hadean Lands sale at IndieGameStand

I am happy to report that Hadean Lands is this week's deal on IndieGameStand. For the next four days, you can buy my alchemical IF puzzle hit for -- for -- whatever price you want. Go nuts.

Beat the average price to get some bonuses:

  • High resolution map: This is the artwork that I used for the Hadean Lands backer reward poster. It is larger than the version included with the general HL release, and includes a few additional details.
  • Hadean Lands source code samples: A few representative samples from the Inform 7 source code of the game.
  • Critical Hit: An unfinished prototype of a game I started in 2009. This has never been released on the Internet, although I included it on the HL backer reward CD.

IndieGameStand is offering Hadean Lands for Mac, Windows, and Linux. These are exactly the same versions that are available on the Humble Store and Itch.IO.

Play IF on iPhone or iPad? I've put the iOS version of HL on sale too! For the same period -- until Thursday. Or buy the bundle with Shade and Heliopause.

Note: the iOS version is not pay-what-you-want; it's a flat $2. And it does not include the IGS bonuses listed above. The two sales are separate; sorry, I have no way to link them together. But you can buy both if you want, right?


Posted in Zarfplan | Tagged , , , , | 4 Comments

Customizing an interpreter for a Glulx game release

Another technical question from Twitter: the integration of Hadean Lands with its iOS app. How did I set up iOS UI features like the dynamic map and the recipe index?

(Warning: if you don't think C code is interesting, this post is not for you! Sorry.)

The iOS version of HL uses my standard iOS IF interface, extended. I've added two tabs to it. The map tab shows your current location, and you can tap to travel to any room you've visited before. The recipe tab shows an index of recipes and other information you've learned. These work just like the "GO TO..." and "RECALL..." commands, so they don't make the game easier to solve, but they're convenient shortcuts.

I'm not going to post the iOS UI code I used. If you know iOS programming, it's very basic -- textbook UITableView and UIImageView stuff. Instead, I'll talk about the general problem: transferring information between the Glulx VM and your native (C) interpreter.

I should put "general problem" in quotes. There are several Glulx interpreters, after all. But let's assume that you're building a native app for your Glulx game, incorporating the glulxe interpreter engine (in C), and you want to customize it with game-specific features. You've implemented the UI part; now you just need to extract game state information. Say, the player's location to show on the map.

There are a couple of approaches that would work. For example, we could define a completely general system for transmitting game information to an outside observer, and add that to the Glk spec. Sound like a good idea? Well, maybe, but it's both a hard problem and a vague problem -- what's "information"? We'd probably need some kind of structured interchange format (XML? JSON?). Then we'd have to encode and decode that. Plenty of headaches. No thanks, not right now.

Or we could define a new Glk output capability just for this game. No spec, just define a function ("glk_set_map_location") and have the game call it each turn. I thought about this, but I decided it would require modifying too many different modules. Glk function dispatching is kind of ugly.

Instead, I decided to write C code to peer directly into Glulx VM memory! It's stored as a simple byte array, after all. Reading the game state out is just a matter of understanding the memory layouts of objects, variables, and arrays.

Okay, that's not easy, but it's doable in a small amount of code. To make this work:

  • You'll need to know some Inform 6. Sorry. Inform 7 is a wonderful high-level programming system, but it compiles into low-level objects, variables, and arrays.

  • You'll need to extract information from the gameinfo.dbg file that's built along with your game. (This lives in the Build subdirectory of your Game.inform project.) This is where you find the memory addresses of those objects, variables, and arrays.

  • You'll need some boilerplate C code to examine objects, variables, and arrays. I'll attach it to this post; you can copy-and-paste.

How do you use this? Say you're interested in the player's location. (For the map, right?) You know from the Standard Rules that

The location variable translates into I6 as "real_location".

Browse through gameinfo.dbg with a text editor (or an XML editor) and you'll see a stanza that starts:

    <address> 249528</address>
    [...more info...]

This tells you the absolute memory address of the I6 variable real_location. Call gameparse_get_global() with that address -- the function is shown below -- and you'll get the player's location, expressed as the memory address of the room object.

How do you know what room that is? Somewhere in gameinfo.dbg is another stanza:

    <value>     273861</value>
    [...more info...]

This indicates that an object named "Kitchen" has memory address 273861. (It happens to be the 88th item that the compiler defined.)

Obviously this is not very convenient. All of these addresses are liable to change every time you compile your Inform game. So you wind up writing a script to parse your gameinfo.dbg XML, locate the real_location address, locate an object called I#_kitchen (for some integer, might not be 88), and so on. I like to write them out to a C header file looking like this:

#define GLOBAL_REAL_LOCATION (249528)
#define OBJ_KITCHEN (273861)

Then you can include this header in your game project and write code like

if (gameparse_get_global(GLOBAL_REAL_LOCATION) == OBJ_KITCHEN) {...}

But you'll have to write this XML-parsing script yourself, I'm afraid. I don't have one for you. You could start with

Note that you can't do this for I7 global variables (declarations like "Foo is a thing that varies.") Those get tucked into an I6 array and the gameinfo.dbg file has no information about them. If you need to observe a global variable, you'll have to declare it in I6 with an I7 translation. See I7 manual 27.22.

The gameparse_obj_child, gameparse_obj_sibling, gameparse_obj_parent functions let you traverse the I6 object tree. (Although this doesn't give you I7 relations like component-ness.) I used this for HL's recipe index. The game's internal knowledge objects are moved into special containers, for easy scopability, so I can trawl those containers to set up the recipe tab.

Looking at object attribute and properties is easy. The functions gameparse_obj_attribute and gameparse_obj_property do that. Knowing what I6 attribute or property represents a given Inform property is harder. The best plan is to to look at the generated I6 code (the Build/auto.inf in your Inform project) and see what's going on under the covers. For examine, the boolean property open/closed is implemented by the following I6 lines:

! meaning of "open"
if (t_0) return (GetEitherOrProperty(t_0, open));

This means you're looking for an I6 attribute in the gameinfo.dbg file:


Or say you've written the I7 line:

A thing has a number called the weight.

You find that this generates I6 code like:

! [1: let n be the weight of the noun]
tmp_0 = GProperty(OBJECT_TY, noun, p15_weight);

And so you're looking for an XML stanza like:


At this point you start to wonder if the general information API wouldn't be better after all. Maybe it is. Why didn't I go that way? (I realize this is more of a peek into Zarfbrain than you probably care about.) I find that this stuff is the easy part. Drawing a map was hard. Extracting recipes from game output and importing them into an iOS app was work, if not really hard. Extracting state from VM memory was a solved problem; I just had to do it for a lot of objects.

Also, it's fast. I only inspect game state when flipping to the relevant tab, and the inspection code is C. If I'd rigged the game to output state to an API, it would have to be every turn, which would slow down normal gameplay. Or I guess I could have added a secret input event for tab-flipping, which would mean blocking the UI on game code, also slow... Anyhow.

Some other concerns:

  • In my iOS interpreter, the VM runs in a background thread. The UI runs in the main thread, as is usual for iOS apps. How did I synchronize the VM inspection? I didn't! Totally whiffed the thread-safety issue. It's generally not a problem; the player will flip tabs while the VM is blocked awaiting input. But if you have some fancy timed-input code that moves the player around, and the player flips tabs at just the moment when the timer fires, you could get a bum value out of real_location.

  • What about Z-code games? You can take the same approach, but you need different state-inspection code, because the Z-machine's memory layout is different. (For a start, it's all 16-bit words, not 32-bit.) I did some of this for the iOS releases of Dreamhold, Shade, and Heliopause. But I didn't wrap up the C code into nice functions like these. So -- exercise for the reader, sorry.

  • Can you do this in Quixe? (A Javascript interpreter instead of a C interpreter.) Yes, and the plan is just about identical. Quixe maintains a private memmap array, which is a Javascript array of byte values, so you just have to translate the code below into Javascript and you'll get the same results. The only trick is that memmap is in a private scope. You could add the functions below to the Quixe global object, or rely on ReadWord/ReadByte, or just add a one-liner to export memmap:

    get_memmap: function() { return memmap; },

Finally, we have the question of input. When the player taps a room on the HL map, the game must accept it as input.

Again, there are a few ways to handle this. I decided to use a custom Glk event. The Glk spec says that negative event ids (0x80000000 to 0xFFFFFFFF) are reserved for implementation-specific events, and that's what this is. The iOSGlk library has a forceCustomEvent method. The map UI invokes this, passing a negative constant as the event type and the room object address as an extra argument. Conveniently we've already extracted the addresses of all the rooms from gameinfo.dbg.

(Other Glk libraries might not have this sort of API, but it will be easy to add. All events funnel into the Glk library in the same way.)

The only remaining chore is for the game to react to this custom event. Unfortunately, Inform's core parser loop is built to accept only text. This will have to be improved someday! (Not just for custom map hacks, but for hyperlink input, mouse input, and so on.)

But, again, I took the cheap way out. I used the HandleGlkEvent hook to translate the custom event into the input line "MAP-VERB 273861", where the number is the decimal room address.

This is not ideal because a player could type that line by hand! Well, whatever. Players can do what they want. Mind you, I sanity-check the argument very carefully to make sure an invalid address can't crash the game or leave the player stuck in a teakettle.

The relevant I7 code (and I6 inclusions) appear at the end of this post. I just noticed, though: it won't compile with the current Inform 6 compiler (6.33)! This is because I rely on the constants #lowest_object_number, #highest_object_number, #highest_class_number. These were missing from the Glulx compiler until, well, until I was writing this map code and needed them. You can build the latest I6 compiler from source and shove that into your I7 distribution. Then this'll work.

So the conclusion is, this is all a big pain in the butt, isn't it. Yep.

(No comments out of you, Dave. It really was the least-effort solution for my particular problem.)

C code for examining Glulx VM state:

#include "glulxe.h"

/* The glulxe.h header defines the glui32 type and the Mem4() macro.
    Also the memmap global variable (array of bytes). */
/* These functions do a little bit of safety-checking, but you really
    should be careful to only call them with valid object addresses. */
/* Feel free to add warnings or errors to the "error" cases. I like to
    throw exceptions, myself. */
/* All of this code assumes that NUM_ATTR_BYTES is 7, the default
    value for Glulx games. If you increase NUM_ATTR_BYTES, you'll
    have to adjust the object structure offsets. */

int gameparse_mem_active(void)
    return (memmap != NULL);

/* Fetch a global variable. */
glui32 gameparse_get_global(glui32 addr)
    if (!memmap)
        return 0; // error: called get_global with no memory map
    return Mem4(addr);

/* Get the object which contains a given object, or 0 if it
    is off-stage. (The I6 parent() function.) */
glui32 gameparse_obj_parent(glui32 obj)
    if (!memmap)
        return 0; // error: called obj_parent with no memory map
    if (memmap[obj] != 0x70)
        return 0; // error: called obj_parent on a non-object
    return Mem4(obj+5*4);

/* Get the first object contained by a given object, or 0 if it
    has no contents. (The I6 child() function.) */
glui32 gameparse_obj_child(glui32 obj)
    if (!memmap)
        return 0; // error: called obj_child with no memory map
    if (memmap[obj] != 0x70)
        return 0; // error: called obj_child on a non-object
    return Mem4(obj+7*4);

/* Get the next object contained after a given object, or 0 if there
    are no more. (The I6 sibling() function.) */
glui32 gameparse_obj_sibling(glui32 obj)
    if (!memmap)
        return 0; // error: called obj_sibling with no memory map
    if (memmap[obj] != 0x70)
        return 0; // error: called obj_sibling on a non-object
    return Mem4(obj+6*4);

/* Look up an attribute flag on an object. */
int gameparse_obj_attribute(glui32 obj, int attr)
    if (!memmap)
        return 0; // error: called obj_attribute with no memory map
    if (memmap[obj] != 0x70)
        return 0; // error: called obj_attribute on a non-object

    unsigned char byte = memmap[obj+1+(attr>>3)];
    if (byte & (1 << (attr & 7)))
        return 1;
        return 0;

/* Look up a property value on an object. */
/* Returns the first word of the property, if multi-word. (In most I7 games,
    the only multi-word property is "name". So you can't use this function
    to scan through the name list of an object.)
    If the property is not provided for this object, returns 0. */
glui32 gameparse_obj_property(glui32 obj, int prop)
    if (!memmap)
        return 0; // error: called obj_property with no memory map
    if (memmap[obj] != 0x70)
        return 0; // error: called obj_property on a non-object

    glui32 proptab = Mem4(obj+16);
    glui32 propcount = Mem4(proptab+0);
    for (int ix=0; ix<propcount; ix++) {
        glui32 propent = proptab+4+ix*10;
        int pid = Mem2(propent+0);
        if (pid == prop) {
            glui32 paddr = Mem4(propent+4);
            return Mem4(paddr);

    /* Property not provided. */
    return 0;

Inform 7 code for accepting custom input events. (This assumes a "select one room on a map" action, but it can be adapted to other uses.)

Include (-
[ HandleGlkEvent ev ischar args   val;
    if (ischar == 0 && ev-->0 == CUSTOM_EVENT_ID) {
        val = ev-->2;  ! the object address of the tapped room
        glk_cancel_line_event(gg_mainwin, gg_event);
        ! Write a synthetic "MAP-VERB ###" command into the buffer.
        VM_PrintToBuffer(buffer, INPUT_BUFFER_LEN-WORDSIZE, PrintVisitNum, val);
        return 2;
    return 0;
[ PrintVisitNum val;
    print "MAP-VERB ", val;
-) before "Stubs" in "Glulx.i6t".

To decide what object is paranoid-object-check (N - number): (- ParanoidObjCheck({N}) -).
Include (-
! Return val if val is a valid object, otherwise 0.
! This code requires the bleeding-edge (6.34) Inform 6 compiler.
[ ParanoidObjCheck val;
    if (val < Class + ((#lowest_object_number + #highest_class_number) * GOBJ_TOTAL_LENGTH))
        return 0;
    if (val > Class + ((#highest_object_number) * GOBJ_TOTAL_LENGTH))
        return 0;
    if ((val - Class) % GOBJ_TOTAL_LENGTH ~= 0)
        return 0;
    if (val->0 ~= $70)
        return 0;
    return val;

Numeric-visiting is an action applying to one number.
Understand "map-verb [number]" as numeric-visiting.

Carry out numeric-visiting:
    let N be the number understood;
    let O be paranoid-object-check N;
    if O is nothing:
        instead say "That address ([N]) is not an object!";
    if O is not a room:
        instead say "That address ([N]) is not a room!";
    [Check locked doors and so on here...]
    now the player is in O;
    say "You move to [O]."
Tagged , , , , , | Leave a comment

Hadean Lands greenlit! It turns out

A few days ago my idle twitter-browsing was upended:

Huh. I just checked the Greenlight page for @zarfeblong's Hadean Lands... I somehow missed the news that Valve had started the GL process (@andetkaihetera)

Really? I, um, missed the news too. But a quick glance at the HL Greenlight page showed:

This game has been Greenlit by the Community!

The community has shown their interest in this game. Valve has reached out to this developer to start moving things toward release on Steam.

I was off at Balticon, so I couldn't dig into the matter right then. (Which is why everybody else announced the news before me.) But now I'm back and more or less caught up on life. So here's what I know.

If Valve reached out to me, I missed it. The Greenlight page says "Updated: May 12 @ 7:24pm", and the voting stats stop on May 11. So I guess the game was officially greenlit two weeks ago and nobody noticed until this weekend? O the embarrassment.

The site now offers me a link to "become a Steamworks partner". So I have begun that process. I have filled out a great many forms' worth of tax and banking info, the usual excitement. (And the usual confusion about whether I should use Zarfhome LLC's EIN or my personal SSN, a question which I will never, ever get right on the first try.)

Bureaucracy aside, what does this mean for Hadean Lands? I wish I could just push a button and launch the thing onto Steam. But no -- not that simple.

The Mac/PC/Linux download packages that I built last year are playable. But they're not nice. Gargoyle doesn't even have a font preference menu. (You can bejigger a text config file, of all the archaic monstrosities.)

Worse problem: Gargoyle doesn't handle high-res displays. It renders text at the old-school resolution, which means it looks fuzzy and awful. "Retina" displays are standard on high-end Macs and are moving steadily down the product line, and now we're seeing them on Windows machines too. So this is serious.

I would like to switch to other interpreters, at least on Mac and Windows. However, the options are currently Mac Zoom (crashy) and WinGlulx (backscroll is hidden behind an obscure keystroke). Um. I'm very much afraid that I'll have to spend a couple of months fixing up other people's interpreters before I can build Steam-acceptable games.

Now, in some ways this is great. I like contributing fixes to open-source projects! Particularly for IF interpreters! But it's a lot of work, and no cash up front. What's up front is learning curve -- I haven't built either Windows or MacOS apps, not since the 1990s.

I'd probably want some game-specific interpreter features, too. There's the dynamic map -- or, if I can't swing that, I should at least display the static map in a separate window when asked. Same for the IF postcard.

On top of that, I need to browse through Steam's SDK and figure out how it works. I have to think about achievements (probably not) and trading cards (I don't even know). I have to look into whether Steam's libraries can legally be wedged in with IF interpreters, which tend to be GPL.

Plus: this would be a terrific opportunity for that HL bug fix release, right? An impressive bug list has piled up since October. I've barely touched it. Surely it's worth putting my best foot forward for the Steam release.

Whew. All of this will happen, but it will happen in parallel with other work. For example, look at this exciting teaser page that I put up last week...

What is this? I'm not saying! Except to note that it is neither parser-based nor traditionally choice-based (hyperlink or menu style). Fun, eh?

And now, the traditional "green it forward" section:

Cyberganked, Robb Sherwin's retro text RPG, has just gone up on Greenlight. Character classes! Live photos! CGA palettes! Live photos in CGA palettes! Surely a winner.

Porpentine, Twine author and winner of multiple IF awards, is Greenlighting Eczema Angel Orifice, a collection of over 20 of her works. You can't talk about the past few years of choice-based IF without talking about Porpentine.

And some IF works which have been on Greenlight for a while, and are still working their way towards the goal line:

Jack Toresal and The Secret Letter (Mike Gentry and David Cornelson)

The Shadow in the Cathedral (Ian Finley and Jon Ingold)

Posted in Zarfplan | Tagged , , , , , , , | 7 Comments

Hadean Lands on the Humble Store

I am happy to announce that Hadean Lands can now be purchased directly from the Humble Store. (It's currently listed under New Releases, though of course it will scroll off that page pretty soon.)

This is the same version that's been available all along. (No, I have not done a bug-fix release. I know, it's getting to be time...)

The Humble Store is fixed-price, not pay-what-you-want. The win is that 10% of proceeds go to charity.

You can still buy HL through the pay-what-you-want widgets on my web site. It's still in the Adventure Gamers Store. And of course the iOS version is still available from Apple.

(Have you voted for Hadean Lands on Steam Greenlight?)

Posted in Zarfplan | Tagged , , , , , , , | Leave a comment

XYZZY Awards

The XYZZY Awards for best interactive fiction of 2014 have just been announced. I'm happy to say that Hadean Lands won in four categories: Best Puzzles, Best Setting, Best Implementation, and Best Use of Innovation.

The overall Best IF Game of 2014 went to 80 Days, which absolutely deserved it. It was a tightly-contested award -- Hadean Lands was in the running, along with Kevin Gold's Choice of Robots, Porpentine's standout Twine work With Those We Love Alive, and IFComp winner Hunger Daemon by Sean M. Shore.

Winners in other categories included Lynnea Glasser's Creatures Such As We, Ade McT's Fifteen Minutes, michael lutz's the uncle who works for nintendo, and a symbolically satisfying tie between Twine and Inform 7 for Best Technological Development.

Here's the full list of winners and finalists. Congrats to everybody!

Since this is my brag post, I'll also note that I'm working on a new IF game! This will not be parser-based. I've got ideas about cool things to do with a touchscreen other than typing a lot.

No other hints right now. Stay tuned for more information.

Posted in Zarfplan | Tagged , , , , , , | Leave a comment

Various world models in IF

Another question from the tweetzone: "What are the significant differences for object/rooms + hypertext/choice vs parser + web?"

Here's (more of) that strand(s) of conversation:

I want tools to create a hypertext based game that still has a room and object model for the engine. Any suggestions? (@KalevTait)

I've done it (in Glulx) but the game design space is poorly understood. (As compared to parser+object model.) (@zarfeblong)

this just means it needs more research (@emshort)

What are the significant differences for object/rooms + hypertext/choice vs parser + web? Maybe I’ve misunderstood. (@jurieongames)

Emily's further responses:

parser + web = you still type. world model + choice = you're selecting what to do from options based on model (@emshort)

Oh, and I guess choice-based games tend to come from a CYOA, paragraph-based design approach? (@jurieongames)

often. even if they don't, enumerating all the options that would exist with a parser gives you a too-long list (@emshort)

so you need then to build a hierarchical interface or else have a smaller tighter verb set, for instance (@emshort)

I agree with Emily here (as usual), but I want to back up and talk about ways I've approach IF design.

Parser IF is a well-explored field, which started with Adventure and expanded through generations of... Adventure imitators. That's not a criticism, that's history. The MIT gang tried to make another game like Adventure; so did Scott Adams, albeit with more limited resources; so did other groups. Then in the 90s, many hobbyists tried to make more games like the Infocom set (etc), and built tools to accomplish that. What rooms are, what objects are, what the world model is, what interactions mean -- all go back to Adventure in a very direct line. I'll assert that 75% of the game mechanics in today's parser IF can be found in Adventure... in rudimentary form, sure, but present. And 75% of the rest can be found in Zork.

That's the form I grew up playing, and then writing. Not the only form, but the closest to my heart. But -- when I build a different kind of game, I'm not trying to approximate parser IF in a different-shaped bottle.

Like I said up top, I've created a hypertext game with a room and object model. That's Bigger Than You Think, a game that I wrote for the 2012 Yuletide fanfic exchange. This has a hybrid UI: you can click on links or type (single) words at a command prompt. It has rooms and an inventory.

(I'm going to assume that you've played BTYT, at least a little bit. If you haven't, hit the link and flip through a few moves.)

BTYT is not a parser game turned hyperlinky. I didn't design it that way and the underlying assumptions don't match the Adventure model. It's much more like a CYOA game-book with added inventory features.

Let's look at rooms. BTYT seems to offer a classic Adventure-style layout: each "page" is a location, and you have a choice of exits, each of which leads to a new location.

You'll quickly notice, however, that there's never a choice to "go back where you came from". Nor is there a sense of stopping to take action in a given location. A page is really an event, part of the story of an exploration into a cave. (The narration of the event includes entering and looking around.) You are always moving towards an endpoint; you cannot explore at will, except by using the "start over" option.

So the model is really The Cave of Time, the first of the "Choose Your Own Adventure" gamebook series. That book offered the notion that each page was a physical location in a cave -- but it didn't really stick to it, because pages in a book just don't represent Adventure rooms very well. Pages want to be sequenced events. (Later books in the series entirely discarded the idea of representing a physical maze. Our common notion of "CYOA game" is all about branching events, not branching tunnels.)

What about inventory? If you poke down certain branches of BTYT, you can find some objects to take -- a crowbar, a rope; "medium-sized dry goods" in the Adventure vein. But again, these are not manipulable objects in an Adventure-style world model. You can't put them down or try different actions with each one. Instead, they become an extra set of CYOA-style options -- available to try in each scene, until you find the right situation for each one.

(Note that the game header lists the current movement choices on the left, and the current inventory choices on the right.)

Paper gamebooks can't easily offer an inventory in this way. It's the experimental facet of BTYT. But it's not an Adventure-style inventory. I designed it to fit in with the CYOA model; it's what a gamebook choice-list would look like if it could be dynamic.

Seltani takes yet a third approach. Seltani is a hypertext environment inspired by Myst Online. The Myst games tend towards richly detailed environments but a sparse inventory system. You are expected to spend your time exploring the world, and then manipulating pieces of it "in place". You don't typically apply arbitrary tools to arbitrary targets.

Therefore, I wanted to create a choice-based system in which nodes are typically locations. You'll stop in a location to examine many of its parts, and perhaps pull some levers or turn some knobs. This required a multi-window UI: an environment window which describes what's around you, a detail window which describes the particular item you're paying attention to, and a history window in which events (and environmental changes) scroll by.

Note that this is different from the Adventure UI, where everything happens in a "history window". In parser IF, looking and examining are actions -- the response is a description at that moment. If you LOOK twice in a row, the world may have changed. Seltani's descriptive windows, in contrast, are always current.

(Some parser IF has tried permanent LOOK or INVENTORY panes. The Scott Adams games of the early 80s worked this way, for example; Beyond Zork also offered such a mode. However, these experiments have not caught on in the parser-IF community.)

Seltani has something like a world model, although it's very flat. It's got worlds, locations within a world, and that's about it. The built-in infrastructure is mostly about the portals between worlds rather than world contents.

Significantly, Seltani doesn't have objects or an inventory system. Why not? Well, say it did. What would you do with objects? "Actions" in this UI are hyperlinks which either examine or manipulate the world. If you carried a sword from the Living Room to the Kitchen, and a "sword" hyperlink were (somewhere) available, you could reasonably expect to examine the sword. But that's all! There's no way to express dropping the sword or smashing a window with it.

I avoided this problem in BTYT by discarding the idea of "examine". In that game, a "sword" hyperlink always means "take the sword" (when you first discover it) or "use the sword on something here" (if you're carrying it). I restricted the design to have at most one whackable target per location -- and you never drop anything except in its final use-location. Furthermore, BTYT is made of simple objects which do not require close inspection. So a single-link inventory works okay. But Myst games are full of detail; the BTYT model would never have worked for Seltani.

This is not to say the Seltani model can't be extended that way. The engine supports an extra "world pane" which remains visible throughout a world. The world designer could put an inventory list there. (Or, equivalently, tag an inventory list onto every location description in the world.) You'd have to decide what it meant to click on an inventory link in each location -- essentially inventing your own world model.

What you can't do is carry "objects" from one world to another. Seltani assumes that worlds are independent. It's hard enough rigging up one Age without figuring out how to respond to artifacts from every other Age!

(No, worlds aren't necessarily independent. You can build two Ages which are interconnected and share data. But that gets beyond this scope of this post.)

I should also note that the Seltani model can be extended in the other direction, too. You can build CYOA-style (or Twine-style) worlds, where nodes are treated as events rather than locations. To do this, you have to avoid relying on the event window. You also have to also lock out Seltani's multiplayer features, since a group of chatting players are implicitly presenting events in a location.

I've talked about two of my choice-based game designs, and how I try to craft each one so that the game and the UI match up.

One sometimes sees attempts at "hybrid" UIs -- trying to present a text game with both command-line and menu-based interfaces. You won't be surprised to hear that I have no patience for such experiments. I'd ask myself: does the game's experience depend on the parser interface? If it does, it's required! And if not, get rid of it! -- it's a waste of your time and the player's.

(But what about BTYT? I'll tell you straight up: the command-line interface on that game adds nothing. I should have gotten rid of it. I left it in to support MUD play via ClubFloyd, which is a very minor use case -- it should not have influenced me.) (Anyhow, the right approach would be to update Floyd to support hyperlink input. The RemGlk library makes this possible.)

The same goes for attempts to "port" parser games to a choice-based UI. I have nothing against remakes of a game. (Coloratura, for one example, is a parser game that was remade by the author in Twine.) But this is a design process, akin to translating a book into a movie or vice versa. You can't slap a new UI system onto a game and expect it to be "the same game but now accessible to more people".

I intended to wrap this post up by responding to Jon Ingold's post: Parser as Prototype: why choice-based games are more interesting.

My reaction is "how fundamentally wrong-headed". But if I try to support that, I will need so many qualifiers that I'll fly into the weeds and sink. I mean:

  • The post is from a year and a half ago, which is decades in Internet Time
  • Jon recently commented "Def not talking about approximating a parser game. Rather, parser was a step one to being able to design choice games this way" (@joningold)
  • Jon's design process is his process and I'm not going to step on it
  • The post is about the Sorcery! game series, and I haven't even played those
  • I don't assert that parser IF is some golden standard which other models need to approximate (much less measure up to)

So there's no fundamental disagreement -- rather, I think the post is weirdly framed to make an apology which doesn't need to be made.

I have played a lot of 80 Days. I can confidently say that it's not an approximation of a parser game. 80 Days is its own kind of IF, and its interface fits it very well. It doesn't have a "world model" in the sense of a space to manipulate objects. Its world model is, you know, a model of the world -- big and round and covered with cities -- and your inventory is meaningful in the space of planning your trip.

Note the word "planning". Much of the gameplay of 80 Days involves collecting, buying, or selling objects. But they are not used in the way that, say, Hadean Lands uses objects -- as mysteries whose places in the world come as crucial discoveries. Rather, their value is cumulative and largely predictable. When you buy a didjeridoo, you know where it's most profitable to sell it. If you miss that stop, well, you can probably sell it elsewhere -- and there are other ways to get cash anyhow. Other objects act as bonuses in the mini-game of learning new routes; but again, there are lots of ways to learn routes, and your piece of shortbread is never going to spell the difference between success and failure.

While I was finishing this post, the XYZZY Award finalists were announced. As it happens, Hadean Lands and 80 Days were each nominated for five awards.

It would be meretricious to explain that this will be settled by battle royale of alchemical Kaiju versus Victorian steam-mecha, as piloted by myself and Meg Jayanth. Mostly because With Those We Love Alive was nominated for eight awards, so you have to amend the battle with Porpentine and Brenda Neotenomie drawing mystical runes all over both of us, which makes it all confusing and hard to film.

I will instead wish good fortune to all the nominees, including the above-mentioned and also Kevin Gold, Sean M. Shore, A.D. Jansen, michael lutz, kaleidofish, Sam Ashwell, Steph Cherrywell, Emily Short, Lynnea Glasser, C.E.J. Pacian, Jason Dyer, Ade McT, Carolyn VanEseltine, Simon Christiansen, Mæja Stefánsson, Graham Nelson, Juhana Leinonen, Jim Munroe, Chris Klimas, Nicky Case, Kateri -- whew! I hope I didn't screw that list up.

Tagged , , , , , , , , , , , | 3 Comments

Designing alchemy in a puzzle game

A question about Hadean Lands from the tweet gallery: "Have you written anything about how you approached designing the alchemical system?"

Excellent question! The answer is "No, but I should, shouldn't I," yes okay. (Thanks @logodaedalus.)

My twitter-sized reply was "Sound cool while supporting the puzzles," but I can say more than that.

(Note: I will start this post by talking about HL in generalities. Later on I'll get into more spoilery detail about the game structure. It won't come down to specific puzzle solutions, but I'll put in a spoiler warning anyway.)

The keynote for HL's system was the alchemy puzzle in The Dreamhold. The Dreamhold lab had just two ingredients and three actions to take, but it felt like a dense explorable territory.

Dreamhold's principle was that any action you try on a given substance will produce a new and interesting result. And then you can try new actions on that! Obviously this exponential expansion has to be tied off pretty soon. Many of the combinations converge to common outcomes. The tree is only a few steps deep, really. (I think there are twelve possible substances to find.) But it's enough to give a sense of experimentation and discovery.

For HL, I wanted that sense, but bigger. Did I succeed? Heck no! It was an impossible goal. HL has forty-odd starting ingredients and thirty-odd magic words (not to mention other ritual actions, and the environmental influences, and...). Just providing the first step of a dense exploration tree would be... well, somebody might do it, but I wasn't going to.

So I developed HL with a less ambitious principle: you get recipes. When following a recipe, you should always be able to tell a right action from a wrong one. That is, a particular magic word will produce a unique response if you use it at the right time -- different from the response you get if you use it at the wrong time. The differences may be slight, but they're perceptible.

I didn't want to entirely crush the spirit of experimentation. So the second principle was: recipes aren't everything. The opening puzzle demonstrates this, and various later puzzles require you to substitute or invert ritual elements. I set up parallel structures and oppositional structures to make that make sense.

I think everyone agrees that I didn't hit the perfect balance. The game starts you with an off-recipe puzzle, but there's too long an interval before the next one. In between are lots of recipes that you have to follow perfectly; you lose track of the initial lesson. But most players were able to get onto the right track (or jump off the wrong one, if you like).

A followup question was "Did you have alchemical dynamics in mind when making the puzzles?" The answer is... mixed.

(Spoiler warning for the overall game structure, starting here!)

The core arc of HL is the limited supply of four key elements. You need all four for the endgame, and there are intermediate goals which require two or three. So initially you can only accomplish one intermediate goal at a time; then you have to reset.

That was my initial puzzle framework. I wrote that down, and then started complicating it. What ritual needs elements X and Y? Is it the ritual itself which needs those elements, or do I invent a sub-ritual which consumes X and provides a related X2? And so on.

At this point, I was inventing puzzles and alchemical mechanics in parallel. Or rather, I was going back and forth -- every decision on one side firmed up the possibilities on the other side. I needed puzzles whose solutions would seem reasonable; I needed mechanics which would feel like parts of a plausible magical science.

You'll note that I didn't start by creating a complete magical system and then deriving puzzles from it. Nor did I invent a bunch of puzzles and then invent alchemy that could solve them. Neither approach has ever worked for me. So if you're hoping for a complete, consistent model of HL alchemy -- I'm sorry. No such thing exists.

I knew that it couldn't exist, of course. That's one reason that the alchemy is described as being eclectic and syncretic. It fits nicely with the social background, too. The real-life British Empire did steal artifacts from all over the world. I evolved the idea that a magical British Empire would lift occult knowledge from every place they conquered, and jam it all together without regard for consistency or context!

(We assume this made them better at conquering. The game doesn't touch on much history, but references to the "East Empire" imply that they've got a firm grasp on Central Europe, and no doubt the New World as well. If I were a better writer, I'd have built a story about the Navy running into aliens and trying to treat them colonially... oh, well, room for a sequel.)

(There will be no sequel. That was a joke.)

The point is, I could make up whatever alchemical rules I wanted. I tried for a balance -- consistency in some places, chaos in others. I could draw on mythical, mathematical, or religious sources without having to be accurate about any of it. Convenient!

Back to the puzzle construction. As I said, there were a few key resources whose scarcity determined the game arc. Then I invented more resources -- both ingredients and formulae -- which either resulted from or combined with the key ones.

This could itself have created an ever-expanding tree of dependencies. But I constrained it, or at least bent it back on itself, with a third principle: everything in the game should be used at least twice. Ideally, in slightly different ways.

A naive adventure game uses each item exactly once. Indeed, many graphical adventures remove things from your inventory once you've used them successfully. This cuts against your sense of immersion -- not because of the anti-realism, but because you wind up watching the game mechanics rather than the game. An object disappearing (or being checked off) is a better signal of progress than the response of the game world. Text adventures don't have this disappearance convention; nonethless, the player learns to keep track of what's been used and ignore it thereafter.

I would rather teach the player that there's always more to learn. You may think you understand an item, but you still have to keep it in mind for future use. You have to keep everything in the game in mind at all times. This is the underlying challenge.

So I went over and over the list of rituals, looking for singletons. Magic word used only once? Work it into a new ritual. Alchemical potion only solves one puzzle? Invent a new place to use it. This added a richness to the mechanics. Two uses of a reagent imply there must be more; you have the sense that there must be underlying laws to explain it all. This is, as I said, an illusion; but it's a well-supported illusion.

Of course, it added up to a gob-smacking number of puzzles. Fortunately (or perhaps not), I was blessed with a very large list of formulae, resources, and recipes to scatter around the Retort. I could "use up" these extra puzzles as obstacles to various resources. (Thus all the locked cabinets.)

Also, since these puzzles weren't involved in the key resource plotline, it was okay if they had multiple solutions. (Some of the cabinets can be opened two or three ways.)

The final principle of Hadean Lands: involve all the senses. Let me go back to a line that I quoted in 2010, explaining the HL Kickstarter:

"If a witch could teleport (a thing that seems impossible, but I could be wrong), it would involve hours of preparation, rituals, chanting, and filling all the senses with the desired result until the spell would work in a blinding explosion of emotional fulfillment." (Steven Brust, Taltos)

Magic should be a transcendent experience. I tried to describe the effects of your rituals in colors, textures, sounds, scents... even the words that you speak are given synesthetic weight. Not to mention the ineffable air of things going wrong or right (so useful for cueing mistakes).

Of course, an adventure game involves lots of repetition, and nothing wears out faster than a repeated sense of transcendence. (Except maybe humor.) I dodged this problem with HL's PERFORM mechanic. When you PERFORM a known ritual, it doesn't repeat all of the descriptive text; I kept the output bare and mechanical. You're not reading it anyway! You just want to know whether the ritual succeeded. This preserves your sense of involvement with new rituals.

(Admittedly this falls apart when you're failing at a new ritual. That's a somewhat repetitive experience -- inevitably, I think.)

So there are my principles of magic design. I don't suppose I sound like a Hermetic occultist. I hope I do sound like a writer or designer describing his craft, because that's what this is. A lot of fussy details and a clear plan, is all.

Like the man said: writing is the art of causing change in a consenting reader, in accordance with the writer's will. You gotta be pragmatic about that stuff or you'll get nowhere.

Posted in Zarf on Games, Zarfplan | Tagged , , , , , , , , , , | Leave a comment

Why it takes longer than you think

In case you're wondering, nobody hassled me about how long the rewards took. Apparently you folks really were in it for the game -- or to support me, which is even nicer.

However, I bet there are people out there who are working on Kickstarters. And they should be warned: it always takes longer than you think. To substantiate this, here's a timeline of Hadean Lands work that came after the game shipped.

Note that I did lot of reward design in December, but didn't order the stuff until early January. That's because I knew I would be out of town for the last week of December. I didn't want expensive parcels arriving when I was gone.

  • Oct 30: Hadean Lands goes live for sale. (I won't describe the whole monkey dance of sending out iOS gift codes. Too painful to recall.)
  • Oct 31 to Nov 3: Catching up on backers who had problems getting the game, or who sent in late Kickstarter surveys. Also general PR work -- answering emails, posting on every social network I know.
  • Nov 5: Submit iOS app version 1.1. (Better iPhone 6 support.)
  • Nov 7 to 10: Toronto trip for WordPlay. (File under "marketing".)
  • Nov 10: Release iOS app version 1.1.
  • Nov 13 to 17: New York trip for Practice. (File under "networking".)
  • Nov 30: Finalize book design; order proofs.
  • Dec 2: Finalize postcard design; order postcards.
  • Dec 6: Get first proofs of the book.
  • Dec 8: Finalize map poster design; order proofs.
  • Dec 12: Decide the books are too large. Reformat smaller, order more proofs.
  • Dec 19: Submit iOS app version 1.2. (Save-file import and export.)
  • Dec 25 to 31: Out of town. Not thinking about HL.
  • Jan 1: Release iOS app version 1.2. (I didn't want to release this while I was gone, either.)
  • Jan 2: Order books.
  • Jan 3: Order posters.
  • Jan 6: Look into CD pricing.
  • Jan 11: Finalize CD design; order CDs.
  • Jan 21: Positive Slate review! (And PocketTactics too.) Suddenly I am back in PR mode.
  • Jan 22: Argh, half of the posters are misprinted and not usable. Contact customer support and ask for replacements.
  • Jan 24: Post Steam Greenlight page for HL.
  • Feb 1: The Month of Postage begins. (Assume days and days of sticking labels on things.)
  • Feb 17: Haul books and posters to the post office.
  • Feb 27: Haul half the CDs to the post office.
  • Mar 3: Haul the rest of the CDs to the post office.
Posted in Zarfplan | Tagged , , , , , , | Leave a comment

The Adventure Gamers Store is open

The season of GDC-and-PAX is upon us, which means more gaming news than any one human can hope to digest. And yet, I will burden you with a couple more snippets.

The site, which has been reviewing adventures in various forms since 1998, has opened a web storefront specifically for adventure games. Hadean Lands is in the launch lineup, as are several other indie highlights: Dominique Pamplemousse, Lumino City, stacks of Wadjet Eye and Daedalic titles, etc.

( gave Hadean Lands a super-nice review back when I launched.)

Note the Adventure Gamers Store currently only offers Windows versions of these games. (They say they hope to add Mac/Linux in the future.) Also, everything is currently priced in Euros. (You can buy from the US or anywhere else, don't worry.) I've set the HL price at €4.39, which makes it a fractionally better deal than the $4.99 price I've got everywhere else. Snap it up before the winds of currency conversion shift!

And in other news about places that sell HL...

The Itch.IO site has just announced that they will start taking a share of game revenues. (For most of their history they have been a completely free service.) This change will happen on March 23rd.

Unlike most platforms, they are going to let the game author decide what cut Itch takes of their games. They suggest 10%, but the author can move that slider anywhere between 0% (author keeps all the loot) up to 100% (donating all revenue to support Itch).

This is a sweet idea, and very much in the spirit of the Itch service. I am happy to support it by offering them the same 30% taken by Apple, Steam, and (for that matter) the Adventure Game Store. You can buy HL via Itch here.

Tagged , , , , , , , | Leave a comment