Attention: Here be dragons
This is the latest
(unstable) version of this documentation, which may document features
not available in or compatible with released stable versions of Godot.
Checking the stable version of the documentation...
Perguntas frequentes
O que eu posso fazer com o Godot? Quanto ele custa? Quais são os termos da licença?
O Godot é um Software livre e de código aberto disponível sob a licença MIT aprovada pela OSI. Isso significa que ele é grátis para baixar, e você também é livre para usar o código e o programa.
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 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 do 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.
For full details, look at the COPYRIGHT.txt as well as the LICENSE.txt and logo LICENSE.txt files in the Godot repository.
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.
Para obter informações sobre suporte para consoles, consulte o site do Godot.
Para mais informações, veja as seções exportação e compilando Godot você mesmo.
Nota
O Godot 3 também tinha suporte para Universal Windows Platform (UWP). Esta plataforma foi removida no Godot 4 devido à falta de manutenção, e está sendo obsoletada pela Microsoft. Ela 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 a C# ainda é relativamente recente e, portanto, você pode encontrar alguns problemas pelo caminho. O suporte a C# também está atualmente ausente na plataforma web. Nossa comunidade de desenvolvimento amigável e dedicada está sempre pronta para lidar com novos problemas à medida que surgem, mas, como este é um projeto de código aberto, recomendamos que você primeiro faça sua própria pesquisa. Procurar por discussões em issues abertos é uma ótima maneira de começar a solucionar 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. Foi construída do zero para maximizar o potencial do Godot com a menor quantidade de código possível, permitindo que tanto desenvolvedores iniciantes quanto experientes aproveitem os pontos fortes do Godot o mais rápido possível. Se você já escreveu algo em uma linguagem como Python, você se sentirá em casa. Para exemplos e uma visão geral completa do poder que o GDScript oferece, consulte o guia de scripting com GDScript.
Há várias razões para usar o GDScript, mas 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 o Godot era dupla: primeiro, reduzir o tempo necessário para começar a usar o Godot, oferecendo aos desenvolvedores uma maneira rápida de se familiarizarem com a engine, com foco na produtividade; segundo, reduzir a carga geral de manutenção, atenuar a dimensionalidade dos problemas e permitir que os desenvolvedores da engine se concentrem em corrigir bugs e aprimorar recursos relacionados ao núcleo do mecanismo, em vez de gastar muito tempo tentando fazer um pequeno conjunto de recursos incrementais funcionar em um grande conjunto de linguagens.
Como o Godot é um projeto de código aberto, desde o início foi fundamental priorizar uma experiência mais integrada e fluida em vez de atrair mais usuários com suporte a linguagens de programação mais conhecidas, especialmente quando esse suporte resultaria em uma experiência inferior. Entendemos se você preferir usar outra linguagem no Godot (veja a lista de opções suportadas acima). Dito isso, se você ainda não experimentou o GDScript, experimente por três dias. Assim como o Godot, depois de ver o quão poderoso ele é e a rapidez com que seu desenvolvimento se torna, acreditamos que você vai se apaixonar pelo GDScript.
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 o Godot foram:
Não há um bom suporte ao paralelismo na maioria das VMs de script, e o Godot utiliza threads (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).
Muitas linguagens existentes têm interfaces terríveis para conectar-se com o C++, resultando em uma grande quantidade de código, bugs, gargalos e ineficiência em geral (Lua, Python, Squirrel, JavaScript e etc). Nós queríamos focar em uma engine incrível, e não em uma incrível quantidade de integrações.
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.).
Garbage collector 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 da engine 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 do C# é complexo, 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 Godot Engine. No entanto, o C# pode ser mais lento que o GDScript ao fazer muitas chamadas à API do Godot, devido ao custo da serialização. O desempenho do C# também pode ser afetado pelo garbage collection, que ocorre em momentos aleatórios e imprevisíveis. Isso pode resultar em problemas de travamento em projetos complexos e não é um problema 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 scripts em múltiplas linguagens, ou utilizando GDExtension junto com linguagens de script. Esteja ciente de que isso traz suas próprias complicações.
Quais formatos de modelos 3D são suportados pelo 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 documentação Importando cenas 3D.
O [insira aqui um SDK fechado como FMOD, GameWorks, etc.] será suportado no Godot?
O objetivo do Godot é criar uma engine livre e gratuita de licença MIT e código aberto que seja modular e extensível. Não há planos para que a comunidade de desenvolvimento da engine dê suporte a qualquer SDK de terceiros, de código fechado/proprietário, já que a integração com estes seria contra a filosofia do Godot.
Dito isso, como o código do Godot é 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 abaixo.
Se você conhece uma SDK de terceiros que não é suportada pelo Godot mas que oferece uma integração livre e de código aberto, considere iniciar você mesmo o trabalho de integração. 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 scripts de ferramenta.
Além disto, veja as postagem do blog oficial sobre GDExtension, um jeito de desenvolver extensões nativas para o Godot:
Você também pode dar uma olhada na implementação do 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 do Godot no meu sistema (para integração com área de trabalho)?
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 o 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 do 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 Iniciar. Você também pode fixar o 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 do 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 não for possível mover o binário do editor Godot para um local protegido, você pode mantê-lo em algum lugar no seu diretório pessoal e modificar a linha
Path=no arquivo.desktopcujo link está abaixo para conter o caminho absoluto completo 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 do 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 no diretório de configuração ou de dados do usuário. Essa geralmente é uma boa prática, mas significa que os arquivos de configuração não serão transferidos entre máquinas se você copiar a pasta que contém o executável do Godot. Consulte Caminhos de arquivos em projetos Godot para obter mais informações.
Se quiser usar o Godot de uma forma realmente portátil (por exemplo, para executá-lo em um pendrive), siga as instruções em Modo autocontido.
Por que o 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á várias razões para isto:
Manutenção do código e menor exposição a bugs Toda vez que aceitamos código novo no repositório do Godot, contribuidores existentes costumam se responsabilizarem pela manutenção. Alguns contribuidores não continuam a trabalhar no código após ter seu trabalho mesclado, o que pode complicar a manutenção desse código. Isso pode levar a funcionalidades com bugs que nunca são corrigidos. Além disso a "superfície da API" que precisa ser testada e verificada continua crescendo com o decorrer do tempo.
Facilidade de contribuição. Ao manter 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 do editor pequeno. Nem todos têm uma conexão rápida com a Internet. Garantir que todos possam baixar o editor do Godot, extraí-lo e executá-lo em menos de 5 minutos torna o Godot mais acessível a desenvolvedores em todos os países.
Manter o tamanho do binário pequeno para modelos de exportação. Isso impacta diretamente o tamanho dos projetos exportados com o Godot. Em plataformas móveis e web, manter os tamanhos dos arquivos pequenos é importante para garantir instalação e carregamento rápidos em dispositivos com recursos limitados. Além disso, existem muitos países onde a internet de alta velocidade não está prontamente disponível. Para piorar a situação, limites rígidos de uso de dados geralmente estão em vigor nesses países.
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 da 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.
A maneira mais comum e adequada de se conseguir isso é usar uma única resolução base para o jogo e lidar apenas com diferentes proporções de tela. Isso é necessário principalmente para jogos 2D, já que em 3D, trata-se apenas do campo de visão vertical ou horizontal da câmera.
Escolha uma resolução base única para o seu jogo. Mesmo que existam dispositivos que suportem até 1440p e outros que suportem até 400p, o dimensionamento de hardware padrão do seu dispositivo cuidará disso com pouco ou nenhum custo de desempenho. As opções mais comuns são resoluções próximas a 1080p (1920x1080) ou 720p (1280x720). Lembre-se de que quanto maior a resolução, maiores serão os seus recursos, mais memória eles ocuparão e maior será o tempo de carregamento.
Use as opções de esticar no Godot; esticar os elementos da tela mantendo as proporções funciona melhor. Consulte o tutorial Resoluções múltiplas para saber como fazer isso.
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 lança a próxima versão do Godot?
Quando estiver pronta! Veja Quando será o próximo lançamento? para mais informações.
Qual versão do Godot devo usar para um novo projeto?
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 Qual versão eu deveria usar para um novo projeto? 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?
Fantástico! Como um projeto de código aberto, o Godot prospera da inovação e da ambição de desenvolvedores como você.
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 issue que lhe interesse em um dos links acima e tente corrigí-lo. Você precisará aprender como compilar a engine a partir do código fonte ou como fazer build da documentação. Você também precisa se familiarizar com o Git, um sistema de controle de versão usado pelos desenvolvedores do Godot.
Explicamos como trabalhar com o código fonte da engine, como editar a documentação, e outras formas de contribuir na nossa documentação para contribuintes.
É 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.
Veja Creating applications para mais informações.
É possível utilizar o Godot como uma biblioteca?
Se você quer fazer um jogo com o Godot, lembre-se que o Godot foi projetado para ser usado com seu editor. Nós recomendamos que você tente utilizá-lo, já que provavelmente poupará tempo a longo prazo.
Para aplicações mais especializadas, pode fazer sentido usar o Godot como biblioteca. Desde o Godot 4.6, há suporte experimental para usar o Godot como uma biblioteca estática ou compartilhada na forma do LibGodot. Atualmente há suporte para isso no Windows, MacOS e Linux. O suporte para Android e iOS está planejado para uma versão futura.
Você pode encontrar exemplos de aplicações que utilizam o Godot como uma bilbioteca no repositório do Github migeran/libgodot_project.
Qual toolkit de interface de usuário o Godot usa?
O Godot não usa um toolkit padrão de GUI como o GTK, Qt ou wxWidgets. Em vez disso, o Godot usa seu próprio toolkit de interface gráfica, que é sempre renderizado usando aceleração de hardware. Renderização em software não está inclusa, embora soluções externas que emulam APIs gráficas na CPU possam ser usadas.
Este toolkit é exposto na forma de nós de Control, que são usados para renderizar o editor (que é escrito em C++). Esses nós de Control também podem ser usados em projetos com qualquer linguagem de script suportada pelo Godot.
Este toolkit 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", já que o próprio editor é um dos usuários mais complexos do sistema de UI do Godot.
Este toolkit de UI personalizado pode ser incluído em outras aplicações (experimental). No entanto, a maneira preferida de usá-lo é usando o editor do Godot para criar aplicações além de jogos.
Por que Godot usa o sistema de compilação SCons?
O Godot usa o sistema de compilação SCons. Não há planos para mudar para um sistema de compilação diferente no futuro próximo. Há muitas razões pelas quais escolhemos o SCons ao invés outras alternativas. Por exemplo:
O 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 recompilar o projeto toda vez. O SCons pode fazer isso facilmente, sem quebrar os builds.
O SCons nunca irá quebrar um build, não importa quantas alterações, configurações, adições, remoções etc. tenha sido feitas.
O processo de compilação do 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 macros feita apenas para compilação.
O processo de compilação do Godot faz uso pesado de ferramentas de compilação cruzada. Cada plataforma tem um processo de detecção específico, e tudo isso deve ser tratado como casos específicos com código especial escrito para cada um.
Por favor, tente manter uma mente aberta e se familiarizar pelo menos um pouco com o SCons se você quer compilar o Godot por conta própria.
Por que Godot não usa a STL (Standard Template Library)?
Como muitas outras bibliotecas (Qt por exemplo), o Godot não utiliza a STL (com algumas exceções como primitivas de threading). Acreditamos que a STL é uma excelente biblioteca de uso geral, mas tínhamos requisitos especiais para o Godot.
Modelos STL criam símbolos muito grandes, o que resulta em binários de depuração enormes. Em vez disso, usamos poucos 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 internos da engine.
Nossos contêineres possuem rastreamento de memória embutido, o que ajuda a rastrear melhor o uso da memória.
Para 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 aquele oferecido pela STL é muito básico e carece de suporte adequado à internacionalização.
Confira os tipos de Container do Godot para alternativas.
Por que o Godot não usa exceções?
Acreditamos que jogos não devem crashar, aconteça o que acontecer. Se uma situação inesperada acontecer, o Godot exibirá um erro no console (que pode ser rastreado até mesmo por script), mas tentará se recuperar da maneira mais elegante possível e continuar.
Além disso, exceções aumentam significativamente o tamanho do arquivo executável e resultam em compilação mais demorada.
O Godot usa um ECS (Entity Component System)?
O Godot não usa um ECS, ao invés disso depende de heranças. Embora não exista uma única abordagem melhor, descobrimos que o uso de uma abordagem baseada em herenças resultou em uma melhor usabilidade e, ao mesmo tempo, foi rápido o suficiente na maioria dos casos.
Dito isto, nada impede que você faça uso de composição em seu projeto, criando nós filhos com scripts individuais. Esses nós podem então ser adicionados e removidos durante a execução para adicionar e remover comportamentos dinamicamente.
Mais informações sobre as decisões de design do Godot podem ser encontradas neste artigo.
Por que o Godot não força os usuários a implementar o DOD (Data-Oriented Design)?
Embora o Godot tente internamente usar a coerência de cache o máximo possível, acreditamos que os usuários não precisam ser forçados a usar as práticas do DOD.
O DOD é principalmente uma otimização de coerência de cache que só proporciona melhorias significativas de desempenho ao lidar com dezenas de milhares de objetos processados a cada quadro com poucas modificações. Ou seja, se você estiver movendo algumas centenas de sprites ou inimigos por quadro, o DOD não resultará em uma melhoria significativa de desempenho. Nesse caso, você deve considerar uma abordagem de otimização diferente.
A grande maioria dos jogos não precisa disso e o Godot oferece funções úteis para fazer o trabalho na maioria dos casos.
Se um jogo precisa processar uma quantidade tão grande de objetos, nossa recomendação é usar C++ e GDExtensions para tarefas que exigem 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 (em inglês).
Quem está trabalhando no Godot? Como entro em contato com vocês?
Veja a página correspondente no site do Godot.