[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [kidsgames] Re: Light Princess -- Where are those programmers?



Steve Baker wrote:
> 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!

Oh, of course -- I'm summarixing a bit, you understand.
Unfortunately, right now, I don't really have any "tame"
programmers (as you put it later in your message).  I
just have a few "wild" ones who are casually interested in
this game as well as their own.  My point in posting was
obviously to raise some more interest in the project and
to pique some responses from people (and I appreciate
yours, BTW).  I think the real problem is I need to
look further afield to find people willing to work 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?

It could be that I am indeed too shy.  I am always aware
that people are working on their own agendas or "out of
the goodness of their hearts" and that I certainly have
no ability (or desire, really) to force my way here.  I
don't want to drive off interest by haranguing everybody.

> > http://light-princess.sourceforge.net/
> It's a VERY nice site!
Why thank you!  It's still a bit inconsistent, but I'm
trying to keep it usable.

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

They sound hard, of course.  But although there's no
source code available, I was able to find pretty detailed
design documents from Carnegie Mellon.  The actual
implementation was surprisingly simple stuff.  It was
originally written in a combination of Lisp & C.  Of
course, Python pretty much _is_ a combination of Lisp & C,
stylistically, so I feel the implementation should
translate well.  (e.g. the Active Planning Tree is
obviously a hierarchical Python list, plans and goals
are fairly simple classes, and so on).

"Emotions" in the Oz architecture are basically just
mnemonically named counters -- they acquire practical
meaning by the plans that are associated with them.
I was working on a more "elegant" version of this
for awhile, but I'm starting to think the Oz projects'
method is probably more pragmatic.

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

Obviously the character agents should probably come in
fairly late.  The game "world" engine is to be based on
an already working interactive fiction engine.  I don't
have that specified further, because I don't necessarily
know all the internal workings of it yet, but the code
is supposed to run as is.

The animation and presentation part is more complex, of
course.  But it will be based fairly closely on the
underlying libraries.  The main new thing is providing
the Cel/Layers abstraction and converting 3D room info
into a 2D presentation.

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

Well, I am actually a competent programmer.  No
individual piece of this is outside my abilities,
really -- it's just WAY too many pieces!  However,
I suspect that my design is not necessarily the
one other developers will prefer.  My attitude is
that "he who writes it rules it."

That's one reason why this design has clear
internal interfaces.  The idea is that we
can negotiate over the interfaces and what kind
of services each component has to provide, but
the people who write the parts should have
discretion to design it how they see fit.
I don't see how else people would be willing
to work.  If I provide internal design info,
it's meant to be a suggestion to get people
started.

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

Oh yeah, testbedding and workarounds.  That's
definitely the way to go.  Rapid prototyping
cycles for each piece.  Otherwise, it's never
going to work.

> Start from the places where you get interesting (preferably
> visual/audio) outputs so that there is overtly visible
> progress being made.

Well, you can see we've been following that advice
on the creative development as well.

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

Yes it's a good place to start.  That's what I've been
tinkering with so far.  

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

As I said above, PUB is an existing IF engine --
that's just a problem of learning the existing design
(and documenting it better), and figuring out how best
to integrate it with the (as yet unwritten)
presentation software.  Basically I need somebody to test
it out and play with it some.  The author was actually
pretty good about commenting the code, BTW, from what
I've seen.  It's just that the comments haven't been
converted to documentation.  I looked for some automatic
tools to do that, but they all require that the comments
be moved around or converted to doc strings in order to
get captured.  An easy job, but tedious.  I'm going to
try to get PUB moved into the CVS on Source Forge this
week, so folks can see for themselves.

Well thanks for all your comments!


-- 
Terry Hancock
hancock@earthlink.net
-
kidsgames@smluc.org  -- To get off this list send "unsubscribe kidsgames"
in the body of a message to majordomo@smluc.org