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.

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 detalhes completos, 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

  • X11 (Linux, *BSD)

  • Web

  • Android (experimental)

Para exportar seus jogos:

  • Windows (e UWP)

  • macOS

  • X11 (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.

Alguns usuários também relatam terem compilado e utilizado o Godot com êxito em sistemas baseados em ARM com Linux, como Raspberry Pi.

Existe também um esforço não-oficial sendo feito para compilar para alguns consoles. Porém, nada disso está incluído nos scripts padrão de compilação ou nos modelos de exportação até esse momento.

Para mais informações, veja as seções exportação e compilando Godot você mesmo.

Quais linguagens de programação são suportadas pelo Godot?

As linguagens suportadas oficialmente em Godot são GDScript, Visual Scripting, 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. Nossa comunidade de desenvolvimento amistosa e trabalhadora 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. Pesquisando através de discussões em open issues para verificar se há problemas descobertos. Esta é uma ótima maneira de começar sua solução de problemas.

Quanto a novas linguagens, é possível oferecer suporte através de terceiros utilizando os recursos GDNative / NativeScript / PluginScript. (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--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 Godot era dupla: 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 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 resolver problemas e melhorar os recursos relacionados ao engine core--em vez de desperdiçar tempo tentando fazer um pequeno conjunto de recursos incrementais funcionarem em um grande conjunto 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 adicionais suportando linguagens de programação mais familiares--especialmente quando suportar 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, mas criar ligações com um sistema orientado a objetos (usando fallbacks) era complexo, 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:

  1. Não há um bom suporte a threads na maioria das VMs de scripting, e o Godot utiliza threads (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).

  2. 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).

  3. Muitas linguagens existentes têm interfaces terríveis entre si e 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.

  4. Não existem tipos de vetor nativos (vector3, matrix4, etc.), resultando em uma performance muito reduzida ao usar tipos personalizados (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).

  5. Coletor de lixo resulta em atrasos e um grande uso desnecessário de memória (Lua, Python, JavaScript, ActionScript, etc.).

  6. Dificuldade de integração com o editor de código para fornecer complementação de código, edição em tempo real, e etc. (todas elas). Isso é muito bem suportado por GDScript.

O GDScript foi projetado para reduzir os problemas acima, e mais.

Quais tipos de formatos de modelos 3D são suportados por Godot?

Godot possui suporte a Collada por meio do exportador OpenCollada (Maya, 3DSMax). Se você estiver usando Blender, dê uma olhada no nosso próprio Exportador Better Collada.

A partir do Godot 3.0, glTF é suportado.

O FBX é suportado através da biblioteca Open Asset Import. No entanto, o FBX é proprietário, por isso recomendamos o uso de outros formatos listados acima, se adequado para o seu fluxo de trabalho.

O [insira aqui um SDK fechado como FMOD, GameWorks, etc.] será suportado no Godot?

O objetivo do Godot é criar uma engine gratuita com licença MIT de 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 seriam contra a filosofia do Godot.

Assim, sendo 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. Tudo é permitido.

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 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 %LOCALAPPDATA%\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 no 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/godot ou /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 digitando godot.

    • 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 .desktop linkado abaixo para conter o * caminho absoluto* para o binário do Godot.

  • Salve este arquivo .desktop em $HOME/.local/ compartilhar/aplicativos/. Se você tem privilégios de administrador, você também pode salvar o arquivo .desktop em /usr/local/share/applications para 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), siga as etapas em Modo autocontido.

Por que o Godot usa Vulkan ou 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 mais.

Como Godot tem apenas algumas pessoas trabalhando em seu renderizador, preferimos ter menos back-ends de renderização para manter. Além disso, usar uma única API em todas as plataformas permite maior consistência com menos problemas específicos de cada plataforma.

A longo prazo, nós talvez desenvolveremos um renderizador Direct3D 12 para o Godot (principalmente para os propósitos do Xbox), porém Vulkan e OpenGL continuarão sendo o renderizador padrão em todas as plataformas, incluindo o 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 disso seria o recurso de inteligência artificial avançada.

Há algumas razões para isto:

  • Manutenção do código e menor exposição a bugs Toda vez que aceitamos um novo código 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. 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.

  • Manter o tamanho do binário pequeno para modelos de exportação Isso impacta diretamente no tamanho dos projetos exportados com o Godot. Em plataformas móveis e web, manter os tamanhos dos arquivos pequenos é essencial para assegurar instalações e carregamento rápidos em dispositivos de baixo desempenho. Novamente, existem muitos países onde a Internet de alta velocidade não está disponível para todos. Além disso, limites de banda costumam estar ativos 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 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 fazer isso é, na verdade, usar uma única resolução básica para o jogo e lidar apenas com diferentes proporções de tela. Isso é necessário principalmente para 2D, já que em 3D é apenas uma questão de ajuste da Camera (XFov ou YFov).

  1. Escolha uma resolução base para seu jogo. Mesmo que existam dispositivos que vão até 2k e outros que desçam até os 400p, o redimensionamento por hardware normal no seu dispositivo vai tomar conta disso a pouco ou nenhum custo de desempenho. As escolhas mais comuns são próximas a 1080p (1920x1080) ou 720p (1280x720). Tenha em mente que, quanto maior a resolução, maiores são os conteúdos, e mais memória eles vão ocupar e mais tempo levará para carregar.

  2. Use as opções de esticar no Godot; O alongamento 2D, mantendo as proporções, funciona melhor. Verifique o tutorial Resoluções múltiplas sobre como conseguir isso.

  3. 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.

  4. 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.

Se você deseja que seu jogo também funcione em dispositivos antigos com telas minúsculas (menos de 300 pixels de largura), você pode usar a opção de exportação para reduzir as imagens e definir essa compilação para ser usada para determinados tamanhos de tela na App Store ou Google Play.

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.

Veja também os posts oficiais no blog (em inglês) sobre os seguintes tópicos:

Você também pode dar uma olhada na implementação da GDScript, nos módulos em Godot e também no suporte não-oficial a Python para Godot. Isto seria um bom ponto de partida para ver como uma ferramenta externa integra-se com o Godot.

Quando será o próximo lançamento do Godot?

Quando estiver pronto! Veja Quando será o próximo lançamento? para mais informações.

Eu gostaria de contribuir! Como eu posso começar?

Incrível! Como um projeto de código aberto, o Godot prospera com a inovação e a ambição de desenvolvedores como você.

O melhor lugar para começar é em issues. Procure um problema que você se identifica, então proceda para How to Contribute guia para aprender como fazer um fork, modificar e enviar uma solicitação de envio (Pull request = PR) com suas alterações.

Eu tenho uma grande ideia para o Godot. Como posso compartilhar essa ideia?

Pode ser tentador trazer ideias para o Godot, como aquelas que resultam em grandes mudanças no "core", algum tipo de imitação do que outra game engine faz ou fluxos de trabalho alternativos que você gostaria de incorporar ao editor. Isso é ótimo, e somos gratos por ter pessoas tão motivadas que desejam contribuir, mas o foco do Godot é e sempre será a funcionalidade principal, conforme descrito no Roadmap, eliminação de bugs e resolução de problemas e conversas entre membros da comunidade Godot.

A maioria dos desenvolvedores na comunidade Godot estará mais interessada em aprender sobre coisas como:

  • Sua experiência de uso do software e os problemas que você tem (nos preocupamos muito mais com isso do que com ideias de como melhorá-lo).

  • As funcionalidades que você gostaria de ver implementadas porque precisa delas para seu projeto.

  • Os conceitos que foram difíceis de entender enquanto aprendia o software.

  • As partes do seu fluxo de trabalho que você gostaria que fossem otimizadas.

  • Partes onde você sentiu falta de tutoriais concisos ou onde a documentação não estava à altura.

Por favor, não pense que suas ideias para o Godot não sejam bem-vindas. Em vez disso, tente reformulá-las como um problema primeiro, para que os desenvolvedores e a comunidade tenham uma base funcional para fundamentar suas ideias.

Uma boa maneira de abordar o compartilhamento de suas ideias e problemas com a comunidade é como um conjunto de histórias de usuários. Explique o que você está tentando fazer, que comportamento espera que aconteça e, em seguida, qual comportamento realmente aconteceu. Enquadrar problemas e ideias dessa maneira ajudará toda a comunidade a manter o foco em melhorar as experiências do desenvolvedor como um todo.

Pontuação bônus se trouxer capturas de tela, números concretos, casos de teste ou projetos de exemplo (se aplicável).

É 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.

Dito isso, nós não vamos recomendar o uso do Godot para criar um aplicativo mobile visto que o modo de baixo processamento (low-processor) ainda não é suportado em plataformas mobile.

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 não usa STL (Standard Template Library, ou Biblioteca de Modelos Padrão)?

Como muitas outras bibliotecas (Qt por exemplo), Godot não utiliza STL. Acreditamos que o STL é uma excelente biblioteca de uso geral, mas tínhamos requisitos especiais para o 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.

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.

Além disso, as exceções aumentam significativamente o tamanho do binário do executável.

Por que Godot não aplica o RTTI?

Godot fornece seu próprio sistema de conversão de tipo, que pode opcionalmente usar o RTTI internamente. Desativar o RTTI em Godot significa que tamanhos de binários consideravelmente menores podem ser alcançados, com um pequeno custo de desempenho.

Por que Godot não força os usuários a implementar o DoD (Data oriented Design, ou Design orientado a Dados)?

Enquanto Godot internamente, para muitas das tarefas de alto desempenho, tenta usar a coerência do cache da melhor maneira possível, acreditamos que a maioria dos usuários não precisa realmente ser forçado a usar práticas de DoD.

O DoD é principalmente uma otimização da coerência do cache que só pode obter melhorias significativas de desempenho ao lidar com dezenas de milhares de objetos (que são processados a cada quadro com poucas modificações). Por exemplo, se você estiver movendo algumas centenas de sprites ou inimigos por quadro, o DoD não o ajudará e você deverá considerar uma abordagem diferente para a otimização.

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 GDNative 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?

Veja Maneiras de contribuir.

Quem está trabalhando no Godot? Como entro em contato com vocês?

Veja a página correspondente na página do Godot.