IF System Idea
Tech-Know-Phile
used to date is that it can not be used anywhere at any time, as they
require a specific system to run on, and require an installation.
I was wondering how many people would be interested in an IF system
that was based entirely on existing, and in-draft, standards such as
(X)HTML, HTML 5, CSS, XML, etc. It would be able to be view without
any special interpreter, only a modern browser would be required.
Online and offline play would be possible.
This would open up many possibilities, such as playing a game from
your PC, saving it, resuming it on your iPhone while riding the bus,
and finishing it on your friend's netbook. Another possibilty would be
the capability to rate, review, and submit bug reports and suggestions
for a game, even during game play. Full accessability features, such
as those outlined by the W3C for people with disabilities. Such a
system could even be embedded in remote web sites allowing any
webmaster the ability to imbed games in his site.
I would not be able to create the system alone, and would need help,
but for now just let me know what you think.
Andrew Plotkin
> One problem that I have encountered with every IF system that I had
> used to date is that it can not be used anywhere at any time, as they
> require a specific system to run on, and require an installation.
>
> I was wondering how many people would be interested in an IF system
> that was based entirely on existing, and in-draft, standards such as
> (X)HTML, HTML 5, CSS, XML, etc. It would be able to be view without
> any special interpreter, only a modern browser would be required.
> Online and offline play would be possible.
Quite a bit of work has been done on this model, by several people.
Notably, taking the current IF interpreters and *porting* them to
Javascript -- thus getting all the advantages you describe, without
giving up the existing development tools.
Parchment is the standout example: a Javascript Z-machine interpreter.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Ikz
I agree. I wish we had something like this. I don't know what XML is
though, I'm too lazy to look it up. But the other ones aren't
programming languages either. You'd need javascript or php to make the
IF language, you know? The rest is just markup making it look pretty.
I don't find the current state of things to be ideal... I find Inform
7 to be a great dev language, but I don't like its presentation on
most interpreters and its need for interpreters. Interpreters which
help limit our fanbase to slightly more tech-savvy people, and are of
inconsistent quality in general. I think it's time we looked into an
end product that's inherently web-based. I find parchment to be
clunky, and it's frozen on me at least once with every game i've
played on it. I like TADS a little bit more for playing IF because the
interpreter I have for HTML TADS is so well-made. I like to be able to
cut and paste text right from gameplay. But it's even less-ported than
Inform, isn't it? There's z-code interpreters for a lot of stuff. Even
the DS.
I don't know where I'm going with this, I just wish we were publishing
games into nice, clean internet standards instead of converting them
using javascript after the fact. I barely know html and css, let alone
php, so go ahead and program something if you can do it or get someone
to do it. Even if it's a new language, anythign that published
natively php story files would be cool, right? I mean, ports can only
go so far. It's like emulating old game systems, you introduce bugs
and crap the more you pull from the past.
Tech-Know-Phile
> Here, Tech-Know-Phile <techknowph...@gmail.com> wrote:
> > One problem that I have encountered with every IF system that I had
> > used to date is that it can not be used anywhere at any time, as they
> > require a specific system to run on, and require an installation.
>
> > I was wondering how many people would be interested in an IF system
> > that was based entirely on existing, and in-draft, standards such as
> > (X)HTML, HTML 5, CSS, XML, etc. It would be able to be view without
> > any special interpreter, only a modern browser would be required.
> > Online and offline play would be possible.
>
> Quite a bit of work has been done on this model, by several people.
> Notably, taking the current IF interpreters and *porting* them to
> Javascript -- thus getting all the advantages you describe, without
> giving up the existing development tools.
>
> Parchment is the standout example: a Javascript Z-machine interpreter.
>
>
> --Z
>
> --
> "And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
> *
I certainly will look into Parchment, I hadn't come across that one
before.
Dannii
Yes please do look into Parchment. And if you like it and want to help
out, that would be great too!
Dannii
What specifically about Parchment do you find clunky? Any ideas of
what could improve it?
About the freezes: which browser are you using? Are you using one with
a JIT JS engine? A lot of new games made with I7 do a great deal of
processing and so will be slow on all interpreters. I actually have
some ideas that could help with this, but such changes would really be
most helpful for Glk and Glulx, which are active standards still being
updated. Zarf is working on a Glulx terp, and I'll help him once it's
a bit more complete.
It would be great to have a JS TADS3 VM, but it appears far more
complicated than either the Z-Machine or Glulx! Has anyone actually
written a TADS3 terp independently of the one by Mike Roberts? As far
as I know all the TADS terps are just ports of the original.
And a php interpreter wouldn't be all that great, if it ran over the
net it would be super laggy, and you'd still need a system with php on
it. I think the best option will be a JS Glulx interpreter with a new
more web-friendly IO system. Such an IO system could also be used on
standard desktop terps with the easy embedibility of WebKit (or Gecko.)
Ikz
As far as I know, I found Parchment to be "clunky" (the technicalness
of my criticism is awesome) when I used it because I couldn't get a
window that filled my screen, or play a game that wasn't on that
official list thing without hunting it down in the IF archive and
copying that URL in. As opposed to Parchment asking for a file and me
telling it where to look on my HD or something. See, I don't even know
if it's supposed to do -that-. Maybe there's a trick I'm missing to
get it off my HD, maybe I'm supposed to give it the path all the way
from C:. I dunno.
As for the crashes/freezes, I can't remember what games. I think one
was that game where you're the alcoholic detective, which was released
pretty recently. And maybe another one was Starcross. I can't remember
anything else, but there were like 4 games that I've had crash on me
out of playing 4 or 5 games for extended periods while on campus. I
know it was on Firefox though, on a Vista computer. I understand this
is an extremely unhelpful anecdotal bug report. Having never used the
program on one of my own personal computers (I have windows frotz and
html tads on there, so no need) it could very well be the computer's
fuckup, and not Parchment's.
But regardless yeah, a toolbar at the bottom or top of parchment that
lets you enter some parameters for interpreter window width, text
options, etc. would be a plus. Not that it's not already the best-
looking web based interpreter. I've never had a problem with the
command processing speed, but I think I had a problem with my typing
speed outrunning the command line, like it had to catch up to get to
what I had typed. I can't replicate that problem on this computer, so
I'm thinking that's specific to the computer I was using at the time.
Dannii
Although I wouldn't want it to start in full screen, I do think it
would be good to let people change the width of Parchment. It's not a
high priority though.
The Parchment home page has a link to this page which will show you
how you can play any online zcode: http://parchment.googlecode.com/svn/trunk/zcode.html
As to games that are on your HD... well I'm working to make that
easier too. At the moment you need to convert it to JS, but I want to
make it load raw zcode games if the browser is smart enough to do
that.
> As for the crashes/freezes, I can't remember what games. I think one
> was that game where you're the alcoholic detective, which was released
> pretty recently. And maybe another one was Starcross. I can't remember
> anything else, but there were like 4 games that I've had crash on me
> out of playing 4 or 5 games for extended periods while on campus. I
> know it was on Firefox though, on a Vista computer. I understand this
> is an extremely unhelpful anecdotal bug report. Having never used the
> program on one of my own personal computers (I have windows frotz and
> html tads on there, so no need) it could very well be the computer's
> fuckup, and not Parchment's.
Did they _crash_ or were they just slow? And did you try with Firefox
3.5? It will be a lot faster than Firefox 3. (Unfortunately I can't
get the speed improvements from Firefox 3.5 because they don't have a
working linux TraceMonkey build yet :( )
> But regardless yeah, a toolbar at the bottom or top of parchment that
> lets you enter some parameters for interpreter window width, text
> options, etc. would be a plus. Not that it's not already the best-
> looking web based interpreter. I've never had a problem with the
> command processing speed, but I think I had a problem with my typing
> speed outrunning the command line, like it had to catch up to get to
> what I had typed. I can't replicate that problem on this computer, so
> I'm thinking that's specific to the computer I was using at the time.
I wouldn't want a toolbar... instead I'm planning to have a full page,
called the Library. It will be somewhat similar to Zoom, and will show
the games you've played recently, and savefiles for them, and let you
search for new games, as well as uploading local ones. I also want to
change it to having a normal textbox, rather than the weird console
input thing it has now.
Thanks for your feedback!
George Oliver
> called the Library. It will be somewhat similar to Zoom, and will show
> the games you've played recently, and savefiles for them, and let you
> search for new games, as well as uploading local ones. I also want to
> change it to having a normal textbox, rather than the weird console
> input thing it has now.
>
The Library sounds fantastic, but when you say textbox do you mean a
separate input textbox, and by weird console input do you mean the in-
line '>' prompt? Because I really prefer that weird console input in
IF. ;D
A textbox is neither necessary or good looking in IF in my opinion.
Dannii
It would be styled to look the same as what is used now. But: it would
be faster, smoother and more responsive, wouldn't require a nasty hack
to allow pasting, and in general would be nicer from the JS
perspective.
Dannii
post at the Parchment discussion group! http://groups.google.com/group/parchment
:)
Conrad
Hey,
I just wanted to chime in to say I think Parchment is a great idea.
I've only used it a few times, as I generally prefer to run stuff off
my computer locally, but the need for such a standard was one of the
first worrisome ideas that came to me when I discovered the IF
community a few years ago; and so I was therefore very happy to see
Parchment.
I can't offer any support other than the moral kind, being largely non-
technical and kinda broke; but if you want to take a vacation in
Cambodia during the next year, I can help you out.*
Conrad.
* FOOTNOTE: Really this goes for anyone on here. "Help you out" being
defined as helping you find a decent $5/night guest house, etc.
C.
Dannii
Haha thanks Conrad. I've got no plans to visit Cambodia, but if that
changes I'll let you know!
Poster
<c5125b34-2393-4a13...@k26g2000vbp.googlegroups.com>,
Ikz <ikz...@gmail.com> wrote:
> On Sep 15, 9:12�pm, Tech-Know-Phile <techknowph...@gmail.com> wrote:
> > One problem that I have encountered with every IF system that I had
> > used to date is that it can not be used anywhere at any time, as they
> > require a specific system to run on, and require an installation.
> >
> > I was wondering how many people would be interested in an IF system
> > that was based entirely on existing, and in-draft, standards such as
> > (X)HTML, HTML 5, CSS, XML, etc. It would be able to be view without
> > any special interpreter, only a modern browser would be required.
> > Online and offline play would be possible.
> >
> > This would open up many possibilities, such as playing a game from
> > your PC, saving it, resuming it on your iPhone while riding the bus,
> > and finishing it on your friend's netbook. Another possibilty would be
> > the capability to rate, review, and submit bug reports and suggestions
> > for a game, even during game play. Full accessability features, such
> > as those outlined by the W3C for people with disabilities. Such a
> > system could even be embedded in remote web sites allowing any
> > webmaster the ability to imbed games in his site.
> >
> > I would not be able to create the system alone, and would need help,
> > but for now just let me know what you think.
>
> I agree. I wish we had something like this. I don't know what XML is
> though, I'm too lazy to look it up. But the other ones aren't
> programming languages either. You'd need javascript or php to make the
> IF language, you know? The rest is just markup making it look pretty.
>
The problem here is one of the source languages. Inform, TADS, Hugo, and
ALAN are just worlds apart (pun intended) from anything Javascript can
offer. If you try in Javascript, you will hurt yourself and if you
require me to, I will hurt YOU. :) HTML 5, while nice, still does not
provide the core capabilities of the languages up above.
Other languages force it all on to the server side, which begs the
question -- who's going to set up a server or servers to handle all
this? Do you want to force IF devs to set up their own server just to
code? Furthermore, do you want the playability of the game to depend
upon the continued existence of some URL out there? So you're requiring
both a web presence just to run the thing and a continued web presence
to keep playing it into the future. That's a usability deal-killer, I'm
afraid.
Other folks have tried this, and while I don't remember the name of the
system off-hand, it's pretty advanced for being a COYA type setup.
However, that's about all that you're going to get, which isn't enough.
I empathize with the original poster. I too would like something simple,
fast, and modern that doesn't depend upon a compiler. However, there's
just nothing out there that fits this need.
I would like to bring up the fact that you can distribute IF with the
compiler built-in, so people don't have to go and download the compiler
as well. Also, I sincerely doubt that the people who are interested in a
text-based game will lack the mental firepower to download an
interpreter (especially if you bundle it with your game as I've done!).
:)
--
Poster
www.intaligo.com I6 libraries, doom metal, Building
sturmdrangif.wordpress.com Game development blog / IF commentary
Seasons: fall '09 -- One-man projects are prone to delays.
Dannii
>
> The problem here is one of the source languages. Inform, TADS, Hugo, and
> ALAN are just worlds apart (pun intended) from anything Javascript can
> offer. If you try in Javascript, you will hurt yourself and if you
> require me to, I will hurt YOU. :) HTML 5, while nice, still does not
> provide the core capabilities of the languages up above.
I disagree... Javascript provides everything these IF systems need,
and more. If there is any major problem it's the big difference in
screen models: between that of a console program and that of a
reflowing html renderer. However that isn't really an issue, it just
provides an extra challenge: design a more appropriate IO system for
Glulx. It has other advantages too, like dynamic code recompilation,
and perhaps a simple threading model.
Andrew Plotkin
> On Sep 17, 9:28�pm, Poster <pos...@nospam.com> wrote:
> >
> > The problem here is one of the source languages. Inform, TADS, Hugo, and
> > ALAN are just worlds apart (pun intended) from anything Javascript can
> > offer. If you try in Javascript, you will hurt yourself and if you
> > require me to, I will hurt YOU. :) HTML 5, while nice, still does not
> > provide the core capabilities of the languages up above.
>
> I disagree... Javascript provides everything these IF systems need,
> and more. If there is any major problem it's the big difference in
> screen models: between that of a console program and that of a
> reflowing html renderer. However that isn't really an issue, it just
> provides an extra challenge: design a more appropriate IO system for
> Glulx.
The current model was designed with HTML in mind, remember, and I
think I've demonstrated that much of it. The Javascript Glk demo I put
up (months ago) supports window resizing in the way you'd expect of an
interpreter.
Dannii
Text Grid Windows are really not ideal for HTML though (and even
though they may not be used much, they still must be supported, which
is a hassle), and I think that having basically just one stream per
window is too limiting.
But such discussions are pretty pointless. If/When someone gets around
to prototyping such a system then we can discuss its benefits and
flaws. As was done to some extent with the Channel IO.
Captain Mikee
> The Parchment home page has a link to this page which will show you
> how you can play any online zcode:http://parchment.googlecode.com/svn/trunk/zcode.html
I think it's the "simply upload the Z-code file to a server" line that
makes it not only clunky, but downright intimidating. Why not mention
that you can paste in any IF Archive link? Then it would be merely
clunky.
I love the new "show me how!" link on ifdb, but why doesn't it list
Parchment as a platform? Or even provide a Parchment url alongside the
download links?
Ummm... duh, it does. How did I miss that? Is it new in the last
couple weeks? Maybe the "show me how" link should reiterate the
Parchment link for idiots like me.
And what's this "play now button?" Looks interesting...
IFDB rocks! What more do we need?
- Mike
Kenneth 'Bessarion' Boyd
> As far as I know, I found Parchment to be "clunky" (the technicalness
> of my criticism is awesome) when I used it because I couldn't get a
> window that filled my screen, or play a game that wasn't on that
> official list thing without hunting it down in the IF archive and
> copying that URL in.
Hmm...knee-jerk newbie reaction (last two attempts at TADS3 game
composition failed from lack of time management skills): does
Parchment accept file:// URLs?
Dannii
wrote:
If you have a downloaded copy of Parchment and access Parchment itself
by file:// it will (though it currently will only load converted
files, watch http://code.google.com/p/parchment/issues/detail?id=102
to see when that is fixed.)
The live http:// Parchment can't currently access file:// URLs because
that would be a browser security risk. However it would be nice to
make that work too (in modern browsers) when the Library has been
finished.
weevil
its worth is only going to be readily apparent to people who are both
web developers AND IF writers/enthusiasts.
When it's simplified enough to be a single javascript plugin that you
drop into a page, Parchment is going to allow you to turn an IF story
into a web page- not a flash or java applet stuck in a page, but a
real live page of html text that is coming from the DOM via
javascript, and is able to be styled via CSS by each individual
publisher. This is a page on your server that you yourself made- and
because it's javascript and not a boxed up applet, you can do anything
with that text- you could use javascript to turn words into hotlinks,
you could animate text and divs jquery style for all sorts of
interface weirdness (expanding animated lists, automatically embedded
media players, it's really as limitless as the kind of stuff you can
do in a regular webpage with javascript). And since you can play the
game on a page without downloading an interpreter, it's going to be
easier and accessible to more people.
On Sep 17, 1:23 pm, Dannii <curiousdan...@gmail.com> wrote:
> On Sep 18, 3:31 am, "Kenneth 'Bessarion' Boyd" <zaim...@zaimoni.com>
> wrote:
>
> > On Sep 16, 12:06 pm, Ikz <ikz...@gmail.com> wrote:
>
> > > As far as I know, I found Parchment to be "clunky" (the technicalness
> > > of my criticism is awesome) when I used it because I couldn't get a
> > > window that filled my screen, or play a game that wasn't on that
> > > official list thing without hunting it down in the IF archive and
> > > copying that URL in.
>
> > Hmm...knee-jerk newbie reaction (last two attempts at TADS3 game
> > composition failed from lack of time management skills): does
> > Parchment accept file:// URLs?
>
> If you have a downloaded copy of Parchment and access Parchment itself
> by file:// it will (though it currently will only load converted
> files, watchhttp://code.google.com/p/parchment/issues/detail?id=102
Poster
<c96e4f97-9e2c-4cbb...@v23g2000pro.googlegroups.com>,
Dannii <curiou...@gmail.com> wrote:
You're asking people who can learn TADS, HUGO, etc to spend even more
time learning something even less suited to actually Writing a game.
Furthermore, the code necessary to do basic things in these other
languages is obscure in Javascript, if it can even be done at all.
Imagining "take all" in Javascript makes my head hurt.
Dannii
> In article
> <c96e4f97-9e2c-4cbb-8543-d41cc1545...@v23g2000pro.googlegroups.com>,
I don't think you have understood my suggestion. A new IO system
wouldn't necessarily even involve authors writing JS, nor would it
have anything at all to do with actions a player would enter.
(Have custom JS in a game would be a nice possibility, but I'm not
sure of the security implications.)