Poll on most dearly missed feature in IF...
Umbi
I decided that I want to give back to the IF community that has give
me so much. So being a software engineer and wanted to start a new
interesting project I decided that it could well be something related
to IF. Now I have many plans but I thought it would be interesting
(for the community as well) to know what is the most dearly missing
feature in the IF software landscape. I won't specify platform
details, since I thinks is an interesting general question!
What is missing? What would you (as community) like to see the most?
Any feedback is welcome.
-- Umberto
Victor Gijsbers
> What is missing? What would you (as community) like to see the most?
I have the feeling that by general consensus, a way to put up
Glulx-games in websites is sorely needed--i.e., something like
Parchment, but for Glulx. Andrew Plotkin is working on one part of it,
but only the front end if I recall correctly?
Personally, I would love to see a gtk-based (or qt-based, or otherwise
cross-platform) shell for gargoyle that functions as a nice graphical IF
library.
Kind regards,
Victor
Parham Doustdar
Please consider the accessibility issues, as well. QT and GTK under Windows
are both inaccessible, and require a great amount of work to make them be
accessible. I would vote for a web-based way to have Tads 2 or 3, or Glulx
games played with a web-browser, not necessarily through an application
offline.
"Victor Gijsbers" <vic...@lilith.gotdns.org> wrote in message
news:4b55abbf$0$22944$e4fe...@news.xs4all.nl...
mwigdahl
My vote is for direct web support for Glulx / TADS. I don't think any
other feature has more potential to expand the audience of IF, and
unless the upcoming Inform 7 build is much more efficient in its code
generation, most I7 games are going to require Glulx simply due to Z-
machine size constraints.
Matt
Paolo Lucchesi
> Personally, I would love to see a gtk-based (or qt-based, or otherwise
> cross-platform) shell for gargoyle that functions as a nice graphical IF
> library.
I'm a Gargoyle user, but I'd prefer a fully customizable library, where
you can specify your preferred 'terps.
bye
--
Paolo Lucchesi - pluc...@NOSPAMtin.it
Paolo Lucchesi
> QT and GTK under Windows
> are both inaccessible, and require a great amount of work to make them be
> accessible.
I don't know about qt, but I use at least three gtk programs (Pidgin,
Gimp, Inkscape) under Window with no problem. Wx-widgets can be a great
choiche too..
> I would vote for a web-based way to have Tads 2 or 3, or Glulx
> games played with a web-browser, not necessarily through an application
> offline.
Yes, that will be great (not for me, I like my 'terps, but I'd like to
put my glulx games playable online).
Erik Temple
I'm with everyone who wants to see Glulx and TADS 3 games playable in
the browser. Since there is already work underway on a javascript
glulx terp, it seems like starting up a T3 equivalent would be the
single most significant contribution one could make with a piece of
software. I've heard that the T3 virtual machine is a complex beast,
so this might also offer a (hopefully welcome) measure of challenge...
--Erik
Jim Aikin
> Since there is already work underway on a javascript
> glulx terp, it seems like starting up a T3 equivalent would be the
> single most significant contribution one could make with a piece of
> software. I've heard that the T3 virtual machine is a complex beast,
> so this might also offer a (hopefully welcome) measure of challenge...
I'm not a real programmer, only a fumble-fingered hobbyist, but I
suspect Erik is right that this would be a challenge. For one thing, the
HTML TADS interpreter engine (which would have to be supported -- not
just text mode) does some interesting things with clickable links. If
you put this into a browser-based terp, the possibilities for clicking
links start to expand....
If you're looking for a big challenge that's not web-based, how about
writing a TADS 3 compiler that compiles to glulx?
--JA
S. John Ross
My wish-list as someone writing IF is very different from my wishlist
as someone playing it :)
As a player, I want simple, broadly-useful toys like a better
automapper, an interpreter that can look the way I want it to look
(with themes I can swap around easily to suit genre and title), stuff
like that.
As a writer, I want more hours in the day and more coffee.
Ron Newcomb
A proper Mac port of TADS3 would be lovely, too.
Jim Aikin
>
> A proper Mac port of TADS3 would be lovely, too.
<jumps up and down, waves arms, and makes whooping noises> Yeah!
Erik Temple
> A proper Mac port of TADS3 would be lovely, too.
Agreed, but wouldn't this be even *more* appealing if T3 games were more
accessible, e.g. through a web app that would run well on all (or,
realistically, most) platforms? *Writing* Tads 3 games via Wine/Crossover
is a lot more palatable, I think, than asking folks to *play* T3 games
using Wine. Just sayin'...
Umbi
I understand, but I thought that you could play games for T3 with
several interpreters under mac...
But I tried the workbench for mac and is not (but my most sincere
thanks to the author, that i have
already contacted) comparable with the one for windows...
-Umberto
Erik Temple
wrote:
I think most of us are talking implicitly about HTML Tads, rather than
text-only Tads. There is currently one HTML Tads Mac interpreter
(CocoaTADS), but it's uncertain whether its development will continue.
More to the point, Linux has no HTML Tads player either. There is no
support whatsoever, I think, for mobile devices. A javascript
implementation of the HTML Tads, a la Parchment (z-code) and the
under-development Quixe (glulx), would address all of these at a single
stroke.
I'm definitely not saying that a TADS 3 IDE for Mac wouldn't be desirable
(I'm on a Mac myself), just that--to my mind--improving Tads *as a
platform* is more fundamental than making native authoring tools
available, esp. given that the current authoring tools work, according to
what I've heard, pretty well under Wine.
--Erik
Umbi
[big cut]
> I think most of us are talking implicitly about HTML Tads, rather than
> text-only Tads. There is currently one HTML Tads Mac interpreter
> (CocoaTADS), but it's uncertain whether its development will continue.
> More to the point, Linux has no HTML Tads player either. There is no
> support whatsoever, I think, for mobile devices. A javascript
> implementation of the HTML Tads, a la Parchment (z-code) and the
> under-development Quixe (glulx), would address all of these at a single
> stroke.
>
> I'm definitely not saying that a TADS 3 IDE for Mac wouldn't be desirable
> (I'm on a Mac myself), just that--to my mind--improving Tads *as a
> platform* is more fundamental than making native authoring tools
> available, esp. given that the current authoring tools work, according to
> what I've heard, pretty well under Wine.
>
> --Erik
Good. Will look into that. Thanks a lot for the clarification.
-- Umberto
jeremy...@gmail.com
web-playability in such a way that maximizes the flexibility of
authors to try things to make their games look cool when played in a
browser, dwarfs everything else.
I don't know enough to know how far a javascript Glulx terp will get
to that end; I know the spec is under revision. A different
possibility would be a browser-based terp that allowed community use
of the FyreVM; I don't know where that stands.
--Jeremy
Andrew Plotkin
> My personal poll vote would that improving web-playability, especially
> web-playability in such a way that maximizes the flexibility of
> authors to try things to make their games look cool when played in a
> browser, dwarfs everything else.
>
> I don't know enough to know how far a javascript Glulx terp will get
> to that end; I know the spec is under revision.
As you know I've been leaning towards using CSS for the new spec, as a
way of making Javascript terps as easy as possible to write. That's
about the extent of the overlap between the issues, however. Getting a
better style system is (currently) a design problem; getting
Javascript terps is an implementation problem.
As you also know, I haven't posted about the spec in several weeks...
I hope to have something new up tomorrow.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Jim Aikin
True, but CocoaTADS works very well, in spite of its being labelled
"pre-beta." So you don't have to play TADS games under Wine.
Workbench only works about 98% under Crossover. There are some minor
issues. I haven't tried it under Wine, and I haven't updated Crossover
in the past year (since I got one of the free copies they were handing
out on Hallowe'en 2008). So I may be behind the curve here.
I agree, though, that having a browser-based T3 interpreter would be a
bigger gain than having Workbench on the Mac.
--JA
Erik Temple
wrote:
Jeremy, I think this may also address some of what you're wondering about:
A javascript terp, whether it's Z-code or Glulx or Tads, has the advantage
of producing HTML output. If it's well implemented, the HTML will be
marked up with classes that can be used to style the elements using CSS to
some degree (from the webpage through which the game is played). I'm not
sure of the details of how the Glulx CSS system would work, but I think
the idea is that the author will be able to specify (a subset of) the
actual styles while writing the game, by providing a style sheet. But
styling could also be done on the client side, and depending on how the
style "cascade" (that's the C in CSS) is implemented, even overriding the
styles originally provided by the author. (Allowing, for a large-type
edition, say, or a "branded" version from the same binary as the standard
version.)
--Erik
vaporware
wrote:
> My personal poll vote would that improving web-playability, especially
> web-playability in such a way that maximizes the flexibility of
> authors to try things to make their games look cool when played in a
> browser, dwarfs everything else.
>
> I don't know enough to know how far a javascript Glulx terp will get
> to that end; I know the spec is under revision. A different
> possibility would be a browser-based terp that allowed community use
> of the FyreVM; I don't know where that stands.
I think Chris Cavanagh's browser-based FyreVM terp is usable enough.
However, games have to be compiled with the FyreVM Support extension
to work there.
vw
Erik Temple
> On 1/19/2010 11:49 AM, Erik Temple wrote:
>> On Tue, 19 Jan 2010 12:25:48 -0600, Ron Newcomb <psc...@yahoo.com>
>> wrote:
>>
>>> A proper Mac port of TADS3 would be lovely, too.
>>
>> Agreed, but wouldn't this be even *more* appealing if T3 games were more
>> accessible, e.g. through a web app that would run well on all (or,
>> realistically, most) platforms? *Writing* Tads 3 games via
>> Wine/Crossover is a lot more palatable, I think, than asking folks to
>> *play* T3 games using Wine.
>
> True, but CocoaTADS works very well, in spite of its being labelled
> "pre-beta." So you don't have to play TADS games under Wine.
I was really referring to Linux there. A lot of folks in the IF community
are on Linux, and I would bet a lot of the potential but untapped audience
is as well (and Mac OS also looms large in both of those categories, I'd
think). CocoaTads does work nicely (with some minor irritants), but the
author has stated that he may or may not continue working on it, depending
primarily on user feedback and enthusiasm, I think. Speaking of which, I
have some bug reports/interface notes that I've been meaning to send him...
> Workbench only works about 98% under Crossover. There are some minor
> issues. I haven't tried it under Wine, and I haven't updated Crossover
> in the past year (since I got one of the free copies they were handing
> out on Hallowe'en 2008). So I may be behind the curve here.
Crossover is actually a fancy (Mac-only) wrapper for Wine. It's possible
that configuration settings could be tweaked to make it run better (or
missing DLLs added), but I'm no expert. Maybe a linux user has looked into
it. As of 2006, the Players Kit was said to work perfectly:
http://appdb.winehq.org/appview.php?appId=1415
--Erik
mwigdahl
> On Tue, 19 Jan 2010 15:43:17 -0600, Andrew Plotkin <erkyr...@eblong.com>
> wrote:
Yeah! You could even hook it up to AdSense and inject timely, topical
ads directly into the text stream based on keywords you use in room
descriptions!
On second thought...
Matt
Peter Pears
Oh, well, speaking for myself, what I would like to see the most is a
Spatterlight-style frontend for all my Windows IF needs, like Blorple
but to which I could add other formats like Spetcrum TZX, Amiga ADF
and Apple II DSK. And which made use of the bibliographical
information on Babel-compatible games, rather like Spatterlight does.
Or maybe it's Zoom. I keep mixing them up.
But I doubt the rest of the community would be interested in it. A),
most people here seem to use Mac anyway (even the Inform 7 IDE, I
found, has a few extra features on the Mac), and B), other people have
brought up more pressing issues.
Still, here's my vote. :)
Poster
<ce8631ec-fd90-4cd2...@b10g2000yqa.googlegroups.com>,
Umbi <umberto.m...@gmail.com> wrote:
The ability to patch a game after release without having to upload a
whole new version.
--
Poster
www.intaligo.com I6 libraries, doom metal, Building
sturmdrangif.wordpress.com Game development blog / IF commentary
Seasons: Q4 '10 -- One-man projects are prone to delays.
jeremy...@gmail.com
> A javascript terp, whether it's Z-code or Glulx or Tads, has the advantage
> of producing HTML output. If it's well implemented, the HTML will be
> marked up with classes that can be used to style the elements using CSS to
> some degree (from the webpage through which the game is played). I'm not
> sure of the details of how the Glulx CSS system would work, but I think
> the idea is that the author will be able to specify (a subset of) the
> actual styles while writing the game, by providing a style sheet. But
> styling could also be done on the client side, and depending on how the
> style "cascade" (that's the C in CSS) is implemented, even overriding the
> styles originally provided by the author. (Allowing, for a large-type
> edition, say, or a "branded" version from the same binary as the standard
> version.)
Thanks. This is helpful. Let me just toss out one thing that exists
in my mind as "looking cool," with the understanding that I'm working
with below median background knowledge and not trying to nag anyone
about implementing anything. I think something cool-looking for
webplay of a text game would be if you could have a (photo)graphic
border around your game that changes with different levels/chapters/
events in the game. As with other webgames, the game would be
designed for a window of a particular size within the browser (with
the text as a window within that window), and there wouldn't be the
idea that players should be able to rescale the game to any aspect
ratio of their choosing.
I know that different pieces of what this implies can be done in
Glulx, but I don't know if they can be done together, and then
obviously whether that would work in any forthcoming javascript Glulx
terp would be a different matter.
An incidental thing this raises about browser play is what kind of
author interest there is in the concept of, if the appropriate browser
based terp was available, writing games that were willing to trade off
being compatible with other terps for the sake of looking good in
their online form. In other words, I can imagine an author thinking,
"If I can give people a link to a game that is going to look cool in a
browser using [terp xxx], I'm not going to worry about people not
being able to download a file to play in [terp yyy] or [terp zzz]."
But maybe that's idiosyncratic on my part.
--Jeremy
Jim Aikin
>
> The ability to patch a game after release without having to upload a
> whole new version.
Good point. And this reminds me of one that I had forgotten: It would be
lovely if there were a way to save a file in one version of a given game
and later load that file into a later release of the same game. This
would be quite useful, both for testers and for players.
I understand that there are issues in terms of how the save file is
configured, and in terms of what the model world looks like after the
old file is loaded ... but I'm pretty sure those issues are not
insuperable. The load routine could make some default assumptions about
missing data -- for instance, if a new object has been added to the game
in the new version, that object would remain in its starting location
when the old file is loaded.
It's quite normal in the world of real computer software (such as word
processors) to be able to open an old file after upgrading to a new
version of the software. There are situations in which this backward
compatibility breaks down, but even an imperfect implementation would be
better than none, which is what we have at present.
--JA
vaporware
I suspect this wouldn't be a big technical hurdle on TADS, it'd just
require some decision making along the lines you mentioned. Making it
work for Z and Glulx, on the other hand, would require a massive
rethinking of how the save process works.
The best bet is probably to use transcripts instead of save files,
just like the I7 IDE's replay feature: record the sequence of commands
(plus the random seed, timed input delays, etc.) and silently replay
them in the new version. In fact, something like that could be added
to Quetzal as an extra data chunk, and the terp could still use the
original save data when the story file hasn't changed.
vw
jeremy...@gmail.com
issue being how the new version would know what byte #379 in the old
save file meant--but others are more knowledgeable about this than I
am. A variant that I think would be cool is if there was a built in
way to save the game as the random seed plus all the commands that had
been entered up to that point, instead of as a game state, and then
restoring by restarting and executing all the commands.
Zoom allows this at the terp level by having a skein, as does the I7
IDE (which is why I wish you could use the I7 IDE to play games).
--Jeremy
Erik Temple
> Thanks. This is helpful. Let me just toss out one thing that exists
> in my mind as "looking cool," with the understanding that I'm working
> with below median background knowledge and not trying to nag anyone
> about implementing anything. I think something cool-looking for
> webplay of a text game would be if you could have a (photo)graphic
> border around your game that changes with different levels/chapters/
> events in the game.
You can do this now with a z-code game in Parchment, I believe. Basically,
it involves writing text into the game that instructs the javascript layer
what to do--you implement the border using HTML/javascript. The text
instructions are not displayed by Parchment, but I think they would be by
other interpreters; in other words, you would need to create a version of
the game specifically for Parchment. More on this can be found in threads
here, I believe:
http://groups.google.com/group/parchment
I'm not sure how (or whether, though for obvious reasons I hope the plan
is for it to be fully featured) Quixe will implement graphics. Even if it
doesn't, I would think that, unless Zarf actively blocks it, a similar
javascript/HTML technique to that I described for Parchment could be used
to do what you want to do. And if graphical capabilities are included,
then of course a graphical frame would be simple.
I'm not familiar with SilverGlulxe (though it's cool to see that it
exists), and I don't know whether it implements Glulx graphics
capabilities out of the box; it might be necessary to implement a frame
such as you describe on the server side rather than using HTML. (It looks
like changing other aspects of the look--fonts, etc.--would have to be
done on the server side as well.)
> As with other webgames, the game would be
> designed for a window of a particular size within the browser (with
> the text as a window within that window), and there wouldn't be the
> idea that players should be able to rescale the game to any aspect
> ratio of their choosing.
I am sure that with any of these implementations, the author would have
control over the size of the window, and it's unlikely that the player
would have (easy) control over the size of the game window. (Dynamic
resizing of the window *could* be implemented in javascript, but I doubt
it would be high on any developer's list of features.)
On the desktop side, I *believe* that the Treaty of Babel indicates that
authors should be able to specify that games have a certain window size
and disallow resizing. I don't know if that's been implemented in any of
the current interpreters. I seem to recall playing around with Zoom and
finding that it was not.
[snip]
> An incidental thing this raises about browser play is what kind of
> author interest there is in the concept of, if the appropriate browser
> based terp was available, writing games that were willing to trade off
> being compatible with other terps for the sake of looking good in
> their online form. In other words, I can imagine an author thinking,
> "If I can give people a link to a game that is going to look cool in a
> browser using [terp xxx], I'm not going to worry about people not
> being able to download a file to play in [terp yyy] or [terp zzz]."
> But maybe that's idiosyncratic on my part.
As I mentioned, the HTML/javascript combo means that Parchment can
potentially do more than any desktop interpreter, and I'm sure that it
will become a kind of pseudo-platform in itself. Indeed, I think there are
already people targeting it exclusively. The same thing could easily
happen, I would think, for a Glulx interpreter (video, for example, is not
supported by Glulx, but could be triggered using javascript embedded in
the game file). (And of course, though it's a bit of a hack for Parchment,
this is the central concept behind FyreVM and its channels as well--the
potential, at least, is there to add I/O elements that are not available
within the virtual machine.)
--Erik
Andrew Plotkin
>
> I'm not sure how (or whether, though for obvious reasons I hope the plan
> is for it to be fully featured) Quixe will implement graphics. Even if it
> doesn't, I would think that, unless Zarf actively blocks it, a similar
> javascript/HTML technique to that I described for Parchment could be used
> to do what you want to do. And if graphical capabilities are included,
> then of course a graphical frame would be simple.
I've thought about the game communicating with Javascript in an
embedded SVG image, but not in the app shell. Both good ideas.
Erik Temple
wrote:
> More on this can be found in threads here, I believe:
> http://groups.google.com/group/parchment
Just looked through some of the threads in here myself
(http://groups.google.com/group/parchment/browse_thread/thread/b7013878ff7e42ef#),
and found this link to a Parchment test with visual coolness
applied--looks like it's using the JQueryUI framework (and CSS) to restyle
things, as well as to route game data to other tabs:
http://geocache-if.appspot.com/test/integration.html
The printing of input text from the command line to the main window is a
bit buggy (in Chrome, seems to be better in Firefox), but overall it's
pretty impressive. Go east and look at the pictures in the gallery and
you'll see inline images in a z-code game. Cool.
--Erik
Conrad
>
> My vote is for direct web support for Glulx / TADS. I don't think any
> other feature has more potential to expand the audience of IF, and
> unless the upcoming Inform 7 build is much more efficient in its code
> generation, most I7 games are going to require Glulx simply due to Z-
> machine size constraints.
I agree! I want web support for TADS 3, which, although it's "html
TADS", you can't get online with.
It'd be a big thing.
Conrad.
Emily Boegheim
> What is missing? What would you (as community) like to see the most?
Personally, what I miss most is a version of the TADS 3 Workbench for
Linux. As Jim Aikin said, although the Windows version does run in
Wine, there are enough niggling issues to make using it an unpleasant
experience.
This probably isn't high on most people's wishlists, though.
Emily
Dannii
It should be very possible with Glulx's file IO. For some stories it
would be very easy, a current location and a few other settings. But
the more things that the game's state depends on the more complex it
would be. Still, it would always be possible to do it.
Hannes Schüller
> whole new version.
Huh? GNU diff/patch will handle binaries just fine.
Hannes
Otto Grimwald
> What is missing? What would you (as community) like to see the most?
Like many, I'd like to see a web based Glulx interpreter. It could be
powered by javascript like for Parchment, or a new version/improvement
of Zag http://wso.williams.edu/~jon/zag/ which is working well, but the
display is not very nice (no antialiased fonts) and the VM version is
obsolete now.
I'd like also to see a way to display glulx game a bit like TextFyre
games ( http://chicagodave.files.wordpress.com/2009/03/slwithart1.jpg
which looks great), but using web standards, truly multiplatform
(running in a standard browser but not by using silverlight or mono or
whatever) and open source.
scramble
1.) A web-based glulx 'terp. We'll see a lot more glulx releases in
the future as I7 tends to generate rather large game files. I've read
elsewhere ( http://groups.google.de/group/rec.arts.int-fiction/browse_thread/thread/4aba7f7e93319a3b#
) that something like this is in the works.
2.) A z-code or glulx 'terp with proper automap support.
3.) An I7 expansion that adds a graphical automap to the game. Should
include the possibility to use a custom tileset and something like
"index map with X south of Y". The difference to item 2 is that 2 also
works for existing games. 3 gives the author more influence on the
map.
Looking at the propsals, it's good to see they're almost all geared
towards improving the accessibilty of IF. The biggest nuisances for
beginners are handling/installing terps and drawing maps.
Peter Pears
> 3.) An I7 expansion that adds a graphical automap to the game. Should
> include the possibility to use a custom tileset and something like
> "index map with X south of Y".
That one already exists. I sure wish it was more used, too.
http://inform7.com/extensions/Mark%20Tilford/Automap/index.html
It's version 1, though. There is a version 2, but it's been swallowed
in the whole "no extension page update" thingy. But Vaporware was kind
enough to set up this page:
http://hansprestige.com/inform/extns2009/
You can get v2 from here.
Erik Temple
> > 3.) An I7 expansion that adds a graphical automap to the game. Should
> > include the possibility to use a custom tileset and something like
> > "index map with X south of Y".
>
> That one already exists. I sure wish it was more used, too.
Well, it's not a *graphical* automap, though; it uses ASCII art.
Scramble asked for a graphical automap with customizable tilesets,
which is in fact quite doable in a Glulx graphics window. It might
even be possible to modify the existing Automap extension's logic to
write to an array, and then render a map using sprite tiles from that
array.
A javascript automapper, customizable with CSS, might be the next step
in the evolution, though. It could listen in on the I/O from Parchment
or Quixe and generate a graphical map on the same page as the web
interpreter. More reliably, an extension could pass hints, embedded in
the game text, to the javascript mapper, allowing an accurate automap
to be generated even if a game doesn't use compass directions.
My own belief is that author-generated maps, rather than auto-
generated maps, are a better way to address scramble's concerns about
accessibility, while also improving a game's curb appeal. If you don't
mind a minor self-plugulation, I am working on a relatively full-
featured set of tools that should make generating a map quite a bit
easier; I will likely release it soon after the next build of Inform
emerges.
--Erik
weevil
main control, but also has an additional roguelike ascii-display for a
map, and to show the location of objects in a room.
Erik Temple
> I would love to work on a game that uses an IF text parser for its
> main control, but also has an additional roguelike ascii-display for a
> map, and to show the location of objects in a room.
I haven't really looked at it, but I think this extension does
something like that:
http://inform7.com/extensions/Sebastian%20Rahn/Room%20&%20Dimension/index.html
--Erik
Clint Bishop
> Hi to Everyone,
> I decided that I want to give back to the IF community that has give
> me so much. So being a software engineer and wanted to start a new
> interesting project I decided that it could well be something related
> to IF. Now I have many plans but I thought it would be interesting
> (for the community as well) to know what is the most dearly missing
> feature in the IF software landscape. I won't specify platform
> details, since I thinks is an interesting general question!
>
>
>
> -- Umberto
What's missing in IF is to make IF relevelant for 2010 not 1990...
No IF game should ever be played in anything other than a browser.
Period.
Second, where's the Facebook app that allows the sharing and
distribution of IF games?
Casual gaming on Facebook would be a great opportunity to propagate IF
to huge audiences. If Zynga can get millions hooked on lame games like
mafia wars and farmville, shouldn't the IF community be at the very
least, attempting to make itself known there?
I don't see one suggestion on this "wish" list that is going to make
IF broaden it's appeal. And that's the problem...
Erik Temple
wrote:
> I don't see one suggestion on this "wish" list that is going to make
> IF broaden it's appeal. And that's the problem...
I suspect you haven't bothered to read past the first post, then. Your
first point is this:
> No IF game should ever be played in anything other than a browser.
> Period.
...which is just a hyperbolic restatement of what nearly every message in
this thread has said: that better support for playing IF in the browser is
what's most needed.
Browser-based interpreters are also more or less a *precondition* to
sharing IF on Facebook etc, which was your second point. So it seems to me
that, while no one has asked the OP to code up something for Facebook,
your vision is hardly light-years beyond everyone else's. Sharing games
via Facebook might be an effective way to publicize IF, but not until
there are games in an easy-to-use browser-based format to share.
--Erik
Nathan
> No IF game should ever be played in anything other than a browser.
> Period.
I occasionally play IF in a browser.
I also play IF in DOSBox, MESS, and other emulators.
I also play IF on the Diamond Mako PDA.
Mostly I play in Gargoyle or xfrotz on my desktop.
Is there any reason at all to take options away from people?
> Second, where's the Facebook app that allows the sharing and
> distribution of IF games?
> Casual gaming on Facebook would be a great opportunity to propagate IF
> to huge audiences. If Zynga can get millions hooked on lame games like
> mafia wars and farmville, shouldn't the IF community be at the very
> least, attempting to make itself known there?
Maybe *good taste* has prevented it so far.
I gave a little contact info to TextFyre when I bought the
Hobbyist Edition of Shadow in the Cathedral, but *no way*
am I going to give some online game access to my
Facebook profile.
Besides, IF is for the literate.
vaporware
* Jesse McGrew found a crate of babel fishes in his dungeon and sent
you one! Click here to explore your dungeon and send a present back to
him!
* Remember, you receive 10 zorkmids every day for each friend who is
playing IF! Click here to invite more friends!
* IF thinks you may be interested in Choose Your Own Adventure and
Hypertext! Click here to join these groups!
vw
Ron Newcomb
> > > Period.
Er, one of Clearwire's towers was out for a week, meaning I had no
'net access at home.
> * Jesse McGrew found a crate of babel fishes in his dungeon and sent
> you one! Click here to explore your dungeon and send a present back to
> him!
>
> * Remember, you receive 10 zorkmids every day for each friend who is
> playing IF! Click here to invite more friends!
>
> * IF thinks you may be interested in Choose Your Own Adventure and
> Hypertext! Click here to join these groups!
OK you can take it off of Facebook now. I've had my fill.
Adam Thornton
vaporware <jmc...@gmail.com> wrote:
>* Jesse McGrew found a crate of babel fishes in his dungeon and sent
>you one! Click here to explore your dungeon and send a present back to
>him!
>
>* Remember, you receive 10 zorkmids every day for each friend who is
>playing IF! Click here to invite more friends!
>
>* IF thinks you may be interested in Choose Your Own Adventure and
>Hypertext! Click here to join these groups!
I just threw up in my mouth a little.
I lie.
I just threw up all over everything, a lot.
Adam
Jerome West
> * Jesse McGrew found a crate of babel fishes in his dungeon and sent
> you one! Click here to explore your dungeon and send a present back to
> him!
>
> * Remember, you receive 10 zorkmids every day for each friend who is
> playing IF! Click here to invite more friends!
>
> * IF thinks you may be interested in Choose Your Own Adventure and
> Hypertext! Click here to join these groups!
* You've just found a lonely grue who has been abandoned by his parents.
Click here to adopt him. (It is getting dark.)
markm
> I just threw up all over everything, a lot.
Just keep it away from my Cheerios.
Dannii
>
> Second, where's the Facebook app that allows the sharing and
> distribution of IF games?
> Casual gaming on Facebook would be a great opportunity to propagate IF
> to huge audiences. If Zynga can get millions hooked on lame games like
> mafia wars and farmville, shouldn't the IF community be at the very
> least, attempting to make itself known there?
>
> I don't see one suggestion on this "wish" list that is going to make
> IF broaden it's appeal. And that's the problem...
It's on my to-do list, but other things are more important. I promise
to make it as unobnoxious as I can!
Richard Bos
> What's missing in IF is to make IF relevelant for 2010 not 1990...
>
> No IF game should ever be played in anything other than a browser.
> Period.
You, sir, are an idiot.
On the rare occasions that I've played IF in a browser, I found the
experience disappointingly inferior to playing in a dedicated 'terp.
Richard
S. John Ross
> I just threw up all over everything, a lot.
Here are 50 Special Red Zorkmids for use in Zorkville. Can you help me
by sending a gift back?
Adam Thornton
Yes. It's there.
You'll probably need a mop and maybe sawdust. You'll recognize it; it
has carrots in it.
Adam
Conrad
More to the point, this kind of thing has long been done. They're
called MUDs...
Conrad.
Parham Doustdar
Java applets (a client works much better). IF has a single character,
whereas MUDs have more than one (E.G. the number of players is the number of
people online on the MUD). MUDs are not as much story or puzzle-driven as
IF, they are more combat oriented (or at least partly combat oriented), or
based on rolling dice (like MUSHes).
"Conrad" <conra...@gmail.com> wrote in message
news:dbe6cc75-e429-46dd...@a6g2000yqm.googlegroups.com...
vaporware
> More to the point, this kind of thing has long been done. They're
> called MUDs...
I call it Guncho.
vw
namekuseijin
> On Jan 21, 12:03 pm, Clint Bishop <clintmbis...@gmail.com> wrote:
> > Casual gaming on Facebook would be a great opportunity to propagate IF
> > to huge audiences. If Zynga can get millions hooked on lame games like
> > mafia wars and farmville, shouldn't the IF community be at the very
> > least, attempting to make itself known there?
>
> Maybe *good taste* has prevented it so far.
>
>
> Besides, IF is for the literate.
nailed it! Let the hordes chat on MSN about nothing, play flash "hit
the monkey" mini-games and download porn on the iPod. It's up to one
to decide to get out of the trash and realize what's it's been missing
in life.
namekuseijin
> In article <881c86b5-bc8e-4c6e-8d1a-94928d434...@22g2000yqr.googlegroups.com>,
>
> vaporware <jmcg...@gmail.com> wrote:
> >* Jesse McGrew found a crate of babel fishes in his dungeon and sent
> >you one! Click here to explore your dungeon and send a present back to
> >him!
>
> >* Remember, you receive 10 zorkmids every day for each friend who is
> >playing IF! Click here to invite more friends!
>
> >* IF thinks you may be interested in Choose Your Own Adventure and
> >Hypertext! Click here to join these groups!
>
> I just threw up in my mouth a little.
>
> I lie.
>
> I just threw up all over everything, a lot.
it could be worse. a grue could be following you on twitter. :)
behold:
http://twitter.com/grue
S. John Ross
> nailed it! Let the hordes chat on MSN about nothing, play flash "hit
> the monkey" mini-games and download porn on the iPod. It's up to one
> to decide to get out of the trash and realize what's it's been missing
> in life.
Quite. There are _far_ better porn-viewing devices than the iPod.
Jerome West
> Second, where's the Facebook app that allows the sharing and
> distribution of IF games?
> Casual gaming on Facebook would be a great opportunity to propagate IF
> to huge audiences. If Zynga can get millions hooked on lame games like
> mafia wars and farmville, shouldn't the IF community be at the very
> least, attempting to make itself known there?
Facebook games allow people to interact with their friends, and to do so
without any necessity for their friends to be playing at the same time.
They also offer strong incentives for playing over extended periods of time.
These games successfully appeal to a vast number of people. Many of
these people would never have considered playing any form of "video game".
A Facebook app that simply allowed people to play an existing work of IF
within a browser might attract a handful of users due to its novelty
value, but would not in any way begin to tap into the vast user base
attracted by games like Mafia Wars.
Perhaps there's some way to create a hybrid game? I can't see any way to
do it myself, but it would certainly be an interesting beast if anyone
managed to pull it off.
Stuart Allen
> The ability to patch a game after release without having to upload a
> whole new version.
You can do this with the interpreted IF languages. :)
I also miss tab completion. I had it working well in my custom
interpreter but lost the feature when I moved to Glk (a worthwhile
trade though). It would be nice to see the Glk API expanded to allow
the game to register a call back function that would provide the words
currently in scope any time the UI asked for them.
Stuart
Andrew Plotkin
This falls under "interrupt keys" (allow line input to terminate on
keys other than Enter), plus the newline-cleanup feature that's
already been requested. I think those two together give you the
ability to do tab completion.
(At a basic level, anyway. True command-completion integration would
have to be fancier -- you'd really want to supply the list of words to
the UI in advance.)
Interrupt keys have always been a standing request (since the
Z-machine had 'em) but it hasn't come up in a while. Now it has, so
thank you. :)
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
vaporware
> Here, Stuart Allen <stu...@animats.net> wrote:
>
> > On Jan 20, 9:50 am, Poster <pos...@nospam.com> wrote:
>
> > > The ability to patch a game after release without having to upload a
> > > whole new version.
>
> > You can do this with the interpreted IF languages. :)
>
> > I also miss tab completion. I had it working well in my custom
> > interpreter but lost the feature when I moved to Glk (a worthwhile
> > trade though). It would be nice to see the Glk API expanded to allow
> > the game to register a call back function that would provide the words
> > currently in scope any time the UI asked for them.
>
> This falls under "interrupt keys" (allow line input to terminate on
> keys other than Enter), plus the newline-cleanup feature that's
> already been requested. I think those two together give you the
> ability to do tab completion.
>
> (At a basic level, anyway. True command-completion integration would
> have to be fancier -- you'd really want to supply the list of words to
> the UI in advance.)
Indeed - doing it with interrupt keys would mean moving the cursor to
the end after refreshing the line, right? So it'd be impractical to
use completion if you go back to edit the beginning of the line.
vw
Stuart Allen
> (At a basic level, anyway. True command-completion integration would
> have to be fancier -- you'd really want to supply the list of words to
> the UI in advance.)
I can certainly see how that would be advantageous. At the time I was
just using the GNU Readline library which, from memory (it's been a
while now, I'd have to look at the old code...), asked for a new
filtered list each time your pressed tab. It also asks for a different
list based on whether the cursor is in the first column or not to
distinguish between commands or arguments, which translates to verbs
and nouns in IF. Ultimately I wanted to write a better version that
inspected the grammar tree and was context sensitive all the way
through a long (multi-object) command but I never go that far. I also
added a flag that the game author could give to an object to exclude
it from tab completion which was useful for avoiding the accidental
discovery of things but obviously isn't of much use to legacy games.
> Interrupt keys have always been a standing request (since the
> Z-machine had 'em) but it hasn't come up in a while. Now it has, so
> thank you. :)
You're welcome. :)
Stuart