Inform 7: Some thoughts on publishing
JDC
future developments", but I thought I'd put it in a separate thread
since it covers my experience with finishing and publishing works with
I7 rather than the language itself. For the record, I have released
two works with I7 (Möbius in this year's Comp, and The Retreat for the
IF Dreams mini-comp), both relatively short. Since I spent much more
effort on the first of these, most of my comments are drawn from it.
Overall I have found I7 very pleasant to work with, and coding about
as close to painless as I have experienced. This is not a minor point;
there are a lot of unpleasantries in bringing any sort of project to
completion, and minimizing them might be the difference between some
works being finished or not. But more importantly, it probably makes a
difference in quality of a released work if testing and polishing it
is easier. The testing and indexing facilities of the IDE are probably
the ones I find the most useful. Starting a project is also easier (or
at least more appealing) in I7 than it was in I6. I had learned I6
well enough that I intended to begin something substantial in it this
summer had I7 not been released, but I found myself delaying and
setting up preliminaries rather than diving into the actual writing.
I'm sure this is a matter of inexperience (or the excitement
surrounding the release of I7), but I found it much easier to get into
the heart of a work with I7. Hence, I have been more apt to start
things in I7, which of course is a key step in finishing them...
But onto some specifics:
* Inform 6 code inclusions
Emily Short wrote:
> Inform 6 users reacted to the first sight of I7 by
> trying to safeguard existing capabilities: wanting to be assured that
> it is possible to write hybrid I6/I7 works, to include verbatim I6
> code, and so forth. Today many users have solid experience of writing
> medium-sized works with I7, and low-level I6-interface features are
> talked about less.
This was a concern of mine. I remember people initially discussing the
possibility of using I7 to initially create an I6 file and then
working with it in I6; this passed quickly and I'm certain no one has
actually done it. But I6 inclusions seem to still be necessary. I used
a number of I6 inclusions in Möbius (for drawing the status line,
storing and replaying actions, switching articles and the proper
attribute during play, checking whether acting silently, forcing
output to prevent long delays during extended waiting, and stripping
commas from input). The action storing was of course fundamental, but
the rest were primarily cosmetic. This sort of tweaking is generally a
bit low-level and fiddly, so I don't see it as a significant weakness
(particularly as I know enough I6 to handle most of it, and the kind
folks at raif helped with the rest) and having the ability allowed me
to indulge my control-freak tendencies in polishing. I am developing
some sort of strange aesthetic avoidance of I6 inclusions whenever
possible, though.
* Replay, skein, and transcript
I use the Replay feature extensively and find it indispensable. Being
able to quickly check the result of a change while playing makes it
much easier to fix bugs as I find them. I also find myself using a
sort of "trial-and-error" approach to experiment with output,
tinkering with it until it looks the way I want (things like the
ordering of responses, location of paragraph breaks, and other more
visual aspects). I also used test scripts to quickly get to certain
points in the game (past the intro, and to the ending, mainly).
I did not make extensive use of the skein or transcript. Part of the
reason for this is that Möbius is essentially linear so I had one line
to test, and I found it faster to use a test script to skip the
beginning rather than using a skein node (also, since the game
"reset", I could test several things in one playthrough without having
to restart). I didn't use the transcript feature much at all; part of
the reason was that there is a tiny amount of randomized text
generation and I kept forgetting to start with "random", so I would
see these differences highlighted (It just occurred to me that it
might be a useful feature in the IDE to be able to set the random-
number generator to predictable somewhere, maybe a check-box in the
transcript pane, to deal with this more easily). I also tended to test
very "locally", checking specific features one at a time rather than
in extended plays.
In retrospect, I wish I had used the transcript feature more, and
blessed some test scripts before making bug-fixes; this would probably
have caught a couple of bugs I introduced while making post-beta-test
changes. I need to train myself to use this more in the future.
On a related note, I found the syntax of I7 made automatic spell-
checking much easier since there were very few non-English words which
were flagged. As a result of this (and Replay) I think I was able to
give my testers a much cleaner game than I might otherwise have (now,
if I7 could just find my conceptual errors for me...).
I could see the addition of some more debugging features being helpful
(being able to watch variables, set breakpoints, etc.), but this
hasn't been a big issue for me; I tend to just add some debugging code
to print out variables as needed; being able to Replay after adding
this sort of thing makes it a bit easier.
* The Index
The index is very useful. It probably took me a couple of months to
really remember to use it, but now it's second nature. Particularly
for looking up actions.
* Cover art
I actually have some mixed feelings about cover art, owing mainly to
my utter lack of artistic skill. I included cover art with Möbius, but
it was basically created with parametric equations entered into a
graphing program. Unless my next work is entitled "Klein Bottle" or
"Torus" or something, I'll have to (a) forego cover art, (b) learn to
draw, or (c) find someone to do the artwork for me. I like the idea of
cover art; I think it can present some flavor, it makes a web-site
dramatically more appealing, and it's just generally kind of cool.
Particularly as advertisement on a website, I think it's something
that can help encourage outsiders to try IF. Once I had the cover art,
I7 made adding it very easy; in some ways I almost felt obligated to
add cover art given how easy it was to include.
I imagine there are many IF authors who, like me, are not talented
visual artists. And who, like me, are individualistic and like being
able to create a work on their own. In this respect I would not want
to see cover art regarded as a necessity, so that people feel obliged
to include some clip art with their title pasted over it (granted,
that's more or less what I did). Fortunately, there has been at least
one person who has offered his artistic services for IF cover art;
hopefully there will be others, or at any rate some sort of resources
developed for linking artists with authors. Cover art a being
relatively feature, I imagine it will take some time for some standard
practices arise (akin to what happens with beta testing now, perhaps).
I do have some misgivings about commissioning art for a work which has
been created with otherwise free tools (although I would consider it
for a project which I felt really rose to a more professional level).
* Bibliographic data and blorbs
Emily Short wrote:
> The wariness of I7 authors entering the
> 2006 IF competition - they mainly steered clear of blorbed story files
> with cover art - reflects that I7's default story file format, though
> based solidly on existing formats, is not yet widely accepted. This may
> be because Treaty of Babel-compatible interpreters and IF browsers are
> not yet widely used. We hope to do more in 2007 to champion
> interpreters and IF browsers which are cross-IF-virtual-machine, and
> which make IF generally more like iTunes and less like /usr/bin.
I think I probably would have simply released a .z8 file rather than a
blorb if I hadn't included cover art, for this reason. I recall that
one of my testers asked if I could provide him the .z8 to test on a
handheld, but I don't know how many people use interpreters which do
not handle blorbs (or how difficult it is to unblorb); I myself use
Zoom and Spatterlight almost exclusively now (but I do confess to
having installed terminal frotz on the Sun in my office, purely for
emergencies), and it's nice to have the metadata.
* Websites
Emily Short wrote:
> One thing I've wondered about is whether it would be useful to offer a
> website template that would make it easier for people to put up their
> games on the web for browser play; the problem there, though, is that
> even if we autogenerated the necessary html, the author would still
> have to install zplet or ZMPP or a Glulx java terp on his website; not
> hard, but not quite a one-click process that we can automate from
> within I7. And then, too, zplet and ZMPP aren't as flexible about
> saving and other goodies as one might like, so they're still not a
> complete solution to the web-mounted game problem.
I toyed with the idea of adding this to my website; one problem I
found was that the display didn't quite work correctly (I think there
was some weirdness with the status line or menu displays) so I took it
down, intending to possibly some day work out a modified version for
online play (which will likely not happen anytime soon...). I think
you would probably need to ensure you had a browser interpreter that
behaved pretty close to the built-in ones before automating it within
I7 (ideally you might want to include it in I7 and then the
interpreter could simply be bundled into the website folder). At this
point I would say that people who can get an interpreter installed on
their websites can probably get an interpreter installed on their
websites.
* Some random tidbits that might help with publishing, or might not,
and are wildly speculative in any event
- It might be useful to automate submitting to the ifarchive,
something like "Release to ifarchive". Then again, this might be
dangerous.
- The ability to create custom icons for games.
- Automatically bundling games into executables. Certainly
problematic, since they wouldn't be cross-platform, but this might
help to package games to make them more accessible to the general
public.
Anyways, I think I'll stop with this pretty rough summary; I can
elaborate on any particular issues of interest.
-JDC
Emily Short
> Emily Short wrote:
> > One thing I've wondered about is whether it would be useful to offer a
> > website template that would make it easier for people to put up their
> > games on the web for browser play; the problem there, though, is that
> > even if we autogenerated the necessary html, the author would still
> > have to install zplet or ZMPP or a Glulx java terp on his website; not
> > hard, but not quite a one-click process that we can automate from
> > within I7. And then, too, zplet and ZMPP aren't as flexible about
> > saving and other goodies as one might like, so they're still not a
> > complete solution to the web-mounted game problem.
>
> I toyed with the idea of adding this to my website; one problem I
> found was that the display didn't quite work correctly (I think there
> was some weirdness with the status line or menu displays) so I took it
> down, intending to possibly some day work out a modified version for
> online play (which will likely not happen anytime soon...).
Hm, plausible. Personally, I don't like the way the status line
usually looks on a website: it feels clunky and ugly if there's any
other kind of artwork or design to the page. I have been experimenting
with this and wound up recompiling Damnatio Memoriae and Glass to
remove the status line entirely -- not a huge deal given that both
games are tiny and neither has much important information up there.
(You can see the results linked from http://emshort.wordpress.com/my-
work if you're interested. This is also the reason I wrote the
incredibly-tiny status line removal extension, whose entire purpose is
to strip the status line out of z-code games. I used ZMPP to display
these two games rather than zplet because I prefer ZMPP's font
rendering.)
Now you mention it, though, I bet the help menus in DM are broken in
this format. Hm. Maybe I'll try removing them, too, since in the web
version there's a link to other how-to-play instructions. Still, it
does feel like cheating to take out bits out of the game because the
web interpreter handles them badly. I've also found, even in these
very short games, that it is frustrating to play with no scrollback at
all. So I don't know. I'm not wholly satisfied so far.
Anyway -- still thinking about the rest of it, but thanks for this.
Stephen Granade
> * Some random tidbits that might help with publishing, or might not,
> and are wildly speculative in any event
>
> - It might be useful to automate submitting to the ifarchive,
> something like "Release to ifarchive". Then again, this might be
> dangerous.
I would suggest not. On rare occasions we have had to fiddle how files
are submitted to the archive, and that could break such a submission
mechanism. At this point I hope that our submission web interface is
easy enough that the barrier for submitting is low.
Stephen
--
Stephen Granade
stephen...@granades.com
mikegentry
> problematic, since they wouldn't be cross-platform, but this might
> help to package games to make them more accessible to the general
> public.
Yes. Please.
Tim Howe
Only as long as, like self-extracting ZIPs, there is a way to manually
pull the game back out of the executable so as to play it on another
platform.
--
vsync
http://quadium.net/~vsync/
READ CAREFULLY. By receiving this email you agree, on behalf of your
employer, to release me from all obligations and waivers arising from
any and all NON-NEGOTIATED agreements, licenses, terms-of-service,
shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure,
non-compete and acceptable use policies ("BOGUS AGREEMENTS") that I
have entered into with your employer, its partners, licensors, agents
and assigns, in perpetuity, without prejudice to my ongoing rights and
privileges. You further represent that you have the authority to
release me from any BOGUS AGREEMENTS on behalf of your employer.
For further details please visit http://www.reasonableagreement.org/
JDC
> "mikegentry" <m...@edromia.com> writes:
> >> - Automatically bundling games into executables. Certainly
> >> problematic, since they wouldn't be cross-platform, but this might
> >> help to package games to make them more accessible to the general
> >> public.
>
> > Yes. Please.
>
> Only as long as, like self-extracting ZIPs, there is a way to manually
> pull the game back out of the executable so as to play it on another
> platform.
Yeah, I was thinking of this as a supplement to the regular game file,
maybe in connection with a website. Something like "Release along with
a website including Mac and Windows executables".
-JDC
JDC
> On Feb 5, 1:30 am, "JDC" <j...@psu.edu> wrote:
> > Emily Short wrote:
> > > One thing I've wondered about is whether it would be useful to offer a
> > > website template that would make it easier for people to put up their
> > > games on the web for browser play; the problem there, though, is that
> > > even if we autogenerated the necessary html, the author would still
> > > have to install zplet or ZMPP or a Glulx java terp on his website; not
> > > hard, but not quite a one-click process that we can automate from
> > > within I7. And then, too, zplet and ZMPP aren't as flexible about
> > > saving and other goodies as one might like, so they're still not a
> > > complete solution to the web-mounted game problem.
>
> > I toyed with the idea of adding this to my website; one problem I
> > found was that the display didn't quite work correctly (I think there
> > was some weirdness with the status line or menu displays) so I took it
> > down, intending to possibly some day work out a modified version for
> > online play (which will likely not happen anytime soon...).
>
> Hm, plausible. Personally, I don't like the way the status line
> usually looks on a website: it feels clunky and ugly if there's any
> other kind of artwork or design to the page. I have been experimenting
> with this and wound up recompiling Damnatio Memoriae and Glass to
> remove the status line entirely -- not a huge deal given that both
> games are tiny and neither has much important information up there.
> work if you're interested. This is also the reason I wrote the
> incredibly-tiny status line removal extension, whose entire purpose is
> to strip the status line out of z-code games. I used ZMPP to display
> these two games rather than zplet because I prefer ZMPP's font
> rendering.)
If this were to become a common thing, it might be useful to allow
contingent sections of the source to make creating alternate versions
easier. Something like:
Section 1(a) - For standard game only
<status line, menus, etc.>
Section 1(b) - For online game only
<remove status line, other stuff that you want different>
I imagine this wouldn't be too difficult to implement since there's
already a hook for Z-code vs. Glulx sections of the source.
-JDC
Emily Short
> one problem for me is that the cover art cannot afterwards be treated
> as a normal image - you cant assign a "figure name" to it then display
> it somewhere else. to do so, you have to make a second copy of it and
> give it a different name. also, the cover art is never displayed in
> the index, but other images are. this is inconsistent to me.
I seem to recall there being a technical reason.
I do not recall what the technical reason was.
As a separate point, though, I suspect that cover art at full size is
usually going to be larger than you want in-game images to be. (This
does not really answer your objection about consistency.)
> > Emily Short wrote:
> > > The wariness of I7 authors entering the
> > > 2006 IF competition - they mainly steered clear of blorbed story files
> > > with cover art - reflects that I7's default story file format, though
> > > based solidly on existing formats, is not yet widely accepted.
> > I think I probably would have simply released a .z8 file rather than a
> > blorb if I hadn't included cover art, for this reason. I recall that
> > one of my testers asked if I could provide him the .z8 to test on a
> > handheld, but I don't know how many people use interpreters which do
> > not handle blorbs (or how difficult it is to unblorb);
>
> big problems finding compatible interpreters for me. especially as
> even the built-in interpreter doesnt have full support for images, or
> any support for cover art.
Given that cover art is usually displayed in a kind of "Info about
this game" dialogue box, I'm not sure what it would look like for
Inform 7 to support this feature -- you don't have a game browser to
look at a bunch of different games, just the one you're currently
compiling. What did you have in mind?
> gargoyle doesnt support it well either.
> winglulxe is good but doesnt do cover art. so currently there is no
> "perfect mix" interpreter. and then there's sound...
The sound issue we hope to address later.
Other interpreter problems may be reason to contact the 'terp authors
-- as has been pointed out on other threads, authors of interpreters
don't always know about bugs/desired features unless they're
specifically told.
> has everybody seen this website:http://www.smallwhitehouse.org/archive-games.html?
>
> " Play games directly from this mirror of the IF Archive on your
> browser. Restricted to Inform, TADS, and Glulx games with story files
> ending in .z3, .z5, .z8, .gam, .blb, or .gblorb. "
It's a neat idea; it's also, I think, not quite how I would want to
introduce IF to people online, if I were doing this for the general
public. The look is too minimal, and browsing games from the list is
unfriendly, if you don't already know what the files are likely to be.
> > - It might be useful to automate submitting to the ifarchive,
> > something like "Release to ifarchive". Then again, this might be
> > dangerous.
>
> i would like the inform-fiction.org site itself to host the automatic
> webpages created for games. crazy huh?! not all authors have access
> to, or know how, to run their own website. i'd like to see a few extra
> options in the publishing steps to "upload" the completed webpages,
> along with the storyfile, directly to inform-fiction.org, where it
> would be held in a "games available" section or somesuch. would
> certainly be more enticing for prospective players than the current
> ifarchive site (although it wouldnt replace it, just an extra avenue).
Mumble mutter hrm. Having thought about this: I personally would be
sorry to see the Inform site trying to compete in any way with the IF
Archive / Baf's Guide / etc. as a means of finding IF. For one thing,
it would give people another place they'd have to check for new
releases; in the ADRIFT community, a lot of games get uploaded only to
the ADRIFT site and not to the IF Archive, which contributes to the
partial segregation of those authors. (There are other things that
contribute as well, but having a centralized repository for publishing
IF seems like a good thing.) I realize you're not proposing to abolish
that, but I don't know whether it would be easy to guarantee that
everything published on the I7 site was also listed at Baf's, so we
would probably have some effective disparities whether we wanted them
or not.
Aside from that, we don't really have the resources to run such a
thing right now; we'd need a volunteer maintainer (not me or Graham)
and some new submission process by which people could put up their
pages, and... well, I see what you're getting at, but I think a better
way may be to focus on improving the front end of the archive and the
publication possibilities there.
> > - The ability to create custom icons for games.
(I assume what you mean is, the ability to assign some previously-
created icon to a game -- I'm sure we're not going to build in an icon-
editor.)
I have absolutely no idea how feasible that is. My impression is that
it's pretty easy to affix icons to Mac OS X files, but I don't know
about Windows, and I could also just be Wrong. I kind of like the
notion, though.
> > - Automatically bundling games into executables. Certainly
> > problematic, since they wouldn't be cross-platform, but this might
> > help to package games to make them more accessible to the general
> > public.
>
> definitely agree with this. but it wouldnt "replace" the the .z*
> creation, just add an extra *.exe file alongside it. so no issues with
> cross-platform, just an extra option for pc users. and presumably the
> same option for mac users. this would certainly help get more players
> - never underestimate the "dumbness" of pc and max users! other
> platform users would be presumed to be a bit more tech-y so wouldnt
> need this, but it would certainly help in the pc and mac market.
Hm hm hm hm hmtehm hm.
Two possible objections arise; maybe more. [Note: these are my own
opinions; I haven't discussed this with the rest of the I7 team.]
The first is a tactical/publicity objection. I can see that it is
easiest to hand a complete novice an executable without any of this
interpreter/game file dichotomy. But as soon as you are giving them
games 2, 3, 4, etc., it is more desirable that they have an
interpreter like Zoom or Spatterlight that can keep track of and run a
whole set of different games. What's more, the game file (if properly
tagged) should be a single-click to launch, even if you do have to
have the application on your computer as well. So perhaps offering
people a zip of game + interpreter would be better, in the long run?
The second is that if we built the executable-exporting stuff *into*
I7, we'd have to keep updating every time the interpreters changed;
for now, while things are in beta, we're releasing a new build every
few weeks/month anyway, but later it might become cumbersome to keep
up. Besides which, it is the nature of people that not everyone would
*like* the interpreter we chose, and want to package their file with a
different one instead; in which case, they're back to square one.
Back in the day, when I still ran Mac Classic, I recall that MaxZip
could at any time export an executable version of the game it was
running. That was easy, tidy, and cool; I used it a fair amount when
distributing games to less IF-savvy friends. To the best of my
knowledge, no modern interpreters do this. Still, I'm inclined to
think that having executable export as an interpreter feature would be
the better solution, if people feel strongly about distributing
executables rather than game/terp pairs. It would also mean that
people could bundle their non-I7 games up, so older works or those
written on other systems wouldn't be left in the cold.
JDC
> i would like the inform-fiction.org site itself to host the automatic
> webpages created for games. crazy huh?! not all authors have access
> to, or know how, to run their own website. i'd like to see a few extra
> options in the publishing steps to "upload" the completed webpages,
> along with the storyfile, directly to inform-fiction.org, where it
> would be held in a "games available" section or somesuch. would
> certainly be more enticing for prospective players than the current
> ifarchive site (although it wouldnt replace it, just an extra avenue).
I wonder if this could instead be worked into the archive or Baf's
guide or something. You would only need to upload the html file for a
website (fairly small) which had its links set up to download the game
file from the archive (instead of including it in a directory with the
html, as is currently the default). Someone visiting (say) Baf's guide
could then find (in addition to the usual links for game, solution,
etc.) a link for the game's webpage.
-JDC
Tim Howe
> On Feb 6, 4:57 pm, Tim Howe <v...@quadium.net> wrote:
>> "mikegentry" <m...@edromia.com> writes:
>> >> - Automatically bundling games into executables.
>>
>> Only as long as, like self-extracting ZIPs, there is a way to manually
>> pull the game back out of the executable so as to play it on another
>> platform.
>
> Yeah, I was thinking of this as a supplement to the regular game file,
> maybe in connection with a website. Something like "Release along with
> a website including Mac and Windows executables".
My fear is that today's version of "all the world's a VAX" developers will
helpfully remove all the confusing cruft and just release the Windows
executable.
L. Ross Raszewski
>
>- Automatically bundling games into executables. Certainly
>problematic, since they wouldn't be cross-platform, but this might
>help to package games to make them more accessible to the general
>public.
Why is it that whenever someone wants to make games"more accessible",
thyey always float this TERRIBLE idea?
You want your game to be more accessible to the general public? The
feature I'd advise is to automatically bundle the game into a windows
*installer* that unpacked itself into an UNBUNDLED terp and gamefile,
along with some shortcuts to get it running.
JDC
Well, I don't necessarily consider this a good idea myself, but my
Windows-using friends (the non computer-savvy ones at least) seem to
expect something they can download and click on, especially for
something they're just trying casually. I should also note that I know
essentially nothing about Windows myself, and don't really know the
executable/installer distinction. I guess I envision something like a
directory containing the game file, an interpreter, and a shell script
which runs the game in the interpreter (and when you double click on
the package it executes the script). This sounds more like an
installer, I guess. I still think a one-step download would help get
people to try IF for the first time, even if it's not the optimal way
to play.
-JDC
Andrew Plotkin
> On 5 Feb 2007 01:30:26 -0800, JDC <jd...@psu.edu> wrote:
> >
> >- Automatically bundling games into executables. Certainly
> >problematic, since they wouldn't be cross-platform, but this might
> >help to package games to make them more accessible to the general
> >public.
>
>
> Why is it that whenever someone wants to make games"more accessible",
> thyey always float this TERRIBLE idea?
Because MaxZip's bundle facility made games more accessible for Mac
users.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
When Bush says "Stay the course," what he means is "I don't know what to
do next." He's been saying this for years now.
greg
> I guess I envision something like a
> directory containing the game file, an interpreter, and a shell script
> which runs the game in the interpreter (and when you double click on
> the package it executes the script).
And if the installer puts a shortcut on the desktop/
in the start menu that invokes the appropriate
interpreter/gamefile combination, your average non-
savvy user isn't going to notice any difference.
--
Greg
fel...@yahoo.com
> - Automatically bundling games into executables. Certainly
> problematic, since they wouldn't be cross-platform,
Well, TADS3 can do that, and the resulting .exe runs just fine
in Linux (or any other platform that supports Wine, I think).
Winglulxe has a feature where renaming the interpreter to
match the .blb story file makes it load the game
automatically when run (and the license kindly allows
redistribution). Again, the resulting combination runs fine
in Linux (minus the sound, grrr....)
So two widely-used platforms are already covered. I would
venture to guess that similar game/interpreter bundles
are possible on the Mac (what, with the whole .app
bundling system). With that, the vast majority of
non-technical computer users should be covered, and for
the rest of us authors could simply release the plain game
files in addition to the interpreter bundles.
Felix
fel...@yahoo.com
> thyey always float this TERRIBLE idea?
>
> You want your game to be more accessible to the general public? The
> feature I'd advise is to automatically bundle the game into a windows
> *installer* that unpacked itself into an UNBUNDLED terp and gamefile,
> along with some shortcuts to get it running.
I don't get it. If your objection is against having to download the
interpreter with each game, then what's the difference? You want
just the game file. Fair enough. Ask the author to release it as such,
in addition to the platform-specific install kit/executable. Or is
there
something else?
Felix
JDC
> > > - The ability to create custom icons for games.
>
> (I assume what you mean is, the ability to assign some previously-
> created icon to a game -- I'm sure we're not going to build in an icon-
> editor.)
>
> I have absolutely no idea how feasible that is. My impression is that
> it's pretty easy to affix icons to Mac OS X files, but I don't know
> about Windows, and I could also just be Wrong. I kind of like the
> notion, though.
Yeah, I was thinking of a previously created icon. It's actually quite
easy to do this by hand in OS X (I also have no idea about Windows),
so there's probably not a compelling reason to automate it.
> The second is that if we built the executable-exporting stuff *into*
> I7, we'd have to keep updating every time the interpreters changed;
> for now, while things are in beta, we're releasing a new build every
> few weeks/month anyway, but later it might become cumbersome to keep
> up. Besides which, it is the nature of people that not everyone would
> *like* the interpreter we chose, and want to package their file with a
> different one instead; in which case, they're back to square one.
>
> Back in the day, when I still ran Mac Classic, I recall that MaxZip
> could at any time export an executable version of the game it was
> running. That was easy, tidy, and cool; I used it a fair amount when
> distributing games to less IF-savvy friends. To the best of my
> knowledge, no modern interpreters do this. Still, I'm inclined to
> think that having executable export as an interpreter feature would be
> the better solution, if people feel strongly about distributing
> executables rather than game/terp pairs. It would also mean that
> people could bundle their non-I7 games up, so older works or those
> written on other systems wouldn't be left in the cold.
I agree with this in principle; the one concenr I have with it is the
ability to create bundles for other platforms than the one you're
using. If I need to be able to run a Windows interpreter to create a
Windows executable it would make this difficult for me (since I have a
Mac and a linux box sans WINE); similarly for Windows users creating
Mac bundles.
I think it wouldn't be too hard to create a sort of template, though.
I've thought a little about doing this with Zoom on OS X as follows:
- Create a bundle which contains the zoom application and a command
line script to run it on a game file with a fixed name (named, say,
game.zblorb).
- You would then simply rename your file game.zblorb and put it in the
correct location in the bundle
- Change the name of your bundle to whatever you game is called, add
an icon if you wish, and you're done.
I haven't tried implementing this yet (if I get ambitious I might);
maybe someone has a better suggestion. I don't see any reason why you
couldn't then create an OS X bundle for your game on another OS by
simply taking the template and moving your game file into the
appropriate spot in the directory.
I don't know enough about Windows executables/installers to know if
something similar could be done there as well.
-JDC
Rikard Peterson
"JDC" wrote the following on the subject of adding icons to game files:
> Yeah, I was thinking of a previously created icon. It's actually quite
> easy to do this by hand in OS X (I also have no idea about Windows),
> so there's probably not a compelling reason to automate it.
It is not possible in Windows. (At least not in a way that would show
the icons without first registering the filetype - by extension - as one
containing an icon in the same way an executable does. And I don't think
doing that is a good idea.)
Rikard
L. Ross Raszewski
>On Feb 6, 10:50 pm, "Emily Short" <emsh...@mindspring.com> wrote:
>> On Feb 5, 9:34 am, "niz" <n...@infidel.freeserve.co.uk> wrote:
>> > > Emily Short wrote:
>> > > > The wariness of I7 authors entering the
>> > > > 2006 IF competition - they mainly steered clear of blorbed story files
>> > > > with cover art - reflects that I7's default story file format, though
>> > > > based solidly on existing formats, is not yet widely accepted.
>> > > I think I probably would have simply released a .z8 file rather than a
>> > > blorb if I hadn't included cover art, for this reason. I recall that
>> > > one of my testers asked if I could provide him the .z8 to test on a
>> > > handheld, but I don't know how many people use interpreters which do
>> > > not handle blorbs (or how difficult it is to unblorb);
>>
>> > big problems finding compatible interpreters for me. especially as
>> > even the built-in interpreter doesnt have full support for images, or
>> > any support for cover art.
>>
>> Given that cover art is usually displayed in a kind of "Info about
>> this game" dialogue box, I'm not sure what it would look like for
>> Inform 7 to support this feature -- you don't have a game browser to
>> look at a bunch of different games, just the one you're currently
>> compiling. What did you have in mind?
>
>at the start of the game.
>
That's not really "what it's for", though. It's meant to be more like
box art. The matter of a splash screen for your game is really best
handled separately. The basic goal of the frontispiece is to be
something shown *outside the game*, as by a browser or in a game
catalogue. That's why it's called "cover art" and not "title screen".