I'm not entirely certain that this thread should go here, but it does seem to be related to design issues. I'm nearing completion of the engine half of my game project. I've created a general-purpose 2D sprite engine with a variety of features that I'll need for the actual game. However, one of the things I want to be able to do is release the engine with the game (that is, make them separate components) so that other people can modify the game content or make their own games using the engine. With that in mind, I made a few design choices, such as: fully scriptable game objects using Python easy to read plaintext data files generic engine Now I am faced with a problem: the engine, as it stands, is very generic. It's primarily a datadump and a message sender (user -> sprite and sprite -> sprite). Collision detection basically tells each sprite what they hit, what direction it was moving in, and what side the collision came from. There's no physics, no support for objects like walls or platforms, not even really the concept of a "player" (some sprites may accept keyboard input, and one of those "sprites" will be the camera; otherwise, no player per se). This makes the engine incredibly flexible in terms of what it is capable of doing, but it puts a lot of work on the shoulders of the content creator. To actually make a game, you need to write Python scripts for each object that determine how they react to objects (this includes things like backing off from permanent barriers so sprites don't get stuck, as well as the entire physics problem). This seems, to me, like an inelegant solution that will lead to a lot of duplication of work, assuming anybody ever tries to use my game engine. I'd like to find a way to cover that for people without reducing the generality of the engine. So far, the best idea I've come up with is to make a set of generic scripts that describe common game objects. For example, the "wall" object would just sit in space and never react to anything. A "simple moving sprite" object would have some basic precoded movement, and would react properly to collisions with wall objects. A "realistic sprite" object would be subject to gravity, friction, and so on, as well as doing everything that the "simple moving sprite" did. The idea here is that these scripts would serve as templates; you'd never actually see them running on their own in the game, but the content creator could use them as jumping-off points for their own game objects. Does this sound like a reasonable solution? Do you have any better ideas?

I like your idea of providing some generic 'template' scripts, and was in fact intending to suggest it before I read that you'd already thought of it.

One possible suggestion though, would be to put some of the basic physics in it's own script rather than having reactions to it in the sprite's scripts - why have them write gravity handling code into each sprite, rather than have a single 'gravity' script which effects all sprites? As gravity acts on a number of variables (depending on how complex you make your physics), giving different sprites different properties could still make them act different to each other.