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.

Stop reading this!

Introduction

The projects below are sketches and ideas. Our project changes over time, so 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.

Your application should have at least the following information (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?
• Skype ID - If you don't use Skype, install it.
• Phone Number - Cellular is preferable, for emergency contacts.
• Timezone - Where do you live.
• Bio - Who are you? What makes you the best person to work on this project?

Integrating the Wintermute Engine

Technical contacts: Arnaud Boutonné, Eugene Sandulenko.

The Wintermute Engine (WME) is a set of tools for creating and running graphical adventure games. This idea involves integrating the game runtime engine into ScummVM - this would make the games far more portable. Since there is a free SDK, it would allow people to directly develop 2D games that would run in ScummVM, which is a regular request from ScummVM users.

While the original runtime itself is LGPL, there is also a portable version of the runtime called WME Lite, which already runs on Windows, iOS and MacOS. It only supports the 2D games, but since the 2.5D/3D games are outside the scope of ScummVM, that is ideal.

The important part of the task would be the actual integration; using ScummVM subsystems for graphics, audio, input, etc, and reworking the code to follow our portability/style guidelines. If there's enough time, it would also be possible to add some missing WME Lite features: for example, video support (which is probably most important) and sprite frame mirroring, rotations and blending modes.

See OpenTasks/Engine/Wintermute for more details.

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.

Scalers

Technical contact: Eugene Sandulenko, Johannes Schickel.

Our SDL-based backends (a backend is roughly equivalent to a 'port'), such as the one used by default on desktop machines, use 2D scaler functions to 'scale up' the game screen to a larger size, such as plain 2x/3x scalers and HQ2x/HQ3x.

Right now, they are all hardcoded into the build, which means that adding new scalers is inconvenient, especially since they all have to be built into ScummVM. This means that, at the moment, we have stopped adding new scalers to the code. If our plugin system could be extended to allow for scalers to be provided as plugins, then these problems would be solved.

Once this is done, and the existing scalers changed to be plugins, then support could be added for scalers supporting higher bit depths (32bpp) - which would allow us to use a 32bpp overlay for the GUI. And finally, new scalers could be added (there have been several patches submitted already).

Saving anywhere

Technical contact: Alyssa Milburn.

On phones and other mobile devices, ScummVM may need to be shut down abruptly - for example, due to memory pressure caused by an incoming call, or another background task.

It would be very nice to be able to (automatically) save at any point when you have to shut down ScummVM suddenly - including in cutscenes, conversations, etc... at the moment, most engines don't allow this.

Since saving is something that every engine implements separately, a GSoC project might consist of implementing this for a number of engines.

New game engines

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.

DOS Port

Technical contact: David Turner.

ScummVM is already ported to most common Operating Systems and devices, and quite a few uncommon ones.
However, one major exception is DOS. This has been requested and talked about a fair number of times, but with no progress i.e. Thread

This is partly as there is no SDL port for DOS. The student would either need to look at SDL DOS porting, create a DOS custom backend or use the Win32 port of SDL using HX Extender. A native DOS porting of SDL is the recommended route, targeting VESA VGA Graphics, SB16 Sound Output, MPU401 etc.

It would be intended that the required libraries including libSDL and ScummVM would be compiled by an open C++ toolchain such as OpenWatcom.

Since DOSBox provides an emulated DOS machine and FreeDOS provides a free and open source 100% compatible DOS implementation, MS DOS will not be needed by the student, though support for this is intended.

The student would require good C/C++ skills and knowledge of DOS internals or a willingness to learn and demonstrable progress on this task i.e. DOS Graphics Demo...

Security Audit

Technical contact: David Turner.

As ScummVM is a framework housing a collection of game engines, rather than "serious" software such as a web server, operating system or cryptographic library, it is not considered security critical and thus should not be installed on servers, or other computers running critical infrastructure.

However, we do consider security issues i.e. ScummVM does not generally require root privileges to run, Git helps harden our VCS against malicious modification, etc. We also use static analysis e.g. CPPCheck and dynamic analysis e.g. Valgrind to catch programming and memory access issues which could prove exploitable. However, no one has performed a specific audit of ScummVM for security issues.

The aim of this task would be for the student to perform this review and enhance ScummVM's code, especially with respect to validation of input, especially configuration file, savegame and game datafile loading.

Apart from the ScummVM base, GUI, common and platform specific save/loading code, this will require individual work on each engine's save/load and resource loading code to assess if any issues exist and what improvements can be made without causing regressions...

This task will have the side effect of reducing bug reports of crashes which turn out to be due to corrupted game datafiles or savegames.

Kudos points will be given to a student creating and submitting a binary/script patch to a supported game's datafiles which is detected normally, but results in some kind of exploit i.e. crash, infinite loop, especially if they propose a engine code patch to fix the issue which does not prevent normal games from operating correctly.

The student would require good C/C++ and communications skills. Interest or prior experience of secure programming, analysis of malware or similar would be desirable.