Using Perl for IF, why not?
James Edward Gray II
like an ideal fit. In fact, so much so that I went looking for what
someone must have does before me, but other that Rezrov I can't find
any significant links between the two.
On top of that, everything I'm reading about IF says use TADS of
Inform. Don't get me wrong, I'm sure they're great, but I don't know
them and I do know Perl which I can and have used to do everything
under the sun for years now. Perl is also VERY portable, if used
responsibly.
So that leaves me wondering... Why not Perl?
I'm not trying to start fights or call the entire IF community wrong.
I'm asking honestly and seriously, because I would expect you know IF
better than me. Tell me, why is it a bad idea to use Perl?
James
Rexx Magnus
> So that leaves me wondering... Why not Perl?
>
> I'm not trying to start fights or call the entire IF community wrong.
> I'm asking honestly and seriously, because I would expect you know IF
> better than me. Tell me, why is it a bad idea to use Perl?
>
> James
You'll basically still need to write it from the ground up. Whilst perl
has pretty good string parsing ability, it's not tremendously accessible
(when compared to the other systems of compiler/interpreter) to most
average users.
Whilst it could be argued that it is well suited for writing games that
run on a server, there are ways of running the other systems in the same
manner, which still means that you have the widest possible audience, both
from online players and standalone clients.
To email me, visit the site.
John Roth
news:6fd1fcf5.04031...@posting.google.com...
It's not a particularly bad idea. As a comparison, there are
two IF systems in Python, which I do know (and I play with
them a bit.)
Both TADS and Inform are purpose built for the task of
doing interactive fiction. With all due respect, Perl's object
capabilities are bolted on, while TADS and Inform are more
or less carefully structured for the task, and Python's are
both pretty mainstream and an integral part of the language.
This leads to interesting problems. Most IF programs need
to define routines (that is, methods to use OO-speak) for each
object, which usually means (in Python) that one has to both
create a class and instantiate it. PAWS (Python Adventure
Writing System) has a real problem with the movement maps.
I'm not sufficiently familiar with PUB (Python Universe Builder)
to do a critique.
As a professional software developer, I could probably
fix most of the difficulties with PAWS, but the result still
wouldn't be as convenient as a purpose built language.
I'd suggest you attempt to port Cloak of Darkness to
Perl and see how it goes. Cloak of Darkness is Roger
Firth's test game - it's been ported to just about every
IF system in existance so it makes a great testbed.
If you manage that, then try Alice. Alice is only one room,
but it's quite a bit more complex (about 500 lines of Inform
code.)
John Roth
>
> James
Joe Mason
> I'm brand new to IF, but definitely not new to Perl. To me, they seem
> like an ideal fit. In fact, so much so that I went looking for what
> someone must have does before me, but other that Rezrov I can't find
> any significant links between the two.
Why an ideal fit? Just because Perl is good at text parsing? Because
the actual "parsing" part of an IF parser is pretty trivial - it's the
world model that's the hard part, and I don't see where Perl has a huge
advantage there.
If you want to use a standard scripting language, there's PAWS, which is
a set of Python libraries. (And I believe there's another Python-based
one, too - PUB? Python Universe Builder? Something like that...)
Joe
Joe Mason
> This leads to interesting problems. Most IF programs need
> to define routines (that is, methods to use OO-speak) for each
> object, which usually means (in Python) that one has to both
> create a class and instantiate it. PAWS (Python Adventure
> Writing System) has a real problem with the movement maps.
> I'm not sufficiently familiar with PUB (Python Universe Builder)
> to do a critique.
>
> As a professional software developer, I could probably
> fix most of the difficulties with PAWS, but the result still
> wouldn't be as convenient as a purpose built language.
I tried briefly to create a singleton class in Python that would
automatically create an instance object without needing any extra
syntax, but never got very far. I wouldn't be at all surprised if this
were easy in Ruby, though. Have you looked at that? If I were to write
an IF world model in general language, that's probably the one I'd pick,
because it seems like it can be tweaked to provide the same types of
conveniences (grammar tables, singleton objects) that custom built IF
languages have.
Joe
Andrew Plotkin
>
> I tried briefly to create a singleton class in Python that would
> automatically create an instance object without needing any extra
> syntax, but never got very far.
I tried fairly extensively. I couldn't do it either.
> I wouldn't be at all surprised if this
> were easy in Ruby, though. Have you looked at that? If I were to write
> an IF world model in general language, that's probably the one I'd pick,
> because it seems like it can be tweaked to provide the same types of
> conveniences (grammar tables, singleton objects) that custom built IF
> languages have.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Paolo Lucchesi
> On top of that, everything I'm reading about IF says use TADS of
> Inform. Don't get me wrong, I'm sure they're great, but I don't know
> them and I do know Perl which I can and have used to do everything
> under the sun for years now. Perl is also VERY portable, if used
> responsibly.
>
> So that leaves me wondering... Why not Perl?
Well. IMHO the main reason is that you'll spend much more time
implementing from scratch the parser and a good world-model than
learning a new language; if you know how to program, learning a new
language should be a rather easy task.
Moreover, but this is a minor problem, Windows user doesn't have a
built-in perl interpreter. AndI don't know how perl can run on portable
devices...
bye
--
Paolo Lucchesi
email: plucchesiNOSPAM(at)NOSPAMtin(dot)NOSPAMit
homepage: http://www.paololucchesi.it
"Non viviamo in un mondo perfetto (per fortuna)"
John Roth
"Joe Mason" <j...@notcharles.ca> wrote in message
news:slrnc5fmh...@gate.notcharles.ca...
> In article <105f8v0...@news.supernews.com>, John Roth wrote:
> > This leads to interesting problems. Most IF programs need
> > to define routines (that is, methods to use OO-speak) for each
> > object, which usually means (in Python) that one has to both
> > create a class and instantiate it. PAWS (Python Adventure
> > Writing System) has a real problem with the movement maps.
> > I'm not sufficiently familiar with PUB (Python Universe Builder)
> > to do a critique.
> >
> > As a professional software developer, I could probably
> > fix most of the difficulties with PAWS, but the result still
> > wouldn't be as convenient as a purpose built language.
>
> I tried briefly to create a singleton class in Python that would
> automatically create an instance object without needing any extra
> syntax, but never got very far.
I suspect you could do this with metaclasses, but that's not
exactly either a well-known or obvious technique. It also still
leaves you with two objects (one of which, the class object, is
quite large) where one should be all that is needed.
If I was going to pursue this notion, the direction I would take
would be to define the routines at the module level with a naming
convention (something like "before__open") and then have an
"endOfObjectDefinition()" routine that would find all of them, put
them in the right places and do any other cleanup and sanity checking
needed. I think that minimizes the hassle for the game author.
> I wouldn't be at all surprised if this
> were easy in Ruby, though. Have you looked at that? If I were to write
> an IF world model in general language, that's probably the one I'd pick,
> because it seems like it can be tweaked to provide the same types of
> conveniences (grammar tables, singleton objects) that custom built IF
> languages have.
You can do that in just about any general-purpose language.
The major issue is how convenient the result is for the game author.
John Roth
>
> Joe
John Roth
Those are the two I know of. There are a number of authoring
issues I have with PAWS, but they are all fixable.
John Roth
>
> Joe
John Roth
"Paolo Lucchesi" <plucchesi@spamma_tu_ma_tin.it> wrote in message
news:8rU5c.56848$z23.2...@news3.tin.it...
> James Edward Gray II wrote:
>
> > On top of that, everything I'm reading about IF says use TADS of
> > Inform. Don't get me wrong, I'm sure they're great, but I don't know
> > them and I do know Perl which I can and have used to do everything
> > under the sun for years now. Perl is also VERY portable, if used
> > responsibly.
> >
> > So that leaves me wondering... Why not Perl?
>
> Well. IMHO the main reason is that you'll spend much more time
> implementing from scratch the parser and a good world-model than
> learning a new language; if you know how to program, learning a new
> language should be a rather easy task.
> Moreover, but this is a minor problem, Windows user doesn't have a
> built-in perl interpreter. AndI don't know how perl can run on portable
> devices...
Interpreter distribution is a significant problem, yes. There is
a standard Perl (and Python, and Ruby, and TCL, and so forth)
distribution for Windows that is easily installable. The benefit you
get from that is that you now also have a language you can use for
anything, pretty much for free.)
John Roth
Daniel Ellison
wrote:
Wouldn't this be the perfect situation for a prototype- or object-based
language? No classes, so no problem getting a singleton. You can even
modify "parent" objects on the fly and see the effects immediately in all
child objects (imagine lighting a set of rooms all at once by giving the
parent a "light" property). The only problem with general-purpose
languages is that they are usually very large. Even the smallest runtimes
can't compete with the size of your average z-code interpreter.
So what are the choices if your criteria include a minimal runtime system?
Either use one of the existing IF authoring systems or roll your own
language that meets all your needs. I'm working on the latter, an
object-based Lisp-alike with multiple inheritance. I have at *least* a
year of work ahead of me, but so far the interpreter is just over 70k of
compiled ANSI C. That is certainly small enough! :) And it already works
well enough to implement "Cloak of Darkness", "Alice", "Advent", etc.
Anyway, I do think an object-based language is the best fit for IF since
much of the time you want only one instance of any particular object.
Unfortunately there are very few around, and the most visible one
(Javascript) don't get no respect...
Dan Ellison (Long-time lurker, occasional head-poker-inner)
James Edward Gray II
> In article <6fd1fcf5.04031...@posting.google.com>, James Edward Gray II wrote:
> > I'm brand new to IF, but definitely not new to Perl. To me, they seem
> > like an ideal fit. In fact, so much so that I went looking for what
> > someone must have does before me, but other that Rezrov I can't find
> > any significant links between the two.
>
> Why an ideal fit? Just because Perl is good at text parsing? Because
> the actual "parsing" part of an IF parser is pretty trivial - it's the
> world model that's the hard part, and I don't see where Perl has a huge
> advantage there.
Funny you should choose this as a complaint. I would say one of
Perl's strengths is that the combination of auto-resizing arrays,
hashes, and references make dealing with complex data structures
almost trivial.
The following example is super simple, but it was coded up in a matter
of minutes:
#!/usr/bin/perl
use strict;
use warnings;
# build world as nested hashes
my %world = ( Bridge => { Description => 'The Bridge of the
spaceship...',
Exits => { North => 'Quarters',
West => 'Airlock',
South => 'Engines' } },
Engines => { Description => 'The ship\'s engine room...',
Exits => { North => 'Bridge' } },
Airlock => { Description => 'The primary airlock...',
Exits => { East => 'Bridge' } },
Quarters => { Description => 'Crew quarters...',
Exits => { South => 'Bridge' } } );
# if would be easy and better to replace the above hard coded
definitions,
# with definitions loaded from an external data file
my $where = 'Bridge'; # starting point
while (1) { # infinite event loop
# describe where we are
print "\n$where\n $world{$where}{Description}\nExits\n";
for my $exit (keys %{ $world{$where}{Exits} }) {
print " $exit ($world{$where}{Exits}{$exit})";
}
# ask for a command
print "\n\nWhat now? ";
chomp( my $command = <> );
# parse commands
if ($command =~ /^(?:n(?:orth)?|e(?:ast)?|s(?:outh)?|w(?:est)?)$/i) {
my %directions = qw(n North e East s South w West);
my $exit = $directions{lc substr $command, 0, 1};
if (exists $world{$where}{Exits}{$exit}) {
$where = $world{$where}{Exits}{$exit}; # change location
}
else { print "\nYou can't go $exit from here.\n"; }
}
elsif ($command =~ /^l(?:ook)?$/i) {
# DO NOTHING - just looping will reprint description
}
elsif ($command =~ /^(?:quit|exit|bye)$/i) { exit; }
else { print "\nCommand '$command' not found.\n"; }
# etc...
}
__END__
I know this doesn't yet do much, but it's actually pretty easy to
extend further. Add a nested "Commands" hash for each room, for
example. If a command isn't recognized as one of the basics, check
there. The values could be sub routine references, which get called
when matched.
It's also easy to add a hash that tracks player state information.
Give that hash and each room an "Inventory" array, implement "get" and
"drop" (or whatever), and you've got basic object support.
For added fun, add a save and load subroutine for the world hash and
you've turned a simple quick-and-dirty script into a game engine
easily reused by editing data files. The subroutine references would
be a problem there, so switch them to strings of Perl code that get
eval()ed. You don't lose any power that way and they serialize to the
data file no problem.
Those are quick ideas and easy to implement. We haven't even got to
Perl's objects yet, which to be honest is what I would use for any
serious projects. Despite the implications of an above post, they're
are very functional and surprisingly flexible.
I've seen multiple sites in my IF research that suggested skipping
simple IF languages and going right to TADS or Inform so you're not
too limited in what you can do. I guess to me, using a full fledge
programming language is a similar leap.
Let's think about an example. I want to build a "Library" room,
complete with book-fetching librarian. You ask the librarian for a
book, they wander off for a time, then return with it and you can read
it. Now I probably want to make one book in the list significant, but
I want to give the impression of a library that really has some books.
If I'm using Perl, my first thought is "Easy, make requests to
Project Gutenberg." (This is just an example. Please don't try this
at home without checking that it is in fact legal first.) If I can
use the LWP modules, this goes down to a couple of lines of code even,
but I can certainly do it without them too. Throw in a call to fork()
and the user can keep playing while "the librarian" is busy walking
the lag-filled Net... er, I mean bookshelves. Is this equally simple
with TADS or Inform?
James
James Edward Gray II
> With all due respect, Perl's object capabilities are bolted on...
Perl's objects are far from perfect, I'll give you. As a Certified
Java programmer, they took more than a little getting use to for me.
But don't make the mistake of thinking they aren't used to do real
work every day. I've written a 3,000+ line server in Perl's objects.
It's functional, useful, extendable and maintainable.
> I'd suggest you attempt to port Cloak of Darkness to
> Perl and see how it goes. Cloak of Darkness is Roger
> Firth's test game - it's been ported to just about every
> IF system in existance so it makes a great testbed.
>
> If you manage that, then try Alice. Alice is only one room,
> but it's quite a bit more complex (about 500 lines of Inform
> code.)
Those are excellent ideas. I believe I'll try that very thing. Thank
you.
James
Knight37
news:6fd1fcf5.04031...@posting.google.com:
> Tell me, why is it a bad idea to use Perl?
If your goal is to write a game that a lot of people will play then it's a
bad idea because I doubt that many people are going to want to install a
Perl distribution just to play one game. But if your goal is to learn and
have fun writing regardless of having an audience then go for it.
Knight37
Quintin Stone
> I know this doesn't yet do much, but it's actually pretty easy to extend
> further. Add a nested "Commands" hash for each room, for example. If a
> command isn't recognized as one of the basics, check there. The values
> could be sub routine references, which get called when matched.
>
> It's also easy to add a hash that tracks player state information.
> Give that hash and each room an "Inventory" array, implement "get" and
> "drop" (or whatever), and you've got basic object support.
It is very easy to do a simple game in Perl. That's Perl's strength.
It's easy to do quick and dirty scripts.
However (and I say this as an unabashed script monkey whose home pages are
absolutely dripping with Perl), the heart and mind of any IF are the world
model and parser. And the parser is more than just the tokenization, it's
also the intelligence to choose the proper matches and do disambiguation.
In these respects, Perl doesn't have an inherent advantage over any other
general purpose language, or specialty IF language written in one of those
general purpose languages.
> I've seen multiple sites in my IF research that suggested skipping
> simple IF languages and going right to TADS or Inform so you're not too
> limited in what you can do. I guess to me, using a full fledge
> programming language is a similar leap.
Read enough reviews and you will see that modern IF players expect a
certain level of sophistication to their games: pronouns, undo (of at
least 1 command), mutliple objects with the possibility of exceptions, and
more. The issue with using a full language is that you have to start from
square one and build all that from scratch if you want your game to be
well received by the community at large.
> Let's think about an example. I want to build a "Library" room,
> complete with book-fetching librarian. You ask the librarian for a
> book, they wander off for a time, then return with it and you can read
> it. Now I probably want to make one book in the list significant, but
> I want to give the impression of a library that really has some books.
> If I'm using Perl, my first thought is "Easy, make requests to Project
> Gutenberg." (This is just an example. Please don't try this at home
> without checking that it is in fact legal first.) If I can use the LWP
> modules, this goes down to a couple of lines of code even, but I can
> certainly do it without them too. Throw in a call to fork() and the
> user can keep playing while "the librarian" is busy walking the
> lag-filled Net... er, I mean bookshelves. Is this equally simple with
> TADS or Inform?
Nope, because these languages (TADS, Inform) weren't built with networking
in mind. And the reason is that they are for traditionally self-contained
games that might be played on a home computer, a server, a PDA, or maybe
even a graphics calculator. So in this hypothetical, you do have a
trade-off between some additional functionality that won't be useful to
every player, and the convenience of having the hardest parts of the
system already done for you and thoroughly tested for years with lots of
libraries targeted at specific IF problems.
Despite what some people say, I don't think anyone here really wants to
discourage people from using general purpose languages in writing IF so
much as open their eyes to the considerable hurdles they'll face in the
process. From the reviews I've read (and my own experience), the
complaints end up being:
A) The game couldn't recognize some/most standard IF command/syntax
B) The game didn't have the normal meta-commands I'm used to
C) I couldn't play it on my Linux/PalmOS/Mac/TRS-80 machine
If you're interested in developing, say, a Perl module for IF development,
you'll probably be able to find some people interested in helping. To
bring it up to the sophisticatin level of existing IF languages, however,
will be a considerable task.
/====================================================================\
|| Quintin Stone O- > "You speak of necessary evil? One ||
|| Code Monkey < of those necessities is that if ||
|| Rebel Programmers Society > innocents must suffer, the guilty must ||
|| st...@rps.net < suffer more." -- Mackenzie Calhoun ||
|| http://www.rps.net/QS/ > "Once Burned" by Peter David ||
\====================================================================/
Andrew Plotkin
> Joe Mason <j...@notcharles.ca> wrote in message news:<slrnc5fm6...@gate.notcharles.ca>...
> > In article <6fd1fcf5.04031...@posting.google.com>, James Edward Gray II wrote:
> > > I'm brand new to IF, but definitely not new to Perl. To me, they seem
> > > like an ideal fit. In fact, so much so that I went looking for what
> > > someone must have does before me, but other that Rezrov I can't find
> > > any significant links between the two.
> >
> > Why an ideal fit? Just because Perl is good at text parsing? Because
> > the actual "parsing" part of an IF parser is pretty trivial - it's the
> > world model that's the hard part, and I don't see where Perl has a huge
> > advantage there.
>
> Funny you should choose this as a complaint. I would say one of
> Perl's strengths is that the combination of auto-resizing arrays,
> hashes, and references make dealing with complex data structures
> almost trivial.
The world model is a higher-level problem than designing its data
structures. The problem is making the world behave in a way which
supports the common IF defaults, but can also be extended in all the
strange and ad-hoc ways which IF games requires. Without causing
exponential complexity problems for the author.
I have begun to think that Inform and TADS, with their well-developed
models -- even TADS 3 -- are only first-generation solutions to the
problem.
John Roth
news:opr40ed6...@news.look.ca...
You mean something like IO (www.iolanguage.com)? While
I've never used it, I think it's got some real possibilities in that area.
John Roth
John Roth
"James Edward Gray II" <pe...@grayproductions.net> wrote in message
news:6fd1fcf5.04031...@posting.google.com...
Nice example.
John Roth
>
> James
John Roth
"Andrew Plotkin" <erky...@eblong.com> wrote in message
news:c3a43a$e5g$1...@reader1.panix.com...
I thoroughly agree. As an occasional dropper-inner on these forums,
I see lots of room for improvement.
John Roth
Joe Mason
> Joe Mason <j...@notcharles.ca> wrote in message news:<slrnc5fm6...@gate.notcharles.ca>...
>> In article <6fd1fcf5.04031...@posting.google.com>, James Edward Gray II wrote:
>> > I'm brand new to IF, but definitely not new to Perl. To me, they seem
>> > like an ideal fit. In fact, so much so that I went looking for what
>> > someone must have does before me, but other that Rezrov I can't find
>> > any significant links between the two.
>>
>> Why an ideal fit? Just because Perl is good at text parsing? Because
>> the actual "parsing" part of an IF parser is pretty trivial - it's the
>> world model that's the hard part, and I don't see where Perl has a huge
>> advantage there.
>
> Funny you should choose this as a complaint. I would say one of
> Perl's strengths is that the combination of auto-resizing arrays,
> hashes, and references make dealing with complex data structures
> almost trivial.
Well, obviously, but that's not a Perl monopoly. Lot's of languages
have those. You were talking about an "ideal" fit, so I was looking for
something Perl has that Python or Ruby don't.
Joe
Fredrik Ramsberg
> "John Roth" <newsg...@jhrothjr.com> wrote in message news:<105f8v0...@news.supernews.com>...
> > With all due respect, Perl's object capabilities are bolted on...
>
> Perl's objects are far from perfect, I'll give you. As a Certified
> Java programmer, they took more than a little getting use to for me.
> But don't make the mistake of thinking they aren't used to do real
> work every day. I've written a 3,000+ line server in Perl's objects.
> It's functional, useful, extendable and maintainable.
It cracks me up to hear Perl and maintainable in the same sentence
without a negation nearby... I've worked with Perl for a year. Comparing
to the other dozen or so languages I've used, I think Perl is the least
maintainable I've seen.
It's very powerful, but it also invites the programmer to write totally
incomprehensible code. A good, disciplined programmer can write more
maintainable code, but good Perl programmers tend to be more interested
in squeezing in a lot of funcionality in few lines of code. The basic
design philosphy "There's more than one way to do it" is pretty much the
worst design philosophy I've seen, at least on par with that of InterCal.
It's a language by hackers, for hackers.
That said, the example you showed is promising. You have some valid
points, but saying that Perl makes for maintainable code isn't one of
them.
I wish you good luck anyway, and will keep a keen eye on what you come
up with, should you post it here.
/Fredrik
Joe Mason
> It cracks me up to hear Perl and maintainable in the same sentence
> without a negation nearby... I've worked with Perl for a year. Comparing
> to the other dozen or so languages I've used, I think Perl is the least
> maintainable I've seen.
Hey, I hate Perl more than anybody, and I've been manfully resisting
the flamewar invitation. Is all my restraint for nothing?
Joe
Default User
That's the usual case for a general-purpose language. If you want to
develop games for people, use one of the systems. If you want to come up
with an exercise to improve your skills with a language, IF is a great
project. It touches on most of the typical programmin challenges, except
perhaps numerical computation.
Brian Rodenborn
John Roth
After a while, the invitations become less and less inviting.
John Roth
>
> Joe
John Roth
"Default User" <first...@boeing.com.invalid> wrote in message
news:4058A7E9...@boeing.com.invalid...
It's also a good testbed for techniques that are difficult
in Inform or TADS. The pity is that it takes quite a bit
of work to get to the point where Inform and TADS run
out of steam, and then you risk having run down the wrong
road.
John Roth
>
>
>
> Brian Rodenborn
Nikos Chantziaras
>
> seem like an ideal fit.
That's because you're brand new to IF but definitely not new to Perl.
Jesse McGrew
...
> Wouldn't this be the perfect situation for a prototype- or object-based
> language? No classes, so no problem getting a singleton. You can even
> modify "parent" objects on the fly and see the effects immediately in
> all child objects (imagine lighting a set of rooms all at once by giving
> the parent a "light" property). The only problem with general-purpose
> languages is that they are usually very large. Even the smallest
> runtimes can't compete with the size of your average z-code interpreter.
Which languages did you have in mind? I know TADS has that kind of
object model, as does my own cheap knockoff Snack
(http://sf.net/projects/snack/), but of course those languages are
designed for IF.
Jesse
James Edward Gray II
> Well, obviously, but that's not a Perl monopoly. Lot's of languages
> have those. You were talking about an "ideal" fit, so I was looking for
> something Perl has that Python or Ruby don't.
That's easy. I know Perl, and not Python or Ruby. ;)
James
James Edward Gray II
serious and informative answers. You have opened my eyes to many
issues. Your words are not falling on deaf ears. I'm listening.
I do believe Perl is capable of building text adventure games.
Serious projects, not just the simple toys I've shown. (To those who
don't, let's just agree to disagree.)
I realize that going that route may alienate some players (mainly
portable devices and players who don't wish to install perl). On the
flip side, it could be argued that perl is likely installed on far
more machines than say TADS today, so I may gain a few at the same
time.
Yes, I would have to build a system from scratch and I guess that
would add to the effort. At the same time, it may give me an
opportunity or two to try some unique approaches and that could be a
good thing too.
Maybe that's a sign that I'm really itching to build a Perl IF machine
and/or library, over a specific adventure. I hadn't really considered
that until it was brought up, but has some appeal. The idea of
bringing some others into the project who might like to help would be
a real boon too.
I'll think on all that you've said and make a well informed choice.
Again, thank you.
James
Susan Davis
>
> I wouldn't be at all surprised if this
> were easy in Ruby, though. Have you looked at that? If I were to write
> an IF world model in general language, that's probably the one I'd pick,
I did some work several years ago to try to use Scheme as an IF
development language, and finally got out because I was spending too
much time writing tools and not enough writing actual games. My latest
shiny new toy is Squeak, and I'd be tempted to try to use it if I ever
let myself get dragged back into tool development again.
But from a player's perspective, the problem with Squeak is that it
requires that the user install a Smalltalk VM (or browser plug-in)
on their machine in order to play, which isn't reasonable. We already
have three major IF VM's (the Z-machine, Glulx, and TADS), which is at
least one too many, and I tend to avoid games that don't run on a VM
that I already have. I'm willing to assume that a player would have
a Java VM installed, and possibly a copy of Perl, but something like
Squeak or Guile would be pushing it.
PAWS actually stacks up fairly well from that perspective: I have a
version of Python already on most of my machines, to run games like
Frozen Bubble and Solarwolf, and if I didn't, Python code can be
compiled for the JVM using Jython. If I were distributing a PAWS
game, I'd probably Jython it, and distribute the resulting JAR, as
an IF game in a human-readable scripting language is too much of
an open invitation for the player to spoil the game by reading the
code. Which is a problem with using Perl, come to think of it.
-- Sue --
(I had been intending to use Kawa to run my Scheme system on the JVM,
but at the time, it didn't do tail recursion correctly.)
--
Susan Davis <s...@sue.net>
Daniel Barkalow
> In article <105f8v0...@news.supernews.com>, John Roth wrote:
> > This leads to interesting problems. Most IF programs need
> > to define routines (that is, methods to use OO-speak) for each
> > object, which usually means (in Python) that one has to both
> > create a class and instantiate it. PAWS (Python Adventure
> > Writing System) has a real problem with the movement maps.
> > I'm not sufficiently familiar with PUB (Python Universe Builder)
> > to do a critique.
> >
> > As a professional software developer, I could probably
> > fix most of the difficulties with PAWS, but the result still
> > wouldn't be as convenient as a purpose built language.
>
> I tried briefly to create a singleton class in Python that would
> automatically create an instance object without needing any extra
> syntax, but never got very far. I wouldn't be at all surprised if this
> were easy in Ruby, though. Have you looked at that? If I were to write
> an IF world model in general language, that's probably the one I'd pick,
> because it seems like it can be tweaked to provide the same types of
> conveniences (grammar tables, singleton objects) that custom built IF
> languages have.
It might actually be worth taking another look at Java for IF sometime
soon; most of the changes from the original Java have addressed ways in
which it was singularly unsuitable. For example, you can now create
anonymous classes with single instances pretty easily, and you can have
methods which take variable numbers of arguments (like Inform's
"print" statement). There's also support for keeping compile-time type
information in structures, so you don't have tons of casts everywhere, and
there's a nice syntax of looping over lists.
Of course, there's still the problem that you'd have to write a complete
library or port one from a special purpose language. But at least now the
language syntax isn't so much of a barrier.
-Iabervon
*This .sig unintentionally changed*
Daniel Ellison
wrote:
Yes, that's the idea. I looked at Io before starting this project, but the
syntax didn't do anything for me. It's quite small at 100-200k, and is
prototype-based. It also has network extensions for those who like that
sort of thing. :) Of course, that will increase the size. But I agree, it
does have potential. Maybe I could get used to the syntax...
Daniel Ellison
Daniel Ellison
As John mentioned, Io is a good example of what I was talking about.
Rhino, a stand-alone Javascript implementation in Java, would also work.
If you wanted to get really fancy with graphics yet still have a full-on
prototype-based language, use Macromedia's Actionscript, which is built
into Flash. Of course, the last two don't really meet the size criterion
very well.
Daniel Ellison
Craig Latta
Hi Sue!
> My latest shiny new toy is Squeak, and I'd be tempted to try to use
> it if I ever let myself get dragged back into tool development again.
I'll do my best. :)
> But from a player's perspective, the problem with Squeak is that it
> requires that the user install a Smalltalk VM (or browser plug-in)
> on their machine in order to play, which isn't reasonable.
You might be interested in a minimal version of Squeak I'm writing,
which installs and runs itself with a single webpage visit, is fairly
small (virtual machine and memory snapshot are each around 90K), and can
load modules into itself over a network. It's at
http://netjam.org/squat/.
Oh, and for people who were interested in the "authoring as IF" message
I posted a few weeks back, my current spec transcript (using Cloak of
Darkness) is at http://netjam.org/cloak/.
take care,
-C
--
Craig Latta
improvisational musical informaticist
cr...@netjam.org
www.netjam.org
Smalltalkers do: [:it | All with: Class, (And love: it)]
Joe Mason
> It might actually be worth taking another look at Java for IF sometime
> soon; most of the changes from the original Java have addressed ways in
> which it was singularly unsuitable. For example, you can now create
> anonymous classes with single instances pretty easily, and you can have
That's interesting - how does that work?
Joe
Sam Denton
> I would like to thank everyone who has responded to my questions with
> serious and informative answers. You have opened my eyes to many
> issues. Your words are not falling on deaf ears. I'm listening.
>
> I do believe Perl is capable of building text adventure games.
> Serious projects, not just the simple toys I've shown. (To those who
> don't, let's just agree to disagree.)
I'm coming into this flame-fest a day late, but I'm in the process of
writing several Inform utilities in Perl. One is 'log2inf' which
takes a transcript file (x.log) and produces includable Inform source
(x.inf). It's currently undergoing a major expansion in which I'm
reading and parsing the grammar productions found in 'Grammar.h', just
so I can recognize and parse valid commands. So, yes, I agree that
Perl has the power.
OTOH, Perl programs are human readable. People can argue with me on
this, but the more accessible the source code, the easier it is for me
to cheat in a game. Inform encodes all ASCII so even a 'strings'
utility won't reveal details of the operation of a game. Maybe I'm
weak-willed, but I hate having hints, walk-throughs, etc, handy when
playing a game, as the temtation to use them can be unbearable when a
puzzle is challenging. And once you do use something, its hard to
avoid looking a "neighboring" hints. (Can you tell that I like
Invisiclue systems?)
Then there's the target audience. Just because a computer has Perl
installed doesn't mean that the user has any interest in I-F. I have
at home a small Beowulf cluster with Perl installed, but I'm not going
to be playing I-F on any of it. I also have a PalmOS device, on which
I can play a game while flying between Atlanta and Paris without
worrying about the battery going dead. If someone wants an
introduction to I-F, there are several web-based systems that don't
require installation of any interpreter what-so-ever, while someone
who becomes interested is going to download Z-code and TADS 'terps
eventually anyway.
Just my $.02.
Esa A E Peuha
> The basic
> design philosphy "There's more than one way to do it" is pretty much the
> worst design philosophy I've seen,
Well, every (useful) language has that freedom to some degree, but Perl
does take it to ridiculous levels. The formal syntax of Perl is a
nightmare, but that's to be expected in a language that's a superset of
both Sed and Awk...
--
Esa Peuha
student of mathematics at the University of Helsinki
http://www.helsinki.fi/~peuha/
Quintin Stone
> Maybe that's a sign that I'm really itching to build a Perl IF machine
> and/or library, over a specific adventure. I hadn't really considered
> that until it was brought up, but has some appeal. The idea of bringing
> some others into the project who might like to help would be a real boon
> too.
One of the reassuring things about using a terp language that runs in a
virtual machine is that players can run games without too much worry of
malicious code causing damage to their machine. (This is assuming you
trust the author of the interpreter, of course.) That might be something
you keep in mind while working on your system. I haven't put any real
thought into a Perl "sandbox" mode, but I'm reasonably sure someone could
figure out a way.
Daniel Barkalow
The compiler generates a class as you specified it to be, and puts in an
object creation of that class. It's not any more efficient in the
implementation, but the source is much cleaner. It also does some tricks
automatically to make it possible to refer to things in the scope outside
the expression from inside it. You end up with a bunch of classes with
names like Rooms+3, which are dealt with automatically by the compiler.
As for how you write it:
Item clock = new Item() {
public String getDescription() {
return "It is a clock that says " + formatTime();
}
};
This actually creates an object of a anonymous subclass of Item, which
overrides getDescription(). It's not really a singleton, in that, if you
run this several times, you'll get separate instances each time, but if
this is in a context that can only be run once (a static block or as the
initializer for a static field), there's no way to create a second object
of the type.
Gene Wirchenko
[snip]
>One of the reassuring things about using a terp language that runs in a
>virtual machine is that players can run games without too much worry of
>malicious code causing damage to their machine. (This is assuming you
You mean like Microsoft Word?
Oops, bad example.
[snip]
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
A.M. Kuchling
Joe Mason <j...@notcharles.ca> wrote:
> I tried briefly to create a singleton class in Python that would
> automatically create an instance object without needing any extra
Michael Hudson suggests the following code. Prototype is the basic class;
Room and its subclasses would be part of the game.
--amk
class Prototype (type):
def __init__ (metacls, name, bases, attributes):
super(Prototype, metacls).__init__(name, bases, attributes)
def __new__ (metacls, name, bases, attributes):
klass = super(Prototype, metacls).__new__(
metacls, name,
tuple(map(type, bases)),
attributes)
inst = super(type(klass), klass).__call__()
return inst
def __call__(self, *args):
return type(self)(*args)
__metaclass__ = Prototype
class Room:
d = 3
def describe (self):
print 'I am a room. There are %i kittens here.' % self.d
class SpecialRoom(Room):
d = 4
class SpecialerRoom(SpecialRoom):
d = 6
print Room, type(Room), Room.d
Room.describe()
print SpecialRoom, type(SpecialRoom), SpecialRoom.d
SpecialRoom.describe()
SpecialerRoom.describe()
Joe Mason
> On Wed, 17 Mar 2004 05:23:09 GMT,
> Joe Mason <j...@notcharles.ca> wrote:
>> I tried briefly to create a singleton class in Python that would
>> automatically create an instance object without needing any extra
>> syntax, but never got very far. I wouldn't be at all surprised if this
>
> Michael Hudson suggests the following code. Prototype is the basic class;
> Room and its subclasses would be part of the game.
Curses! I came very close to doing this with Ruby last night, but
couldn't quite get it. Now you've beaten me to it.
This is very cool. I was worried that this would disallow dynamic
object creation, but the very first example in
http://www-106.ibm.com/developerworks/linux/library/l-pymeta.html led me
to this:
def clone(klass):
class anon(klass): pass
return anon
rooms = []
for i in range(0, 10):
rooms.append(clone(Room))
rooms[i].d = i
for i in rooms:
print i, type(i), i.d
i.describe()
Now all I'd add to this is an accessor, "SpecialRoom.proto = Room", so
you can track inheritance, and probably make the clone() function a
method of - ah, hell, let's do that right now.
class Prototype (type):
def __init__ (metacls, name, bases, attributes):
super(Prototype, metacls).__init__(name, bases, attributes)
def __new__ (metacls, name, bases, attributes):
# create a new class
klass = super(Prototype, metacls).__new__(
metacls, name,
tuple(map(type, bases)),
attributes)
# add a clone method if none exists
if not getattr(klass, "clone", None):
def clone(self):
class anon(self): pass
return anon
setattr(klass, "clone", clone)
# create an instance of the class and record the bases
inst = super(type(klass), klass).__call__()
inst.bases = bases
return inst
def __call__(self, *args):
return type(self)(*args)
__metaclass__ = Prototype
This is a little inconsistent - if I create a class like this:
class DNA:
bases = (A, C, G, T)
def clone(self, sequence):
seq2 = []
for i in sequence:
if sequence[i] not in bases:
raise DegradedError
else:
seq2[i] = sequence[i]
return seq2
Then bases would get overwritten but clone would not.
On the other hand, there might be a valid reason for overwriting clone,
same way you sometimes fiddle with the behaviour of __new__.
It also might be useful to make a convenience function to return X.bases
+ type(X), since right now the naive way to test for a "room" is "if
Room in x.bases", which of course isn't true for Room itself.
Joe
Amir Karger
> serious and informative answers.
Good for you for listening. Good for everyone else for not starting a
flame war.
> I do believe Perl is capable of building text adventure games.
> Serious projects, not just the simple toys I've shown.
Yes, it is. OTOH, as others said, you will have to build a parser &
world model from scratch. This is a lot of work that has taken a whole
community (not one person) YEARS to get right (for certain evolving
definitions of right).
The "game" you posted, while an impressive display of Perl's power and
conciseness, is pretty much a Perl version of the late 80's BASIC
Adventure games. (I should know;
http://www.perl.com/language/ppt/src/wump/wump) Coding moving and a
couple actions, maybe even a verb-object parser, is doable in many
languages. (Anyone played the Befunge IF game?) It's the details that
trip you up. (Smell? Ropes? NPCs?) And while Perl could handle it,
it won't be easy to code up all that stuff.
> I realize that going that route may alienate some players (mainly
> portable devices and players who don't wish to install perl). On the
> flip side, it could be argued that perl is likely installed on far
> more machines than say TADS today, so I may gain a few at the same
> time.
I believe ActivePerl contains a system where you can create an
"executable script" that basically includes Perl.exe. Though I don't
know what it does about modules, and the executables are probably pretty
big. But if it works, it means Windows users can play without
downloading Perl.
> Yes, I would have to build a system from scratch and I guess that
> would add to the effort. At the same time, it may give me an
> opportunity or two to try some unique approaches and that could be a
> good thing too.
I'm sure it would be fun. Well, when you start. Huge projects have their
unpleasant times, too. If you feel like doing it, then enjoy. Just take
the warnings from the raifers that you won't finish it in a month.
The biggest question here is whether your abilities would be best served
in starting your library from scratch OR in working on some other
effort, using existing tools. You might come up with new
parsing/modeling ideas, but if noone uses them because TADS/Inform are
the heavyweights, then it might be fun for you but not anyone else.
If that matches your goals, then go for it.
> Maybe that's a sign that I'm really itching to build a Perl IF machine
> and/or library, over a specific adventure.
Well, of course. A Perl monk would call this True Laziness. Why write
just one program when you can write a library that'll allow you to write
many programs, even though you'll probably end up writing NO programs,
because in the meantime you came up with this brilliant idea for a
library that would scan Dilbert gifs and pipe the punchlines to
fortune(6).
Since you asked about Perl-related projects in your original post - and
because I like talking about myself - I'll mention that I'm currently
working (sloooowly) on a project to translate Z-code into regular Perl.
(In theory, it will someday also translate into Parrot assembly. I've
also done a very ugly XML output, which, with REALLY neat XSLT's, could
in theory translate to other languages. Or maybe even get executed as a
new Web Z-machine? Too bad I know nothing about XML.)
The project is called Plotz, and I'm amused that a Google for Plotz
turns up the cosmically-but-not-otherwise-related www.plotzmachine.com.
(Plotz was also used in a raif discussion ages ago to mean "that thing
that IF has that makes it not just fiction".)
Plotz turns Z-code (Inform/Infocom assembly) like this:
4f2 @add g01 2 -> loc3
4f7 @jg loc3 17 5c1
4fa @output_stream 4
into Perl like this:
L4f2: $locv[3] = get_global_var(1) + 2;
L4f7: goto L5c1 if $loc[3] > 17;
# Can't do below in 1 line of Perl w/out serious golfing/obfuscation
L4fa: &Plotz::IO::output_stream(4);
Yes, it's completely useless, but it's fun. I'm currently refactoring
some of the I/O code, which I stole wholesale from Rezrov. After that, I
just need to code up save/restore, and I'll have all of the z3 opcodes
working (for certain definitions of working). If I ever finish that,
I'll clean up the code a bit more and then post it to CPAN.
Anyway, good luck with whatever PerlIF you decide to do.
-Amir Karger
Amir Karger
> pe...@grayproductions.net (James Edward Gray II) wrote in message news:<6fd1fcf5.04031...@posting.google.com>...
>
> writing several Inform utilities in Perl. One is 'log2inf' which
> takes a transcript file (x.log) and produces includable Inform source
> (x.inf).
Since I haven't said so before, let me say that this is an amazing,
truly creative idea. Are you designing it to be able to read multiple
transcripts (because you can't do all paths in one game for many games
- e.g., death)? Although there's the major danger that global
variables and object locations etc. will be different from transcript
to transcript - can you be sure you'll get consistent code?
James: here's an example of doing a neat, creative project that
doesn't reproduce 95% of things that have been done, but instead adds
to an existing system. (Then again, who'm I to talk? I wrote a Perl
parser for 80's-era BASIC.)
> OTOH, Perl programs are human readable. People can argue with me on
> this, but the more accessible the source code, the easier it is for me
> to cheat in a game. Inform encodes all ASCII so even a 'strings'
> utility won't reveal details of the operation of a game.
I don't buy it. If you're really concerned, it's super-trivial to have
Perl rot13 all of the strings, or encrypt them much more fancily.
Heck, you could store them as ZSCII without too much work. Or
"encrypt" the whole program with Acme::Blank.
> I have
> at home a small Beowulf cluster with Perl installed, but I'm not going
> to be playing I-F on any of it. I also have a PalmOS device, on which
> I can play a game while flying between Atlanta and Paris without
> worrying about the battery going dead.
No-one's cross-compiled Perl yet? How embarrassing!
http://www.perl.com/CPAN/ports/index.html
Looks like it's available for the Sharp Zaurus and WinCE. As Palms get
more powerful, I have to imagine they'll be able to handle Perl.
> If someone wants an
> introduction to I-F, there are several web-based systems that don't
> require installation of any interpreter what-so-ever
Bzzzt. If you've got a Perl IF library, it would be easy to whip up a
CGI script to run games on it.
-Amir
Stas Starkov
> I would like to thank everyone who has responded to my questions with
> serious and informative answers. You have opened my eyes to many
> issues. Your words are not falling on deaf ears. I'm listening.
[SNIP]
> Yes, I would have to build a system from scratch and I guess that
> would add to the effort.
Look at the fate of HUGO -- another good IF authoring system.
Stas Starkov
> I tried briefly to create a singleton class in Python that would
> automatically create an instance object without needing any extra
> syntax, but never got very far.
Well, we (Wildwizard and I) tried to expand PAWS and in several aspects
we more or less reached the level of Inform -- our purpose was to make
games playable in Russian. Here's example of the source code for a
single object:
############ Lava object ##################
def LavaProps( where = None ):
obj = Lava # internal object name (to refer to it in the program)
SDesc = "hot lava" # object's title
LDesc = "The lava is hot.<br>" # description
def before(): # "before" as in Inform
if Global.CurVerb not in [ExamineVerb, PutInVerb, PutOnVerb]:
s( "That would be dangerous." ) # say that to the player
return TRUE # and stop
else:
return FALSE
# player actions processing:
# def iPutInBefore():
# if ...
# return TRUE
def iPutOnBefore(): # it's possible to redirect actions
return Lava.iPutInBefore()
ProcessProps( obj, locals(), where ) # process the object properties
# instantiating the object from the item class:
Lava = item_cl( "noun1,noun2,noun3", "hot,red,boiling" )
LavaProps( LavaCave ) # LavaCave -- is where the lava is located
Lava.give( HIDE ) # some attributes
###########################################
(If you're interested, I can give more information about implementation,
but be ready to a lot of hacks in source code. :-) )
The IF authoring system (called "Hydra") was not very stable (i.e. it
was possible to break it easily), but it worked... And then I dumped it
in favor of RTADS (Russian variation of TADS).
Joe Mason
It's that "instantiating" step that I want to skip - even if it's only a
line, like in this case, it still adds to the confusion of what goes in
the LavaProps class and what's part of the Lava item.
> (If you're interested, I can give more information about implementation,
> but be ready to a lot of hacks in source code. :-) )
Sure, send it along. I should take a look at PUB, too - never even
tried that one.
Joe
Adam Thornton
Stas Starkov <st...@mail.rb.ruANTISPAM> wrote:
>Look at the fate of HUGO -- another good IF authoring system.
Kent Tessman cries!
Adam
Stas Starkov
LavaProps is just a function -- a common place for all properties of an
object. Hydra library is based on the PAWS and I couldn't _imagine_ that
it's possible to do what Michael Hudson have done.
>> (If you're interested, I can give more information about implementation,
>> but be ready to a lot of hacks in source code. :-) )
>
> Sure, send it along.
I'm not sure that I'll show many tricks -- the Hydra library is more
"extensive" then "intensive", but it worked for Russian language. :-)
What I'd like to show is what ProcessProps() does:
############
def ProcessProps( obj, locals, where = None ):
""" Transferring input _locals_ into the object _obj_. Then move the
_obj_ to the _where_ location. """
if obj == None:
raise AttributeError, "obj == None: perhaps, obj wasn't redefined"
if not isinstance( obj, item_cl ) and not isinstance( obj, room_cl ) \
and not isinstance( obj, actor_cl ):
raise TypeError , "wrong type of obj"
props = zip( locals.keys(), locals.values() )
for prop in props:
k, w = prop
if obj != w and where != w:
setattr( obj, k, w )
move( obj, where )
############
The function allows to write:
############
def LavaProps( where = None ):
obj = Lava
d = 3
def PrintD():
print d
# ...
# etc
Lava = item_cl()
LavaProps()
############
instead of:
############
def PrintLavaD():
print Lava.d
Lava = item_cl()
Lava.d = 3
PrintLavaD()
############
Of course Michael Hudson's code is much better.
Joe Mason
> LavaProps is just a function -- a common place for all properties of an
> object. Hydra library is based on the PAWS and I couldn't _imagine_ that
> it's possible to do what Michael Hudson have done.
Oh, sorry - I was reading too quickly.
> ############
> def ProcessProps( obj, locals, where = None ):
> """ Transferring input _locals_ into the object _obj_. Then move the
> _obj_ to the _where_ location. """
Ah, I see. Nice and general - I like it.
> The function allows to write:
>
> ############
> def LavaProps( where = None ):
> obj = Lava
> d = 3
> def PrintD():
> print d
> # ...
> # etc
>
> Lava = item_cl()
> LavaProps()
> ############
>
>
> instead of:
>
>
> ############
> def PrintLavaD():
> print Lava.d
>
> Lava = item_cl()
> Lava.d = 3
> PrintLavaD()
> ############
Yeah, that's an improvement. But, like I said, the biggest hangup for
me was just remembering to put things in different places - a function
for this, a table for that - instead of all in one class. For which...
> Of course Michael Hudson's code is much better.
I'll note that metaclasses were only available in Python 2.2, which
didn't come out until 2001. (I know this only because I spent all
yesterday reading about them.) IIRC PAWS is much, much older than that,
and probably your own code was too.
Joe
Roger Carbol
> I wouldn't be at all surprised if this
> were easy in Ruby, though. Have you looked at that? If I were to write
> an IF world model in general language, that's probably the one I'd pick,
> because it seems like it can be tweaked to provide the same types of
> conveniences (grammar tables, singleton objects) that custom built IF
> languages have.
Surely, Inform, TADS3, et cetera, are general languages.
.. Roger Carbol ..
mathew
Knight37 <knig...@email.com> wrote:
>If your goal is to write a game that a lot of people will play then it's a
>bad idea because I doubt that many people are going to want to install a
>Perl distribution just to play one game.
On the other hand, everyone except Windows users already has a Perl
distribution.
mathew
mathew
>them and I do know Perl which I can and have used to do everything
>under the sun for years now.
This sounds suspiciously like the Golden Hammer antipattern.
mathew
Richard Bos
Revo? MacOs 9? Sinclair QL? The world is not just made of _your_ bitty-
box and _their_ bitty-box, you know.
Richard
Rexx Magnus
I'm praying that it's sarcasm, and not a genuine "there are only two OSes"
mentality!
To email me, visit the site.
Daniel Ellison
Further to the prototype-based language discussion, a new one has just
popped up: Prothon. It claims to be a classless Python, i.e. prototyped.
It's still pre-alpha, but is quite interesting nonetheless. I do think
object- or prototype-based languages have an excellent future and are a
viable alternative to object-oriented languages. Here's the Prothon
announcement message from comp.lang.python:
"Mark Hahn" <ma...@prothon.org> wrote in message
news:mailman.1080239527.2...@python.org...
> Ben Collins and I have developed a new interpreted object-oriented
language
> very closely based on Python, that is Prototype-based, like Self
> (http://research.sun.com/research/self/language.html) instead of
class-based
> like Python.
>
> I have named the language Prothon, short for PROtotype pyTHON. You can
> check it out at http://prothon.org.
>
> The prototype scheme makes object oriented computing very simple and
> complicated things like meta-classes melt away. Once you get used to
> prototypes, classes seem very ancient and old-fashioned. You can inherit
> data as well as methods and you can switch prototypes (think "types" or
> "classes") on the fly.
>
> Prothon is pre-alpha, but runs well enough to give it a spin. Basic
types,
> the File object, importing, packages, and the Re module are ready to try.
> It runs on Linux/Unix and Windows.
>
> Obviously Prothon is not Python compatible, so I have taken the liberty of
> implementing many changes that have been imagined for the almost mythical
> Python 3.0. Right now I've made decisions unilaterally, but I'm not
> planning on freezing language decisions until 7/04, so get on the Prothon
> mailing lists and make your opinions known.
>
> Since the Prothon interpreter has been written from the ground up, we've
had
> the opportunity to make it industrial-strength. We feel this is very
> important for high-end hosting applications, and that this is a current
> weakness of Python and it's GIL. Prothon has no GIL. Here are some
> interpreter features:
>
> - Uses native OS threads, even multiple interpreters can run at once on
the
> same objects.
>
> - Locking is done at the object level with shared read locks and exclusive
> write locks.
>
> - No recursion limits, Prothon is stackless.
>
> - Garbage collection is mark-and-sweep in seperate thread.
>
> - C coding is simple. Macros simulate coding at Prothon level. (No
> reference counting!)
>
> - Ints are 64-bits, internal architecture is all 64-bit.
>
> - Built on Apache Portable Runtime (APR) for stability, ease in porting,
and
> eventual integration with Apache.
>
mad...@bmrb.wisc-antispam.edu
MacOs is unix now.
Besides, you can always distribute a perl interpreter as part of
your game, right in the same package.
Gene Wirchenko
>On Fri, 26 Mar 2004 02:15:09 GMT, mathew scrawled:
>
>> In article <Xns94AF69058...@130.133.1.4>,
>> Knight37 <knig...@email.com> wrote:
>>>If your goal is to write a game that a lot of people will play then it's
>>>a bad idea because I doubt that many people are going to want to install
>>>a Perl distribution just to play one game.
>>
>> On the other hand, everyone except Windows users already has a Perl
>> distribution.
>I'm praying that it's sarcasm, and not a genuine "there are only two OSes"
>mentality!
Um, remind me. Are we supposed to be running UsDOS or ThemDOS?
Joe Mason
>:> On the other hand, everyone except Windows users already has a Perl
>:> distribution.
>:
>:Revo? MacOs 9? Sinclair QL? The world is not just made of _your_ bitty-
>:box and _their_ bitty-box, you know.
>
> MacOs is unix now.
MacOs 9 is unix now? How'd they manage that?
> Besides, you can always distribute a perl interpreter as part of
> your game, right in the same package.
Neat trick for the platforms he just mentioned where they don't exist.
Joe
Michael Chapman Martin
> Neat trick for the platforms he just mentioned where they don't exist.
Perl exists for MacOS 7.0 and later.
http://www.macperl.com
The major platform I've seen people use for IF that isn't on the list of
Perl ports is PalmOS. Z-Code at least runs there...
--Michael
Steve Mading
Perl source code is open. So if there was enough of a demand for it,
it *could* be ported to one of those platforms by some dedicated
enthusiast. Since it's already got a number of ports, I'd imagine
there can't be a whole lot of platform-specific stuff in the main
code tree. The only problem might be size. I don't think Perl is
a tiny interpreter.
Richard Bos
> Richard Bos <r...@hoekstra-uitgeverij.nl> wrote:
> :mathew <me...@pobox.com> wrote:
> :
> :> In article <Xns94AF69058...@130.133.1.4>,
> :> Knight37 <knig...@email.com> wrote:
> :> >If your goal is to write a game that a lot of people will play then it's a
> :> >bad idea because I doubt that many people are going to want to install a
> :> >Perl distribution just to play one game.
> :>
> :> On the other hand, everyone except Windows users already has a Perl
> :> distribution.
> :
> :Revo? MacOs 9? Sinclair QL? The world is not just made of _your_ bitty-
> :box and _their_ bitty-box, you know.
>
> MacOs is unix now.
MacOs _9_ is not now, never has been, and never will be, a Unixoid. None
of the other two that I mentioned, or any of a great number of others,
come with a Perl distribution out of the box.
> Besides, you can always distribute a perl interpreter as part of
> your game, right in the same package.
For the Revo? Bit big, innit?
Richard
Steve Mading
: mad...@bmrb.wisc-antispam.edu wrote:
:
:> Richard Bos <r...@hoekstra-uitgeverij.nl> wrote:
:> :mathew <me...@pobox.com> wrote:
:> :
:> :> In article <Xns94AF69058...@130.133.1.4>,
:> :> Knight37 <knig...@email.com> wrote:
:> :> >If your goal is to write a game that a lot of people will play then it's a
:> :> >bad idea because I doubt that many people are going to want to install a
:> :> >Perl distribution just to play one game.
:> :>
:> :> On the other hand, everyone except Windows users already has a Perl
:> :> distribution.
:> :
:> :Revo? MacOs 9? Sinclair QL? The world is not just made of _your_ bitty-
:> :box and _their_ bitty-box, you know.
:>
:> MacOs is unix now.
:
: MacOs _9_ is not now, never has been, and never will be, a Unixoid.
I said "now", not "then". MacOS 9 isn't something I'd call "now".
: None
: of the other two that I mentioned, or any of a great number of others,
: come with a Perl distribution out of the box.
:
:> Besides, you can always distribute a perl interpreter as part of
:> your game, right in the same package.
:
: For the Revo? Bit big, innit?
Yeah, there are some platforms too small to run perl on. I also
don't know why anyone would bother playing an ID game on
them either.
Joe Mason
>: For the Revo? Bit big, innit?
>
> Yeah, there are some platforms too small to run perl on. I also
> don't know why anyone would bother playing an ID game on
> them either.
Ah, I see now. You're trolling. Please leave our otherwise rational
thread.
Joe
Ross Presser
> Yeah, there are some platforms too small to run perl on. I also
> don't know why anyone would bother playing an ID game on
> them either.
There are some people with minds too small to imagine people might have
other motives than they do. I don't know why anyone would bother talking to
such people either.
Steve Mading
I can't imagine why some people think that since THEY want to
do something that this means everyone else has to too. If
someone wants to develop an IF platform in a language that
doesn't work well on tiny environments, that's not a problem
unless that person wants to use it on tiny environments.
Otherwise, we'd all be using assembly language, just to make
sure each game can run on everything, even a 4-bit vending
machine CPU.
Steve Mading
Telling someone he can't use a language becuase it doesn't work
on YOUR platform is what made this thread irrational. I wasn't
complaining when someone a while back tried making a .NET based
IF system, even though I prefer using unix, for which I doubt
his .NET system would work well on. I just figured, "well, there's
a system I won't be using then."
Richard Bos
<spammer...@real-addr-is-madings-at-bmrb-wisc-edu.invalid> wrote:
> Joe Mason <j...@notcharles.ca> wrote:
> : In article <c4a2u5$mhp$1...@news.doit.wisc.edu>, Steve Mading wrote:
> :>: For the Revo? Bit big, innit?
> :>
> :> Yeah, there are some platforms too small to run perl on. I also
> :> don't know why anyone would bother playing an ID game on
> :> them either.
Neither do I, given that ID never did develop their games for the Revo.
Though it would've been fun to see Commander Keen on a QL <g>.
> : Ah, I see now. You're trolling. Please leave our otherwise rational
> : thread.
>
> Telling someone he can't use a language becuase it doesn't work
> on YOUR platform is what made this thread irrational.
Nobody told you that you _cannot_ use Perl; merely that, if you do, you
might not get as many players as if you'd used a "normal" IF language.
However, mathew said something else entirely. He claimed that
_everybody_ except Windows users already has a Perl distribution. This
is demonstrably untrue, and that very fact will hamper a game written in
Perl.
Richard
Rexx Magnus
rec.arts.int-fiction writing in message news:c4bg5j$g71$1
@news.doit.wisc.edu
> I can't imagine why some people think that since THEY want to
> do something that this means everyone else has to too. If
> someone wants to develop an IF platform in a language that
> doesn't work well on tiny environments, that's not a problem
> unless that person wants to use it on tiny environments.
> Otherwise, we'd all be using assembly language, just to make
> sure each game can run on everything, even a 4-bit vending
> machine CPU.
>
I don't think vending machines are terribly conducive to playing IF.
Steve Mading
: Steve Mading
How many people owning the smaller more cramped devices like that
don't also own a more full-fledged computer? The statement was not
that every device has perl, but that every PERSON does.
Steve Mading
: Steve Mading woke up on Tue, 30 Mar 2004 09:54:59 GMT and sat in
And I have the same opinion on the kinds of platforms that were
brought up as being unable to run Perl.
Joe Mason
>: I don't think vending machines are terribly conducive to playing IF.
>
> And I have the same opinion on the kinds of platforms that were
> brought up as being unable to run Perl.
We're talking about the same art form here, right? Text on a screen?
Commonly no fancy graphics? Originated on hardware vastly less powerful
than current pocket computers? Ideal for playing on platforms where
resources are limited?
Joe
Ben Heaton
On Tue, 30 Mar 2004, Steve Mading wrote:
> Rexx Magnus <tras...@uk2.net> wrote:
> :
> : I don't think vending machines are terribly conducive to playing IF.
>
> And I have the same opinion on the kinds of platforms that were
> brought up as being unable to run Perl.
>
One of those platforms was Mac OS 9. I don't know about its Perl
capabilities, but I can tell you from experience that it's conducive to
playing IF. I recall running games in both TADS and Inform on it, with
some rather nice interpreters (HyperTADS and MaxZip).
I don't think it's even technically possible for TADS to be ported to a
vending machine; there are some difficult stack issues.
-Ben Heaton
Steve Mading
:
:
If there was demand for it, Perl could be ported to MacOS 9. There
isn't demand because you get it by just upgrading to OSX.
Andrew Plotkin
> Ben Heaton <bh0...@mail.rochester.edu> wrote:
> :
> : One of those platforms was Mac OS 9. I don't know about its Perl
> : capabilities, but I can tell you from experience that it's conducive to
> : playing IF.
>
> isn't demand because you get it by just upgrading to OSX.
Steve, you're changing your defensive position with every post. It's
not convincing anyone; it's not even an argument.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Daniel Barkalow
> I don't think vending machines are terribly conducive to playing IF.
"Which Coke do you mean, the Coke or the Coke?"
"You can't see any Nestea here."
"I only understood you as far as wanting to vend."
Actually, I bet it wouldn't be too difficult to program a vending machine
to use IF-style messages.
-Iabervon
*This .sig unintentionally changed*
Steve Mading
: Steve Mading woke up on Tue, 30 Mar 2004 09:54:59 GMT and sat in
They keep giving me concoctions almost, but not quite, entirely
unlike tea.
Steve Mading
: Here, Steve Mading <spammer...@real-addr-is-madings-at-bmrb-wisc-edu.invalid> wrote:
:> Ben Heaton <bh0...@mail.rochester.edu> wrote:
:> :
:> :
:> : One of those platforms was Mac OS 9. I don't know about its Perl
:> : capabilities, but I can tell you from experience that it's conducive to
:> : playing IF.
:>
:> If there was demand for it, Perl could be ported to MacOS 9. There
:> isn't demand because you get it by just upgrading to OSX.
:
: Steve, you're changing your defensive position with every post.
False. I'm correcting repetative strawmen versions of my argument.
For example, someone said MacOS 9 has no perl. I said MacOS is
a unix now (with the understood, but unstated conclusion that this
means it has perl now). Someone misconstrued that to mean I was
saying MacOS 9 has perl - no, because MacOS 9 does not equal MacOS
"now" and is not what I was talking about. My stance didn't change.
Your understanding of it did.
I doubt I could get TADS to run on DOS 1.0. But it would
still be right for me to say it runs on DOS now.
Joe Mason
>: Steve, you're changing your defensive position with every post.
>
> False. I'm correcting repetative strawmen versions of my argument.
> For example, someone said MacOS 9 has no perl. I said MacOS is
> a unix now (with the understood, but unstated conclusion that this
> means it has perl now). Someone misconstrued that to mean I was
> saying MacOS 9 has perl - no, because MacOS 9 does not equal MacOS
> "now" and is not what I was talking about. My stance didn't change.
> Your understanding of it did.
MacOS 9 and MacOS 10 are entirely different operating systems. The
poster you were responding to didn't say "MacOS" (which could be
understood as "the most recent thing that calls itself MacOS"), he
*specifically* said MacOS 9. So when you responded talking about Unix,
either you didn't notice that he was talking about 9 - the charitable
response - or you were implying that nobody in their right mind would
still be running MacOS 9.
Since apparently it's the latter, I repeat that you are trolling.
Joe
Branko Collin
<spammer...@real-addr-is-madings-at-bmrb-wisc-edu.invalid>, you
wrote on Tue, 30 Mar 2004 21:02:06 +0000 (UTC):
>If there was demand for it, Perl could be ported to MacOS 9. There
>isn't demand because you get it by just upgrading to OSX.
ITYM 'updating'.
--
"Rotterdam: /Kielschieters/, omdat zij een bootje, dat met de kiel
naar boven in de Maas dreef, voor een walvisch hielden, waarop zij
hun geweren afvuurden." uit: Nederlandsche volkskunde, JKFH Schrijnen
Help dit en andere PD-boeken te corrigeren op http://www.pgdp.net
Josh Vanderhoof
> Steve Mading
> <spammer...@real-addr-is-madings-at-bmrb-wisc-edu.invalid>, you
> wrote on Tue, 30 Mar 2004 21:02:06 +0000 (UTC):
>
> >If there was demand for it, Perl could be ported to MacOS 9. There
> >isn't demand because you get it by just upgrading to OSX.
http://www.cpan.org/ports/index.html#macosclassic
Mac OS Classic (pre-X)
MacPerl support is included in perl, in releases later than 5.6.1. The
current release of MacPerl is based on 5.6.1. Mac OS 8.1 or better is
required, although the previous version (5.2.0r4) and the MPW tool may
be used on Mac OS 7.5.5 or better. For older Mac OS versions, see
MacPerl 4.1.8, all in the ports/mac/ directory.
Steve Mading
Your false dichotomy has been noted. Those two options were not
the only possibilities, which should be blantantly obvious since
my clarification represents at least a third option.
: Since apparently it's the latter, I repeat that you are trolling.
Your conclusion follows logically from your premise. But your
premise is false.
Cedric Knight
> On Tue, 30 Mar 2004, Steve Mading wrote:
>
>> Rexx Magnus <tras...@uk2.net> wrote:
>>>
>>> I don't think vending machines are terribly conducive to playing IF.
> I don't think it's even technically possible for TADS to be ported to
> a vending machine; there are some difficult stack issues.
On the other hand, the Z-machine is finite-state, and the logic in
vending machines, like a lot of other office machinery, is reasonably
powerful, usually based around a 8-bit CPU/EEPROM combination like the
8240. You may recall these kinds of embedded firmware were going to be
a target for the 'Microsoft at Work' idea back in the 90s.
There has been a discussion list for the possible implementation of the
Z-machine on embedded chips, initially working on a Z3 version of
Adventure. The main problem with most vending machines (except the
newest LCD versions) would obviously be that they can only scroll about
6 characters at a time. Still, someone claims to have installed the
prototype interpreter on a coffee dispenser at work, and got it up to
173 points during break times, just so she could leave it at the
confusing message "Insert coins to receive fresh batteries".
I'm now worrying about people who will only be able to play IFComp
entries at work. Couldn't the TADS stack problems be resolved in theory
by modifying the plastic cup machinery and feeding in an infinite number
of cups for it to work on, just like a Turing machine?
Just a thought
CK
Stas Starkov
<spammer...@real-addr-is-madings-at-bmrb-wisc-edu.invalid> wrote:
> Joe Mason <j...@notcharles.ca> wrote:
> : poster you were responding to didn't say "MacOS" (which could be
> : understood as "the most recent thing that calls itself MacOS"), he
> : *specifically* said MacOS 9. So when you responded talking about Unix,
> : either you didn't notice that he was talking about 9 - the charitable
> : response - or you were implying that nobody in their right mind would
> : still be running MacOS 9.
>
> Your false dichotomy has been noted. Those two options were not
> the only possibilities, which should be blantantly obvious since
> my clarification represents at least a third option.
>
> : Since apparently it's the latter, I repeat that you are trolling.
>
> Your conclusion follows logically from your premise. But your
> premise is false.
That's how typical troll acts -- he accuses other people in
misunderstanding.
You asked for it, man, -- you're plonked.
Matthew Russotto
Daniel Barkalow <iabe...@iabervon.org> wrote:
>On 30 Mar 2004, Rexx Magnus wrote:
>
>> I don't think vending machines are terribly conducive to playing IF.
>
>"Which Coke do you mean, the Coke or the Coke?"
>
>"You can't see any Nestea here."
>
>"I only understood you as far as wanting to vend."
>
>Actually, I bet it wouldn't be too difficult to program a vending machine
>to use IF-style messages.
"Violence is not the answer." (after being kicked)
--
Matthew T. Russotto mrus...@speakeasy.net
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue." But extreme restriction of liberty in pursuit of
a modicum of security is a very expensive vice.