Difference between revisions of "GSoC Ideas"

From ScummVM :: Wiki
Jump to navigation Jump to search
(→‎Summer of Code Applications: Explain the general application layout in more detail.)
(Update to point to latest idea page)
 
(75 intermediate revisions by 11 users not shown)
Line 1: Line 1:
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.
+
 
 +
 
 +
----
 +
 
 +
'''See [[Summer of Code/GSoC Ideas 2019|GSoC Ideas 2019]]''' for the 2019 version of this page.
 +
 
 +
----
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
 
 +
<!--This page contains a list of ideas about projects/tasks for the ScummVM and the ResidualVM projects 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.
 +
 
 +
These are just the few projects that we have come up with ourselves, and there are many many other tasks which would be helpful to the project - many ScummVM engines have their own TODO lists, and there are large tasks related to ResidualVM engines.
  
 
Of course, if you are not participating in Summer of Code, you are also very welcome to try working on one of these projects.
 
Of course, if you are not participating in Summer of Code, you are also very welcome to try working on one of these projects.
Line 12: Line 30:
 
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.
 
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.
+
== 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.
  
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]].
+
When writing this application, remember that the application has several important purposes. First of all, it should identify the objectives of your project (what you intend to get done). Furthermore, it needs to convince us your project is worth the effort we will be putting into mentoring it. Last, but not least, it should convince us that you are the right person for this task.
  
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.
+
In particular, your application is your opportunity to show us that you understand what you'll be doing for the task! We expect you to demonstrate that you've spent some of your own time thinking about it. A good example of what we do ''not'' want to see in your application is a copy of the text from our version of an idea's description.
  
Finally: All of the code submitted must be contributed under the terms of the GPL v2+.
+
You '''must''' read the Summer of Code [[Summer of Code/Project Rules | Project Rules]], which are '''obligatory''' for our students, and tell you what you should do '''before you apply'''. There are also some [[Summer of Code/Students Guidelines | Guidelines]] for our students.
  
=== [[Summer of Code]] Applications ===
+
We don't expect you to produce a perfect application without any help at all (although of course, that would be even more impressive), but we do expect you to show some independent insight into the task you've chosen, and to be willing to improve it based on our feedback and comments.
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 [[Summer of Code/Project Rules | Project Rules]], which are '''obligatory''' for our students, and tell you what you should do '''before you apply'''. There are also some [[Summer of Code/Students Guidelines | Guidelines]] for our students.
+
=== Application template ===
  
Your application should have at least the following information (adapted from the FreeBSD [http://www.freebsd.org/projects/summerofcode.html Proposal Guidelines]):
+
Your application should have at least the following information (adapted from the FreeBSD guidelines):
  
* '''Name'''
+
* ''Name''
* '''Email'''
+
* ''Email''
* '''Online nicks'''
+
* ''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.
+
: You should at least add your IRC (freenode) nickname here.
* '''Project Title'''
+
* ''Project Title''
: State precisely what your project is about. 40 characters is usually a good upper limit.
+
: State precisely what you intend your project to be about. 40 characters is usually a good upper limit.
* '''Possible Mentor''' (optional)
+
* ''Possible Mentor'' (optional)
* '''Benefits to the ScummVM Community'''
+
* ''Benefits to the ScummVM Community''
: A good project will not just be fun to work on, but also generally useful to others.
+
: A good project will not just be fun to work on, but also generally useful to others. Why do you think it's a good project for us?
* '''Deliverables'''
+
* ''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.
+
: The deliverables will be used to evaluate your progress/success at the mid-term/final evaluations, so it's very important that you list some clear goals here. Some examples:
:* "Improve X modules in ways Y and Z."
+
:* "Get scene X in game Y working."
:* "Write 3 new man pages for the new interfaces."
+
:* "Improve feature X in ways Y and Z."
 +
:* "Fix bug Z in game Q."
 +
:* "Write documentation for the new interfaces."
 
:* "Improve test coverage by writing X more unit/regression tests."
 
:* "Improve test coverage by writing X more unit/regression tests."
:* "Improve performance in FOO by X%."
+
:* "Improve performance in this game scene by 20%."
: 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 benefitial 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.
+
: 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.
: 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.
+
: You should be sure to justify whether a goal is vital for the success of your project, or just optional, but be make sure not to mix this up with the description of the goals themselves.
* '''Project Schedule'''
+
: Finally, be sure to describe some '''milestones''', your targets for the project. 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.
: Create a schedule with (at least) the granularity of weeks here. 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.
+
* ''Project Schedule''
* '''Availability'''
+
: Create a proposed schedule with (at least) the granularity of weeks. This schedule should (among other things) explain how long your project will take and when you can begin to work on it, and you should connect the weeks to the Summer of Code schedule, i.e. clearly make the start, mid-term evaluations, etc. visible. There are multiple ways to organize this, we trust you to find the best way to present your schedule.
: How many hours per week can you spend working on this? What other obligations do you have this summer?
+
: Obviously we want to see a connection between your goals and your schedule: be sure to elaborate why you think X takes time Y and what possible issues might arise here; obviously your schedule will probably change once you've started working on your project, so we want to know what kind of risks and problems you think might cause such changes.
* '''Skype ID'''
+
: Last but not least, put a fixed date for each milestone you defined here. We want at least one milestone before the mid-term.
 +
* ''Availability''
 +
: How many hours per week can you spend working on this? What other obligations do you have this summer? Be honest if you're not going to have time in some weeks (due to exams, or vacation, or other work), and explain how plan to make this up.
 +
* ''Skype ID''
 
: If you don't use Skype, install it.
 
: If you don't use Skype, install it.
* '''Phone Number'''
+
* ''Phone Number''
 
: Cellular is preferable, for emergency contacts.
 
: Cellular is preferable, for emergency contacts.
* '''Timezone'''
+
* ''Timezone''
 
: Where do you live.
 
: Where do you live.
* '''Bio'''
+
* ''Bio''
 
: The two main questions you should answer here are:
 
: The two main questions you should answer here are:
 
:* Who are you?
 
:* Who are you?
 
:* What makes you the best person to work on this project?
 
:* 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)?
 
: 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'''
+
* ''Pull Request''
 
: A link to the pull request you submitted as part of our [[Summer of Code/Project Rules | Project Rules]]
 
: A link to the pull request you submitted as part of our [[Summer of Code/Project Rules | 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.
+
=== Coding Rules ===
 +
 
 +
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.
  
== Audio Output Configuration ==
+
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+.
 +
 
 +
== ScummVM Projects ==
 +
=== Audio Output Configuration ===
  
 
Technical contact: [[User:LordHoto|Johannes Schickel]].
 
Technical contact: [[User:LordHoto|Johannes Schickel]].
Line 71: Line 103:
  
 
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.
 
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.
 +
 +
'''As this task involves a very precise design before starting implementation, please keep in touch with the mentors as soon as possible if you're interested.'''
  
 
See [[OpenTasks/Audio/Audio Output Selection]] for more discussion and some technical details.
 
See [[OpenTasks/Audio/Audio Output Selection]] for more discussion and some technical details.
  
== MIDI Device Configuration ==
+
=== MIDI Device Configuration ===
  
 
Technical contact: [[User:LordHoto|Johannes Schickel]].
 
Technical contact: [[User:LordHoto|Johannes Schickel]].
Line 81: Line 115:
  
 
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).
 
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).
 +
 +
'''As this task involves a very precise design before starting implementation, please keep in touch with the mentors as soon as possible if you're interested.'''
  
 
See [[OpenTasks/Audio/MIDI Device Configuration]] for more discussion and some technical details.
 
See [[OpenTasks/Audio/MIDI Device Configuration]] for more discussion and some technical details.
  
== Improve Main GUI ==
+
=== Improve Main GUI ===
  
 
Technical contacts: [[User:Sev|Eugene Sandulenko]].
 
Technical contacts: [[User:Sev|Eugene Sandulenko]].
Line 94: Line 130:
 
See [[OpenTasks/Generic/Improve GUI Look]] for more details.
 
See [[OpenTasks/Generic/Improve GUI Look]] for more details.
  
== Improve touchscreen GUI ==
+
=== Improve touchscreen GUI ===
  
 
Technical contacts: [[User:Sev|Eugene Sandulenko]].
 
Technical contacts: [[User:Sev|Eugene Sandulenko]].
Line 107: Line 143:
 
See [[OpenTasks/Generic/Touch GUI]] for more details.
 
See [[OpenTasks/Generic/Touch GUI]] for more details.
  
== Avalanche Engine ==
+
=== 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: [[User:Strangerke|Arnaud Boutonné]], [[User:Sev|Eugene Sandulenko]].
+
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.
  
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 [http://www.mobygames.com/game/dos/lord-avalot Lord Avalot d'Argent].
+
=== Improve AGI Engine ===
 +
Technical contacts: [[User:Sev|Eugene Sandulenko]].
  
The sources has been given under GPLv2, as well as the game data.  
+
The current implementation of our AGI Engine, which is used for the early Sierra On Line games; would greatly benefit from some implementation details present in the other open source AGI interpreter, NAGI.
  
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.
+
The important parts of this task would be to analyze the implementation differences between the ScummVM implementation and NAGI, particularly in the main loop and in the rendering class, then to reimplement these in the ScummVM engine without causing regressions of the currently supported games and to improve the support of the latest AGI games including the fangames.
  
See [[OpenTasks/Engine/Avalanche]] for more details.
+
See [[OpenTasks/Engine/ImproveAGI]] for more details.
  
== Improving WME engine ==
+
=== Adding text to speech support in Mortville Manor ===
Technical contacts: Our IRC channel, our mailing list, or contact [[User:somaen|Einar Johan Trøan Sømåen]]
+
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Strangerke|Arnaud Boutonné]] or [[User:criezy|Thierry Crozat]]
  
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.
+
The original Mortville Manor game was using a speech synthesis based on PC Speaker.  
  
See [[OpenTasks/Engine/Improve WME]] for more details.
+
The purpose of this task is to replace obsolete speech synthesis by an external dependency which will allow to implement a
 +
decent text to speech generation, in (at least) French, German and English.
  
== Hardware accelerated blitting ==
+
=== Adding speech synthesis of on-screen text for people with reduced sight or for learning to read ===
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]]
+
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Strangerke|Arnaud Boutonné]] or [[User:criezy|Thierry Crozat]]
  
Some engines (Wintermute, Broken Sword 2.5) would greatly benefit from hardware acceleration for their graphics code.
+
Using the same library used in the previous task, add a similar text to speech generation for other games. The exact list of titles should be defined as soon as possible between the mentors and the student.
Obviously the purpose of this task is not to make it available on all ports. The impacted ports have to be determined in advance.
+
 
 +
This task would allow people suffering of sight issues to play more games in ScummVM, but it could also be very useful to help people to learn how to read.
 +
 
 +
=== Macromedia Director ===
 +
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Fuzzie|Alyssa Milburn]], [[User:Clone2727|Matthew Hoops]]
 +
 
 +
Many 90s-era adventure games were developed using the Macromedia (now Adobe) Director tool. They don't run any more on modern systems, and current versions of Director can't even open the files (and too much has changed; Macromedia themselves have said that "reauthoring the movie from scratch" is often more efficient). It would be nice to be able to play these games in ScummVM!
 +
 
 +
There is already (Python) code available which can parse and display the contents of Director 2 and Director 3 'movie' files, and the basic framework of a ScummVM C++ engine. The task would involve trying to implement enough of 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.
 +
 
 +
=== AGS ===
 +
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Fuzzie|Alyssa Milburn]]
 +
 
 +
The Adventure Game Studio engine has been open sourced. It would be nice to have it available (at least for legacy games) as part of ScummVM, so it can benefit from our platform support.
 +
 
 +
There's an existing unfinished partially-rewritten(!) engine for ScummVM (see [[AGS]]) which is missing some core functionality (such as save/load code) but already allows you to complete some AGS games. Adding save/load functionality (not trivial) and implementing some of the other missing code would get it to a point where it could be merged into the main codebase.
 +
 
 +
'''This task almost certainly needs experience in understanding/refactoring of complex existing codebases, so please contact us as soon as possible if you're interested.'''
 +
 
 +
=== Port WebVenture engine ===
 +
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.
 +
 
 +
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.
 +
 
 +
'''This task requires C++ and JavaScript knowledge.'''
 +
 
 +
=== Native OS X port ===
 +
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.
 +
 
 +
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.
 +
 
 +
'''This task requires C++ and Objective-C/Cocoa knowledge.'''
 +
 
 +
=== Improving the iPhone/iOS port ===
 +
 
 +
Technical contact: [[User:LordHoto|Johannes Schickel]], [[User:Sev|Eugene Sandulenko]].
  
See [[OpenTasks/Graphics/Hardware Acceleration]] for more details.
+
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.
  
== Implement Z Engine ==
+
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.
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Md5|Filippos Karapetis]], [[User:Sev|Eugene Sandulenko]]
 
  
Using the existing engine available from http://github.com/Marisa-Chan/Zengine, write an engine implementation for ScummVM.
+
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.
This engine will have to support Zork Nemesis and Zork Grand Inquisitor.
 
  
See [[OpenTasks/Engine/Z Engine]] for more details.
+
'''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.'''
  
== Sources for other ideas ==
+
=== Sources for other ideas ===
  
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Sev|Eugene Sandulenko]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]]
+
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Sev|Eugene Sandulenko]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]], [[User:LordHoto|Johannes Schickel]]
  
 
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).
 
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.
 
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 ==
+
=== New game engines ===
 +
 
 +
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Sev|Eugene Sandulenko]], [[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.
 +
 
 +
== ResidualVM Projects ==
 +
This section contains project ideas for ResidualVM. You will need some basic knowledge of OpenGL and 3D math, in addition to any extra skills indicated in each entry.
 +
 
 +
=== Wintermute 3D ===
 +
Technical contacts: [[User:somaen|Einar Johan Trøan Sømåen]], [[User:aquadran|Paweł Kołodziejski]]
 +
 
 +
In 2012, the Wintermute engine was ported into ScummVM. However, as this was a port of the 2D-only Lite-version of WME, and since ScummVM is designed to run only 2D games, the ScummVM port has no support for the 3D parts of the engine, and is thus not able to run any of the games that use them.
 +
 
 +
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]]
 +
 
 +
See [http://wiki.residualvm.org/index.php/GSoC_Ideas#In_Cold_Blood_engine_refactor ICB engine refactor] for more details
 +
 
 +
=== iOS port ===
 +
Technical contacts: [[User:aquadran|Paweł Kołodziejski]], [[User:somaen|Einar Johan Trøan Sømåen]]
 +
 
 +
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.
 +
 
 +
See [http://wiki.residualvm.org/index.php/GSoC_Ideas#iOS_port_of_ResidualVM iOS Port] for more details
 +
 
 +
=== Sources for other ideas ===
 +
 
 +
Technical contacts: ResidualVM IRC channel (#residualvm on freenode.net), or contact [[User:aquadran|Paweł Kołodziejski]], [[User:somaen|Einar Johan Trøan Sømåen]]
 +
 
 +
=== New game engines ===
  
Technical contacts: Our IRC channel, our mailing list, or contact [[User:Sev|Eugene Sandulenko]], [[User:DJWillis|John Willis]], [[User:Strangerke|Arnaud Boutonné]]
+
Technical contacts: ResidualVM IRC channel (#residualvm on freenode.net), or contact [[User:aquadran|Paweł Kołodziejski]], [[User:somaen|Einar Johan Trøan Sømåen]]
  
 
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.
 +
-->

Latest revision as of 21:14, 5 March 2019



See GSoC Ideas 2019 for the 2019 version of this page.