Perguntas Frequentes

O que eu posso fazer com o Godot? Quanto custa? Quais são os termos de licença?

Godot é ‘Software Livre e de Código Aberto’ disponível em https://opensource.org/licenses/MIT> ` Licença MIT. 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, tanto comercial quanto não-comercialmente.

Todo o conteúdo desta documentação estão 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 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 reportam construindo e usando Godot sucessivamente 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?

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, JS, AS, 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, JS).
  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, JS 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, JS, AS, etc.).
  5. Coletor de lixo resulta em atrasos e um grande uso desnecessário de memória (Lua, Python, JS, AS, etc.).
  6. Dificuldade de integração com o editor de código para prover completamento de código, edição em tempo real, etc. (todas elas). Isso é muito bem suportado por GDScript.

GDScript foi projetado para reduzir os problemas acima e mais.

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

Godot suporta Collada através de OpenCollada exportado (Maya, 3DSMax).

Se você estiver usando Blender, dê uma olhada no nosso Better Collada Exporter.

A partir de Godot 3.0, glTF é suportado.

A SDK do FBX tem uma licença restritiva, que é incompatível com a licença aberta usada pelo Godot. Dito isto, FBX poderia continuar a ser fornecido por terceiros como um plugin. (Veja a questão dos plugins acima.)

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

O objetivo de 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 de 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, criar plugins para o Editor ou adicionar o suporte a novas línguas, veja EditorPlugins e scripts tool.

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

Why does Godot not use STL (Standard Template Library)

Like many other libraries (Qt as an example), Godot does not make use of STL. We believe STL is a great general purpose library, but we had special requirements for Godot.

  • STL templates create very large symbols, which results in huge debug binaries. We use few templates with very short names instead.
  • Most of our containers cater to special needs, like Vector, which uses copy on write and we use to pass data around, or the RID system, which requires O(1) access time for performance. Likewise, our hash map implementations are designed to integrate seamlessly with internal engine types.
  • Our containers have memory tracking built-in, which helps better track memory usage.
  • For large arrays, we use pooled memory, which can be mapped to either a preallocated buffer or virtual memory.
  • We use our custom String type, as the one provided by STL is too basic and lacks proper internationalization support.

Why does Godot not use exceptions?

We believe games should not crash, no matter what. If an unexpected situation happens, Godot will print an error (which can be traced even to script), but then it will try to recover as gracefully as possible and keep going.

Additionally, exceptions significantly increase binary size for the executable.

Why does Godot not enforce RTTI?

Godot provides its own type-casting system, which can optionally use RTTI internally. Disabling RTTI in Godot means considerably smaller binary sizes can be achieved, at a little performance cost.

Why does Godot not force users to implement DoD (Data oriented Design)?

While Godot internally for a lot of the heavy performance tasks attempts to use cache coherency as best as possible, we believe most users don’t really need to be forced to use DoD practices.

DoD is mostly a cache coherency optimization that can only gain you significant performance improvements when dealing with dozens of thousands of objects (which are processed every frame with little modification). As in, if you are moving a few hundred sprites or enemies per frame, DoD won’t help you, and you should consider a different approach to optimization.

The vast majority of games do not need this and Godot provides handy helpers to do the job for most cases when you do.

If a game that really needs to process such large amount of objects is needed, our recommendation is to use C++ and GDNative for the high performance parts and GDScript (or C#) for the rest of the game.

Como eu posso ajudar o desenvolvimento de Godot ou contribuir?

Veja Ways to contribute.

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

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