IF making software; power and flexibility - is it always required?
Dot Net Developer
mechanics within the IF builders that they use to write their IF games?
If not, could some of these games perhaps have been built in easier to
use IF builders that use more simple "point-and-click" style
interaction, without any programming at all?
Regards, dnw.
u...@mail.ru
As far as I know, the most non-programmer-friendly IF-development
system is ADRIFT, which lets you writing games without any programming
at all. The site of ADRIFT: http://www.adrift.org.uk.
Although I personally don't use it, many people who do work with ADRIFT
are members of r*if, as well.
Valentine
ChicagoDave
This is an excellent question and the answer from my perspective is
complicated.
On the one hand, you have strong IF programmers that are always trying
to push the edge of how AI aspects of their games work. In their case,
the more powerful the system, the better.
Then you have people who want to tell a story. They'll use whatever
tool is available to do the job and still create something highly
regarded.
The answer lies in what sort of resulting game you envision. If you
want anything like an Infocom game, I suspect even the least powerful
tools could do the job. If you want something that has powerful NPC's
that walk around, interact with the PC and other NPC's, interact with
objects...then you're going to probably want the most powerful system
you can get your hands on.
Now which system is the most powerful is a long-standing debate. You
can find history on that by searching on Google Groups for "best
platform" or "TADS vs. Inform".
David C.
Jeff Nyman
news:1166973977....@42g2000cwt.googlegroups.com...
> Do the IF writers within this community utilise complex programmatic
> mechanics within the IF builders that they use to write their IF games?
Some do. It depends on the system you are using and how you are using that
system. It also depends on what you mean by "complex programmatic
mechanics." I presume you mean constructing the game via a strict
programming language. (I say that because some systems can utilize "complex
programmatic mechanics" and yet still hide much of that from the author.)
> If not, could some of these games perhaps have been built in easier to
> use IF builders that use more simple "point-and-click" style
> interaction, without any programming at all?
The question here is strictly asking if creating such games would be
"easier" so I'm just speaking to that.
My opinion: I think some games can be *easier* to build at an initial level
if you have some interface that lets you build the game via a graphical
interface in some fashion. That said, just because such games are easier to
build does not mean you could build the same kind of game as you would have
had you used a system based on direct programming.
I liken it to GUI application development with the numerous graphical IDE's
out there. For example, you can use NetBeans (for Java) or Visual Studio
(for .NET) to graphically build the components of your application. However,
to actually get the application to do much beyond the initial stages of
showing up, you have to program the logic that exists behind the
application. It is *easier* to build up your initial application, but you
still need to drop to the programming level at some point.
In my experience, graphical systems that hide the programming entirely,
rarely let you create games that are as powerful as those that you do
program in. (The same situation applies in creating graphical-based
interactive fiction games, such as systems with AGI, SCI or AGS. They all
rely on scripting to do anything relatively complex.) Look at systems like
the Source SDK (for Half Life 2) or the DarkBasic system (for FPS Creator).
With both systems you can build first-person shooters with "point-and-click"
like methods, but to do complex things that make the game more dynamic, you
have to drop to the respective coding elements that are hidden behind the
visual builders. In all these caess, it is *easier* to create the basic game
structure (rooms, levels, maps, character placement) but to get everything
interacting intelligently and in an entertaining way means dropping to the
programming level.
In a different but related example, you can look at various "story
generators" out there or "novel authoring systems" where you can "plug in"
the various attributes of the novel you want to write. These systems then
churn away at what you entered and attempt to provide structure to your
novels and indicate where complications should go or where plot points
should be encountered. That can help you a bit: but to actually get your
novel done, you have to write it. (Think of "writing it" as being equivalent
to "programming it" for purposes of the analogy I'm trying to draw here.) So
it can be *easier* to outline your novel or give structure to your thoughts,
but at some point you have to drop down the writing level.
So the point here is that in most creative systems (software development,
graphical games, novel writing) you have to, at some point, get your "hands
dirty" with some actual code/scripting/writing even if the initial creation
can be made easier by a visual tool of some sort.
Of course, there is room to consider various types of interfaces. After all,
look at Inform 7. You could argue that what it's trying to do is change the
interface by which people program. Granted, it's not allowing you to
visually ("point-and-click") create your game, but it is presenting the
nature of the programming in a very different way. Many have argued that it
is *easier* to create a game in Inform 7 than in other systems. Systems like
ADRIFT or Quest are examples of other types of interfaces, which are closer
to the visual creation style I would guess. Certainly you can create viable
games in those two systems and it's been argued that this initial creation
is easier for some.
What type of game results from all this, of course, depends on the power of
the visual system and how much it does for you or how much this visual
system lets you do what a system that you could fully modify at the
programming/script level would do. My own personal experience has shown me
that visual tools can do a lot but they usually can't do enough once people
realize what they want to do.
- Jeff
Dot Net Developer
ChicagoDave wrote:
> > Dot Net Developer wrote:
> > Do the IF writers within this community utilise complex programmatic
> > mechanics within the IF builders that they use to write their IF games?
> > If not, could some of these games perhaps have been built in easier to
> > use IF builders that use more simple "point-and-click" style
> > interaction, without any programming at all?
>
> This is an excellent question and the answer from my perspective is
> complicated.
>
> On the one hand, you have strong IF programmers that are always trying
> to push the edge of how AI aspects of their games work. In their case,
> the more powerful the system, the better.
>
> Then you have people who want to tell a story. They'll use whatever
> tool is available to do the job and still create something highly
> regarded.
>
> The answer lies in what sort of resulting game you envision.
> If you want anything like an Infocom game, I suspect even the least powerful tools could do the job.
..And some of them were great.
> If you want something that has powerful NPC's that walk around, interact with the PC and other NPC's, interact with objects...then you're going to probably want the most powerful system you can get your hands on.
Is powerful NPC construction the primary IF building element which
separates programming based IF making software with IF software that
requires very little or no programming? Could easier-to-use IF
builders somehow "catch up" with TADS3 / Inform7 by providing (better)
NPC mechanics, or are there many other areas of technical complexity
that current IF authors require that do not exist inside easier-to-use
IF builders?
-dnw.
ChicagoDave
> Is powerful NPC construction the primary IF building element which
> separates programming based IF making software with IF software that
> requires very little or no programming?
No. There are many types of logical AI that can be implemented that
push the interactivity into more of a simulation. In a more complex
platform, you will be able to develop rules for interactivity and then
let things happen. Some of these things seem simple on the surface,
like how liquids are handled, fire, air, coins, anthing that can have a
quantity-based logic. These things are highly complicated, but when
implemented properly and well, they provide a much richer simulation.
There are other things. Some NPC conversation systems are very complex,
but as I've noted, this is something that with a lot of really detailed
If-then-else code, can be implemented in most platforms. But one of the
problems with IF is that it's hard to design, write, and program
everything. It takes time. A lot of time. So if you were going to try
to implement something, and had a tool that could help you achieve your
goals more efficiently, wouldn't you choose that tool?
Another part to IF is experience. The more you write IF and especially
at the lower level, the better you understand the inner-workings. I
might say this allows you to better write IF, but I'm not so sure that
this is true. A good knowledge of how logic works, some good
puzzle-development skills, and a decent understanding of how IF can be
patterned might just be enough. Of course you still need a tool to
implement your idea, so you're back to square one.
An example of something that has nothing to do with which platform you
select.
Any reasonable IF game has a lot of smoke and mirrors. You start with a
set of locations and one, two, or a handful of obvious things to
investigate. In order to control the progress of the entire thing, some
puzzles will be resolved while new puzzles appear. There's a sort of
controlled expansion of interactivity and then collapse. It's very
common to see a game open up to several simultaneous puzzles and then
collapse to a single puzzle. A good game might do this several times
before the end game.
It's understanding things like this that I think are far more important
than which platform you choose. Understand IF first. Then think about
how to implement it. Of course I say that having implemented many of my
ideas in code and so I can't prove that it's possible to learn IF
without coding. I just _think_ it's possible.
David C.
Jim Aikin
> separates programming based IF making software with IF software that
> requires very little or no programming?
No. It's all of the features together. Almost any game that's complex enough
to be interesting will require customized behavior in some and perhaps many
areas. Authors need to define new verbs, create objects that do visionary
things, test the values of arbitrary variables in order to adjust room
descriptions, et cetera.
Ultimately, creating a work of IF involves modeling a world. The development
tools you use provide a default world model, and if you're satisfied with
that default (whatever it is), then you're off to the races. But almost any
good game will require that the world model be extended or altered here and
there. That's why, in my opinion, a point-and-click IF authoring system is
doomed from the start. It makes the wrong assumption about what's needed,
namely that the world model it provides will suffice to meet the author's
needs.
To give just one practical example of world modeling, Inform 6 models a very
primitive form of containment. Containers behave rather like wicker baskets.
If you happen to need a container with a narrow aperture, or a glass
container whose contents can be viewed even when it's closed, you'll have to
extend the model yourself.
If you want to study world modeling, I don't think you could do better than
to learn TADS 3 from top to bottom. (Set aside about a year for this.) Its
world model is, in many ways, very sophisticated. And yet, within a week of
starting work on a project, I've had to write code for a new type of
containment that the T3 library doesn't support.
My experience may not be typical, though. I'm a known perfectionist and
wacko (a bad combination).
--JA
Khelwood
> And yet, within a week of
> starting work on a project, I've had to write code for a new type of
> containment that the T3 library doesn't support.
What new type of containment is that then?
Jim Aikin
Background: I'm exploring the possibility of porting Last Resort to T3. I
need to significantly expand and improve the game, and I want to learn T3,
so here we are. If you've played it, you'll know what I'm talking about, but
if you haven't, this discussion might be a bit of a spoiler. I'll keep it
general and vague.
The concept is that there are things you might not be able to touch
directly, but that you might be able to pick up and manipulate using an
intermediate object. One example would be a rare and precious postage stamp,
which can only be handled with tweezers. If you try to take or touch the
stamp, the stamp objects: "The oil on your fingertips would smudge the
printing!"
The first step is to create a new action, TakeWith, and to create some
tweezers as a container. But that's not enough. Now you can pick up the
stamp with the tweezers, but there's no way to let go of the stamp, because
by default 'drop stamp' tries to route the stamp from the tweezers through
your hands. (Try it and you'll see -- it doesn't work.) So you have to
interfere with the preCond for the Drop action.
Next, the tweezers need to know if they're holding something (I've done this
in a very klugey way, because I didn't know that I could test if
(contents[1])), so that they'll refuse to let you pick up anything else. You
also need to make sure you're handling PutIn and PutOn correctly, and so on.
It isn't terribly complex, but it does require that the model for
containment be extended in very specific ways.
--JA
Neil Cerutti
> To give just one practical example of world modeling, Inform 6
> models a very primitive form of containment. Containers behave
> rather like wicker baskets. If you happen to need a container
> with a narrow aperture, or a glass container whose contents can
> be viewed even when it's closed, you'll have to extend the
> model yourself.
For the sake of correctness, Inform 6 does support glass
containers out of the box, as it were.
But I agree with the general thrust of your comments, otherwise.
--
Neil Cerutti
Jim Aikin
> use IF builders that use more simple "point-and-click" style
> interaction, without any programming at all?
You know ... what would be truly sweet would be a point-and-click front-end
code generator. I would love to see such a program (for Windows, of course).
After specifying your preferred language -- Inform 6, Inform 7, TADS 2, TADS
3, Hugo, whatever -- you would drag rooms onto the map from a parts box and
connect the rooms using the mouse by dragging connections, for instance from
the south node of one room to the north node of another. As each room is
added, you would be prompted to fill in the room name and description. The
parts box would also include doors and fixed in-room items such as chairs,
beds, cabinets, and scenery.
The point of this would NOT be to develop a complete game by pointing and
clicking. The software would simply generate source code in your chosen
language, which you would then be expected to modify as needed.
I can readily envisage more of the specification for such a program, but I'm
certainly not enough of a code warrior to create it myself. What do others
think? Would it be useful?
--Jim Aikin
Jeff Nyman
news:n%Cjh.40346$wP1....@newssvr14.news.prodigy.net...
> I can readily envisage more of the specification for such a program, but
> I'm certainly not enough of a code warrior to create it myself. What do
> others think? Would it be useful?
I think it could be very useful. The Plugh! tool (for TADS; but no longer
developed; http://www.plugh.info/) did something along these lines. There's
also IF Mapper (written in Ruby, still active, I think;
http://ifmapper.rubyforge.org/). So the ideas, at least, have been out
there. I think Visual Inform was originally going to go along a route like
this. (It's no longer being developed, but you can get the source for the
VB6 code at
http://www.ifarchive.org/indexes/if-archiveXprogrammingXeditors.html.)
I agree, however, that an application like this could certainly have its
benefits, such as perhaps taking out some of the tedious elements (such as
the basic creation of lots of rooms). The precedent is there, at the very
least.
- Jeff
Dot Net Developer
Jim Aikin wrote:
> > If not, could some of these games perhaps have been built in easier to
> > use IF builders that use more simple "point-and-click" style
> > interaction, without any programming at all?
>
> You know ... what would be truly sweet would be a point-and-click front-end
> code generator. I would love to see such a program (for Windows, of course).
>
> After specifying your preferred language -- Inform 6, Inform 7, TADS 2, TADS
> 3, Hugo, whatever --
> you would drag rooms onto the map from a parts box ...
I really like the idea of building your adventure world by "drawing" a
visual representation of it.
> and connect the rooms using the mouse by dragging connections, for instance from
> the south node of one room to the north node of another. As each room is
> added, you would be prompted to fill in the room name and description. The
> parts box would also include doors and fixed in-room items such as chairs,
> beds, cabinets, and scenery.
>
> The point of this would NOT be to develop a complete game by pointing and
> clicking.
> The software would simply generate source code ...
Cool! Simple adventures perhaps wouldn't need much extra coding, and
more complex adventures would require the user to add anything extra
they needed to the generated code, giving great flexibility and kind of
like the "best of both worlds".
Now if only I could be bothered to write this, I might have something
working in, oh I don't know, 2020?
-dnw.
Jeff Nyman
>
> Now if only I could be bothered to write this, I might have something
> working in, oh I don't know, 2020?
>
Like I said in another post, some examples are already out there so this
might not be as hard as you think. If your only goal is to have this tool
generate some basic code for rooms (and some description logic), IF Mapper
already does that. You can at least get some ideas from that.
The harder part, for many people, is coming up with the visual map drawing
component, because you have to allow connecting lines between the map
elements. The tool Zinc (which is not a visual design tool) has logic that
shows how to make maps. (It's written in Java:
http://zinc-if.sourceforge.net/) That could probably give you some starting
points.
The actual conversion of the map into code wouldn't be that much of a
programming challenge -- again, if the only goal were to take the basic
visual map that was drawn and then convert that into the various languages
out there. That would just require knowing the code constructs of TADS 2,
TADS 3, Inform 7 or whatever else you wanted to convert to and then finding
a way to store your map programmatically so that you could cycle through it
and build the rooms and the connections. (Again, IF Mapper does some of this
already, so you could build off of that logic.)
- Jeff
Dot Net Developer
Jeff Nyman wrote:
> "Dot Net Developer" <dotnetd...@hotmail.co.uk> wrote in message
> news:1167045512....@42g2000cwt.googlegroups.com...
> >
> > Now if only I could be bothered to write this, I might have something
> > working in, oh I don't know, 2020?
> >
>
> Like I said in another post, some examples are already out there so this
> might not be as hard as you think. If your only goal is to have this tool
> generate some basic code for rooms (and some description logic), IF Mapper
> already does that. You can at least get some ideas from that.
>
> The harder part, for many people, is coming up with the visual map drawing
How about a map similar to the one in the old DOS PC game called
_Descent_ by Parallax software published by Interplay. In this map,
you could zoom in and out, and twist it about and such which would
allow the user and developer to manipulate "multi-level" maps such as
all the floors in a house for example, from the basement right up to
the attic. You could also do some "twisty little passages"! <g>
-dnw.
d...@pobox.com
On Dec 24, 10:16 pm, "Jim Aikin" <raif...@musicwords.net> wrote:
> > If not, could some of these games perhaps have been built in easier to
> > use IF builders that use more simple "point-and-click" style
> > interaction, without any programming at all?
> You know ... what would be truly sweet would be a point-and-click front-end
> code generator. I would love to see such a program (for Windows, of course).
>
> After specifying your preferred language -- Inform 6, Inform 7, TADS 2, TADS
> 3, Hugo, whatever -- you would drag rooms onto the map from a parts box and
> connect the rooms using the mouse by dragging connections, for instance from
> the south node of one room to the north node of another. As each room is
> added, you would be prompted to fill in the room name and description. The
> parts box would also include doors and fixed in-room items such as chairs,
> beds, cabinets, and scenery.
So it would be cool if the Map page of Inform 7 (er, the World tab of
the Index Panel) was an input system as well as an output system.
Wouldn't it? You could drag things from the Kind page onto the Map
page, and cool stuff like that.
Can't imagine that I would use such a thing, but then it's always a
struggle to get me to leave my cave and stop using vi.
drj
Jeff Nyman
news:1167350718....@k21g2000cwa.googlegroups.com...
>
> So it would be cool if the Map page of Inform 7 (er, the World tab of
> the Index Panel) was an input system as well as an output system.
> Wouldn't it? You could drag things from the Kind page onto the Map
> page, and cool stuff like that.
I could easily envision something where the map abilities of Inform 7 could
be used as the starting point instead of the Source tab. Perhaps there would
be a "Graph Tab" or something, where they can map out their model world in
some fashion. Then the basic elements of the room layout would be created
via the source.
In my opinion, however, if the IDE is going to be such center focus (as it
clearly is with I7) then it would probably have been better to write it as a
plug-in architecture. (Then again, I'm biased. Just about every tool
solution I build is plug-in based to some extent.) The reason I feel that
might be good for the I7 IDE is that someone could write, say, a "GUI Map
Module" that could hook into the code base. Further, someone could write a
GUI Object Creator module or a Full Relations Graph module or something
along those lines. For those who want to do I6 development in the IDE (on
Windows anyway), a plug-in could be created. Maybe a spell checker plug-in
could be created. Etc. Etc. If the IDE started to develop into a true
authoring tool, plug-ins geared to that aspect could be written.
In that case, however, it would probably be better (although certainly not
necessary) to use a cross-platform language for the IDE. In Java I think of
something like jEdit which has used this kind of architecture very
successfully. In Ruby I think of FreeRIDE which, again, has been very
successful. The code editor SourceEdit (written in VB6) actually started to
get good when it changed to a plug-in architecture (of sorts).
- Jeff
d...@pobox.com
On 29 Dec, 00:46, "Jeff Nyman" <jeffnyman_nospam@nopam_gmail.com>
wrote:
> <d...@pobox.com> wrote in messagenews:1167350718....@k21g2000cwa.googlegroups.com...
Surely the IDEs (both of them!) are written in a cross-platform
language? Do you mean it should be written using a cross-platform GUI
API? Yeah, sure. Apparently there are ways to write Objective-C GUIs
that compile both on OS X using NextStep, er, Cocoa, and on other
platforms using GNUstep. Not that I've ever tried it.
drj
vaporware
[...]
> If the IDE started to develop into a true
> authoring tool, plug-ins geared to that aspect could be written.
>
> In that case, however, it would probably be better (although certainly not
> necessary) to use a cross-platform language for the IDE. In Java I think of
> something like jEdit which has used this kind of architecture very
> successfully. In Ruby I think of FreeRIDE which, again, has been very
> successful. The code editor SourceEdit (written in VB6) actually started to
> get good when it changed to a plug-in architecture (of sorts).
Or perhaps the plugins could be written in I6/I7, compiled to Glulx,
and run with the Glulx interpreter built into the IDE (with some extra
operations available only to plugins).
vw
Jeff Nyman
news:1167357801.6...@a3g2000cwd.googlegroups.com...
>
> Surely the IDEs (both of them!) are written in a cross-platform
> language? Do you mean it should be written using a cross-platform GUI
> API?
Correct, indeed. Of course, in this case the IDE is predicated on the GUI.
There is no separation of this with Inform 7 (or with too many IDE's out
there, for that matter). However, not just the GUI itself: the plug-in
architecture. C++ (and certainly C) isn't known for being the most robust
language for this kind of thing because it (often) uses system dependencies.
(For example, on Windows it tends to place emphasis on DLL files, at least
for a generic framework, or elements of COM that are not cross-platform.)
The GUI by itself is, in my experience, less of a problem in that you could
try things with the wxWidgets library or maybe even GTK+.
(I know the CLI and CLR concepts are making some interesting changes to how
all this might work, but time will tell if .NET is truly cross-platform
enough to support the "varied language" approach.)
In my experience, writing truly cross platform compatible C/C++ applications
with plug-in architectures can be limited in terms of what you can do
because you eventually get into areas where you will definitely break its
portability. (Of course, it could easily be argued that this is just because
I wasn't doing things correctly.)
Then again, maybe cross-platform development in this case really wouldn't be
all that warranted. I'm not sure. I think it would have been more important
to consider the future design goals of I7 as a whole and then what role the
putative IDE would play in that. Perhaps that's been done but, to my
knowledge, it's nothing any of us have heard about and my personal opinion
is that the route taken was potentially limiting.
- Jeff