Re: Light Princess -- Where are those programmers?

[Erik <br0ke@math.smsu.edu>]

> 
> Terry Hancock wrote:

<snip>

> Managing programmers is known to be a hard thing.

understatement, methinks :)
 
> > 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.
>  

the programmers have caught a glimpse of software engineering.
Just about ny non-hack program will require a specification or
will simply not get finished. Gotta set concrete goals :)

> > 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 think the best method is to sit down with the developers for
specification meetings and evolve the specification instead of
dictating it. Another thing to look at is the difference between
a general specification that describes all the nasty ugly specifics
of the game (but doesn't say anything about code structure,
programming language, etc), and the software specification. If
you don't have a document that describes the project completely,
you may contemplate creating one just to give everyone an
overview of the final product. 

That being said, I'd suggest you look into setting up realtime
meetings using something like IRC so you can be in immediate
communication and do all the argueing, changing, etc and try to
get a real evolution of the system spec.

> > 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.
> 

Be glad your developers understand that they're part of a team. :)
Describe to them what they need to do, try not to tell them how to
do it. It may even be useful to fully and clearly specify the needs
the game has of the engine and let the programmers design the
software architecture?

> >  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.

<snip>

mebbe try to involve yourself as the ambassador of the rest of the
project to the programming team? They'll probably knock out their
own pecking order once ya get things moving? *shrug*

>  
> > 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?

yeah, communication is important. Sounds to me like they 
understand it isn't their show, and they really want to contribute.
Get some dialog and with them (no working 'for' should happen
methinks)


> It's a VERY nice site!

yes, frightening display of conviction and effort

> 
> 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!)

yeah, some of it might be better described to be less imposing.
List out sample heuristic rules, fuzzy variables, etc.

> 
> 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.

yeah, I agree, don't try to dictate specifics. I say work with
your team and develope something better than any one
person could do alone.

<snip blah balh blah some stuff that basically boils down to
defining milestones>

milestones are important. They give you places to stop and
look back to make sure you're doing things right. They give
you a lot of small deadlines so you can keep the project
moving. They give you a big sense of accomplishment when
you hit them. 

> 
> Each one of those steps seems bearable - but the entire
> package seems like a massive undertaking.  Your programmers
> are probably feeling overwhelmed.

overwhelmed sucks :)

<snip>

> 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!
> 

I'd try to lay out all the milestones up front and try
to define them as well as possible (maybe create a
milestone graph instead of line if you have ideas that
might be decided down the road). Don't set any
milestones for the programmers without their input,
you may misjudge and make the milestone too difficult.

<snip>

> 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.
> 

That's a really good idea on several levels. It widens
the developer base by including alternative interests.
It also gives you a parallel application to test the
versatility of your engine as it's developed, giving
the engine a better chance of being usable for other
projects.

<snip>

The diagrams on the webpage seem to present a hybrid
representation of a data flow-chart and a structural
hierarchy diagram. It might be useful to present a few
diagrams to help make the overall structure more
comprehendable. My week infantile mind has to work
too much to grok the structure to be happy :)

Why, yes, I do realize this was a big waste of
bandwidth and didn't help anyone :) I just like sending
big emails.

        -Erik <erik@smluc.org> [http://math.smsu.edu/~br0ke]

The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep
Refrigerated.

---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.dk
For additional commands, e-mail: linuxgames-help@sunsite.dk