[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] The introduction of my Google Summer Code Project



Hi Noah:
      Thank you for giving such comments and tips in detail. I fully understand what you said. I've made some games before and I know the problems face to me. you are right, scope controlling is very important, making a general engine is impossible to me. you can see the plan of current figures is basic, it just targets on collision detecting, control of objects' moving, and pygame object wraping. I just want to make it fast and lightweight and very simple to use(just like pygame :-> )   I will design the APIs carefully with helps in the community. 
Your advices about testing is very good, I will do unit tests to test all functions and modules.
     And I won't make it like all by myself, I'd like to stand on giant's shoulder. e.g. I will use a mature full optimized vector math library, and other mature open source library will be used.
 
>> ... however the net benefit to the community will be zero....
:-),then let me make 0 to be 0.1
 
Regard
 
Zhang Fan

Noah Kantrowitz <kantrn@xxxxxxx> 写道:

On Apr 28, 2008, at 9:47 PM, 帆 张 wrote:
>
>
> Noah Kantrowitz 写道:
> 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


雅虎邮箱,您的终生邮箱!