--- "Randy W. Sims" <[EMAIL PROTECTED]> wrote:
> Amir Karger wrote:
> > I've written a module that parses Z-machine files[1] and translates
> > them into executable Perl scripts. In the future, it'll be
translating
> > to other languages: first on the list is PIR. I'd like to CPAN-ify
> > it, and wanted to ask about namespace.
>
> That's interesting. Are the scripts then independent of the module?
Um, no. Well, not yet. In v0.8, which I hope to release in the next
couple weeks, the script does a 'use Whatever::Runtime::Opcodes' and
'use Whatever::IO'. In theory, though, I could include those modules
at
the bottom of the created script. It's on my "Maybe TODO" list for
v1.0. This would allow a person to download just one Perl file to play
a
game, without needing a separate interpreter. (Of course, Jzip already
does this with C executables.)
I'm not optimizing for script shortness at all - the 92K Zork 1 Z file
contains 6800 commands, and currently yields a 960K Perl script, and
the
500K "Not Just an Ordinary Ballerina" (42000 commands) expands to 5 MB!
(Expanding machine language to entire lines of code will do that to
you,
although usually you don't notice, because of one-liner source commands
like '#include stdio.h'.) The Runtime modules are < 150K, even with
POD,
so it won't appreciably increase the game file size.
Once I get into other languages, there'll be more pressure to include
everything in one file, since I don't know how well "perl Makefile.PL;
make install" will work on Java code.
> > * Games::Zmachine - well, Z-machine isn't technically just for
> > games. I say "technically" because the most "useful" Z-machine
> > program I've seen is a Befunge interpreter. But this module is
> > really doing more munging than gaming.
>
> This is the namespace I'd expect to find it in, but since I'm not
> clear on the "translating" part, I don't know if that should be the
> complete name.
Let me explain. No, there's too much. Let me sum up.
This is not an interpreter, where you run "foo zork1.z3" and get to
play
Zork. Games::Rezrov does that. What my program does is take
Z-machine commands like (in a simplified Z assembly language):
1220 add 3 top_of_stack -> local1
1225 jg local1 global1a ?branch
1230 call sub_foo local1 2
.branch
1235 print_paddr 2a3b
and translates them to:
L1220: $local[1] = 3 + pop @stack;
L1225: goto L1250 if $local[1] > global_var(26);
L1230: z_call(1476, $local[1], 2);
# print " You are likely to be eaten by a grue."
# (I don't put a literal print in there because the text
# at that address can change (within limits)!)
L1250: output_text(decode_text(2a3b));
Except things are much uglier because, for example, any time you do
addition et al. in Z-code, you have to change the two arguments from
unsigned to signed integers. Yuck. (Someday, $local[1] will be tied to
a class that does the pack/unpack behind the scenes; by the time I get
there Moore's law will have gotten rid of any potential slowdown. And
Parrot will have a ZMachineInt PMC that knows how to do arithmetic.)
This is why I was not so inclined to make this a Games:: module. As I
mentioned in the original post, there have been some non-games written
in Z-code. But I think a more compelling reason is that this module is
parsing and translating. To me, those are more Language-y than Game-y
things.
On the other hand, I guess you can make the argument that the
end result is a playable game. And people aren't really coding in
Z-code for anything but fun at this point.
Having talked and thought it over, then, I'm less opposed to
Games::Zmachine than I had been. If most people think it logically
belongs there, I'll use that. It saves me a few keystrokes and columns
in my text editor compared to Language::Zmachine, if nothing else.
As far as your asking whether "that should be the complete name" -
well,
parsing will be done by GZ::Parser::*, translating by
GZ::Translator::*.
I've currently got a bunch of GZ::Runtime::* modules, but I was
thinking
of flattening that out and changing it to GZ::Input, GZ::Output,
GZ::Objects (things like lamps & swords, not OO objects), and GZ::State
for save/restore. I'm definitely just a beginning student of Zen and
the
art of module/directory hierarchies, though.
> > [1]For those unfamiliar with the Z-machine
Btw, the Z-machine shares with Perl the distinction of having been
ported to a huge array of platforms. In fact, one of the main reasons
Infocom created a virtual machine was that then they could write the
same Z-machine to run on all the different platforms available before
the diversity-less days of Wintel (plus N simple emulators, of course).
As a result of the simplicity & small memory requirements they built
in,
rec.arts.int-fiction had a thread about Z-machine on cell phones last
week. I'd hate to text message in "lie down in front of bulldozer",
though.
> Long live Zork!
Amen.
-Amir
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail
