[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [pygame] The introduction of my Google Summer Code Project
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. Designing a good engine and API is among the hardest tasks
in game development. I have tried several times and am not embarrassed
to say that all were fairly lousy. I still learned a great deal from
each attempt, so I wouldn't say its wrong to try. Just be aware of the
task in front of you. Some small tips I can give:
* Control scope. _Do not_ try to make a generic engine. I would say
stick to something like "top-down car-based games" or "side-view
platform games" or similar.
* Design the API in full, then try to write a mock game in it.
* Test everything as frequently as possible. Testing game code is
still tricky, but use unit tests to see that the right code paths are
being hit.
, and I want to offer some more useful special interfaces for game
development like rigid-doll system and explosion system in future.
This engine is just a part of pygame which means it is integrated
with pygame inside.
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.
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.
--Noah