|
-----Original Message-----
Hello every one:
I have proposed to work in the Pygame project in the google summer of code 2008. Fortunately, my application is accepted. My aim is to develop a 2D real-time physics engine for Pygame. The module will be integrated with Pygame seamlessly.
Since PyGame is mainly for developing 2D games, this physics engine will aim
for the simulation of 2D rigid body dynamics. The functions of the physics
engine include: I will implement the core functions in C. If you have any advice or idea about this application, please give it to me. I'd like to make this one as good as I can with all you people's help of this community, thank you very much. Zhang Fan
Let me second the recommendation to make the first part of the project be building an easy to use bridge to box2d or chipmunk. If nothing else, the effort of interfacing with an existing library will illustrate far better than any other method which parts could be smoothed over in writing your own physics library. The other benefit here, is that if we’ve got a good API, then it’s fairly straightforward for other people to come along and build interfaces to different physics engines, say a 2D constrained ODE. As with all things software related there’s a set of tradeoffs inherent in physics engines (notably accuracy <> speed), and no one solution is ideal for every game. I think that’s one of the reasons the sprite module works well, as it it’s core it’s a fairly simple set of interfaces that are easy to extend for what you need.
As a bonus, box2d just released a new version last month, with quite a few new features. Chipmunk might be easier though, given that it was built with ruby integration in mind. You might also consider that pyglet would probably like a 2d physics library too, and might be interested in working with whatever you develop.
I mention this, as it sounds from your tone that you’d be stressing ease of use and accuracy (i.e. stability) over simulation speed, which is exactly the opposite set of tradeoffs I’m looking for in my next game project.
When you do go forward with building your physics engine, one thing to keep in mind would be to pick a feature that’s not present in the exisitng physics engines, and build a good implementation of that to differentiate yourself from the other projects that are out there. Easy integration with pygame might be that feature, though I’m not convinced. J
On a similar note, I’d really like to see the vector library/interface that you write be separate from the physics library, as that would be useful for many other things than working with a physics simulation. It seems like a lot of people end up rolling their own vector libraries, and that’s one of the stupid easy things to make faster in C. I’d love to see a vector interface as easy to use and full featured as the rect interface we have now. The tricky optimization bit here would be a clean way to group a large number of vector operations for speed, much like the numpy hacks that people use today. --------- John Krukoff helot@xxxxxxxxxxx
|