Pygame Summer of Code application:
Improved Sprite and Scene system

Apr 4th, 2012

Sagie Maoz

 

Name

Sagie Maoz

 

E-mail address

sagie@maoz.info

 

Other contact information

 

• Phone number: +972 (52) 8343339

• IRC handle (freenode): n0nick

• Jabber: sagiem@gmail.com

• Skype username: sagiemaoz

• Alternative email address: n0nick@php.net

• Time zone: GMT +0200 (Israel)

• Preferred language: English or Hebrew

 

About me

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.



Time commitment

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.

 

Programming Experience

I have been programming for more than 10 years in one way or another.

As mentioned, In the past 6 years I have worked as a professional developer in various technology companies, mostly in the area of Internet and Web applications, using open-source technologies and languages such as Javascript, PHP, Ruby and Ruby on Rails, Python and Django, Java and others.

I have also studied, as part of my Computer Science courses, working and developing in PLT Scheme, Java and C.

 

I am a frequent contributor to open-source projects, both personally and as part of my job. I have contributed to large-scale projects such as PHP, Mozilla and Wordpress, and to many smaller projects such as Rails gems and various Javascript plugins and extensions.

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.

 

Pygame Experience

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.

 

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.

 



Work plan

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.

Weeks 1-2

• 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.

Weeks 3-4

• 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.

Weeks 5-6

• 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.

Weeks 7-8

• Implementing the new features of the sprites module.
• Writing documentation for the sprites work.

 Weeks 9-10

• 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.

 Weeks 11-12

• Implementing a scene/director system based on the chosen design.
• Documenting the scenes system and the way to use it.

 

Project complete.

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.

Thanks!