On, Tue Apr 29, 2008, Noah Kantrowitz wrote: > > On Apr 28, 2008, at 9:47 PM, 帆 张 wrote: >> >> >> Noah Kantrowitz <kantrn@xxxxxxx> 写道： >> The problem with chipmunk, and by extension box2d, is what exactly? I >> would rather see the existing bindings improved than someone try >> writing a new engine. Perhaps make a library that provides a mixin to >> easily enable binding pygame Sprite objects to physics objects. >> >> --Noah >> >> Thank you for your good advice. >> >> Fist I'd like to tell the diffiences between our physics engine and >> Chipmunk: my engine will be integrated with Pygame directly which means it >> offers more user-friendly interfaces. for example, a user who use pygame >> as a 2D graphics engine and pymunk as 2D physics engine, he or she must >> write codes for managing both rendering state sand physics states of game >> objects, just like you said before "binding between physics object and >> sprite", by contrast, our engine in Pygame will manage them all >> automaticly > > So you aren't writing a library for people to use, you are writing a game > engine. This is fine, but you should understand the distinction and know > that homebrew game engines are rarely useful to anyone but the author. Depending on the design it does not necessarily has to be an own game engine with a specific purpose. Designing the physics API as standalone system first, leaving the sprite module aside, let's you easily use it wherever and however needed. The object types can be easily plugged into own, existing class code and an PhysGroup.update() method updates theirs states. So using e.g. a layout similar to the Sprite system let's you easily manage physics object lists, apply single world physics and all that stuff. Bindings to the sprite module can be done more or less easily via a new Sprite type that inherits from the physics objects as well. The same for the sprite groups let's you easily do a single update() run, which takes care of both, updating the physics and sprite internals. This allows users to use the physics as standalone system for their own code or wrapped via the sprite module. As you surely know, the sprite module is not applicable to any scenario, too and several people tend to write their own sprite system instead using pygame's. [...] >> Indeed, Writing a new engine maybe sound like a little ambitious and >> useless. I have ever thought about just to wrap a mature physics library >> in Python like Box2D engine and improve it by writing a layer for binding >> and so on, but I'm a fan of physics development, I decide to make it on my >> own. I know It's hard for me to make a mature one in just three months, > > You are wrong about this. It isn't hard. It is impossible. You will > undoubtedly learn much doing this, however the net benefit to the community > will be zero. This depends on what should be accomplished. Implementing mass, moment and angles including world influences and the interaction with other objects via a simple collision detection approach is surely capable. >> but I want to give Pygame users more choices in physics module with pygame >> and I will improve it with other people in the community for making it >> better, I hope it won't end after google SOC. And I'm dedicating myself >> into this project. >> > > Many people say that, the numbers say otherwise. Its nothing personal but I > think the GSoC project does more harm than good to the FOSS community, as > there are now several years of unmaintained and generally shoddy code in > various corners that no one knows what to do with. The publicity and $ are > nice, but I think the community loses in the end. Which is usually caused by the community as well. Think of Alex' pygame-ctypes API, no one really used at the beginning. The feedback was very low, which was and is a pity and was surely pretty disappointing for him. And now there are coming more and more questions regarding it while we have to say: sorry, currently unmaintained and not stable enough. Regards Marcus
Attachment:
pgpanPvXqPYAH.pgp
Description: PGP signature