Perguntas Frequentes
O que eu posso fazer com o Godot? Quanto custa? Quais são os termos de licença?
Godot é um Software Livre e de Código Aberto disponível sob a licença MIT aprovada pela OSI. Isso significa que é livre, bem como gratuito e "de graça."
Resumindo:
Você é livre para baixar e usar o Godot para qualquer finalidade: pessoal, sem fins lucrativos, comercial ou qualquer outro.
Você é livre para modificar, distribuir, redistribuir e remixar o Godot como quiser, por qualquer motivo, seja ele não-comercial ou comercial.
Todo o conteúdo desta documentação anexa está publicado sob a licença permissiva Creative Commons Attribution 3.0 (CC-BY 3.0), com atribuição a "Juan Linietsky, Ariel Manzur e a comunidade Godot Engine."
Logomarcas e ícones geralmente estão sob a mesma licença Creative Commons. Note que algumas bibliotecas de terceiros incluídas no código-fonte do Godot podem ter licenças diferentes.
Para mais detalhes, consulte os arquivos COPYRIGHT.txt, e também LICENSE.txt e LOGO_LICENSE.txt no repositório do Godot.
Veja também a página da Licença no site do Godot.
Quais plataformas são suportadas pelo Godot?
Para o editor:
Windows
macOS
Linux, *BSD
Android (experimental)
Web (experimental)
Para exportar seus jogos:
Windows
macOS
Linux, *BSD
Android
iOS
Web
Ambos os binários de 32 e 64 bits são suportados onde fizerem sentido, sendo 64 o padrão. As builds para macOS oficial suportam Apple Silicon nativamente, bem como x86_64.
Alguns usuários também relatam terem compilado e utilizado o Godot com êxito em sistemas baseados em ARM com Linux, como Raspberry Pi.
A equipe do Godot não pode fornecer uma exportação de console de código aberto devido aos termos de licenciamento impostos pelos fabricantes de consoles. Independentemente da engine que você usa, lançar jogos em consoles é sempre muito trabalhoso. Você pode ler mais sobre isso aqui: Suporte para Consoles em Godot.
Para mais informações, veja as seções exportação e compilando Godot você mesmo.
Nota
Godot 3 também tinha suporte para Universal Windows Platform (UWP). Esta porta de plataforma foi removida em Godot 4 devido à falta de manutenção, e está sendo depreciada pela Microsoft. Ainda está disponível na versão estável atual do Godot 3 para usuários interessados.
Quais linguagens de programação são suportadas pelo Godot?
As linguagens suportadas oficialmente no Godot são GDScript, C# e C++. Veja as subcategorias para cada linguagem na seção de scripting.
Se você está apenas começando com o Godot ou desenvolvimento de jogos em geral, GDScript é a linguagem recomendada para aprender e usar, uma vez que é nativa no Godot. Enquanto linguagens de script tendem a ter menos performance que linguagens de menor nível, para prototipagem, desenvolvimento de Minimum Viable Products (MVPs), e focar em Time-To-Market (TTM), GDScript vai fornecer um modo rápido, amigável e capaz de desenvolver seus jogos.
Observe que o suporte ao C# ainda é relativamente novo e, como tal, você pode encontrar alguns problemas ao longo do caminho. Atualmente o suporte a C# não é suportado pela plataforma web. Nossa comunidade de desenvolvimento amigável e esforçada está sempre pronta para enfrentar novos problemas à medida que eles surgem, mas como esse é um projeto de código aberto, recomendamos que você faça primeiro uma diligência prévia. Pesquisar em problemas em aberto <https://github.com/godotengine/godot/issues?q=is%3Aopen+is%3Aissue+label%3Atopic%3Adotnet> é uma ótima maneira de começar sua resolução de problemas.
Quanto a novas linguagens, é possível oferecer suporte através de terceiros com as GDExtensions. (Veja abaixo sobre como os plugins funcionam.) Existe trabalho em andamento, por exemplo, para vinculações não oficiais do Godot para Python e para Nim.
O que é GDScript e porque eu devo usá-lo?
GDScript é a linguagem de script integrada do Godot. Ela foi construída desde o início para maximizar o potencial do Godot com a menor quantidade de código, permitindo que desenvolvedores novatos e experientes capitalizem os pontos fortes de Godot o mais rápido possível. Se você já escreveu algo em uma linguagem como Python antes, você se sentirá em casa. Para exemplos, histórico e uma visão geral completa do poder que o GDScript oferece a você, verifique o Guia de script do GDScript.
Há várias razões para usar o GDScript - especialmente quando você está criando protótipos, em fases alfa/beta do seu projeto, ou não está criando o próximo título AAA. A razão mais importante é a redução da complexidade.
A intenção original de criar uma linguagem de script personalizada e altamente integrada para Godot visa duas coisas: primeiro, reduzir a quantidade de tempo necessária para começar a usar o Godot, oferecendo aos desenvolvedores uma maneira rápida de se expor à engine com foco na produtividade; segundo, reduzir o esforço geral de manutenção, diminuir a variedade de problemas, e permitir que os desenvolvedores da engine se concentrem em resolver bugs e melhorar as funcionalidade relacionadas ao core da engine, em vez de desperdiçar tempo tentando fazer um pequeno conjunto incremental de funcionalidades funcionar para um grande número de linguagens.
Já que Godot é um projeto de código aberto, foi imperativo desde o começo priorizar uma experiência mais integrada ao invés de atrair usuários com suporte a linguagens de programação mais familiares, especialmente quando o suporte a essas linguagens mais familiares resultaria em uma experiência pior. Nós entendemos se você prefere usar alguma outra linguagem no Godot (Veja a lista de opções suportadas acima). Com isso dito, se você não tentou usar o GDScript, experimente por três dias. Assim como Godot, uma vez que você vê o quão poderoso e rápido seu desenvolvimento se torna, nos achamos que o GDScript irá crescer em você.
Mais informações sobre como ficar mais confortável usando GDScript ou outras linguagens de tipagem dinâmica podem ser encontradas no tutorial GDScript: Uma introdução às linguagens dinâmicas.
Quais foram as motivações por trás da criação do GDScript?
Em seus primórdios, a engine utilizava a linguagem de script Lua. Lua é rápida graças ao LuaJIT, mas criar ligações com um sistema orientado a objetos (usando fallbacks) era complexo e lento e necessitava de uma quantidade enorme de código. Após alguns experimentos com Python, ela também demonstrou ser difícil de embutir.
As principais razões para criação de uma linguagem personalizada para Godot foram:
Não há um bom suporte ao paralelismo na maioria das VMs de script, e o Godot utiliza partes_paralelizáveis (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
Não há um bom suporte a extensão de classes na maioria das VMs de scripting, e adaptá-las para a forma como o Godot funciona é altamente ineficiente (Lua, Python, JavaScript).
Many existing languages have horrible interfaces for binding to C++, resulting in a large amount of code, bugs, bottlenecks, and general inefficiency (Lua, Python, Squirrel, JavaScript, etc.). We wanted to focus on a great engine, not a great number of integrations.
Não existem tipos de vetor nativos (Vector3, Transform3D, etc.), resultando em uma grande redução de performance quando usados tipos personalizados (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).
Coletor de lixo resulta em atrasos e um grande uso desnecessário de memória (Lua, Python, JavaScript, ActionScript, etc.).
Dificuldade de integração com o editor de código para fornecer autocompletar de código, edição em tempo real, e etc. (todas elas).
O GDScript foi projetado para reduzir os problemas acima, e mais.
Qual linguagem de programação é mais rápida?
Na maioria dos jogos, a linguagem de script em si não é a causa dos problemas de desempenho. Em vez disso, o desempenho é afetado por algoritmos ineficientes (que são lentos em todas as linguagens), pelo desempenho da GPU ou pelo código comum do motor em C++, como física ou navegação. Todas as linguagens suportadas pelo Godot são rápidas o suficiente para scripts de uso geral. Você deve escolher uma linguagem com base em outros fatores, como facilidade de uso, familiaridade, suporte à plataforma ou recursos da linguagem.
Em geral, o desempenho do C# e do GDScript está na mesma ordem de magnitude, e o C++ é mais rápido que ambos.
Comparar o desempenho do GDScript com o C# é complicado, já que o C# pode ser mais rápido em alguns casos específicos. A linguagem C# em si tende a ser mais rápida que o GDScript, o que significa que o C# pode ser mais rápido em situações com poucas chamadas ao código do motor do Godot. No entanto, o C# pode ser mais lento que o GDScript ao fazer muitas chamadas à API do Godot, devido ao custo do marshalling. O desempenho do C# também pode ser prejudicado pela coleta de lixo, que ocorre em momentos aleatórios e imprevisíveis. Isso pode resultar em travamentos em projetos complexos, e isso não é exclusivo do Godot.
C++, usando GDExtension, quase sempre será mais rápido que C# ou GDScript. No entanto, C++ é menos fácil de usar que C# ou GDScript, e o desenvolvimento com ele é mais lento.
Você também pode usar múltiplas linguagens em um único projeto, com script em múltiplas linguagens, ou utilizando GDExtension com linguagens de script. Esteja ciente de que isso traz suas próprias complicações.
Quais tipos de formatos de modelos 3D são suportados por Godot?
Você pode encontrar informações detalhadas sobre formatos suportados, como exportá-los pelo seu software de modelagem 3D e como importá-los para o Godot na Importando cenas 3D documentação.
O [insira aqui um SDK fechado como FMOD, GameWorks, etc.] será suportado no Godot?
O objetivo do Godot é criar um motor gratuito de licença MIT e código aberto que seja modular e extensível. Não há planos para que a comunidade de desenvolvimento do motor dê suporte a qualquer SDK de terceiros, de código fechado/proprietário, já que a integração com estes seriam contra a filosofia do Godot.
Assim, por Godot ser de código aberto e modular, nada impede que você ou qualquer outra pessoa interessada adicione essas bibliotecas como um módulo e publique seu jogo com elas, seja em código aberto ou fechado.
Para ver como prover suporte a seu SDK de preferência, veja a pergunta sobre Plugins acima.
Se você conhece uma SDK de terceiros que não é suportada por Godot mas que oferece uma integração livre e de código aberto, considere iniciar você mesmo o trabalho de integração. Godot não é propriedade de uma pessoa; ele pertence à comunidade, e cresce junto com contribuidores ambiciosos da comunidade como você.
Como posso fazer extensões para o Godot?
Para criar extensões para o Godot, como plugins para o Editor ou adicionar suporte a novas linguagens, dê uma olhada em Criando Plugins e ferramentas de scripts.
Além disto, veja as postagem do blog oficial sobre GDExtension, um caminho para desenvolver extensões nativas para a Godot:
Você também pode dar uma olhada na implementação em GDScript, nos módulos do Godot, assim como na integração do motor de física Jolt para o Godot. Este seria um bom ponto de partida para ver como outra biblioteca de terceiros se integra ao Godot.
Como instalo o editor Godot no meu sistema (para integração com desktop)?
Como você não precisa realmente instalar o Godot em seu sistema para executá-lo, isso significa que a integração com a área de trabalho não é realizada automaticamente. Existem duas maneiras de contornar isso. Você pode instalar Godot pela Steam (todas as plataformas), Scoop (Windows), Homebrew (macOS) ou Flathub (Linux). Isso executará automaticamente as etapas necessárias para a integração da área de trabalho.
Como alternativa, você pode executar manualmente as etapas que um instalador faria por você:
Windows
Mova o executável do Godot para um local estável (ou seja, fora da sua pasta Downloads), para que você não o mova acidentalmente e quebre o atalho no futuro.
Clique com o botão direito do mouse no executável Godot e escolha Criar atalho.
Mova o atalho criado para
%APPDATA%\Microsoft\Windows\Start Menu\Programs. Este é o local do usuário atual para os atalhos que aparecerão no Menu do Início. Você também pode fixar Godot na barra de tarefas clicando com o botão direito do mouse no executável e escolhendo Fixar na Barra de Tarefas.
macOS
Arraste o aplicativo Godot extraído para /Applications/Godot.app, então arraste-o para o Dock se desejar. O Spotlight será capaz de encontrar o Godot desde que esteja em /Applications ou ~/Applications.
Linux
Mova o binário do Godot para um local estável (ou seja, fora da sua pasta Downloads), para que você não o mova acidentalmente e quebre o atalho no futuro.
Renomeie e mova o binário do Godot para um local presente em sua variável de ambiente
PATH. Normalmente é/usr/local/bin/godotou/usr/bin/godot. Fazer isso requer privilégios de administrador, mas também permite que você execute o editor Godot a partir de um terminal digitandogodot.Se você não pode mover o binário do editor Godot para um local protegido, você pode manter o binário em algum lugar em seu diretório pessoal, e modificar a linha
Path=no arquivo.desktoplinkado abaixo para conter o * caminho absoluto* para o binário do Godot.
Salve este arquivo .desktop em
$HOME/.local/share/applications/. Se você tem privilégios de administrador, você também pode salvar o arquivo.desktopem/usr/local/share/applicationspara tornar o atalho disponível para todos os usuários.
O editor Godot é um aplicativo portátil?
Em sua configuração padrão, Godot é semi-portátil. Seu executável pode ser executado em qualquer local (incluindo locais não graváveis) e nunca requer privilégios de administrador.
No entanto, os arquivos de configuração serão gravados na configuração do usuário atual ou no diretório de dados. Esta é geralmente uma boa abordagem, mas isso significa que os arquivos de configuração não serão utilizáveis em máquinas diferentes se você copiar a pasta que contém o executável Godot. Veja Caminhos de arquivos em projetos Godot para mais informações.
Se uma verdadeira operação portátil for desejada (como por exemplo, para uso em um pendrive USB), siga as etapas em Modo autocontido.
Por que o Godot prioriza Vulkan e OpenGL ao invés do Direct3D?
Godot visa a compatibilidade entre plataformas e padrões livres em primeiro lugar. OpenGL e Vulkan são as tecnologias abertas e disponíveis (quase) em todas as plataformas. Graças a essa decisão de design, um projeto desenvolvido com Godot no Windows funcionará sem problemas no Linux, macOS e outros.
Apesar do Vulkan e OpenGL ainda serem nosso foco primário devido aos benefícios de serem padrão aberto e de sereme multiplataforma, Godot 4.3 introduziu suporte experimental ao Direct3D 12. Esta adição visa aprimorar o desempenho e a compatibilidade em plataformas onde o Direct3D 12 é predominante, como Windows e Xbox. Contudo, Vulkan e OpenGL continuará sendo renderizador padrão para todas as plataformas, inclusive Windows.
Por que Godot pretende manter seu conjunto de recursos principais pequeno?
O Godot intencionalmente não inclui funcionalidades que podem ser implementadas por add-ons, a não ser que sejam usadas muito frequentemente. Um exemplo de algo não usado frequentemente é a funcionalidade de inteligência artificial avançada.
Há algumas razões para isto:
Code maintenance and surface for bugs. Every time we accept new code in the Godot repository, existing contributors often take the responsibility of maintaining it. Some contributors don't always stick around after getting their code merged, which can make it difficult for us to maintain the code in question. This can lead to poorly maintained features with bugs that are never fixed. On top of that, the "API surface" that needs to be tested and checked for regressions keeps increasing over time.
Facilidade de contribuição. Mantendo a base de código pequena e limpa, a tarefa de compilar o código-fonte continuará simples e rápida. Isso deixa mais fácil para novos contribuidores começarem a trabalhar com o Godot, sem a necessidade dos mesmos comprarem máquinas mais potentes.
Manter o tamanho binário pequeno para o editor. Nem todos têm uma conexão rápida com a Internet. Ter certeza de que todos podem baixar o Godot, extraí-lo e rodá-lo em menos de 5 minutos faz dele mais acessível para desenvolvedores em todos os países.
Keeping the binary size small for export templates. This directly impacts the size of projects exported with Godot. On mobile and web platforms, keeping file sizes low is important to ensure fast installation and loading on underpowered devices. Again, there are many countries where high-speed Internet is not readily available. To add to this, strict data usage caps are often in effect in those countries.
Por todas as razões acima, temos que ser seletivos no que podemos aceitar como funcionalidade base no Godot. Esse é o motivo pelo qual pretendemos mover algumas funcionalidades base para add-ons oficiais em versões futuras do Godot. Em termos de tamanho do binário, isso também tem a vantagem de fazer com que você "pague" somente pelo que usa em seu projeto. (Enquanto isso, você pode compilar modelos de exportação personalizados com certas funcionalidades desabilitadas para otimizar o tamanho de seu projeto.)
Como devem ser criados os assets para lidar com múltiplas resoluções ou proporções de tela?
Essa pergunta aparece com frequência e provavelmente por conta do desentendimento criado pela Apple quando eles dobraram a resolução de seus dispositivos. Isso fez as pessoas pensarem que ter os mesmos conteúdos em diferentes resoluções era uma boa ideia, então muitos continuaram nesse caminho. Aquilo funcionou até certo ponto e só em dispositivos Apple, mas então vários dispositivos Apple e Android com diferentes resoluções e aspectos foram criados, e com uma variedade enorme de tamanhos e DPIs.
The most common and proper way to achieve this is to, instead, use a single base resolution for the game and only handle different screen aspect ratios. This is mostly needed for 2D, as in 3D, it's just a matter of camera vertical or horizontal FOV.
Choose a single base resolution for your game. Even if there are devices that go up to 1440p and devices that go down to 400p, regular hardware scaling in your device will take care of this at little or no performance cost. The most common choices are either near 1080p (1920x1080) or 720p (1280x720). Keep in mind the higher the resolution, the larger your assets, the more memory they will take and the longer the time it will take for loading.
Use the stretch options in Godot; canvas items stretching while keeping aspect ratios works best. Check the Resoluções múltiplas tutorial on how to achieve this.
Determine uma resolução mínima e decida se deseja que seu jogo se estenda vertical ou horizontalmente para diferentes proporções, ou se há uma proporção mínima e você deseja que barras pretas apareçam nas bordas. Isso também é explicado em Resoluções múltiplas.
Para interfaces de usuário, utilize a ancoragem para determinar onde os controles devem estar e se mover. Se as interfaces são mais complexas, considere aprender sobre Containers.
E é isso! Seu jogo deve funcionar em múltiplas resoluções.
Quando será o próximo lançamento do Godot?
Quando estiver pronto! Veja Quando será o próximo lançamento? para mais informações.
Which Godot version should I use for a new project?
Recomendamos utilizar o Godot 4.x para novos projetos, porém dependendo do conjunto de funcionalidades que precisa, pode ser melhor usar a 3.x. Veja Which version should I use for a new project? para mais informações.
Devo atualizar meu projeto para usar novas versões do Godot?
Algumas versões são mais seguras de serem atualizadas que outras. No geral, se você deve ou não atualizar depende das circunstâncias do seu projeto. Veja Devo atualizar meu projeto para usar novas versões do Godot? para mais informações.
Devo utilizar o renderizador Avançado+, Mobile ou Compatibilidade?
Você pode encontrar uma comparação detalhada dos renderizadores em Overview of renderers.
Eu gostaria de contribuir! Como eu posso começar?
Awesome! As an open source project, Godot thrives off of the innovation and the ambition of developers like you.
A melhor maneira de começar a contribuir com o Godot é usando-o e relatando quaisquer problemas que você possa encontrar. Um bom relatório de bug com etapas claras de reprodução ajuda seus colegas contribuidores a corrigirem os bugs de forma rápida e eficiente. Você também pode relatar problemas que encontrar na documentação online.
Se você se sentir pronto para enviar seu primeiro PR, escolha qualquer problema que lhe interesse em um dos links acima e tente corrigi-lo. Você precisará aprender como compilar o mecanismo (a engine) a partir dos fontes ou como construir a documentação. Você também precisa se familiarizar com o Git, um sistema de controle de versão usado pelos desenvolvedores do Godot.
We explain how to work with the engine source, how to edit the documentation, and what other ways to contribute are there in our documentation for contributors.
É possível usar o Godot para criar aplicativos que não sejam jogos?
Sim! O Godot possui um extenso sistema de UI embutido, e seu pequeno tamanho de distribuição pode torná-lo uma alternativa adequada para frameworks como Electron ou Qt.
Quando criar uma aplicação que não seja um jogo, certifique-se de habilitar o Modo Baixo Processamento nas Configurações do Projeto para diminuir o uso da CPU e GPU.
Confira Material Maker e Pixelorama para exemplos de aplicativos de código aberto desenvolvidos com o Godot.
É possível utilizar o Godot como uma biblioteca?
O Godot é desenvolvido para ser usado com sua interface de edição. Recomendamos que você experimente, pois provavelmente economizará tempo a longo prazo. Não há planos de tornar o Godot utilizável como uma biblioteca, pois isso tornaria o restante do motor mais complicado e difícil de usar para usuários casuais.
Se você deseja usar uma biblioteca de renderização, procure usar um mecanismo de renderização estabelecido. Lembre-se de que os mecanismos de renderização geralmente têm comunidades menores em comparação com o Godot. Isso tornará mais difícil encontrar respostas para suas perguntas.
Qual kit de ferramentas de interface do usuário o Godot usa?
O Godot não usa um kit de ferramentas GUI padrão como GTK, Qt ou wxWidgets. Em vez disso, Godot usa seu próprio kit de ferramentas de interface de usuário, renderizado usando OpenGL ES ou Vulkan. Este kit de ferramentas é exposto na forma de nós de Controle, que são usados para renderizar o editor (que é escrito em C++). Estes nós de Controle também podem ser usados em projetos de qualquer linguagem de scripting suportada pelo Godot.
Este kit de ferramentas personalizado possibilita o benefício da aceleração de hardware e tem uma aparência consistente em todas as plataformas. Além disso, ele não precisa lidar com as ressalvas de licenciamento LGPL que vêm com GTK ou Qt. Por último, isso significa que o Godot está "comendo sua própria comida de cachorro", já que o próprio editor é um dos usuários mais complexos do sistema de UI do Godot.
Este kit de ferramentas de UI customizado não pode ser usado como uma biblioteca, mas você ainda pode usar o Godot para criar aplicativos não-jogos usando o editor.
Por que Godot usa o sistema de construção SCons?
Godot uses the SCons build system. There are no plans to switch to a different build system in the near future. There are many reasons why we have chosen SCons over other alternatives. For example:
Godot pode ser compilado para uma dúzia de plataformas diferentes: todas as plataformas de PC, todas as plataformas móveis, muitos consoles e WebAssembly.
Os desenvolvedores geralmente precisam compilar para várias plataformas ao mesmo tempo, ou até mesmo destinos diferentes da mesma plataforma. Eles não podem se dar ao luxo de reconfigurar e reconstruir o projeto todas as vezes. SCons pode fazer isso sem suor, sem quebrar as compilações.
SCons nunca irá interromper uma compilação, não importa quantas alterações, configurações, adições, remoções etc. tenha sido feitas.
O processo de construção de Godot não é simples. Vários arquivos são gerados por código (binders), outros são analisados (shaders), e outros precisam oferecer personalização (modules). Isso requer lógica complexa que é mais fácil de escrever em uma linguagem de programação real (como Python) em vez de usar uma linguagem baseada em macro apenas significava para o building.
Godot's build process makes heavy use of cross-compiling tools. Each platform has a specific detection process, and all these must be handled as specific cases with special code written for each.
Please try to keep an open mind and get at least a little familiar with SCons if you are planning to build Godot yourself.
Por que Godot não usa STL (Standard Template Library, ou Biblioteca de Modelos Padrão)?
Like many other libraries (Qt as an example), Godot does not make use of STL (with a few exceptions such as threading primitives). We believe STL is a great general-purpose library, but we had special requirements for Godot.
Os modelos STL criam símbolos muito grandes, o que resulta em enormes binários de depuração. Em vez disso, usamos alguns modelos com nomes bem curtos.
A maioria de nossos contêineres atende a necessidades especiais, como Vector, que usa cópia na gravação e usamos para transmitir dados, ou o sistema RID, que requer tempo de acesso O(1) para desempenho. Da mesma forma, nossas implementações de hash map foram projetadas para integrar-se perfeitamente aos tipos de mecanismo interno.
Nossos contêineres possuem rastreamento de memória embutido, o que ajuda a rastrear melhor o uso da memória.
Para matrizes (arrays) grandes, usamos memória em pool, que pode ser mapeada para um buffer previamente alocado ou para uma memória virtual.
Usamos nosso tipo de String personalizado, pois o fornecido pela STL é muito básico e carece de suporte adequado à internacionalização.
Confira os tipos de Container do Godot para alternativas.
Por que Godot não usa exceções?
Acreditamos que os jogos não devem travar, aconteça o que acontecer. Se uma situação inesperada acontecer, Godot imprimirá um erro (que pode ser rastreado até mesmo no script), mas tentará se recuperar da maneira mais elegante possível e continuar.
Additionally, exceptions significantly increase the binary size for the executable and result in increased compile times.
O Godot usa um ECS (Sistema de Componentes da Entidade)?
Godot não usa um ECS e depende de herenças. Embora não exista uma abordagem melhor, descobrimos que o uso de uma abordagem baseada em herenças resultou em uma melhor usuabilidade e, ao mesmo tempo foi rapido o suficiente na maioria dos casos.
That said, nothing prevents you from making use of composition in your project by creating child Nodes with individual scripts. These nodes can then be added and removed at runtime to dynamically add and remove behaviors.
Mais informações sobre as decisões de design do Godot podem ser encontradas neste artigo.
Why does Godot not force users to implement DOD (Data-Oriented Design)?
While Godot internally attempts to use cache coherency as much as possible, we believe users don't need to be forced to use DOD practices.
DOD is mostly a cache coherency optimization that can only provide significant performance improvements when dealing with dozens of thousands of objects which are processed every frame with little modification. That is, if you are moving a few hundred sprites or enemies per frame, DOD won't result in a meaningful improvement in performance. In such a case, you should consider a different approach to optimization.
A grande maioria dos jogos não precisa disso e Godot fornece ajudantes úteis para fazer o trabalho na maioria dos casos.
Se for necessário um jogo que realmente precise processar uma quantidade tão grande de objetos, nossa recomendação é usar C++ e GDExtensions para as partes de alto desempenho e GDScript (ou C#) para o restante do jogo.
Como eu posso ajudar no desenvolvimento do Godot ou contribuir?
Consulte How to contribute.
Quem está trabalhando no Godot? Como entro em contato com vocês?
Veja a página correspondente na página do Godot.