GDevelop and Google Summer of Code

Google Summer of Code is a global program focused on bringing more student developers into open source software development. Students work with an open source organization on a 3 month programming project during their break from school.

This year, GDevelop is one of the mentoring organisations. If you're a student and interested in working with us, read on!

Results of GSoc 2020 projects will be written on this Result page.

Ideas list

Those ideas are not exhaustive. Feel free to suggest your own idea! Or combine ideas into your own. The descriptions are generic enough so that you can suggest different approaches, goals and stretch goals. Mentor(s) are available for all ideas listed already.

Revamped shortcuts/"Goto Anything" in the editor

GDevelop has support for a few shortcuts, but would benefit from new shortcuts to navigate between the tabs, do common tasks (run the game, export it, focus some editors). In particular, a shortcut to open a “Goto Anything”/“Command panel” popup like in popular text editors (VS Code, Sublime Text, JetBrains IDEs…) would allow power user to do things much more quickly. This will also make the software more accessible. Shortcuts can also be made customisable.

  • Outcome: revamped shortcuts in the whole editor, “goto anything”-like feature to run commands.
  • Skills: React.js (for the editor), JavaScript.
  • Difficulty: Easy

Improved Debugger and Profiler

GDevelop has a debugger and profiler that can be used when previewing a game. The debugger can list the objects, expose things like variables and allow to edit them. The profiler can measure the time for each part of the game. Both are still quite raw, so we could improve the UI to make it easier to filter objects, add export/import of data, show information in real time, show charts…

  • Outcome: debugger and profiler with improved features.
  • Skills: React.js (for the editor), JavaScript (for the engine), WebSockets (communication between editor and games)
  • Difficulty: Easy

WebAssembly for collisions

GDevelop will soon have an dedicated module to handle object position and collisions (as well as raycast and other algorithms)… but we could go further by writing it in WebAssembly, and benefit from increased performance.

  • Outcome: a library integrated into the game engine handling the object collisions (and associated operations) with benchmark against the old implementation.
  • Skills: C++ (or Rust, or a language that can be used to generate a WebAssembly library), JavaScript, Algorithms and data structure knowledge.
  • Type: Exploratory
  • Difficulty: hard

Objects that can be containers for sub objects ("nodes")

All objects in a GDevelop scene are stored in a list. For making complex objects in a game, it can be useful to combine multiple of them on the screen (for example, a car can be composed of two Sprite objects for wheels and a Sprite for the rest of the car). A new feature allowing to compose objects by assembling other “sub objects” would allow make this easy. It would also improve the game authoring experience, making the list of objects clearer - and objects easier to reuse.

  • Outcome: feature allowing to create objects composed of other objects and design a level with them.
  • Skills: JavaScript (React for the interface, Vanilla JS for the game engine), a bit of C++ will be required.
  • Difficulty: medium

Tile map objects

A tile map is one of the most asked feature by users - as they are useful for platformers, RPG and a lot of games. Tons of software exist to author maps composed of tiles, that could be imported in GDevelop. We could go further and make a basic map editor working directly in the GDevelop editor.

  • Outcome: a “Tiled Map” object that is performant and can be created using an external software or the GDevelop editor.
  • Skills: JavaScript
  • Difficulty: medium

Refactored and faster code generation

Code generation is a very important point in GDevelop. This project would rework the code generation of events to make it clearer, faster and unlock potential new features like improved object handlings to avoid unnecessary work and get runtime performance boost. This can be seen as a work on a lightweight compiler - which can be fun to then later work on larger ones!

  • Outcome: better generated code in games, faster code generation and performance.
  • Skills: C++ (mandatory to dig into the existing codebase), JavaScript (for the generated code), good understanding of algorithms and data structures.
  • Difficulty: medium

Live update of games ("hot reloading")

Editing a game and previewing it in a few seconds is nice… but what if you could edit a game and have the preview automatically update on the fly? The user should be able to edit the events of the game (or even objects) and have the game being updated to use the new events (or the updated objects) without being fully reloaded and restarted.

  • Outcome: things modified in the editor are updated in the previewed game.
  • Skills: JavaScript (for the editor and the game engine)
  • Difficulty: Easy to Medium

Dynamic lights and shadows

In addition to visual effects (“shaders”) that can be used in GDevelop, a “Dynamic lights” extension would be a great addition, allowing game objects to cast shadows and react to light sources. This can be both implemented as deferred lighting and by casting shadow. pixi-lights and pixi-shadows could be good starting points.

  • Outcome: extension allowing to use lights and/or shadows, with optional integration to third party editors.
  • Skills: JavaScript (for the editor and the game engine)
  • Difficulty: Medium

Rendering games in parallel to game logic

Rework the game engine so that while events/logic is being run for a frame, the previous frame is being rendered on screen.

  • Outcome: a working game engine that is rendering the games properly while running the logic.
  • Skills: JavaScript, Web workers, notion of threading.
  • Type: Exploratory
  • Difficulty: hard (needs very good understanding of game rendering/WebGL/Pixi.js)

Support opening multiple projects or multiple instances of the editor

Rework the editor so that the user is not forced to close a game before opening another one in the editor. This could either take the shape of another, separate editor window. Or maybe we can keep everything in the same window and have the games share the project manager and share the same list of tabs.

  • Outcome: Support opening multiple games in the editor without closing the current project.
  • Skills: JavaScript, React, Electron
  • Difficulty: Medium (good React knowledge)

Add support for boolean variable types (and arrays)

Rework the variables, add action/conditions and slightly adapt the UI to add support for boolean variables (true/false). As a stretch goal, add support for arrays, in addition to structures.

  • Outcome: Boolean variables can be used in GDevelop (right now we must use numbers to simulate them).
  • Skills: Mix of C++ and JavaScript
  • Difficulty: Easy to Medium

Your own idea

Your own ideas and variations on the existing one are very welcome! Remember to take a look at the roadmap if you want to know more about what users are asking for.

How to candidate?

You'll need two things!

  • First, become a bit familiar with GDevelop by solving or working an issue (or adding a simple new feature) on the GitHub Issue Tracker. Take a look at the Good First Issues.
    • You'll need to set up your development environment 💻. The README will explain everything! We're not explaining too much here because it's up to you to search and see how to do. It's not difficult ;)
    • Find an issue that looks interesting to you. Might be a Good First Issue or another one.
      • Do some research, try things, and if you need help ask on the forum or on the GitHub issue itself. Only do that though after searching the problem for a bit (we won't answer to questions to get started as there should be all explained in the README… but in case of doubt - ask!)
      • If you have something interesting, comment on the issue or open a Pull Request! Prepare it with all the required tests and checks, explain what you've done and a reviewer should give you some feedback.
  • Searching to solve an issue is a good first step that will actually help you in the second part: making a proposal!
    • Read the section about how to make a proposal on GDevelop page on Google Summer of Code website 🙇‍♀️.
      • Prepare your proposal on the Google Summer of Code website 🤓. While it's ok to ask questions about GDevelop development on the forum or on GitHub if it's related to an issue, we won't directly proofread or review your proposal. We can answer specific questions about the codebase, but the proposal must be coming from you.
      A good proposal will show that you understood at least the big principles and are able to dive more in the problem. Read also this thread.
Again, make sure to get familiar with GDevelop first. It's a good idea for you to try already to code and contribute to GDevelop! This will help you to understand the codebase and make a better proposal. Read and try some issues in the list of Good First Issues on GitHub.

Frequently Asked Questions

Where can I talk with others about GSoC? What are the communication channels?

Check out the forum section about GSoC. You can send an email (find it on the GSoC organisation page) but all the information should already be there.

For student(s) that will work on GDevelop during GSoC, we'll have regular catch-up by email, using GitHub and sometimes by video call.

Should I reach out to the forum, by email and on the Discord chat to have my proposal considered?

No. Your proposal will be considered in all cases. It's a good idea to engage with the community on the Discord or the forum if you want to know more how GDevelop works. Looking at “Good First Issues” and trying to fix/improve stuff on GitHub is recommended for you to have a better idea of how GDevelop is coded before making your proposal.

Should I include my participation on the forum/Discord/GitHub in my proposal?

Yes, it's a good idea, if you participated or contributed already to GDevelop, to include it in your proposal so that we know what you did already - especially useful to give us more confidence in you being able to achieve the project 👍