Sunday, October 13, 2019

Kickstarter and organizing

As I'm sure you know, the past few weeks have seen a wave of acrimony around Kickstarter and its nascent union, Kickstarter United. The company fired two employees who were involved in union organizing efforts. Kickstarter claimed it was for unrelated performance reasons; the workers filed an NLRB complaint. KS's CEO said that "The union framework is inherently adversarial"; the union asked the company for voluntary recognition; the company refused and is insisting on an NLRB-run election first.
I've been pretty unsure how to react to these events. I support the idea of tech-worker unionization, inside and outside the game industry. I don't like Kickstarter's apparently obstructionist and wishy-washy position. (Geez, calling your opponents "adversarial" and then refusing voluntary cooperation? I guess it's adversarial now.) But I am not at all familiar with the particulars of union organizing or how NLRB procedure works out for the various sides.
The union has pointedly not called for a boycott of KS or KS projects, but -- like many people -- I have been much less inclined to interact with the company since this situation flared up. Some prominent projects have jumped ship to other platforms such as Indiegogo.
Last week the union posted a call to action. This is straightforward: no boycott yet; express your support.
So that makes me feel better about starting to browse and back KS projects, as I used to do regularly. I do support Kickstarter United and the right of KS employees to unionize. Kickstarter is ready to organize. There. I have said so.
To be clear, I'm not a heavy KS backer. I keep an eye on the narrative game projects and occasionally back one if it looks cool and I think it needs the boost. (Plus whatever Cyan puts on the stove, but those are much higher-profile affairs.) The last time I put money down was August. Now I've caught up and kicked some money at a game or two.
This is not to say that I consider Kickstarter to be union-washed and clean. I am, to half-coin a phrase, keeping an eye out for the union label on new projects. I hope more projects declare their explicit support. And I'm definitely watching Kickstarter's policies and (more importantly) their actions. They've built up a lot of good will helping to launch niche and indie projects -- including mine. That goodwill is now theirs to lose.

Monday, September 23, 2019

Apple Arcade and the future(s)

Apple Arcade's launch is splattered all over the pundosphere, with every possible hot take from "This is pretty good" to "This could be a problem."
I haven't tried Arcade yet. I'm waiting for iOS 13.1 to drop on Tuesday. Also, I'm wallowing in new unplayed PC games already (Little Misfortune, Asshole Goose Game, etc). A free trial month of 75 more games feels like more of a threat than a promise. But hey, I can still blog about it.
Everybody(*) loves Apple Arcade for obvious reasons. "This is a really good deal for players"; "Apple pushes back against manipulative free-to-play crap." These are both true statements. They both amount to the same thing: Apple is investing a lot of money in iOS games and releasing them for way below cost.
This is great for the devs involved. I recognize a lot of names on that launch list and I am happy for them. But it also leaves us wondering how long the party will last, and who will be invited. Community nerves are already sensitized, or just rubbed raw, by the arguments around the Epic Game Store. Epic is also in its money-hose platform-building stage -- but for how long?
Thus the asterisk on the statement above. Investment dollars and free games buy a lot of love and a lingering whiff of fear. It's hard not to see Arcade as yet another stride in the race to the bottom. Is the "premium" pay-up-front game about to suffocate?

Tuesday, September 3, 2019

The Zarfian Cruelty Scale, revisited

The Zarfian Cruelty Scale is 23 years old as of last month. That's not a numerically interesting anniversary, but it's respectable age for a offhand scrap of critical theory that still gets mentioned regularly.
I am pleased and amused by the Cruelty Scale's continuing currency. But I also worry that people might apply it more broadly or rigidly than it deserves. The Cruelty Scale has had caveats almost from the beginning; it embodies many 1996-ish assumptions about IF and game design. I think it's time to, at minimum, dig into those assumptions. We should make sure we know what we're thinking when we use it.

Thursday, August 29, 2019

Abusers, another shoe in the wall

When I said "I know stories that are still not public," I didn't expect them to get blown open within 24 hours.
Yesterday, Meg Jayanth posted this thread:
An anon account has been naming abusers in the games industry. Alexis Kennedy is one of them. I can't speak to the motives of the anon, but Alexis is a well-known predator in the games industry. I have been warning people about him for years.
Olivia Wood followed up with a description of her experience, in which Alexis Kennedy took advantage of his position of authority over her. Emily Short added her observations. Many other women have spoken up about his manipulative and boundary-pushing behavior.
Kennedy is not the only name to hit the spotlight since my first post, but he's the case that strikes closest to home. I played Echo Bazaar and Sunless Sea. They were great games. His company, Failbetter Games, was and is a highlight of innovative design in the narrative game world. After Kennedy left Failbetter, I was excited to see what he would do next. (Until I started hearing rumors about his behavior, it did not occur to me to wonder why he had left Failbetter Games.)
Failbetter also was and is publicly devoted to foregrounding the voices of underrepresented groups, including women. Many of my friends wrote for Echo Bazaar and Sunless Sea. As Emily said, it was a shock to learn that Kennedy was taking public credit for this good citizenship while privately treating it as his personal grabbing ground.
(Kennedy's new company has a "mentorship program" for indies. Unsurprisingly, the indie devs in that program are now cutting ties.)
So. This sucks. It has sucked for a lot of women, privately, for years. I wasn't happy to find out about it, and if you're just finding out now, you're not happy either. Nevertheless it is incumbent on us to know, acknowledge, and make sure these stories are heard.
Those who are speaking up now have my gratitude and admiration. I know it didn't just happen. It was a long process of people taking care of each other -- making sure that they could come forward, if not safely, at least from a position of support. These posts are my attempt to aid and support that effort.
I'll leave off with this thread:
We believe and stand with everyone who has come forward to speak out about Alexis Kennedy tonight.
Alexis left Failbetter three years ago. We no longer have any ties with him personally, creatively or financially.
We know that for some of you, Fallen London and Sunless Sea are irredeemably linked with him. It can be heartbreaking to love something as much as people love these games and feel they're tainted by association.
We fully understand and respect that. This sort of behaviour has no place in our industry, or in any other. We can only say that we strive to be a studio we can be proud of, and that you can be proud to support.

Tuesday, August 27, 2019

Abusers in the game-dev world

Two personal accounts appeared yesterday -- no, screw passive voice. Nathalie Lawhead and Zoe Quinn spoke out yesterday, naming two prominent game designers/musicians as abusers and rapists: Jeremy Soule and Alec Holowka. Nathalie's account; Zoe's account.
I hang around indie dev circles but I'm pretty peripheral. I don't think I've ever run into either of these men. I learn these stories when they go public, or when women tell them to me in confidence.
Sometimes, I hear a story along with a warning that the victim is still vulnerable to retaliation, that she does not want the story to go public yet. I know stories that are still not public and names that people warn each other about in private.
I cannot say anything else about those names. What I can say is: I believe Zoe and Nathalie. They are speaking up with courage to share what they know and help prevent future abuses.
I'll also note that this trail of terrible revelations is another aspect of crunch in the gaming industry. Nathalie's story, in particular, is about being rendered vulnerable by the desperation and insecurity of her "opportunities" in the game-dev world. Unscrupulous higher-ups in the industry are able to take advantage of workers -- particularly newcomers. Crunch is the public, "acceptable" face of this abuse: exhaustion, erosion of personal time and personal relationships. Inevitably, that is not the end of it. Sometimes it is assaulting people and then pressuring them to be silent about it.
So that's today's bitter thought. Take hands.

UPDATE, Aug 29th: see also next post.

UPDATE, Sep 3rd: Scott Benson has posted his experiences with Alex Holowka, who died last week as this discussion and its consequences spun on.

Tuesday, August 6, 2019

A quick trip to Riven, and further VR thoughts

Yesterday I said that I was a VR skeptic. I've mentioned this before. But I admit that I don't have an awful lot of VR experience to base my opinion on. I've spent a few minutes playing with a Vive, and I tried out the VR Firmament demo at GDC a couple of years ago.
(I've also spent a couple of minutes playing with a Magic Leap devkit unit. But that's AR, a different category.)
Don't get me wrong: I've enjoyed each of these demos. VR is a good trick. My problem is that it's not that much better than the usual sort of videogame experience. For example, I played Zed a couple of weeks ago. When I think back on that play-through, I don't remember being looking at a flat screen -- I remember being there. That's how I react to first-person videogames. It's how I reacted to Myst and Riven in the 90s, on those terrible 800x600-pixel CRTs. VR certainly gives that sense of being there, but why should I pay hundreds of dollars extra when I can get the same experience from a TV? Plus the ability to drink from my water glass.
However! At Mysterium I had the opportunity to try the latest Starry Expanse demo in VR. I also could have tried Zed and Obduction in VR, but the lines were longer for those, so I just did the one.
This was a very small and unpolished demo. It started in the tram-car station of Survey Island, and then you could walk in to the elevator chamber and summon the elevator. That's it. You couldn't board the tram or ride the elevator.
The game locomotion is still set up for regular controllers: two-stick walk-and-turn navigation. This is widely agreed to be the worst setup for VR motion sickness. Nearly all VR games offer teleportation, tunnel zip, or some other alternative. Starry Expanse is still very much in progress; it hasn't gotten those modes working yet.
As it happens, I didn't feel ill at all -- at least not in my ten-minute session. Moving around was quite comfortable. The most disconcerting effect came after I took the helmet off. Walking away, I felt like I was drifting underwater. The world wasn't wobbling but it was distinctly... shock-absorbed. The sensation passed off after a minute or two.
Apparently my body's reaction to vestibular inconsistency isn't to get sick, but rather to shut my inner ears right down. That's good to know.
So have I changed my opinion about VR? No, but I've refined it some.
The demo pulled me into the world of Riven instantly. That's what felt different from a regular flatscreen game. I'm used to a period of adaptation. I launch the game, I wrangle the preferences, I find the "New Game" button. Then I slide into the first-person experience and the screen fades away. It doesn't take long -- a few minutes at most -- but it does take time. VR is helmet, bang, you're there.
It strikes me that this aspect of VR is more advantageous to quick demos than to long-form games. I mean, if you're in a flashy-noisy PAX expo hall, the instant transition to a fantasy world -- cutting out all the distraction -- is really striking. It gives you something that a flatscreen in the demo booth can't. But at home? In a quiet room where you've already decided to spend your time? That advantage flattens out.
So I wonder if the whole VR craze isn't based on a misapprehension. Maybe the tech companies who demo VR at game shows are drawing false conclusions -- seeing reactions that just don't carry over to home gamers in the living room.
Or maybe I'm just not a typical gamer. Wouldn't be the first time.
Anyway, my original position stands. It's been two days since I walked down that tunnel on Survey Island. I remember being there... just like I was in 1997, when I first played Riven. Of course it was full 3D rather than the old slideshow, but you know what? I don't remember 1997 Riven in slideshow either. The flaws in the experience have annealed in memory. It's a seamless world now, like all the magical worlds I've visited before and since.
I look forward to visiting again. And I'm grateful that the Starry Expanse team is building it for me. (Perhaps under Cyan's imprimatur, if the roadmap holds up.) But I still don't think I need the helmet for it.

Monday, August 5, 2019

News from Mysterium 2019

I imagine you think of this as just an annual news post. "Hey, here's some Myst news that isn't a kickstarter!" But we really do get together once a year and have a weekend of community love. I don't go to every Mysterium, but this year is the 20th gathering and it's (approximately) the 25th anniversary of Myst's release. We're celebrating Zed being released and Firmament being in production. So I felt I really had to take part.
Plus, a chance to tour the Cyan office! Come on.

But I'll spare you my vacation photos and anecdotes. Here's the news post. This information is straight from Rand Miller's presentation on Saturday, plus other people who presented over the weekend.

Saturday, July 13, 2019

Early Myst Online prototypes recovered

A couple of days ago, Cyan's Eric Anderson posted some delightful links via Twitter:


Here's a fun treat for all the Myst/D'ni/Uru fans out there... The original pre-Uru, pre-Mudpie "DIRT/Descent" demo, in all its fully-playable glory! Don't ask us for support, just cross your fingers and hope it works. PS: This thing is 19 YEARS OLD! tinyurl.com/DIRT-Descent pic.twitter.com/hxzYqKLD2F

And for all you HARD CORE fans: Here is the 20-year-old Pre-DIRT "Nexus" Demo built before Cyan even acquired Headspin! It's so old you need to install a (included) Glide GPU wrapper! Also, I have no idea how to solve the "puzzle". Enjoy! tinyurl.com/NexusDemo99 pic.twitter.com/DtoR0PEpBt

Extra Double Bonus!!!!!! Here is the playable "Hector Cove" demo as well (also from around 2000)... Because why not - right? Go harass some janky birbs! tinyurl.com/HectorCove pic.twitter.com/o2yYaMEF5I
(Headspin was an independent studio which developed the first version of the Plasma 3D engine. Cyan acquired Headspin in 1998 and used their engine for RealMyst, Myst 5, and all the versions of Uru / Myst Online. A GPL version is now available.)
I never played these demos; I didn't start tunnelling into Myst Online fandom until 2003-ish. And I'm sorry to admit that I still haven't played them. My Windows gaming machine is currently packed in a box, and it'll be a couple of weeks before I have access to it again.
But you're not me, so have at it.

Sunday, July 7, 2019

Apps, tools, and what I use to get through life

Apple did their annual developer announcements last month. The general response is that there's good stuff in store for the Mac/iOS/tvOS ecosystem. Common dev toolkit across all platforms, a new declarative interface builder, multi-window UI and thumb-drive support for iPads, a consistent undo gesture. Decent controller support for iOS games.
I could link to articles with titles like "Audacity" and "Changes Everything". Let's just go with this summary from Dave Mark.
I have spoken to a lot of longtime developers, and many new developers this week to gauge the reaction of what’s going on behind-the-scenes at WWDC. The response has been overwhelmingly positive for what Apple has introduced publicly and what they are saying and doing in the talks and labs during the conference. [...] If developers are happy, consumers are going to be pleased because we are going to get some great apps in the coming months.
(--Dave Mark, Thoughts on WWDC 2019)
That all sounds nice, and I bumped along for a few weeks in a cloud of mild Apple euphoria. But at some point I started trying to figure out what this means for me, specifically. How does my life improve?
Turns out -- it doesn't. I know that sounds weird; I'm a lifetime Mac user and I have no intention of jumping ship. But somehow, I'm not in the app market. I just don't buy productivity tools.

Let me try to quantify this. I've just spent a year helping to organize and run an IF conference. As co-chair, I was involved in every aspect of this thing -- the web site, the program book, the budget, everything. What was my toolset for this daunting job?
  • BBEdit. My Mac text editor since forever. I spent a surprisingly long time on the free BBEdit Lite and TextWrangler tools, but when TextWrangler retired a couple of years ago, I paid for the full version. Therefore, I am now out of the market for text editors.
  • Emacs. Yes, I use both Emacs and BBEdit. I go back and forth without thinking. Don't ^@ me.
  • Numbers. This is the spreadsheet that comes free on Mac/iPhone/iPad. We kept piles of data in spreadsheets. However, there was nothing specifically Apple about the way I did it. I could have used Excel or Google Sheets. In fact, when sharing data with the rest of the team, I always exported it to .xlsx files, .csv files, or Google.
  • Pages. This is Apple's free word processor, sibling to Numbers. Again, it was nice to use a native app, but any number of equivalent tools would have worked. The end goal was always to export a PDF. (If I didn't want a PDF, I'd be in Emacs or BBEdit.)
  • Inkscape. Open-source vector illustration editor. This is actually in a precarious state -- the Mac port is two years out of date and about to capsize in the MacOS 32-bit purge. But it's still my go-to tool for any kind of illustration.
  • Google Forms and Google Docs. We ran several attendee surveys and questionnaires.
  • Dropbox. Our shared document repository.
  • Slack. For what you use Slack for.
  • Python. For ad-hoc everything. Also for the web site, which was based on the Pelican static generator.
Really, you ask, Python? Yup. For example, when I laid out the program book, I did it in two columns for the two-page spreads. Oops -- the printing service wanted one column per page. Rather than reformatting, I wrote up a quick script to (1) convert the PDF to image data; (2) slice that into left and right halves; (3) write them out as PNG files.
Similarly, when I sent out email to attendees, I used a little script which chewed through the attendance spreadsheet (in .csv form) and sent email to each address. Stuff like that. There's plenty of ways to do these tasks, but I reach for a script.
This is why I bounce off all those articles saying "I've switched to the iPad as my regular work machine!" We got another round of them this month -- not without justification. But the fact is that all of my workflows eventually expand to include a Python script. It sounds like a joke, but it's the honest truth.
(I'm writing this blog post in BBEdit. When I'm done, I'll pipe it through a script to convert the Markdown syntax to HTML, and shove that into Google's Blogger interface. That's how I roll.)

This is probably more detail than you need about my tech obsessions. It boils down to: I like open-source tools and tools which can interoperate with them. And I'm quite resistant to changing gears. If something works, I'd rather figure out how to keep it working.
As a result, I have no idea what the last dozen hot new drawing apps are. Sorry! (Nor am I asking for recommendations.) I suppose this entire post is an indulgence of cane-waving. Sure, new tools can be fun, but haven't you already figured out how to do your work twenty years ago? Rarggh, kids, lawn, etc.
When I look at my iOS devices, the last serious app I installed was Slack. And Slack's been going for a while now, right? Oh, and I installed a bank app because I opened an account at a new bank.
(Note that games are a different scene entirely. I grab new iOS games at a whim; I regularly browse the app store lists looking for new ones. Sometimes I'll try a new game because it's a lazy morning and I'd rather pay three bucks than get out of bed right then. You know how it is.)
Let me turn the question around (before this gets any more embarrassing). What are the tools that have changed the way I work? And when did I adopt them?
(I'm not going to count software development languages, because that's work in its own right. I'm talking about tools that help me with not-inherently-software tasks. Like running a convention.)
  • Text editors (Emacs, BBEdit). Before that I think I wrote stuff down in my terrible handwriting until my hand cramped. I used word processors in high school, but mostly for assignments, not saving data. Then I got my first computer account where I could save files -- and not in the uncertain hell of floppy disks. Life-changing. (Arguably, this includes the crucial flip-side skill of "organizing files in a directory tree".)
  • Email. Any serious communication, I want it in email. Email is my memory. Plain text please; HTML just gets stripped. Attachments are fine but I'll save them off separately.
  • Vector graphics (PostScript, Inkscape/SVG). I did not do art until I could program it. Then I found out about PostScript and started trying stuff like this. Not that this is terrific art, but it was a space I could mess around with. I worked up to projects like the Hadean Lands map, which I did in Inkscape.
  • Scripting languages (csh, Python). See above. Perl happened to a lot of people of my generation, but I skipped it.
  • Online chat (Zephyr, MUDs, IRC, XMPP, Slack). Many different work, social, and mixed-work-social circles. Chat has gone through a lot of different platforms; I've used all of them in roughly the same way. I can coordinate with people entirely via email, but chat complements email by letting you have a discussion right now. Yes, Slack has nice amenities -- file attachments! -- but when Slack is ruined by corporateness we'll move on to something else. (Note: Discord is a bad replacement and will not survive.)
  • Distributed version control (Git). Yes, I used SVN before Git. And RCS before that. RCS was bad, SVN was fine. But Git was when I said, oh right, I should use this on anything that might need revisions. No server setup, just git init and start work. Revelatory.
  • Spreadsheets. I came very late to spreadsheets. I didn't start one until I wanted to track sales of iOS apps, which was 2011. They certainly solve a bunch of problems, though.
  • Bug/issue trackers? I'm not sure this looms as large as the other items, but it's a runner-up.
And... that's it. That's the toolbox. Oh, I use innumerable other tools ad hoc, but these are the ones that rearranged how I do everything.
You see immediately that these are all old technologies. I picked most of them up in college. Git and spreadsheets are the only recent additions, and of course spreadsheets were around much earlier. So if there's a moral (and I've been rambling long enough that there better be a moral), it's that I've been a conservative old fart my entire life.
That said, you never know. I did figure out spreadsheets at age 40, and I'm not dead yet.
pbpaste | blogmark.py | pbcopy

Wednesday, June 26, 2019

Myst TV rights involved in yet another vague but probably exciting deal

Apologies for the skeptical headline. I've been covering this story in various forms for a decade now.
Village Roadshow Entertainment Group, the Australian-American co-producer and co-financier of the “Matrix” and “Sherlock Holmes” franchises, has acquired the rights to the first-person graphic adventure. [...]
Village Roadshow says it will use the games to develop a “multi-platform universe including film, scripted and unscripted television content.” The company will develop and produce the content with original co-creator Rand Miller and his youngest brother Ryan Miller, as well as Isaac Testerman and Yale Rice at Delve Media.
For the past few years, Cyan has been partnering with Legendary Television to try to make a Myst TV series or movie or something. (E.g. the failed Hulu deal in 2014.) It sounds like Legendary is no longer involved. So this news could be summed up as "Cyan switches production partners". But Village Roadshow has put down money for the rights, so that's a step forward.
(I need hardly remind people that "paid for the rights" is a long, long way from "greenlighted the production of a show." And "multi-platform universe" basically means "we haven't decided what we want yet".)
The article mentions Isaac Testerman's Delve Media. This is interesting. The last time I saw Delve mentioned in relation to this story was this backroom wrangle in 2012. I didn't realize they were still involved, or had become involved again.
Anyhow, despite my world-weary tone, this is exciting. Hopefully we'll hear more about it in August at Mysterium.

Thursday, June 20, 2019

NarraScope 2019: complete

NarraScope 2019 is over. Here's what I wrote about it.
You've probably already read this blog post. But NarraScope was such a large part of my past year that I need to at least mention it on my personal blog.
Yowza, that was great.
See you in 2020.

Tuesday, June 11, 2019

Notes on recent games: big narrative

Observation

You are the system AI of an LEO space station which has just gone wrong. The surviving astronaut reboots you. Fix the problems.
This feels rather old-fashioned, for a couple of reasons. Narratively, you're on rails; Emma gives you tasks and you carry them out. You have enough leeway to hunt around the station and collect notes -- journals and logs in a very classic environmental-storytelling mode. But the next task is always clear. Your only real narrative choices are how exhaustively you want to hunt journals.
As for the mechanics, the basic navigation model is simple. You can switch cameras in each space station module, and switch to new modules as they come online. You can connect to any station device visible on camera; you can report anything you see to Emma. Later, you get to steer a floating drone. Pretty much everything else you do in the game is a matter of "connect to a device, figure out its controls, do what Emma asks." Or "Figure out its controls, see a problem, report it." You wind up using most devices twice or more, so you get the sense of learning a toolkit, but it doesn't really have systematic mechanics that build on each other.
So that makes Observation sound pretty dishwater, doesn't it? But the game works really well! It's a series of crises -- as you would expect from a barely-functional space station -- and the sense of urgency carries you right on through all the mini-quests and button games. All of which are fun. They may not have a deep narrative or mechanical basis, but you feel good when you get something right and Emma gasps in relief. Reporting a problem may be a matter of selecting a trouble spot and pushing a button, but Emma seizes on your intel and advances the plot, and there's your sense of agency.
Furthermore, being on rails fits your narrative role. You are, after all, only a computer. Your NPC partner is doing the real work of fixing the station. You're taking care of all the background mechanical stuff that Emma either can't reach or can't spare the time for. You've always got a job to so. It's a simple trick, but as I say, it works really well.
If I have a real complaint, it's that the puzzles involve too much searching around with the slow-and-grindy camera controls. When I got stuck, it was always because I'd failed to find one critical switch or sticky note. The only way to advance was to keep panning around. It's a dense environment, but it's mostly space-station clutter; it's not that much fun to explore.
(A couple of scenes move outside the station, and the view is stunning -- but it's also a much larger environment and it's really easy to get lost.)
So I can't say that Observation pushes any boundaries. But everything it does is so engaging and nicely constructed that I don't care. It's a terrific experience. Recommended.

Close to the Sun

It is impossible to talk about this game without mentioning Bioshock. On the one hand, that's a problem. On the other hand, it's an easy problem to ignore. Monumental Art Deco follies are awesome; we've played in them before Bioshock; why not play in some more?
Plus, the pitch is "Bioshock without zombies", which gets me up out of my chair dancing. I didn't mind the combat in Bioshock; it's a gun game. But that wasn't what interested me. I was there for the environments, narrative, and puzzles. Close to the Sun is all those minus the gun. Great!
Well, pretty good. I mean, it's fine. I mean...
For a start, it doesn't seem to have much to say. Bioshock starts with a thinly-veiled Ayn Rand declaiming the glories of personal liberty; and the game was about free will and liberty. CttS gives us an alt-history Nikola Tesla declaiming the glories of pure scientific genius, and somehow it comes to exactly the same thing. You have giant gilt rooms inhabited by extremely rich people. This Tesla is an extremely rich power magnate, hounded by resentful Edison terrorists -- which is a nice bit. But there's no take here. Except for portraying Tesla as kind of a clueless lunatic, which comes off as watered-down reality and a watered-down Cave Johnson, both at the same time.
The story involves running around the dead ship looking for your sister-the-scientist. There's the expected sisterly banter on the radio, plus Tesla diatribes and a few other characters. The characters never really came to life, though. At least as far as I got.
For all my gripes, it's a perfectly playable game with kickass visual environments. Some kind of time-fracture story is building up, which has potential. I'm perfectly willing to play through such a game. However -- I didn't finish CttS. At a certain point you get chased by a lunatic with a knife. (The Whitechapel killer, of all the really-not-Art Deco figures.) You have to run away or get messily stabbed. I tried running away six or eight times. Five times in a row, I tripped over a low barrier because the "vault" button refused to work. Then I gave up.
I wanted to like CttS more, but there just didn't seem to be much meat on the bones. Observation did more, quicker, with less dialogue.

Zed

And now, the awkward bit where I like a game, I recommend a game, but everything I have to say about the game is negative.
First, unsetting the expectations. When Zed launched its Kickstarter in 2016, it billed itself as a puzzle adventure. The pitch invoked Myst early and often. (Underscoring that, Zed wound up being published by Cyan.) But development is hell, as we know, and the final release has evolved into something a lot more Gone Home than Myst.
That's fine, as long as you don't walk in jonesing for puzzles. Walking sims are great. My complaint is that Zed spends much of its (short) length walking through well-trodden territory. It's a symbolic exploration (check) of someone's life (check) laden with loss, regret, and nostalgia (check) and affairs with hot young grad students. No, wait, that last bit is a different genre. This one is an artist being screwed over by Hollywood.
And the play consists of finding symbolic objects that trigger memories. Find all four in a scene and you can go on to the next. Repeat until sentimental ending symbolic of new beginnings.
None this is bad, but we've seen it before. A lot. Even more so on the psychological-horror side of the walking-sim fence. Zed doesn't go the horror route, but the techniques are still familiar.
In theory, Zed explores the life of an artist suffering from dementia. I say "in theory" because that aspect seems barely present in the narrative, and not at all in the gameplay. I have not lived through the hell of a parent or loved one falling into dementia, but I have friends who have. They talk about progressive inevitable loss: loss of memory, loss of ability, loss of the person they once knew. Every remnant you find is a tiny miracle -- and crushing, because it's got an expiration date.
Zed isn't about loss. It's about memory, yes, but your experience is the opposite of loss: you build someone's complete life. Everything you find is crystal-clear. Winning means finding it all.
Okay, this is a hard problem. I'm not saying Zed had to tackle the experience of loss this way. But it feels like a missed opportunity that it didn't even try.
(The obvious comparison is Stephen Granade's Twine game Will Not Let Me Go, but I'm embarrassed to say that I've never played through it. It's the right comparison anyhow.)
Okay, enough negatives. Zed is a visual treat -- large, striking, vivid environments, wildly varied and each appropriate to its theme. If you are a VR enthusiast, I'm sure you will enjoy wanding through them as much as I enjoyed the old-fashioned flatscreen experience. The voice acting is lively and convincing. It avoids the cliche of walking-sim monologue narration while still staying focused on the protagonist's voice; a good trick.
And the story pulls together solidly at the end. It's a genuine and moving conclusion.
And I've still spend four times as long complaining about Zed as I've spent praising it. It's good, you should play it. I just wish there was more for me to buy into, rather than just to watch.

Outer Wilds

(Not "Outer Worlds", an unrelated and as-yet-unreleased game.)
I haven't finished Outer Wilds. I'm still working on it. I'm not going to write much, because it's not the game I thought it was when I started. And it's not the game I thought it was half an hour later, when the (SPOILER) started. So I'm probably still wrong about what game it is.
But it is 100% adorable, with banjos, marshmallow roasts, and spaceflight among St-Exupery-sized planets. It's also deeply nerdy. And it's, I'm pretty sure it is, no I'm sure, it's incredibly clever.
Play this one. Don't wait for me to talk more about it.

Monday, June 10, 2019

Notes on recent games: nifty little experiments

Fugue in Void

Expectations count. When you fire this up, it opens with a langorously slow zoom into an abstract monochrome worldscape. I stared at it. I wiggled the joystick. I went and got a glass of water. It was still zooming. It was pretty, but, like, was the game broken? I killed the process.
Then I looked back at the Steam page, which says: "The game starts with a 10 minute intro." Geez, if I'd known that... To be clear, this is my fault for projecting my expectations onto the work. I should have been willing to say "What is happening is the thing that is happening" and then settle back to watch.
Anyhow. This work will make more sense if you view it as coming from the demoscene rather than the indie game world. (I have no idea if the creator knows this.) The noninteractive opening would be at home in any demoparty. The body of the work has the mode of a walking sim (with slivers of game trope) (pressure plates open doors), but it remains a piece about visual experience rather than world interaction. Specifically, a world of overwhelming concrete architecture, abstract sculpture, and blown-out visual contrast. The style has turned up before (e.g. NaissanceE) but I enjoyed being able to take it in without annoying platforming goals.

Mountain

Not a recent game, of course. I picked up the iOS version this month for no particular reason.
The followup Everything rather eclipsed Mountain, because Everything is larger (by definition!) and also has structure to make a gaming audience feel at home. But Mountain offers as much charm for its size. I have never before said "Why, yes, I do sometimes feel like a mountain floating in the void, trying to serenely meditate on the universe, and then a washing machine or a stapler or something flies out of the void and sticks to me, you know what I mean?" But now that you ask, the answer is yes, I do. It's a remarkably cogent question considering that the game asks it nonverbally. And it's reassuring to consider that the stapler will quietly decay. Someday it will be gone, even as more objective noise flies out of the void towards me.
I left the game running for a while, and when I came back, the mountain was gone. Now I've started over, and I have to keep the tablet nearby and take a look now and then. Well played. Hey, look, there's cake.

Alt-Frequencies

A game about radio stations with a genuinely awesome interface gimmick. You listen to broadcaster audio tracks in real time, flipping channels at will. Your only mode of interaction is to record a clip from one station and then play it as a "listener call-in" to another station. This gives you a broad range of action without the awful pit-traps of free text or speech input. Nice clear authoring model, too. And fully voiced for both game outputs and player "inputs"!
To keep the script under control, it's a time-loop game; you get three minutes on every channel and then the world resets. The writers decided to make the story about the time loop -- a natural (perhaps inevitable) interplay of form and content.
The problem is, there's no room to set up an actual conflict here. It's a vague "public debate about the time loop". Newscasters say politicians are for and against it, talk-radio hosts discuss dissent, pop DJs mention the upcoming vote. Conspiracy jocks insinuate that the loop has already started (which of course it has). But there's no actual debate. It's an unsubtle Brexit riff, but Brexit shorn of racism, nationalism, health care, banking, and the Irish border -- i.e., nothing about Brexit at all, nor any other current issue.
So it's fluff, yes, but by the same token it's broadly-drawn and a lot of fun to listen to. The voice talent are all having a great time. It's an easy play-through; very short overall, and the script gives you plenty of nudges about what you should be doing. Very much worth a run just to see how the gimmick plays.
(Big bonus points for supporting accessibility for visually impaired players.)

Sunday, June 9, 2019

A more complete collection of Infocom sources and game files

A followup to my discussion of the Infocom source release a couple of months ago...
I've just spent a couple of weeks gathering up every version of the source code and the game files that I could find. Jason's GitHub collections are excellent, but they are an edited extract from one source: the so-called "Infocom Drive". They omit some published variations, beta-tests, and so on.
For years, the IF Archive has had another collection of Infocom game files (though not source code): the patches collection. But these were in an annoying encoded format, in order to dodge the legal problems with archiving commercial games.
I figure that those legal problems are well out the barn door now. It's time to have every Infocom game file variation in one place, indexed and easy to download. So here they are:
I've tagged everything with the release number and serial number, where known. Plus tags for whatever other info we've got: "alpha", "beta", "mac", etc.
Research and enjoy!

Thursday, May 23, 2019

Heaven's Vault: design ruminations

I've played through Heaven's Vault twice now.
At the end of the first run, I had this distinct thought which I had never put into words before. I wrote:
What's the word for when you finish a story, and now you can really start to discover the story? Because, on the second run, the boundaries and spaces of what you can do will be distinguishable from "what I just did". It's this feeling of "I've seen the covers, now I can open the book."
Jon Ingold immediately shot back "archeology", which was on target, but not really the answer. If you are interested in games, you read a game for its interactive structure. That's distinct from reading the story. But in a well-designed game, the interactive structure is part of the story. Or vice versa. They support each other. That's the idea I was trying to get at: the story can't have its full impact until you understand the game mechanics, and you can't fully understand the mechanics until you've run through the story a few times and kicked the boundaries.
This is true of all games; you always think about how else your session might have gone. But it's not always such a present truth! Many games make their boundaries pretty clear on the first run-through. You've already felt your way around the walls, you might say, in the course of making your way to the exit.
I'm not describing games that we think of "linear" vs "nonlinear" (those weakest of game descriptors). When I played through Night in the Woods, I spent my story time talking to Bea. I could have hung out with Gregg instead, and it's clear that would have led to a different story. But I also had a good sense of how it would be different. I might yet replay the game to see those Gregg conversations, and to see any of a number of other story variations. I wouldn't expect to it to be a different game.
Finishing Heaven's Vault was very different! I had the overwhelming sense that I didn't know what kind of game it was yet. I didn't know which of my choices were vital; I didn't even know which of my actions had been choices. And so I started the game over. (Not immediately, but after a break of a couple weeks.)

As it happens, my second HV run-through felt quite similar to my first.
I don't meant it was a disappointment! For one thing, I had a much stronger grasp of the alien language. (The game allows you to keep your translation dictionary across runs. This is a well-chosen, if unsubtle, enticement for those odd people who don't get obsessed with game design questions at the end of round one...)
I don't even mean that the story played out the same way the second time. I visited locations in a different order. I explored many of those locations from different angles. I made a couple of brand-new (-to-me) discoveries. And, to tick the most obvious box, I chose a different "final ending" and changed the fate of the Nebula.
On the other hand: I visited all the same locations, and met all the same people (minus one extra, plus one surprise). I was heading to the same final destination all the time. In broad arc, I was playing the same game. Only every single detail was different, or potentially different.
In some sense Heaven's Vault telegraphs this. It's told in flashback, after all! The first scene you see is the final chapter: under the eye of a watchful god, you and your robot discover a sealed vault.
So you know that this is your final destination. Every possible variation of the story will lead there. You know that you will arrive with the robot. No story branch can end with your death, or the robot's disappearance or destruction. The game has to be about ordering and details.
(But I didn't think about that until the second run-through...)
What the game does best is care about these details, these large-or-tiny variations. You see this most clearly when you fire up a game-in-progress. It opens with a text summary -- a rundown of what you've done so far. Every reviewer praises this feature, but it's not easy to explain how stunningly smooth this summary is. It's not just a bullet-point list of everything you've done. That would be excruciating and unboundedly long.
No, what HV gives you is the story so far. It's the high points; no more than five lines, and they have arc. "You are searching for X, but you've also found Y, which has put you on the trail of Z." Cause and effect. The distinction between "and" and "but".
Furthermore, everything is described in terms of what you know. A location might be "an undiscovered Holy Empire site" or "a Holy Empire garden" or "a Holy Empire mausoleum", depending on whether you've explored it, what you've found, and what you've deduced. One site wound up with completely different descriptors in my first and second run-throughs, because the protagonist discovered slightly different evidence and then came to entirely different conclusions about what had occurred there.
This application of your game history is not just for the opening summaries, by the way. It extends through the entire design. Everything is described in terms of your present knowledge: map labels, navigation choices, references in dialogue. When you leave a site, your character reflects (out loud) on what she's done there and what she might do next. When you arrive in a familiar location, such as your university, she might comment on the tasks she expects to do there -- but only later in the game, when you've built up habits!
It's all powered by the same history-tracking engine, which stores and contextualizes everything from the broad arc of play to the moment-by-moment arc of a conversation. I mentioned the difference between "and" and "but"? You can see this when you're working through one of the linguistic challenges. "This word is right, and this other word is also right." Or: "This word is right, but this other word is wrong." To generate those sentences, HV needs to track successes and failures within the challenge. And the same, at macro scale, for the entire game.

I said my two run-throughs were similar. In some ways I tried to make them as different as possible. I looked at location X before location Y, instead of after. I took different tacks when overcoming certain difficulties. I drank heavily instead of abstaining in the bar.
But I didn't alter my basic approach to play. I was methodical, as I am in most games. I tried to search every location thoroughly, find every artifact, and read every inscription before I left. So it is not surprising that I found the same locations and made most of the same basic discoveries. It was all of the locations, so it was the same list! If I'd taken a hastier and more headstrong tack, I would have had a very different gameplay experience. A journey to the same ending, but with more gaps; no doubt filled by guesswork, perhaps with a very different final perception of how the world had gotten there.
(Less correct, you say? Based on less data, to be sure. But this is archeology: always guesswork in the end. There are always gaps. We'll never know the complete history of the Nebula, no matter how many times we play or how many wiki pages we fill.)
Nonetheless: two play-throughs, even two thorough play-throughs, are two different experiences. And it was striking (the second time!) how many differences derived from small changes of my focus or small differences in timing.
On one moon, I poked around exploring while the robot examined a device. Then, feeling done, I decided to leave. That was in the first run-through. Second run-through: I poked around exploring for a few minutes longer. Hey, says the robot of a sudden, just noticed something about the device! Which led to a question, which led to a conversation, which led to another trip, which led to a revelation that I'd had no clue about in my first session.
This revelation was one of the high dramatic moments of the session. Everything that followed was cast in the new terms that I had discovered. It was what the story was about, at least in part. And yet this moment was so easy to miss! In the first session, I blew right past it; I never knew there was anything to miss.
It wasn't even a choice, from my point of view. The game never presented a menu selection between "explore the moon for eight minutes" vs "explore the moon for ten minutes". It was just a thing I happened to do. And there were several more choices I had to make in order to stumble across this particular plot thread. I happened to ask person X about the robot's discovery, and then suggest plan Y...
If you frame this HV story line as a puzzle, a challenge for the player with story as the reward -- it's a blatantly unfair puzzle. Frame it as an achievement and it's even worse. "Stand here for N minutes, doing nothing, with no feedback"; players reach for their pitchforks.
HV has a few scenes with traditional adventure-game puzzles -- but only a few. To frame it as a puzzle game is just a mistake. You really have to view the game as a big bag of things the player might do. Some of these require patience and methodical search. Some require fiddling with mechanical controls and platforms. Some require treating NPCs in certain ways, or not treating them in other ways. Most require some combination of circumstances which you can't reasonably plan for, in your first game session or any other.
But if any given goal is so "unfairly difficult" to achieve, why play? Because the game isn't about all the stuff that you fail to notice. It's about the one thing you do notice. There's such a density of goals that you are very likely to achieve some of them. Whatever revelation or dramatic moment you reach -- that's what the story is about! ...For you; in that session; do you see? The history-tracking engine is able to seamlessly describe your particular discovery as the arc of the story.
That is to say: you're going to do something, indeed, a great number of things. You'll do the things that suit you as a player: exploring, or searching, or puzzling, waiting, negotiating, flirting. Something. And you'll find some astonishing secret. And whatever you find will be a reward for whatever you did.
This is hard to describe, isn't it? It sounds like a tautology when I say it. And yet I've never seen it done like this.
I grew up with puzzle-fest adventure games. Games that challenge you to do every single thing, and unlock the ending when you do it. Or to make a choice, and unlock the one ending (out of several) which is determined by that choice. Then we had the choice-based style and visual novels, which had branching structure all the way through. Lots of explicit choices, with implicit consequences, and variations of each chapter as you progressed.
More recently, we have the heap-of-side-quests game, like Sunless Skies or Inkle's previous hit 80 Days. In those games, you find a grab-bag of parallel micro-stories in a large universe. As in HV, the micro-stories you find follow what you happen to do; you have no hope of discovering or experiencing them all.
But HV goes beyond that bag-of-quests format. The story threads don't spread out into a haze of disparate starbursts. Every thread is part of the story of the Nebula; they all work towards that final chapter in the vault. And any handful of them make a story. I won't say they're all equally satisfying, but they all feel like plausible middles to that ending. There, that's my tag-line for the game. Forget multiple endings; we've entered the era of games with multiple middles.

Speaking of endings, this blog post probably ought to have one.
You understand that I am, necessarily, talking out my ear. I claim that the real value of Heaven's Vault is all the stories that I've never seen -- that I can't even tell where I missed seeing them. I've only played it twice! How could I even know?
Well, I recall Jon Ingold commenting that nobody can see more than 30% of the game content in a run-through. I know, it's cheating to believe what the designer says, but it fits with my experience. As I said, I've seen a couple of major revelations. I've also seen a few mysteries that I tried to plumb and couldn't. In my sessions, they were mysteries of the past, the lost foundations on which the story rests. But I have no doubt that some path leads down there.
Beyond that, I trust in probability. If I found a couple of treasures by unlikely chance, how many are there to find?

Wednesday, April 17, 2019

What is ZIL anyway?

The Infocom ZIL code dump has kicked off a small whirlwind of news articles and blog posts. A lot of them are somewhat hazy on what ZIL is, and how it relates to MDL, Lisp, Z-code, Inform, and the rest of the Golden-Age IF ecosystem.
So I'm going to talk a lot about it! With examples. But let's go through in chronological order.
The first version of Zork was MDL Zork. This is what Tim Anderson, Marc Blank, Bruce Daniels, and Dave Lebling wrote as MIT hackers around 1977 to 1979. MDL, the MIT Design Language, was a Lisp-like functional language created at MIT. MDL ran on the PDP-10, so that's where this ur-Zork ran.
Zork was ported to Fortran by Bob Supnik in 1980, and then to C. These versions, generally known as "mainframe Zork" (or "Dungeon") circulated among DEC user groups, wasted years of mainframe user time, and -- along with "mainframe Colossal Cave" -- changed the lives of many. (Including me, age 9 or so.)
At the same time, those MIT hackers formed a company and set out to... well, to make business software, if you look at those early plans. But they figured they'd first make a quick buck by porting Zork to home computers. However, MDL programs couldn't possibly run on an Apple 2 or a TRS-80. So the Infocom folks sat down and designed the Z-machine.
I'm not going to go through this story in depth. For that, I recommend Jimmy Maher's overview at the Digital Antiquarian. Here's the quickie: Infocom would write a game in ZIL, or "Zork Implementation Language" -- a high-level language derived from MDL. A compiler called ZILCH would then compile the game into a binary format.
The binary format, Z-code, was a program for an imaginary computer called the Z-machine. (Today we would say "virtual machine".) Nobody intended to build a Z-machine. But they could write a program that emulated the Z-machine. This program, called ZIP, was compact enough to run on a 16-bit home computer. So Infocom could distribute ZIP and the Z-code file on a floppy disk (or cassette tape!) and thus sell a playable game.
ZIL is not a mystery. We haven't had a lot of ZIL code available before this week. But someone scanned an Infocom ZIL manual years ago. You can read that manual here. (It's dated 1989, and primarily written by Steve Meretzky -- "SEM".)
But what kind of language is ZIL?
Above I said it was "derived from MDL". This is no surprise; the Infocom people wanted to reuse as much of MDL Zork as possible in their new commercial product. The resemblance is obvious, and indeed some of ZIL Zork was nearly identical to MDL Zork. Here's a function from the combat implementation in MDL Zork:
<DEFINE VILLAIN-STRENGTH (VILLAIN
                      "AUX"  (OD <OSTRENGTH .VILLAIN>) WV)
    #DECL ((VILLAIN) OBJECT (WV) <OR FALSE VECTOR>
           (OD VALUE) FIX)
    <COND (<G=? .OD 0>
           <COND (<AND <==? .VILLAIN <SFIND-OBJ "THIEF">>
                       ,THIEF-ENGROSSED!-FLAG>
                  <SET OD <MIN .OD 2>>
                  <SETG THIEF-ENGROSSED!-FLAG <>>)>
           <COND (<AND <NOT <EMPTY? <PRSI>>>
                       <TRNN <PRSI> ,WEAPONBIT>
                       <SET WV <MEMQ .VILLAIN ,BEST-WEAPONS>>
                       <==? <2 .WV> <PRSI>>>
                  <SET OD <MAX 1 <- .OD <3 .WV>>>>)>)>
    .OD>
And here's the same code from the ZIL version:
<ROUTINE VILLAIN-STRENGTH (OO
                       "AUX" (VILLAIN <GET .OO ,V-VILLAIN>)
                       OD TMP)
     <SET OD <GETP .VILLAIN ,P?STRENGTH>>
     <COND (<NOT <L? .OD 0>>
            <COND (<AND <EQUAL? .VILLAIN ,THIEF> ,THIEF-ENGROSSED>
                   <COND (<G? .OD 2> <SET OD 2>)>
                   <SETG THIEF-ENGROSSED <>>)>
            <COND (<AND ,PRSI
                        <FSET? ,PRSI ,WEAPONBIT>
                        <EQUAL? <GET .OO ,V-BEST> ,PRSI>>
                   <SET TMP <- .OD <GET .OO ,V-BEST-ADV>>>
                   <COND (<L? .TMP 1> <SET TMP 1>)>
                   <SET OD .TMP>)>)>
     .OD>
Pretty similar, right? But under the surface, rather different things are going on.
MDL is a functional language in the Lisp vein. Pretty much everything boils down to linked lists. Executing a program means freely constructing and throwing away lists, so there must be a garbage collector behind the scenes. The MDL compiler does what it can to eliminate memory allocation; efficient MDL code might be compiled to static machine code. But if the compiler can't do that, you wind up allocating stuff on the heap.
But the Z-machine doesn't have a garbage collector. It has no primitive operations for constructing lists or allocating objects. There are no Z-machine instructions for finding the head and tail of a list. (The famous car and cdr primitives of Lisp, called 1 and REST in MDL. The Z-machine don't have 'em.)
(You may know that I wrote a small Lisp interpreter for the Z-machine. It was fun, but the Z-machine gave me no help at all! I had to build the Lisp heap and list data structures myself, out of primitive Z-machine byte arrays. Same with the garbage collector. It's all terribly inefficient and janky.)
So how does ZIL perform these operations? Answer: it doesn't! As far as I can tell, the ZIL Zork code doesn't use Lisp-style (linked) lists at all. The 1, NTH, and REST functions appear only rarely, and I believe they always apply to static strings or arrays. MAPF, a basic Lisp tool which transforms one list into another, doesn't appear at all.
In contrast, the MDL source is filled with 1, NTH, REST, MAPF, and other functional-language constructs.
So in one sense, ZIL is a completely different language from MDL. It's a C-like compiled language which operates entirely on fixed data structures. But in another sense, as you can see from the examples above, they're almost identical! How does this make sense?
My answer is that game logic is a fairly narrow sort of programming. The combat example sets some local variables and looks up some object properties (fixed data structures!). It compares numbers; it compares variables to objects. And there's a bunch of "if" statements with "and"s and "or"s. Familiar, right? There are dozens of ad-hoc game scripting languages with similar features. You don't use a language like that to solve graph-theory problems, much less build a compiler.
(The Ancient Terror puzzle in Enchanter does involve some graph theory, but this is implemented with some rather clunky nested loops. Not a Lisp-y solution at all.)
It's not that functional methodology is impossible in ZIL. The language clearly imports as much of MDL's functional model as it can. It's just that this isn't very much. ZIL has about as much of MDL as can be compiled into static (non-allocating) code. Which makes sense -- that's exactly what the ZILCH compiler did.
To bring the story up to the present... In 1993, Graham Nelson released Inform. This language (and compiler) had exactly the same goal as ZIL: to efficiently compile source code into Z-machine files. Graham didn't have access to any information about ZIL at that point, so he just made up his own language, which was mostly like C because that's what he was familiar with.
(Of course C itself was designed to run efficiently on fixed data structures. So Graham had an easier job, in some sense. Not to take anything away from his accomplishment!)
Inform (up through version 6) became the cornerstone of the Z-machine ecosystem. But the Z-machine had some hard limits; it had been designed for 16-bit microcomputers and could not easily be expanded. So by 1997 there was a clear need for a new virtual machine. This is where I come into the picture. I designed Glulx as a replacement VM.
Amusingly (or ironically, or inevitably), Glulx had one core goal: to efficiently compile Inform 6 code to a new virtual machine. Every line of I6 code had to work essentially the same as it had before. Glulx used 32-bit values instead of 16-bit values, and I reorganized the memory layout and the instruction table. But the core data structures looked very much like those of the Z-machine.
As a result, it should be possible to compile ZIL to Glulx! I don't think anybody's done it. But Glulx was shaped by I6, I6 was shaped by the Z-machine, and the Z-machine and ZIL were shaped by each other. The chain of influence extends all the way from Joel Berez's coffee table to mine.
Inform 6 was followed by Inform 7, a completely new language which compiles to Inform 6 source code. At least for now. Future versions may compile to a new abstraction. But that's a story for another time.
Footnote: my conclusions about ZIL have to be qualified: I could be wrong. I don't know ZIL or MDL, really. I have an MDL programming guide open as I write this...

EDIT-ADD:
Given the MDL and ZIL code examples above, I thought it was worth adding the Inform 6 equivalent. This is from Allen Garvin's hand-polished I6 port of the ZIL code.
[ VillainStrength oo villain od tmp ;
    villain = oo-->0;
    od = villain.strength;
    if (od >= 0) {
        if (villain == thief && Thief_engrossed) {
            if (od > 2) {
                od = 2;
            }
            Thief_engrossed = false;
        }
        if (second && second has weapon && oo-->1 == second) {
            tmp = od - oo-->2;
            if (tmp < 1) {
                tmp = 1;
            }
            od = tmp;
        }
    }
    return od;
];
If you check, this is line-by-line equivalent to the ZIL version above. But it's much more readable to modern eyes, isn't it?
To some degree, this is just because I6 is part of the C-derived family of languages. (I'm told that "Algol family" is a better term, but I've never touched Algol.) This includes C, C++, C#, Javascript, Perl, Swift... very different languages, but they all share the basic assumption that if (X) print(Y) is a sensible way to write code. A programmer these days might never have used any other kind of language.
I6 follows C very closely, in this example. The only quirks are:
  • the --> operator (for arrays, where C would have oo[0], oo[1], oo[2]);
  • the has operator (for testing object flags; in ZIL this was FSET?);
  • defining functions in square brackets, which is idiosyncratic.
Everything else is expressed in ways that look completely natural. Mind you, the lower-case text helps a lot. But we're very used to code where identifiers are text, operators are (mostly) punctuation, and one line of code is conventionally one abstract step of procedure.
In 1979, for people brought up on Lisp, MDL probably wasn't as strange. No doubt they would say that it's much simpler to put the operator at the beginning of every call (<SET OD .TMP> rather than od = tmp;). Test operators always end with ?, whereas in the I6 code you have to look for an if to figure out whether you're performing a test. The difference between period and comma as atom prefixes is no doubt a concise way to express something (which I haven't bothered to look up what it is). And so on.
I still think the lower-case code is easier on the eyes, but hey.

EDIT-ADD 2: Tim Anderson has kindly sent along a lot of details about MDL -- or Muddle, as I should be calling it. I include his comments verbatim below.
A few comments on Muddle, ZIL, and their friends:
Although the original PDP-10 Zork was written in Muddle, it was, unintentionally, much closer to ZIL (which didn't exist yet, obviously) than it had to be. There were a few reasons for this:
  • Lisp-ish languages were, by outsiders, thought to be inherently slow, so it was a point of pride to write code (and build a tool chain) that disproved this. (There was a benchmark done with some math-heavy computation where compiled Maclisp was faster than FORTRAN, on the same hardware.) A lot of things in the Zork code were there at least in part because of this.
  • The basic objects (rooms and so on) were not lists, they were vectors (or perhaps templates; the difference was slight)--each object was a block of contiguous memory, much like a C struct. Quicker access to the elements, smaller memory footprint, and--much closer to the data structures you'd find in C, or ZIL.
  • There was a lot of effort put into not provoking the garbage collector (No consing, please, this is Lisp!). The Muddle garbage collector, when it ran (there was a lot of innovation in garbage collection later, but this was 1977), just stopped processing for a while, made a clean, compact copy of the heap, replaced the old one with that, and let you continue. This could take several CPU seconds, which on a time-sharing system could turn into a really long long time--very bad for interactive game play. In addition: the machine being used had a 256K word address space, with 512K of physical memory, and was supporting 10, sometimes 20 users. Keeping the memory footprint down was a good way to keep your friends: as much as possible of the code was in read-only memory--allowing it to be shared between processes, and ensuring that there was a clean separation later on, in ZIL. And avoiding dynamic memory allocation reduced the really significant load produced by the garbage collector.
  • As Jesse mentions in the comment about macros, they provided full access to the Muddle interpreter at compile time, and were certainly used in the original Zork as well as later on. The only memory saving produced by compilation was the elimination of macro expansion at runtime (in Muddle, as in Lisp, a call to a macro would be evaluated twice: first to run the macro, which returned some freshly consed-up code, then to evaluate that; the compiler did the first step at compile time, then compiled the result). Muddle, like Lisp, had as its basic function EVAL, which ran the interpreter on a single piece of uncompiled code. Zork never called that--slow, prone to unexpected consing, and so on. So it didn't get in the way when moving to ZIL (or to FORTRAN); everything that was running in Zork was compiled, which limited the bad (inefficient, difficult to port) things that Muddle supported in the interpreter.
  • Each Muddle atom could have two values--a global, and a local (,FOO was syntactic sugar for <GVAL FOO>; .FOO, <LVAL FOO>). Locals, as with Lisp, had dynamic scope--in interpreted code, functions called from within an invocation of MYFUNC could access any locals bound within MYFUNC (assuming that no intervening function had another binding of them, of course). In compiled Muddle, though, local variables that needed to be accessed from outside the function itself had to be declared SPECIAL; any other locals ended up having, in effect, static scope within the body of the defining function. Zork used no specials: it made for faster, and, honestly, more understandable code. And also made it easier to port to statically-scoped languages.
  • The Muddle compiler acquired some intrinsics to allow direct (single machine instruction) access to the key parser output variables PRSA, PRSO, and PRSI. This was a different way of thinking about things, and again required a bit more discipline.
  • It was unnecessary to declare the type of anything in Muddle, but that would make the compiler's job much harder, and reduce performance. So pretty much every variable, and every field in the Zork objects, had a type declaration associated with it. Faster code, but also easier to port to a language without dynamic types.
  • MAPF (or its friend, MAPR--map First vs. map Rest) was probably used in Zork somewhere, but not in the most general form, where it constructed a new list; rather, it was an easy way to iterate over a list. In that form, it would be relatively easy, if it came to that (I don't think it did), for Zilch to do something sensible, or even to write a macro that would construct the iteration at compile time.
The virtual machine used for Cornerstone was quite a bit more powerful than the Z machine. There were a few reasons for that:
  • It was required. A nearly-relational database, with what passed for a GUI in those days, had need of a lot more functionality than a text adventure.
  • The minimal target hardware was something like a PC-AT (maybe an XT): hard drive, 640K of memory, etc. There was no need to run on an Apple II or a Commodore 64.
  • Infocom had a fair amount of experience with these things by then.
  • Not to be invidious, but the people building the tool chain for Cornerstone were better at that kind of development (years of experience, and it was their primary job--not true with ZIL, except for the people building the individual Z machine implementations) than those defining ZIL and the Z machine. They weren't as good at writing games, though, so it worked out.
(-- Tim Anderson)

Tuesday, April 16, 2019

All of Infocom's game source code

I can just leave that statement there, right? I don't have to elaborate? Jason describes it better than I could, anyhow:
So, Infocom source code is now uploaded to Github. Most people don't speak or want to speak the language it's written in, ZIL (Zork Implementation Language). You can browse through it and kind of suss out what's being done when and the choices made over the course of time.
In cases where the source code had multiple revisions, and I don't know the story of what revisions came when and came why, I did a reasonable job of layering them out (this came before that, that came after that) and doing multiple "check-ins" of the code so you can see diffs.
Often, there are cases that some games were built up from a previous game, allowing modification of the macros and structures and then making them work in the new game. For example, an NPC partygoer in one game was a thief in a previous one. Dungeons become stores, etc.
--@textfiles (Jason Scott), from a twitter thread
This material has been kicking around for a while now. If you search for articles about "the Infocom drive", you'll see some discussion from years past. Actually, don't do that, it's mostly old arguments that don't need to be rehashed.
The point is that a great deal of historical information about Infocom has been preserved -- but it's not publicly archived. You can't go research it anywhere. Nobody admits to having it, because it's "proprietary IP", and you're not supposed to trade in that stuff because companies like Activision make the rules.
So when Jason puts this information online, he's taking a stance. The stance is: history matters. Copyright is a balance between the rights of the owner to profit and the rights of the public to investigate, discuss, and increase the sphere of culture. Sometimes the balance needs a kick.
Quite possibly all these repositories will be served with takedown requests tomorrow. I'm downloading local copies for myself tonight, just in case.
One other note: Jason's comments say "...there is currently no known way to compile the source code in this repository into a final "Z-machine Interpreter Program" (ZIP) file." This is somewhat out of date. There are long-standing open-source efforts to build a ZIL compiler. ZILF is the most advanced one that I know of. I don't know whether it's rated to compile this historical ZIL code -- but I'm sure that people are already giving it a shot.