[I7] Thoughts on game presentation

[Andrew Plotkin]

On Wed, 6 Feb 2008, Andrew Hunter wrote:

> The thread on raif about packaging games has had me thinking about how to add 
> this as a feature to Zoom. My first thought was to automatically add files in 
> a particular subdirectory of the Resources folder to the iFiction window. 
> This would be far from ideal, though - the user would be presented with a 
> list containing a single game, and would work out that they need to 
> double-click it.
>
> This does address a particular issue with packaging games, though: the 
> interpreter is often much larger than the game itself (especially with 
> multimedia interpreters like Zoom), so packaging games on a one-shot basis is 
> very wasteful. Packaging them with a complete interpreter is a lot better, 
> especially when the player can just click the 'Find More' button to go to the 
> IFDB and find similar games.
>
> Ideally, we'd like a packaged game to start up immediately, or at least 
> present itself in its own way, so when the player starts up the interpreter 
> for the first time they are presented straight away with the game they 
> downloaded, with the seamless ability to find more later on. My thoughts on 
> how this should be achieved is where the compiler comes in. Games that wish 
> to be packaged in this way should provide a new blorb chunk that contains an 
> HTML title page (and an arbitrary number of extra 'files' to contain images, 
> style sheets, etc - these could be accessed through a scheme similar to the 
> inform:/ URLs we use to access documentation at the moment). This would 
> effectively be an extension to the cover image system already in place.
>
> The interpreter, on finding it has a library of exactly one game containing a 
> title page would display this by default instead of the list of games. The 
> user would click a link, or press a key, and be taken to the game itself. 
> Once they'd played the game, they could use the same page to navigate to the 
> 'related games' in the IFDB: perfect for introducing newcomers to IF.

I am not fond of this scheme, because it doesn't do a good job of the 
original problem -- making something which looks like a standalone
game application to the user. You wind up with an app called "Curses" (or 
whatever), which *starts* by playing your game, but then (apparently by 
itself) morphs into a player for a list of the games you've looked at. Are 
they all Curses? If I download another standalone application, why does it 
list the same games as before plus one more? Which one do I throw away?

I think my old MaxZip UI is still applicable. I don't *care* that 
downloading ten megabytes of interpreter with each game is wasteful. 
That's not what the user cares about.

(I've played about five of Mateusz Skutnik's "Submachine" Flash games. Do 
you know how much of each one was reused library code, or reused sound 
files, which I downloaded five times for no reason? Yeah, neither do I.)

Actually the MaxZip UI can evolve a little, since disk space and bandwidth 
are cheaper now than in 1994. The binding path is the same: Zoom provides 
a menu option "Export Bound Application..." This creates a copy of the 
Zoom application, with the game file stuffed into Resource. The clone 
would also be tweaked to not be a handler of game file types. (Maybe it 
*would* handle save-game files, but only of its own game.)

When I download and run this bound app, it quietly copies the game file 
into my home directory. (This is so that if I run plain Zoom someday, I 
see the game listed.)

The question is then, how do I transit from the bound app to plain Zoom? 
As I said, it's more important that this be clear than efficient. Maybe 
have a menu option for "Browse more games..." which brings up a page 
containing IFDB listings *and* a link to Zoom. Or the page could have a 
button for "Install the Zoom IF player..." which would clone the bound app 
back into Zoom.

> There's a further step, though. While thinking about embedding HTML in 
> games, I started wondering about doing the opposite: embedding the game 
> in HTML.

I have no comment on this beyond "Sounds reasonable." Stuffing HTML, CSS, 
and Javascript into the Blorb makes sense.

> It would also be possible to embed the game on an actual webpage using 
> the same technique, but people are really quite averse to installing 
> plugins in my experience.

In mine too.

I have a long-backburnered plan to implement GlkWebApp. That would require 
a server-side script, but then the game would be a plain old dynamic web 
site on that server.

--Z

-- 
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
9/11 did change everything. Since 9/12, the biggest threat to American
society has been the American president. I'd call that a change.