web-based if
Gu
firt of all, this is a x-post r.g.int-fiction / r.a.int-finction as it
is about both playing and writing if.
i don't know if this subject has been discussed before in this (these)
ng, but it has probably been as my idea is not entirely original. this
post has its equivalent in the italian newsgroup dedicated to if, but
i'd like to know more opinions on a theme that interests me so much
that i'm investing a big amount of time on it (reguardless of my
studies.. oh well..!)
everything, including bug hunting, shoe shopping, blind dates and
french cooking, seems to moving to the web. no more paper mails, no
more films in the cinemas. this is not always a bad thing, but i'm
deviating from the purpose of this topic.
well, i'm developing a new if language. yup, i know, another one, why
are challenging inform, there's plenty of unused languages and stuff
like that. i don't want you to test it nor to use it, i'm having a lot
of fun doing it and as far as i'll be able to use it to create my
adventures i'll be happy and satisfied.
my language, apart from specifical grammar / language things i'm not
writing to talk about, is php based. no, better: the language is not,
the compiler / parser / virtual machine is.
in a word, you program in a common plain text file, then it is
executed online by a server and you play it online.
and this is the point: what do you think about playing if online in a
browser? a similar approach is automatically multi-platform and this
is one of the biggest advantages. then, you don't need to download a
thing to play it, so, if the only computer you have is that of your
workplace / university where you're not allowed to download and or
install programs, you can play if anyway.
someone told me that this way there's not the feeling of "possessing"
the game, or feeling it 'yours' cause it's not on physically the hard
drive. then, if you don't have a flat account (you have to pay to stay
online) or you don't have an internet connection, you cannot play if.
i'm developing a very basic and simple personal server system (based
on the minimal xitami) to play them or converting the scripts into
php-gtk programs would bypass the problem. hope to hear opinion from
you.
thanks in advance
gu
Nerd42
something. get some multiplayer IF goin'
but you sound like you oughtta be writin' JavaScript client side code
... u dont need server side 2 do an online singleplayer IF do u?
Gu
well.. it is not a mud. "online if" is just a way of convaying,
presenting it and playing it, but apart from that i'm talking about
normal single player if. there's no javascript involved as all the
parser work is done on the server and the adventure file is on the
server. the browser is just used to display results ("You're in a dark
room") as always..
defaul...@yahoo.com
Gu wrote:
> hi to all!
> firt of all, this is a x-post r.g.int-fiction / r.a.int-finction as
it
> is about both playing and writing if.
Actually, not a crosspost but multiposted. That's usually considered to
be bad form.
> and this is the point: what do you think about playing if online in a
> browser? a similar approach is automatically multi-platform and this
> is one of the biggest advantages. then, you don't need to download a
> thing to play it, so, if the only computer you have is that of your
> workplace / university where you're not allowed to download and or
> install programs, you can play if anyway.
This, as you surmise, has been discussed here in the past.
One of the challenges is how to maintain state data from turn to turn.
In a CGI situation, which is really what you are doing when you use
PHP, there are basically three ways:
1. The data in contained in hidden form fields in the display page
(POST data).
2. The data is in the URL of the form target (GET data).
3. The data is maintained by the server.
All three have their advantages and disadvantages.
There are other approaches, generally running TADS or other interpreter
as a Java applet, see Jetty and Zplet. Here is a web site with some
examples:
http://raddial.com/if/games/bap.html
Brian
Gu
>
>Gu wrote:
>> hi to all!
>> firt of all, this is a x-post r.g.int-fiction / r.a.int-finction as
>it
>> is about both playing and writing if.
>
>Actually, not a crosspost but multiposted. That's usually considered to
>be bad form.
..so, sorry about that
>> and this is the point: what do you think about playing if online in a
>> browser? a similar approach is automatically multi-platform and this
>> is one of the biggest advantages. then, you don't need to download a
>> thing to play it, so, if the only computer you have is that of your
>> workplace / university where you're not allowed to download and or
>> install programs, you can play if anyway.
>
>This, as you surmise, has been discussed here in the past.
>
>One of the challenges is how to maintain state data from turn to turn.
>In a CGI situation, which is really what you are doing when you use
>PHP, there are basically three ways:
>1. The data in contained in hidden form fields in the display page
>(POST data).
>
>2. The data is in the URL of the form target (GET data).
>
>3. The data is maintained by the server.
>
>All three have their advantages and disadvantages.
actually, data is stored on the server. it is easy to use txt files,
server variables or even a database. my approach is for text files and
it runs smootly so far, expecially considering that if games are nere
that big for the present coputer standards and that i have a
"compressed" way of operating on files. server variables are also a
valuable solution.
but my main interest in this post is not about technical stuff (which
i'm solving by myself without huge problems), but about "how do you
feel playing adventures online?" and "how do you feel knowing your
adventures are played online"
>There are other approaches, generally running TADS or other interpreter
>as a Java applet, see Jetty and Zplet. Here is a web site with some
>examples:
>http://raddial.com/if/games/bap.html
thanks for the link, it's inspiring, i'll be reading it.
gustavo
tuamigofiel
isn't something that you have to worry about lag times, but would you
have to wait for a page to load in between every move? If you make a
typing error, then you'd have to wait for the new page to load and tell
you that. It seems like it would be pretty slow. Maybe you have a
solution, but one of the advantages of having the story on my personal
computer is that my computer does everything. It doesn't get sent back
and forth.
It probably isn't too big a deal nowadays with broadband connections,
but even any delay would be too much; it seems like it would be too
slow no matter what. Even the half second while the page loads would be
a long time. I don't think I would enjoy it.
defaul...@yahoo.com
> >Actually, not a crosspost but multiposted. That's usually considered
to
> >be bad form.
>
> ..so, sorry about that
The difference being that replies to a properly cross-posted message
progagate to all referenced newsgroups, plus a good newsreader will
detect that one has read the message in a different group and so
consider it read in the others.
> >One of the challenges is how to maintain state data from turn to
turn.
> >In a CGI situation, which is really what you are doing when you use
> >PHP, there are basically three ways:
> >1. The data in contained in hidden form fields in the display page
> >(POST data).
> >
> >2. The data is in the URL of the form target (GET data).
> >
> >3. The data is maintained by the server.
> >
> >All three have their advantages and disadvantages.
>
> actually, data is stored on the server. it is easy to use txt files,
> server variables or even a database. my approach is for text files
and
> it runs smootly so far, expecially considering that if games are nere
> that big for the present coputer standards and that i have a
> "compressed" way of operating on files. server variables are also a
> valuable solution.
Basically option three. The problem with that is how to identify the
player and to maintain that identity across multiple sessions. You can
have some sort of log in system, but that is a bit of a hassle for the
casual user. You can use a session var method, but that goes away if
the user closes that browser.
> but my main interest in this post is not about technical stuff (which
> i'm solving by myself without huge problems), but about "how do you
> feel playing adventures online?" and "how do you feel knowing your
> adventures are played online"
I don't think there's enough of a base of web-based IF out there for
people to make that call yet. It will probably be more popular as more
people migrate to broadband vs. dialup, as long as there are those
willing to provide the games.
The problem really is that there is a large stable base of games
already written for the desktop interpreters now, and a somewhat
limited number of players. Most won't care that much about web-based
other than as a "test drive". They've already got the framework to run
the games. What you'd want with a web-based approach is to attract new
players that are already running Inform or TADS interpreters on the
home computers.
Brian
Gu
wrote:
hi!
the first if where played on machines with 256k of ram, loaded from a
cassette and interpreted on-the-fly by a BASIC interpreter. and they
where playable. i think, nowadays, any comuputer running whatever
browser and connected to the net with whatever connection whould work
great. plus, using a system of hidden frames, i don't actually load
lots of pages, i just run the script and append the text to the main
windows, so that the output you have to download is just a couple of
lines at a time..
Gu
>> >One of the challenges is how to maintain state data from turn to
>turn.
>> >In a CGI situation, which is really what you are doing when you use
>> >PHP, there are basically three ways:
>> >1. The data in contained in hidden form fields in the display page
>> >(POST data).
>> >
>> >2. The data is in the URL of the form target (GET data).
>> >
>> >3. The data is maintained by the server.
>> >
>> >All three have their advantages and disadvantages.
>>
>> actually, data is stored on the server. it is easy to use txt files,
>> server variables or even a database. my approach is for text files
>and
>> it runs smootly so far, expecially considering that if games are nere
>> that big for the present coputer standards and that i have a
>> "compressed" way of operating on files. server variables are also a
>> valuable solution.
>
>Basically option three. The problem with that is how to identify the
>player and to maintain that identity across multiple sessions. You can
>have some sort of log in system, but that is a bit of a hassle for the
>casual user. You can use a session var method, but that goes away if
>the user closes that browser.
you just enter a username and password. it IS for the casual user, as
name and password are not depending on any registration or account,
they're just for the purpose of a later retrival and a minimum
security. i just add username and password to the filename for
loading/saving logs.
>> but my main interest in this post is not about technical stuff (which
>> i'm solving by myself without huge problems), but about "how do you
>> feel playing adventures online?" and "how do you feel knowing your
>> adventures are played online"
>
>I don't think there's enough of a base of web-based IF out there for
>people to make that call yet. It will probably be more popular as more
>people migrate to broadband vs. dialup, as long as there are those
>willing to provide the games.
>
>The problem really is that there is a large stable base of games
>already written for the desktop interpreters now, and a somewhat
>limited number of players. Most won't care that much about web-based
>other than as a "test drive". They've already got the framework to run
>the games. What you'd want with a web-based approach is to attract new
>players that are already running Inform or TADS interpreters on the
>home computers.
>
>
>Brian
you're right. our hobby is really "elitist", but i don't think they're
something bad trying to capture the attention of new players. new
players mean fresh forces to if, possibly new authors and thus new
games.
if a person happens to load a if-concerning page at random (surfing
the web, wasting time, looking for free games) he can easily navigate
away from the page if he just reads "if are funny to play, remember
those adventures in the '80? just download this software if you want
to play an inform adventure, or this for tads or this for adrift,
install them and just download this game in that directory and you're
ready to play!". but if the text is just "if are funny. click here to
play", they'd probably give it a try. possibly they'd like it. then,
the if world is ready to be explored. every player started as being a
casual player.
for the same reason, every author started as a being a "curious"
author, and that's why i'm keeping the language behind my games as
simple as possible.
Mike Snyder
news:1114789752.9...@o13g2000cwo.googlegroups.com...
You can check out my browser-based MUD -- http://www.starlock.com/
---- Mike.
ru...@grunt.berkeley.edu
can see with a web based IF is the presentation. Currently what we
have now is a box in a browser window that's visually looks like an
IBM PC running DOS. It's stark. The current setup also has the
requirement that the user have java installed and to allow their
browser to run java applets. A "pure" html solution with the server
running a java servlet or php wouldn't need java on the client end,
and you could make the page a lot more attractive.
But I agree that the need to load the next page after each user entry
could detract from the experience. You could perhaps reduce some of
that by having the output of the game in a frame with relatively
static content frames above, below, and on both sides of it, with the
frame borderwidth set to 0, so the frames aren't obvious. So only the
center frame is reloading/refreshing.
r...@robinjohnson.f9.co.uk
Likewise!
> But I agree that the need to load the next page after each user entry
> could detract from the experience. You could perhaps reduce some of
> that by having the output of the game in a frame with relatively
> static content frames above, below, and on both sides of it, with the
> frame borderwidth set to 0, so the frames aren't obvious. So only
the
> center frame is reloading/refreshing.
I've done it in Javascript, with the whole game kept in memory on the
client so there's no need to reload anything:
http://www.robinjohnson.f9.co.uk/adventure/hamlet.html
That doesn't look so good yet, but my current development version of
the same 'platform' uses clever DHTML for a nicer, scrolling display. I
can get it on the web in the next few days, if anyone's interested.
Robin Johnson
Gu
CLAP CLAP CLAP!
Oh, man, that is great! As soon as i've some spare time I'll play your
adventure. This is exacly the direction i like. Javascript adventures
are a step ahead (meaning they're better) the adventure system I'm
developing. I'm doing it web / based by with a server-side core (php).
Your adventure system solves a great problem of mine: both are
automatically multi-platform, but your can run offline while mine
cant, and your is faster. CONGRATULATIONS! If you want to have a look
at what I'm doing go here:
www.amoeba.it/public/pif/accesso.php (it's just in Italian,
unfortunately)
I'd reccomand you getting rid of DHTML and go with css and layers.
Look into my code to see what I mean.
I want more, Robin!