Formas de contribuir

Godot Engine es un proyecto sin fines de lucro, impulsado por la comunidad, libre y de código abierto. Casi todos (excepto nuestro desarrollador líder, Juan. Más sobre esto abajo) están trabajando pro bono en su tiempo libre, por interés personal y por el amor de crear un motor libre de calidad excepcional.

Esto significa que para prosperar, Godot necesita que tantos usuarios como sea posible se involucren contribuyendo al motor. Hay muchas formas de contribuir a un proyecto tan grande, haciendo posible que todos aporten algo positivo al motor, independientemente de sus habilidades:

  • Be part of the community. The best way to contribute to Godot and help it become ever better is simply to use the engine and promote it by word-of-mouth, in the credits or splash screen of your games, blog posts, tutorials, videos, demos, gamedev or free software events, support on the Q&A, forums, Contributors Chat, Discord, etc. Participate! Being a user and advocate helps spread the word about our great engine, which has no marketing budget and can therefore only rely on its community to become more mainstream.

  • Haz juegos. No es ningún secreto que, para convencer a los nuevos usuarios y especialmente a la industria en general de que Godot es un competidor importante en el mercado, necesitamos grandes juegos hechos con Godot. Sabemos que el motor tiene mucho potencial, tanto para juegos en 2D como en 3D, pero dada su corta edad todavía nos faltan grandes lanzamientos que llamen la atención sobre Godot. Así que sigue trabajando en tus increíbles proyectos ¡Cada nuevo juego aumenta nuestra credibilidad en el mercado de desarrollo de videojuegos!

  • Involúcrate en el desarrollo del motor. Esto puede ser contribuyendo código a través de pull requests, probando los snapshots de desarrollo o directamente en la rama git master, reportando bugs o sugiriendo mejoras en el issue tracker, mejorando la documentación oficial (tanto la referencia de la clase como los tutoriales) y sus traducciones. Las siguientes secciones cubrirán cada una de esas formas "directas" de contribuir al motor.

  • Donación. Godot es un proyecto sin ánimo de lucro, pero aún así puede beneficiarse de las donaciones de los usuarios para muchas cosas. Aparte de los gastos habituales como los costes de alojamiento o el material promocional de los eventos, también utilizamos el dinero de las donaciones para adquirir hardware cuando es necesario (por ejemplo, utilizamos el dinero de las donaciones para comprar un MacBook Pro para implementar el soporte Retina/HiDPI y otras características relacionadas con el MacOS). Y lo más importante, también utilizamos el dinero de las donaciones para contratar a los desarrolladores del núcleo para que puedan trabajar a tiempo completo en el motor. Incluso con un salario mensual bajo, necesitamos un ingreso constante de donaciones para continuar haciendo esto, lo cual ha sido muy beneficioso para el proyecto hasta ahora. Así que si quieres donar algo de dinero al proyecto, revisa "nuestro sitio web" <>`_ para más detalles.

Contribuyendo con el código

The possibility to study, use, modify and redistribute modifications of the engine's source code are the fundamental rights that Godot's MIT license grants you, making it free and open source software.

As such, everyone is entitled to modify Godot's source code, and send those modifications back to the upstream project in the form of a patch (a text file describing the changes in a ready-to-apply manner) or - in the modern workflow that we use - via a so-called "pull request" (PR), i.e. a proposal to directly merge one or more Git commits (patches) into the main development branch.

Contributing code changes upstream has two big advantages:

  • Your own code will be reviewed and improved by other developers, and will be further maintained directly in the upstream project, so you won't have to reapply your own changes every time you move to a newer version. On the other hand it comes with a responsibility, as your changes have to be generic enough to be beneficial to all users, and not just your project; so in some cases it might still be relevant to keep your changes only for your own project, if they are too specific.

  • The whole community will benefit from your work, and other contributors will behave the same way, contributing code that will be beneficial to you. At the time of this writing, more than 1000 developers have contributed code changes to the engine!

To ensure good collaboration and overall quality, the Godot developers enforce some rules for code contributions, for example regarding the style to use in the C++ code (indentation, brackets, etc.) or the Git and PR workflow.

A good place to start is by searching for issues tagged as junior jobs (or Hacktoberfest during October) on GitHub.

Ver también

Technical details about the PR workflow are outlined in a specific section, Pull request workflow.

Details about the code style guidelines and the clang-format tool used to enforce them are outlined in Code style guidelines.

All pull requests must go through a review process before being accepted. Depending on the scope of the changes, it may take some time for a maintainer responsible for the modified part of the engine to provide their review. We value all of our contributors and ask them to be patient in the meantime, as it is expected that in an open source project like Godot, there is going to be way more contributions than people validating them.

To make sure that your time and efforts aren't wasted, it is recommended to vet the idea first before implementing it and putting it for a review as a PR. To that end, Godot has a proposal system. Its usage is encouraged to plan changes and discuss them with the community. Implementation details can also be discussed with other contributors on the Godot Contributors Chat.


Proposals are only required when working on an enhancement or a new feature. Bug reports are sufficient for fixing issues.

Testing and reporting issues

Another great way of contributing to the engine is to test development releases or the development branch and to report issues. It is also helpful to report issues discovered in stable releases, so that they can be fixed in the development branch and in future maintenance releases.

Testing development versions

To help with the testing, you have several possibilities:

  • Compile the engine from source yourself, following the instructions of the Compiling page for your platform.

  • Test official pre-release binaries when they are announced (usually on the blog and other community platforms), such as alpha, beta and release candidate (RC) builds.

  • Test "trusted" unofficial builds of the development branch; just ask community members for reliable providers. Whenever possible, it's best to use official binaries or to compile yourself though, to be sure about the provenance of your binaries.

As mentioned previously, it is also helpful to keep your eyes peeled for potential bugs that might still be present in the stable releases, especially when using some niche features of the engine which might get less testing by the developers.

Filing an issue on GitHub

Godot uses GitHub's issue tracker for bug reports and enhancement suggestions. You will need a GitHub account to be able to open a new issue there, and click on the New issue button.

Cuando informes de algún error, debes tener en cuenta que el proceso es similar a una cita con tu médico. Has notado síntomas que te hacen pensar que algo podría estar mal (el motor se cuelga, algunas características no funcionan como se esperaba, etc.). Es el papel del equipo de localización de fallos y de los desarrolladores ayudar a realizar el diagnóstico del problema que se ha encontrado, para que la causa real del fallo pueda ser identificada y abordada.

You should therefore always ask yourself: what is relevant information to give so that other Godot contributors can understand the bug, identify it and hopefully fix it. Here are some of the most important infos that you should always provide:

  • Operating system. Sometimes bugs are system-specific, i.e. they happen only on Windows, or only on Linux, etc. That's particularly relevant for all bugs related to OS interfaces, such as file management, input, window management, audio, etc.

  • Hardware. Sometimes bugs are hardware-specific, i.e. they happen only on certain processors, graphic cards, etc. If you are able to, it can be helpful to include information on your hardware.

  • Godot version. This is a must-have. Some issues might be relevant in the current stable release, but fixed in the development branch, or the other way around. You might also be using an obsolete version of Godot and experiencing a known issue fixed in a later version, so knowing this from the start helps to speed up the diagnosis.

  • How to reproduce the bug. In the majority of cases, bugs are reproducible, i.e. it is possible to trigger them reliably by following some steps. Please always describe those steps as clearly as possible, so that everyone can try to reproduce the issue and confirm it. Ideally, make a demo project that reproduces this issue out of the box, zip it and attach it to the issue (you can do this by drag and drop). Even if you think that the issue is trivial to reproduce, adding a minimal project that lets everyone reproduce it is a big added value. You have to keep in mind that there are thousands of issues in the tracker, and developers can only dedicate little time to each issue.

When you click the New issue button, you should be presented with a text area prefilled with our issue template. Please try to follow it so that all issues are consistent and provide the required information.

Contributing to the documentation

There are two separate resources referred to as "documentation" in Godot:

  • The class reference. This is the documentation for the complete Godot API as exposed to GDScript and the other scripting languages. It can be consulted offline, directly in Godot's code editor, or online at Godot API. To contribute to the class reference, you have to edit the XML file corresponding to the class and make a pull request. See Contribuyendo a la referencia de la clase and Class reference writing guidelines for more details.

  • The tutorials and engine documentation and its translations. This is the part you are reading now, which is distributed in the HTML format. Its contents are generated from plain text files in the reStructured Text (rst) format, to which you can contribute via pull requests on the godot-docs GitHub repository. See Contributing to the documentation for more details.

Contribución de traducciones

To make Godot accessible to everyone, including users who may prefer resources in their native language instead of English, our community helps translate both the Godot editor and its documentation in many languages.

Ver Editor y documentación de localización para más detalles.