Re: [pygame] Working on Retro 80s Game SDK, Looking for general support

["Patrick Mullen" <saluk64007@xxxxxxxxx>]

On Tue, Jan 6, 2009 at 3:39 PM, Casey Duncan <casey@xxxxxxxxxxx> wrote:
> On piece of advice I have is to create actual games with the system as early
> as possible, especially before the apis and features have completely
> solidified. It's very helpful to point out awkward or missing parts of the
> system.
>
> -Casey

Seconded!  You should develop 2 or 3 test games (each test game should have some
variety to each other) as you develop the system.  When you get stuck
on a test game,
you know what needs to be added, and because you have the other test
games you have
an idea of how to add the new feature without breaking them.

Also, automated testing is really important when building a framework.
 I had to throw
out my own framework and start over because the code was bad enough it would
have taken too much time to fix all of the problems, and I had no
tests to verify
that my changes weren't breaking things.  Every fix I did broke
something else that I
didn't know about.  Now that I have a huge test suite, I am more
flexible in adding
new features or subtly changing the code.

Your library sounds like a great idea, and seems fairly complete so
far.  The hard
things are to come though.  Editors and online especially are quite
difficult if they
haven't been a part of your design already.  Editors tend to need the
engine to be
structured a certain way, unless you want to work hard at making the editor very
smart.  Although you might have already been structuring things with
this in mind.
The same goes for multiplayer.  It's very difficult to convert a
system where everything
knows about everything and stays in sync for free, to a multiple machine
syncronizable simulation.  Come to think of it, that is difficult even
if you start from there :)

By the way:
>> * Support for tracked music in formats like
pygame already supports tracked formats.  I can't remember which
exactly, but I'm pretty sure xm,
it, and mod work.
>> * Implementation of critical modules in C to improve speed.
Probably won't be necessary.  Best way to speed up a pygame game is to
use pyopengl, which
kind of throws your design for a loop.  No pygame.draw or surfaces for
one thing.

Good luck, I love projects like this.  I'd help if I wasn't bogged
down with my own :)