Pygame: Improved Sprite and Scene system
Short description: A re-design of the sprites module, creating a generalized code base to make it more flexible, and a new scene/director system to encapsulate sprites into distinct game sections and control their workflow.
Additional info: http://j.mp/pygame-n0nick
Pygame Summer of Code application:
Improved Sprite and Scene system
Apr 4th, 2012
Other contact information
Phone number: +972 (52) 8343339
IRC handle (freenode): n0nick
Skype username: sagiemaoz
Alternative email address: firstname.lastname@example.org
Time zone: GMT +0200 (Israel)
Preferred language: English or Hebrew
I am a Computer Science and Linguistics B.Sc. student in Tel Aviv, Israel, part of a pilot Computational Linguistics program, expected to graduate in 2013.
I have been programming professionally for 5 years before attending TAU, mostly developing web-based software and applications. I currently work for Waze Mobile as a part-time developer and consultant.
Google Summer of Code is my main plan for the summer.
Unfortunately, as the GSoC dates do not correspond to the semester schedule here, I will have to invest some time to studying throughout the development period;
My regular studying schedule lasts until June 22nd, meaning I will have to devote my mornings to school and homework.
Finals period is from June 27th to July 24th.
Particularly, I have five final exams scheduled on : June 27th, July 3rd, July 15th, July 22nd and July 24th.
I will have to focus on each of these for a couple of days.
I realize that this schedule does not leave too much spare time for me to be fully involved with the project.
However, as I am eager to fulfill my obligations, I am prepared to be very flexible with my time and work hard nights and weekends to make up for the lost time.
I could also agree to add an additional week of work after the standard coding time frame.
My place of work is aware of my applications and will make required accommodations to fit the schedule.
I am confident that I will have more than 35 hours a week to develop for Pygame.
I have been programming for more than 10 years in one way or another.
I have also studied, as part of my Computer Science courses, working and developing in PLT Scheme, Java and C.
In addition, I maintain a few of my own small open-source projects, also mostly revolving around web development.
I have participated in last year’s Google Summer of Code for the Apertium project, implementing a new translation language pair, translating from Maltese to Hebrew. This project revolved around writing custom Python tools to process mass amount of corpus texts and generate valid XML for the translation engine.
It was a very positive experience to be part of Summer of Code 2011 and work on such a project. Being in direct contact with project contributors, as well as working on things of different nature than what I’m used to, were very enlightening and enjoyable.
I have heard of Pygame a few times in the past and have actually started taking the tutorials given in the book Making Games with Python & Pygame. I have not gone so far in the examples and did not get to write my own game, although I’m very excited about game development in general and about using Python and Pygame in particular.
I have been talking to fellow contributors on the IRC channel for the last few days and have learnt a few details about the code and the project’s development cycle. I’ve also downloaded the code and browsed through it to learn about the general structure and to understand my project goals.
The project consists of two parts: (1) redesigning the sprite models and (2) implementing a basic scene/state system support.
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.
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),
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.
A stable set of classes implementing the Director/Scene workflow.
Documentation explaining the internal design and the way to use it.
The following is a roughly drafted work plan, based on my estimations of the amount of research needed to be done, and of course of the actual coding.
Due to the mentioned scheduling conflicts with my studies, it is possible that the first half of the timeline needs to be spaced out more, pushing some of the work towards the second half.
Community Bonding Period
- Setting up a working development environment.
- Studying the Pygame source more thoroughly.
- Specifically studying the current sprite classes.
- Posting to contributors’ mailing list, calling for suggestions for design concepts, possible new features and useful research resources.
- Researching the practice of handling sprites and sprite groups in other open-source 2D sprite-based game engines.
- Consulting with mentors and the community regarding a suitable design decision.
- Producing a report paper, reviewing the researched practices and specifying the goals to implement.
- Writing tests for the new sprite work, maintaining as much legacy support for the older interface as possible.
- Writing the classes for Sprite and Sprite Group according to the design decisions made.
- Implementing old functionality in a generic level.
- Deciding on a set of new features to work into the sprites system, from the list above and suggestions from the community.
- Implementing the new features of the sprites module.
- Writing documentation for the sprites work.
- Studying implementations of a scene/director workflow in other open-source systems, researching different approaches to it.
- Consulting with mentors and the community in regards to the approach to select for the new system.
- Implementing a scene/director system based on the chosen design.
- Documenting the scenes system and the way to use it.
Pygame community feedback
The ideas for this project were discussed in the #pygame IRC channel with contributors such as TheSheep, masquerade and illume.
Suggestions for specific features to add, as well as links to resources to study (e.g., implementations in other projects, or references to pygame’s API) were noted and used in the writing of this proposal.
The proposal was also sent to the pygame-users mailing list, and I’m waiting for feedback and suggestions to adopt to the project.