Open source IF?
Malcolm
games generally distributed as open source? I can see a lot of benefit
to the IF community if the source for many popular projects was
available for others to read, learn from and critique (or even debug).
I can think of two reasons off-hand, I suppose, wanting to maintain
control over one's own artistic work and wanting to keep "secrets" of
the game hidden. Are there others?
Of these two reasons, the latter is fairly weak I think. Secrets will
come out. There is as much temptation to read the source as there is to
download a walkthrough off the net.
But the first of the two does make some sense. You may have put a lot
of work into your work and don't want strangers plagiarising your code.
But then again, from an artistic point of view, I would have less
trouble with people plagiarising my code than with them plagiarising my
prose writing, which they could cut and paste without any problems.
One might also feel reluctance to allow others to potentially change
and redistribute your work, making it say things you never wanted it to
say. But do we all consider ourselves such "serious artists" that we'd
worry about this?
For many years, I've played on a MUD (LambdaMOO) which allows players
to be builders. Some major parts of the world have passed through many
sets of hands over the life of the MOO and are all the better for it.
Because the source is openly readable, bugs can be diagnosed and fixed
long after the original authors have moved on. Many times I have taken
somebody else's code and revised and improved it for my own objects.
Couldn't we do something similar for our work in IF?
Malcolm
ems...@mindspring.com
> Here's something I've been wondering about for a while: why aren't IF
> games generally distributed as open source? I can see a lot of benefit
> to the IF community if the source for many popular projects was
> available for others to read, learn from and critique (or even debug).
My feeling is that my code, unless written specifically for release, is
not good enough for anyone to learn from; that as a prop to finding out
about the innards of the game, it's inferior to a walkthrough; and that
I would prefer not to have other people debug or rewrite my work.
Anyway, before releasing any of my code I'd really need to go over it
and clean it up first -- in some cases, quite a lot. And, well, the
returns on that time investment (for me or anyone else) seem
insufficient to justify it.
You're in luck about Shade, though -- Zarf has already released the
code for that, though not, as far as I know, under any sort of open
source license. Still, for the purposes of reading the code for a
class:
http://www.eblong.com/zarf/if.html
Anyway, the open source idea has in fact been suggested before -- if
you wind up not getting as much feedback this time around as you'd
like, try searching on "Question on Open Source IF" on Google groups.
Doctor Freeze
IF. My background is good old fashioned novel writing and reading. I'm
currently hard at work on my own attempt at ``literary'' IF and was
thinking that I should probably slap an open source license on it when I
``publish'' it. One of the first things I did when trying to learn IF
programming was to get a source copy of Advent and start playing around
with it, adding things, removing things, cleaning up the tortured prose.
The source for Advent (I'm looking at the Inform source) has already
passed through many hands and there are many other versions.
Open source can be scary though, for authors I mean. There's a lot of
what-ifs that whirl around in your head when you think about giving up
creative control, but with IF a lot of the creative control has been
ceded to the reader/player anyway.
Open source is also a humble act. If there's bugs in my IF and I've
moved on to other projects, but some reader is inspired to fix them and
release an improved version, then they should be able to do that. I
think it would be polite for the reader to ask the author first (if
possible and before releasing the modified version).
Dave Griffith
> Open source can be scary though, for authors I mean. There's a lot of
> what-ifs that whirl around in your head when you think about giving up
> creative control, but with IF a lot of the creative control has been
> ceded to the reader/player anyway.
I was mildly disappointed with "Jason Finds Fleece". This was a spoof
of "robotfindskitten", which I ported from C to Inform. I appreciate it
when people think enough of my work to build on it, but I'd like to see
what happened to my code. Source to "robotfindskitten" is available at
the IF Archive.
BTW, I'm rather pleased with the way I've been able to press the
standard Unix tool "make" into service for easing the organization and
compilation of Inform code. Does anyone else here use "make" with
Inform?
--
David Griffith
dgr...@cs.csbuak.edu <-- Switch the 'b' and 'u'
Kevin Venzke
news:1122007954.4...@g49g2000cwa.googlegroups.com...
> I can think of two reasons off-hand, I suppose, wanting to maintain
> control over one's own artistic work and wanting to keep "secrets" of
> the game hidden. Are there others?
>
> Of these two reasons, the latter is fairly weak I think. Secrets will
> come out. There is as much temptation to read the source as there is to
> download a walkthrough off the net.
I don't think the latter is weak. There can be more to a game's "secrets"
than just how to complete it.
Also, there might well not be a walkthrough.
Kevin Venzke
Jeff Nyman
> Here's something I've been wondering about for a while: why aren't IF
> games generally distributed as open source? I can see a lot of benefit
> to the IF community if the source for many popular projects was
> available for others to read, learn from and critique (or even debug).
A lot of times you will hear people say, "Well, there are a lot of
games open sourced." What often gets missed is that some people learn
better when they are learning from a particular game they really liked.
For example, the author of "All Things Devours" released his source
code and that really encouraged me to sit down and learn a bit more
Inform. Yes, there were other Inform source out there, but I really
liked the game and, as such, I was more apt to use source from *that*
game as a learning experience.
So sometimes the more open source the better, because people respond
well to open source that they find interesting (as opposed to open
source that just serves as an indicative example).
> I can think of two reasons off-hand, I suppose, wanting to maintain
> control over one's own artistic work and wanting to keep "secrets" of
> the game hidden. Are there others?
Well, the artistic part seems odd to me, although I agree with you this
could be a motivation. But, after all, the value of the game should
come from the story it tells, not just from the algorithm(s) used to
present the game. In fact, I would think if certain algorithm(s) are,
in fact, very effective to writing good games, you would want those out
there. (In fact, is that not often the basis of extensions in the first
place?)
As far as secrets, to me that is just as simple as leaving it up to
people: after all, someone can choose not to look at the source until
they have finished the game.
> But the first of the two does make some sense. You may have put a lot
> of work into your work and don't want strangers plagiarising your code.
I think of it like an author of a book. Stephen King may write a great
novel. Now I could steal his work, word for word. But I would pretty
quickly be found out by the community of readers for that kind of
material. However, learning the tricks of the trade to being a good
writer (such as characterization or plotting) is also what goes into
the work and that is something I would think could be shared.
That logic kind of reverses itself for IF: there the plotting,
characterizing is not so much at issue. What is at issue is using the
same exact prose or the exact same characters, for example. But the
code logic behind what makes all that work is (to me) conceptually
similar to a novel writing sharing the "tricks" of the craft.
Again, with my "All Things Devours" example, it would be pretty stupid
of me to release a 'new' game that was basically just that game, with a
few changes. (Or releasing something like 'Starcrossed Over' but that
only differed in the title, but everything else was like the Infocom
game.) But learning from the source code from such games (both of which
I enjoyed) is much different. Or, at least, it is to my way of
thinking.
> One might also feel reluctance to allow others to potentially change
> and redistribute your work, making it say things you never wanted it to
> say. But do we all consider ourselves such "serious artists" that we'd
> worry about this?
Even so, you can try to release things under various licenses that
prohibit changes or modifications to your work but still release the
source code.
- Jeff
samwyse
> BTW, I'm rather pleased with the way I've been able to press the
> standard Unix tool "make" into service for easing the organization and
> compilation of Inform code. Does anyone else here use "make" with
> Inform?
Yes. I also use dfrotz to run regression tests against my games as I
write them.
Dave Griffith
Interesting. What are these tests like? I'm guessing you feed it a
walkthrough and massage the results with Perl.
Chris Pickett
> samwyse <deja...@email.com> wrote:
>
>>Dave Griffith wrote:
>
>
>>>BTW, I'm rather pleased with the way I've been able to press the
>>>standard Unix tool "make" into service for easing the organization and
>>>compilation of Inform code. Does anyone else here use "make" with
>>>Inform?
>
>
>>Yes. I also use dfrotz to run regression tests against my games as I
>>write them.
>
>
> Interesting. What are these tests like? I'm guessing you feed it a
> walkthrough and massage the results with Perl.
We use something like this for regression testing our PNFG compiler and
NFG interpreter... just pipe the walkthrough file into the interpreter,
capture the result on stdout, and diff the result against what you think
it is supposed to be. Pretty easy to do with just (ba)sh.
make by itself is okay, but I prefer autoconf et al. or ant for larger
things.
Chris
Poster
> Here's something I've been wondering about for a while: why aren't IF
> games generally distributed as open source? I can see a lot of benefit
> to the IF community if the source for many popular projects was
> available for others to read, learn from and critique (or even debug).
>
> and redistribute your work, making it say things you never wanted it to
> say. But do we all consider ourselves such "serious artists" that we'd
> worry about this?
The first few games I'm working on will fall under this category, I'm
afraid. That's because I designed them, down to the verb, to convey what
I wanted. The success or the failure are mine. If I wanted to design
something more like a template, or with the end goal in mind that others
would take it and run with it, I would. I've got nothing against doing
that. It'd be kewl. But that's not what I did.
I think a lot of folks release classes from their code, though. I know
I'm planning to when Building's been out for a month or two. The rest of
my code isn't that interesting. Standard stuff. Semi-hacky. You get the
picture.
I must admit, that I looked at Christminster's code when I was first
starting out, to figure out a few things. :o
-- Poster
www.intaligo.com/ -^-^-^- Inform libraries and extensions!
www.intaligo.com/building/ *- B U I L D I N G -* Dark IF. Coming soon!
Dave Griffith
>>>Yes. I also use dfrotz to run regression tests against my games as I
>>>write them.
>>
>>
>> Interesting. What are these tests like? I'm guessing you feed it a
>> walkthrough and massage the results with Perl.
> We use something like this for regression testing our PNFG compiler and
> NFG interpreter... just pipe the walkthrough file into the interpreter,
> capture the result on stdout, and diff the result against what you think
> it is supposed to be. Pretty easy to do with just (ba)sh.
> make by itself is okay, but I prefer autoconf et al. or ant for larger
> things.
I can't fathom using autoconf and friends with Inform. It's bad enough
trying to get it to work with straight C. But when it does, it's very
very nice.
samwyse
> samwyse <deja...@email.com> wrote:
>
>>Dave Griffith wrote:
>
>>>BTW, I'm rather pleased with the way I've been able to press the
>>>standard Unix tool "make" into service for easing the organization and
>>>compilation of Inform code. Does anyone else here use "make" with
>>>Inform?
>
>>Yes. I also use dfrotz to run regression tests against my games as I
>>write them.
>
> Interesting. What are these tests like? I'm guessing you feed it a
> walkthrough and massage the results with Perl.
Exactly. If a game has objects and/or verbs that are complicated, I put
them into include files like this:
Object jabberwocky ...
Object vorpal_blade ...
Extend attack ...
#ifdef UNIT_TEST;
Object kitchen ...
Initialise [ ;
move jabberwocky to kitchen;
move vorpal_blade to kitche;
];
#endif;
This allows me to compile the include file as a stand-alone game and
test special behaviors, and well as the more extensive tests of the
entire game. I don't need to massage things with Perl too much, though,
as I typically just capture the output and 'diff' it with something
that's known to be good.
Thomas Countford
> You may have put a lot
>of work into your work and don't want strangers plagiarising your code.
>But then again, from an artistic point of view, I would have less
>trouble with people plagiarising my code than with them plagiarising my
>prose writing, which they could cut and paste without any problems.
I fully agree with you. Now imagine them starting to plagiarise your
writing *and* your code.
For beginning authors, however, game source codes can prove invaluable.
When it comes to secrets and solutions, I don't think it matters all
that much whether or not a couple of players use the source code to
solve a difficult puzzle. If a player chooses to have a peek at it, he
(or she) probably does it because he's hopelessly stuck at some point.
Some authors might feel this is a waste of the energy they've put into
their well-crafted puzzle, but I would feel much worse if players got
frustrated and condemned my game to the recycle bin as a result.
Nikos Chantziaras
>
> Here's something I've been wondering about for a while: why aren't IF
> games generally distributed as open source? I can see a lot of benefit
> to the IF community if the source for many popular projects was
> available for others to read, learn from and critique (or even debug).
>
> I can think of two reasons off-hand, I suppose, wanting to maintain
> control over one's own artistic work and wanting to keep "secrets" of
> the game hidden. Are there others?
If we're really talking about open source (not just source code that has
been released for everyone to look at and learn from), then there's the
issue of me copying your code over to a new project, making some
modifications and releasing it to the public. Imagine you just open-sourced
"Foo", and a week later, someone releases "NewAndBetterFoo".
Chris Pickett
> If we're really talking about open source (not just source code that has
> been released for everyone to look at and learn from), then there's the
> issue of me copying your code over to a new project, making some
> modifications and releasing it to the public. Imagine you just open-sourced
> "Foo", and a week later, someone releases "NewAndBetterFoo".
I'd feel very honoured if that were to happen to me.
Chris
Nikos Chantziaras
>
> Nikos Chantziaras wrote:
> > Imagine you just open-sourced "Foo", and a week
> > later, someone releases "NewAndBetterFoo".
>
> I'd feel very honoured if that were to happen to me.
Well, same here actually. :)
Mike Snyder
news:42e559fa$0$21980$892e...@authen.white.readfreenews.net...
Not being a huge fan of Open Source myself, I could be mistaken -- but
doesn't Open Source code come with its own license, which pretty much allows
NewAndBetterFoo as long as NewAndBetterFoo is also free and gives credit to
the original? It's not the same as freeware.
What would be more of a concern to me is releasing the source code to Foo
*without* making it Open Source... then finding NewAndBetterFoo a week
later. That wouldn't flatter me at all.
I don't mind releasing source code, but I wouldn't want to "Open Source"
most of my games. A while back, though, I tried to get somebody to take over
one of my online games so it could be maintained and developed as Open
Source. I found no takers, so I gave up.
---- Mike.
Nikos Chantziaras
> Not being a huge fan of Open Source myself, I could be mistaken -- but
> doesn't Open Source code come with its own license, which pretty much
allows
> NewAndBetterFoo as long as NewAndBetterFoo is also free and gives credit
to
It actually encourages it.
> I don't mind releasing source code, but I wouldn't want to "Open Source"
> most of my games.
Meanwhile I changed my opinion on open source games. It doesn't make much
sense. If there's a bug, report it to the author. If you don't like it, it
doesn't make sense to change it and then play your own modified version.
It's a different story for non-game apps though.
Mike Snyder
>
> It actually encourages it.
>
Which is why I wanted to Open Source one of my online games. I guess the
original authors tend to get the ball rolling, instead of looking for
somebody to take over.
> Meanwhile I changed my opinion on open source games. It doesn't make much
> sense. If there's a bug, report it to the author. If you don't like it,
> it
> doesn't make sense to change it and then play your own modified version.
> It's a different story for non-game apps though.
Half-way through your reply, I was thinking to make the same comment you did
there at the end. If your goal is release a free product that relies on the
efforts of other developers, it probably makes sense. When I did a little
checking into it, most of the Open Source games I found (maybe at
SourceForge -- I forget) were seemingly abandoned, or only being developed
by the original author. Larger non-game applications fared better.
I'd prefer an API, map/story editor, resource editor, or some other method
of adding to a game without touching the underlying engine -- the kind of
thing IF engines already allow for game creation. An open-ended adventure
might benefit from Open Source, but for most IF, as you said, it makes more
sense to let the author fix problems. After all, the author should know the
ins and outs of the game better than anyone.
As for generally making the source code to more IF games available, I
appreciate what's available, but have never *expected* it. I released source
code for my games (for what little that's worth), but might later write
something I'd prefer to keep closed -- at least for a time. From what I've
seen, quite a bit of source is available already, for all the major IF
languages. It's enough to learn from, even if code for a particular game
that might appeal to a particular person has not been released.
---- Mike.
Chris Pickett
> Meanwhile I changed my opinion on open source games. It doesn't make much
> sense. If there's a bug, report it to the author. If you don't like it, it
> doesn't make sense to change it and then play your own modified version.
> It's a different story for non-game apps though.
I know it's a different genre (at least it's text-based), but nethack is
a shining example of how F/OSS can work really really well. As an
example of an IF game that was passed around multiple times, look at the
history of Adventure / Colossal Cave (however, it's not "open source").
Chris
Mantar, Feyelno nek dusa
> Not being a huge fan of Open Source myself, I could be mistaken -- but
> doesn't Open Source code come with its own license, which pretty much
> allows NewAndBetterFoo as long as NewAndBetterFoo is also free and gives
> credit to the original? It's not the same as freeware.
If you're using the GPL license, yes. The source code is copyrighted to
you, but the GPL means you grant others the right to use, view, modify,
and/or improve your code. The only restriction is that if they then
distribute it, the code containing their changes must be available too.
People are socially encouraged to contribute their changes back to the
primary copyright holder where useful, but it's generally enough to just
make them available.
This differs from say, the BSD license. The BSD license has only one
requirement: credit be given to the original authors. Otherwise it's okay
to bottle it up and make it a big secret. You'll see BSD credits in
proprietary products from Microsoft, Apple, and others.
> What would be more of a concern to me is releasing the source code to Foo
> *without* making it Open Source... then finding NewAndBetterFoo a week
> later. That wouldn't flatter me at all.
That would be copyright infringement, so I can understand that. It is
grounds for a civil suit, too, as is releasing NewAndBetterFoo without the
source code if Foo had been GPLed.
Malcolm
Yes, I'm a regular contributor of patches to the Nethack source, and I
agree that it has profited enormously fromthe many hands that have
worked on it, to become probably the richest game world in existence.
It is interesting to see how open-source development of nethack has
proceeded. Most people still play the "official" branch of the game.
There is also a separate semi-experimental Slash'Em branch
(Super-Lota-Added-Stuff-Hack with Extended Magic) which has now
diverged widely from the orginal game. And then there are people like
me, who develop and release patches for the official source, and hope
that someday those patches will catch the eye of the official DevTeam
and will be included in the next official release.
Of course, it's a different kind of game in many ways, and I'm not sure
how open source would work with IF.
Malcolm
Mike Roberts
> Nikos Chantziaras wrote:
>> Imagine you just open-sourced "Foo", and a week later, someone releases
>> "NewAndBetterFoo".
>
> I'd feel very honoured if that were to happen to me.
I think that sentiment would be atypical among IF authors, actually. This
really cuts to the heart of why you're finding so few games released in
source form, in my opinion.
The thing to understand is that a significant part of text IF's draw - for
authors - is that it's physically possible for a single person to write a
complete work in her spare time. That isn't the case for almost any other
type of computer game. There are other things about the medium to like, of
course, but most of those other things aren't unique to text IF; and IF has
a big downside, too, which is that its audience is so small.
So I think IF authors tend to self-select for low (or negative) interest in
collaboration. I mean, if you were the sort of person who liked
collaboration, you might as well take advantage of the wider choices of
media this would open to you, and pick one that has some of the desirable
properties of IF but which has a bigger audience, such as graphical
adventures. And I think that this disinclination towards collaboration
might correlate with a certain possessiveness about one's work, which might
include a desire *not* to have someone else presume to improve upon it.
(Sure, you could release your source and write a license that prohibits
anyone from creating an "improved" version; but if you don't care to have
anyone fix bugs or "improve" your writing style, you're left with basically
no selfish motive for releasing the source at all. It would be a purely
altruistic gesture, for the edification of the next crop of would-be
authors. That might be enough for some people, but it's not a particularly
urgent motivator for most. And maybe not enough in your mind to offset the
risks you always take when you release source code - the risk that someone
will wantonly ignore your license terms, or that Unisys will discover that
you've infringed their patent on A Method And Apparatus For Displaying
English Words In ASCII, or heaven knows what else.)
--Mike
mjr underscore at hotmail dot com
samwyse
> Here's something I've been wondering about for a while: why aren't IF
> games generally distributed as open source? I can see a lot of benefit
> to the IF community if the source for many popular projects was
> available for others to read, learn from and critique (or even debug).
Since I haven't seen anyone else mention this, allow me to point out
that a lot of IF is built from open source. By this I mean that a given
system's standard library is available for modification; many games use
library modules that are open; and a fair number of authors release new
modules that are derived in some way from their games. The only things
that generally aren't released would be the actual text and the objects
that encapsulate it, and those items aren't required for others to read,
learn from, or critique.
Chris Pickett
Hmmm. Neither inform-6.30.2/COPYING nor tads-3.0.8/tads3/README.TXT are
Free / open source software licenses. I grepped around, but couldn't
find a different license for the library files.
Chris
Chris Pickett
Of course, I meant to write tads-3.0.8/tads3/LICENSE.TXT.
Chris
samwyse
>> Hmmm. Neither inform-6.30.2/COPYING nor tads-3.0.8/tads3/README.TXT
>> are Free / open source software licenses. I grepped around, but
>> couldn't find a different license for the library files.
>
> Of course, I meant to write tads-3.0.8/tads3/LICENSE.TXT.
I can't find a COPYING file in any of my versions of the Inform
compiler's source code nor the library, all of which are downloaded
directly from Graham Nelson's website. Nevertheless, I'll agree that
the source code for the compiler isn't open source, because the status
of the compiler isn't the issue here. Very few people writing IF feel
the need to hack the compiler.
The library files (which are all Inform source code, not C) start with
the words, "Copyright Graham Nelson 1993-2004 but freely usable (see
manuals)". If we assume that by "manuals", Graham means DM4, then the
only references to the "openness" of the library are the following,
which indicate that authors are allowed to rewrite the library as needed
(although the Inform language tries very hard to minimize that need):
"The Library is itself written in Inform, and with experience it's not
too hard to alter it if need be." (p 191)
"Anson Turner's "animalib" retains the core algorithms of the Inform
library (principally the parser and list-writer) but redesigns the
superstructure of properties and attributes with the aim of a cleaner,
more consistent world model." (p 193, an example of someone altering the
library)
Let's see, you have the source and you're allowed to modify it. Sounds
like that fits the definition of "open source", although it is closer to
a BSD license than it is to the GPL.
Chris Pickett
> Chris Pickett wrote:
>
>>> Hmmm. Neither inform-6.30.2/COPYING nor tads-3.0.8/tads3/README.TXT
>>> are Free / open source software licenses. I grepped around, but
>>> couldn't find a different license for the library files.
>>
>>
>> Of course, I meant to write tads-3.0.8/tads3/LICENSE.TXT.
>
>
> I can't find a COPYING file in any of my versions of the Inform
> compiler's source code nor the library, all of which are downloaded
> directly from Graham Nelson's website. Nevertheless, I'll agree that
> the source code for the compiler isn't open source, because the status
> of the compiler isn't the issue here. Very few people writing IF feel
> the need to hack the compiler.
Yes, I just chose the compiler distributions because they also include
the libraries, and I couldn't find a license elsewhere.
For Inform's COPYING file, see:
http://ifarchive.org/if-archive/infocom/compilers/inform6/source/inform-6.30.2.tar.gz
( same thing linked through http://tinyurl.com/7f87t )
I also mirrored it since ifarchive.org is very slow:
http://www.sable.mcgill.ca/~cpicke/inform-6.30.2.tar.gz
> The library files (which are all Inform source code, not C) start with
> the words, "Copyright Graham Nelson 1993-2004 but freely usable (see
> manuals)". If we assume that by "manuals", Graham means DM4, then the
> only references to the "openness" of the library are the following,
> which indicate that authors are allowed to rewrite the library as needed
> (although the Inform language tries very hard to minimize that need):
>
> "The Library is itself written in Inform, and with experience it's not
> too hard to alter it if need be." (p 191)
>
> "Anson Turner's "animalib" retains the core algorithms of the Inform
> library (principally the parser and list-writer) but redesigns the
> superstructure of properties and attributes with the aim of a cleaner,
> more consistent world model." (p 193, an example of someone altering the
> library)
>
> Let's see, you have the source and you're allowed to modify it. Sounds
> like that fits the definition of "open source", although it is closer to
> a BSD license than it is to the GPL.
One test that many freeware or pseudo-"open source" licenses fail is
this: can I put the Inform library source on a CD, either verbatim or
having been modified by me, and sell it? Certainly the compiler license
files, which may be reasonably assumed to cover the library files that
are shipped in the same package (modulo inferring the definition of
"freely usable" from the manual), explicitly prohibit this.
Chris
Chris Pickett
> I also mirrored it since ifarchive.org is very slow:
easily fixed with a closer ifarchive.org mirror :( Sorry for all the
follow-up posts.
Sands...@yahoo.com
Mike Roberts wrote:
<< I think that this disinclination towards collaboration
might correlate with a certain possessiveness about one's
work, which might include a desire *not* to have someone
else presume to improve upon it. >>
I think IF authors beta test their games because they do
want other people to improve their work. The concern is
probably more along the lines of keeping the author's voice
or intent intact, which is unlikely to happen once the author
loses the ability to choose what will or won't go into a
game, and how these things are expressed.
<< if you don't care to have anyone fix bugs or "improve"
your writing style, you're left with basically no selfish
motive for releasing the source at all. It would be a purely
altruistic gesture, for the edification of the next crop of
would-be authors. That might be enough for some people, but
it's not a particularly urgent motivator for most. >>
But there are a lot of library extensions at the IF Archive.
It looks a little like there is more donated code at the
Archive than most people can sort through or make use of.
For instance, I've seen a couple of "go to" library modules
that no one's made use of and some generalized code to handle
the division and mixing of powders and fluids that I don't
think anyone's borrowed. (Perhaps no one's wanted those
functions, but they sound pretty useful to me.)
Out of curiosity, can anyone think of something that would be
tough to implement that's shown up in a game but not been
published in source form at the Archive (or in the newsgroup)?
<< And maybe not enough in your mind to offset the risks you
always take when you release source code - the risk that someone
will wantonly ignore your license terms, or that Unisys will
discover that you've infringed their patent on A Method And
Apparatus For Displaying English Words In ASCII, or heaven
knows what else.) >>
Yes, but, fortunately, once taking money from people is no longer
the objective, these sort of things appear to happen far less often.
Mike Roberts
> mjr:
>> I think that this disinclination towards collaboration
>> might correlate with a certain possessiveness about one's
>> work, which might include a desire *not* to have someone
>> else presume to improve upon it.
>
> I think IF authors beta test their games because they do
> want other people to improve their work.
Well, not literally - I mean, authors don't traditionally hand over the
source to beta testers and ask them to please go improve it. But
indirectly, yes: one beta-tests a game to get ideas from other people for
improvements.
> The concern is probably more along the lines of keeping
> the author's voice or intent intact [...]
That's the possessiveness I'm talking about.
I didn't mean to suggest that IF authors as a group are hostile to input -
quite the opposite is true, I'm sure. But they do want the final say, and
they want the end product to be theirs. They want to be able to decide
which suggested improvements are actually improvements. That's what I meant
about authors not wanting other people to *presume* to improve things - a
suggestion isn't presumptive, as the author's under no obligation to take
it.
steve....@gmail.com
situation.
Mike writes:
> I think IF authors tend to self-select for low (or negative) interest in
> collaboration. I mean, if you were the sort of person who liked
> collaboration, you might as well take advantage of the wider choices of
> media this would open to you, and pick one that has some of the desirable
> properties of IF but which has a bigger audience, such as graphical
> adventures.
I politely but strongly disagree with this characterization of the
IF-authors.
Yes, the authors choose IF because they can do it by themselves, but it
is not because they have negative interest in collaboration. The author
is for the first time getting into writing games. And after much work,
they write a game or two. They may dream of collaborating on a larger
work, but where and how?
I've been around a bit, and I don't even know: where's this the
graphical adventure project you speak of? I'd be happy to collaborate!
I've always received strong interest whenever I've proposed or entered
a collaborative IF-project.
Rikard Peterson
Steve Breslin wrote in
news:1122941380.5...@g49g2000cwa.googlegroups.com:
> I've been around a bit, and I don't even know: where's this the
> graphical adventure project you speak of? I'd be happy to
> collaborate!
I just have to finish my current project first. (Hopefully before the
end of the year...) Then I'll probably be looking for collaboration on
either a text or graphical game. :)
Rikard