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.

Resumindo:

  • Você está livre para baixar e usar Godot para qualquer propósito, pessoal, sem lucro, 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, dê uma olhada nos 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)

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.

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

There are several reasons to use GDScript--especially when you are prototyping, in alpha/beta stages of your project, or are not creating the next AAA title--but the most salient reason is the overall reduction of complexity.

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?

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

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

Porquê a Godot usa Vulkan Ou OpenGL ao invés do Direct3D?

O Godot busca a compatibilidade entre plataformas e padrões livres antes de tudo! O OpenGL e O Vulkan são tecnologias livres e disponíveis em (quase) todas as plataformas. Graças a essa decisão de projeto, um projeto desenvolvido com Godot no Windows funcionará sem problemas no Linux, macOS e mais.

Como há poucas pessoas trabalhando no renderizador do Godot, preferimos ter menos renderizadores backend para manter. Além disso, usar uma única API em todas as plataformas nos permite uma melhor consistência com menos problemas característicos 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 quê Godot pretende manter a quantidade de suas funcionalidades base baixa?

Godot intencionalmente não inclui funcionalidades que podem ser implementadas por [i]add-ons[/i] 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 de código e "superfície" para bugs Toda vez que aceitamos um novo código no repositório do [i]Godot[/i], 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 fonte continuará simples e rápida. Isso deixa mais fácil para novos contribuidores começarem a trabalhar com a 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 à Internet. Ter certeza de que todos podem baixar a Godot, extraí-la e rodá-la 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 "Templates" de exportação Isso impacta diretamente no tamanho dos projetos exportados com a Godot. Em plataformas móveis e na Web, manter os tamanhos dos arquivos pequenos é essencial para assegurar instalações rápidas e baixos tempos de carregamento em dispositivos de baixa performance. E, 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 em efeito 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 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 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 EditorPlugins e scripts de 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.

Quando será o próximo lançamento?

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

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 em 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 do Godot é e sempre será, a funcionalidade central como descrita no Roadmap, consertando bugs e discutindo problemas, e discussão entre membros da comunidade do Godot.

A maior parte dos desenvolvedores na comunidade do 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).

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

Ao criar um aplicativo que não seja um jogo, tenha certeza de habilitar o low-processor mode nas Configurações do Projeto para diminuir o uso da CPU e da GPU.

Dito isso, nós não vamos recomendar o uso do Godot para criar um aplicativo mobile visto que o modo 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 usada 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 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 Control, que são usados para renderizar o editor (que é escrito em C++). Estes nós Control 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.

Why does Godot not use STL (Standard Template Library)?

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 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 falhar, não importa o quê. Se ocorrer uma situação inesperada, o 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 eu posso ajudar o 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.