Perguntas Frequentes

O que eu posso fazer com a 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 como em “liberdade de expressão”, bem como em “cerveja grátis.”

Resumindo:

  • Você está livre para baixar e usar Godot para qualquer propósito, pessoal, sem lucro, comercial, ou qualquer outro.
  • Você pode modificar, (re)distribuir e remixar o Godot o quanto você quiser, por qualquer motivo, seja ele comercial ou não-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, dê uma olhada nos arquivos COPYRIGHT.txt,`LICENSE.txt <https://github.com/godotengine/godot/blob/master/LICENSE.txt>`_ e LOGO_LICENSE.txt no repositório de Godot.

Veja também a página da Licença no site de Godot <https://godotengine.org/license>`_.

Quais plataformas são suportadas por Godot?

Para o editor:

  • Windows
  • macOs
  • X11 (Linux, *BSD)

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

Para mais informações, veja as seções Exportando 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 usa, uma vez que é nativa ao Godot. Enquanto linguagens de script tendem a ter menos performance que liguagens 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?

O GDScript é a linguagem de script integrada do Godot. Foi construído a partir do zero para maximizar o potencial do Godot com a menor quantidade de código, ajudando aos desenvolvedores novatos e experientes a usufruir dos pontos fortes do Godot o mais rápido possível. Se você já escreveu alguma coisa em uma linguagem como o Python antes disso, você se sentirá em casa. Para exemplos, histórico e uma visão geral completa do poder que o GDScript oferece, confira nosso guia GDScript:.

Há várias razões para usar o GDScript - especialmente quando você está criando protótipos, em estágios 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 geral da complexidade. **

A intenção original de criar uma linguagem de script personalizada e altamente integrada para Godot era dupla: primeiro, reduz a quantidade de tempo necessária para começar a usar o Godot, oferecendo aos desenvolvedores uma maneira rápida de se expor ao motor com foco na produtividade; segundo, reduz a carga geral de manutenção, atenua a dimensionalidade dos problemas e permite que os desenvolvedores do motor se concentrem em esmagar bugs e melhorar os recursos relacionados ao núcleo do motor–em vez de gastar muito tempo tentando obter um pequeno conjunto de recursos incrementais que funcionam 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, o motor 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?

Dito isso, o suporte a Collada por Godot é bom. Por favor, use o exportador OpenCollada para maior compatibilidade se você estiver usando Maya ou 3DS Max. Se você estiver usando Blender, dê uma olhada no nosso próprio Exportador Better Collada.

A partir de Godot 3.0, glTF é suportado.

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

A [insira aqui uma SDK fechada como PhysX, GameWorks, etc.] será suportada no Godot?

O objetivo do Godot é criar um motor gratuito com licença MIT de 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, 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 a começar a trabalhar na integração por si mesmo. Godot não é propriedade de uma pessoa; ela pertence à comunidade e cresce junto com contribuidores ambiciosos da comunidade como você.

Como devem ser criados os ativos para lidar com múltiplas resoluções ou razões de aspecto?

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 forma mais comum e apropriada de fazer isso é, na verdade, usar uma resolução base única para o jogo e apenas lidar com as diferentes razões de aspecto. Isso é mais necessário para 2D, pois em 3D é só uma questão de ajuste do campo de visão (XFov e YFov) da câmera.

  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 esticamento no Godot, esticando em 2D enquanto mantém o aspecto (proporção) funciona melhor. Veja o tutorial Multiple resolutions sobre como fazer isso.
  3. Determine uma resolução mínima e aí decida se você quer que seu jogo estique verticalmente ou horizontalmente para diferentes razões de aspecto, ou se tem uma mínima e você quer que apareçam barras pretas em vez de esticar. Isso também é explicado no passo anterior.
  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 diminuir imagens, e definir para que essa compilação seja usada para determinados tamanhos de tela na App Store ou Google Play.

Como posso estender Godot?

Para estender o Godot, como criar plugins para o Editor ou adicionar suporte a novas linguagens, dê uma olhada em:ref:EditorPlugins <doc_making_plugins> e ferramentas.

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

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

Impressionante! Como um projeto de código aberto, Godot prospera da inovação e ambição de desenvolvedores como você.

O primeiro 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 Godot. Como posso compartilhar essa ideia?

Pode ser tentador querer trazer ideias ao Godot, como aquelas que resultam e mudanças massivas no núcleo, um tipo de mímica que outro motor de jogos faz, ou modos de trabalho alternativo que você iria querer dentro do editor. Tudo isso é ótimo e nós agradecemos por ter tantas pessoas motivadas querendo contribuir, porém, o foco da Godot é e sempre será, a funcionalidade central como descrita no Roadmap, consertando bugs e discutindo problemas, e discussão entre membros da comunidade da godot.

A maior parte dos desenvolvedores na comunidade da Godot ficarão mais interessados em aprender coisas como:

  • Sua experiência utilizando o software e os problemas que você tem (nos preocupamos bem mais com isso do que ideias sobre 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.

Portanto, por favor, não sinta que suas ideias para o Godot não são bem-vindas. Em vez disso, tente reformulá-las em um problema primeiro, para que os desenvolvedores e a comunidade tenham uma base comum para discussão.

Uma ótima abordagem ao compartilhar suas ideias e problemas com a comunidade é a partir de histórias de usuários. Explique o que você está tentando fazer, o comportamento que você espera que aconteça, e então, o que realmente houve. Ao colocar problemas e ideias dessa forma, podemos ajudar a comunidade inteira a ficar focada em melhorar a experiência 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).

Por que Godot não usa STL (Standard Template Library, ou Biblioteca de Modelos Padrão)

Como muitas outras bibliotecas (Qt como exemplo), Godot não utiliza STL. Acreditamos que o STL é uma excelente biblioteca de uso geral, mas tínhamos requisitos especiais para 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 pré-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 falhar, não importa o quê. Se ocorrer uma situação inesperada, a Godot imprimirá um erro (que pode ser rastreado até o script), mas tentará se recuperar o mais graciosamente 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, tente 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 posso ajudar o desenvolvimento de 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.