Thoughts on Major Scenario Projects
by Hamish Sanderson
These things always take much longer than you think. eg. Trojan was
conceived about 18 months ago, work seriously began Dec95, first
mapmakers recruited around Easter 96, work dropped off completely
over summer because the idiot coordinator (ie. me) went off for 10
weeks without any internet connection. Picked up in Sept96, has
been on the burn pretty much ever since - and still isn't finished!
And it's based on an engine that is 3+ years old and will probably be
out about the time MacQuake starts appearing......so I hope folk
don't trade in their old copies of M1 for Quake before Trojan is
ready!;)
So:
Rule 1 - Whatever date you expect to be done by, you won't. So don't
go booking any holidays timed for the week after your proposed
release dates!
-----------------ooOoo-----------------
These things always involve far more work than anyone realises.
Making shapes, sounds, maps, etc can be pretty intensive on its own,
but putting them together is also a pretty major project, especially
when it's all coming from different sources. Trojan 's maps were all
completed ages ago (with one exception, but maybe I'll come back to
this later) - much of the works since for me has been assembling them
into a single pack (which also involves a lot of work balancing
difficulty & alien/ammo placement across the entire pack of 27
levels).
In fact, it's taken longer to bring the maps together, which
had several folk working on them, than the graphics which I did most
of myself. (However, without the graphics being done at the beginning
it would have been very difficult to build the maps!)
So this is:
Rule 2 - this can be a easily turn into 7-day-a-week job. Slow and
tedious, but still far better to do a bit a day than let it all pile
up til the weekend.
-----------------ooOoo-----------------
Laws of Diminishing Returns - (ok, so stop me here if you think this
is wrong, but it's just my opinion after a looooong day). I think it
is possible to have too many people on a project. Every time you take
on someone new it takes time for them to become familiar with the
project, both it's noble aims (ie. what's required), and its guts
(ie. how to do the job).
So bringing on 1 mapmaker per map required might seem like a quick
way to do things, but it probably won't be. You might be better to
have 1 mapmaker per 4 maps - they'll get through the 2nd, 3rd and 4th
ones a lot faster once they've learned the ropes over the first one.
(A project co-ordinator loves nothing more than being able to let
mapmakers get on with the job, secure in the knowledge that they've
done one good map already and know how to approach the rest.)
Having said that, I've had some folk contributing just a single map,
and they've done great. But I couldn't have survived 27 different
folk all starting from fresh....
Rule 3 - limit the size of your group to something sensible. Taking
on more folk won't make things go much faster, but will add
considerably to the work involved in running the project.
-----------------ooOoo-----------------
Which brings me to.........
Running the Project. Now, this is really the key job. (I'm not
bragging or anything just because I'm a project co-ordinator, this is
actually the most demanding job of all!) I honestly don't know of any
projects that have been run on a purely democratic basis where
everybody has equal say. To be honest, though I think this might work
for a project where everyone is in the same room, I don't think it
could work for a large Internet-based group. (Try getting a dozen
people on IRC all at the same time on the same day and see how
successful a group discussion of all the issues could be! :/
Especially for folk using school computers, or who are in different
time-zones, etc.)
So somebody has to be in charge. How folk decide who is boss is up to
them, but it's an important decision to make. With Trojan it was
easy, I'd already built the shapes and sounds (or most of them
anyway), plus the story was mine, so there wasn't much issue of who
was boss - the job automatically fell to me. The result being that
although those involved have all worked really hard, I've had to work
a damn sight harder! Which means Major Commitment. (Written in
Extra-Bold and Underlined three times!)
So anyone who wants to organise a 20+ level scenario with completely
new graphics & sounds thrown in: take note. If you had a life before
you started the job, you probably won't have one by the time you're
finished (well, look at me!:). It can be a Major Slog, so unless
you're sure you can handle it, don't commit to something you can't
realistically attempt to see through.
Rule 4 - You gotta be able to rely on the co-ordinator. And the
co-ordinator has to be sure that he can devote sufficient time to run
the project.
-----------------ooOoo-----------------
The next rule turns this one around a bit. I know this one probably
won't go down too well with everybody, but it's in no way intended as
a personal attack on anyone. Or:
You got to be able to depend on the group members. ie. if someone
promises to do something for a month's time, and doesn't deliver
anything after 8 weeks then the group has a problem. Unfortunately
(and this is where I'll probably get flamed to hell by everyone),
some folk will be eager enough to sign up for a project but as soon
as work is due to be completed you'll never hear from them again.
Now, to be entirely fair, there can be many reasons for folk dropping
out of a project: their college/school commitments could be too
great, they might later disagree with the aims of the group, they
could (for all anyone else knows) be pushing up daisies after an
unfortunate argument with the front of a 40 ton truck......
(ie. flaming someone for being late is probably not a wise idea -
be polite, especially if you don't know the full story.) So be aware
that taking on other people to do work doesn't always work out. And
for anyone who does drop out, for whatever reason, let somebody know
you're leaving. (Even if they fall out with the group it's still
polite to let folk know the work won't be getting done.) So the best
way may be to take folk on on a trial basis at first. But don't just
stick to established names because you're worried about untried folk
- some of the best work on Trojan has been done by folk completely
new to Marathon editing, it might take a bit longer for somebody new
to learn the ropes, but they can also bring a whole lot of enthusiasm
and fresh ideas to the project.
Rule 5 - the coordinator must be prepared to have to deal with folk
who don't hold their end of the bargain. But do it politely and
professionally. And other members mustn't make commitments they can't
expect to keep.
-----------------ooOoo-----------------
On top of all that, there's stuff like editing - somebody has to make
sure that everything fits together, which also means arranging for
alterations or corrections to be made (either by the editor or the
author, but either way by agreement). Also quality control (ouch!) -
if somebody produces something that is plain awful then don't expect
it to go away by itself - it needs dealt with.... one way or another.
Communications - a group only functions if people keep talking to
each other. Nothing worse than not knowing what anyone is doing.
The co-ordinator needs to be in regular contact with the rest of the
group, and group members need to let the coordinator know if there
are any problems. (It's also polite of members to inform the
coordinator if they're going for a month's holiday or have exams on
or anything else which might present problems - and *before* the
occassion!:)
I could also list the number of problems we've had due to ISP's,
broken Macs, etc, but I won't cos I'd be here all night. Just be
aware that emails don't aways get through, attachments may be
corrupted, folk may be out of touch because their ISP has fallen
down, etc. (And if it happens to you, then for goodness sake, let
someone know as soon as possible!) Make sure folk know how to use
email, ftp, etc, and if not then get someone to teach them.
-----------------ooOoo-----------------
Anyway, there's probably lots more I could add, but just to
demonstrate how hard it is to run these projects at times:
I'm using an outside computer suite for all my email, ftp, web
access, etc. (ie. I don't have a modem connection to my Mac at
home). I use 486 PCs running Win3.1 for all email, file transfers,
etc. The place opens at 8.30am and shuts at 9.30pm Mon to Fri. It's
also open weekends, but not during the holidays (like, just now) so
I'm limited in how much contact I can have with folk in a day or
week. Plus it's in the UK, so I'm several time zones away from the
US, and we also have members in other parts of the world. The mail
server here takes a very big dislike to attachments sent from certain
types of accounts, so file transfers can really be a problem (they
were impossible at first until I'd managed to teach myself all the
ins and outs of Win3.1 and the apps running under it. I should say
that Claude and other folk were really helpful and patient with me
whilst I was still learning the ropes - thanks guys). Oh, and it's a
15 minute walk between here and my home, so if I forget to bring
something on floppy then it generally has to wait another day.
Oh, and I've lost count of the number of hours I've spent online -
but it's an awful lot.
(And people wonder why I sometimes get cranky!)
-----------------ooOoo-----------------
One last thing - make damn sure that good records are kept of who's
doing what (& where to contact them), when stuff is due, what's
required and how to do it, timetables, etc. etc. etc. Bad admin. can
be the death of a project, easy. And finally, KEEP BACKUPS!!! Sure as
hell, the first time you forget to make a backup of a file, the next
time you look for it you'll find it corrupted or lost or something
(it's a good idea to hang onto older versions as you go along, just
in case the most recent version turns out to be corrupted but isn't
apparent til later). Oh, and this applies to everyone in the group
(the only difference is that the coordinator has to keep backups of
everybody else's work, as well as his own, and in triplicate if
possible for safety's sake).
Back to The Table Of Contents
by Hamish Sanderson
These things always take much longer than you think. eg. Trojan was
conceived about 18 months ago, work seriously began Dec95, first
mapmakers recruited around Easter 96, work dropped off completely
over summer because the idiot coordinator (ie. me) went off for 10
weeks without any internet connection. Picked up in Sept96, has
been on the burn pretty much ever since - and still isn't finished!
And it's based on an engine that is 3+ years old and will probably be
out about the time MacQuake starts appearing......so I hope folk
don't trade in their old copies of M1 for Quake before Trojan is
ready!;)
So:
Rule 1 - Whatever date you expect to be done by, you won't. So don't
go booking any holidays timed for the week after your proposed
release dates!
-----------------ooOoo-----------------
These things always involve far more work than anyone realises.
Making shapes, sounds, maps, etc can be pretty intensive on its own,
but putting them together is also a pretty major project, especially
when it's all coming from different sources. Trojan 's maps were all
completed ages ago (with one exception, but maybe I'll come back to
this later) - much of the works since for me has been assembling them
into a single pack (which also involves a lot of work balancing
difficulty & alien/ammo placement across the entire pack of 27
levels).
In fact, it's taken longer to bring the maps together, which
had several folk working on them, than the graphics which I did most
of myself. (However, without the graphics being done at the beginning
it would have been very difficult to build the maps!)
So this is:
Rule 2 - this can be a easily turn into 7-day-a-week job. Slow and
tedious, but still far better to do a bit a day than let it all pile
up til the weekend.
-----------------ooOoo-----------------
Laws of Diminishing Returns - (ok, so stop me here if you think this
is wrong, but it's just my opinion after a looooong day). I think it
is possible to have too many people on a project. Every time you take
on someone new it takes time for them to become familiar with the
project, both it's noble aims (ie. what's required), and its guts
(ie. how to do the job).
So bringing on 1 mapmaker per map required might seem like a quick
way to do things, but it probably won't be. You might be better to
have 1 mapmaker per 4 maps - they'll get through the 2nd, 3rd and 4th
ones a lot faster once they've learned the ropes over the first one.
(A project co-ordinator loves nothing more than being able to let
mapmakers get on with the job, secure in the knowledge that they've
done one good map already and know how to approach the rest.)
Having said that, I've had some folk contributing just a single map,
and they've done great. But I couldn't have survived 27 different
folk all starting from fresh....
Rule 3 - limit the size of your group to something sensible. Taking
on more folk won't make things go much faster, but will add
considerably to the work involved in running the project.
-----------------ooOoo-----------------
Which brings me to.........
Running the Project. Now, this is really the key job. (I'm not
bragging or anything just because I'm a project co-ordinator, this is
actually the most demanding job of all!) I honestly don't know of any
projects that have been run on a purely democratic basis where
everybody has equal say. To be honest, though I think this might work
for a project where everyone is in the same room, I don't think it
could work for a large Internet-based group. (Try getting a dozen
people on IRC all at the same time on the same day and see how
successful a group discussion of all the issues could be! :/
Especially for folk using school computers, or who are in different
time-zones, etc.)
So somebody has to be in charge. How folk decide who is boss is up to
them, but it's an important decision to make. With Trojan it was
easy, I'd already built the shapes and sounds (or most of them
anyway), plus the story was mine, so there wasn't much issue of who
was boss - the job automatically fell to me. The result being that
although those involved have all worked really hard, I've had to work
a damn sight harder! Which means Major Commitment. (Written in
Extra-Bold and Underlined three times!)
So anyone who wants to organise a 20+ level scenario with completely
new graphics & sounds thrown in: take note. If you had a life before
you started the job, you probably won't have one by the time you're
finished (well, look at me!:). It can be a Major Slog, so unless
you're sure you can handle it, don't commit to something you can't
realistically attempt to see through.
Rule 4 - You gotta be able to rely on the co-ordinator. And the
co-ordinator has to be sure that he can devote sufficient time to run
the project.
-----------------ooOoo-----------------
The next rule turns this one around a bit. I know this one probably
won't go down too well with everybody, but it's in no way intended as
a personal attack on anyone. Or:
You got to be able to depend on the group members. ie. if someone
promises to do something for a month's time, and doesn't deliver
anything after 8 weeks then the group has a problem. Unfortunately
(and this is where I'll probably get flamed to hell by everyone),
some folk will be eager enough to sign up for a project but as soon
as work is due to be completed you'll never hear from them again.
Now, to be entirely fair, there can be many reasons for folk dropping
out of a project: their college/school commitments could be too
great, they might later disagree with the aims of the group, they
could (for all anyone else knows) be pushing up daisies after an
unfortunate argument with the front of a 40 ton truck......
(ie. flaming someone for being late is probably not a wise idea -
be polite, especially if you don't know the full story.) So be aware
that taking on other people to do work doesn't always work out. And
for anyone who does drop out, for whatever reason, let somebody know
you're leaving. (Even if they fall out with the group it's still
polite to let folk know the work won't be getting done.) So the best
way may be to take folk on on a trial basis at first. But don't just
stick to established names because you're worried about untried folk
- some of the best work on Trojan has been done by folk completely
new to Marathon editing, it might take a bit longer for somebody new
to learn the ropes, but they can also bring a whole lot of enthusiasm
and fresh ideas to the project.
Rule 5 - the coordinator must be prepared to have to deal with folk
who don't hold their end of the bargain. But do it politely and
professionally. And other members mustn't make commitments they can't
expect to keep.
-----------------ooOoo-----------------
On top of all that, there's stuff like editing - somebody has to make
sure that everything fits together, which also means arranging for
alterations or corrections to be made (either by the editor or the
author, but either way by agreement). Also quality control (ouch!) -
if somebody produces something that is plain awful then don't expect
it to go away by itself - it needs dealt with.... one way or another.
Communications - a group only functions if people keep talking to
each other. Nothing worse than not knowing what anyone is doing.
The co-ordinator needs to be in regular contact with the rest of the
group, and group members need to let the coordinator know if there
are any problems. (It's also polite of members to inform the
coordinator if they're going for a month's holiday or have exams on
or anything else which might present problems - and *before* the
occassion!:)
I could also list the number of problems we've had due to ISP's,
broken Macs, etc, but I won't cos I'd be here all night. Just be
aware that emails don't aways get through, attachments may be
corrupted, folk may be out of touch because their ISP has fallen
down, etc. (And if it happens to you, then for goodness sake, let
someone know as soon as possible!) Make sure folk know how to use
email, ftp, etc, and if not then get someone to teach them.
-----------------ooOoo-----------------
Anyway, there's probably lots more I could add, but just to
demonstrate how hard it is to run these projects at times:
I'm using an outside computer suite for all my email, ftp, web
access, etc. (ie. I don't have a modem connection to my Mac at
home). I use 486 PCs running Win3.1 for all email, file transfers,
etc. The place opens at 8.30am and shuts at 9.30pm Mon to Fri. It's
also open weekends, but not during the holidays (like, just now) so
I'm limited in how much contact I can have with folk in a day or
week. Plus it's in the UK, so I'm several time zones away from the
US, and we also have members in other parts of the world. The mail
server here takes a very big dislike to attachments sent from certain
types of accounts, so file transfers can really be a problem (they
were impossible at first until I'd managed to teach myself all the
ins and outs of Win3.1 and the apps running under it. I should say
that Claude and other folk were really helpful and patient with me
whilst I was still learning the ropes - thanks guys). Oh, and it's a
15 minute walk between here and my home, so if I forget to bring
something on floppy then it generally has to wait another day.
Oh, and I've lost count of the number of hours I've spent online -
but it's an awful lot.
(And people wonder why I sometimes get cranky!)
-----------------ooOoo-----------------
One last thing - make damn sure that good records are kept of who's
doing what (& where to contact them), when stuff is due, what's
required and how to do it, timetables, etc. etc. etc. Bad admin. can
be the death of a project, easy. And finally, KEEP BACKUPS!!! Sure as
hell, the first time you forget to make a backup of a file, the next
time you look for it you'll find it corrupted or lost or something
(it's a good idea to hang onto older versions as you go along, just
in case the most recent version turns out to be corrupted but isn't
apparent til later). Oh, and this applies to everyone in the group
(the only difference is that the coordinator has to keep backups of
everybody else's work, as well as his own, and in triplicate if
possible for safety's sake).
Back to The Table Of Contents