Game creator for dummies?
there is no spoon
like to design my own games. I came across a piece of software a while back
which took care of all the programming side. All you had to do was tell it
what rooms/areas were where, where you got to from each, what characters
where where, whether they were enemies, etc etc.
I'd be grateful if anyone could point me in the right direction where I can
get this piece of software from.
Cryptonomic
usually produce very simple games that are really not all that challenging.
I speak as someone who learned Inform from the ground-up (although,
admittedly, I did have prior experience in other programming languages) and
I think the best use of these types of "gaming systems" is when you are
forced to do some of the programming to handle the extra situations or just
to make the game a little more dynamic and "life-like", if you will.
This same sort of thing applies even in the graphical adventure milieu, such
as with Adventure Game Studio or SCI Studio. Yes, you can create rooms and
characters but to do the stuff that makes a game fun, you have to learn the
scripting language behind those tools. Likewise, with interactive fiction. I
would recommend trying to just learn Inform (or TADS or Hugo or whatever).
Inform has a great Designer's Manual (although not for the first-timer) and
also there is a well written "Inform for Beginner's" guide that is quite
easy to understand and is fantastically informative. I have been going
through the TADS manual and, likewise, it is quite well-written and allows
you to see how to create some simple scenarios in the language. This also
applies to Hugo from what I have seen but I have not played around with that
as much yet.
You might, however, want to check out this pretty extensive list:
http://www.ambrosine.com/resource.html
There are a lot of different "engines" there to look at, some touted for
non-programmers, some for programmers, and some for those in-between.
- Cryptonomic
Stephen L Breslin
simple sense. A good game cannot be written with a game creator.
Unless you learn how to code, you'll never write a good game.
But oh, no, look what crypt said!
>Inform has a great Designer's Manual (although not for the first-timer) and
>also there is a well written "Inform for Beginner's" guide that is quite [...]
>informative.
I would point you towards the Tads Manual 2.5.5, available from the
if-archive: if-archive/programming/tads2/manuals. There's a lot of
other useful stuff in that directory.
Tads and Inform are both good, whether you're a tadcheese or a
tadpole.
I learned how to do this stuff by looking at source code for games;
the simpler and better commented, the better to begin with. Tads comes
with a simple game which is like to a *good* game creator, in that it
gives you the basic layout for making rooms and objects, and you can
change it to plug your own text and such. That's a nice way to get
started.
SteveG
I've heard of several text game creation systems which could match
that description. There's probably several that I've never heard of.
So I couldn't be sure which one you came across before but I'll take a
few guesses.
Were you perhaps thinking of a system with a graphical user interface?
If so, perhaps you are thinking of Adrift, Quest or SUDS?
http://www.adrift.org.uk/
http://www.axeuk.com/quest/index.htm
http://www.sudslore.com/
-- SteveG
remove _X_ from my address to send me email
J.Pitchpine
take a look at its designer manual. Here's a direct link to the IF
Archive:
ftp://ftp.ifarchive.org/if-archive/programming/adrift/
I have never built anything with Adrift so I couldn't say if it allows
to create games as complex as those you can make with Inform, TADS,
Hugo or Alan, but it seems very easy to use.
I am learning Hugo and I can say that it is very straightforward and
easy as language. Its main plague is the manual, which assumes you
already know programming basis. I learned so much from peeking the
source code of the sample game, and this alone tells how easy the
language is.
I have sympathy for things like Quest, Adrift, etc. but I hardly
believe they can reach the ductility and power allowed by a real IF
Authoring System. They're certainly a good starting point, so I'd
certainly encourage you to try them out.
stev_...@actrix.gen.nz (SteveG) wrote in message news:<3d557ae6...@news.actrix.co.nz>...
Ally M.
news:ec22c08e.02081...@posting.google.com:
(snip)
> I have sympathy for things like Quest, Adrift, etc. but I hardly
> believe they can reach the ductility and power allowed by a real IF
> Authoring System. They're certainly a good starting point, so I'd
> certainly encourage you to try them out.
To spoon: AFAIK, Quest can be programmed as well as clicked around in. It
might thus be more suitable than ADRIFT in case you plan to "upgrade" one
day.
The Quest games I saw so far (two or so) were almost unplayable, but that
might not have been Quest's fault.
Drawback in either case, Windows only.
regards
~Ally
David A. Cornelson
news:aj3lr1$ngi$1...@knossos.btinternet.com...
> Any help would be appreciated. I'm not much of a programmer, but I'd
still
> like to design my own games. I came across a piece of software a while
back
> which took care of all the programming side. All you had to do was tell
it
> what rooms/areas were where, where you got to from each, what characters
> where where, whether they were enemies, etc etc.
I'm one of the most vocal proponents of better IF tools. We've come a long
way in the five years I've been involved, but mostly on the help/support
side. There is as yet no difinitive editing tool that has an elegant
paradigm for building interactive fiction. There are library files and
add-ins for some of the more popular text editors and this is currently the
route I use and recommend.
I personally use UltraEdit with the Inform syntax highlighting library
installed. UltraEdit gives you the ability to have many files open at once
with tabs at the top to be able to quickly move from file to file. For the
large game I've been working on for two years now, this is necessary since
each scene is rather large text-wise and scrolling/searching became painful.
Of course a more elegant editor would organize your code in such a way that
the user need not know about files, but it's been tried (see Visual Inform
written in Visual Basic 6 in the archive) and ultimately was a failure.
There are a few that have some combination of features/text editing that are
nice, but still lack some element of _writing_ that building IF requires.
A purely graphical interface will probably never work. Sure, the graphical
interface could help you visualize some aspects of your model world, but so
can a piece of paper and a pencil. A graphical interface could potentially
help you connect locations, locate items quickly in a large world model,
maybe even handle some coding, but in the end you still have to _write_ the
text that the game-player will read.
And therein lies the nearly impossible paradigm of having a one size fits
all game editor. I think there _are_ some improvments to be made. An editor
that contains features like code completion, intellisense, context sensitive
help, impeccable syntax highlighting, instant error-checking, inline
debugging, and other similar features would go a long way to making IF more
easily learned and programmed.
Other "way out" features, like combinatorial explosion management routines,
are often dreamed of, but no one really knows how to implement them.
I have some ideas about all of this that I keep notes on, because even
though I wrote Visual Inform and it was a failure, it taught me many things
about what _I_ want in an IF game editor. Someday I'll get back to working
on an editor of some sort. Probably not for a few years though.
For now, take the advice of the other posters. Pick a language and just
learn it and write a game using a text editor. There really is no better way
to do it.
Jarb
MaDbRiT
>To spoon: AFAIK, Quest can be programmed as well as clicked around in. It
>might thus be more suitable than ADRIFT in case you plan to "upgrade" one
>day.
This is quite correct - Quest allows the author to use either a GUI point n
click approach or code entirely by hand in its own scripting language. In fact
one can switch back and forth using the two approaches on one piece which is a
unique feature I think. It is also good in that one can code in the GUI and
then look at the actual code generated which might be educational for a newbie.
:-)
>
>The Quest games I saw so far (two or so) were almost unplayable, but that
>might not have been Quest's fault.
>
I don't think it is Quest's fault at all.
A total newbie trying to 'knock out' a first game over a couple of evenings in
TADS for instance would most likely be doomed to failure as he/she would
(probably) never get it to compile and so couldn't release it. The same person
using Quest would just as likely have a game that ran (and so could be
released) even if it was *completely* awful.
Of course this means a lot of stuff that should never see the light of day
because the author hasn't put enough work or thought into it gets released.
This tends to reflect badly on the system itself, which is a bit unfair. I
think Quest in particular has a lot of potential still to be exploited. Version
3.1 has a fairly impressive specification and is a lot more powerful than the
limited V1 & 2 versions of a few years ago.
>Drawback in either case, Windows only.
>
This is the only really significant problem for me - but if the Windows
limitation really is too much to take and one finds TADS, Inform & Hugo too
daunting, ALAN is an easy to use option that is well worth investigating.
AB
Woodfish
been using it for years, and you can do literally anything with it,
seriously. Granted, nearly all the games written using it are rubbish,
but the only reason you don't get that with Inform or TADS is because
it takes a year to learn the thing, so you have to be really serious
about creating adventures.
Cryptonomic
news:a4d2f115.02081...@posting.google.com...
Actually, I just started learning Inform about three weeks ago and while I
am by no means an expert, I consider myself fairly good now at constructing
some decent puzzles. I know you were probably just speaking generally but I
think that people often shy away from programming or scripting because they
have the usually mistaken assumption that it wil take them "a year to learn
the thing". A little bit of dedicated effort, with some help from others who
have been there before, can make learning a language quite easy,
particularly when it is a focused language like Inform, TADS, etc (as
opposed to a general language like C, C++, Java, etc).
Mind you, I am not necessarily saying this in relation to ADRIFT. I have not
used ADRIFT at all yet and I do plan to take a look at it. As someone else
here has said, tools that help create Interactive Fiction are certainly
welcome. For me they are particularly welcome as long as they do not
constrain the story making ability. As you say, many of the games written in
it are rubbish. I cannot attest to this one way or the other but perhaps
this is because that kind of system fosters that type of game creation.
(Again: please understand I have not used the system so I cannot say this
for certain and I know the same thing could occur with Inform, TADS, Hugo,
etc.) But that is why I tend to shy away from some tools and not others.
When they do tend to lead to more than their share of rubbish, often there
are reasons for that in terms of the type of mindset the tool fosters in
terms of creating games or stories.
You also seem to equate learning a more complex system with being "serious
about creating adventures". If that is the case, perhaps that also explains
the "rubbish" that you are talking about with ADRIFT. If your statement is
accurate, perhaps the "rubbish" comes from those who are "less serious" and
thus choose a more non-programmatic tool for creating stories/games. Again,
I am just throwing thoughts out there as I do not mean to disparage any one
tool, particularly when I have not used it yet.
- Cryptonomic
Banzai88
In article <rWy59.63705$UU1.11468@sccrnsc03>, "Cryptonomic"
<cryptonom...@hotmail.com> writes:
>"Woodfish" <yimc...@hotmail.com> wrote in message
>news:a4d2f115.02081...@posting.google.com...
>> I'd like to see someone name one feature that ADRIFT doen't have. I've
>> been using it for years, and you can do literally anything with it,
>> seriously. Granted, nearly all the games written using it are rubbish,
>> but the only reason you don't get that with Inform or TADS is because
>> it takes a year to learn the thing, so you have to be really serious
>> about creating adventures.
>
>Actually, I just started learning Inform about three weeks ago and while I
>am by no means an expert, I consider myself fairly good now at constructing
>some decent puzzles.
From a dedicated lurker who goes thru the random "I wanna play/make
an IF game" phase every so often...
Seems like a lot of the problem *I've* seen is less the system used
than it is the simple fact that most folks can't write. A great story
idea or even just a great puzzle idea means nothing if the person
creating the game can't create an engaging "universe" to put it in,
but I've seldom if ever seen this brought up. It's usually the system
that gets the blame.
Maybe it's the old "90% of everything is rubbish" rule rearing its
head. Anyone who has delved into the world of fanfic can identify
with this, I'm sure.
Chris
(will go back to lurking now - you may return to your regularly
scheduled newsgroup)
remove 77 to reply
Highlander - Buckaroo Banzai - Buffy - Kolchak - Jon Sable - Ceirdwyn
The Sims - Doc Savage
all can be found at:
http://hometown.aol.com/lostgiant/index.htm
][
@#####|}======================>
][
Andrew Plotkin
> I'd like to see someone name one feature that ADRIFT doen't have. I've
> been using it for years, and you can do literally anything with it,
> seriously.
I just took a glance at the ADRIFT manual. It lists a lot of features.
All those features are categorical lists of things you can't do with
ADRIFT, because they're all hard-wired into the system. You can't do
them any differently.
That's the basic problem. I just typed a bunch of examples of things
I've done in Inform, but it's pointless to go through them, really.
--Z
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.
Jeff Pack
news:a4d2f115.02081...@posting.google.com:
I'm sure someone with more programming experience could offer a list of
things impossible or infeasible to accomplish in ADRIFT. But I'm still
more of a player of IF than a writer. So how about a decent parser?
As I understand it, most of the interesting actions in ADRIFT are handled
by the Tasks system. Basically, this checks to see if the user's input
matches an expression defined by the author. If it doesn't, and it
doesn't match anything in the (extremely limited) standard library, it
won't be understood.
The first example in the ADRIFT manual for tasks is "turn *wheel": this
matches "turn wheel," "turn the wheel", "turn the steering wheel," etc.,
but not "spin wheel," "rotate wheel," "turn rim," etc. You can get
around this somewhat with "advanced command construction"; the example
given is "[get/take/pick up] {the} [{green} apple from] {the} {large}
[box/crate]". This matches a lot, but still leaves out a lot of
possibilities: the IF player is accustomed to being able to "get apple"
if it's in scope without specifying "from box"; under ADRIFT this action
will either fail or give the player the apple without triggering the
task. In addition, it's pretty easy to see that a proper list of
synonyms for a task will quickly grow unwieldy; what the author is
expected to do is almost write their own parser for every command. Most
don't, turning their games into guess-the-verb.
In contrast, what a language like Inform does (correct me if I'm wrong
here) is allow you to define new verbs (e.g., "turn") and give them
synonyms ("spin," "rotate"). Same goes for nouns. Thus instead of
having to define all the synonyms anew for each task, the task can be
more simply expressed as "turn wheel"; the parser will figure out that
"spin the rim" is equivalent.
As far as I know, there's no reason why ADRIFT couldn't work this way.
But right now it doesn't, and that's a serious enough problem for me to
avoid games written in ADRIFT. (There are other problems with the
system, such as generally being unable to UNDO a fatal move, but these
are relatively minor inconveniences.)
Jeff
Plugh!
Cornelson" <da...@plover.net> came along and depressed me with ...
> I'm one of the most vocal proponents of better IF tools.
I'm right behind you. In fact, I know that I am much, much better
equipped to develop such tools than I am to develop any half way
decent i-f.
In addition to my main project (see http://www.plugh.info), I am open
for requests.
I did once suggest a central repository, where we could match requests
for tools from potential users with ne'er do wells with too much time
on their hands who could implement said requests, but nothing ever
came of it.
> We've come a long
> way in the five years I've been involved, but mostly on the help/support
> side. There is as yet no difinitive editing tool that has an elegant
> paradigm for building interactive fiction.
I'm trying, I'm trying, for Mike's sake. I'm almost at beta.
> Of course a more elegant editor would organize your code in such a way that
> the user need not know about files, but it's been tried (see Visual Inform
> written in Visual Basic 6 in the archive) and ultimately was a failure.
I liked Visual Inform. I thought it was a great idea for a project and
am sorry that you didn't take it any further.
> A purely graphical interface will probably never work. Sure, the graphical
> interface could help you visualize some aspects of your model world, but so
> can a piece of paper and a pencil. A graphical interface could potentially
> help you connect locations, locate items quickly in a large world model,
> maybe even handle some coding, but in the end you still have to _write_ the
> text that the game-player will read.
I totally agree with your conclusion. My only goal is to reduce
housekeeping overhead. I have made it so that the user has complete
control over how much/little code to write but, let's be honest, while
you can create a puzzle-less environment with a few clicks, it's
rather boring. The user_has_ to be able to write (good) i-f and tools
can only hope to take care of some of the tedium and automate a few
things, without getting in the way of the creative process.
I have, however, allowed the power user complete control over all
levels of the code, including the manipulation of the class tree and
the modification, addition and deletion of classes and properties.
> And therein lies the nearly impossible paradigm of having a one size fits
> all game editor. I think there _are_ some improvments to be made. An editor
> that contains features like code completion, intellisense, context sensitive
> help, impeccable syntax highlighting, instant error-checking, inline
> debugging, and other similar features would go a long way to making IF more
> easily learned and programmed.
Now, there's a requirement spec for me. I'll work on all of that.
> I have some ideas about all of this that I keep notes on, because even
> though I wrote Visual Inform and it was a failure, it taught me many things
> about what _I_ want in an IF game editor. Someday I'll get back to working
> on an editor of some sort. Probably not for a few years though.
Well, I hope that I'm not boring this NG by posting yet again. I do
every few months or so, when my motivation is low, and I get a little
feedback and that encourages me for a few more months. But I think
ther reason that I have been at this for several years is that I
secretly realize that when I get it finished there still won't be many
people who will want to use it.
> For now, take the advice of the other posters. Pick a language and just
> learn it and write a game using a text editor. There really is no better way
> to do it.
He's right, you know.
For what it's worth, I am working on a sort of housekeeping / code
generating tool which generates TADS code (shouldn't be too difficult
to add Inform too), where the map can be drawn with point & click and
items & NPCs placed in the rooms, with all of it fully customizable,
giving total control over the generated code.
The idea is mainly to replace all of those scraps of paper and
automate that which can be automated. I have a v1.0 feature set
defined and have it generating Cloak of Darkness (no biggy, I know)
and am currently using it to implement Ditch Day Drifter, which I will
validate by using a published walkthrough. After that, it goes out for
beta testing.
As always, I end with my pathetic plea for everyone to visit
http://www.plugh.info and have a look at the site, maybe even d/l the
program and provide me with some feedback; if you think it sucks,
please tell me why; if you want to request a feature please do so.
Sorry for taking your time, we now return you to regularly scheduled
programming...
Cryptonomic
news:20020811160544...@mb-ch.aol.com...
> Greetings,
> Seems like a lot of the problem *I've* seen is less the system used
> than it is the simple fact that most folks can't write. A great story
> idea or even just a great puzzle idea means nothing if the person
> creating the game can't create an engaging "universe" to put it in,
> but I've seldom if ever seen this brought up. It's usually the system
> that gets the blame.
That is a very good point. Perhaps it is a little of both. Like I say, I
have seen systems that can constrain your writing just by virtue of how they
make you design the model world. In other words, if they do not force you to
think it out as much, they will not force you to become better at your
writing. (Mind you, I am not just speaking of pure prose here or interesting
"universes" because, of course, much of that comes from within. If you
simply lack the ability to tell a good story, have good ideas, or formulate
good puzzles within that story, I doubt any system will really help you in
that regard.)
I work in the field of Quality Assurance and I liken it to automated testing
tools. No one tool is going to make you write good test cases necessarily
but I have found that the tools that make you script out the tests in a
language (as opposed to "visually" building them) force you to think about
*how* you should test more and that directly leads to writing better test
cases. Likewise with these Interactive Fiction systems; in working with
those that force you to basically code from the ground up, I have found that
it forces me to think a great deal more about the locations in my story and
the various things that the user can do there. Granted, I could still
produce rubbish because I may not follow what the rules are telling me or I
may not flesh out the "universe" even where I could have. That comes at a
price of a steeper learning curve and perhaps a little more difficulty
during the process of creating the "universe" but it seems the end result,
if done well (which is up to the person), makes that learning and creating
process worth it.
Anyway, all of this conversation has now made me step up my timetable to
look at ADRIFT. I am now curious to see how a system like that works in
comparison to a system like TADS or Inform.
- Cryptonomic
Cryptonomic
news:uldbdvq...@corp.supernews.com...
> I have some ideas about all of this that I keep notes on, because even
> though I wrote Visual Inform and it was a failure, it taught me many
things
> about what _I_ want in an IF game editor. Someday I'll get back to working
> on an editor of some sort. Probably not for a few years though.
I think one of the big problems with many editors that I have seen
(including one I was starting to write myself) is that they are mainly
written in Visual Basic. That seems to be the language of choice. Given the
sheer number of Linux/Unix users relative to interactive fiction, an editor
written in something like Java might be a better choice. Open source
programs like Jext and JEdit point the way to how to make the basic editor.
The problem is: it is just that - a basic editor. Which often means it is no
better than a good text editor. (By "good" text editor I mean one where I
can have easily accessible tabs to open files, syntax coloring that allows
me to add to it, and line numbers.)
This is partly why I stopped development on my own IF editor program. I
realized that, in the end, I was not really providing anything that was so
much more useful than a basic text editor. I mean I had a few little things
that could help but, overall, I felt I was more wasting my time and would be
wasting the time of others who probably already used things like TextPad,
UltraEdit, IF-IDE, etc., and were happy with those.
I think the biggest thing people can do to start formulating a good IF
system is to come up with a list of requirements for what they need (to be
at least useful) and then what they want. A good list like that can start to
direct thinking and lead to a better development effort. Right now I notice
a lot of us are writing tools but they all pretty much do the same things.
That is a lot of duplication of effort for what appears to be little gain,
given how little the tools appear to be used. I think Imaginate and Plugh
have some interesting concepts to them. I think Visual Inform also did as
well. The trick is looking at what "writing IF" means and what "constructing
world models for IF" means and then start building the application around
those operative definitions rather than just building a slightly better sort
of mouse trap.
Just some thoughts.
- Cryptonomic
Adrien Beau
> Given the sheer number of Linux/Unix users
> relative to interactive fiction, an editor written in
> something like Java might be a better choice. Open source
> programs like Jext and JEdit point the way to how to make the
> basic editor.
Or you could have a look at Eclipse (eclipse.org) and
Netbeans (netbeans.org), which are both extensible IDEs written
in Java. You get all the foundations, you "only" have to add
support for the specificities of your language. I happen to
think Eclipse is better than Netbeans.
Or you could just use Vim (my editor of choice). As some say,
"My IDE? It's called Unix."
> I think the biggest thing people can do to start formulating a
> good IF system is to come up with a list of requirements for
> what they need (to be at least useful) and then what they
> want. A good list like that can start to direct thinking and
> lead to a better development effort. Right now I notice a lot
> of us are writing tools but they all pretty much do the same
> things. That is a lot of duplication of effort for what
> appears to be little gain, given how little the tools appear
> to be used.
It seems this subject has been quite debated in the past, but
I'm blissfully ignorant of that. :)
My opinion is that there are far too many people trying to
reinvent the wheel (a good editor), when there's already an
excellent offering (Vim, Emacs, TextPad, Visual*, etc.). This
opinions is not specific to the IF newsgroups.
Here's an example: the Netbeans editor simply sucks when
compared to Vim, even though they've spent a lot of time
writing it. Why did I use Netbeans? For its great debugger, for
its visual Java interface builder, and to have an overview of
my files. I was more impressed by the Eclipse editor, but most
of what it does can be done in Vim with a good deal of
scripting.
I think tool authors should concentrate on offering scripts,
plugins, and small independent programs that can be used or
called from these editors. The more editors that can interface
with your tool, the better.
While big and integrated interfaces are very nice to the user,
I doubt the community can manage to gather the resources needed
to build them. Concentrate on smaller tools, with more
achievable goals. As for what tools are needed, I'd have to be
writing IF right now to be able to tell you. ;)
--
adrie...@yahoo.guess
Plugh!
> Cryptonomic wrote:
>
> > Given the sheer number of Linux/Unix users
> > relative to interactive fiction, an editor written in
> > something like Java might be a better choice.
there is some grain of truth to the "write once, debug everywhere"
slur.
An alternative is some of the Borland products, such as Delphi/Kylix
which allow you to write the same Pascal (soon to include C++ too)
code once & simply recopmpile for Widnows/Linux - alas, no Mac
support. This really is an *excellent* tool for creating GUIs, the
mroe complex you want them, the better it is.
> > I think the biggest thing people can do to start formulating a
> > good IF system is to come up with a list of requirements for
> > what they need (to be at least useful) and then what they
> > want. A good list like that can start to direct thinking and
> > lead to a better development effort.
Agreed 100%. I have tried to start something in that driection before,
but no-one wants to contribute. I like to hack code in my free time
and am honest enough to admit taht I am betetr at that thanm at
creating i-f, so if potential users would only define what they want,
I would be happy to work at it.
> > Right now I notice a lot
> > of us are writing tools but they all pretty much do the same
> > things. That is a lot of duplication of effort for what
> > appears to be little gain, given how little the tools appear
> > to be used.
Agreed. so why is no one (seemingly) ineterestd in a central
repository?
> I think tool authors should concentrate on offering scripts,
> plugins, and small independent programs that can be used or
> called from these editors. The more editors that can interface
> with your tool, the better.
Sounds liek a good idea.
> While big and integrated interfaces are very nice to the user,
> I doubt the community can manage to gather the resources needed
> to build them. Concentrate on smaller tools, with more
> achievable goals.
You may well be right. It was six years(!) ago that I first posted
suggesting my program I've been hacking away at it for 2 years now. I
have seen several large, ambitious projects crash & burn, so maybe
small is beautiful.
> As for what tools are needed, I'd have to be
> writing IF right now to be able to tell you. ;)
Go on, have a try anyway. You do say that many of "us" are writing
such tools...
Simon Baldwin
> Adrien Beau <adrie...@yahoo.guess> wrote in message news:<3d57ea63$0$10500$626a...@news.free.fr>...
> > Cryptonomic wrote:
> >
> > > Given the sheer number of Linux/Unix users
> > > relative to interactive fiction, an editor written in
> > > something like Java might be a better choice.
> Agreed, though it does tend to run a little slowly on some systems &
> there is some grain of truth to the "write once, debug everywhere"
> slur.
>
> An alternative is some of the Borland products, such as Delphi/Kylix
> which allow you to write the same Pascal (soon to include C++ too)
> code once & simply recopmpile for Widnows/Linux - alas, no Mac
> support. This really is an *excellent* tool for creating GUIs, the
> mroe complex you want them, the better it is.
Or how about an IF IDE in Inform? It'd be guaranteed to run on just
about all IF author's systems.
Hard-to-impossible for Z-machine, but, I suspect, possible (for some
definition of the word "possible") for Inform with Glulx. Certainly
a lot of work, but maybe not hugely more than already invested in some
of the other tools currently available. Maybe also possible in TADS,
Hugo, and others.
Simon
Timothy Groves
> > An alternative is some of the Borland products, such as Delphi/Kylix
> > which allow you to write the same Pascal (soon to include C++ too)
> > code once & simply recopmpile for Widnows/Linux - alas, no Mac
> > support. This really is an *excellent* tool for creating GUIs, the
> > mroe complex you want them, the better it is.
The FPC compiler is as broad-based as the Borland products (since it's
based on the Borland products, sorta). Of course, I don't have the
foggiest idea how to write an IDE...
> Or how about an IF IDE in Inform? It'd be guaranteed to run on just
> about all IF author's systems.
> Hard-to-impossible for Z-machine, but, I suspect, possible (for some
> definition of the word "possible") for Inform with Glulx. Certainly
> a lot of work, but maybe not hugely more than already invested in some
> of the other tools currently available. Maybe also possible in TADS,
> Hugo, and others.
1. Does Glulx support calling child processes? Because otherwise,
you'd just be writing an editor.
2. Come to think of it, is there any way to "chain" a program in either
straight Z or under Glulx? Even if no variables can be passed, and the
result is merely, 'existing code dumped, new code loaded and run', well,
cache files are a wonderful thing.
> Simon
--
ICQ#66022322
"It's a terrifying thing, isn't it? To live in fear.
That's what it's like to be a slave."
--Rutger Hauer, Bladerunner
Neil Cerutti
<983626bd.02081...@posting.google.com>, Simon Baldwin
wrote:
> Or how about an IF IDE in Inform? It'd be guaranteed to run on
> just about all IF author's systems.
It's been done. Don Schaer's _Inform School_ is a Z-machine game
that includes an editor and interpreter for a subset of Inform.
I don't know how it was done, so you'll have to ask Don.
--
Neil Cerutti
cer...@trans-video.net
David A. Cornelson
news:68bd0e8.02081...@posting.google.com...
> Just when I thought that my work day couldn't get any worse, "David A.
> Cornelson" <da...@plover.net> came along and depressed me with ...
>
I am noted for depressing people. I depress them, but they pop back up all
the time. It's depressing.
On a less serious note, I will compile a list of requirements I believe
would be suitable for a widely used IF Editor. I will post them later.
Maybe.
Jarb
Plugh!
Now, that would un-depress ("impress" ?) me, by giving me something to
sink my teeth into. (please make it a new thread, btw)
> Maybe.
Aw, now you've done it again.
there is no spoon
Who would have known such a simple question would spark such a huge thread.
Maybe I should try it more often! I am currently (after downloading Adrift
because of the help from this group) writing a Harry Potter themed story.
It has taken about three hours, and you can get to the zoo. How about that!
<sarcasm in abundance> I agree that you need to be a good story teller
before the programming side, so I'm going to stick with Adrift while I get
the hang of it. It really isn't bad...
Thanks to everyone.
"Neil Cerutti" <cer...@12-104-16-35.trans-video.net> wrote in message
news:ajepri$1aj3mn$2...@ID-60390.news.dfncis.de...
Handorobou
> synonyms for a task will quickly grow unwieldy; what the author is
> expected to do is almost write their own parser for every command. Most
> don't, turning their games into guess-the-verb.
The author CAN define synonyms for commands in the standard library,
which helps some. But yes, not completely. Making a proper list of
commands for a task in ADRIFT is more work than it ought to be.
Furthermore, tasks with long and comprehensive lists of commands can
slow down the speed of game execution, from my experience.
Nevertheless, I am a strong advocate of ADRIFT. I recognize its
limitations. Everything Jeff said about the ADRIFT parser is true.
The biggest reason I chose ADRIFT as my game-authoring tool is that it
is not only author-friendly but player-friendly. I've not encountered
an interpreter with as many handy features to offer as ADRIFT's. Not
that a better interpreter doesn't exist somewhere, but I haven't seen
it. The ADRIFT interpreter (called the "ADRIFT Runner") can display
graphical maps, auto-completes words partially typed, allows users to
click on text to be copied to the command line, supports sound and
graphics in a variety of formats, has a 'control panel', and so on. I
don't use all of these features myself when I'm playing, but a game
developer has to think of his audience. Some people do use these
features. At the very least there is a great deal of potential.
While decent games written in ADRIFT are few and far between, that and
all other factors aside, playing IF is more enjoyable in ADRIFT.
In response to Woodfish, and backing up what he wrote...
As an author using ADRIFT, I have been able to do about 95% of the
things in my games that I've wanted to. Sometimes a clever workaround
is required to implement something unconventional, but more often than
not there is a way. I'm confident that what functionality is yet
missing from the tool will be added sooner or later. The most
significant shortcoming, I'd say, is that ADRIFT is not yet
cross-platform.
Campbell
> here) is allow you to define new verbs (e.g., "turn") and give them
> synonyms ("spin," "rotate"). Same goes for nouns. Thus instead of
> having to define all the synonyms anew for each task, the task can be
> more simply expressed as "turn wheel"; the parser will figure out that
> "spin the rim" is equivalent.
ADRIFT can do exactly that, although it rarely appears to be used.
To be honest, I think one of the main problems with ADRIFT is that
it's lacking the extensive libraries of some of the older systems.