Re: [pygame] Cross-References

["Patrick Mullen" <saluk64007@xxxxxxxxx>]

Yeah, this is a problem that I think all programmers run into at one point or another, where the beast they've created gets to be almost unmanageble, because you can't see where each piece fits into the whole thing, and it can be hard to add new functions to your code, because there are either a lot of places where you could try and fit it; or worse, a lot of places where you have to actually integrate that code.  Planning out an interface can be good, but it's easy to overdesign things as well.  In the past I have done this, where I have a class for every little thing, many sub-sub classes, and even multiclassing.  Ever since pyweek, when my goal was to get as much working code as possible, my philosophy has shifted slightly.  

When I was working on a platformer, my first big project in pygame (currently on hold, go figure) I definately designed it from an engine/framework standpoint rather than from a game standpoint.  I was building this awesome huge thing that would make it "easy" to make whatever kind of game I wanted.  But I accomplished more during that week of pygame than I ever did with the platformer.  Instead of building classes for everything, I had a few smart classes, and a lot of global functions to handle everything.  In the end, even though it felt like I was crappy code, it all works very nicely, gets the job done, and isn't even that ugly.  Now, in my current projects, I am taking a more utilitarian approach to my coding.  If a class makes sense, I use that, if an event system fits, I'll use that; if a global function will be the simplest method for a task, then why complicate things?  If you are careful, you can get by with underdesigning things if you leave room for refactoring. 

I don't know which method is best, but I found that when I was working on the "engine" I spent nearly all of my time making the engine parts better, rather than making a game.  I ended up with a halfway decent tile/map editor, and no game.  My multiplayer game on the other hand (not pygame, but it's applicable), is quite far along, and a joy to work with and add new features to boot!  

Now I have started to work on a shoot-em-up, we'll see what kind of code design it ends up as.  I haven't done much code yet, I am going to try actually designing most of the game before I code too much, to have a guide to go by.  It will be the first big pygame project I work on since my philosophy shifted, so I am excited to see what happens.  I am probably going to use some mixture of classes and functions, and while the event system really fits the multiplayer game, I will most likely shy away from that since I want it to be as fast and furious as possible.  Not that events are slow, but it just feels more natural for fast games to be lower level.  I think I will decouple the ai from the sprites so that it is easy to have large ai groups that move together, and I need to think long and hard about how to handle parents/children - in order to do those big awesome bosses those games usually have, as well as show all the various upgrades on your ship.  So probably some frankenstein combo of functions that handle a lot of objects to avoid many function calls, and lots of data for the objects themselves in classes.

One thing I'm not sure how I am going to tackle, are the cool paths that enemies move along.  Should I use some sort of b-splines, or should I come up with a simplified scripting language for enemies etc.  And bosses are going to be interesting.

Anyway, I think that as long as you keep in mind places where you may want to add things, you can keep code modular without overdesigning everything.  Choose a pattern that fits the project, and spend at least as much time working on the "game" side of things as the engine, unless you have a team and everyone can specialize on one thing.  Of course team projects have whole other issues.  Just my 2 cents.