[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Light Princess -- Where are those programmers?
Terry Hancock wrote:
> Well, we've been going for about six months now, and
> what we have are some character artists, a web maintainer
> (me), and some other creative work. There _are_
> programmers on my mailing list, but they appear
> to be acting as spectators.
Managing programmers is known to be a hard thing.
Doing that with people who are doing things out of
the goodness of their hearts is doubly hard.
> I've run into to two types of problems interfacing
> with the programming side of the fence:
> 1) They say "well, write me a specification -- I can't
> code anything without a spec". So I do, which brings
> us to problem #2:
I'm a little suprised at that reaction...but OK.
> 2) They don't want to follow my plans. I write specs,
> they argue a bit, and then they go off with plans to
> write something quite different, and generally I don't
> hear much from them after that.
You have to be prepared to discuss your specifications.
If they don't like what you propose they probably will
just seen out another project.
It's important that this is a cooperative exercise...they
get to change the direction of the project too!
> I was originally under the impression that in the open
> source world, I'd need to grant maximum creative freedom
> to the programmers in order to get interest.
Yes. That's generally true.
> But then
> after some discussion, I became convinced that they
> actually wanted me to do the research and planning
> (i.e. the "software engineering") and just ask them
> to code.
That's unusual - but it's an individual thing. You
may happen to have people who *prefer* to have rigid
specifications. But from your points (1) and (2) above,
I suggest that you have a mixture of people - some of
whom want a specification - some of whom want the freedom
to go off at a tangent.
> Now I don't know what to think -- except possibly that the
> original premise, i.e. that there are plenty of programmers
> ready to write games and game engines given creative
> content, is horse feathers! :) I would love for you
> guys to prove me wrong on this!
Managing an OpenSource project is quite hard. The 'people
skills' thing can be hard to get a grip on.
I would not be shy about this. On your mailing list, write
these concerns - heck - forward your post from linuxgames/kidsgames
onto your own list...tell them that you don't understand what
they want - ask them to give you a 'meta-specification' (a
specification for the specification) - what do they WANT you
to express in your spec - what do they want you to leave
to their creative freedom?
> As a result of this situation, I have written a fairly
> detailed specification for our game engine requirements,S
> as well as locating some existing code and design
> bases to work from. This is outlined on the webpage for
> The Light Princess (go to "Developers" and then to
> "Game Engine"):
> The entire site has actually grown quite large by now,
> so I hope you will take the time to look around it
> a bit to understand what we're trying to do.
It's a VERY nice site!
I've taken a look at your specification - and whilst
some of it seems pretty straightforward for someone
to just pick up and run with (the AutoManga presenter,
the Sentence-Input and GUI module) - some are VERY hard
for a programmer to just go off and implement. (Emotion!
Heuristics Interpreter! Yikes!)
However, if the other modules around those were a bit
more firm, I think I could get a grip on it. This looks
a bit like putting together a jigsaw puzzle in which
all the pieces are made of Jello. If most of the puzzle
were completed and solid, I could probably figure out where
one Jello piece had to be added.
I don't think you should interpret this comment as a
need to write REALLY RIGID specifications for each part.
I suspect that if you are not a programmer, you wouldn't
succeed at the system engineering required to do that.
For an OpenSource project, I think you have to get
your programmers to firm up the design as they go along.
I think you need to break the design down to manageable
chunks that can be 'got going' in a standalone manner.
Start from the places where you get interesting (preferably
visual/audio) outputs so that there is overtly visible
progress being made.
If you can (for example) define the Cel animation
module and have your programmers go off and implement
that - with the special effects and such - and make it
so it can be driven by some simply Python code...I think
you'd find that your team of tame programmers would leap
off and write it for you.
Once that's working and producing visible results, climb
one more layer up the hierarchy and get into your "PUB"
module so you can then build worlds and render them.
...essentially take this rather daunting 'world view'
and split it into 'brain-sized' chunks...not worrying
overly much about the high level stuff until you have
the lower levels actually working and producing results.
Initially, you'll have a 'movie player' where a human does
all of the scripting. Perhaps a little later, you can
have your 'actors' obey higher level commands, then add
the GUI so you can give those commands in English and
they'll be obeyed without question, then give your actors
their AI so those commands now become 'suggestions' or
whatever the player input has to be.
Each one of those steps seems bearable - but the entire
package seems like a massive undertaking. Your programmers
are probably feeling overwhelmed.
> Anyway, I would really like to invite you all to
> take a look at the present site and let me know if
> you're interested in contributing.
It's really not my kind of a thing...very nice - but
just not my style. (Also I have *way* too many other
Mind you, I only
> wrote this detailed spec because it was requested
> of me -- I'm willing to be quite flexible on it. We
> did discuss a number of points about it, and I'm
> pretty attached at this point to using XML/SVG for
> game resources and programming in Python as needed
> (for the _game_ programming, not necessarily the
> _game_engine_ programming).
I don't think you'll get many objections to that
> The character agents
> are an exciting technology that I thought might
> capture someone's interest...
Yes - but they come over as WAY too hard a problem
when considered alongside the vast amount of other
stuff you need doing.
Take your existing document - relabel it as "Our
long range plan" - write a new document that describes
the first step that'll lead to something you can
actually RUN and see some kind of a result from.
As each part gets close to working, add another
chunk from the long range plan into the "What we
are doing next" file.
**ALWAYS** discuss in advance what your team
want to do next - expect them to not only change
the structure of your plans - but also the end
result of the project. You are just one member
of a team now!
> Anyway, please take a look at it,
> folks -- we worked pretty hard on creative content,
> it would be a shame to see it collapse for lack
> of interested programmers!
Yes - it *LOOKS* great.
Just a thought - if you are finding it hard to
recruit people - bear in mind that quite a large
proportion of your potential programming team
members will be college age males (sorry - that's
a fact of life). They are unlikely to go for the
somewhat 'girly' image of the Light Princess.
Why not plan a PARALLEL set of artwork - to use
the same game engine - that would run a story
similar to the ultra-trendy Japanese Anime' stuff?
I would have thought that sort of stuff would
fit the same story-telling-with-user-direction
software - but would have more geek-appeal.
Not that I'm telling you to abandon the kids story...
just make it so that both needs are attacked at
the same time.
Steve Baker HomeEmail: <firstname.lastname@example.org>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org