Summer of Code/Application/2007

Draft Outline

TODO: Answer the questions/points listed on http://code.google.com/support/bin/answer.py?answer=60303&topic=10727

Introduction

• scummvm description and purpose (Q1)
• scummvm hierachy

proper team structure, subteams for engines, ports, infrastructure.

• scummvm in facts.

LoC, # devs (active & all time), # ports, downloads (Q1)

Draft Intro

ScummVM is a program which allows users to run certain commercial graphical point-and-click adventure games (e.g. Monkey Island, Simon the Sorcerer, Space Quest, and many more), provided you already own their data files. To this end, the team works by either reverse engineering game executables (usually with the permission of creators of the game), or by using the original source code of the games (provided by the creators of the games, after negotiations with the team). The number of engines is constantly growing thanks to a very agile and diversified development team.

One of the corner stones of ScummVM's success is its extreme portability. Besides running on all main stream desktop environments, be it Windows, Mac OS X or most Unix variants (Linux, *BSD, Solaris, ...), it works on game consoles (Nintendo DS, PlayStation 2, PlayStation Portable and more), smart phones and PDAs (WinCE, PalmOS or Symbian based), and even on many not-so-mainstream systems (like BeOS, AmigaOS or OS/2).

This high portability is possible thanks to the flexible and modular structure of the ScummVM internals. Everything can be grouped into roughly three categories:

1. Backends (responsible for support of specific target devices, like PalmOS or WinCE, etc.)
2. Engines (sometimes dubbed front ends) containing the actual game specific code
3. Infrastructure code, providing portable access to audio (including MIDI), graphics, user input, data access , a custom graphical user interface, and more

The structure of the team reflects this structure, in so far as developers can be roughly grouped into the following categories (with some people being in more than one, or being multiple times in a single category):

• Porters -- responsible for a specific port
• Engine authors -- responsible for a specific game engine (includes being repsonsible for handling users bug reports, i.e. support)
• Infrastructure development -- e.g. people working on MIDI code, on the built-in custom GUI, etc.
• Packagers -- not all ports require dedicated backends (e.g. we have on built around the SDL library, which itself is highly portable), but they still require somebody to test and compile them, which is where porters come in
• Documentation / web site management
• Project leads -- we currently have three, and they all are also represented in one of the above categories, but besides this organize and coordinate things, make decisions, solve disputes etc. (as one would expect)

This structure enables us to be highly productive in a team of about 30 currently active developers (out of an all time pool of well over 60), who work together on a codebase exceeding 600,000 LOC. In addition we have many non-developer contributors, and a huge and highly active community. We are among the most active projects hosted on sourceforge.net -- well over 100,000 monthly downloads and ~9 millions project web hits per month speak for themselves, we think.

SoC Participation Application

• participation statement. (Q3,4)
• - what will scummvm gain? (Q2)

new blood (devs); enhance and/or optimize codebase; resolve long standing TODOs;

• - what will students gain (Q2)

participation in leading sf.net project; interaction with a large team of devs (learn working in a large team); introduction to game development tactics for code (optimization etc); emulation (VM) principles; coding portable code; observe/use/integrate into leading OO infrastructure (osystem); produced code will be readily runnable across a wide spectrum of platforms;

• how to keep students interested (Q16,17)

weed out the applicants. we need entusiastic students, as we ourselves are passionate about our work. game developement is a very rewarding (in a spiritual manner :-) ) field of coding. lively and large team interacting though mailing lists and irc. makes turnaround time between a question raised and possible answers very small.

Mentors

• Short bios for _sev, Fingolfin, Jubanka. (Q12,13)

In particular, we do not need a "normal" CV, we need something to support we can mentor students, eg. great familiarity with code etc, students (if applicable), actively helping new devs. trying to answer (Q13) implicitly.

• nail (Q13) explicitly in the concluding paragraph

briefly reiterate each mentor's expertise.

When things go wrong

• Students. (Q14)

Communication breakdown seldom occurs abruptly. Usually, a student losing interest will keep an ever lowering profile. The mentors will regularly query for status (at least once a week). When the student is in trouble, the mentros will go to lengths to support the student actively. The tasks will be planned ahead by the mentor, with informal interim reports (maybe) and milestones. Of course there may be RL problems prohibiting the continuation of the task (unpredictable).

• Mentors. (Q15)

There may be unforeseen difficulties for a mentor, leading to unavailability for some periods of time. The students can always turn to the very active irc channel for both general and specific inquiries. Mentors will update their status between them, so no students get left alone if a mentor drops out.

Data

• table for Q5,6,7,8,9,11,12

License:	GPL
Ideas page:	OpenTasks

Student application template

• TBD