Difference between revisions of "Summer of Code/GSoC Ideas 2016"

From ScummVM :: Wiki
Jump to navigation Jump to search
 
(67 intermediate revisions by 6 users not shown)
Line 3: Line 3:
We've had a lot of successful student projects as part of Google's Summer of Code in previous years -- we hope to inspire you to work with us and (hopefully) add your own success.
We've had a lot of successful student projects as part of Google's Summer of Code in previous years -- we hope to inspire you to work with us and (hopefully) add your own success.


For all of these tasks, you'll probably need to already be comfortable with a basic level of C++. Some of the tasks might need more specialised knowledge (for example, working with ResidualVM may need you to understand some OpenGL and 3D math).
For any work on ScummVM, you'll probably need to already be comfortable with a basic level of C++. Some of the tasks might need more specialised knowledge (for example, working with ResidualVM may need you to understand some OpenGL and 3D math); we give our thoughts about this alongside each suggested task, below.


Most importantly, we'd like you to join our community. There are many previous GSoC participants who are still involved in our project, and whether or not you participate as part of Summer of Code, we'd love for you to get involved too.
Most importantly, we'd like you to join our community. There are many previous GSoC participants who are still involved in our project, and whether or not you participate as part of Summer of Code, we'd love for you to get involved too.


You should come to our [[IRC Channel]] and introduce yourself! We're friendly, and it's often the easiest way to ask questions about the tasks and the code in general. 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, answer questions and help out.
You should come to our [[IRC Channel]] and introduce yourself! We're friendly, and it's often the easiest way to ask questions about the tasks and the code in general. 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, answer questions and help out.
You can find more information about what we expect from you before you apply at [[GSoC Application]].


__TOC__
__TOC__


== Introduction ==
== Introduction ==
We have a list of potential tasks further down on this page, but before you look at them, perhaps you'd like to take a look at some of the successful projects from previous years! We encourage all of our students to maintain a blog during their summer work, which is a nice way to get some sense of what they accomplished.


One popular type of task is to improve our support for the games you love, whether this means a new game engine, or helping us to perfect an existing one.
One popular type of task is to improve our support for the games you love, whether this means a new game engine, or helping us to perfect an existing one.


Sometimes source code is available - in recent summers, students integrated code supporting games such as [[Sfinx]], [[The Prince and the Coward]] and [[Avalanche]] into ScummVM. In fact, our support for the [[Wintermute]] engine was not only started by a GSoC student, who integrated the code into our tree, but also [[Wintermute/Games|drastically improved]] by another student a year later.  
Sometimes source code is available - in recent summers, students integrated code supporting games such as [[Sfinx]] ([http://urukgsoc.blogspot.hu/search/label/CGE2 blog]), [[The Prince and the Coward]] ([http://lukaslwgsoc.blogspot.com/ blog]) and [[Avalanche]] ([http://urukgsoc.blogspot.hu/search/label/Avalanche blog]) into ScummVM. In fact, our support for the [[Wintermute]] engine was not only started by a GSoC student ([http://summermute2012.blogspot.com/ blog]), who integrated the code into our tree, but also [[Wintermute/Games|drastically improved]] by another student a year later ([https://icodelikeacow.wordpress.com/ blog]).  


[[File:GSOC_EMI.png|160px]] [[File:GSOC_zvision.png|160px]] [[File:GSOC_EMI_asm.png|160px]]
[[File:GSOC_EMI.png|160px]] [[File:GSOC_zvision.png|152px]] [[File:GSOC_EMI_asm.png|147px]]


A more challenging (but hopefully rewarding) idea is to start (or continue) reverse engineering a game where no source is available. Two good examples are the pair of students who drastically improved ResidualVM's support for Escape from Monkey Island, and the work on improving [[Operation Stealth]]. Another option is to work on merging someone else's reverse engineering work, such as was done with the [[ZVision]] engine.
A more challenging (but hopefully rewarding) idea is to start (or continue) reverse engineering a game where no source is available. Two good examples are the pair of students who drastically improved ResidualVM's support for Escape from Monkey Island ([http://diggingemi.blogspot.com/ blog], [http://akzgsoc.blogspot.com/ blog]), and the work on improving [[Operation Stealth]] ([https://buddhahacks.wordpress.com/ blog]). Another option is to work on merging (and improving) someone else's reverse engineering work, such as was done with the [[ZVision]] engine ([http://richiesams.blogspot.com/search/label/ScummVM blog]).


If you'd prefer to improve ScummVM more directly, there are even more options available there; in the past, students have improved our OpenGL support, added a testing framework, written a new GUI framework, improved sound format support and added support for high-colour (16bpp and above) graphics. It's difficult for us to imagine ScummVM as it was before some of these projects, you can make a huge difference!
If you'd prefer to improve ScummVM more directly, there are even more options available there; in the past, students have (to give some examples) improved our OpenGL support, added a testing framework ([http://jakimushka.blogspot.com/ blog]), improved our scaler code ([http://singron.blogspot.com/ blog]), written a new GUI framework, added loadable modules for embedded platforms ([http://tonypuccinelli.blogspot.com/search/label/ScummVM blog]), rearchitected our keyboard input code ([http://kenny-gsoc.blogspot.com/ blog]) and added support for high-colour (16bpp and above) graphics. It's difficult for us to imagine ScummVM as it was before some of these projects, you can make a huge difference!


== Tasks ==
== Tasks ==
Line 29: Line 33:
The ideas here are meant to be just that - '''ideas'''. We hope they help inspire your proposals, but you should also consider suggesting your own completely new project ideas. Pick something you really want to see improved/fixed, and come and talk to us about it!
The ideas here are meant to be just that - '''ideas'''. We hope they help inspire your proposals, but you should also consider suggesting your own completely new project ideas. Pick something you really want to see improved/fixed, and come and talk to us about it!


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).
If you're looking for more inspiration for ideas, beware of our [[TODO]] (and the other TODO lists linked from there) and our [[OpenTasks]] pages. Many of the tasks listed there might be incomplete or outdated, or too difficult for a new developer. The best thing to do is to come and talk to us!
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.


== GUI Tasks ==
== GUI Tasks ==
Line 41: Line 44:


Technical contacts: [[User:Sev|Eugene Sandulenko]].
Technical contacts: [[User:Sev|Eugene Sandulenko]].
Difficulty level: Easy (code) / medium (architecture). You'll need a touchscreen device which can run ScummVM, to test on.


Our launcher/options GUI has been designed for keyboard/mouse input, and does
Our launcher/options GUI has been designed for keyboard/mouse input, and does
Line 53: Line 58:
Technical contacts: [[User:Sev|Eugene Sandulenko]].
Technical contacts: [[User:Sev|Eugene Sandulenko]].


We have a wishlist for improved GUI widgets; we'd like better sliders, multiline text widgets, and an improved list widget. We also want proper widgets for our PopUp and List widgets.
Difficulty level: Easy.


Also, several years ago, we switched to a new XML-based and vector-based GUI, but unfortunately during this transition number of nice touches were lost. In particular, the current GUI lacks soft shadows and antialiasing in number of places. We'd like them back!
We have a wishlist for improved GUI widgets; we'd like better sliders, multiline text widgets, an improved list widget, and better widgets for PopUps.
 
Also, several years ago, we switched to a new XML-based and vector-based GUI, but unfortunately during this transition number of nice touches were lost. In particular, the current GUI lacks soft shadows and antialiasing in number of places. We'd like them back! At the same time, it would be nice to add support for transparent PNG files.
 
Finally, it would be nice to have support for a scalable GUI which looks good at modern resolutions, which would require changes to our theme format, among other improvements.


See [[OpenTasks/Generic/Improve GUI Look]] for more details.
See [[OpenTasks/Generic/Improve GUI Look]] for more details.
Line 69: Line 78:
=== Macromedia Director ===
=== Macromedia Director ===
Technical contacts: [[User:Fuzzie|Fuzzie]]
Technical contacts: [[User:Fuzzie|Fuzzie]]
Difficulty level: Medium. You'll need a reasonable level of programming experience, and probably some Director games.


Many 90s-era adventure games were developed using the Macromedia (now Adobe) Director tool. It would be nice to be able to play these games in ScummVM! We have Python code available which can parse and display the contents of Director 2 and Director 3 'movie' files. This should be enough to implement a ScummVM engine to allow some early Director adventures to be played; for example, parsing the movie files, implementing the frame-based playback system, drawing bitmaps and shapes, playing sounds and running some basic (Lingo) scripting.
Many 90s-era adventure games were developed using the Macromedia (now Adobe) Director tool. It would be nice to be able to play these games in ScummVM! We have Python code available which can parse and display the contents of Director 2 and Director 3 'movie' files. This should be enough to implement a ScummVM engine to allow some early Director adventures to be played; for example, parsing the movie files, implementing the frame-based playback system, drawing bitmaps and shapes, playing sounds and running some basic (Lingo) scripting.
Line 75: Line 86:
Technical contacts: [[User:DJWillis|John Willis]], [[User:Md5|Filippos Karapetis]].
Technical contacts: [[User:DJWillis|John Willis]], [[User:Md5|Filippos Karapetis]].


The [http://seancode.com/webventure/ WebVenture] [https://github.com/mrkite/webventure engine] by Sean Kasun is a reimplementation of the [https://en.wikipedia.org/wiki/MacVenture MacVenture] engine from ICOM Simulations.  
Difficulty level: Medium. You'll need to understand JavaScript, as well as a good level of C++.


It was used in the late 80s and in the early 90s for 4 games. The MacVenture games are still available for purchase from [http://www.zojoi.com/ Zojoi].
It would be great to support games which were written for the [https://en.wikipedia.org/wiki/MacVenture MacVenture] engine from ICOM Simulations.  It was used in the late 80s and in the early 90s for 4 games. The MacVenture games are still available for purchase from [http://www.zojoi.com/ Zojoi].


The current code is written in JavaScript, which means it will have to be completely rewritten in C++ and integrated in ScummVM.
The [http://seancode.com/webventure/ WebVenture] [https://github.com/mrkite/webventure engine] by Sean Kasun is a reimplementation of this engine, so we (hopefully) already know enough about how it works. Of course, the current code is written in JavaScript, which means we can't use it directly; a new engine needs to be written (in C++) and integrated into ScummVM.
 
'''This task requires C++ and JavaScript knowledge.'''


=== Wintermute 3D ===
=== Wintermute 3D ===
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]]
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]]
Difficulty level: Medium/hard. You'll need to be able to understand 3D graphics, and rearchitecture/design the relevant parts of the engine.


In 2012, support for games using the Wintermute engine was merged into ScummVM, but it still lacks support for games which use 3D graphics. It would be great to be able to play these games in ResidualVM!
In 2012, support for games using the Wintermute engine was merged into ScummVM, but it still lacks support for games which use 3D graphics. It would be great to be able to play these games in ResidualVM!


See [http://wiki.residualvm.org/index.php/GSoC_Ideas#Wintermute_3D_port Wintermute 3D] for more details.
'''ResidualVM project.''' See [http://wiki.residualvm.org/index.php/GSoC_Ideas#Wintermute_3D_port Wintermute 3D] for more details.


=== In Cold Blood engine refactor ===
=== In Cold Blood engine refactor ===
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]], [[User:joostp|Joost Peters]]
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]], [[User:joostp|Joost Peters]]


ResidualVM project. See [http://wiki.residualvm.org/index.php/GSoC_Ideas#In_Cold_Blood_engine_refactor ICB engine refactor] for more details
Difficulty level: Medium/hard. You'll need to be able to understand the relevant parts of the engine.
 
'''ResidualVM project.''' See [http://wiki.residualvm.org/index.php/GSoC_Ideas#In_Cold_Blood_engine_refactor ICB engine refactor] for more details
 
=== Improve SCI support ===
 
Technical contacts: Our SCI team; talk to us on IRC, or send an e-mail.


== Infrastructure Tasks ==
Difficulty level: Hard. Good C++ knowledge and some knowledge of x86 assembly.
 
ScummVM has stable support for the older Sierra SCI games, but the newer ones -- such as Space Quest 6, Quest for Glory 4, Gabriel Knight 1 -- still need extensive work. As this is also something we are very actively working on ourselves, please come talk to us if you would be interested in helping out with reverse engineering and re-implementation.
 
=== Dink Smallwood engine (Cancelled) ===
 
Technical contacts: [[user:strangerke|strangerke]], [[User:dreammaster|dreammaster]]
 
Difficulty level: Medium. Good C++ knowledge.
 
<strike>Dink Smallwood is an action RPG video game, developed by Robinson Technologies, at the time consisting of Seth Robinson, Justin Martin, and Greg Smith. It was first released in 1998 before being released as freeware on October 17, 1999. The game has a small but constant fan following that continues to develop add-ons for the game more than 15 years after its release. The game is also notable for its humorous dialogue and surrealistic themes in various scenes between the gameplay.</strike>
 
<strike>The purpose of the task is to port the available sources of Dink Smallwood on top of ScummVM's OSystem framework and to make sure it also have a good support of fan's MOD. (about 350 games currently)</strike>
 
'''''This task has been cancelled due to the existence of the very good and active project [http://www.gnu.org/software/freedink FreeDink]. The scope of this project has been misunderstood when the task was added. All our apologies.'''''
 
=== Dungeon Master engine ===
 
Technical contacts: [[user:strangerke|strangerke]], [[User:dreammaster|dreammaster]]
 
Difficulty level: Medium. Good C++ knowledge.
 
Dungeon Master was released on 15 December 1987 on the Atari ST, and by early 1988 was a strong seller, becoming the best-selling game for the computer of all time.
It then was ported to Amiga, PC DOS and many other platforms, with the same success. It's considered nowadays to be a reference in RPG game, possibly the title who made the genre popular.


=== Improve Android port ===
The purpose of the task is to port Dungeon Master's engine and implement it on top of ScummVM's OSystem framework and to make sure it also have a good support of fan's MOD.


Technical contacts: [[User:Fuzzie|Fuzzie]]
=== Bring your own Adventure or RPG ===


=== Improving the iPhone/iOS port ===
Technical contacts: Talk to us on IRC, or send us an email.


Technical contact: [[User:LordHoto|Johannes Schickel]], [[User:Sev|Eugene Sandulenko]].
Difficulty: Hard. You'll need good knowledge of C++, as well as knowledge of (reading) assembly.


The current iOS port, which we still label as iPhone, is functional but feels not really polished in a number of ways. The port comes from a time when the first two generations of the iPhone were still the top models. This, for example, makes it not as nicely usable on modern iOS devices because of resolution issues. Furthermore, while the gesture input serves as a great way to, for example, change control schemes, it also has some annoying issues. The most prominent example is that the "open global main menu" gesture sometimes causes the main menu to immediately close.
Our project consists of re-implementations of classic games, and we have listed
a number of potential new game engines that you could work on here on our ideas
page. However, you may have a classic 2D Adventure game or Role Playing Game
(RPG) you are interested in yourself that is suitable for ScummVM that you
would like to reverse engineer and re-implement. If so, great!


Build wise the iOS port is currently only supported by using a custom toolchain. Supporting the official toolchain and XCode as development environment in '''addition''' to the current toolchain is something we would really like to see. We already have a tool to auto-generate project files for Microsoft Visual Studio. The idea would be to take the currently WIP XCode support and finish it. Building with the official toolchain on command line would also be nice to have.
Adding a completely new game engine is not easy, and you will have to convince
us that you are aware of the challenges involved, that the game you are
interested in is feasible, and that you have the necessary skills. Preferably,
you will already have done some preliminary investigation, into for example
data file formats, disassembly, etc.


Essentially, this task requires working on various aspects of the iOS port. This includes graphics, GUI, input handling, but also build related aspects. Ideally, we want our iOS port to feel much smoother for the users, but also for developers working on it.
Please come talk to us to see if we have a mentor who would be interested in
working with you on such a game. We'd be happy to help out.


'''This task requires C++, ObjC(++), and iOS development knowledge. It also requires access to a (jailbroken) iOS device, preferable both iPhone and iPad, and the official iOS development environment.'''
== Infrastructure Tasks ==


Finally, there's always plenty of other practical tasks on our wishlist!


=== Improve iOS port of ResidualVM ===
=== Improve Android port ===


Technical contacts: [[User:aquadran|Paweł Kołodziejski]], [[User:somaen|Einar Johan Trøan Sømåen]]
Technical contacts: [[User:Fuzzie|Fuzzie]]


Currently ResidualVM has an in progress Android port, but it lacks an iOS port. This task is about to make it for iPhones and iPads.
Difficulty level: Medium/hard. You'll need some knowledge of C++, Java and ideally Android development and OpenGL. Access to at least one Android device is probably also necessary.


See [http://wiki.residualvm.org/index.php/GSoC_Ideas#iOS_port_of_ResidualVM iOS Port] for more details
Our current Android port is in need of improvement, especially combined with modern versions of Android. We'd like to improve the GUI and the input code in particular, but hopefully you also have your own ideas if you've tried the port (if you haven't: do so!). There are some patches already available, and it should be possible to merge code from other projects (such as SDL 2). A native configuration GUI could also be an option.


=== Improve audio device configuration ===
=== Improve audio device configuration ===
Line 126: Line 176:
Technical contact: [[User:LordHoto|Johannes Schickel]].
Technical contact: [[User:LordHoto|Johannes Schickel]].


Our configuration currently doesn't support all audio and MIDI options we would like, and even common configurations cannot always be conveniently specified.
Difficulty level: Medium. You'll need enough C++ experience and knowledge to design a suitable solution.


See [[OpenTasks/Audio/Audio Output Selection]] and [[OpenTasks/Audio/MIDI Device Configuration]] for more discussion and some technical details.
Our configuration currently doesn't support all the audio and MIDI options we would like, and even common configurations cannot always be conveniently specified.
 
See [[OpenTasks/Audio/Audio Output Selection]] and [[OpenTasks/Audio/MIDI Device Configuration]] for more discussion and some technical details of two possible tasks in this direction.


=== Hardware accelerated blitting ===
=== Hardware accelerated blitting ===
Technical contacts: Our IRC channel, our mailing list, or contact [[User:somaen|Einar Johan Trøan Sømåen]], [[User:LordHoto|Johannes Schickel]], [[User:Fuzzie|Alyssa Milburn]], [[User:Digitall|David G. Turner]]
Technical contacts: preferably [[User:LordHoto|Johannes Schickel]], otherwise [[User:somaen|Einar Johan Trøan Sømåen]], [[User:Fuzzie|Alyssa Milburn]] or [[User:Digitall|David G. Turner]]


Some engines (Wintermute, Broken Sword 2.5) would greatly benefit from hardware acceleration for their graphics code.
Difficulty level: Medium. Some knowledge of graphics APIs (ideally OpenGL) would help, and ideally a mobile device of some kind which can run ScummVM, to experiment with.
Obviously the purpose of this task is not to make it available on all ports. The impacted ports have to be determined in advance.
 
Some engines (such as Wintermute and Broken Sword 2.5) would greatly benefit from hardware acceleration for their graphics code. Since this is not possible for all ports, an important part of this work would be developing a suitable API.


See [[OpenTasks/Graphics/Hardware Acceleration]] for more details.
See [[OpenTasks/Graphics/Hardware Acceleration]] for more details.
Line 141: Line 194:
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]].
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]].


ScummVM's current OS X port is SDL 1.2 based, which is a dead project, having been replaced by SDL2, and Apple has a tendency to change and deprecate functionality with each version of their OS, as such, the current state of the OS X port seems to degrade with each new OS X release. Functionality added in newer releases of OS X, such as the new Full-screen modes introduced in 10.7 are also not available for use in ScummVM with the current SDL1.2 port.
Difficulty level: Medium. You'll need to know C++ and Objective C (and ideally have some Cocoa experience), and have a Mac.
 
ScummVM's current OS X port is based on SDL 1.2, which is a dead project (having been replaced by SDL2); this means that the current state of the OS X port seems to degrade with each new OS X release. Also, functionality added in newer releases of OS X (such as the new full-screen modes introduced in 10.7) are not available for use in ScummVM.
 
One option for solving this would be to create a backend for OS X that doesn't use SDL. This would mean writing/porting replacement code for the parts where SDL currently handles things (i.e. at least audio, video and input, and ideally other details too). Preferably, such a project would be to retain backwards compatibility with 10.2 as we have today, while also allowing for a good user experience on the very latest OS X versions.
 
=== Text to speech ===
 
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Strangerke|Arnaud Boutonné]] or [[User:criezy|Thierry Crozat]]
 
We have two suggested tasks in the direction of text-to-speech:
 
'''Adding text-to-speech support in Mortville Manor'''
 
Difficulty: Easy (depending on how you want to approach the task); just knowledge of C++ and some experience programming should suffice.
 
The original [[Mortville Manor]] game used a speech synthesis system based on PC Speaker.
 
Our hope for this task would be to replace this obsolete speech synthesis with an external dependency which would allow the implementation of modern text-to-speech generation, in (at least) French, German and English. We have some ideas for which libraries would be suitable, but we're also open to suggestions (and offering the option of platform-specific APIs is also a possibility).
 
'''Adding speech synthesis of on-screen text for people with reduced sight or for learning to read'''
 
Difficulty: Medium. You'll need to be comfortable enough with C++ to be able to (quickly) understand enough of the existing engine code in order to add this functionality.
 
Using the same library used in the previous task, it would be nice to have similar text-to-speech generation for other games. The challenge here would (hopefully) be to add the necessary interfaces for providing the text, and any needed other information (such as timing), to individual game engines. Part of your preparatory work would be working out (with our help) which engines to target.
 
This task would allow people suffering from sight issues to play more games in ScummVM, and it could also be very useful to help people who are learning to read.
 
Alternatively (or additionally), you could consider adding other accessibility features.
 
=== Cloud integration ===
 
Technical contacts: [[User:Sev|Eugene Sandulenko]], [[User:uruk|Peter Bozso]] or talk to us on IRC or send an e-mail
 
Difficulty: Medium. You'll need knowledge of C++, and learn or know about APIs of selected cloud services.
 
Cloud integration would make it possible to transparently share savegame and game data files between devices. The more providers (Google Drive/Dropbox/OneDrive/OwnCloud/etc...) we could support, the better. ScummVM supports many platforms (Windows, Mac OS X, Linux, iOS, Android, and many others), so any solution would also need to be sufficiently portable.
It would be also nice to have an option for users who don't want to use a cloud service or can't access their device's file system fully (for example on iOS), where they can configure their own server as the data provider.
 
=== SCI tools ===
 
Technical contacts: our SCI team; talk to us on IRC, or send an e-mail


One option for solving this, is to create a backend for OS X that doesn't use SDL. This would mean writing replacement code for the parts where SDL currently handles things (i.e. atleast audio/video/input, but possible other details). A major aim of such a project would be to retain backwards compatibility with 10.2 as we have today, while allowing for a good user experience on the very latest OS X versions as well.
Difficulty: Medium. You'll need to know or learn about SCI internals.


'''This task requires C++ and Objective-C/Cocoa knowledge.'''
We're in the process of reverse engineering modern SCI games (SCI32 games, from the generation of Gabriel Knight 1, Quest for Glory 4, Space Quest 6, etc.). For testing and debugging purposes, having access to good tools to study data files, resources, scripts, and run-time behaviour can be very useful. A number of such tools already exist, including some of our own tools, tools from FreeSCI which need porting to ScummVM, and a few external tools. You may identify gaps in the currently available tools, and in discussion with our SCI development team, propose ways of improving or integrating these tools, with the goal of making it easier to develop support in ScummVM for SCI32 games.

Latest revision as of 14:02, 21 March 2016

If you'd like to get involved in ScummVM - or one of our sister projects, such as ResidualVM - we'd love to help you get started!

We've had a lot of successful student projects as part of Google's Summer of Code in previous years -- we hope to inspire you to work with us and (hopefully) add your own success.

For any work on ScummVM, you'll probably need to already be comfortable with a basic level of C++. Some of the tasks might need more specialised knowledge (for example, working with ResidualVM may need you to understand some OpenGL and 3D math); we give our thoughts about this alongside each suggested task, below.

Most importantly, we'd like you to join our community. There are many previous GSoC participants who are still involved in our project, and whether or not you participate as part of Summer of Code, we'd love for you to get involved too.

You should come to our IRC Channel and introduce yourself! We're friendly, and it's often the easiest way to ask questions about the tasks and the code in general. 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, answer questions and help out.

You can find more information about what we expect from you before you apply at GSoC Application.

Introduction

We have a list of potential tasks further down on this page, but before you look at them, perhaps you'd like to take a look at some of the successful projects from previous years! We encourage all of our students to maintain a blog during their summer work, which is a nice way to get some sense of what they accomplished.

One popular type of task is to improve our support for the games you love, whether this means a new game engine, or helping us to perfect an existing one.

Sometimes source code is available - in recent summers, students integrated code supporting games such as Sfinx (blog), The Prince and the Coward (blog) and Avalanche (blog) into ScummVM. In fact, our support for the Wintermute engine was not only started by a GSoC student (blog), who integrated the code into our tree, but also drastically improved by another student a year later (blog).

GSOC EMI.png GSOC zvision.png GSOC EMI asm.png

A more challenging (but hopefully rewarding) idea is to start (or continue) reverse engineering a game where no source is available. Two good examples are the pair of students who drastically improved ResidualVM's support for Escape from Monkey Island (blog, blog), and the work on improving Operation Stealth (blog). Another option is to work on merging (and improving) someone else's reverse engineering work, such as was done with the ZVision engine (blog).

If you'd prefer to improve ScummVM more directly, there are even more options available there; in the past, students have (to give some examples) improved our OpenGL support, added a testing framework (blog), improved our scaler code (blog), written a new GUI framework, added loadable modules for embedded platforms (blog), rearchitected our keyboard input code (blog) and added support for high-colour (16bpp and above) graphics. It's difficult for us to imagine ScummVM as it was before some of these projects, you can make a huge difference!

Tasks

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

The ideas here are meant to be just that - ideas. We hope they help inspire your proposals, but you should also consider suggesting your own completely new project ideas. Pick something you really want to see improved/fixed, and come and talk to us about it!

If you're looking for more inspiration for ideas, beware of our TODO (and the other TODO lists linked from there) and our OpenTasks pages. Many of the tasks listed there might be incomplete or outdated, or too difficult for a new developer. The best thing to do is to come and talk to us!

GUI Tasks

Our current GUI could use refreshing and updating, in particular to improve how it works with newer platforms such as iOS or Android. We have a few suggested tasks:

Improve touchscreen GUI

Technical contacts: Eugene Sandulenko.

Difficulty level: Easy (code) / medium (architecture). You'll need a touchscreen device which can run ScummVM, to test on.

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.

Improve Main GUI

Technical contacts: Eugene Sandulenko.

Difficulty level: Easy.

We have a wishlist for improved GUI widgets; we'd like better sliders, multiline text widgets, an improved list widget, and better widgets for PopUps.

Also, several years ago, we switched to a new XML-based and vector-based GUI, but unfortunately during this transition number of nice touches were lost. In particular, the current GUI lacks soft shadows and antialiasing in number of places. We'd like them back! At the same time, it would be nice to add support for transparent PNG files.

Finally, it would be nice to have support for a scalable GUI which looks good at modern resolutions, which would require changes to our theme format, among other improvements.

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

Game Tasks

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

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.

If you don't feel quite up to that level of challenge, we have lots of other suggestions:

Macromedia Director

Technical contacts: Fuzzie

Difficulty level: Medium. You'll need a reasonable level of programming experience, and probably some Director games.

Many 90s-era adventure games were developed using the Macromedia (now Adobe) Director tool. It would be nice to be able to play these games in ScummVM! We have Python code available which can parse and display the contents of Director 2 and Director 3 'movie' files. This should be enough to implement a ScummVM engine to allow some early Director adventures to be played; for example, parsing the movie files, implementing the frame-based playback system, drawing bitmaps and shapes, playing sounds and running some basic (Lingo) scripting.

Port WebVenture engine

Technical contacts: John Willis, Filippos Karapetis.

Difficulty level: Medium. You'll need to understand JavaScript, as well as a good level of C++.

It would be great to support games which were written for the MacVenture engine from ICOM Simulations. It was used in the late 80s and in the early 90s for 4 games. The MacVenture games are still available for purchase from Zojoi.

The WebVenture engine by Sean Kasun is a reimplementation of this engine, so we (hopefully) already know enough about how it works. Of course, the current code is written in JavaScript, which means we can't use it directly; a new engine needs to be written (in C++) and integrated into ScummVM.

Wintermute 3D

Technical contacts: Einar Johan Trøan Sømåen, Paweł Kołodziejski

Difficulty level: Medium/hard. You'll need to be able to understand 3D graphics, and rearchitecture/design the relevant parts of the engine.

In 2012, support for games using the Wintermute engine was merged into ScummVM, but it still lacks support for games which use 3D graphics. It would be great to be able to play these games in ResidualVM!

ResidualVM project. See Wintermute 3D for more details.

In Cold Blood engine refactor

Technical contacts: Einar Johan Trøan Sømåen, Paweł Kołodziejski, Joost Peters

Difficulty level: Medium/hard. You'll need to be able to understand the relevant parts of the engine.

ResidualVM project. See ICB engine refactor for more details

Improve SCI support

Technical contacts: Our SCI team; talk to us on IRC, or send an e-mail.

Difficulty level: Hard. Good C++ knowledge and some knowledge of x86 assembly.

ScummVM has stable support for the older Sierra SCI games, but the newer ones -- such as Space Quest 6, Quest for Glory 4, Gabriel Knight 1 -- still need extensive work. As this is also something we are very actively working on ourselves, please come talk to us if you would be interested in helping out with reverse engineering and re-implementation.

Dink Smallwood engine (Cancelled)

Technical contacts: strangerke, dreammaster

Difficulty level: Medium. Good C++ knowledge.

Dink Smallwood is an action RPG video game, developed by Robinson Technologies, at the time consisting of Seth Robinson, Justin Martin, and Greg Smith. It was first released in 1998 before being released as freeware on October 17, 1999. The game has a small but constant fan following that continues to develop add-ons for the game more than 15 years after its release. The game is also notable for its humorous dialogue and surrealistic themes in various scenes between the gameplay.

The purpose of the task is to port the available sources of Dink Smallwood on top of ScummVM's OSystem framework and to make sure it also have a good support of fan's MOD. (about 350 games currently)

This task has been cancelled due to the existence of the very good and active project FreeDink. The scope of this project has been misunderstood when the task was added. All our apologies.

Dungeon Master engine

Technical contacts: strangerke, dreammaster

Difficulty level: Medium. Good C++ knowledge.

Dungeon Master was released on 15 December 1987 on the Atari ST, and by early 1988 was a strong seller, becoming the best-selling game for the computer of all time. It then was ported to Amiga, PC DOS and many other platforms, with the same success. It's considered nowadays to be a reference in RPG game, possibly the title who made the genre popular.

The purpose of the task is to port Dungeon Master's engine and implement it on top of ScummVM's OSystem framework and to make sure it also have a good support of fan's MOD.

Bring your own Adventure or RPG

Technical contacts: Talk to us on IRC, or send us an email.

Difficulty: Hard. You'll need good knowledge of C++, as well as knowledge of (reading) assembly.

Our project consists of re-implementations of classic games, and we have listed a number of potential new game engines that you could work on here on our ideas page. However, you may have a classic 2D Adventure game or Role Playing Game (RPG) you are interested in yourself that is suitable for ScummVM that you would like to reverse engineer and re-implement. If so, great!

Adding a completely new game engine is not easy, and you will have to convince us that you are aware of the challenges involved, that the game you are interested in is feasible, and that you have the necessary skills. Preferably, you will already have done some preliminary investigation, into for example data file formats, disassembly, etc.

Please come talk to us to see if we have a mentor who would be interested in working with you on such a game. We'd be happy to help out.

Infrastructure Tasks

Finally, there's always plenty of other practical tasks on our wishlist!

Improve Android port

Technical contacts: Fuzzie

Difficulty level: Medium/hard. You'll need some knowledge of C++, Java and ideally Android development and OpenGL. Access to at least one Android device is probably also necessary.

Our current Android port is in need of improvement, especially combined with modern versions of Android. We'd like to improve the GUI and the input code in particular, but hopefully you also have your own ideas if you've tried the port (if you haven't: do so!). There are some patches already available, and it should be possible to merge code from other projects (such as SDL 2). A native configuration GUI could also be an option.

Improve audio device configuration

Technical contact: Johannes Schickel.

Difficulty level: Medium. You'll need enough C++ experience and knowledge to design a suitable solution.

Our configuration currently doesn't support all the audio and MIDI options we would like, and even common configurations cannot always be conveniently specified.

See OpenTasks/Audio/Audio Output Selection and OpenTasks/Audio/MIDI Device Configuration for more discussion and some technical details of two possible tasks in this direction.

Hardware accelerated blitting

Technical contacts: preferably Johannes Schickel, otherwise Einar Johan Trøan Sømåen, Alyssa Milburn or David G. Turner

Difficulty level: Medium. Some knowledge of graphics APIs (ideally OpenGL) would help, and ideally a mobile device of some kind which can run ScummVM, to experiment with.

Some engines (such as Wintermute and Broken Sword 2.5) would greatly benefit from hardware acceleration for their graphics code. Since this is not possible for all ports, an important part of this work would be developing a suitable API.

See OpenTasks/Graphics/Hardware Acceleration for more details.

Native OS X port

Technical contacts: Einar Johan Trøan Sømåen, Paweł Kołodziejski.

Difficulty level: Medium. You'll need to know C++ and Objective C (and ideally have some Cocoa experience), and have a Mac.

ScummVM's current OS X port is based on SDL 1.2, which is a dead project (having been replaced by SDL2); this means that the current state of the OS X port seems to degrade with each new OS X release. Also, functionality added in newer releases of OS X (such as the new full-screen modes introduced in 10.7) are not available for use in ScummVM.

One option for solving this would be to create a backend for OS X that doesn't use SDL. This would mean writing/porting replacement code for the parts where SDL currently handles things (i.e. at least audio, video and input, and ideally other details too). Preferably, such a project would be to retain backwards compatibility with 10.2 as we have today, while also allowing for a good user experience on the very latest OS X versions.

Text to speech

Technical contacts: Our IRC channel, our mailing list, or contact Arnaud Boutonné or Thierry Crozat

We have two suggested tasks in the direction of text-to-speech:

Adding text-to-speech support in Mortville Manor

Difficulty: Easy (depending on how you want to approach the task); just knowledge of C++ and some experience programming should suffice.

The original Mortville Manor game used a speech synthesis system based on PC Speaker.

Our hope for this task would be to replace this obsolete speech synthesis with an external dependency which would allow the implementation of modern text-to-speech generation, in (at least) French, German and English. We have some ideas for which libraries would be suitable, but we're also open to suggestions (and offering the option of platform-specific APIs is also a possibility).

Adding speech synthesis of on-screen text for people with reduced sight or for learning to read

Difficulty: Medium. You'll need to be comfortable enough with C++ to be able to (quickly) understand enough of the existing engine code in order to add this functionality.

Using the same library used in the previous task, it would be nice to have similar text-to-speech generation for other games. The challenge here would (hopefully) be to add the necessary interfaces for providing the text, and any needed other information (such as timing), to individual game engines. Part of your preparatory work would be working out (with our help) which engines to target.

This task would allow people suffering from sight issues to play more games in ScummVM, and it could also be very useful to help people who are learning to read.

Alternatively (or additionally), you could consider adding other accessibility features.

Cloud integration

Technical contacts: Eugene Sandulenko, Peter Bozso or talk to us on IRC or send an e-mail

Difficulty: Medium. You'll need knowledge of C++, and learn or know about APIs of selected cloud services.

Cloud integration would make it possible to transparently share savegame and game data files between devices. The more providers (Google Drive/Dropbox/OneDrive/OwnCloud/etc...) we could support, the better. ScummVM supports many platforms (Windows, Mac OS X, Linux, iOS, Android, and many others), so any solution would also need to be sufficiently portable. It would be also nice to have an option for users who don't want to use a cloud service or can't access their device's file system fully (for example on iOS), where they can configure their own server as the data provider.

SCI tools

Technical contacts: our SCI team; talk to us on IRC, or send an e-mail

Difficulty: Medium. You'll need to know or learn about SCI internals.

We're in the process of reverse engineering modern SCI games (SCI32 games, from the generation of Gabriel Knight 1, Quest for Glory 4, Space Quest 6, etc.). For testing and debugging purposes, having access to good tools to study data files, resources, scripts, and run-time behaviour can be very useful. A number of such tools already exist, including some of our own tools, tools from FreeSCI which need porting to ScummVM, and a few external tools. You may identify gaps in the currently available tools, and in discussion with our SCI development team, propose ways of improving or integrating these tools, with the goal of making it easier to develop support in ScummVM for SCI32 games.