Difference between revisions of "Summer of Code/Application/2007"

From ScummVM :: Wiki
Jump to navigation Jump to search
 
(17 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== The Application ==
== Introduction & overview ==


=== Introduction & overview ===
This is the application of the [http://www.scummvm.org ScummVM] project for the [http://code.google.com/soc Google Summer of Code]. Let's start with a quick overview of the facts before turning to the more elaborate parts of this document.
 
This is the application of the [http://www.scummvm.org ScummVM] project for the [http://code.google.com/soc Google Summer of Code]. Let's start with a quick overviw of the facts before turning to the more elaborate parts of this document


{| cellpadding="3"
{| cellpadding="3"
Line 30: Line 28:
|}
|}


=== About ScummVM ===
== About ScummVM ==


The ScummVM project aims to allow users to run many old (and not so old) 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.
The ScummVM project aims to allow users to run on modern hardware a variety of commercially available graphical point-and-click adventure games including Monkey Island, Simon the Sorcerer, Space Quest, and many more. To this end, ScummVM features a complete reimplementation of each supported game engine (Virtual Machine - VM) in a structured fashion using the C++ language. The development 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. 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).
The VM approach followed by ScummVM results in efficient code, which has been ported to numerous Operating Systems. Besides running on all mainstream desktop environments, namely Windows, Mac OS X and most Unix variants (Linux, *BSD, Solaris, ...), ScummVM works on popular 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 made possible by the flexible and modular structure of the ScummVM internals, which more or less falls into the following three categories:  
ScummVM's high portability is a direct consequence of the flexible and modular structure of its architecture, which can be roughly divided into the following three major categories:  
# Backends (responsible for support of specific target devices, like PalmOS or WinCE, etc.)
# Backends, which are responsible for supporting specific target devices, like PalmOS or WinCE,
# Engines (sometimes dubbed front ends) containing the actual game specific code
# Engines, also called front ends internally, contain the actual game specific (VM) code, and
# Infrastructure code, providing portable access to audio (including MIDI), graphics, user input, data access , a custom graphical user interface, and more
# Infrastructure code, which provides easy and portable baseline functionality, such as 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):
The large team of developers is split in groups which focus in different aspects of the architecture, in a manner derived from the above mentioned categorization. The team members are often not strictly confined to their respective group. Developers may assume different roles in several teams. Currently, the developers are split in the following subteams:
* Porters -- responsible for a specific port
* Porters: Responsible for a specific ScummVM port.
* Engine authors -- responsible for a specific game engine (includes being repsonsible for handling users bug reports, i.e. support)
* Engine authors: Responsible for a specific game engine and its associated bug reports (support).
* Infrastructure development -- e.g. people working on MIDI code, on the built-in custom GUI, etc.
* Infrastructure development: Includes for example developers 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
* Packagers: Not all ports require dedicated backends. For example our SDL backend is highly portable, but it still requires somebody to test and compile it. Packagers execute this function.
* Documentation / web site management
* 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)
* Project leads: There are currently three project leads. They all are also represented in one of the above categories, but besides this they organize and coordinate things, make decisions, solve disputes etc.
 
All of this enables us to be highly productive in a team of about 30 currently active developers (out of an all-time pool of over 60), who work together on a codebase exceeding 600,000 lines of code. 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 with well over 100,000 monthly downloads and ~9 million project web hits per month.
 
== What we hope to gain ==
For one thing, we hope to attract new blood: we hope to gain some new active developers via these projects. While we already have several very active contributors, these people are already mostly busy in specific subprojects and tasks. New people mean new ideas, new energy, and new ways of thinking. Therefore, a longer lasting engagement of our student contributors would be our highest hope.
 
Furthermore, all of our developers work on ScummVM in their spare time. But for some tasks, it's most effective if you can spend a certain block of time working on this task exclusively; just what we would get via the SoC.
Hence, we hope to gain some nice shiny new code providing useful new functionality to our users and developers. Even if the authors don't stick around, this will benefit all of the ScummVM community.


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.
Lastly, we also believe that we can learn a lot from this whole event in terms of interaction with prospective new team members, how to motivate students to participate in our projects, and so forth: knowledge that may turn out to be very valuable outside of the SoC, too.


=== What we hope to gain ===
== Our mentors ==
For one thing, we hope to attract new blood -- we hope to gain some new active developers via these projects. While we already have several very active contributors, these are already mostly tied up in specific subprojects and task. New people mean new ideas, new energy, new ways of thinking. So a longer lasting engagement of our student contributors would be our highest hope.
Our mentors were selected as volunteers from the development team who are already intimately familiar with the internals of ScummVM, our coding conventions etc.. All three are familiar with guiding people (in particular, students) through project work effectively (in fact, two of them happen to be lead developers of ScummVM). As such, we are convinced that we are able to guide interested students through the Summer of Code to the net benefit of all involved parties.


Furthermore, all of our developers work on ScummVM in their spare time. But for certain tasks, it's simply best if you can spend a certain time working on this task more or less exclusively -- i.e. just what we would get via the SoC.
== How we will deal with participants 'missing in action' ==
Hence, we hope to gain some nice shiny new code providing useful new functionality to our users and developers. Even if the authors don't stick around will this benefit all of the ScummVM community.
We hope that nobody will disappear, but we plan to take a proactive approach, i.e., we will try to minimize the risk of a loss of communication, but if it happens, we are prepared to deal with it, too.


Lastly, we also believe that we can learn a lot from this whole event in terms of interaction with prospective new team members, how to motivate students to participate in our projects etc., knowledge that may turn out to be very valuable outside of the SoC, too.
For the mentors, the risk is relatively low; two are project leads and are reachable virtually 24/7 (in case of emergencies). We all have exchanged sufficient contact information (including cell phone numbers etc.) to be able to discover our whereabouts etc. Should something really bad happen (like somebody ending up in hospital and hence unable to work, a natural disaster, etc.), we will attempt to shift students to new mentors (among the existing mentors, or drawn from our backup pool of mentors). This will depend on the number of students we have to mentor.


=== Our mentors ===
As for the students, for starters we plan to exchange as much communication data as possible (cell phone numbers, postal addresses etc.). Through a friendly atmosphere we hope to minimize the risk of any student being "afraid" to report problems they might have etc.. On the other hand, we will make it clear that we expect dedicated work of the students and that unannounced/unjustified disappearances will draw consequences, like negative reports or even the failure of the whole project. Still, establishing a positive and friendly connection between student and mentor will be the cornerstone of our efforts in this regard. If the student trusts the mentor and tells him about his fear, uncertainties and problems early on, they can try to find a solution together, possibly with the help of the rest of the team. Also, integrating the students into our community should reduce the likelihood of disappearances further (see also the next section).
Our mentors were selected as volunteers from the development team, who are already intimately familiar with the internals of ScummVM, our coding conventions etc.. All three are familiar with guiding people (in particular, students) through project work effectively (in fact, two of them happen to be lead developers of ScummVM). As such, we are convinced that we are able to guide interested students through the Summer of Code to the net benefit of all involved parties.


=== How we will deal with participants 'missing in action' ===
A common cause (we believe, based on our own experiences as students *g*) is a lack of structure in the assigned work, resp. an inability of the student to make real progress. To avoid this, we will request that students come up with a (realistic) project plan / schedule. The mentors will watch the progress with the students and discuss it with them regularly (at least weekly). We hope to detect potential problems early on this way, thus being able to help the students get around them, to the benefit of all.
TODO Q14 & Q15


=== Integrating students with the community ===
If all fails, though, and a student really vanishes completely, we will have to deal with the consequences, just like with regular projects in a company. Projects *can* fail, after all, no matter how hard you try to avoid it.
TODO Q16 & Q17


=== Student application template ===
== Integrating students with the community ==
Our community uses forums, IRC, a Wiki and our mailing list for a vivid exchange of thoughts all the time. We will urge the students to participate in all of them; especially on IRC can they directly talk to many nice and helpful team and community members. The mentors will introduce the students to the rest of the team (making sure everybody knows who the students are). There are people active in the IRC channel virtually 24/7, thanks to the international nature of the project.
 
We also expect the students to talk to non-mentor team members on a regular basis about parts of ScummVM for which these team members are experts (if these parts happen to be relevant for the student's project). To achieve that, the mentors will specifically introduce them to each other, and will try to encourage them to work together.
 
== Student application template ==
The following was adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines].
The following was adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines].


Line 84: Line 92:
* '''Availability''' - How many hours per week can you spend working on this? What other obligations do you have this summer?
* '''Availability''' - How many hours per week can you spend working on this? What other obligations do you have this summer?
* '''Bio''' - Who are you? What makes you the best person to work on this project?
* '''Bio''' - Who are you? What makes you the best person to work on this project?
== Draft Outline ==
TODO: Answer the questions/points listed on http://code.google.com/support/bin/answer.py?answer=60303&topic=10727
=== Abstract ===
=== 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)
=== 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.
==== Draft ====
This section presents the overall strategy used to prevent students and mentors from dropping out of their tasks.
==== Students ====
There are two main reasons for a student to stop participating in the assigned task:
Loss of interest, and unforeseen difficulties.
There are various causes for the former case, such as:
* The student cannot cope with the technical requirements of the task,
* Communication with the mentor does not fare well, or
* The student is daunted by the current codebase.
It is up to the mentors to identify this case and act.
Through the screening process the mentors will assess the technical skills of the candidate.
Then, if communication breakdown occurs it rarely happens 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 mentors will go to lengths to support the student actively.
The tasks will be planned ahead in conjunction the mentor, with informal interim reports and milestones as applicable.
In the case of disappearing students due to unforeseen difficulties unrelated to the task at hand, there is not much that can be done effectively.
Hopefully, this case will be identified through the frequent student-mentor communication.
==== Mentors ====
Of the two above mentioned cases, only the case of unpredictable circumstances, unrelated to the project, applies to the mentors.
When a mentor anticipates a period of unavailability, the student will be referred to another mentor and the administrator will be notified.
The students can always turn to the very active irc channel for both general and specific inquiries.
Mentors will internally update their status, so no students get left alone if a mentor drops out.

Latest revision as of 11:23, 4 March 2008

Introduction & overview

This is the application of the ScummVM project for the Google Summer of Code. Let's start with a quick overview of the facts before turning to the more elaborate parts of this document.

Project: ScummVM
Participation in prior SoCs: None
Applications for prior SoCs: None
Organization administrator: fingolfin (max AT quendi.de)
Backup administrator: sev (sev.mail AT gmail.com)
Project License: GPL
Ideas page: OpenTasks
IRC channel: #scummvm on irc.freenode.net
Development mailing list: https://lists.sourceforge.net/lists/listinfo/scummvm-devel
Mentors:

About ScummVM

The ScummVM project aims to allow users to run on modern hardware a variety of commercially available graphical point-and-click adventure games including Monkey Island, Simon the Sorcerer, Space Quest, and many more. To this end, ScummVM features a complete reimplementation of each supported game engine (Virtual Machine - VM) in a structured fashion using the C++ language. The development 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. The number of engines is constantly growing thanks to a very agile and diversified development team.

The VM approach followed by ScummVM results in efficient code, which has been ported to numerous Operating Systems. Besides running on all mainstream desktop environments, namely Windows, Mac OS X and most Unix variants (Linux, *BSD, Solaris, ...), ScummVM works on popular 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).

ScummVM's high portability is a direct consequence of the flexible and modular structure of its architecture, which can be roughly divided into the following three major categories:

  1. Backends, which are responsible for supporting specific target devices, like PalmOS or WinCE,
  2. Engines, also called front ends internally, contain the actual game specific (VM) code, and
  3. Infrastructure code, which provides easy and portable baseline functionality, such as access to audio (including MIDI), graphics, user input, data access, a custom graphical user interface, and more.

The large team of developers is split in groups which focus in different aspects of the architecture, in a manner derived from the above mentioned categorization. The team members are often not strictly confined to their respective group. Developers may assume different roles in several teams. Currently, the developers are split in the following subteams:

  • Porters: Responsible for a specific ScummVM port.
  • Engine authors: Responsible for a specific game engine and its associated bug reports (support).
  • Infrastructure development: Includes for example developers working on MIDI code, on the built-in custom GUI, etc.
  • Packagers: Not all ports require dedicated backends. For example our SDL backend is highly portable, but it still requires somebody to test and compile it. Packagers execute this function.
  • Documentation / web site management
  • Project leads: There are currently three project leads. They all are also represented in one of the above categories, but besides this they organize and coordinate things, make decisions, solve disputes etc.

All of this enables us to be highly productive in a team of about 30 currently active developers (out of an all-time pool of over 60), who work together on a codebase exceeding 600,000 lines of code. 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 with well over 100,000 monthly downloads and ~9 million project web hits per month.

What we hope to gain

For one thing, we hope to attract new blood: we hope to gain some new active developers via these projects. While we already have several very active contributors, these people are already mostly busy in specific subprojects and tasks. New people mean new ideas, new energy, and new ways of thinking. Therefore, a longer lasting engagement of our student contributors would be our highest hope.

Furthermore, all of our developers work on ScummVM in their spare time. But for some tasks, it's most effective if you can spend a certain block of time working on this task exclusively; just what we would get via the SoC. Hence, we hope to gain some nice shiny new code providing useful new functionality to our users and developers. Even if the authors don't stick around, this will benefit all of the ScummVM community.

Lastly, we also believe that we can learn a lot from this whole event in terms of interaction with prospective new team members, how to motivate students to participate in our projects, and so forth: knowledge that may turn out to be very valuable outside of the SoC, too.

Our mentors

Our mentors were selected as volunteers from the development team who are already intimately familiar with the internals of ScummVM, our coding conventions etc.. All three are familiar with guiding people (in particular, students) through project work effectively (in fact, two of them happen to be lead developers of ScummVM). As such, we are convinced that we are able to guide interested students through the Summer of Code to the net benefit of all involved parties.

How we will deal with participants 'missing in action'

We hope that nobody will disappear, but we plan to take a proactive approach, i.e., we will try to minimize the risk of a loss of communication, but if it happens, we are prepared to deal with it, too.

For the mentors, the risk is relatively low; two are project leads and are reachable virtually 24/7 (in case of emergencies). We all have exchanged sufficient contact information (including cell phone numbers etc.) to be able to discover our whereabouts etc. Should something really bad happen (like somebody ending up in hospital and hence unable to work, a natural disaster, etc.), we will attempt to shift students to new mentors (among the existing mentors, or drawn from our backup pool of mentors). This will depend on the number of students we have to mentor.

As for the students, for starters we plan to exchange as much communication data as possible (cell phone numbers, postal addresses etc.). Through a friendly atmosphere we hope to minimize the risk of any student being "afraid" to report problems they might have etc.. On the other hand, we will make it clear that we expect dedicated work of the students and that unannounced/unjustified disappearances will draw consequences, like negative reports or even the failure of the whole project. Still, establishing a positive and friendly connection between student and mentor will be the cornerstone of our efforts in this regard. If the student trusts the mentor and tells him about his fear, uncertainties and problems early on, they can try to find a solution together, possibly with the help of the rest of the team. Also, integrating the students into our community should reduce the likelihood of disappearances further (see also the next section).

A common cause (we believe, based on our own experiences as students *g*) is a lack of structure in the assigned work, resp. an inability of the student to make real progress. To avoid this, we will request that students come up with a (realistic) project plan / schedule. The mentors will watch the progress with the students and discuss it with them regularly (at least weekly). We hope to detect potential problems early on this way, thus being able to help the students get around them, to the benefit of all.

If all fails, though, and a student really vanishes completely, we will have to deal with the consequences, just like with regular projects in a company. Projects *can* fail, after all, no matter how hard you try to avoid it.

Integrating students with the community

Our community uses forums, IRC, a Wiki and our mailing list for a vivid exchange of thoughts all the time. We will urge the students to participate in all of them; especially on IRC can they directly talk to many nice and helpful team and community members. The mentors will introduce the students to the rest of the team (making sure everybody knows who the students are). There are people active in the IRC channel virtually 24/7, thanks to the international nature of the project.

We also expect the students to talk to non-mentor team members on a regular basis about parts of ScummVM for which these team members are experts (if these parts happen to be relevant for the student's project). To achieve that, the mentors will specifically introduce them to each other, and will try to encourage them to work together.

Student application template

The following was adapted from the FreeBSD Proposal Guidelines.

  • Name
  • Email
  • Project Title
  • Possible Mentor (optional)
  • Benefits to the ScummVM Community - a good project will not just be fun to work on, but also generally useful to others.
  • Deliverables - It is very important to list quantifiable results here e.g.
    • "Improve X modules in ways Y and Z."
    • "Write 3 new man pages for the new interfaces."
    • "Improve test coverage by writing X more unit/regression tests."
    • "Improve performance in FOO by X%."
  • Project Schedule - How long will the project take? When can you begin work?
  • Availability - How many hours per week can you spend working on this? What other obligations do you have this summer?
  • Bio - Who are you? What makes you the best person to work on this project?
Retrieved from "https://wiki.scummvm.org/index.php?title=Summer_of_Code/Application/2007&oldid=8461"