Wednesday, September 16, 2020

Myst VR teaser drops

I'm sure you already saw it, but I strive for completeness here, so here you go: a trailer for Myst in VR. The Steam page and GOG page are also up.
There's really not much to say about this. As Cyan's announcement says, they've been teasing this for a while now:
In fact, we suspect that some of you were onto us as far back as last summer when Rand gave his keynote at Mysterium 2019... We’ve been holding our breath ever since that video hit the internet hoping his keynote speech wouldn’t go viral, so for those of you who picked up on what we were laying down last year... Thanks for helping us keep things under wraps!
(From today's Firmament news update, one of the places where Cyan announced this.)
I take that last bit as a direct poke, since I blogged about Rand's keynote in 2019! VR possibilities and all! No, Rand didn't say "VR" -- he just called it a "definitive edition of Myst". But we all knew what he meant.
The real surprise here is that they're announcing it now. Firmament is currently on track for probably 2022, so this is looking like parallel development rather than sequential. Of course, it's impossible to know how the schedule will fall out.
The trailer and screenshots indicate that they've gotten a good ways into development. And it is very pretty.
Other tidbits:
  • The title is just Myst, no modifiers.
  • It will be VR-only and Quest-exclusive at launch, but flatscreen Windows and other VR platforms will follow.
  • The Steam page says "Built from the ground up to play in VR and flatscreen PC with new art, sound, interactions, and even optional puzzle randomization..."
  • The teaser has a slightly different opening narration in Rand's inimitable voice.
  • The D'ni text seen in the Myst book is a rather delightful easter egg for fans. See the top comment on the youtube page for a transcription.
I am of course pleased by this news, although I'll have to wait for the flatscreen release. Mind you, Firmament is still top of my wanted list.
The note about "puzzle randomization" is interesting. Many of the puzzles in Myst are entirely suitable for this. (Think about the clock tower, for example -- the required time code could be anything.) This isn't a huge expansion of the game's design, but it will be a nice change for people who want to replay it without feeling like they're following an invisible teleprompter. And it will be "optional", so detail mavens don't need to freak out.
The video and screenshots imply that they've scaled the island up a bit, and added lots of detail. But they haven't redesigned anything from scratch. It's still the classic, "noncanonical" Myst. Trap books will still be trap books. The puzzles will still be mostly nonmimetic insertions. Myst Island will not have bathrooms or living spaces.
...Or will it? Cyan could add practically anything as new bonus content; we'd cheer for it. It's really just a question of how much scope they allow themselves.
Okay, back to waiting mode, everybody.

Saturday, September 12, 2020

Recent additions to my Infocom collection

Last year, after the Infocom source code dump, I posted my Obsessively Complete Infocom Catalog.
This was the same data -- source code and some playable game files -- but with every version separated out and tagged. Release date, release type (alpha/beta/etc), game file version, all the information I could find.
Since 2019, people have sent me a fair number of pointers to "new" source code. Some of these were previously collected in various places; some have been dug out of MIT tape archives. I've been adding them to the page as they came in.
Want a quick tour?

Saturday, August 22, 2020

Hadean Lands: minor update

I have posted an update to Hadean Lands on Steam, Itch, and the Humble Store. This includes improvements to the UI framework only. (No changes to the game content.)
The game now supports OS dark theme. If you have your system OS theme set to "dark", all of the game windows (including the journal, map, preferences, and so on) will use a light-on-dark theme.
The story window will still be set to the color theme you last selected (Dark, Light, Sepia, Slate). You can adjust this to match in the preferences.
The preferences menu now has two system-responsive options: "Light/Dark" and "Sepia/Slate". These allow the story window to adjust if you switch your OS theme back and forth. I don't know why you would, but the game allows for it. (New players will see "Light/Dark" as the default preference.)
Other changes:
  • The Electron framework has been updated to 8.4.1. This should fix the "harfbuzz" library error that some Linux users were seeing.
  • There is a "Display Cover Art" menu option in the View menu, should you wish to bask in that.
  • The Mac version is now notarized.
Let me know if you run into any problems. Thanks!

Friday, August 21, 2020

Fan-built Ages in Myst Online

I've been writing about the idea of user-contributed content in Myst Online for almost long as Myst Online has been around. Then the game got cancelled in 2008. Then it was brought back as a static legacy server (source code available).
So people started experimenting with the tools for creating new Ages. A bunch of fan-run "shards" went up, both to test client fixes and to collect fan-built worlds.
Did I write about this new activity? Nope. I did not.
Playing around in the shards was a hassle. I'd have to figure out which sites to watch; I'd have to run variant client software; I'd have to keep track of bugs and age format details and who knows what else.
I don't mind going shoulder-deep in a steaming pile of half-working software! It's literally what they pay me for. But I have so many IF tools and systems on my plate that I just didn't need another one. So I said, look -- I'm going to blog this stuff for the typical Uru user. And the typical user doesn't know or care about shards. They log onto MOUL, Cyan's official shard. So I'll write up new content when it's imported into MOUL.
That was, oh, I think it was 2010 when I decided that.
Guess what happened today!

Sunday, August 16, 2020

The parser and the Myst plot hole

Occasionally someone asks, "Could Myst be done as a parser text game?" Sure! But you wouldn't want the translation to be too literal. Some of the puzzles would be less fun, more difficult, or more tedious when rendered in text form. So it's worth going back to rethink the design.
(Ironically, the sub maze -- Myst's most-reviled puzzle -- would translate pretty well. The relevant clues could be worked into environmental text. Plus, text IF has no movement delays, so if you missed the cues, brute-force mapping would be rather less tedious...)
But the most interesting design question is: do you allow TAKE? Myst is full of objects, but you can't carry any of them except book pages. (And one lit match.) But parser IF is all about the joys of acquisition! Do we stick to the limitations of the original game? Or shall we update the puzzle design to include keys and crowbars and lamps and all those other adventuring tools?
And while I was thinking about that, I realized... huh. The original game missed something.
To recap briefly (and spoilerifically): when you find enough red or blue pages, the evil brothers tell you how to open the secret fireplace compartment. That contains the last red and blue page and the green D'ni linking book. The green book shows you Atrus, who tells you to find and bring him the white page. His copy of the Myst book (his exit from D'ni) was sabotaged, and he needs the white page to fix it.
But in fact Atrus doesn't need the white page! And Atrus should know it! There's a simpler way to free Atrus which has nothing to do with the white page. This alternate solution isn't implemented in the game, but it is absolutely possible according to the logic of the story.
If you feel like solving the puzzle, I'll leave a bit of spoiler space.

Thursday, August 6, 2020

Mysterium starts Friday, online

Every year I write a Myst news wrapup post after Mysterium. This is because I enjoy hanging around the fandom, and then I pick up news, so I post it. Last year I even visited Cyan HQ; that was a trip and a half.
This year, of course, there are no trips. Trips are virtual. This means that you can hang around Mysterium as easily as me! It's the usual online setup: talks on Twitch and/or Youtube, chatter on Discord. Schedule is here.
Let me also bump your recollection of the Myst documentary Kickstarter, which has a week left. It's been running slow. I know a documentary isn't as exciting as a new game (also running slow), but a bunch of historical material will come out of this. We've already gotten this snippet of raw Achenar footage from the original Myst production files. Come on, you want more.
Opening stream is 7:45 pm Eastern on Friday. See you there.

Tuesday, July 28, 2020

Trademarking Infocom, again, part two

I posted yesterday about a company called SmartMonsters, who are running a port of (MIT) Zork in a MUD framework. They are trying to register the "Infocom" trademark.
But it turns out that someone else is trying to do the same thing. If you look at the URL infocom.xyz, you'll see a bare-bones site which claims "Infocom and the Infocom logo are trademarks of Infocom LLC." According to business records, Infocom LLC is a company formed in Colorado Springs in 2015.
Now, a US trademark search turns up no mention of this crew. And it looks like they've been claiming the "Infocom" trademark for years with no registration. But I am told that they are objecting to SmartMonsters' use of it. I don't really know how the trademark-tussling process works, so let's just say it's "in contention".
(I need hardly say that registering the Infocom trademark gives you no rights at all to the Infocom games. Those are covered by copyright, an entirely separate matter.)
So what are they doing with the trademark? The answer is a job posting that appeared last week:
In this position you will be provided with the source code for a proprietary assembler that consists of slightly under 4,000 lines of code. The source code you will study was written in assembly language to run on the TOPS-20 operating system on the PDP-10 mainframe computer. [...]
In this position you will play an important role by writing a functional specification document that describes the functions, program flow, error handling, and other information of the assembler that the person operating inside the clean room will need to know to develop a compatible replacement program. The replacement program is expected to be able to process the same input files and to generate bit-identical output files. [...]
The final specification will be made available under GPL-3.0-or-later. The software developed inside the clean room will be released under AGPL-3.0-or-later.
"Freelance Specification Writer" posted by Infocom LLC
This is an exact description of Infocom's ZAP assembler, which was part of their ZIL toolchain. (ZILCH turned ZIL code into Z-code assembly; ZAP turned the assembly into a Z-code game file.)
The source code in question turned up in the Infocom source-dump which appeared last year. Nobody noticed it right off. But a few months ago, a sharp-eyed user spotted ZAP buried in the MiniZork source directory.
The file "zap.mid" is MIDAS assembly code, an MIT variant of PDP-10 machine language. And it is indeed about 3800 lines long.
The job post describes a classical clean-room setup. You do this if you want to make a work-alike copy of someone else's program that isn't derived from their source code. The result does the same job -- "identical output", like the post says -- but you own it. This is legal because algorithms aren't copyrightable. (It may be ethically sketchy -- that's another whole question. But it's legal.) (Unless the algorithm is patented, but that's not the case here.)
So that's what this company is trying to do. The next question is, why? This is where my brain falls flat on the floor. And not just mine. I asked Jason Scott. He passed the word along to the old Infocom folks. Nobody, I mean nobody, can figure out what the point is.
The infocom.xyz site has two games up, which look like Lode Runner clones -- Linux only. This doesn't give much clue what line of business they're in, other than "not in it for the money".
(Yes, I sent them email, in case they were willing to tell me. They said "no further comment beyond what has already been made public.")
Let's be clear about what already exists. There are several open-source compilers that handle Z-code assembly. zasm does it; Inform 6 and ZILF both include the capability. We also have throrough descriptions of the Z-machine architecture, both Infocom's original document and the modern reconstruction. And of course there are dozens of open-source interpreters which play Z-code games.
All of these tools derive from the reverse-engineering work that went on in the late 1980s. The InfoTaskForce's seminal Z-code interpreter is archived here.
That was no kind of a "clean-room" project! The InfoTaskForce group dug into Infocom's proprietary games and interpreters, figured out how it all worked, and reimplemented it. (The Infocom spec document I linked didn't turn up until years later.) If Infocom, the original company, had wanted to make a legal issue of it in 1989, they probably could have. But they didn't.
After that, everything discovered by the ITF was public knowledge. The modern Z-machine spec (originally written by Graham Nelson) was a collation of that knowledge; Graham did not have to decompile Infocom interpreters. That spec has a Creative Common license (BY-SA-4, noted here). It's freely usable in every practical sense.
You can say that all modern Z-code/ZIL tools are "tainted evidence", due to the original ITF reverse-engineering. But it's a tenuous argument. And it still leaves the question of what you'd use a "less-tainted" ZAP assembler for.
Academic purposes? Studying Infocom's tools and processes is a worthwhile (and fascinating) goal. But it makes no sense to use a clean-room tool for that. You want to study every scrap of information available!
Compiling Infocom's ZIL source code for fun? There are plenty of people doing that already, using existing open-source tools. Some folks are even tackling bug fixes and modernization. (Yes, Activision's copyrights are a question here. The concensus is that volunteer updates to the source code are fan activity and basically okay. Don't go selling them, is all.)
Compiling Infocom's code for profit? A clean-room compiler or assembler doesn't give you any leverage there. You're still building a game file derived from proprietary source code. Again, selling it without Activision's permission would be right out.
Writing new, original ZIL games for fun? As I said, this is already a popular hobby. The forum is buzzing with ZIL programming chatter.
Writing new, original games for profit? I gotta tell you, ZIL is not the right tool for that job. Even if you think you're going to get rich off parser IF (tricky at best), you'll want a modern tool which can handle dense, highly-detailed games. Of all the Infocom alumni who revisited parser IF (Marc Blank, Mike Berlyn, Bob Bates), none of them chose ZIL.
For the sheer challenge of the hack? Maybe? But people usually don't put down money for that sort of fun. This setup involves hiring a documentation writer and a copyright lawyer, for a start.
So I'm left with nothing. My best guess is that they want to write unauthorized sequels to the Infocom canon, but they don't understand either the legal realities (a clean-room assembler gains you nothing) or the IF community. My second guess is that they want to contribute a legally unencumbered open-source tool, but they don't understand that this has no practical value. I dunno. They're certainly doing nothing to dispel the impression that they might have sketchy intentions.
On top of which, they consistently present themselves as "Infocom". Not "Infocom enthusiasts" or even "a new generation of Infocom". This tweet (from last year) is an eye-rolling example. I also see a discussion thread in which someone said they were (briefly) selling the old Infocom games without permission? I can't verify that, but jeez.
I guess we'll find out, or else they'll sink without a trace and we never will.