GSoC Ideas

This page contains a list of ideas about projects/tasks for the ScummVM project which we feel are relatively substantial (and so appropriate for at least part of a Google Summer of Code project), and accessible to newcomers with good C++ knowledge.

This is just the few projects that we have come with ourselves, and there are many many other tasks which would be helpful to the project - many ScummVM engines have their own TODO lists.

Of course, if you are not participating in Summer of Code, you are also very welcome to try working on one of these projects.

Introduction

The projects below are sketches and ideas. Our project changes over time, so if you're not reading this during the Summer of Code application period, the descriptions might be outdated by the time you read them (although we strive to keep them up-to-date). You should talk with somebody from the team, ideally with someone listed as a possible technical contact, before starting work on any of them.

Most developers are active in our IRC Channel, and that is often the easiest way to ask questions about the tasks and the code in general. You should come to our IRC channel and introduce yourself. The channel is the main form of everyday communication for the project, and there will almost always be developers there who can discuss your project ideas and answer questions.

You must follow our Coding Conventions. In particular, note that you can't use the standard C++ library for code used inside ScummVM itself. Using it for a non-essential tool should be fine, though.

All code, unless stated differently (for example, platform-specific code), must be written in clean and portable C++; in particular, various versions of both GCC and Visual Studio must be able to compile it. We also have some Code Formatting Conventions.

We only accept clean and maintainable code. This is a somewhat vague requirement, but as a rule of thumb, if the code does what it is supposed to do, but is not extensible, a quick hack, or we need to rewrite it from scratch to properly integrate it, we will not accept it. In particular, we would rather have a maintainable, clean and incomplete piece of code that we could extend, than a complete but unmaintainable piece of code.

Finally: All of the code submitted must be contributed under the terms of the GPL v2+.

Summer of Code Applications

The ideas here are meant to be just that - ideas. You should also consider suggesting your own completely new project ideas, or to suggest a modified version of one of our ideas, or a combination of ideas. Not all the ideas might be substantial enough for the whole of GSoC, while other ideas might be far too much work. We expect you to consider this in your application and proposed schedule.

You must read the Summer of Code Project Rules, which are obligatory for our students, and tell you what you should do before you apply. There are also some Guidelines for our students.

Your application should have at least the following information (adapted from the FreeBSD Proposal Guidelines):

• Name
• Email
• Online nicks

Please list the nicknames of the communication channels you plan to use to keep in touch with us. For example, list your IRC (on FreeNode) nick here.

• Project Title

State precisely what your project is about. 40 characters is usually a good upper limit.

• 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

The deliverables will be used to evaluate your progress/success at the mid-term/final evaluations. Thus, it is very important to list quantifiable results here (this does not need to be a simple list!) 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%."

Make sure there is a clearly visible set of goals that need to be accomplished for your project to be considered successful. It is also encouraged to list additional goals you plan to accomplish in the course of your project if everything goes as expected. You already explained why your project is beneficial for us, however, here you should motivate why a goal is required for your success or just optional. Make sure not to mix the description of a goal with this.

In addition to the mere goals of your project define milestones. A milestone should be connected to the progress/accomplishment of goals. You should, at the very least, define 2 (two) milestones here. Again, describe the milestones and elaborate on your reasons for defining exactly these milestones. When you plan to accomplish the milestones will be handled in the schedule and not here.

• Project Schedule

Create a schedule with (at least) the granularity of weeks. This schedule should, for example, explain how long your project will take and when you can begin to work on it. Please connect the individual weeks with the overall Summer of Code schedule, i.e. clearly make the mid-term evaluations (etc.) visible. There are multiple ways to organize this, we trust you to find the best way to present your schedule. However, we want to see a connection to the goals here. This includes elaborating why you think X takes time Y and what possible issues might arise here. Last but not least, put a fixed date for each milestone you defined here. We want at least one milestones before the mid-term.

• Availability

How many hours per week can you spend working on this? What other obligations do you have this summer?

• Skype ID

If you don't use Skype, install it.

• Phone Number

Cellular is preferable, for emergency contacts.

• Timezone

Where do you live.

• Bio

The two main questions you should answer here are:

• Who are you?
• What makes you the best person to work on this project?

Make sure you fill this with some life. We would like to know your age and university year for example. Also, explain your connection to ScummVM in the general and to your project in specific. What experience do you have with C++ or other languages required in your project? Have you taken university courses which you think will be helpful? Did you work on any projects we can take a look at? Do you think you will learn anything from your proposed project (if yes, explain what)?

• Pull Request

A link to the pull request you submitted as part of our Project Rules

When writing this application, keep in mind that the application serves multiple purposes. First of all, it should identify the objectives of your project, i.e. what should be done. Furthermore, it needs to convince us your project is worth a slot/mentoring. Last but not least, it should convince us that you are indeed the right person for this task. A good example of what we do not want to see in your application is a copy of our version of an idea's description.

Audio Output Configuration

Technical contact: Johannes Schickel.

ScummVM needs an improved internal API and user interface for selecting and controlling audio output. Among other issues, at present there isn't a clear distinction between audio types', audio drivers and audio devices.

The idea is that a proper layer-based audio output system should be designed, implemented and used in all our engines, and an appropriate configuration GUI should be designed and added too.

See OpenTasks/Audio/Audio Output Selection for more discussion and some technical details.

MIDI Device Configuration

Technical contact: Johannes Schickel.

At the moment, configuration of MIDI output is not linked to devices, despite a lot of the configuration options being specific to a device or driver.

This task would involve designing and implementing an interface for querying and storage of a wide variety of MIDI drivers/devices, improving the GUI to allow this configuration, and working on some related improvements (such as allowing devices to be added/removed while ScummVM is running).

See OpenTasks/Audio/MIDI Device Configuration for more discussion and some technical details.

Improve Main GUI

Technical contacts: Eugene Sandulenko.

Several years ago we switched to new XML-based and vector-based GUI. Unfortunately during this transition number of nice touches from previous version of Modern GUI were lost. Particularly current GUI lacks soft shadows, antialiasing in number of places, we are lacking proper widgets for PopUp and List widgets. Those need to be implemented as part of this task.

Also there is need to implement better sliders, multiline text widgets as well as improve current List widget.

See OpenTasks/Generic/Improve GUI Look for more details.

Improve touchscreen GUI

Technical contacts: Eugene Sandulenko.

Our launcher/options GUI has been designed for keyboard/mouse input, and does not work well in practice on modern touchscreen devices.

Since it is theme based, part of the problem can be resolved by using a custom theme. However, our GUI code will need extensions to allow it to behave like a proper touchscreen application.

See OpenTasks/Generic/Touch GUI for more details.

Avalanche Engine

Technical contacts: Arnaud Boutonné, Eugene Sandulenko.

The Avalanche Engine has been generously provided by his authors who found recently the sources. This engine is written in Turbo Pascal and is used in the game Lord Avalot d'Argent.

The sources has been given under GPLv2, as well as the game data.

The important parts of this task would be first to port the sources from Pascal to C++, to rework then refactor it heavily, and to integrate it into ScummVM. The use of ScummVM subsystems for graphics, audio, input, etc, will be mandatory, and it'll be required to follow our portability/style guidelines.

See OpenTasks/Engine/Avalanche for more details.

Improving WME engine

Technical contacts: Our IRC channel, our mailing list, or contact Einar Johan Trøan Sømåen

The current WME engine allows to play several WME games perfectly. There are neverthless some missing features in the current version of the engine, and some parts of the engine require some optimization. As a consequence, this would allow to improve the gaming experience and to add support to more WME games.

See OpenTasks/Engine/Improve WME for more details.

Hardware accelerated blitting

Technical contacts: Our IRC channel, our mailing list, or contact Einar Johan Trøan Sømåen, Johannes Schickel, Alyssa Milburn

Some engines (Wintermute, Broken Sword 2.5) would greatly benefit from hardware acceleration for their graphics code. Obviously the purpose of this task is not to make it available on all ports. The impacted ports have to be determined in advance.

See OpenTasks/Graphics/Hardware Acceleration for more details.

Implement Z Engine

Technical contacts: Our IRC channel, our mailing list, or contact Filippos Karapetis, Eugene Sandulenko

Using the existing engine available from http://github.com/Marisa-Chan/Zengine, write an engine implementation for ScummVM. This engine will have to support Zork Nemesis and Zork Grand Inquisitor.

See OpenTasks/Engine/Z Engine for more details.

Sources for other ideas

Technical contacts: Our IRC channel, our mailing list, or contact Eugene Sandulenko, John Willis, Arnaud Boutonné

One good place to start if you're looking for new ideas would be our TODO page (and the other TODO lists linked from there). Some other ideas (most of which might be incomplete or outdated, or too difficult for a new developer) can be found on our OpenTasks page. Again, be sure to talk to us before thinking too much about any idea on these lists, as many things are likely to be outdated or simply wrong.

New game engines

Technical contacts: Our IRC channel, our mailing list, or contact Eugene Sandulenko, John Willis, Arnaud Boutonné

If you already have reverse engineering experience, you could consider working on one of the external in-development game engines, or even on support for a new game. However, doing this kind of work is very difficult and time-consuming - you would have to convince us that you have the necessary skills to actually be sufficiently productive, probably by demonstrating some actual progress first.