ResidualVM logo Main website - Forums - BuildBot - Doxygen - Contact us Log in curved edge



Introduction & overview

This is the application of the ResidualVM 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: ResidualVM
Participation in prior SoCs: No
Organization administrator: aquadran
Organization co-administrator: somaen
Backup administrator: strangerke
Project License: GPLv2
Ideas page: GSoC Ideas
IRC channel: #residualvm on
Development mailing list: residualvm-devel AT
Backup Mentors:
  • TBD

Please address all items in RED ;-)

Application organized according to program FAQ

Description of the Organization

ResidualVM is a sister project of ScummVM and was created in 2003. ResidualVM shares large blocks of common code with ScummVM, some developers and even a mentor.

ResidualVM is a cross-platform 3D game interpreter which allows you to play some 3D adventure games, such as Cyan's Myst 3 and LucasArts' Lua-based 3D adventures: Grim Fandango and Escape from Monkey Island, provided you already have their data files. ResidualVM just replaces the executables shipped with the games, allowing you to play them on systems for which they were never designed! To this end, the VM (called Engines) are complete reimplementations (in C++) of the engines used in the original games.

The VM approach followed by ResidualVM results in efficient code, which has been ported to several Operating Systems. ResidualVM runs on Windows, Mac OS X and most Unix variants (Linux, *BSD, Solaris), and there is even a port on AmigaOS (which is a big-endian system). Recent developments have also added a basic workable Android port, which is currently undergoing polishing.

ResidualVM has a productive team of about 20 currently active developers (out of an all-time pool of over 40), working together on a codebase of nearly 300,000 lines of code.

What Open Source Initiative approved license(s) does your project use?

GNU General Public License version 2.0 (GPL-2.0)

What is the URL for your Ideas list? **This is the most important part of your proposal. Please make sure we can access it and it is complete when you submit this proposal. “Placeholder” or inaccessible ideas pages will be grounds for an automatic rejection for participation in Google Summer of Code 2014.**

What is the main development mailing list for your organization?

  • residualvm-devel AT

What is the main IRC channel for your organization?

  • #residualvm on

Who will be your backup organization administrator?

  • strangerke

Why is your organization applying to participate in Google Summer of Code 2014? What do you hope to gain by participating?

Each year since 2007, our sister project ScummVM participated in the Google Summer of Code and got impressive results. As some of our team members were involved in these, we decided this year to apply too. We hope that our experience as mentors will benefit the students, and that the open source community will benefit from the work of students with more open source engines available.

In addition, we hope to gain new developers for the project. We hope that after GSoC, students will stick around and improve their projects or work on other interesting tasks. We hope that GSoC brings the students in touch with open source and, in our case, brings them in touch with 3D game development. We hope these students will add their piece of code to this project, but will also keep on contributing afterwards.

We've been successful in the past years with ScummVM tasks, and we're really looking forward to great results for ResidualVM from the program this year.

How many potential mentors do you have for this year's program? What criteria did you use to select them?


  1. Paweł Kołodziejski (aquadran)
  2. Einar Johan T. Sømåen (somaen)
  3. Joel Teichroeb (klusark)
  4. Christian Krause (chkr)

Backup Mentors

  1. Bastien Bouclet (bgK)
  2. Giulio Camuffo (giucam)
  3. Dries Harnie (Botje)


We have 7 potential mentors in the team. Based on the experience we had at ScummVM, we are using similar criteria to select mentors. We want our mentors to have the following qualities:

  • Be able to commit to participating for the entire duration of the program. They first and foremost have to be available to their students and the mentor team.
  • Have a considerable track record hacking on ResidualVM. They can help the students more effectively and in an immediate fashion this way.
  • Have the patience and skills to explain to their respective students on how to tackle their tasks. Also, to be able to help the students out in sticky situations.
  • Have a clear vision on how a task should proceed, from broad strokes down to the implementation itself. Allowing, of course, some freedom of movement to the students, where this is applicable.
  • Be regularly present on our #residualvm-gsoc channel, where we will continuously inform each others of the progresses and issues of the students

It's also important to tell that our mentors have volunteered to work with GSoC. This means that they primarily want to be involved in the program and that they are not dragged in to participate. Moreover, they have all been contributors to ResidualVM for several years, feel comfortable around the ResidualVM code and can guide students to perform their tasks.

Some of our mentors were involved in GSoC during the previous years as members of ScummVM team so they know their way around the procedures and have refined their mentoring style.

We are drawing the best available from our pool of developers to mentor GSoC students.

What is your plan for dealing with disappearing students?

We have never participated in GSoC before, but our sister project, ScummVM has. We will be taking their lessons learnt on this point and we will be using the same measures to avoid this happenning.

  • We will clearly explain that this work should be considered as full-time, and if there is any doubt, we will not let the student enter the program.
  • We will require that students provide status updates to their mentors on a bi-daily basis at most. If a student disappears for more than 3 days without notifying his/her mentor, the student will fail the project. The students will be made immediately aware of this during their applications. In past projects, ScummVM has identified that frequent and meaningful communication goes a long way in keeping the students engaged and interested.
  • We will require comprehensive timelines and we will accept only students which set realistic goals, thus minimizing the risk of getting intimidated.
  • We will make sure that during the whole program that students will feel comfortable with their tasks. Some of our mentors already have experience with that thanks to their previous experience of GSoC with ScummVM. Moreover, we involve two mentors per task rather than just one and the whole project team will help when needed.

What is your plan for dealing with disappearing mentors?

Based on our experience of GSoC as ScummVM mentors, we know that the risk of a disappearing mentor is low.

In order to as efficient as possible, one of our mentors is the project leader and another has been a GSoC student two years ago and a mentor for ScummVM last year. We have exchanged sufficient contact information (including cell phone numbers etc.) to be able to discover our whereabouts. We also assigned two mentors per task in order to make sure that one will be available virtually all the time and, in any case, the students will not be left hanging for any reason at all, no matter what happens.

On top of that, we will use a specific #residualvm-gsoc channel on IRC where mentors and org admins (and only them) will be connected all the time. We will use this channel to keep ourselves informed of the situation of each task, each student and each mentor.

Based on that, we are certain we can find backup mentors in a matter of days to ensure that two team members are always available for each student.

What steps will you take to encourage students to interact with your project's community before and during the program?

Based on the experience we had with ScummVM, we want the students to understand they are special for us, but developers nonetheless. We will encourage them to take part of our discussion just like the other developers.

We will also regularly encourage the whole team to provide support and feedback to the students and to communicate constructively and respectfully with them. The students will be marked with a special flag on our IRC channel (voice), so everyone will be able to identify them easily. We will require our students to write introductory letters to our development mailing list and their blog so everyone will have a sensible background about them, their skills and their assigned task (of course).

In order to help the students familiarize themselves with the project, we have also created several key pieces of documentation for them. As we share some common code with ScummVM, their documentation about common parts is valuable too. This constitutes a highly valuable source of information as a quick reference as well as during the initial explorations of the codebase.

What will you do to encourage that your accepted students stick with the project after Google Summer of Code concludes?

Last year ScummVM decided to require the GSoC student code be merged into their Master tree much earlier in the process, if possible.

As a result, half of their GSoC 2013 students are still active nowadays, and we are confident it's related. We are confident that it is very motivating for students to directly interact with the main repository and could potentially make them stay after the end of GSoC, and we will try that for ResidualVM too.

These measures we have defined make sure the students feel involved in the project and will certainly contribute to their continued involvement.

Are you a new organization who has a Googler or other organization to vouch for you? If so, please list their name(s) here.

Our sister project ScummVM is vouching for us.

ScummVM is a sister project of ResidualVM, dealing with 2D Adventure games. We share a lot of common code and developers.

If you are a new organization, have you applied in the past? If so, for what year(s)?

We never applied before.

Is there anything else we should know or you'd like to tell us that doesn't fit anywhere else on the application?



curved edge   curved edge