An easier IF langauge?
Bill Mackenty
I know this subject has been discussed in the past, but after playing
some incredible games from the annual competition, I am reminded
a) how much I would like to write my own IF game
b) how difficult that seems to be using popular languages (TADS & Inform).
I have heard the argument that you can find someone to program for you,
but I'd like to write my own game. I suppose it has something to do with
owning my work (in a metaphysical sense).
Nonetheless, as an amateur programmer, I would love to write good
interactive fiction which could be played by a large number of folks
(read z machine compatible).
I wonder if there is an easier way to do this, and how many folks with
real literary talent, but no programming skill might take advantage of
such an easier way.
IMHO, of course...
Bill MacKenty
Keene, New Hampshire
Bill
Bill Mackenty wrote in message <6bfun4$6un$1...@news.monad.net>...
...
>a) how much I would like to write my own IF game
>b) how difficult that seems to be using popular languages (TADS & Inform).
>
>I have heard the argument that you can find someone to program for you,
>but I'd like to write my own game. I suppose it has something to do with
>owning my work (in a metaphysical sense).
>
>Nonetheless, as an amateur programmer, I would love to write good
>interactive fiction which could be played by a large number of folks
>(read z machine compatible).
>
>I wonder if there is an easier way to do this, and how many folks with
>real literary talent, but no programming skill might take advantage of
>such an easier way.
It seems to me that a "CASE-like" -tool for Inform could be built. I.E.
database like entry to create rooms, items, paths, etc....
Bill
Daniel Shiovitz
In article <6bg33g$e9m$1...@ha2.rdc1.sdca.home.com>,
Bill <bv...@inetworld.net> wrote:
>Bill Mackenty wrote in message <6bfun4$6un$1...@news.monad.net>...
>...
>>I have heard the argument that you can find someone to program for you,
>>but I'd like to write my own game. I suppose it has something to do with
>>owning my work (in a metaphysical sense).
>>I wonder if there is an easier way to do this, and how many folks with
>>real literary talent, but no programming skill might take advantage of
>>such an easier way.
>
>It seems to me that a "CASE-like" -tool for Inform could be built. I.E.
>database like entry to create rooms, items, paths, etc....
Someone proposes this roughly every three weeks here. The consensus is
always one of two things:
1) Ok, good idea, go write it.
2) The hard bits of programming can't be solved with a GUI.
Specifically, you can't write a game without coding special cases
(because otherwise your game would be just like every other game
produced with this GUI) and the thing about special cases is that
they're special. See?
It's probably an oversimplification to say that a GUI would be
*useless*, but very few people who can program well enough to write
one want to spend the time to do so, which may go to show something.
That said, then, there are roughly four courses open to someone who's
not a good (or not at all) a programmer, but has a Great Idea:
1) Do nothing. Go to your grave with the Great Idea graven upon your
heart but silent upon your lips.
2) Do something that's not very good (and usually get angry that
nobody is able to distinguish your Great Idea from all the mess
(or get disappointed because you can't either))
3) Learn. There are lots and lots and lots of people here who will be
happy to tell you "Hey, I'm not a programmer, but I managed to learn
enough TADS/Inform/Hugo to do something great that a lot of people
liked! Cool!" raif is an extremely helpful, friendly place for new
programmers to ask questions. This choice requires effort and time
on your part, but who said Great Ideas were easy?
4) Team up with someone can program but doesn't have a Great
Idea. This means sacrificing some part of the ownership of the
game, and may mean the game won't be as Great as it could have been
(but it may be better, too), but this may be the more sensible
course if you really don't want to learn how to program. There's an
IF collaborators list someplace. Look in the FAQ.
>Bill
--
(Dan Shiovitz) (d...@cs.wisc.edu) (look, I have a new e-mail address)
(http://www.cs.wisc.edu/~dbs) (and a new web page also)
(the content, of course, is the same)
HarryH
In article <6bg64p$9...@spool.cs.wisc.edu>, d...@mozzarella.cs.wisc.edu says...
>2) Do something that's not very good (and usually get angry that
> nobody is able to distinguish your Great Idea from all the mess
> (or get disappointed because you can't either))
I believe this is the course that I take. [ Hey y'all are moron who can't
understand greatness! :) ] In any case, once you can get something going,
assuming it doesn't crash midway, just show it to people. School of Hard
Knocks do have value, even if you have to wear asbestos most of the time.
Besides, there's enough friendly folks around here who helps with coding
trouble. (Unlike you-know-who who claims to know more or be able to do
better, but has nothing to show for it.)
-------------------------------------------------------
Of course I'll work on weekends without pay!
- successful applicant
Angus McLaren
>some incredible games from the annual competition, I am reminded
>
>b) how difficult that seems to be using popular languages (TADS & Inform).
>
>but I'd like to write my own game. I suppose it has something to do with
>owning my work (in a metaphysical sense).
>
>interactive fiction which could be played by a large number of folks
>(read z machine compatible).
>
>real literary talent, but no programming skill might take advantage of
>such an easier way.
>
As much as potential IF authors would love an easier way to create an IF
adventure, it just can't happen at the moment. TADS is fairly easy to learn,
even easier if you have had C or C++ programming experience. As for inform I
would say that it tends to be more readable and easier to understand when
programming it, although I myself prefer TADS because of my C++ experience.
The easiest, but not the best or most versatile, IF language is AGT.
HTH
Angus McLaren
nee...@hydra.com.au
"Where ever you go, there you are!"
Robert Masenten
bmac...@pisgah.keene.edu (Bill Mackenty) writes:
>
> I know this subject has been discussed in the past, but after playing
> some incredible games from the annual competition, I am reminded
>
> a) how much I would like to write my own IF game
> b) how difficult that seems to be using popular languages (TADS & Inform).
>
> I have heard the argument that you can find someone to program for you,
> but I'd like to write my own game. I suppose it has something to do with
> owning my work (in a metaphysical sense).
[snip]
> I wonder if there is an easier way to do this, and how many folks with
> real literary talent, but no programming skill might take advantage of
> such an easier way.
You might want to take a look at AGT. Some people have found it to
be less intimidating and easier to get started in than Inform and
TADS. (And it can form a "bridge" to the more complex languages,
familiarizing authors with general concepts.)
It has a bad reputation on this group because so many bad games have
been written with it, but I think this has more to do with when these
games were written rather than the system they were created with. (And
a look at some of the Inform entries from the last couple of
competitions should dispel any myth that Inform games can't be equally
poor.) And there have been good games produced with it (Cosmoserve,
Shades of Gray, Klaustrophobia, The Jeweled Arena...).
It's not on the level of Inform or TADS, but the truth is that many
games don't need the unlimited flexibility of those systems-- and many
of the clever tricks in those systems require a nontrivial level of
programing competence, anyhow. Also, AGT is not as weak as it
is often presented-- as several of the games I listed above
demonstrate. (Just for the record: it *is* possible to create loops
using AGT. :-) )
I'm *very* biased (being the author :-) ), but for anyone who does
decide to try AGT, the Magx compiler is faster, catches more errors,
and supports more features than the original compilers. (Including a
simple form of inheritance, support for disambiguation, and an
improved format for metacommands (suggested by Kevin Soucy).)
It can be found at ftp://ftp.gmd.de/if-archive/programming/agt/magx/.
You'll also need to download AGiliTy at
ftp://ftp.gmd.de/if-archive/programming/agt/agility/
in order to play the games.
At the moment, you unfortunately also need to get the original
Master's Edition at
ftp://ftp.gmd.de/if-archive/programming/agt/agtmastr.zip)
for the sake of the documentation. (I'm working on a complete user's
manual for Magx, but at the moment the docs only cover the differences
between the two system.)
Robert Masenten
David Glasser
>b) how difficult that seems to be using popular languages (TADS &
Inform).
>
>I have heard the argument that you can find someone to program for you,
>but I'd like to write my own game. I suppose it has something to do
with
>owning my work (in a metaphysical sense).
>
>interactive fiction which could be played by a large number of folks
>(read z machine compatible).
>
>real literary talent, but no programming skill might take advantage of
>such an easier way.
There are two Inform Beginner's Guides on the web. They aren't
completed yet, but you could give them a try. They are both linked to
from Graham Nelson's Inform page
(http://www.gnelson.demon.co.uk/inform.html). I highly recommend the
one by, let me think, Jeff Johnson. I haven't looked at the other one
for some time, but it is worth looking at too.
--David Glasser
gla...@NOSPAMuscom.com
David A. Cornelson
In article <6bfun4$6un$1...@news.monad.net>,
bmac...@pisgah.keene.edu (Bill Mackenty) wrote:
>
> I know this subject has been discussed in the past, but after playing
> some incredible games from the annual competition, I am reminded
>
> b) how difficult that seems to be using popular languages (TADS & Inform).
>
> I have heard the argument that you can find someone to program for you,
> but I'd like to write my own game. I suppose it has something to do with
> owning my work (in a metaphysical sense).
A hollow voice replies, "Deja Vu..."
Rewind to about October of 1997 and you will read a somewhat long-winded,
know- it-all type cry for the same type of help. I was mistaken and
humbly admit so now.
Interactive Fiction is a hybrid process of both writing AND programming.
Certainly collaboration with a good programmer could solve your problem,
but I agree with you, it doesn't 'seem right'.
This thread has a few direct responses about the various languages
available. I support the use of Inform, but I know from a good friend
that as a C++ programmer, he thinks TADS is much more intuitive.
Whatever. The process of creating a working and popular work of
interactive fiction goes far beyond being a writer or a programmer. This
news group and the annual competition will teach you 'rules of
engagement' that are not inherent in simply writing a game.
You need to 'get involved'. You need to wade into the mud (pun intended)
of interactive fiction and 'be the adventurer'.
This entails learning how the code 'works' so that you understand the
limitations as well as the 'art'.
I'm a believer in learning to write the code yourself. There is currently
no way to do this other than to download a language and it's components,
a few sample games, and begin to dig in.
I have a web page that will help you get started in Inform at
www.placet.com/int-fiction and there are many other helpful sites. The
archive at ftp.gmd.de is priceless and the repository of all important
related works.
Get cracking Bill. Post your questions here when you get started!
David A. Cornelson, Chicago
PS. That said, I still believe that a database driven Visual Inform could
help beginners. Just don't have the time or resources to build it myself.
Sorry.
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Stephen Griffiths
bmac...@pisgah.keene.edu (Bill Mackenty) wrote:
>I know this subject has been discussed in the past, but after playing
>some incredible games from the annual competition, I am reminded
>a) how much I would like to write my own IF game
>b) how difficult that seems to be using popular languages (TADS & Inform).
>I have heard the argument that you can find someone to program for you,
>but I'd like to write my own game. I suppose it has something to do with
>owning my work (in a metaphysical sense).
>Nonetheless, as an amateur programmer, I would love to write good
>interactive fiction which could be played by a large number of folks
>(read z machine compatible).
If z-machine compatibility is essential then Inform is the only
programming language option.
But the other two IF programming languages that are most commonly
mentioned - TADS and Hugo produce games that can be played on nearly
as many different computer systems. (The only glaring omission is that
Hugo games can't be played on the MacIntosh yet - but I would hope
that will problem will be rectified soon.)
As far as easier IF authoring systems go, someone else has mentioned
AGT or Magx. The 'Agility' AGT/Magx game player is available for
MSDOS/Windows PCs, MacIntosh, Amiga and Linux which covers a large
percentage of the potential audiences systems.
The Alan IF authoring system is another option you might like to take
a look at. Alan game playing software is available for the same four
systems as Agility plus the HP-UX and Solaris versions of Unix.
>I wonder if there is an easier way to do this, and how many folks with
>real literary talent, but no programming skill might take advantage of
>such an easier way.
While it may be easier to learn AGT or Alan than Inform, TADS or Hugo,
it's still going to be hard work (but lots of fun if IF is your
thing!) to write a polished, debugged, enjoyable-to-play piece of
interactive fiction. I think it would still involve a lot of work
with, for example, a visual, computer-aided I.F. programming tool.
(Such a tool doesn't exist to test that theory though so I could be
wrong!)
Whatever system you decide to use, there will be people available on
r.a.i-f to help you with your programming problems so good luck!
>IMHO, of course...
>Bill MacKenty
>Keene, New Hampshire
--
SteveG.
(Please remove the typo from my address
if you want to send me mail.)
Patrick Kellum
In article <6bic8g$q9a$1...@wnnews1.netlink.net.nz>, Stephen Griffiths was talking about:
>If z-machine compatibility is essential then Inform is the only
>programming language option.
Why is that? Creating, for example, an assembler that output z-machine
code is very possable. One of the greatest things about the z-machine is
that it is so well documented. I would guess that if someone were so
inclined (or had no social life) they could write an entire z-machine game
in a simple hex editor :-)
Patrick
---
A Title For This Page -- http://www.syix.com/patrick/
Bow Wow Wow Fan Page -- http://www.syix.com/patrick/bowwowwow/
The Small Wonder Page -- http://smallwonder.simplenet.com/
My Arcade Page -- http://ygw.bohemianweb.com/arcade/
"I have photographs of you naked with a squirrel." - Dave Barry
Mike Smith
Bill Mackenty <bmac...@pisgah.keene.edu> wrote in article
<6bfun4$6un$1...@news.monad.net>...
> I know this subject has been discussed in the past, but after playing
> some incredible games from the annual competition, I am reminded
>
> a) how much I would like to write my own IF game
> b) how difficult that seems to be using popular languages (TADS &
Inform).
>
> I have heard the argument that you can find someone to program for you,
> but I'd like to write my own game. I suppose it has something to do with
> owning my work (in a metaphysical sense).
>
> Nonetheless, as an amateur programmer, I would love to write good
> interactive fiction which could be played by a large number of folks
> (read z machine compatible).
>
> I wonder if there is an easier way to do this, and how many folks with
> real literary talent, but no programming skill might take advantage of
> such an easier way.
>
> IMHO, of course...
>
> Bill MacKenty
> Keene, New Hampshire
>
I agree with you wholeheartedly, Bill! I think Inform had its day.
Nowadays, however, I think we should take advantage of newer technologies,
such as a GUI IDE (integrated development environment for those not in the
know) where one can map out rooms visually, then zoom in and embellish with
textual details. And we should use more simpler object-oriented languages
like VB, as one option. The fact that VB can make objects easily makes it
an almost ideal platform for IF. VB is also very unlike the old BASIC--no
line numbers and gotos all over the place. And it's much easier to read in
my opinion than C and Inform's language.
Right now, I'm working on a "world" file for my games in a certain format,
then my program processes this like a stage script. Instead of spaghetti
program logic, I have properties in an *.INI file. Plus, when certain
commands and triggers are detected, I have certain effects on the main
character carried out from the *.INI file. In this sense, my program can be
generic (like an engine) and I can feed it different world file scripts.
All I need to do after that is make a GUI IDE where one can map out rooms
visually, then zoom in and give it properties, then click Compile and it
makes a world file. Another fun thing I could do is build an application
that reads a short novel and when it detects what it thinks is a scene
change, it prompts the user if a room should be created and where shall it
lie. In this sense one could *ALMOST* turn novels into world files with
some touching up required after that.
Mike McKee
Raleigh, NC, USA
HarryH
In article <01bd346b$fa7a3560$074c9ac0@station>, sup...@remedy.com says...
>I think Inform had its day.
>Nowadays, however, I think we should take advantage of newer technologies,
>such as a GUI IDE (integrated development environment for those not in the
>know) where one can map out rooms visually, then zoom in and embellish with
>textual details. And we should use more simpler object-oriented languages
>like VB, as one option. The fact that VB can make objects easily makes it
>an almost ideal platform for IF. VB is also very unlike the old BASIC--no
>line numbers and gotos all over the place. And it's much easier to read in
>my opinion than C and Inform's language.
>Another fun thing I could do is build an application
>that reads a short novel and when it detects what it thinks is a scene
>change, it prompts the user if a room should be created and where shall it
>lie. In this sense one could *ALMOST* turn novels into world files with
>some touching up required after that.
Bah! Real men don't eat Quiche!
VB has windows and interrupts all over the place. So instead of this linear
program progression, you ended up tracking multiple interrupt possibilities.
Maybe you find it easy, but I find it very, very hard.
I'll end the note with a saying (I forget who said it):
An instrument that experts can use is a tool.
An instrument that anybody can use is a toy.
AGT is a good platform, right? I mean it's simple and has picture and music
capabilities, unlike Inform.
Jeff Hatch
Angus McLaren wrote:
> As much as potential IF authors would love an easier way to create an IF
> adventure, it just can't happen at the moment. TADS is fairly easy to learn,
> would say that it tends to be more readable and easier to understand when
> programming it, although I myself prefer TADS because of my C++ experience.
> The easiest, but not the best or most versatile, IF language is AGT.
My system (to be released later this year) will be an easier way to
create an IF adventure. Here's a sample portion of a possible screen in
my editor:
Dir [Main]
Obj Kitchen Room
Cls Room
Fnc Describe void
Fnc Commands void
Var NW MoveTarget 0
Var N MoveTarget LivingRoom
[snip]
Var O MoveTarget OutsideHouse
Obj Counter Platform
Obj Table Platform
Obj Knife Weapon
It's similar to a database. For instance, if a newbie wanted to make
the command "NW" lead to a bedroom from the kitchen, she'd move the
cursor to the row that says "NW" and type "Bedroom." The screen shot
may be intimidating, but creating basic objects will be certainly much
easier than in TADS or Inform.
This still isn't very visual, though. My primary target audience is
TADS users, not non-progammers, and I don't think the simple tool that
Bill and others desire will be created soon. Only non-programmers want
it, and only programmers can create it! Even my database-style editing
was intended mainly to make some conveniences possible for programmers,
notably the ability to simultaneously edit and play a work of IF without
stopping to recompile.
-Rúmil
Paul Francis Gilbert
"Mike Smith" <sup...@remedy.com> writes:
>I agree with you wholeheartedly, Bill! I think Inform had its day.
>Nowadays, however, I think we should take advantage of newer technologies,
Don't confuse the fact that Inform first compiled to a virtual machine
designed over 20 years ago with the idea that it is therefore outdated
technology. Cars have been around for much longer, and I haven't seen
anyone calling cars outdated technology. And before anyone says something
like "Yes but cars have improved", I'd point out that with the recent
V6Lib/Blorb/Glk/Inform-V6, we're seeing a constant improvement in the
system.
>such as a GUI IDE (integrated development environment for those not in the
>know) where one can map out rooms visually, then zoom in and embellish with
>textual details. And we should use more simpler object-oriented languages
You're confusing, as many do, the concept of RAD (Rapid Application
Development for those not in the know ;-)) with the actual language. For
example, there's that Inform IDE program which simplifies objects in
Inform (apparently... I haven't been able to run it, since it requires a
DLL called "MSVCRT.DLL" which isn't included in the package). I'm also
working on a graphical IDE for the IF languages which should be done soon.
Both of these act as frontends for Inform. This is a similar concept to
the front end of Delphi (VB on steriods) and VB. They will and do provide a
visual environment for the design of code.
>like VB, as one option. The fact that VB can make objects easily makes it
>an almost ideal platform for IF. VB is also very unlike the old BASIC--no
You've got to be kidding, right? I'd like to point out that it wasn't
until VB 5 that Microsoft even implemented something that remotely
resembles objects. And even now it's, lets be honest, a fairly pathetic
implementation. It doesn't support full inheritance, which, when you get
right down to it, a successfull platform for the design of IF would require.
>line numbers and gotos all over the place. And it's much easier to read in
>my opinion than C and Inform's language.
Perhaps, but just remember that it's IYHO. Personally, I find Dephi's
syntax much more cleaner than VB or Inform, come to that, but I still think
the languages like TADS and Inform are better IF languages until such time
as someone designs a full IF library for one of these other standard
languages.
>Right now, I'm working on a "world" file for my games in a certain format,
>then my program processes this like a stage script. Instead of spaghetti
>program logic, I have properties in an *.INI file. Plus, when certain
>commands and triggers are detected, I have certain effects on the main
>character carried out from the *.INI file. In this sense, my program can be
>generic (like an engine) and I can feed it different world file scripts.
An interesting concept, but if you're designing it in VB, I think that you'll
find your core system won't be up to the scratch of either TADS' or
Inform's. Just looking at their library code shows how much they include.
Standalone games don't normally suddenly appear with this level of
functionality.
But, as you say, if you're designing yours as a scripting engine, if you
put enough work into it, it may be fairly good. Or at least not another
AGT (with apologies to those who still like AGT).. ie. being simple
to write for, but not powerfull enough for all possibilities. Your
short article on parsing, however, shows this gaming engine of yours
may have some possibilities, so I encourage you to keep working on it.
>All I need to do after that is make a GUI IDE where one can map out rooms
>visually, then zoom in and give it properties, then click Compile and it
>makes a world file. Another fun thing I could do is build an application
I should have my Generic Visual IDE to beta by the end of the month: it's
a visual IDE "shell" for 95/NT which provides all the basics of a good
IDE: speedbar control, menuitems, editor windows with full syntax
highlighting, etc. all in a COM object, so you can design plug in
"language" modules in whatever language you like to take advantage of the
functionality without having to design it all.
>that reads a short novel and when it detects what it thinks is a scene
>change, it prompts the user if a room should be created and where shall it
>lie. In this sense one could *ALMOST* turn novels into world files with
>some touching up required after that.
Interesting concept, although I can't really visualise it myself.
>Mike McKee
>Raleigh, NC, USA
--
Paul Gilbert | p...@yallara.cs.rmit.edu.au (The DreamMaster)
Bach App Sci, Bach Eng | The opinions expressed are my own, all my own, and
Year 4, RMIT Melbourne | as such will contain no references to small furry
Australia | creatures from Alpha Centauri.
Joe Mason
In article <34DE8D...@hatch.net>, Jeff Hatch <je...@hatch.net> wrote:
>
>My system (to be released later this year) will be an easier way to
>create an IF adventure. Here's a sample portion of a possible screen in
>my editor:
>
>Dir [Main]
> Obj Kitchen Room
> Cls Room
> Fnc Describe void
> Fnc Commands void
> Var NW MoveTarget 0
> Var N MoveTarget LivingRoom
>[snip]
> Var O MoveTarget OutsideHouse
> Obj Counter Platform
> Obj Table Platform
> Obj Knife Weapon
May I take this opportunity to point out two flaws I see in this sample. I
don't know how easy these would be to fix, but:
Three-letter category names. Ick. What's wrong with:
Dir [Main]
Object Kitchen
Class Room
Function Describe
Function Commands
...
Even "Obj", "Class" and "Func" would be easier to read. I think keeping your
abbrevs. to 3 letters in the interest of conformity is a mistake.
Also, the "VAR NW" - I just realized I may have misinterpreted this. On the
first glance I interpreted it to mean that "NW", "N", etc. were standard
variables for directions, and so shall it ever be. Will it be possible to
define new directions? I just completely restocked the compass of my
game-in-progress: for the games I plan to write, I'm going to need this
capability.
Speaking of which, I notice what seems to be class inheritance here: a Knife
is-a Weapon. Will there be multiple inheritance? I've gotten pretty used to
that in Inform, which is odd because my exposure to OO came in Turbo Pascal,
which has no such beast (and I miss it terribly when I have to go back).
Joe
Jeff Hatch
You're probably right, but I'll have to make sure there's enough extra
room on the screen for this. Actually, I'm considering replacing the
three-letter abbreviations with icons anyway. (Yes, this is possible
even in DOS text mode.) But maybe icons would be a little too
confusing--I could use a folder icon for the "Directories," but I have
no idea how to draw icons for Classes, Objects, Functions, and
Variables.
This will be quite easy to fix.
> Also, the "VAR NW" - I just realized I may have misinterpreted this. On the
> first glance I interpreted it to mean that "NW", "N", etc. were standard
> variables for directions, and so shall it ever be. Will it be possible to
> define new directions?
Yes, certainly. The definition of the Room class is part of the
library, not part of my system.
> Speaking of which, I notice what seems to be class inheritance here: a Knife
> is a Weapon. Will there be multiple inheritance? I've gotten pretty used to
> that in Inform, which is odd because my exposure to OO came in Turbo Pascal,
> which has no such beast (and I miss it terribly when I have to go back).
Yes, I've implemented multiple inheritance. In fact, I've created a
special kind of multiple inheritance, which is not allowed in C++ or
PERL (I don't know about Inform or TADS). I allow classes to be
declared as "linkable" classes. Then if classes B and C both derive
from linkable class A, and class D derives from both B and C, objects of
class D will inherit only one copy of class A's data. (In C++ and PERL,
an object of class D would have to store two separate copies of A's data
for technical reasons. It took quite a lot of trouble for me to
implement this ability, especially since I wanted to be able to redefine
a class as linkable while running a game without any recompilation and
without game data being damaged.)
-Rúmil
Jeff Hatch
John Francis wrote:
>
> In article <34DF99...@hatch.net>, Jeff Hatch <je...@hatch.net> wrote:
> >
> >Yes, I've implemented multiple inheritance. In fact, I've created a
> >special kind of multiple inheritance, which is not allowed in C++ or
> >PERL (I don't know about Inform or TADS). I allow classes to be
> >declared as "linkable" classes. Then if classes B and C both derive
> >from linkable class A, and class D derives from both B and C, objects of
> >class D will inherit only one copy of class A's data. (In C++ and PERL,
> >an object of class D would have to store two separate copies of A's data
> >for technical reasons. It took quite a lot of trouble for me to
> >implement this ability, especially since I wanted to be able to redefine
> >a class as linkable while running a game without any recompilation and
> >without game data being damaged.)
>
> system storing multiple copies of class A's data is seriously broken.
MSVC 1.52 stores an object of class D in the sequence ABACD. (The
letters represent class names.) Because B and C don't derive from any
class other than A, an object of class B stores its data in the sequence
AB, and an object of class C stores its data in the sequence AC. If
MSVC tried to store a class-D object in the sequence ABCD, then
functions that operate on class C would malfunction since they expect to
find class A's data just before class C's.
After thinking about this for hours, the best solution I found is to
have objects of classes B and C contain pointers at the beginning of
their data segments indicating where to find class A's data. This isn't
very efficient, which is why I made sure that most classes are not
"linkable." But I know C++ doesn't have any equivalent of "linkable"
classes--if this is possible, it's possible for every class. Are you
quite sure there's an implementation of C++ that allows this?
-Rúmil
John Francis
In article <34DF99...@hatch.net>, Jeff Hatch <je...@hatch.net> wrote:
>
>Yes, I've implemented multiple inheritance. In fact, I've created a
>special kind of multiple inheritance, which is not allowed in C++ or
>PERL (I don't know about Inform or TADS). I allow classes to be
>declared as "linkable" classes. Then if classes B and C both derive
>from linkable class A, and class D derives from both B and C, objects of
>class D will inherit only one copy of class A's data. (In C++ and PERL,
>an object of class D would have to store two separate copies of A's data
>for technical reasons. It took quite a lot of trouble for me to
>implement this ability, especially since I wanted to be able to redefine
>a class as linkable while running a game without any recompilation and
>without game data being damaged.)
This *is* allowd by C++. In fact, it is required. Any C++ runtime
system storing multiple copies of class A's data is seriously broken.
--
John Francis jfra...@sgi.com Silicon Graphics, Inc.
(650)933-8295 2011 N. Shoreline Blvd. MS 43U-991
(650)933-4692 (Fax) Mountain View, CA 94043-1389
Unsolicited electronic mail will be subject to a $100 handling fee.
Joe Mason
>library, not part of my system.
<snip>
>Yes, I've implemented multiple inheritance. In fact, I've created a
Beauty. I'm looking forward to seeing it!
Joe
Gevan
On Mon, 09 Feb 1998 18:37:05 -0800, Jeff Hatch <je...@hatch.net> wrote:
>John Francis wrote:
>>
>> In article <34DF99...@hatch.net>, Jeff Hatch <je...@hatch.net> wrote:
>> This *is* [allowed] by C++. In fact, it is required. Any C++ runtime
>> system storing multiple copies of class A's data is seriously broken.
>
>letters represent class names.) Because B and C don't derive from any
>class other than A, an object of class B stores its data in the sequence
>AB, and an object of class C stores its data in the sequence AC. If
>MSVC tried to store a class-D object in the sequence ABCD, then
>functions that operate on class C would malfunction since they expect to
>find class A's data just before class C's.
>
>classes--if this is possible, it's possible for every class. Are you
>quite sure there's an implementation of C++ that allows this?
I'd be the first to admit an *extremely* fuzzy knowledge of C++, so
I reached over to the bookshelf for a copy of Stroustrup to check
my response. Yes, this is *allowed* by C++, and I think you'll find
that virtual base classes do roughly the same job as your "linkable"
classes. It's not the default, however, which is to behave as you
state. As far as I know. Not very far.
John Francis
In article <slrn6dvmh7...@rowanarc.es.co.nz>,
Gevan <sha...@es.co.nz.goaway> wrote:
>On Mon, 09 Feb 1998 18:37:05 -0800, Jeff Hatch <je...@hatch.net> wrote:
>>John Francis wrote:
>>>
>>> In article <34DF99...@hatch.net>, Jeff Hatch <je...@hatch.net> wrote:
>[...]
>>> This *is* [allowed] by C++. In fact, it is required. Any C++ runtime
>>> system storing multiple copies of class A's data is seriously broken.
>>
>>classes--if this is possible, it's possible for every class. Are you
>>quite sure there's an implementation of C++ that allows this?
>
>I'd be the first to admit an *extremely* fuzzy knowledge of C++, so
>I reached over to the bookshelf for a copy of Stroustrup to check
>my response. Yes, this is *allowed* by C++, and I think you'll find
>that virtual base classes do roughly the same job as your "linkable"
>classes. It's not the default, however, which is to behave as you
>state. As far as I know. Not very far.
Congratulations - give that man the prize. He managed to identify
the correct construct, even though I managed to leave out the word
"always" from my original posting, rather destroying the meaning.
What I *thought* I wrote was "... runtime system ALWAYS storing ..."
But when I read the reply I noticed a word had mysteriously slipped
away into the black hole of the editor.
David Alex Lamb
Jeff Hatch wrote:
> After thinking about this for hours, the best solution I found is to
> have objects of classes B and C contain pointers at the beginning of
This is, in effect, the classic way to implement even single inheritance
with old-fashioned (non-OO) relational databases: treat classes A, B, C,
D as separate types (tables); each D has a foreign key ("pointer")
corresponding to the primary key of a particular B and one for a
particular C row, and B and C each similarly reference a particular A
row (which their integrity checks ought to verify is the *same* A). It
actually corresponds pretty closely to one of the mathematical models of
inheritance.
I once worked on a system with multiple inheritance (back in the early
1980s) that allocated D's data in the order ABCD or ACBD, and either B
or C got a "gap" corresponding to the space for the other sibling's
data. We were guaranteed to see the whole inheritance tree before
deciding on data layouts, which is a luxury most object-oriented systems
don't have (and don't usually want).
This kind of headache is why some OO languages don't allow multiple
inheritance, or insist that all but one base class be abstract classes
(which cause no problems if they don't declare any data members), or
forbid the "diamond" style of inheritance that causes the most problems.
So, your solution really isn't so bad -- or, at least, some other
people's solutions are equally bad.
Lars Duning
Sorry for jumping onto the wagon that late, but this is one of the topics
I have hard time not to comment on.
[stepping onto soap box]
Mike Smith wrote:
>
> Bill Mackenty <bmac...@pisgah.keene.edu> wrote in article
> <6bfun4$6un$1...@news.monad.net>...
> > I know this subject has been discussed in the past, but after playing
> > some incredible games from the annual competition, I am reminded
> >
> > a) how much I would like to write my own IF game
> > b) how difficult that seems to be using popular languages (TADS & Inform).
> I agree with you wholeheartedly, Bill! I think Inform had its day.
> Nowadays, however, I think we should take advantage of newer technologies,
> such as a GUI IDE (integrated development environment for those not in the
> know) where one can map out rooms visually, then zoom in and embellish with
> textual details.
I am sceptical about this, people tend to confuse 'visual' with 'easy'[1].
I think that a graphical tool can make the creation of the stage much
easier, but it can never replace the programming necessary to put some
action onto this stage. It is easy to chunk out dozens of rooms - but
without anything to do in these rooms, one might as well not create them
at all. If you don't want to be limited to what the tool offers you, you
have to start programming yourself[2].
Likewise, people forget that the difficult part about programming is the
programming, not the languages. Granted, beginners' languages should be
clean (which is not the same as simple), but no ever-so-nifty tool
can ever relieve you from the necessity of using your brain.
Learning programming means learning to think about solving problems in
abstract terms. The languages are simply a notation for these abstract
terms.
Like any other creative art, programming takes practice. But again like
any other creative art, programming does not require you to be
a professional.
Finally, I'd like to point out that all this also applies to writing IF
in general: tools can only help you in the final step, the implementation.
The difficult part is having a good idea and putting it into a story.
[leaving soapbox again]
[1] I am no fan of IDEs anyway. Usually they force me to adapt to their style
of working, not vice versa, and they all do things differently.
Particularly annoying is that I _do_ own an IDE I like and use: the user
interface of the OS I'm running. YMMV, of course.
[2] Anybody remembering the Shoot-Em-Up Construction kits for the old
home computers?
--
Lars Duening; la...@cableinet.co.uk (Home)
Julian Arnold
In article <34E1A976...@mdisystems.com>, Lars Duning
<URL:mailto:ldu...@mdisystems.com> wrote:
> [2] Anybody remembering the Shoot-Em-Up Construction kits for the old
> home computers?
A friend had one on his C64. I made do with the Graphic Adventure
Creator (GAC) from, um, Incentive Software on my BBC Micro. My firstest
authoring system ('cos the nasty people who sold The Quill never got
back to me. Sniff!).
Jools
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me from
ever completing anything." -- Herman Melville, "Moby Dick"
Andy Wright
Julian Arnold wrote:
>
> In article <34E1A976...@mdisystems.com>, Lars Duning
> <URL:mailto:ldu...@mdisystems.com> wrote:
> > [2] Anybody remembering the Shoot-Em-Up Construction kits for the old
> > home computers?
>
> A friend had one on his C64. I made do with the Graphic Adventure
> Creator (GAC) from, um, Incentive Software on my BBC Micro. My firstest
> authoring system ('cos the nasty people who sold The Quill never got
> back to me. Sniff!).
>
Oh yes, I had GAC on the Amstrad. Fun wasn't it? So powerful and flexible...
For the time, I suppose it wasn't too bad, but it did lead to the sudden
appearance of copious quantities of adventure games with _really_ crap
graphics. Not being able to do nice piccies with it was a major problem,
since it wasn't much cop for text-only games. I did start writing a game
with GAC, a long time ago, but gave up when I realised it was a load of
cobblers. (Yes I do mean the game.)
Andy
Patrick Kellum
In article <34E1A976...@mdisystems.com>, Lars Duning was talking about:
>[2] Anybody remembering the Shoot-Em-Up Construction kits for the old
> home computers?
Just dug out my copy for the C64 a few weeks ago :-) SmurfHunt has to be
the greatest game of all time IMO :-)