SAGE Project & StarLock

2 views
Skip to first unread message

Mike Snyder

unread,
Dec 5, 1999, 3:00:00 AM12/5/99
to
Hi R.*.I-F!

Just wanted to announce that the "SAGE" (Scripted Adventure Game Engine -
www.prowler-pro.com/sage) project is currently on hold. I don't think
anybody is genuinely interested in such an effort right now anyway, so it's
been shelved for now as my company resumes work on a new web-based
multiplayer game, StarLock (www.prowler-pro.com/starlock).

Thanks!

Mike Snyder
Prowler Productions
http://www.prowler-pro.com/

Tomas Clark

unread,
Dec 6, 1999, 3:00:00 AM12/6/99
to
In article <r_C24.19407$BW6.4...@typhoon2.kc.rr.com>,

"Mike Snyder" <wy...@prowler-pro.com> wrote:
> Hi R.*.I-F!
>
> Just wanted to announce that the "SAGE" (Scripted Adventure Game Engine > - www.prowler-pro.com/sage) project is currently on hold.


Too bad! The project sounded pretty interesting to me. Web-based IF could
really take off, but I think you may have been right in your earlier
post, when you were saying that it might be better to port one of the
existing interpreters/engines to work with a web server, instead of
building one from scratch. I think both Inform and Hugo have freely
available source code, don't they? Maybe even TADS although I doubt it.

I'm only vaguely familiar with the subject, but there are plenty of
libraries and such for various popular programming languages to make them
work with the Common Gateway Interface, aren't there? At this point in
time that would be my choice over a Java-based IF interpreter, although
that may change in a year or two.

Tomas Clark
tcl...@word.com


Sent via Deja.com http://www.deja.com/
Before you buy.

Mike Snyder

unread,
Dec 6, 1999, 3:00:00 AM12/6/99
to
Tomas Clark <tcl...@word.com> wrote in message
news:82gpr0$jlb$1...@nnrp1.deja.com...

> Too bad! The project sounded pretty interesting to me. Web-based IF could
> really take off, but I think you may have been right in your earlier
> post, when you were saying that it might be better to port one of the
> existing interpreters/engines to work with a web server, instead of
> building one from scratch. I think both Inform and Hugo have freely
> available source code, don't they? Maybe even TADS although I doubt it.
>
> I'm only vaguely familiar with the subject, but there are plenty of
> libraries and such for various popular programming languages to make them
> work with the Common Gateway Interface, aren't there? At this point in
> time that would be my choice over a Java-based IF interpreter, although
> that may change in a year or two.

I think HUGO would be the way to go, since 3.0 now supports the MIDI music
format (and it has supported graphics all along). I *know* its source is
open. TADS (HTML version) would be good too if porting that is feasable (and
I would think it is). When/if I get back to it, I might actually try to look
into that instead of starting from scratch.

It could be written in C easy enough I think. Since the bigger engines are
modular I believe, the work would come into play in designing new I/O to
spit out a web page and take input from a web page. Most of the C could
would probably be ok. My plan was to port to Perl, and you can link C
libraries into Perl (although I haven't in a long time).

Thanks for the kind words, though!

Mike.


> In article <r_C24.19407$BW6.4...@typhoon2.kc.rr.com>,
> "Mike Snyder" <wy...@prowler-pro.com> wrote:
> > Hi R.*.I-F!
> >
> > Just wanted to announce that the "SAGE" (Scripted Adventure Game Engine
> - www.prowler-pro.com/sage) project is currently on hold.
>
>
>

Matthew T. Russotto

unread,
Dec 7, 1999, 3:00:00 AM12/7/99
to
In article <82gpr0$jlb$1...@nnrp1.deja.com>, Tomas Clark <tcl...@word.com> wrote:

}I'm only vaguely familiar with the subject, but there are plenty of
}libraries and such for various popular programming languages to make them
}work with the Common Gateway Interface, aren't there? At this point in
}time that would be my choice over a Java-based IF interpreter, although
}that may change in a year or two.

Running the Z-machine as a set of CGI scripts would be possible,
though the screen handling would be nil, making playing many existing
games difficult.
--
Matthew T. Russotto russ...@pond.com
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."

Joe Mason

unread,
Dec 7, 1999, 3:00:00 AM12/7/99
to
Matthew T. Russotto <russ...@wanda.vf.pond.com> wrote:
>In article <82gpr0$jlb$1...@nnrp1.deja.com>, Tomas Clark <tcl...@word.com> wrote:
>
>}I'm only vaguely familiar with the subject, but there are plenty of
>}libraries and such for various popular programming languages to make them
>}work with the Common Gateway Interface, aren't there? At this point in
>}time that would be my choice over a Java-based IF interpreter, although
>}that may change in a year or two.
>
>Running the Z-machine as a set of CGI scripts would be possible,
>though the screen handling would be nil, making playing many existing
>games difficult.

Floyd seemed to work fine without screen handling. Isn't it about time
somebody ported CheapGlk to work through CGI?

Joe

Mike Snyder

unread,
Dec 7, 1999, 3:00:00 AM12/7/99
to
Matthew T. Russotto wrote in message ...

>Running the Z-machine as a set of CGI scripts would be possible,
>though the screen handling would be nil, making playing many existing
>games difficult.

What kind of screen handling, as an example? Newer browsers can do almost
anything you'd need. With layers (supported by IE 4.0 and NS 4.0 or newer --
and maybe Opera by now) you can come up with a pretty good GUI. What in
particular would be difficult to do through a browser?

Mike.

Evin Robertson

unread,
Dec 7, 1999, 3:00:00 AM12/7/99
to
In article <67034.20134$BW6.4...@typhoon2.kc.rr.com>,

Well, single character input without java.* comes to mind. The best
solution would probably be a text input box and a list of letters, but
freefall still wouldn't be easily playable and (of more concern),
menus would be awkward.

Just tables would probably be sufficient for most of the display
stuff, and would work with most browsers (assuming a table for
Z-machine upper window doing zarf-style-quotes would even work for
lynx).

I suppose just assume the user has a web browser >= 80 columns.

I'm still trying to figure out how to get things efficient enough that
you could have say, 20 people playing one turn a second and not
notice the load. I suppose everything is hopeless if you get linked
from slashdot.

This is one hundred saves and restores per second plus game reloading
time if you're not maintaining an interpreter loaded with each game
being played and having it called by IPC.

Things get a lot easier if you just have game sessions and don't let
people use the back button on their browser or use bookmarks. But I
figure that the back/forward buttons and bookmarks are the native
interfaces for undo/redo and save and they should be used if at all
possible.

David Glasser

unread,
Dec 7, 1999, 3:00:00 AM12/7/99
to
Tomas Clark <tcl...@word.com> wrote:

> Too bad! The project sounded pretty interesting to me. Web-based IF could
> really take off, but I think you may have been right in your earlier post,
> when you were saying that it might be better to port one of the existing
> interpreters/engines to work with a web server, instead of building one
> from scratch. I think both Inform and Hugo have freely available source
> code, don't they? Maybe even TADS although I doubt it.

TADS also has freely available source code. However, it is a little
complex, aging, and ugly and I'd be surprised if more than five people
understand some of the older code. (The HTML parsing code is much more
readable.)

(I'm not trying to imply that I think TADS is a complex, aging, and ugly
language, just that its internals which users never need to look at are.
I believe MJR's T3 project is trying to fix this by rewriting the entire
TADS-machine from scratch.)

By the way, it's irrelevant that Inform's source is available, as you'd
need to use a ZMachine interpreter on the web, not Inform itself. Frotz
and Zip, among others, have freely available source, and more helpfully
Rezrov (the Perl ZMachine interpreter) features a very expandable I/O
interface. Actually, a CGI interface to rezrov would be a nice project;
maybe I should try it[1].

<""""""""http://www.voicenet.com/~mikeedmo/rezrov/> for more rezrov
info.

[1] Careful readers of raif realize that when I say that, it means that
I will post "I'm going to do this any day now" once a week for a year or
so, and eventually somebody else does it.

--
David Glasser | gla...@iname.com | http://www.davidglasser.net/
rec.arts.int-fiction FAQ: http://www.davidglasser.net/raiffaq/
'No, GLK is spelled "G L K". What is this Java you speak of?'
--Joe.Mason on that portable thing on rec.arts.int-fiction

Andrew Plotkin

unread,
Dec 7, 1999, 3:00:00 AM12/7/99
to
In rec.arts.int-fiction David Glasser <gla...@iname.com> wrote:
> Tomas Clark <tcl...@word.com> wrote:
>
>> Too bad! The project sounded pretty interesting to me. Web-based IF could
>> really take off, but I think you may have been right in your earlier post,
>> when you were saying that it might be better to port one of the existing
>> interpreters/engines to work with a web server, instead of building one
>> from scratch. I think both Inform and Hugo have freely available source
>> code, don't they? Maybe even TADS although I doubt it.
>
> TADS also has freely available source code. However, it is a little
> complex, aging, and ugly and I'd be surprised if more than five people
> understand some of the older code. (The HTML parsing code is much more
> readable.)

The I/O section of TADS is pretty well modularized and documented by now.
You shouldn't have to muck around with internals to redirect that.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

Nat Lanza

unread,
Dec 7, 1999, 3:00:00 AM12/7/99
to
gla...@iname.com (David Glasser) writes:

> Rezrov (the Perl ZMachine interpreter) features a very expandable I/O
> interface. Actually, a CGI interface to rezrov would be a nice project;
> maybe I should try it[1].

Semi-unrelated, but does anyone want to hazard a guess at how painful
doing a PerlGlk would be? There are reasonable Perl interfaces to
curses, Tk, GTK+, and so forth, so doing the actual output should be
pretty easy.

Hmm.


--nat

--
nat lanza --------------------- research programmer, parallel data lab, cmu scs
ma...@cs.cmu.edu -------------------------------- http://www.cs.cmu.edu/~magus/
there are no whole truths; all truths are half-truths -- alfred north whitehead

Nat Lanza

unread,
Dec 7, 1999, 3:00:00 AM12/7/99
to

Fraser

unread,
Dec 7, 1999, 3:00:00 AM12/7/99
to
paene lacrimavi postquam Nat Lanza <ma...@cs.cmu.edu> scripsit:

>Semi-unrelated, but does anyone want to hazard a guess at how painful
>doing a PerlGlk would be? There are reasonable Perl interfaces to
>curses, Tk, GTK+, and so forth, so doing the actual output should be
>pretty easy.

Sort of related: sending Glk to Gtk is a pain, because of the
immaturity of the text widget. If there are any Gtk text widget
experts out there, drop me a line, because it's painful to have
a semi-working version of Glk sitting around on my hard drive
making me feel guilty.

Fraser.
--
fraser 'at' whitelion 'dot' org

Mike Snyder

unread,
Dec 8, 1999, 3:00:00 AM12/8/99
to
-----Original Message-----
From: Evin Robertson <nit...@my-deja.com>
>
>Well, single character input without java.* comes to mind. The best
>solution would probably be a text input box and a list of letters, but
>freefall still wouldn't be easily playable and (of more concern),
>menus would be awkward.

Hmmm... you can do event trapping on newer browsers, but if each key has to
communicate with the server (as opposed to some javascript) then yeah,
that'd be a problem. I guess then, it would be most feasable for games which
don't rely on hotkeys and work with complete commands (followed by "enter")
only...

>Just tables would probably be sufficient for most of the display
>stuff, and would work with most browsers (assuming a table for
>Z-machine upper window doing zarf-style-quotes would even work for
>lynx).

I was thinking Netscape 4.0 or newer, or MSIE 4.0 or newer. This gives you
access to layers which helps make advanced screen design possible.

>I suppose just assume the user has a web browser >= 80 columns.

What does the width matter? I thought line-wrapping was handled by the
interpreter?

>I'm still trying to figure out how to get things efficient enough that
>you could have say, 20 people playing one turn a second and not
>notice the load. I suppose everything is hopeless if you get linked
>from slashdot.

My online RPG gets thousands and thousands of page requests per day (I have
to nuke the logs daily because they grow 20 to 30 meg a day). It's been
running for a year, haven't had a problem with load yet.

What is "slashdot" ?

>This is one hundred saves and restores per second plus game reloading
>time if you're not maintaining an interpreter loaded with each game
>being played and having it called by IPC.

100 saves and restores per second seems pretty extreme. If forced (and if
possible) I'd set it up to use a RAM drive.

>Things get a lot easier if you just have game sessions and don't let
>people use the back button on their browser or use bookmarks. But I
>figure that the back/forward buttons and bookmarks are the native
>interfaces for undo/redo and save and they should be used if at all
>possible.

No. I disable the back button by doing 2 things -- I open in another window
(so people have to "right click" to even get the back button) then ever page
begins with the javascript command "document.forward();" If you try going
back, it won't do you a lot of good. You're not going to be able to use the
back button as an "undo" unless all the game variables are stored on the
page itself -- and if you're doing that, you don't need player save files
except when they're done for the day (or just pop it, if less than 4k, into
a cookie).

Mike.


Andrew Plotkin

unread,
Dec 8, 1999, 3:00:00 AM12/8/99
to
Evin Robertson <nit...@my-deja.com> wrote:
> ...doing zarf-style-quotes...

One day, there will be an accounting for your sins.

Mike Arnautov

unread,
Dec 8, 1999, 3:00:00 AM12/8/99
to
Tomas Clark <tcl...@word.com> wrote:

>Too bad! The project sounded pretty interesting to me. Web-based IF could
>really take off, but I think you may have been right in your earlier
>post, when you were saying that it might be better to port one of the
>existing interpreters/engines to work with a web server, instead of
>building one from scratch. I think both Inform and Hugo have freely
>available source code, don't they? Maybe even TADS although I doubt it.

The A-code Web implementation has already been produced and, pending a
confirmation from its author's employees, should be available under GPL
(as is now the whole A-code engine).

Essentially it is an A-code to Java translator, with three separate
front-end classes: one for running the adventure directly as an app, one
to run it as a servlet via an HTTP browser, and one to run it as a WAP
servlet (for any WAP-enabled devices such as mobile phones).

It all runs quite nicely as a beta-version.

--
Mike Arnautov
http://www.mipmip.demon.co.uk/
mailto:m...@mipmip.demon-co-antispam-uk
Replace dashes with dots and remove the antispam component.

Mike Snyder

unread,
Dec 8, 1999, 3:00:00 AM12/8/99
to
Mike Arnautov wrote in message ...

>Essentially it is an A-code to Java translator, with three separate
>front-end classes: one for running the adventure directly as an app, one
>to run it as a servlet via an HTTP browser, and one to run it as a WAP
>servlet (for any WAP-enabled devices such as mobile phones).

Java applet. That's a whole different ball of yarn. Ick.

Mike.

Andrew Plotkin

unread,
Dec 8, 1999, 3:00:00 AM12/8/99
to
paene lacrimavi postquam Nat Lanza <ma...@cs.cmu.edu> scripsit:

> Semi-unrelated, but does anyone want to hazard a guess at how painful
> doing a PerlGlk would be? There are reasonable Perl interfaces to
> curses, Tk, GTK+, and so forth, so doing the actual output should be
> pretty easy.

Do you mean a Perl interface for Glk? I don't think it should be hard.
Perl is a complete slut of a language and can be made to interact with
anything. :-)

Rules for translating C Glk function calls to Perl ones are, I hope,
straightforward. I deliberately kept to a few types of arguments, to make
the dispatch layer easy. (Yes, glk_gestalt_ext() is the annoying
exception.) You could *use* the dispatch layer, in fact, and then put a
layer of wrappers on top.

Fraser <blanc...@blancolioni.org> wrote:
> Sort of related: sending Glk to Gtk is a pain, because of the
> immaturity of the text widget. If there are any Gtk text widget
> experts out there, drop me a line, because it's painful to have
> a semi-working version of Glk sitting around on my hard drive
> making me feel guilty.

Yeah, I was wondering about that. Damn. I had assumed that GTK had a
reasonable text widget; I mean, isn't that the third widget anybody
writes? (After a pushbutton and a scroll bar. :-)

Even less related: anyone want to take I/O code from Rezrov and make an
Emacs module for Glk? I *know* Emacs has a sufficiently powerful text
widget...

Mike Arnautov

unread,
Dec 8, 1999, 3:00:00 AM12/8/99
to
Mike Snyder <wy...@prowler-pro.com> wrote:

>Java applet. That's a whole different ball of yarn. Ick.

Well, yes, the author of acdjava did have to perform some unnatural
contortions -- all in a good cause, of course. :-)

Arcum Dagsson

unread,
Dec 8, 1999, 3:00:00 AM12/8/99
to
In article <N1k34.21683$H8.5...@typhoon2.kc.rr.com>, "Mike Snyder"
<wy...@prowler-pro.com> wrote:
<snip>

> >I'm still trying to figure out how to get things efficient enough that
> >you could have say, 20 people playing one turn a second and not
> >notice the load. I suppose everything is hopeless if you get linked
> >from slashdot.
>
> My online RPG gets thousands and thousands of page requests per day (I have
> to nuke the logs daily because they grow 20 to 30 meg a day). It's been
> running for a year, haven't had a problem with load yet.
>
> What is "slashdot" ?
>

Slashdot is a news site. The best description is the one on top of the
site: "News for nerds. Stuff that matters". All kinds of technical, human
rights related, and other interesting news is posted there, and anyone can
comment and hold discussions on any article there, generally with a few
hundred posts in a discussion. Now, Slashdot generally links to the site
the info is coming from, and most of the people that read that discussion
visit the link. Generally, this causes the site to go down temporarily
from overload of people. This is the slashdot effect, or being
slashdotted. (And I end up reading it every day 'cause of what interesting
news ends up there. Heavy pro-Linux bias, though...)
--Arcum
--
"Real children don't go hoppity-skip unless they are on drugs..."
"Everyone was acting normal, so I tried to look nonchalant..."
"She left a note by the phone
Don't leave a message 'cause this ain't no home..."

David Glasser

unread,
Dec 8, 1999, 3:00:00 AM12/8/99
to
Andrew Plotkin <erky...@eblong.com> wrote:

> paene lacrimavi postquam Nat Lanza <ma...@cs.cmu.edu> scripsit:
>
> > Semi-unrelated, but does anyone want to hazard a guess at how painful
> > doing a PerlGlk would be? There are reasonable Perl interfaces to
> > curses, Tk, GTK+, and so forth, so doing the actual output should be
> > pretty easy.

I started, once. It's not likely that I'll finish, since my perl is
done either on (a) a Mac, where it's very annoying to do XS stuff or (b)
via telnet on Unix, but it's annoying to do all my development via
telnet. Also, I'm not very good (yet) with XS-type stuff.

The most annoying part is that if you want it to continue the whole
"main function not in the code thing", you'd both have to write a Glk
module (well, Glk:: modules for each output style) *and* make a trivial
embedded perl interpreter that everybody would have to compile in order
to run perlglk stuff.

Also, I suck at XS.

> Do you mean a Perl interface for Glk? I don't think it should be hard.
> Perl is a complete slut of a language and can be made to interact with
> anything. :-)

Of course, question number one is do we rewrite Glk in native Perl
(probably not) or tie it into C libraries with XS/SWIG/whatever. If we
go with the latter, do we have Glk::Term, Glk::Mac, etc or just a Glk.pm
that is smart enough to figure out which one we want, etc.

> Rules for translating C Glk function calls to Perl ones are, I hope,
> straightforward. I deliberately kept to a few types of arguments, to make
> the dispatch layer easy. (Yes, glk_gestalt_ext() is the annoying
> exception.) You could *use* the dispatch layer, in fact, and then put a
> layer of wrappers on top.

Hmm. This sounds like a very good approach and not one I'd thought of.
Could you maybe describe this a bit more? Would one only implement the
gi_dispatch function (or whatever) and then just make Perl's
&glk_do_this be a call to the dispatcher?

"Maybe Glulxification will cause people to start using Scheme for IF. Or
maybe not. Anyhow, I just like saying 'Glulxification'." -andyf on ifMUD

Joe Mason

unread,
Dec 9, 1999, 3:00:00 AM12/9/99
to
Arcum Dagsson <arcum_...@hushmail.c.o.m> wrote:
>Slashdot is a news site. The best description is the one on top of the
>site: "News for nerds. Stuff that matters". All kinds of technical, human
>rights related, and other interesting news is posted there, and anyone can
>comment and hold discussions on any article there, generally with a few
>hundred posts in a discussion. Now, Slashdot generally links to the site

Be warned: lots of interesting things are linked to from it, and I read it
regularly for that reason, but the discussions tend to be shovelled out of
the bottom of the dungheap. There are only occasional gems posted.

Joe

David Given

unread,
Dec 9, 1999, 3:00:00 AM12/9/99
to
In article <XrG34.4129$P23....@news20.bellglobal.com>,

There's an excellent moderation policy. Each article gets assigned a
score; you can set the threshold below which articles are not shown. I
read slashdot with a threshold of 3, and usually get four or five quite
good articles for each story.

Scores range from -1 to 5. You very rarely get 5's. -1 means show
everything.

--
+- David Given ---------------McQ-+
| Work: d...@tao-group.com | ...but hexapodia *is* a key insight!
| Play: dgi...@iname.com |
+- http://wired.st-and.ac.uk/~dg -+

Reply all
Reply to author
Forward
0 new messages