[GINAS] Lisp-ish IF system, anyone?
Jacques Ruiz
It's a Lisp interpretor with a default library to write IF games.
I think it's a very powerfull system to write good "pseudo-AI" NPCs and
dynamic worlds.
It is not stuck to any standard so you have all the memory you want.
Why I hear noone speaking about GINAS? Perhaps because LISP semantic is
harder to learn than imperative languages??
--
Mr Kek
"i'm not moving doesn't mean i can't"
http://www.emi.u-bordeaux.fr/~jruiz
mailto:jr...@emi.u-bordeaux.fr
Neil Cerutti
Jacques Ruiz <jr...@emi.u-bordeaux.fr> wrote:
> I wonder if anyone uses GINAS.
> It's a Lisp interpretor with a default library to write IF games.
> I think it's a very powerfull system to write good "pseudo-AI" NPCs
and
> dynamic worlds.
> It is not stuck to any standard so you have all the memory you want.
> Why I hear noone speaking about GINAS? Perhaps because LISP semantic
is
> harder to learn than imperative languages??
I looked at it last month. It is very interesting, but isn't complete
and seems to have been abandoned by its author. I don't have the
ability to finish the system, so I had to give up. For instance, the
user interface is still a lisp interpreter. That isn't intuitive enough
for most players.
I gather that it was just an experiment by the author, who eventually
got bored with it.
I hope someone takes it up and completes it someday. It has intriquing
potential.
--
Neil Cerutti
ne...@norwich.edu
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Gareth Rees
> I wonder if anyone uses GINAS. It's a Lisp interpretor with a default
> write good "pseudo-AI" NPCs and dynamic worlds.
Lisp is certainly a good choice of implementation language for adventure
games. It has good support for sophisticated data structures, and its
macro facility allows the creation of application-specific
mini-languages.
The question is, why write a new Lisp system when CMUCL, GCL and other
Common Lisp compilers are available for free? Common Lisp is
sufficiently flexible that you don't need anything for writing
adventures that a Common Lisp system doesn't already provide.
> Why I hear no-one speaking about GINAS? Perhaps because LISP semantic
> is harder to learn than imperative languages??
You mean "syntax" rather than "semantic", I think. But anyway, that's
not the reason - after all, if people can learn to write Inform (or
Perl!) then Lisp will pose no difficulty. Reasons for the popularity or
otherwise of development systems have much more to do with marketing,
evangelism, and other factors (sentiment for Infocom was important in
the early days of Inform, I'm sure) than with technical issues.
--
Gareth Rees
Jacques Ruiz
>
> The question is, why write a new Lisp system when CMUCL, GCL and other
> Common Lisp compilers are available for free? Common Lisp is
> sufficiently flexible that you don't need anything for writing
> adventures that a Common Lisp system doesn't already provide.
I found CLOS uggly :)
Well, I can say "why use Inform when C++ can do it?" :)
GINAS Lisp is simple enough (like Scheme) and text-adventure-oriented.
The parser is already here, the tree structures for objects etc...
And it's flexible enough to write good things.
His author worked well, so why not use it? :)
(i am *not* the author!)
>
> > Why I hear no-one speaking about GINAS? Perhaps because LISP semantic
> > is harder to learn than imperative languages??
>
> You mean "syntax" rather than "semantic", I think.
No no, I mean semantic. LISP syntax is very simple. I think the problem
when learning Lisp is not "what's the syntax for that?" but "how to do
that in a lisp-ish fashion?". Recursion, lambda etc.. are "syntax
simple" but their semantic, and how to use them, are not.
> Reasons for the popularity or
> otherwise of development systems have much more to do with marketing,
> evangelism, and other factors (sentiment for Infocom was important in
> the early days of Inform, I'm sure) than with technical issues.
Religion! That's it! :)
>
> --
> Gareth Rees
Iain Merrick
> Gareth Rees wrote:
[...]
> > > Why I hear no-one speaking about GINAS? Perhaps because LISP semantic
> > > is harder to learn than imperative languages??
> >
> > You mean "syntax" rather than "semantic", I think.
> No no, I mean semantic. LISP syntax is very simple. I think the problem
> when learning Lisp is not "what's the syntax for that?" but "how to do
> that in a lisp-ish fashion?". Recursion, lambda etc.. are "syntax
> simple" but their semantic, and how to use them, are not.
My experience in teaching Lisp (well, Scheme; I sort of wander around
the lab helping undergraduates do their practical work):
Too many brackets. They don't understand it. Too many bloody brackets.
My supervisor is one of the people who likes Lisp because it 'has no
syntax', but in practice this isn't the case; not until you know it
really well, at least. All those lets and conds and lambdas and things
-- who can remember which brackets go where?
Oh, and in real Lisp there's a big standard library you've just got to
memorise. The naming scheme is not always intuitive.
However, you _can_ do lots of really clever stuff in Lisp which is
really hard to do in C or Pascal or something similar; taught properly,
it can improve students' programming styles an awful lot.
I know lots of functional programmers who claim that FP is _more_
inuitive than imperative programming, it's just that people are usually
corrupted with imperative experience before they learn FP. I'm not
convinced, but I would advise anyone who has only tried imperative
languages to play with Scheme, ML, Haskell or whatever for a few days;
it's a very interesting approach to programming.
--
Iain Merrick
i...@cs.york.ac.uk
Gareth Rees
> Well, I can say "why use Inform when C++ can do it?" :)
Because C++ has no way of declaring loopy data structures in the source
code. In Inform you can write
Object Room1 "Room 1" with n_to Room2;
Object Room2 "Room 2" with s_to Room1;
and in Common Lisp you could write something like
(object room1 "Room 1" :n_to room2)
(object room2 "Room 2" :s_to room1)
(given the appropriate macro definition), but in C or C++ there's no way
as far as I know to write this kind of loopy declaration.
> No no, I mean semantic. LISP syntax is very simple. I think the
> problem when learning Lisp is not "what's the syntax for that?" but
> "how to do that in a lisp-ish fashion?". Recursion, lambda etc.. are
> "syntax simple" but their semantic, and how to use them, are not.
Common Lisp supports functional, imperative and object-oriented
programming styles. (You have to work a bit harder to do logic
programming.) You can use `lambda' if you like but you can also use
`loop', `return-from' and `go' if you prefer.
If GINAS is Scheme-like then it may only support one style of
programming, so that may be an issue.
--
Gareth Rees
Eric Mitchell
>
> Jacques Ruiz <jr...@emi.u-bordeaux.fr> wrote:
> > Well, I can say "why use Inform when C++ can do it?" :)
>
> Because C++ has no way of declaring loopy data structures in the source
> code. In Inform you can write
>
> Object Room1 "Room 1" with n_to Room2;
> Object Room2 "Room 2" with s_to Room1;
>
> and in Common Lisp you could write something like
>
> (object room1 "Room 1" :n_to room2)
> (object room2 "Room 2" :s_to room1)
>
> (given the appropriate macro definition), but in C or C++ there's no way
> as far as I know to write this kind of loopy declaration.
In c++ you could do:
// forward declarations (not pretty, but functional)
extern Object room1;
extern Object room2;
// Object declarations: "name", Object exits[MAX_DIRS]
Object room1( "Room 1", {&room2, NULL ... } );
Object room2( "Room 1", {NULL, &room1 ... } );
...
Although in a "real" system, you'd probably be working at the story
database definition level, and not the source code. You'd be better
off to instantiate a horde of objects, and then link them together in
a separate initialization phase.
> --
> Gareth Rees
-- ebm
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
| Eric B. Mitchell mailto:emit...@altaira.com |
+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
Erik Max Francis
> Although in a "real" system, you'd probably be working at the story
> database definition level, and not the source code. You'd be better
> off to instantiate a horde of objects, and then link them together in
> a separate initialization phase.
In a practical sense, it would be a lot more straightforward to have
some macro definition language that the IF writer worked in, and then
expand that into C++, and then compile and link the result. m4 would
probably work quite adequately.
The question, of course, is why you would want to do this, when there
are already powerful authoring systems out there.
--
Erik Max Francis / email m...@alcyone.com / whois mf303 / icq 16063900
Alcyone Systems / irc maxxon (efnet) / finger m...@members.alcyone.com
San Jose, CA / languages En, Eo / web http://www.alcyone.com/max/
USA / icbm 37 20 07 N 121 53 38 W / &tSftDotIotE
\
/ Be able to be alone. Lose not the advantage of solitude.
/ Sir Thomas Browne
Erik Max Francis
> Too many brackets. They don't understand it. Too many bloody brackets.
Parentheses, I hope you mean. :-)
> My supervisor is one of the people who likes Lisp because it 'has no
> syntax', but in practice this isn't the case; not until you know it
> really well, at least.
It has "no syntax" in the sense that there are no order of operations,
that everything (an s-expression) is valid as both code and data, etc.
If you understand what an s-expression is, then you can write Lisp. You
need to learn peculiar syntaxes to program in other high-level
languages, like C or C++ -- that is, there's a lot more to learn in
terms of syntax for other languages. Granted you have to know a lot
more (in both cases) to be able to write something useful, but Lisp's
advantage is that the syntax-learning phase is education almost
nonexistent.
> All those lets and conds and lambdas and things
> -- who can remember which brackets go where?
People tend to either really like Lisp or really hate it. I don't use
it much, but I find it quite clever (and it has obvious applications for
artificial life, another interest of mine). A good text editor will
highlight closing parentheses for you, so these kinds of complaints are
pretty easy to get around.
> Oh, and in real Lisp there's a big standard library you've just got to
> memorise. The naming scheme is not always intuitive.
That's true for any programming language; it's not specific to Lisp.
J. Holder
> In article <37611F8E...@emi.u-bordeaux.fr>,
> Jacques Ruiz <jr...@emi.u-bordeaux.fr> wrote:
> > I wonder if anyone uses GINAS.
> > It's a Lisp interpretor with a default library to write IF games.
> and
> > dynamic worlds.
> > It is not stuck to any standard so you have all the memory you want.
> is
> > harder to learn than imperative languages??
> I looked at it last month. It is very interesting, but isn't complete
> and seems to have been abandoned by its author. I don't have the
> ability to finish the system, so I had to give up. For instance, the
> user interface is still a lisp interpreter. That isn't intuitive enough
> for most players.
> I gather that it was just an experiment by the author, who eventually
> got bored with it.
> I hope someone takes it up and completes it someday. It has intriquing
> potential.
I have considered this, and emailed Lee Standish (the author) asking him
about licensing and copyrights and such. Here is What he said:
--- include mail from GINAS author ---
To: jho...@frii.com (J. Holder)
From: Lee Standish <jlsta...@iquest.net>
At 12:44 PM 6/3/98 -0600, you wrote:
>
>Probably thought you wouldn't get much mail on GINAS anymore...
>anyway, I've been thinking about goffing around with your system and
>making modifications for it. I was wondering if either
Never have received much feedback on it, and none since spring '96. As far
as I know, no one is even making use of it.
>a) I could get permission to make a derivative work, which I would distribute
> as freeware.
>
>or
>
>b) you would release GINAS under a BSD-style license, which would mean
> I wouldn't have to ask for permission as you would have implicitly
> given it.
I have no problem with either option. I'm no longer working in a LISPish
environment, haven't touched the code in well over a year, and doubt I will
even make much use of it in the foreseeable future.
>Also, Is there a version newer than 0.4, August 1995?
Nope. v0.4 was going to be relabeled as v1.0, but I was distracted with
finishing grad school and getting a job out in the real world. I had
reworked some of the internals of the engine to improve performance, but
then realized that it would kill performance for resolving inherited class
members, so that change was never finished off. Not even sure where that
code would be, having changed home computers twice since then, meaning that
the code is buried in some archive or other.
------------------------------------------------------------------------
Lee Standish http://members.iquest.net/~jlstandish
jlsta...@iquest.net Co am fear am measg an t-sluaigh
jlsta...@acm.org a mhaireas buan gu brath?
--- end include mail from GINAS author ---
So, if you want to extend / finish it, we have Lee's blessing.
--
John Holder (jho...@frii.com) http://www.frii.com/~jholder/
<jholder> do you like FreeBSD?
<hal> I need to get the ISDN line running so that I will tell it to pass over
me and replace my SuSE box with FreeBSD.
Iain Merrick
> Iain Merrick wrote:
>
> > Too many brackets. They don't understand it. Too many bloody brackets.
>
> Parentheses, I hope you mean. :-)
Well, usage varies. IIRC 'brackets' is the most common 'Commonwealth
Hackish' term, although I wouldn't claim to be a Commonwealth Hacker.
[...]
> It has "no syntax" in the sense that there are no order of operations,
MMmmmm, yes, well, if you're using a purely functional style. And you
have no infinite loops.
> that everything (an s-expression) is valid as both code and data, etc.
> If you understand what an s-expression is, then you can write Lisp. You
> need to learn peculiar syntaxes to program in other high-level
> languages, like C or C++ -- that is, there's a lot more to learn in
> terms of syntax for other languages.
>
> Granted you have to know a lot
> more (in both cases) to be able to write something useful, but Lisp's
> advantage is that the syntax-learning phase is education almost
> nonexistent.
[...]
I would say that C has very little syntax to learn. What you _do_ have
to learn is the totally bizarre way pointers work. I think this was the
only stumbling block I had in learning C, although it now seems totally
natural.
C++ has a bit more syntax, certainly, and languages like Pascal and Ada
have lots.
So, yes, Lisp is pretty good in terms of simple syntax. But I don't
think it vastly outstrips other languages in this respect.
[...]
> People tend to either really like Lisp or really hate it.
Well, that's what I'm arguing against. I like Lisp, but I don't _really_
like it. I've had to use it a fair bit, but I've never bothered to
become fully expert and fluent. When I need to, I will.
I personally learned Haskell (a functional language) and C at the same
time, in my second year at uni. I was corrupted by Basic and Pascal
experience, but I still found Haskell more intuitive at first. However,
several years later, I probably do 99% of my programming -- even quick
hacks -- in C and C++.
[...]
> > Oh, and in real Lisp there's a big standard library you've just got to
> > memorise. The naming scheme is not always intuitive.
>
> That's true for any programming language; it's not specific to Lisp.
Yes, but Lisp doesn't do particularly well in this respect or anything.
Again, it's okay, but it's not a 'love it or hate it' situation. I
think, anyway.
--
Iain Merrick
Fraser Wilson
>C++ has a bit more syntax, certainly, and languages like Pascal and Ada
>have lots.
Well ... at least Ada has a regular syntax, and the Ada standard is
smaller than the C++ standard. I'd be surprised if the EBNF specs
for Ada were larger.
As for C++'s syntax, well, it's pretty warped. For example, some
curly braces need a semicolon after them, some don't. The way to
declare a compile-time constant as a member of a class uses the
keyword "enum." The only way to use switch statements with the
natural semantics ("choose one of these options depending on the
value of this expression") is to break out of them at appropriate
points. And a type expression that says "pointer to method of
class X returning int" is ... bizarre.
ObIF: perhaps the reason NPCs in IF seem less that ideal is that
we expect too much. While we're typing commands to a computer,
we don't mind if it's stupid, because it's only a computer. But
when trying to talk to NPCs, we unconsciously expect them to act
like people, ignoring the fact that we're addressing essentially
the same thing as the IF parser.
Fraser.
(change i's to y's for my real email address)