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

[The Music Guy <musicguy@xxxxxxxxxxxx>]

On Jan 6, 6:10 pm, "Patrick Mullen" <saluk64...@xxxxxxxxx> wrote:
> On Tue, Jan 6, 2009 at 3:39 PM, Casey Duncan <ca...@xxxxxxxxxxx> wrote:
>
> 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.

Automated testing? I'm not really familiar with that. It sounds like a
must, though; how would I go about this?

> Your library sounds like a great idea, and seems fairly complete so far.  The hard
> things are to come though.

It has come far, but its nowhere near what I want it to be yet.
There's definitely a lot left.

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

At present, the file formats that editors will be using are all XML-
based. Loading is fairly straightforward using lxml, but saving has
presented some difficulties. I'm still trying to decide how much data
needs to be stored in objects so that they can be properly saved to
XML.

Generally, though, I am trying to make sure that the engine works in a
way that will allow XML to work. With that much settled, the editors
shouldn't be too difficult. As soon as I finish the menu module I can
begin work on the image/animation editor, then I'll be able to make
better judgments.

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

Game Maker used an array which was constantly synced between two
machines as well as a message queue. That's going to be my starting
point. That's still a ways off, though.

> pygame already supports tracked formats.  I can't remember which
> exactly, but I'm pretty sure xm, it, and mod work

I honestly didn't know that...man, that makes things simpler!

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

Well...three things:

1.) I don't think I mentioned this before, but the sdk is already
designed in such a way that the user needn't use any surfaces
explicitly; use of surfaces is, for the most part, hidden behind the
extended Image classes.
2.) I really have no idea how to use ogl, but I have a feeling
implementing modules in C will be much faster than using ogl if I use
an in-between language like Pyrex or Cython. Besides, depending on ogl
will likely prevent the engine from working very well on older
systems.
3.) Most of the things I wanted to code in C (or Cython, as will
probably be the case) would not benefit from the use of ogl; for
example, the event manager, and the physics engine (including
collision detection).

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

Thanks. I was afraid people were going to tell me not to bother with
something like this since there are already several projects that
resemble this one. I just hope I can take it to the next level before
school starts up again--only two short weeks left!