A small IF platform survey

[samwyse]

Archived from groups: rec.games.int-fiction (More info?)

On or about 4/8/2005 11:37 AM, Jimmy Maher did proclaim:

>> This is the real hard part. Whats going to happen is that as soon as
>> you go in and edit your generated code the visual editor will become
>> much less usefull, and in all probability dangerous because its going
>> to mess up what you've done when it can't understand it.
>
> Yes, I'm aware of that. Compromises would probably have to be made
> here. Some middle ground would have to be found between absolutely free
> editablity of your code and the need to keep the GUI aware of what's
> going on in the code. I'm not sure where that line would have to fall.
> Since I was dreaming, though, I thought I might as well go all out...

There are some tools (non-GUI) that do some of this. For example, I've
written a Perl script that takes a "transcript" and generates room and
object descriptions. The idea is that you write out how you want the
game to play, and code is generated to do that. Other people have
written scripts that take dialog trees and similarly generate code. The
difficulty with all of these is, as you've said, merging things together.

I've sketched plans for an XML representation of Inform code. The
benefit is that you could have several files with partial definitions of
an object that could be combined into one. For example, the
transcript-to-Inform script could provide Bob's "description" property,
a dialog tree script would provide some "life" and "orders" code, and
you could hand-edit the rest. The merge process would result in a
single "Bob" object.

Like so many others, I haven't had the time to do much with this idea, alas.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

On 2005-04-08 08:25:35 -0700, adam@fsf.net (Adam Thornton) said:

> I wonder to what degree something like this could be put on top of an
> existing framework, though. I think that, for instance, Apple's Xcode
> can be extended to support new languages; would it make sense to create
> an Inform development environment for Xcode?

Well, that's essentially what inform-mode under Emacs amounts to, isn't it?

joelh

 

[pj]

Archived from groups: rec.games.int-fiction (More info?)

Andrew Plotkin wrote:
> Here, Jimmy Maher <maherNO@spamgrandecom.net> wrote:
> >
> > Well, it's a question of total development time, not ratios between

> > coding and doing something else. Let me give a simplistic example:
> >
> > Say you write a small game that takes 100 hours to create with just
a
> > text editor. However, you only spend 50 of these hours actually
> > wrestling with important coding problems.
>
> Or, let's say you spend 90 of those hours wrestling with code (and
> prose), and only 10 on repetitive busy work. Then the savings of
> automation are very small.
>
> See, it *is* a question of that coding time ratio. You're assuming
> it's 50%. I think that's a large overestimate.

Well, to support Jimmy a bit, I think you are overestimating the coding
efficiency of many of the folks on RAIF. Not everyone who develops IF
games is a professional developer by trade or training.

Jimmy's 50-50 estimate may be more correct for one basic reason: other
than the simplest construct used to define a room or object, almost any
item in the game has the potential to require significant coding time
if you're not constantly working in Inform. Unless you have lots of
Inform experience and are actively coding a game, it is very easy to
forget which properties are most effective in doing simple things like
scenery objects. Is "has scenery" enough to keep the object from a
"take all?" When do you use "has static" and why? What about
"concealed," what's the difference beteween that and "scenery?"

Every time I go away from the language for even just a few months, I
find that I have to reacquaint myself with these subtle differences.
If I don't, I can spend several hours doing something which you and
other "top coders" may find easy, like a talk button on an intercom.
How do you make it switchable? What's the best way to get the NPC I
want to talk to in scope, or is that even necessary? Has anybody
contributed a button class to the library? Can I modify phones.h to do
what I want? Stupid of me, perhaps, but I'm not a real Inform or TADS
pro, nor am I ever likely to be. On the other hand, if I could just
drag a button object onto the workspace of my visual IDE and read its
comments in the code display, then I would probably save myself the 2
hours or so necessary to relearn these tricks. You probably don't need
to relearn this stuff, so you think of it as "simple coding." For many
of us, however, nothing in Inform is truly simple; it's just degrees of
complexity and the same opportunity for "stuckness" that we find in
playing the games.

I think you are also ignoring the possibility that if coding were
easier because of a drag 'n drop interface, more amateur coders who are
interested in writing but are scared of coding might join the fray.
Right now, let's say there are 50 Inform games a year developed by
people in the community, at an average development time of 100 hrs per
game, or 5000 labor hours per year. Per your ratios, there's only 500
hours a year that could be minimized by a visual development
environment. If it took 10,000 hours to develop that system and 250
hours a year of maintenance, obviously the net community payback would
be non-existent.

But, on the other hand, if the ratio of complex to less complex coding
is actually more like Jimmy's 50-50, and the development time (I
suspect) is really more like 200 hours per game, the payback scenarios
are quite different. You'd be attacking a nut of 5,000 annual hours of
development time for the existing Inform community. And if 50
additional games were developed because more people were attracted to
Inform by the visual IDE, then the potential payback quickly becomes
substantial.

Another point that would help even you "top coders" out there: a
visual IDE could serve as the native host for a class library that
would enable even more complex classes and object behaviors to be
deployed by Inform developers. Case in point: I recently spent a
significant amount of time analyzing how you implemented relative
directions in "Hunter, In Darkness." That required me to go to the
archive, pull down your source, wade through your files, etc., to
decide exactly how you were using the "UnknownVerb" entry point and the
various verbs, verbsubs, and ancillary routines to serve as a model for
the effects I wanted.

If instead a generic solution was sitting in the class library of a
visual IDE, I would simply have dragged it onto my workspace, read the
usage comments, then decided whether or not to use it, modify it, or
try to find an alternative solution. Even "top coders" can get a lot
of benny out of borrowing complex, pre-coded but relatively generic
objects like this rather than building everything from scratch. The
savings are, I expect quite a bit higher than most people really
believe. How many questions on r.a.i.f. end up being the same
solutions that people have figured out time and time again? How do I
do a hint menu? What's the best way to code a rifle or other
projectile shooting weapon? How do I do automatic opening/closing
doors? How do I stop implicit takes at the wrong time? etc., etc.,
etc. A visual IDE with a rich class/methods library could be a
tremendous boon to IF developers and potentially open the door to a
broader community of folks who are intimidated by the current "roll
your own" flavor of IF programming.

No visual IDE will solve all complex coding problems, but I think a
good one would be accepted far more readily than folks on this thread
tend to believe. The real problem is whether anyone has the time, the
chops, and the chutzpah to attack the problem. I don't have the
skills, but would be happy to help specify the requirements and/or
beta-test.

PJ

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

In article <1112721150.152498.229610@o13g2000cwo.googlegroups.com>,
PJ <pete_jasper@hotmail.com> wrote:
>ChicagoDave wrote:
>> I'm going to step in here and ask that we all knock it off.
>
>A good idea. Let's summarize a few salient points, first, however:
>
A few more comments...

>-- Arguing about the security of C, C++ or any of the current set of IF
>compilers is kind of ridiculous. Does anyone honestly think the Hong
>Kong/Taiwan/Shanghai bug-writing/bug-fixing shops are trying to infect
>the world using IF as a vector? In short, "No."
>
No, but well-intentioned mistakes can be just as bad, and there are
malicious people out there. Nor do I want to start changing my habits,
which have worked well so far.

I had been unaware that .NET had useful sandbox capability; thanks for
telling me that, people. There's lots of software out there that I
don't know much about, for various reasons, and IMNSHO too much
propensity for people fond of a software package to assume its
details are well known.

>-- Any discussion of this sort invokes the rabid anti-Microsoft bias of
>many folks on this news group. I sympathize. But Microsoft and .NET
>aren't going away. May as well accept it, particularly as C#.NET is
>pretty cool anyway.
>
Could be; I'm not at all convinced that Microsoft "gets" security yet.
XP SP2 is definitely a step in the right direction there.

>-- Icedragon wants to write games in .NET. Applause. But he will get
>no kudos from the community unless he writes a full .NET IF development
>platform and distributes it broadly enough that somebody else starts
>using it. That means it also has to be good -- probably better, in
>fact -- than the existing IF languages. Possible, but not necessarily
>probable.
>
Not quite - if he writes an excellent game, that would be good. In my
experience, excellent games do not happen nowadays without specialized
IF development systems (even if the author writes his or her own
development system), so this is something of a moot point. In any
case, a development system is at least an indication that other
games might be coming, so it is an incentive to download and install
software to run it.

--
David H. Thornley | If you want my opinion, ask.
david@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

Here, PJ <pete_jasper@hotmail.com> wrote:
> Andrew Plotkin wrote:
> > Here, Jimmy Maher <maherNO@spamgrandecom.net> wrote:
> > >
> > > Well, it's a question of total development time, not ratios between
>
> > > coding and doing something else. Let me give a simplistic example:
> > >
> > > Say you write a small game that takes 100 hours to create with just
> a
> > > text editor. However, you only spend 50 of these hours actually
> > > wrestling with important coding problems.
> >
> > Or, let's say you spend 90 of those hours wrestling with code (and
> > prose), and only 10 on repetitive busy work. Then the savings of
> > automation are very small.
> >
> > See, it *is* a question of that coding time ratio. You're assuming
> > it's 50%. I think that's a large overestimate.
>
> Well, to support Jimmy a bit, I think you are overestimating the coding
> efficiency of many of the folks on RAIF. Not everyone who develops IF
> games is a professional developer by trade or training.

Wouldn't that mean I am uncharacteristically *low* in my code-writing
time, and the average Inform author spends *more* than 90% of his time
wrestling with code?

You go on to talk about a development system that handles some of the
coding for you. Presumably the coding that is, in some sense,
repetitive busywork.

But you then have to go back to the original proposal, which didn't
say that:

Jimmy Maher wrote, on Apr 8, 9:37 am:

> ...typing out object after very similar object, worrying about
> syntax, indenting, hunting down typos, niggly little things like
> making sure each map connection has a corresponding connection at
> its destination, etc.

(I'm sure I spend less time than most authors on *that* stuff, but that
doesn't mean that most people spend a *lot* of time on it. As compared
to designing significant code and writing text.)

In any case, you are allowing the goalposts to drift. "Everyone talks
about the perfect IF development environment, but nobody does anything
about it" -- because when you're just talking about it, you can gloss
over internal contradictions. Places where your simplifications either
(a) aren't powerful enough, or (b) don't simplify the thing that
people really want simplified, or (c) turn out to be just as unsimple
as what they're replacing. Stick to a specific proposal, and at least
we have something to discuss.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

PJ wrote:

(snip a lot of good stuff that I agree with)


> Another point that would help even you "top coders" out there: a
> visual IDE could serve as the native host for a class library that
> would enable even more complex classes and object behaviors to be
> deployed by Inform developers. Case in point: I recently spent a
> significant amount of time analyzing how you implemented relative
> directions in "Hunter, In Darkness." That required me to go to the
> archive, pull down your source, wade through your files, etc., to
> decide exactly how you were using the "UnknownVerb" entry point and the
> various verbs, verbsubs, and ancillary routines to serve as a model for
> the effects I wanted.
>
> If instead a generic solution was sitting in the class library of a
> visual IDE, I would simply have dragged it onto my workspace, read the
> usage comments, then decided whether or not to use it, modify it, or
> try to find an alternative solution. Even "top coders" can get a lot
> of benny out of borrowing complex, pre-coded but relatively generic
> objects like this rather than building everything from scratch. The
> savings are, I expect quite a bit higher than most people really
> believe. How many questions on r.a.i.f. end up being the same
> solutions that people have figured out time and time again? How do I
> do a hint menu? What's the best way to code a rifle or other
> projectile shooting weapon? How do I do automatic opening/closing
> doors? How do I stop implicit takes at the wrong time? etc., etc.,
> etc. A visual IDE with a rich class/methods library could be a
> tremendous boon to IF developers and potentially open the door to a
> broader community of folks who are intimidated by the current "roll
> your own" flavor of IF programming.

Great minds think a alike. 🙂 This functionality was indeed on my mind
when I wrote out my initial description of the ID, but that description
was already getting so long and complex that I decided not to go into it
at that time. However, now that you've brought it up I will say that it
should be possible to add objects to your visual object palette anytime.
I picture the IDE coming with a stable of basic objects, but these
being only a starting point really. After creation, objects could be
packaged up, exported, then uploaded to the archive. Then other users
of the IDE who are interested in objects of that type can just download
the appropriate package and install the objects it contains into their
IDE with just a click or two. The objects are then there on their
palette, ready for use at any time.

> No visual IDE will solve all complex coding problems, but I think a
> good one would be accepted far more readily than folks on this thread
> tend to believe. The real problem is whether anyone has the time, the
> chops, and the chutzpah to attack the problem. I don't have the
> skills, but would be happy to help specify the requirements and/or
> beta-test.

There's the rub, eh? The one argument members of the newsgroup have
raised that I *do* entirely agree with is that this project would
require one hell of a lot of work to pull off, and may not be worth it
in the long run. Still... I'm vaguely thinking about it. We'll see.

Jimmy

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

Here, Jimmy Maher <maherNO@spamgrandecom.net> wrote:
> However, now that you've brought it up I will say that it
> should be possible to add objects to your visual object palette anytime.
> I picture the IDE coming with a stable of basic objects, but these
> being only a starting point really. After creation, objects could be
> packaged up, exported, then uploaded to the archive. Then other users
> of the IDE who are interested in objects of that type can just download
> the appropriate package and install the objects it contains into their
> IDE with just a click or two. The objects are then there on their
> palette, ready for use at any time.

My only comment here is that before you design the IDE, you have to
design the IF development language which is scalable enough to permit
it. Inform isn't it.

I have some ideas, but they're highly speculative. I haven't even come
up with a complete model, much less proved it workable, much less
written it.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.

 

[pj]

Archived from groups: rec.games.int-fiction (More info?)

David Thornley wrote:
> I think this is almost completely orthogonal to the IDE issue, but is
a
> matter of creating and disseminating appropriate libraries.
> If these libraries are available, organized, and easily browsable,
> they can be easily used from any development tool. If they aren't,
> well, the IDE can't access what doesn't exist, or isn't readily
> accessible.

The key to any good visual IDE is the richness of the object model it
is allowing the developer to access, so I don't think this is
orthogonal. The fundamental purpose of a visual IDE is to make
reusable object code "available, organizable, and easily browsable" as
well as simplifying its insertion into / use by the program under
development.

A visual IDE that was nothing but a shell to start with, with no
predefined classes & objects, would not be very exciting to me. I
would still be doing all the work to populate the tool, which cuts the
benefits of object reuse that a visual IDE brings to the table.
Without this capability, you have just another fancy text editor.

So I think the issue of a robust class/methods library for Inform could
use a few different adjectives or descriptors other than orthogonal in
relation to a visual IDE. Of primary importance, probably. Difficult,
undoubtedly. Not yet realized in Inform, obviously. Better suited to
TADS3 or Hugo, perhaps. But given Inform's popular following, I still
think a fully realized visual IDE for Inform could be a rich
enhancement to the IF community.

PJ

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

In article <1113395164.641707.138040@g14g2000cwa.googlegroups.com>,
PJ <pete_jasper@hotmail.com> wrote:
>David Thornley wrote:
>> I think this is almost completely orthogonal to the IDE issue, but is
>a
>> matter of creating and disseminating appropriate libraries.
>> If these libraries are available, organized, and easily browsable,
>> they can be easily used from any development tool. If they aren't,
>> well, the IDE can't access what doesn't exist, or isn't readily
>> accessible.
>
>The key to any good visual IDE is the richness of the object model it
>is allowing the developer to access, so I don't think this is
>orthogonal. The fundamental purpose of a visual IDE is to make
>reusable object code "available, organizable, and easily browsable" as
>well as simplifying its insertion into / use by the program under
>development.
>
Okay, but it appears to me to be a separate task, and one that would
have considerable value without an IDE. It isn't an easy one, either,
and from my limited knowledge of Inform would be easier in another IF
language - TADS 3, for example.



--
David H. Thornley | If you want my opinion, ask.
david@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

In article <1113419544.562065.131880@o13g2000cwo.googlegroups.com>,
ChicagoDave <david.cornelson@gmail.com> wrote:
>And on a more vocal note, I think Inform is great for what it is, but
>if you want to move IF into a "professional" atmosphere, you would need
>a syntax, parser, and world model that were component-based and
>extensible. To do this, you would almost certainly have to develop the
>platform on a full blown VM (.NET CLR or Java VM) as opposed to an IF
>specific VM.
>
The z-machine is certainly not powerful enough, but the T3 virtual
machine (for TADS 3) looks like it should definitely be powerful
enough. What do you think would be required that an IF-specific
VM would lack?


--
David H. Thornley | If you want my opinion, ask.
david@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

I may be mistaken in this area, but the one thing missing from an IF
specific VM is the ability to add the unknown. The other thing that's
sort of tightly-coupled within TADS3 (and all other current platforms)
is that the PC is hardcoded as a single user.

So my contention is that a generalized VM with an IF syntax might be
more extensible.

David C.

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

In article <1113501183.065991.239430@l41g2000cwc.googlegroups.com>,
ChicagoDave <david.cornelson@gmail.com> wrote:
>I may be mistaken in this area, but the one thing missing from an IF
>specific VM is the ability to add the unknown. The other thing that's
>sort of tightly-coupled within TADS3 (and all other current platforms)
>is that the PC is hardcoded as a single user.
>
>So my contention is that a generalized VM with an IF syntax might be
>more extensible.

Hmm, I think the single-user PC is almost entirely a library issue,
unless you're talking about wanting something like networking support.
In that case, yeah, you'd have to add support for it to the
interpreter, but this is something you'd have to do in any case,
regardless of the VM, if it wasn't implemented already. It's not
really that, say, the JVM is more extensible, it's that it's more
*extended* -- it already has support for networking, various kinds of
graphics, and most stuff you'd ever want for an IF system.

>David C.
--
Dan Shiovitz :: dbs@cs.wisc.edu :: http://www.drizzle.com/~dans
"He settled down to dictate a letter to the Consolidated Nailfile and
Eyebrow Tweezer Corporation of Scranton, Pa., which would make them
realize that life is stern and earnest and Nailfile and Eyebrow Tweezer
Corporations are not put in this world for pleasure alone." -PGW

 

[Guest]

Archived from groups: rec.games.int-fiction (More info?)

"ChicagoDave" <david.cornelson@gmail.com> wrote in message:
>I may be mistaken in this area, but the one thing missing from an IF
> specific VM is the ability to add the unknown.

I have no idea what you're getting at here.

> The other thing that's sort of tightly-coupled within TADS3 (and
> all other current platforms) is that the PC is hardcoded as a single
> user.

First off, I don't understand at all what this has to do with this has to do
with building an IDE. (That is what you were talking about, isn't it, or
did I miss a deflection in the thread?) Second, the singleness of the user
isn't actually a VM issue anyway; it's just that the libraries for IF that
tend to be of interest here are libraries for single-player IF.

--Mike
mjr underscore at hotmail dot com

 

[pj]

Archived from groups: rec.games.int-fiction (More info?)

Mike Roberts wrote:
> "ChicagoDave" <david.cornelson@gmail.com> wrote in message:
> >I may be mistaken in this area, but the one thing missing from an IF
> > specific VM is the ability to add the unknown.
>
> I have no idea what you're getting at here.
>
> > The other thing that's sort of tightly-coupled within TADS3 (and
> > all other current platforms) is that the PC is hardcoded as a
single
> > user.
>
> First off, I don't understand at all what this has to do with this
has to do
> with building an IDE. (That is what you were talking about, isn't
it, or
> did I miss a deflection in the thread?) Second, the singleness of
the user
> isn't actually a VM issue anyway; it's just that the libraries for IF
that
> tend to be of interest here are libraries for single-player IF.
>
> --Mike
> mjr underscore at hotmail dot com

Well, way back, the OP was talking about developing an IF game in .NET.
We seem to have successfuly forked the thread over to discussing
development of a visual IDE for IF.

I agree, however, that the robustness of standard IF virtual machines
has little to do with development of a visual IDE for IF.

A visual IDE is a developer's tool that uses a set of simple graphical
paradigms to manage the elements of a program and autogenerate a lot of
code through the quick & easy deployment of rich class libraries and
methods. Conceptually, it's little more than a text editor with a lot
of fancy graphical features on top of it to input, view & edit code,
and with a database underneath to track & manage the objects that are
being coded (the game under development), or already have been coded
(the libraries). Those fancy features, however, can make a tremendous
difference in the productivity of the development process, particularly
when the visual IDE is populated with a rich class & methods library.

It may be true that certain languages suit the visual paradigm better
than others. Obviously, the more object-oriented the language, the
easier it is to manage the code generation process (no "floating"
routines, global variables, etc., would be nice) It may also be true
that a specific IF language might have some limitations like file
handles that would require some hard thinking to circumvent in the code
generation-to-compilation process. There's no doubt that developing a
good, "professional" visual IDE would be a lot of work. But IMHO,
there's no technical reason why good IDE's couldn't be developed for
Inform, TADS and/or Hugo.

PJ