What's IF worth?
If you were asked to write 50,000 words what would you think that would
be worth and then what about these other questions?
- Who gets the copyright? Many work-for-hire contracts also have
copyright release agreements.
- Would you need to have target parameters for the design such as:
- number of NPC's
- number of Locations
- number of areas or regions
- number of Puzzles
- What would you then charge to finish the game? So the writing gets
implemented and there are still spots that need to be "cleaned up"
afterwards. How much do you charge at this point or is it included in
the original amount?
Remember, you're _not_ programming the game...you're just writing it.
You may or may not have a say in the design so the role may be somewhat
If you're also the designer, is that an extra charge?
It's an interesting topic of discussion and I don't think anyone has
ever brought it up.
My experience as a professional freelance writer is that it's a buyer's
market. The relevant question is, how much can you afford to pay. You'll
find someone willing to do the work at any price, from $20 for the entire
game on up. The more you pay, the better results you can expect (or at
least, you can hope...).
In my field, which is music technology, I get paid anywhere between 5 cents
and 25 cents per word depending on the number of ads the magazine is
bringing in. At 5 cents per word, a 20,000-word game would cost you $1,000.
If you're hiring amateurs, you should be able to cut that in half. For a
50,000-word game, which is quite large, a fee of $1,000 (payable on
acceptance, with a kill fee of 25% to be paid even if you reject the work)
would seem appropriate.
> - Who gets the copyright? Many work-for-hire contracts also have
> copyright release agreements.
Everything is negotiable, but in IF I'd expect writers to be so grateful for
getting paid at all that they wouldn't whine or haggle if you asked to keep
all rights. Some of my clients buy all rights forever, others buy exclusive
electronic rights for 12 months and non-exclusive electronic rights
thereafter. In IF I don't think that would work, because non-exclusive
electronic rights would mean they could implement the same game themselves!
> - Would you need to have target parameters for the design such as:
> - number of NPC's
> - number of Locations
> - number of areas or regions
> - number of Puzzles
Certainly. Not explaining this to the writer is just begging to receive a
completely unusable mess.
> If you're also the designer, is that an extra charge?
If you're hiring someone purely to create words for you, the parameters
would have to be a lot more specific than that; otherwise, the writer
is doing design as well. Coming up with puzzles is design work.
Deciding how many rooms there should be, and how they should be laid
out, is design work. Figuring out how conversation goes together is
design work, and your hypothetical author would have to understand the
underlying mechanisms reasonably well in order to produce a script that
you could graft onto it -- unless you're planning to rewrite a lot of
I think this is part of the equation. Let's assume there are two
different scenarios. The first scenario is a writer that is familiar
with all aspects of IF writing. The second is a writer that has no clue
about writing IF.
In the first scenario, you could offer a design or ask for one. In
either case the working relationship would proceed as a traditional
In the second scenario, there would be an initial period where the
designer would detail deliverables and the writer would write to those
specifications. My assumption (and it's a large one) is that after some
period of time, the writer would either latch onto the process or not.
If they did, they would eventually be nuanced in IF writing. If they
didn't feel comfortable with the process, they would probably decline
to do more work in the medium.
I think there are benefits and detractors for both scenarios. In the
case of the experiences IF writer, there will be a strong urge to
control the process and there will also be a strong urge to followed
accepted practices from the IF community. These can be positive
influences, but they can also be negative influences.
The inexperienced writer will have to be trained to some degree, but
they won't have any design or programming biases and so they might
actually develop ideas that are new. These ideas may or may not be
easily implemented, but that's left to the publisher, since they have
to decide if the risk of complexity is worth any perceived reward in
the substance of the game.
If you hire one IF author to do both game design and writing, you have at
least two problems: First, the author's own creative vision may easily take
him or her far afield from your marketing plan. Second, the available talent
pool of people who have all of the requisite skills is smaller, and those
who have them are more than likely to be busy doing their own work.
My own view is that writing _is_ designing, and vice-versa. I don't think
the two are separable. For instance, let's say Dave hires me to write 50
room descriptions. Seems a simple enough assignment ... assuming I have a
clear understanding of (a) the physical layout the designer envisions for
the game and (b) the type of style desired for the writing. But then, in
writing a description of the forest path, I happen to mention some ferns and
some mushrooms. Suddenly we have two new scenery objects that need to be
coded. Do I write descriptions of them? Do I query the designer about
whether to do so? Do I avoid using any nouns in the room description in
order to dodge the problem?
And what about room descriptions that have to change due to game actions?
How can the writer handle such an assignment intelligently without
understanding how the code works?
Or consider the issue of non-default error messages -- a big deal that won't
come up until beta-testing, when you suddenly discover all the things you
SHOULD have implemented. Now the designer has to become a writer, because an
error message is one sentence long. It's not efficient to go back to the
writer and say, "We need another 75 sentences, and here are the situations
you'll have to describe."
In sum, I'd love to see Dave succeed, but I'm not convinced by his vision of
division of labor.
"Emily Short" <ems...@mindspring.com> wrote in message
> In all of my ramblings about commercial IF I often talked about
> separating the writing from the programming and even possibly the
> designs. When writers work in a freelance mode they get paid by the
> word or by the article.
> What's IF worth?
> If you were asked to write 50,000 words what would you think that would
> be worth
About a month. November, to be precise.
There is no advantage in separating design and writing only to have the
writer be forced into doing design; you might as well outsource both
parts as a whole. Then you're stuck with implementing what is primarily
someone else's work. That's not something I'd find enjoyable; but if
you're going to ask the writer to do do design work and then tell
him/her that the design is no good, I can't imagine that going well.
If you don't require the writer to do design, then you could pay someone
to fill in your design with words. How much prose is in a small, medium,
and large game? Once you determined that, then you could decide how well
you were going to pay the writer.
Guru.com is a good place to find hungry writers.
www.intaligo.com Building, INFORM, Seasons (upcoming!)
I don't agree with this. This to me falls under issue-tracking. If
there were a system that the writer could have access to, they would
know what writing needed to be done. At the same time, the writer will
know to add as much detail to a room description as possible and then
within the same system, add the new objects. It might even be possible
to parse the text and do this automatically.
I agree that separating design and writing is extremely complex. But
that says to me that a system might possibly simplify the process. Or
The only way to find out of IF can be written in this manner is to try
to break it down and build the systems (manual or electronic) that
assists in the cause. In other words, prove it.
Undeniably true. My main concern, I guess, is that creating a tracking
system that will allow a writer to access 100 very picky little bug reports
(as I've done during the past week), figure out appropriate textual
responses, and post the responses back to the system, where the programmer
will input them into the code, is another huge programming and logistical
challenge. It's expensive and will need testing. You could write a whole
game in the time it would take to set that up ... so why not write a
marketable game first and develop some cash flow?
> At the same time, the writer will
> know to add as much detail to a room description as possible and then
> within the same system, add the new objects. It might even be possible
> to parse the text and do this automatically.
ROFL. Well, not really, but figuratively. Adding "as much detail as
possible" means writing 5,000 words about EACH ROOM. It takes discriminatory
intelligence to figure out how to group objects, even or especially if
they're nothing but scenery. And now you're talking about yet another huge
automated system that will take development budget and testing.
I would urge you to write a series of marketable games first and worry about
all this high-end stuff next year or the year after.
I agree. But I don't think he'll never get that far.
David Cornelson is the RAIF version of that Dilbert (cartoon)
character, whose macromanagerial notions are, well, laughable. Like, "I
just told my coffee cup to get itself some coffe, but it's still empty.
Where do I submit a bug report?"
He basically brainstorms insanely bad ways of doing things, without
ever actually trying anything out, or even intending to try anything
out. You can tell from the way he behaves that he has no intention to
ever intellectually investigate anything. He's uninterested in the
(obvious) reasons why his plans fail. It's really quite a hilarious
character. (Or, it is when you see it in a cartoon -- when it's an
actual person, it's kinda scary. Still funny though, I guess.)
The problem: you been talking about good ideas, and good ideas talked
about badly makes good ideas sound bad.
Anyone who has done any IF collaboration work will easily assure you
that it works great. The problems here raised are nothing, easily
avoidable by any of many variations of intelligent planning. I've
collaborated a lot, and I have always had great results. Division of
labor is really easy when people are competent and when the goal is
The only problem could be that some jerk decides they're a project
leader, so they don't need to do any work, and they get to tell other
people what they want written here or coded there, all sublime an
uncooperative. That would be a problem. Luckily, such projects don't
get off the ground. (Like I mentioned above, Cornelson doesn't sound
like he's actually moving anything.)
Without commenting on the substance of your attacks, I'd just like to
point out that although the last six letters of David's name happen to
be the same as the last six letters of Graham's name, that doesn't
necessarily mean they're *related*, Steve.
We have digressed from the original intent of this thread and that's my
fault. I really have no interest in debating the systems of
collaborative IF quite this openly. I think Breslin's little rant is
more than enough proof that we not discuss it further.
As for the monetary contracts of writing IF I think your insights are
> We have digressed from the original intent of this thread and that's my
> fault. I really have no interest in debating the systems of
> collaborative IF quite this openly. I think Breslin's little rant is
> more than enough proof that we not discuss it further.
Before we close this discussion, I'll say that while I gave Dave a
little jab about XAML, it's just a professional difference. If you were
to ask me, I'd say that Dave and I are looking in the same direction. We
should be thinking about better methods to organize large projects.
Through my professional project management and by the experience of
others, planning a large project with good management
structures--whatever they are--is a good thing.
Thanks for bringing this up, Dave.