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

From ScummVM :: Wiki
Jump to navigation Jump to search
(initial page, everything should be rewritten (almost))
 
(→‎Smaller Tasks: added keymapper task)
 
(15 intermediate revisions by 4 users not shown)
Line 7: Line 7:
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 [[Discord Server]] and introduce yourself in the #scummvm-gsoc channel! 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]].
You can find more information about what we expect from you before you apply at [[GSoC Application]].
Line 29: Line 29:
== Tasks ==
== Tasks ==


General contacts: Our IRC channel, our mailing list, or contact [[User:Sev|sev]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]]
General contacts: Our Discord server our mailing list, or contact [[User:Sev|sev]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]]


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!
Line 37: Line 37:
== Game Tasks ==
== Game Tasks ==


Technical contacts: Our IRC channel, our mailing list, or contact [[User:Sev|sev]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]], [[User:Md5|Filippos Karapetis]],
Technical contacts: Our Discord channel, our mailing list, or contact [[User:Sev|sev]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]], [[User:Md5|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 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.
Line 50: Line 50:
[[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 a WIP engine in ScummVM tree, but it requires much more work in order to implement all hundreds of Lingo commands.
[[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 a WIP engine in ScummVM tree, but it requires much more work in order to implement all hundreds of Lingo commands.


=== Enhance SAGA engine ===
=== Enhance SAGA engine for supporting Amiga Inherit the Earth ===
Technical contacts: [[User:Sev|sev]]
Technical contacts: [[User:Sev|sev]]


Line 57: Line 57:
We have been supporting the [[Inherit the Earth]] game for a long while. However, Amiga versions are not yet supported by this target. We have the original source codes, and the main difference is the data bundles format.
We have been supporting the [[Inherit the Earth]] game for a long while. However, Amiga versions are not yet supported by this target. We have the original source codes, and the main difference is the data bundles format.


An additional target is to support Chinese version of ITE, that would require reverse engineering with Ghidra, in order to understand how the game does rendering of CJK glyphs.
=== SAGA2 engine ===
 
Technical contacts: [[User:Sev|sev]]
=== Wintermute 3D ===
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!
 
'''ResidualVM project.''' See [http://wiki.residualvm.org/index.php/GSoC_Ideas#Wintermute_3D_port Wintermute 3D] for more details.
 
=== 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]]
 
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
 
=== The Immortal ===
 
Technical contacts [[User:dreammaster|dreammaster]] or [[User:Strangerke|Strangerke]]
 
Difficulty level: Hard. Good knowledge of C++ and assembly (x86 or 68K or 6502) is required.
 
The immortal was released in 1990 by Electronic Arts. It's a mix of genres involving RPG elements with action and puzzles.
The gameplay is different one variant to the other, and all variants are written in assembly, making it more difficult to support all the variants.


In 2018, a GSoC student picked this task but, due to personal issues, didn't manage to complete the task. The purpose of the task is therefore to implement an engine for a variant of the game, using the original sources and the work of JoeFish as a documentation.
Difficulty level: High.


[https://www.mobygames.com/game/immortal/screenshots Screenshots on Mobygames]
We have full sources for [[Halls of the_Dead: Faery Tale Adventure II]] game. This needs to be refactored and brought to ScummVM's OSystem framework. This task requires a decent knowledge of C++ and some x86 assembly (relatively little).


Beware, that the task is ''very'' big, you will have to deal with 90k lines of code and must make the game at least playable. If there is not enough time within GSoC, you would need to spend some time after the program and reach the milestone of playability.
=== Bring your own Adventure or RPG ===
=== Bring your own Adventure or RPG ===


Line 111: Line 88:
== Smaller Tasks ==
== Smaller Tasks ==


=== Unicode and BiDi support for GUI ===
=== Icon based game view and game grouping/filtering ===
Technical contacts: somaen
 
Difficulty: Easy
 
The current game list in ScummVM is a flat, but searchable list of games. Since these are games, most, if not all of them at some point came in boxes with fancy box art, and awesome logos on them,
and that art is a bit more appealing than a simple list of game titles. We currently allow for something a bit prettier for savegames, where we allow for showing a grid of screenshots. This concept
could be taken to the game list as well, allowing for replacing the list of titles with a grid of logos/box art. The logos themselves can be scraped from a variety of places online (perhaps Mobygames
or GoG?), or supplied by the end user manually. To signal the language of each title we would allow for putting a little flag on each title.
 


Technical contacts: [[User:Sev|sev]]
Another point that could be worked on with the game list, is the grouping. Currently the list is sorted by title, some people with larger libraries might prefer to group by company, or game engine instead,
similar to how a file-browser allows you to select what to sort by. Perhaps also allow for foldable groups (per engine, or per company?), similar to how folders work in a file-browser. Further ideas to
allow for better library management are also welcome.
 
=== Add Text To Speech (TTS) to more games ===
Technical contacts: criezy
 
Difficulty: Easy
 
ScummVM includes text-to-speech capabilities that are currently used to improve accessibility in the GUI, and to add speech to a few games. More games could benefit from it and the task will be to add text-to-speech to those.
 
=== Add Keymapper to more games ===
Technical contacts: sev
 
Difficulty: Easy


Difficulty: Easy. It will take up to 2 weeks to implement. C++ knowledge required.
ScummVM includes a global fully configurable keymapper, but this requires engines to be adapted to use it. The feature documentation: [[Keymapper]], some reference implementations: Wintermute has [https://github.com/scummvm/scummvm/blob/master/engines/wintermute/keymapper_tables.h per-game keymaps]; [https://github.com/scummvm/scummvm/pull/2428 a pull request] with adding keymapper to HDB engine; [https://github.com/scummvm/scummvm/commit/cce713ee4c73504e97eba8b0ca9190e47d279e69 a commit] with adding Keymapper to a simpler engine, Griffon.




ScummVM GUI is based on char size strings, so we have to rely on code pages. With this task, you would need to switch our GUI to usage of Common::U32String, thus making it Unicode-friendly.
=== Support Unicode input in GUI ===
Technical contacts: [[User:Sev|sev]]


Along the way, we would need support for right-to-left languages, and basically flip the widgets horizontally.
Difficulty: Medium


Last year we enhanced our GUI for supporting Unicode output. Now we need to enhance our input system, so Unicode input is supported as well. This includes RTL support (we have FriBiDi employed for output).


== Infrastructure Tasks ==
== Infrastructure Tasks ==
Line 143: Line 145:
Difficulty: Medium
Difficulty: Medium


ScummVM uses software scalers for graphics enhancements. In 2012 we were running GSoC for turning them into plugins. [https://github.com/scummvm/scummvm/pull/271 That work] needs to be completed, basically, it is just rebasing of the patch. The rebasing was started here: https://github.com/digitall/scummvm/tree/gsoc2012-scalers-cont
ScummVM uses software scalers for graphics enhancements. In 2012 we were running GSoC for turning them into plugins. [https://github.com/scummvm/scummvm/pull/271 That work] It was recently merged in ScummVM but could require some more love like adding xBRZ scalers.


Modern systems often have OpenGL with shader support. RetroArch project shaders are standard for them in open source gaming. LordHoto started work on adding support for those to ScummVM. His unfinished work could be found here: https://github.com/lordhoto/scummvm/tree/libretro-shader
Modern systems often have OpenGL with shader support. RetroArch project shaders are standard for them in open source gaming. LordHoto started work on adding support for those to ScummVM. His unfinished work could be found here: https://github.com/lordhoto/scummvm/tree/libretro-shader
Line 166: Line 168:


The scope of the project is to design and implement the base system in ScummVM for Windows and Unix (using Named pipes / Unix domain sockets for communication), and to write a high quality companion application for one of the game engines in ScummVM.
The scope of the project is to design and implement the base system in ScummVM for Windows and Unix (using Named pipes / Unix domain sockets for communication), and to write a high quality companion application for one of the game engines in ScummVM.
=== Move Detection Code to the Main Executable ===
Technical contacts: [[User:Sev|sev]], [[User:Criezy|criezy]]
Difficulty: Medium
ScummVM grows every year, and for decreasing the executable size, we have dynamic plugins system in-place. During detection, we are loading every plugin and try to detect files. The relevant code interface is called MetaEngine. This is not effective and quite slow.
What is needed in this task, is changing our plugin system, so detection-related part of MetaEngine goes straight into the main ScummVM executable, and the engines are not required to load for detection.
Benefits would be faster game detection as well as the ability to detect games even if the corresponding plugin is missing, and let the user know which plugin is missing and needed to play that game.
You need a medium knowledge of C++ for this task. Some bash shell knowledge is a plus.

Latest revision as of 18:06, 19 April 2021

If you'd like to get involved in ScummVM, 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.

We often get asks by students with no experience with ScummVM whether they have the necessary skills to participate with us. The idea of GSoC is to introduce students to open source development, so we are not expecting you to have experience with ScummVM. You will have time during the application and community bonding periods to familiarize yourself with the project. The technical skills required to work with us varies from task to task. 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 specialized knowledge (working on a 3D game engine may need you to understand some OpenGL and 3D math, and some engine tasks may require some assembly or reverse engineering knowledge); 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 Discord Server and introduce yourself in the #scummvm-gsoc channel! 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 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 Discord server our mailing list, or contact sev, John Willis, Arnaud Boutonné

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!

Game Tasks

Technical contacts: Our Discord channel, our mailing list, or contact sev, 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: sev

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 a WIP engine in ScummVM tree, but it requires much more work in order to implement all hundreds of Lingo commands.

Enhance SAGA engine for supporting Amiga Inherit the Earth

Technical contacts: sev

Difficulty level: Medium.

We have been supporting the Inherit the Earth game for a long while. However, Amiga versions are not yet supported by this target. We have the original source codes, and the main difference is the data bundles format.

SAGA2 engine

Technical contacts: sev

Difficulty level: High.

We have full sources for Halls of the_Dead: Faery Tale Adventure II game. This needs to be refactored and brought to ScummVM's OSystem framework. This task requires a decent knowledge of C++ and some x86 assembly (relatively little).

Beware, that the task is very big, you will have to deal with 90k lines of code and must make the game at least playable. If there is not enough time within GSoC, you would need to spend some time after the program and reach the milestone of playability.

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.

Smaller Tasks

Icon based game view and game grouping/filtering

Technical contacts: somaen

Difficulty: Easy

The current game list in ScummVM is a flat, but searchable list of games. Since these are games, most, if not all of them at some point came in boxes with fancy box art, and awesome logos on them, and that art is a bit more appealing than a simple list of game titles. We currently allow for something a bit prettier for savegames, where we allow for showing a grid of screenshots. This concept could be taken to the game list as well, allowing for replacing the list of titles with a grid of logos/box art. The logos themselves can be scraped from a variety of places online (perhaps Mobygames or GoG?), or supplied by the end user manually. To signal the language of each title we would allow for putting a little flag on each title.


Another point that could be worked on with the game list, is the grouping. Currently the list is sorted by title, some people with larger libraries might prefer to group by company, or game engine instead, similar to how a file-browser allows you to select what to sort by. Perhaps also allow for foldable groups (per engine, or per company?), similar to how folders work in a file-browser. Further ideas to allow for better library management are also welcome.

Add Text To Speech (TTS) to more games

Technical contacts: criezy

Difficulty: Easy

ScummVM includes text-to-speech capabilities that are currently used to improve accessibility in the GUI, and to add speech to a few games. More games could benefit from it and the task will be to add text-to-speech to those.

Add Keymapper to more games

Technical contacts: sev

Difficulty: Easy

ScummVM includes a global fully configurable keymapper, but this requires engines to be adapted to use it. The feature documentation: Keymapper, some reference implementations: Wintermute has per-game keymaps; a pull request with adding keymapper to HDB engine; a commit with adding Keymapper to a simpler engine, Griffon.


Support Unicode input in GUI

Technical contacts: sev

Difficulty: Medium

Last year we enhanced our GUI for supporting Unicode output. Now we need to enhance our input system, so Unicode input is supported as well. This includes RTL support (we have FriBiDi employed for output).

Infrastructure Tasks

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

Game packaging system

Technical contacts: sev or DJWillis

ScummVM offers 9 freeware games for download, but they need to be downloaded and installed manually. It would be great to develop a universal system which would let us describe a game, e.g. provide screenshots, game descriptions, metadata, and package it for different platforms, so we could put them to different application distribution systems bundled together with ScummVM. For example, we could have Beneath a Steel Sky bundled together with ScummVM, with its own logo, description and instructions on how to add another game along the way.

Potentially and in the future this system could also be used for DLC on platforms which support it, like Steam, Android Play Store or Apple App Store, though support for Android and iOS is out of scope for this project.

Examples are: Linux packages, Google Play, Apple App Store, Steam, ForgeTV store, and anything beyond that.

Support for shaders and arbitrary scalers

Technical contacts: sev

Difficulty: Medium

ScummVM uses software scalers for graphics enhancements. In 2012 we were running GSoC for turning them into plugins. That work It was recently merged in ScummVM but could require some more love like adding xBRZ scalers.

Modern systems often have OpenGL with shader support. RetroArch project shaders are standard for them in open source gaming. LordHoto started work on adding support for those to ScummVM. His unfinished work could be found here: https://github.com/lordhoto/scummvm/tree/libretro-shader

We need to add both improvements to our scaler system. Recent PSP2 port already adds some basics for scalers, particularly in GUI, so that could be reused too.

We need to have it tested on desktops and at least Android, but preferably also Windows and iOS.

Programming interface

Technical contacts: bgK

Difficulty: Medium

The goal of this project is to add a programming interface to ScummVM that other programs could use to interact with it. This would allow advanced users to write companion applications such as:

  • Game interface enhancement tools: Automappers for RPG / Interactive Fiction games. Interactive hint systems for adventure games.
  • Input automation tools: Regression testing / Tool Assisted Speedrun scripts.
  • Highly integrated frontends.
  • Debugging / game development tools.

The interface needs to be bi-directional with the companion application being able to send requests to query information from ScummVM and to receive responses, but also for ScummVM to send notifications to the clients. The interface needs to be easy to integrate with from various programming languages and easy to experiment with.

The scope of the project is to design and implement the base system in ScummVM for Windows and Unix (using Named pipes / Unix domain sockets for communication), and to write a high quality companion application for one of the game engines in ScummVM.