Hello, n0nick (Sagie Maoz) tried to post to the mailing list, but for some reason the mails didn't make it through.
He wanted feedback on the GSOC proposal: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/n0nick/28002 What do you think? I pasted the project description part below: ------------- Project description The project consists of two parts: (1) redesigning the sprite models and (2) implementing a basic scene/state system support. Sprites work The parts of Pygame that currently handle the Sprite objects, while very fundamental for any use of the library, are reportedly not as generic and as feature-full as they should be. The project would revolve around redesigning and rewriting the core code of the Sprite class to fit the needs described by the community, and to add some system-wide functionality. Research is required in order to decide on an optimal design pattern for sprites and sprite groups, that would make use of inheritance and would result in a solid generalized base set of classes. This design should also allow users the flexibility of extending and customizing sprites behavior. Deliverables: - The sprite and sprite group classes rewritten in a more generalized manner. - Features that are currently only implemented in some types of sprites (i.e. grouping and collision detecting) rewritten as generic features, provided for all sprite types. - New general features for sprites that were (and will be) suggested by the community; - Easier positioning methods (ability to use a position tuple instead of rects), - Anchor points, - An improved layering system, - Smarter dirty rendering (detecting changes in sprites to automatically mark them as dirty), - Aggregated sprites object implementing the sprite interface, - Other features suggested and found in research. Scene and state system work Pygame currently does not offer any higher level entity that organizes visual objects by game state and logic. This could be done by implementing a Scene module that would represent a distinct section of the game. As such, it would contain all related sprites encapsulated in this section, and would allow running common actions on them, such as rendering and logic updating (through a Composite or similar pattern). A scene would also define some events, such as “scene start” and “scene end”. These events would be fired by a new external Director module that would define the game workflow and the relation between scenes. Research is needed here to decide on a particular design that would be both simple to grasp and maintain, and also memory efficient. Deliverables: - A stable set of classes implementing the Director/Scene workflow. - Documentation explaining the internal design and the way to use it.
