Godot: C# como linguagem de script

Adicionar mais recursos ao GDscript seria a melhor maneira de abordar o script na minha opinião

Para mim, o principal motivo para escolher Godot em vez de outros mecanismos de jogo é o esquema de script simplificado. Godot não está se oferecendo para aprender uma nova linguagem de programação. Está oferecendo aprender Godot e sua linguagem de script como uma ferramenta combinada para o desenvolvimento de jogos. Essa é uma abordagem menos intimidante do que oferecer aos recém-chegados o aprendizado de C++ ou qualquer outra linguagem de programação para scripts.

Obrigado por abrir esta edição, acho que este é um tópico em que há uma grande diferença entre a melhor escolha racional e o que a maioria pedirá.

A razão mais importante pela qual existe mais do que um motor é porque para além de factores unidimensionais como o desempenho em tarefas de uso geral ou a acessibilidade das interfaces existem factores multidimensionais como o desempenho para situações específicas (não existe um vencedor óbvio se comparar um motor otimizado para jogos 3D e um otimizado para jogos 2D) ou usabilidade para grupos específicos de usuários (uma interface amigável para iniciantes geralmente tem que ocultar funções avançadas).
Então, para encontrar um lugar entre outros motores, um motor tem que escolher uma "filosofia".

Agora, uma linguagem de script é parte integrante de um mecanismo, então a filosofia da linguagem deve se adequar à filosofia do mecanismo, ou pelo menos não deve contradizê-la.

Então, qual é a filosofia de Godot? Vejamos alguns fatos:

• Comparado ao Godot, todos os outros motores principais estão inchados.
  O download do Godot é menor que 20 MB, toda a "instalação" é um executável com menos de 50 MB de tamanho. O Lumberyard, por outro lado, tem um tamanho inicial de download de cerca de 5,5 GB, atualmente minha pasta de instalação é de 15,3 GB. A principal razão para isso é a filosofia da Amazon em relação às dependências. Esse download inicial contém 10,5 GB de imagens criadas de 42 dependências e, se você já trabalhou com serviços da Web da Amazon antes de saber que o AWS SDK não é tão diferente nesse aspecto, não é uma questão de necessidade ou capacidade, é uma questão de escolha. Por exemplo, enquanto o Lumberyard inclui boost e Lua, Godot contém suas próprias versões dos contêineres STL mais importantes e usa GDScript em vez de lua, o que mantém o tamanho baixo, remove dependências e torna o código muito mais legível e acessível.
• O código-fonte de Godot é muito acessível.
  Isso começa com a escolha do sistema de compilação (SCons) que usa python como linguagem de compilação. A maioria dos outros projetos usa sistemas de compilação existentes com linguagens de compilação proprietárias ou escreve seu próprio sistema de compilação proprietário, ambos os quais têm um impacto negativo na legibilidade do código de compilação.
  O próprio código-fonte também está acima da média nesse aspecto. Levei mais ou menos o mesmo tempo para descobrir como escrever um único nó Unreal Blueprint em C++, como levei para escrever o código para minha primeira solicitação de pull para Godot. Isso não quer dizer que o código C++ do Unreal era ilegível, simplesmente não é tão limpo quanto o de Godot, pois usa mais macros e exige que o usuário entenda mais do código de projeto padrão do Unreal do que Godot.
• Godot promove os princípios KISS e OO.
  Para ilustrar isso, vejamos alguns objetos simples no Unity. O primeiro conceito com o qual você se depara no Unity é o de GameObjects com componentes anexados. "composição sobre herança", como é frequentemente chamada (prefiro a formulação de Michael J. Dickheiser "Contenção versus Herança" de "C++ para desenvolvedores de jogos", que não soa como um grito de guerra e promove a reflexão sobre o tópico) é um padrão de sucesso pela flexibilidade que oferece. Essa flexibilidade tem um custo. Se tudo no seu jogo for um GameObject, você não pode realmente obter uma referência ao "jogador", porque não há jogador, há apenas um GameObject que pode ou não ter um componente de jogador anexado (ou melhor, aqueles vários componentes que fazem o jogador).
  Os desenvolvedores do Unity viram o mesmo problema, às vezes você só quer criar um Button, não um GameObject com o componente Button. Então o que eles fizeram foi o seguinte: eles permitiram que você criasse "um botão" através da interface do editor que realmente cria um GameObject com um componente Button anexado. Além disso, eles rotearam os membros mais importantes do GameObject por meio de cada Componente, de modo que agora você pode usar uma referência a um Button da mesma forma que usaria uma referência a um GameObject. Você pode pedir a um Button sua posição, você pode pedir uma lista de seus componentes - mesmo que o Button seja realmente um componente, não o objeto ao qual ele está anexado.
  Então agora temos uma mistura das duas formas mais populares de descrever um mundo de jogo - baseado em composição e em objetos simples. Mas quando você olha para projetos de iniciantes (e até mesmo alguns projetos avançados) você vai descobrir que Unity também facilita a terceira maneira de interpretar um mundo de jogo: programação procedural.
  Em Unity cada objeto é sempre parte de uma "cena". Ao contrário de Godot, esse termo descreve uma parte de nível superior do jogo (disclaimer: agora o Unity tem um SceneManager que fica no topo das cenas, mas meu ponto ainda é válido), o que significa que se um inimigo quiser atirar no jogador, ele pode simplesmente pesquise a cena atual para o jogador e interaja com ela. Essa é a ideia central da programação procedural - você tem uma sequência de comandos que alteram o estado do ambiente sem levar em conta a propriedade. Claro que tecnicamente ainda é programação orientada a objetos, mas como todo objeto pode esperar fazer parte da mesma cena, você está habilitado a escrever código que se comporta como código global. Por exemplo, se você quiser instanciar um objeto, tudo o que você precisa fazer é chamar "Instantiate(templateObject)" e uma cópia do templateObject será instanciada e adicionada à cena. Não há necessidade de perguntar em qual cena adicionar o objeto porque sempre há uma cena da qual tudo faz parte.
  Então Unity promove uma mistura de composição, pensamento orientado a objetos e programação procedural.

Godot, por outro lado, promove o pensamento orientado a objetos, pois, por exemplo, cada objeto em seu jogo pode ser construído como uma cena própria. Essas cenas podem ser iniciadas sozinhas, permitindo testá-las, alterá-las sozinhas etc. Isso, por sua vez, exige que você construa essas cenas de uma maneira que não exija acesso ao ambiente. Por exemplo, se um inimigo quiser interagir com o jogador, é muito mais viável usar sinais para informar à cena subjacente que uma interação é solicitada ou simplesmente exigir que a cena forneça ao inimigo uma referência ao jogador. Você ainda pode pesquisar a cena do jogo para o jogador, mas se você fizer isso, a cena inimiga não poderá ser executada por conta própria, de modo que o design simplesmente não se encaixa nas ferramentas também.

Então, como isso faz diferença em relação à escolha das linguagens de script?
C# é para linguagens o que Unity é para mecanismos. A filosofia do C# sempre foi que, se algum recurso fosse bom tê-lo adicionado à linguagem. Basta olhar para a lista de recursos que foram adicionados com cada versão: https://en.wikipedia.org/wiki/C_Sharp_ (programming_language)#Features_added_in_versions
Agora você pode argumentar que ter um recurso não é algo ruim, certo? Você não precisa usá-lo, apenas deixe-o se não gostar. Infelizmente isso não é verdade para um idioma. Com a importância da internet hoje as línguas não são mais ferramentas, são culturas. Mais cedo ou mais tarde, você terá que procurar ajuda no Google, usará módulos ou objetos criados por outros, usará novos recursos incorporados pela comunidade no mecanismo e, mais cedo ou mais tarde, isso exigirá que você use recursos de linguagem que nunca pretendia usar.
Além disso, se você estiver trabalhando em equipe, aprenderá a gostar de usar uma linguagem que promove um estilo de codificação comum e não oferece dezenas de maneiras de escrever o mesmo código.

Agora você pode se perguntar se quero dizer que uma linguagem com menos recursos é sempre melhor do que uma com mais recursos. Claro que não é o caso. Vamos comparar como o Java resolveu o problema.
C# permite escrever código não gerenciado. Basta usar a palavra-chave apropriada e você pode usá-la diretamente no mesmo arquivo. Ele também permite escrever código funcional usando LINQ, que lê como código SQL e se comporta como código funcional. Para entender completamente o que um arquivo faz, você pode precisar saber bastante sobre paradigmas de programação.
Se você estiver escrevendo Java, você também pode usar programação funcional, basta escrever em um arquivo separado, usar um compilador diferente e chamá-lo de "programação Clojure". Se você preferir combinar programação orientada a objetos e programação funcional, você pode chamá-la de "programação Scala". A parte importante é que você ainda está escrevendo código para a JVM que pode interagir facilmente com o código de outras linguagens JVM.
As linguagens .NET têm a mesma capacidade, mas não são usadas na filosofia C#. Eles poderiam muito bem ter decidido manter um ou dois paradigmas de programação em C# e criar uma nova linguagem para adicionar novos paradigmas, mas em vez disso eles optaram por "uma linguagem para conquistar todos eles" - o que é totalmente bom, é ótimo ter uma linguagem assim. Você deve estar ciente dessa filosofia e das escolhas que você tem como programador.

Para encurtar a história: de todas as linguagens que temos, acho que C# é a pior opção para Godot. É um ajuste natural para o Unity, mas se você tem todas essas opções, por que escolher uma linguagem que promova a mistura e combinação de paradigmas em um mecanismo que promova princípios OO limpos e programação KISS em todas as outras partes?

Portanto, se você acha que C# seria uma boa adição ao Godot, NÃO estou discordando de você - estou apenas dizendo que existem alternativas ainda melhores, que devem ser avaliadas primeiro e que seriam imediatamente esquecidas quando o C# fosse implementado.

@hubbyist

Adicionar mais recursos ao GDscript seria a melhor maneira de abordar o script na minha opinião

Isso pode acontecer com certeza, não acho que seja incompatível com as outras propostas.

Para mim, o principal motivo para escolher Godot em vez de outros mecanismos de jogo é o esquema de script simplificado. Godot não está se oferecendo para aprender uma nova linguagem de programação. Está oferecendo aprender Godot e sua linguagem de script como uma ferramenta combinada para o desenvolvimento de jogos. Essa é uma abordagem menos intimidante do que oferecer aos recém-chegados o aprendizado de C++ ou qualquer outra linguagem de programação para scripts.

Mas Godot já pode ser usado a partir de C++, então nada realmente mudaria (desde que o GDScript seja mantido), exceto que a codificação em C++ seria facilitada para aqueles que desejam fazê-lo (atualmente, escrever módulos requer compilar todo o Godot e não está integrado no fluxo de trabalho).

@Warlaan bela análise. Se você leu meu post, eu também discordei de C# ser uma boa escolha para Godot, por isso propus expandir os recursos C++ já existentes para possibilitar seu uso como linguagem de script, com o GDScript permanecendo o idioma padrão para a maioria dos usuários.

Os usuários devem ser capazes de escrever praticamente em GDScript, porém não é razoável pensar que um grande jogo seria escrito em GDScript. Na minha opinião, não há nada que impeça Godot de ser adequado para jogos grandes, exceto desempenho GDScript, porque o mecanismo é muito bem projetado e já tem um desempenho muito bom (e o Vulkan provavelmente o tornará ainda melhor).

Na minha opinião, o desempenho não agrada a maioria dos usuários de Godot, mas poderia trazer mais profissionais para Godot, o que significa mais contribuições, o que significa uma Godot melhor para todos.

@paper-pauper entendi que estamos do mesmo lado. Quando escrevi "se você acha que C# seria uma boa adição", eu estava me dirigindo a "você, o leitor anônimo", não a você pessoalmente. ;-)
E sim, qualquer nova linguagem de script drenará a atenção do GDScript. Duvido que a comunidade cuide de mais de um idioma, mais cedo ou mais tarde alguns recursos ficarão indisponíveis ou quebrados de qualquer um deles, talvez até o ponto em que um dos idiomas seja descartado.

Também concordo que os únicos problemas reais aqui são os tempos de compilação do C++ e o desempenho do GDScript.
O argumento de que as pessoas já conheciam C# é simplesmente errado imho. Trabalho profissionalmente com C# há cerca de 4 anos (principalmente trabalhando com C++ e SQL) e a única coisa que aprendi nesse tempo é que provavelmente nunca poderei dizer que realmente conheço essa linguagem. Afinal com o C# 6 e as proposições para 7 o número de funcionalidades ainda está crescendo.
Então, quando estamos falando sobre "saber C#", tudo o que podemos realmente nos referir é conhecer a sintaxe mais básica que até mesmo o pior iniciante deve ser capaz de reaprender em poucos dias. Recentemente, dei uma palestra sobre diferentes mecanismos de jogo para uma turma de designers de jogos que usavam exclusivamente o Unity antes e nenhum deles comentou mal a sintaxe do GDScript, enquanto na verdade vários que desistiram da programação agora estão motivados novamente.

Então, sim, uma solução que acelere o GDScript e torne o C++ menos complicado de compilar e usar também seria minha favorita.

Muitas pessoas que "conhecem" C# não usam muitos de seus recursos que o tornam diferente do Java. Basta dar uma olhada na miríade de scripts do Unity que não vão muito longe do que subclasses.

Por esse motivo, sou altamente cético quanto às vantagens práticas que o C# daria. Eles são bons em muitos contextos, mas não no desenvolvimento de jogos. Além disso, o C++1x já oferece muitas dessas coisas (incluindo inferência de tipos, iteradores e algumas ferramentas funcionais básicas) sem nenhuma sobrecarga.

Além disso, é possível que a sobrecarga trazida pelo CLR (ou mesmo pela JVM) possa fazer o Godot ter um desempenho _pior_, embora eu veja algumas vantagens em usar o coletor de lixo da JVM (alguém sabe mais sobre o gerenciamento de memória do Godot)?

Li em fóruns sobre pessoas que não usam Godot por causa do GDScript. Acho que é uma mente fechada, porque não há nada de errado nisso, exceto o fato de ter uma seleção ruim de bibliotecas, que tentei abordar em outro ticket, #3943, sugerindo uma solução que tem zero sobrecarga e multiplataforma Apoio, suporte.

Sem a necessidade de implementar um JIT C++ via LLVM, existe uma solução que roda em código nativo e não requer nenhuma manipulação dos fontes do Godot: vinculação dinâmica.

O primeiro permitiria código nativo sem ter que recompilar o Godot do zero: você apenas o compila como um arquivo .so e o adiciona ao seu caminho de carregamento, então o usa do GDScript sem sobrecarga (já que são todas as chamadas de função).

Isso deve ser muito fácil de fazer (via libdl?)

Além disso, há a ideia de compilar GDScript para C++, assim como o ENIGMA faz com sua linguagem. Isso não é fácil, mas obviamente oferece melhor desempenho.

alguém sabe mais sobre o gerenciamento de memória do Godot?

Dos documentos :

Se uma classe herdar de Reference, as instâncias serão liberadas quando não estiverem mais em uso. Não existe um coletor de lixo, apenas uma simples contagem de referência. Por padrão, todas as classes que não definem herança estendem Reference. Se isso não for desejado, então uma classe deve herdar Object manualmente e deve chamar instance.free(). Para evitar ciclos de referência que não podem ser liberados, uma função deref fraca é fornecida para criar referências fracas.

Só para notar...

Uma grande vantagem do GDscript é que é uma linguagem totalmente sob o controle do Reduz e dos outros desenvolvedores, como funciona para os desenvolvedores Godot não depende de uma equipe externa e, portanto, pode ser desenvolvido de forma específica para o design do motor e ter o que os usuários estão solicitando.

Outra coisa é que, embora o GDscript não seja uma linguagem real de alto desempenho no momento, provavelmente há muitas áreas em que o desempenho pode ser bastante aprimorado, preservando sua simplicidade e natureza de tipagem dinâmica.

Depois, há o fato de que o GDscript não requer nenhum conhecimento de compilação e que você não precisa de nada fora do editor embutido do Godot (o que torna o fluxo de trabalho agradável e organizado, para não mencionar fácil e rápido).

Só uma pergunta, como o interpretador GDscript funciona internamente? Analisa cada linha em tempo de execução como a linguagem Basic antiga ou converte todo o script em tabelas de bytecode e depois executa o bytecode?

@RebelliousX

https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_compiler.cpp
https://github.com/godotengine/godot/blob/master/modules/gdscript/gd_parser.cpp

Eu não acho que existam mais linguagens sérias que funcionem como BASIC! :)

Oi!
Aqui está a história do GDScript:
///////////////////////////
História
Inicialmente, Godot foi projetado para suportar várias linguagens de script (essa capacidade ainda existe hoje). No entanto, apenas GDScript está em uso no momento. Há um pouco de história por trás disso.

Nos primeiros dias, o mecanismo usava a linguagem de script Lua. Lua é rápida, mas criar ligações para um sistema orientado a objetos (usando fallbacks) era complexo e lento e exigia uma enorme quantidade de código. Após alguns experimentos com Python, também se mostrou difícil de incorporar.

A última linguagem de script de terceiros que foi usada para jogos enviados foi Squirrel, mas também foi descartada. Nesse ponto, ficou evidente que Godot funcionaria de maneira mais otimizada usando uma linguagem de script integrada, pois as seguintes barreiras foram atendidas:

• Godot incorpora scripts em nós, a maioria das linguagens não são projetadas com isso em mente.
• Godot usa vários tipos de dados integrados para matemática 2D e 3D, linguagens de script não fornecem isso e vinculá-los é ineficiente.
• Godot usa threads pesadamente para levantar e inicializar dados da rede ou disco, intérpretes de script para linguagens comuns não são amigáveis ​​para isso.
• Godot já possui um modelo de gerenciamento de memória para recursos, a maioria das linguagens de script fornece seus próprios, o que resultou em esforço duplicado e bugs.
• O código de ligação é sempre confuso e resulta em vários pontos de falha, bugs inesperados e insustentabilidade geral.

Finalmente, o GDScript foi escrito como uma solução personalizada. A linguagem e o interpretador para ele acabaram sendo menores que o próprio código de ligação para Lua e Squirrel, e igualmente funcionais. Com o tempo, ter uma linguagem integrada provou ser uma grande vantagem
////////////////////////

Na minha opinião, c++ pode ser o melhor. Existem algumas soluções como:
https://github.com/RuntimeCompiledCPlusPlus/RuntimeCompiledCPlusPlus
Mesmo o script Angel normalmente pode ser como um runtime compilado.
Em scripts, adoro python porque sempre adoro soluções que misturam jogos e simulações científicas (python tem muitas bibliotecas científicas). Então eu reclamo! em outra edição por que Godot tem sua própria biblioteca de física: https://github.com/godotengine/godot/issues/4217
Existem alguns problemas sobre linguagens como C#: https://github.com/godotengine/godot/issues/2790

Boa descoberta, @alabd14313 - isso resolveria praticamente a maioria dos problemas, deixando o GDScript sozinho.

Sobre o RCCPP, é uma ideia muito boa. Eu acho que se Godot o suportasse no modo de editor e o desabilitasse nas compilações, haveria desempenho máximo e os tempos de iteração seriam bem rápidos. Eu ouvi outros mecanismos como o Unreal Engine fazerem algo semelhante com C++, e acho que seria muito legal se Godot permitisse codificação C++ semelhante a scripts.

Parece que os autores conhecem suas coisas, porque nesta página eles listaram a maioria das alternativas para sua abordagem (incluindo a que mencionei, o LLVM JIT).

Acho que essa abordagem faz mais sentido, porque Godot é escrito em C++ (e acho que isso nunca vai mudar, considerando que C++ será ainda melhor em alguns anos), ele já tem uma API C++ e C++ funcionando tem praticamente o desempenho máximo desejável com zero sobrecarga e não haveria tempos de execução ou gerenciadores de memória adicionais. Espero que os devs dêem uma olhada nisso.

Estou um pouco surpreso ao descobrir que este tópico que afaik foi iniciado como uma reação à proposta de adicionar C# como linguagem de script ainda não contém um único argumento PARA C#, mesmo depois de seis pessoas terem expressado sua opinião.
Talvez a decisão de adicionar C# não seja tão premeditada quanto eu presumi pelos rumores que ouvi.

@Warlaan o que acontecerá se postar este URL no grupo do Facebook? :)

Por favor, altere o título para algo como "C++ como linguagem de script".
C++17 tem mais recursos:
http://blog.mattnewport.com/why-c17-is-the-new-programming-language-for-games-i-want/
Admiro os desenvolvedores Godot e agradeço-lhes por seus trabalhos. mas resisto às bibliotecas Box2D/LiquidFun/Bullet. Dessa forma, os desenvolvedores podem se concentrar no pipeline, não em componentes como a física. Com C++ eles podem focar no desempenho, não mantendo e atualizando o gdscript. Teoricamente, o RCCPP pode implementar alguns novos recursos, como o modo de ferramenta, de uma maneira melhor. Talvez...

@reduz mencionou há alguns meses que quer implementar scripts visuais, algo como projetos irreais. Com RCCPP o fluxo de trabalho entre C++ (para programadores) e Visualscripting (para designers de nível e artistas) pode ser implementado como:
Introdução à programação C++ em UE4
C++ e plantas
Assim, em um grupo, os programadores podem desenvolver novas classes de projeto para artistas e artistas as usam em vez de codificar diretamente.

@Warlaan IMHO é porque muito da conversa em C # foi alimentada por pessoas que querem que Godot seja uma imitação do Unity, mas felizmente muitos aqui percebem que Godot é algo próprio e já está à frente do Unity em muitos aspectos e não seria justo para deixá-lo ser afetado pelos mesmos problemas.

@alabd14313 Eu mudaria o título, mas talvez seja melhor criar um problema separado e mantê-lo para a posteridade, para que possa ser vinculado quando alguém propor C# (como costuma ser o caso).

Estou hesitante sobre o script visual, para ser honesto, mas se ele pode ser implementado como um módulo, por que não? Claro, acho que ter scripts visuais (designers e novatos), GDScript (pessoas que podem programar ou estão dispostas a aprender) e C++ (programadores) faria do Godot um programa bastante equilibrado adequado para todos os níveis de habilidade, mas tornando a codificação C++ menos complicado e permitir uma interface mais fácil com bibliotecas de terceiros deve ter uma prioridade mais alta, IMHO, porque pode trazer muitos usuários profissionais (e, consequentemente, contribuidores).

O script visual Imho não é nem de longe refinado o suficiente para fazer sentido. É ótimo para fazer marketing e conversar com iniciantes em programação, mas pela minha experiência a fase de aprendizado durante a qual os iniciantes preferem fluxogramas é muito curta.
Para qualquer coisa, exceto as sequências mais básicas de chamadas, os sistemas que conheço (Unreal, Cryengine, Fungus, Stingray) simplesmente não são úteis. Quero dizer, esta captura de
Se você acha que isso não é tão ruim, deixe-me lembrá-lo de que, se você visse esse código em uma linguagem baseada em texto, cada linha de conexão que começa fora da tela seria uma variável com um nome (espero) significativo.

Os gráficos de fluxo são um pouco úteis quando se trata de shaders/materiais, pois resultados intermediários podem ser exibidos, mas mesmo assim o sistema sofre muito com o fato de que uma equação curta como
float x = (ab)*(a+b)/(1-(a+b))
preenche facilmente uma tela inteira quando é feito como um gráfico, pois toda multiplicação, soma ou diferença é um nó com duas entradas e uma saída. Isso é pelo menos 10 nós para a fórmula acima, e se você não quiser causar um caos de conexões, você terá que duplicar os nós a e b.

Os sistemas de fluxogramas que temos hoje (pelo menos os que conheço) eliminam a opção de dar nomes significativos aos valores, porque em vez de colocar um resultado em uma variável nomeada intermediária, você simplesmente a conecta ao próximo nó. Isso torna o código autodocumentado quase impossível e exige que você se esforce muito mais na documentação.
O que esses sistemas adicionam é a opção de colocar nós onde você quiser, o que, na minha experiência, resulta em código menos legível com mais frequência do que em um que é mais fácil de ler.

E, por favor, não fale sobre gráficos de fluxo como se eles não estivessem codificando. Eles são tanto código quanto qualquer outra linguagem de programação. Eles não estão digitando, só isso.

O script visual é para designers e artistas fazerem alterações sem precisar aprender a codificar. Alguns artistas também são capazes de fazer jogos interativos simples com ele. Ele tem seu alvo onde é definitivamente útil, mas não é para programadores.

@Warlaan Bem, depende de como você define "programação". Certamente o script visual é semelhante à definição de algoritmos, então não está longe de programar, mas a programação também é sobre outras coisas.

Existem algumas boas implementações de programação visual, no entanto. PureData é um e também há GDevelop , um programa de criação de jogos FLOSS muito bom (uma pena que não seja mais popular). Em suma, embora eu pessoalmente não goste (por algumas das razões que você mencionou), também é verdade que nós dois podemos programar, então para nós a programação visual é um processo lento e complicado para alcançar resultados comparativamente ruins.

Ainda assim, concordo com @reduz que algumas pessoas veem um apelo nisso. Eles não são as pessoas que estariam circulando por tópicos como esses, mas também fazem jogos. Acho que eles poderiam trazer algo para Godot.

A razão pela qual os fluxogramas funcionam bem para edição de shaders é que é muito visual (você tem nós que permitem carregar imagens, selecionar cores, etc... sem digitar os caminhos de arquivo e valores manualmente). Você também não tem medo de garantir que a sintaxe esteja correta e que as funções estejam escritas corretamente. Também não há necessidade de descobrir tarefas tão complexas, como trabalhar com uma matriz (tudo é calculado para você).

A metodologia de Godot para edição de shader acaba sendo uma boa abordagem porque separa claramente os componentes de vértice, fragmento e luz e também fornece orientações claras sobre com que tipo de dados você está trabalhando (se são informações normais ou informações da câmera).

Agora, com o script visual, acho que pode ser útil mesmo para coisas moderadamente complexas se os nós estiverem em um nível alto o suficiente em termos de mecânica de jogo (eles fazem coisas mais complexas e têm várias entradas) e se houver nós que permitem que você execute um script ou crie uma expressão/equação (que por sua vez pode ser usada para manipular valores de maneiras complexas). Os problemas que vi com outros sistemas de nós visuais desse tipo é que eles tentam ser o mais próximo possível da programação literal (ou seja, ter um monte de funções de baixo nível como nós em vez de ser mais como uma versão nodal de tijolos lógicos do Blender ou arrastar e soltar do GameMaker).

Claro, ele ainda não permitirá algo tão refinado e tão avançado quanto o que você pode fazer com scripts puros, mas ainda teria um uso para coisas como tipos de objetos simples dentro de um jogo (que não precisam de lógica muito complexa ) ou se você precisar apenas bater rapidamente em algo.

Concordo que algumas pessoas veem um apelo nisso, e também concordo que não é para programadores (são apenas nossas definições de "programador" que diferem ;-) ), então sugiro que deixemos a discussão assim, já que é um pouco offtopic.

Outro recurso útil do C++ é seu tipo estaticamente. Os recursos "auto" e "decltype" podem detectar o tipo de um objeto. Editor e conclusão de código podem ser mais fáceis. Em vez de focar no editor de código interno, podemos usar outro IDE externo. Por enquanto acho que codelite e qtcreator têm um status melhor na conclusão de código. Os codeblocks têm alguns problemas com as palavras-chave do c++11. Além disso, o eclipse-cdt tem uma boa conclusão de código. Um plugin para qtcreator é uma boa ideia (como unreal-visual studio e Unity-Monodevelop). O IDE externo pode ser identificado com um caminho do sistema nas configurações do godot (como /use/bin/qtcreator), não há necessidade de ser compilado e compactado com o godot (ao contrário do pacote Unity tem monodevelop embutido).
Existem outras ferramentas como cppcheck e valgrind que possuem plugins no qtcreator.
Se você quiser ter uma prévia do que é RCCPP:
demonstração

Eu adoraria ver uma linguagem de script baseada em C++ para Godot, mas implementar todos os recursos de C++ seria complicado, como programação de modelos. Deve haver algumas limitações para este tipo de linguagem de script (STL) e modelos não devem ser usados. Também RTTI pode causar problemas de desempenho.

Eu amo GDscript, minha única reclamação sobre isso é a poluição do namespace de variáveis, ao lidar com scripts grandes, definições de variáveis ​​antes de ready() podem se tornar muito confusas e propensas a erros no código devido ao compartilhamento de variáveis ​​entre funções do mesmo arquivo de script .

Meus 3 centavos. (uh... acabou em 20, mas deixe estar...)

Como @alabd14313 mencionado anteriormente "está no ponto em que está" por causa da evolução ao longo dos anos que levou Godot à forma que está hoje.
Não importa se a natureza faz isso ou nós humanos, corrigir as coisas no momento da criação parece ser a melhor maneira de desenvolver, e devo admitir, graças a isso, gosto muito de Godot como é e onde a evolução o trouxe.

Tem todas as peças necessárias.

Nós que podem ser combinados em objetos mais complexos, salvos como cena, então reutilizados novamente como um objeto "simples" em outra cena que é um recurso incrível e mega flexível, na verdade, limitado apenas pela imaginação do próprio usuário e pelas fronteiras da criatividade.

Simples de usar e aprender GDScript, poderoso o suficiente para controlar todos os nós da maneira que nós codificadores estamos acostumados a fazer - digitando linhas de código.
Além de fazê-lo de forma rápida e fácil (completar código / documentação de construção / dicas de ferramentas úteis aqui e ali) sem a necessidade de compilar, basta digitar, experimentar, ajustar e, novamente, polir até a perfeição.

A implantação em várias plataformas com REALMENTE um clique (sem mencionar essas implantações no Android via wifi / adb, edição de vida, depuração, ect é apenas uma obra-prima de arte, não ... É mais, é uma mágica!)

Além disso, todas essas familiaridades com ferramentas comumente usadas, como o liquidificador, etc.
(importar coisas e funciona fora da caixa, tudo está onde e como deveria estar)

E, finalmente, admito que às vezes até a ultracriatividade pode não ser suficiente quando se trata de fazer algo milhões de vezes em um loop e caber em 1 frame. É aí que entra o material C. Se você conhece C, precisa dele, nada o impede de criar plugin, próprio nó personalizado ect, que faz exatamente o que deseja.

Tem quase tudo, e com o tempo, acredito que terá tudo.
(Quer dizer, as coisas que hoje "ainda não estão implementadas" e é preciso fazê-lo 'de alguma forma' ou 'mãos nuas' (leia-se: use uma ferramenta externa para isso) ex. ajustar algo manipulado 3D de maneira fácil (tem que usar o liquidificador )

Godot é incrível e uma coisa mágica, perfeitamente perfeita em seu caminho por onde passa.Precisa de ajustes e adicionar coisas aqui e ali, mas é isso.

Scripts visuais?
Uh. Isso poderia forçar nós codificadores a mudar a maneira de pensar "um pouco" de uma maneira incomum, além disso, não acredito que possa ser tão flexível e legível quanto o código normal.
Imagine que você está codificando e tem uma linha simples como esta ( abc / def ) * ghi
então da maneira mais rápida, como de costume (?) para economizar digitação, você marca parte de algo, cola aqui, recorta ali, cola novamente e em 5 segundos e aperta as teclas, termina com "simples" (porque você sabe o que faz) um forro como ((((abc/def+((abc/def)_ghi^4))_ghi)+(abc/def_(100))_ghi)+abc)
É comum, talvez muitos de nós façamos dessa maneira de maneira super rápida.
Agora imagine fazer isso de maneira Visual...
Pode levar uma tela inteira, muito trabalho com o mouse e não parece tão legível quanto deveria.
(claro, esses forros também não parecem fáceis depois de um ano, mas é para isso que servem os comentários)

E se alguém tiver 100 dessas linhas uma abaixo da outra?
Visualmente ele poderia conseguir um campo de futebol para exibi-lo. Que tal analisá-lo, mudar, isso é uma bagunça e uma grande dor de cabeça.
Claro que os codificadores podem fazer isso porque, não é uma linguagem usada, fazer de alguém um codificador, mas uma maneira específica de pensar, criar algoritmos, manipular dados como pequenas partes e como um todo.
A linguagem, não importa se é C, Python, PHP, Java ou Visual scripting, é apenas uma ferramenta para anotar os pensamentos.
E aqui, Imho, a digitação normal com teclado é a forma mais rápida e legível de anotá-la.
Por outro lado Se alguém não sabe codificar, você espera que ele de repente revele genialidade algorítmica e perceptividade para não se perder dentro da própria ideia e representação visual dela, considerando que quando pensamos em jogo - falamos de algo mais complexo do que duas bolas batendo uns aos outros com a física.

Então, para quem realmente o Visual Scripting seria?
Para tornar a vida dos codificadores mais difícil ou limitar o godot ao nível - engine para "jogos simples" para iniciantes?

Pessoal, há uma longa discussão sobre Visual Scripting em #1220. Por favor, não vamos discutir os mesmos tópicos novamente aqui.

Pessoal, há uma longa discussão sobre Visual Scripting em #1220. Por favor, não vamos discutir os mesmos tópicos novamente aqui.

A maioria dos posts aqui eram tão longos, talvez me tenham feito perder-me durante a leitura.
Desculpe :relaxado:

@RebelliousX Mesmo com RTTI, o C++ ainda teria um desempenho muito melhor que o GDScript. Embora seja verdade que os modelos podem ser um problema.

A solução proposta por @reduz em #3936 já tornaria a codificação em C++ bastante trivial - você apenas faz isso com seu editor e compilador de sua escolha e link com a API do Godot. Se isso for implementado, mesmo que o script em C++ seja bom, não seria muito diferente de escrever código em C++ e chamá-lo de GDScript, em termos de desempenho. Resumindo, acho que focar no #3936 (que é uma solução simples) melhoraria muito:

• Desempenho (já que escrever partes em C++ seria extremamente fácil)
• Disponibilidade de bibliotecas de terceiros (já que os wrappers podem ser distribuídos mais facilmente, mas não tão facilmente quanto o #3943)
• Base de usuários e contribuidores (muitos programadores C++ adotariam Godot)

Então, pode haver foco na digitação estática em GDScript e na otimização do interpretador (por meio de um JIT ou compilando GDScript para C++), mas isso pode ocorrer mais tarde se a escrita de módulos for facilitada.

Eu só quero mencionar alguns pontos que se infiltraram nessa discussão, mas ainda não foram abordados:

• Alguns de nós estão falando sobre melhorar o sistema existente (GDScript como linguagem de script, C++ como linguagem de backend) facilitando o desenvolvimento de C++ e aumentando o desempenho do GDScript. Outros estão falando em usar C++ (ou Java/C#/...) como linguagem de script. Pode parecer que não há diferença real entre permitir o desenvolvimento rápido em C++ e torná-lo uma linguagem de script, mas explicarei com prazer como experimentei e observei o efeito negativo de linguagens de script poderosas na qualidade do design do jogo. E a menos que isso se torne o tópico da discussão, farei isso com prazer nos fóruns ou em outro lugar onde não sequestre este tópico.
• @RebelliousX : Quando você fala sobre "namespace variável", "scripts grandes" e "compartilhamento de variáveis ​​entre funções", parece muito que você não entendeu completamente a natureza orientada a objetos do GDScript (sem ofensa). Cada arquivo GDScript é uma classe, portanto, conflitos de nome entre variáveis ​​(membro) devem ocorrer exatamente com a mesma frequência que em qualquer outra linguagem orientada a objetos. Você não está compartilhando variáveis ​​entre scripts, você está escrevendo várias funções que podem acessar o estado do objeto abrangente.

@Warlaan Sobre o primeiro ponto, acho que você poderia postar aqui, pois está relacionado ao tópico.

@Warlaan sem ofensa. Eu sei que o GDscript é uma classe própria e sei que as variáveis ​​são como variáveis ​​de membro normais na classe C++, mas parece que você perdeu completamente o meu ponto. Você entenderá quando tiver um script com mais de 1000 linhas de código. O que eu quero são referências ou ponteiros, em vez de criar miríades de variáveis-membro, apenas passá-las entre as funções-membro. É mais seguro assim.

Eu gosto de C#, mas vejo prós e contras.

Prós:

• Bom suporte a ferramentas (vamos ser sinceros, você codificaria em C# sem Visual Studio ou MonoDevelop?)
• Indicado para projetos de grande porte
• Amplamente utilizado e maduro, há toneladas de tópicos de suporte na internet.
• Bom desempenho, troca entre C++ e linguagens de script ao mesmo tempo em que é multiplataforma
• Relativamente fácil de vincular a C++

Contras:

• Lixo coletado: projetos de jogos em larga escala também precisam implementar estratégias de alocação para evitar que kicks de GC aconteçam com muita frequência, isso pode ser desagradável
• Não é tão integrado quanto o GDScript (completar caminho de nó? Variáveis ​​de membro de script em nós? Modelo de alocação de memória?)
• O tempo de execução é pesado, e o .NET framework ainda mais. Assim como no Unity, as bibliotecas padrão devem ser remapeadas para as de Godot.
• Não é o melhor ajuste para scripts reais, no sentido de fazer as coisas de forma rápida e suja. C# é mais detalhado e restritivo que GDScript.
• Ainda não há diretrizes sobre o desenvolvimento do Godot. A linguagem é genérica e pode fazer muitas coisas, e como Warlaan disse, os desenvolvedores têm culturas diferentes (você poderia literalmente ter um codificador WPF tentando Godot e se perguntando por que não há uma maneira MVVM de criar GUIs :p)

A maior parte disso também se aplica ao Java.
Talvez eu tenha esquecido outras coisas porque é tarde aqui.

Ok, esta é a minha experiência em relação a linguagens de script ricas em recursos resp. uma completa falta de uma linguagem de script dependendo da sua definição de "linguagem de script". Vou tentar mantê-lo curto. ;-)

Eu tenho trabalhado como reitor de engenharia no School4Games em Berlim, Alemanha há vários anos. Nessa escola não temos um corpo docente para design de jogos "puro", mas nosso curso de design de jogos é chamado de "desenvolvimento de jogos" e inclui aulas de programação suficientes para ensinar designers de jogos a desenvolver seus próprios protótipos e entender as possibilidades e limites das arquiteturas de hardware e software comuns.
Então, os alunos que eu ensino são pessoas que às vezes têm um interesse maior em programação, mas nenhum deles se candidatou a se tornar um programador.
Todo semestre eles têm que formar equipes e desenvolver um jogo. Como quase todos os futuros empregadores em potencial de nossos alunos usam o Unity, foi um requisito para os dois primeiros semestres trabalhar com esse mecanismo.

Agora vamos direto ao ponto sobre o efeito das linguagens de script:
Esses alunos se dividiram em dois grupos. Um que tenta evitar a programação ou perdeu a esperança (o que significa que eles vão assistir a aulas de programação, mas não pedirão ajuda se tiverem problemas, mas desistem silenciosamente) e um que mergulha tão fundo na programação que pula direto para tópicos que normalmente você não se preocuparia ao escrever protótipos de jogos. Por exemplo, um dos meus alunos do primeiro semestre publicou recentemente um tutorial sobre como escrever um Singleton em C# usando genéricos para que você possa transformar uma classe de componente Unity em um singleton herdando da classe genérica do tutorial. O interessante não é tanto que ele conseguiu escrever aquele artigo, afinal ele recebeu ajuda de seus professores e há bastantes recursos sobre o tema na internet. O ponto interessante é que um aluno que se inscreveu em um curso focado principalmente em design de jogos, em vez de programação, estaria interessado em um tópico de programação tão específico. O código desse tutorial nunca mudará devido a mudanças no design do jogo, é uma construção de programação pura.
Algo semelhante aconteceu com um aluno diferente que usou uma aula semelhante para transportar informações de uma cena de jogo para outra. Ele ficou bastante surpreso quando lhe mostrei que ele poderia fazer a mesma coisa com um membro estático público, o que mostra que ele estava procurando soluções completas e complicadas antes de entender completamente todos os elementos básicos.

Portanto, se você pulou adiante, isso resume o texto até agora: embora seja possível escrever código simples em linguagens ricas em recursos, observei várias vezes que as pessoas tendem a descartar soluções simples onde existem alternativas complicadas.

Isso não se deve apenas ao preconceito. Claro, isso é provavelmente um fator. Se você perceber que o código em tutoriais, exemplos ou outras classes em seu projeto parece complicado, você pode concluir que o seu também deve parecer complicado. Mas acho que a verdadeira razão é que na programação faz sentido tentar criar um código à prova de erros. É um desejo natural escrever código que não quebre assim que for usado em um local diferente ou assim que receber uma entrada diferente. E isso exige que você descubra quais opções existem para as quais você pode ter que se preparar.
Acho que essa sensação de ter que checar todas as eventualidades é o que divide meus alunos entre aqueles que se afogam no grande número de recursos do C# e aqueles que saltam direto e perdem o foco na linguagem.

Zylann mencionou a frase "rápido e sujo". Costumamos usar esses dois termos como uma frase, mas quando você pensa sobre isso, na verdade são dois fatores diferentes. Se é ou não possível codificar rapidamente é bastante mensurável. Se o código resultante está sujo ou não, por outro lado, depende de muitos fatores, sendo o mais importante o número de recursos que a linguagem usada possui.
Por exemplo, criar um nó de nível superior e usá-lo como um singleton no Godot é totalmente bom, pois o GDScript não oferece os recursos necessários para implementar o padrão da mesma maneira que você faria em linguagens como C#. Claro, usar o recurso de carregamento automático seria melhor, já que esse é o primeiro lugar em que outros desenvolvedores procurariam singletons (e isso torna a sintaxe um pouco melhor), mas se uma equipe decidir implementá-lo dessa maneira, duvido que haja muito argumento. Imagine, por outro lado, que alguém implementou um singleton no Unity apenas adicionando um membro estático público a uma classe. É tão rápido quanto, de certa forma, é a mesma coisa (ambas são instâncias de classe no local mais público), mas como o C# oferece a opção de tornar o construtor privado, acesse o singleton por meio de uma propriedade com inicialização lenta etc. esperado que você faça isso, caso contrário o código será percebido como muito sujo se não for quebrado.

Agora, o fato de os estudantes de design de jogos mergulharem em tópicos como esses pode ser uma vaga dica do meu ponto de vista, mas acho que posso ilustrá-lo ainda melhor falando sobre a situação no meu primeiro emprego em um grande desenvolvedor de MMO F2P. A equipe em que me juntei é uma das mais experientes desenvolvedoras de jogos da Alemanha. Seu chefe de desenvolvimento cria seus próprios motores internos desde 1995 e, apesar de terem acabado de ser comprados por outra empresa, ainda eram um dos desenvolvedores de maior sucesso na época.
Quando entrei para a equipe, eles estavam usando a terceira versão do mecanismo interno, que não tinha uma linguagem de script. Eles haviam implementado um antes, mas nessa versão do mecanismo eles voltaram a não ter nenhuma linguagem de script, pois havia problemas com a qualidade do código que os designers de jogos entregavam. Em outras palavras, como a linguagem de script era muito poderosa, foi tomada a decisão de mudar a barreira entre programadores e designers de jogos ao ponto em que os designers de jogos só editariam os níveis e alterariam as configurações nas folhas de configuração enquanto os programadores faziam toda a programação - em retrospectiva, eu notei que essa é praticamente a mesma situação em que meus alunos acabam (e parece que muitos estúdios profissionais que trabalham com o Unity acabam).
Agora, por que eu me importaria? Se isso está acontecendo repetidamente, isso não prova que é uma maneira bem-sucedida de trabalhar? Minha resposta é não, porque havia problemas, tanto técnicos quanto no design de jogos, que poderiam ser facilmente explicados pelo fato de que a comunicação entre programadores e designers de jogos se reduzia a escrever tarefas em uma direção e expor configurações na outra. Do ponto de vista dos designers de jogos, os recursos se tornaram caixas pretas que podiam ser habilitadas e desabilitadas, mas daquele lado da equipe não havia ninguém que pudesse discutir ou mesmo prototipar alternativas.
Os programadores, por outro lado, foram empurrados quase naturalmente para uma mentalidade de back-end. A mentalidade "rápido e sujo" do KISS se foi, porque nenhum de nós poderia prever como os recursos que construímos seriam usados. Lembro-me vividamente de uma vez que o banco de dados quebrou porque um designer de jogos implementou uma caça aos ovos de páscoa, fazendo com que os estoques crescessem muito mais do que costumavam ser. Essa foi a última vez que eu assumi que os requisitos de um recurso provavelmente permaneceriam os mesmos.

É por isso que eu acho que ter uma linguagem de script com poucos recursos como uma área definida para o código do jogo é extremamente importante e porque eu acho que não tê-la tem um efeito ruim no design do jogo.

• Escrever código rápido significa ignorar recursos transformando-o em código "rápido e sujo".
• O desejo de escrever código limpo divide os desenvolvedores entre aqueles que não codificam e aqueles que passam mais tempo pensando em codificação e menos tempo no jogo.
• Isso, por sua vez, divide toda a equipe em uma metade que trabalha no design de jogos sem conhecer a base de código e uma que trabalha em recursos sem saber como eles serão usados, deixando ninguém que possa criar recursos de mecanismo baseados no jogo projetar ou sugerir design de jogos com base em recursos que podem ser facilmente implementados.

Não é possível imaginar o desenvolvimento de jogos hoje sem usar bibliotecas de classes pré-construídas, afinal é isso que faz motores com conjuntos de ferramentas como Godot, Unity, Unreal etc. tão bem sucedidos. Mas a diferença entre todos esses mecanismos é onde a linha entre a programação e o design do jogo é traçada e quanta lacuna é criada entre os dois lados.
E com base em minhas observações, acho que a escolha da linguagem de script é um dos fatores mais importantes que podem criar essa lacuna ou fechá-la.

Aliás, a razão pela qual me envolvi tanto com Godot é que estou trabalhando para estabelecê-lo como motor obrigatório para o primeiro semestre. Só para você saber que não estou apenas falando, mas também extraindo minhas consequências. ;-)

@RebelliousX Tenho que admitir que ainda não entendi muito bem o que você quer dizer. Mas já que você disse que o que você quer são referências ou ponteiros, você poderia abrir uma nova solicitação de recurso e postar um exemplo de código para o seu problema lá? Para ser honesto, ainda parece que seu problema é de arquitetura de código, e não de recursos de linguagem ausentes.

Eu deveria ter acrescentado que o KISS traz benefícios principalmente para equipes pequenas. Godot é tão cheio de recursos que um desenvolvedor pode fazer um jogo. Mas assim que um projeto tem mais desenvolvedores, coisas "rápidas e sujas" se tornam menos prováveis ​​e são deixadas para prototipagem ou correções temporárias, então regras/diretrizes precisam ser configuradas. Então, realmente depende de quem está usando o mecanismo e para quê.

Godot em geral também tem mais restrições do que pensamos. Você não pode fazer singletons "c-static-style" ou variáveis ​​globais por um motivo: vazamentos de memória e facilidade de encadeamento. O GDScript não é tão destacado quanto o Python por um motivo: focado em tarefas e desempenho de desenvolvimento de jogos. O sistema de cena também é orientado a objetos por um motivo: você pode fazer "caixas" independentes que podem ser testadas e reutilizadas :)

Este tópico é sobre como adicionar um suporte a módulo C# (ou Java), mas não vejo código de exemplo. Vamos tentar algo em tempo real :)

using GodotEngine;

// Inherit a node type
public class Spikeball : RigidBody2D {

    // Exported variables
    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

    // Notice the naming convention. Should Godot API follow languages or should languages follow Godot?

    void _Ready() {
        SetProcess(true);
        // Should we use the generic system?
        Connect("BodyEnter", this, "_OnBodyEnter")
        // Or use C# features?
        this.bodyEnterEvent += _OnBodyEnter;
    }

    void _Process(delta) {
        var sprite = (Sprite)GetNode("Sprite");
        sprite.SetRot(sprite.GetRot() + delta*rotationSpeed);
        // Or we can have properties
        sprite.rot = sprite.rot + delta*rotationSpeed;
    }

    public void _OnBodyEnter(PhysicsBody2D body) {
        // We cannot invent C# members on the fly, so we can do this if the other script is in C# too.
        // ScriptInstance GetScript();
        var health = body.GetScriptInstance() as IHaveHealth;
        if(health != null) {
            health.TakeDamage(damage);
        }
        // But what if the other is GDScript?

        // A generic approach would look like this, a bit like SendMessage in Unity3D
        // object Call(string funcname, object arg1, ...); // where object can be seen as Variant
        body.GetScriptInstance().Call("TakeDamage", damage);

        // Same thing if we want to get a script variable
        var category = (string)body.GetScriptInstance().Get("category")
        Console.Print(category);
    }

}

O que você acha?
Esse arquivo pode ser compilado como um ativo DLL (ou executado em tempo real). Mas falando sobre isso, precisaríamos gerar um csproj como o Unity?

@Warlaan obrigado por compartilhar sua experiência. Corrija-me se eu tiver errado (foi um post longo), mas você está dizendo que oferecer uma linguagem com menos recursos é melhor para o bem dos programadores, para que eles possam se concentrar no desenvolvimento de seus jogos ao invés de sobrecodificação?

Se assim for, esta é uma observação muito sutil. Acho que os desenvolvedores da Godot têm que fazer o que é melhor para sua base de usuários - eles sabem o que é melhor.

E eu mesmo hoje estava me perguntando se algumas pessoas aqui (inclusive eu) não estão apenas pedindo sutilmente Urho3D , enquanto outras estão pedindo GDevelop . Godot é claramente uma ferramenta intermediária entre esses dois (mas perfeitamente adequada para profissionais, mais como Urho3D), e acho que deve permanecer assim, mas o Unity sempre lançará uma sombra sobre isso porque muitas pessoas aqui vem disso.

Não acho justo esperar que Godot seja uma imitação do Unity - Godot tem um design claramente melhor e, até onde sei, melhor desempenho. Mas algumas pessoas pensam que o GDScript não é adequado para desenvolvimento "sério" e nunca será porque é um tempo de execução personalizado, apesar do fato de que a versão antiga do Mono que o Unity usa também é de certa forma um tempo de execução "personalizado". Além disso, quando você escreve C# no Unity, você escreve código que funciona apenas no Unity na maior parte e segue seus padrões de design, então você também pode usar outra linguagem.

Acho que essas pessoas que querem C# estão erradas, mas um bom compromisso na minha opinião seria oferecer:

1) Melhor desempenho (tipagem estática, talvez um JIT)
2) Melhor suporte para bibliotecas de terceiros (via FFI e integração C++ mais fácil)

para GDScript. O resto pode ser feito em C++, incluindo módulos de escrita que implementam outras linguagens de script (que não precisam ser first-party - todos podem escrever um módulo C#, se quiserem).

@Zylann Não vejo vantagem em escrever esse código em vez do C++ equivalente, honestamente, e o código C++ terá melhor desempenho.

@paper-pauper a vantagem de escrever este código é a mesma do GDScript: você não precisa recompilar o mecanismo para cada plataforma para a qual deseja exportar e... bem, você pode escolher o idioma (e o desempenho é não é o único ponto, como mencionei anteriormente). Concordo que, atualmente, a experiência com GDScript é superior e C++ é a melhor escolha para desempenho puro. Mas, há pessoas que simplesmente não querem fazer C++, por melhor que seja.
Não estou pessoalmente interessado em Godot+C#, apenas avaliando o que acontece se você adicioná-lo ao Godot. E não é tão simples :p

Depois de ler o ótimo livro Game Scripting Mastery (você não pode encontrar muitos livros sobre o assunto, exceto o livro sobre compiladores Red Dragon). Minha conclusão é que, GDscript é adequado, é tão fácil continuar adicionando recursos a uma linguagem de script que a faz perder seu poder. O mais importante é implementar uma linguagem de script não inchada e o mais geral possível para torná-la adequada para diferentes projetos. Do mesmo livro, diz que Unreal está usando C++ com LLVM.

Outra ideia que pode ser mais leve do que implementar um runtime separado: que tal adaptar um transpilador como o TypeScript (que é muito semelhante ao C#, sem o runtime) para emitir GDScript em vez de JavaScript? Isso não precisa ser incluído no Godot, na verdade pode ser um módulo de terceiros. Ofereceria pelo menos tipagem estática (em tempo de compilação) e várias bibliotecas, com o mesmo desempenho do GDScript (porque seria GDScript).

Eu gosto do TypeScript, mas não vejo sentido em adicionar tal complicação. Se alguém fizer isso, terá que mantê-lo para ser compatível com as versões mais recentes do TS. Além disso, TS é um superconjunto de JS, então isso seria capaz de transpilar JS para GDScript? E então, teríamos algumas pessoas com bugs no transpilador pensando que é um bug no motor.

Ainda acho melhor ter uma versão estática do GDScript que possa recorrer mais facilmente ao JIT e ainda estar intimamente relacionado com a engine e com o próprio GDScript atual.

O objetivo do C# é usar uma linguagem estabelecida que possa ser usada fora do Godot também. O TypeScript pode se encaixar nisso, mas não estou convencido de que seja mais fácil fazer um transpilador TS do que incorporar um tempo de execução Mono.

Para mim, como disse no IRC, a melhor opção seria a possibilidade de fazer módulos vinculados dinamicamente. Assim, você pode trabalhar em C++ com mais facilidade e também pode haver módulos de terceiros com linguagens diferentes, como um para C# e outro para C++ como linguagem de script. Aumentaria a capacidade de aumentar os recursos da Godot sem ter que inchar o binário do motor principal.

@vnen

Para mim, como disse no IRC, a melhor opção seria a possibilidade de fazer módulos vinculados dinamicamente. Assim, você pode trabalhar em C++ com mais facilidade e também pode haver módulos de terceiros com linguagens diferentes, como um para C# e outro para C++ como linguagem de script. Aumentaria a capacidade de aumentar os recursos da Godot sem ter que inchar o binário do motor principal.

Ah, concordo 100% - na verdade, expressei uma opinião semelhante no #3936. Eu estava apenas jogando isso lá fora, já que mencionamos o tempo de execução do C # como uma desvantagem :)

Para mim, esse exemplo de módulo C# de @Zylann é adorável, eu mudaria do Unity agora mesmo se estivesse disponível - não se trata do alto desempenho do C++ ou da 'facilidade' do GDScript, é sobre estar confortável.

Ainda sou super novo no Godot e mal tive a chance de fazer um jogo de teste ainda, então vocês podem não achar minha opinião válida, mas para mim o GDScript é o maior obstáculo, não em como deve funcionar com Nodes e Cenas - eu entendo isso (e é bem legal!).

Mas para mim, é literalmente a sintaxe do GDScript que é realmente desanimadora para dizer o mínimo, para não mencionar que o editor de código está severamente ausente - eu adoraria usar o VS, pois já conheço todos os atalhos.
Tenho anos de escrita em C# trabalhado em minhas mãos e honestamente me sinto como uma criança tentando escrever em GDScript.

O que seria perdido ao permitir que os desenvolvedores escrevessem confortavelmente? Eu não preciso da infinidade que é Mono ou fantasias como Linq, eu só quero estar confortável enquanto estou escrevendo meu código.
Eu me contentaria com uma sintaxe do tipo C# para GDScript, pelo menos a opção de usar parênteses curly, ponto e vírgula e tipos explícitos - eu não suporto tipos implícitos pessoalmente, eles me deixam louco.
Acho que o GameMaker permite variações na sintaxe para acomodar diferentes demografias.

Isso é claro, apenas meus 2 centavos de várias horas com Godot - sinta-se à vontade para discordar (como tenho certeza que a maioria de vocês fará).

Além disso, acho que estou perdendo alguma coisa - o que é exatamente sobre GDScript que todo mundo ama tanto?
Eu não estou tentando ofender, eu só não vejo isso ainda.
Estou bastante familiarizado com Perl, então conheço o poder dos tipos implícitos e outros enfeites, mas deve haver mais do que isso, certo?

@Pikl :

Além disso, acho que estou perdendo alguma coisa - o que é exatamente sobre GDScript que todo mundo ama tanto?
Eu não estou tentando ofender, eu só não vejo isso ainda.

O ponto sobre o GDScript não é muito sobre a sintaxe (que é Pythonesque), mas mais sobre o quão integrado ele está com o mecanismo. Pode parecer pedante, mas a sintaxe é a menor das preocupações ao mudar para outro sistema. O que mais importa é a API. Mesmo que adicionássemos C# agora, você provavelmente se sentiria desconfortável com o novo paradigma, já que a maneira como você faz isso no Unity não é a mesma que você faz no Godot.

Desculpe, mas se adicionássemos linguagens para atender a zona de conforto de todo programador, passaríamos a eternidade fazendo exatamente isso. Embora possa fazer sentido trazer os usuários do Unity com o mínimo de estresse (no momento estamos tentando fazer um guia Godot para usuários do Unity), não acho que Godot deva se adaptar para funcionar como o Unity. Caso contrário, teríamos que fazer o mesmo para usuários de Unreal, Urho3D, GameMaker, etc.

Isso não quer dizer que o C# não está acontecendo (pode ser se for viável e dentro do interesse do mecanismo), é apenas que esses argumentos se aplicariam a muitas outras linguagens e mecanismos também.

@Pikl Em primeiro lugar, obrigado por fornecer o primeiro argumento a favor do C#. Agora deixe-me explicar por que eu acho que sua opinião é inválida. ;-P

Vamos dar uma olhada mais de perto no início do exemplo de código de Zylann:

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

Como regra geral, cada palavra-chave e cada caractere não-chave tem um significado. Se não, não deveria estar lá.
Ele começa com
using GodotEngine;
o que significa que este código está se referindo a funções importadas do pacote "GodotEngine". Como todo script no Godot se refere a essas funções e não há outros pacotes para importar, é inútil adicionar essa linha, então vamos removê-la.

A seguir temos
public class Spikeball : RigidBody2D {
Tudo no GDScript é público, então por que mencioná-lo?
class Spikeball : RigidBody2D {
Cada arquivo GDScript contém uma classe com o mesmo nome do script. Isso não é apenas uma convenção de codificação como em outras linguagens, é definido assim, então qual é o sentido de repetir o nome da classe?
: RigidBody2D {
Agora, já que : é a única "palavra-chave" significativa nesta linha, vamos substituí-la por algo um pouco mais legível.
extends RigidBody2D {
Qualquer codificador com um pouco de experiência usará a indentação para marcar as diferentes áreas do código. Isso significa que o código dentro da classe pode ser identificado pelas chaves ao redor E pelo recuo, e é por isso que os desenvolvedores do Python decidiram tornar o recuo obrigatório e se livrar das chaves agora redundantes.
Em nosso caso, a indentação nem é necessária no nível de classe, pois cada arquivo de script é definido como uma classe (a menos que você esteja usando subclasses marcadas por indentação).
extends RigidBody2D

Em seguida, temos as linhas de exportação.

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

Os caracteres [] marcam atributos que são definidos em classes de mesmo nome, que é um mecanismo que não existe no Godot, então ele simplesmente usa palavras-chave.

    export public float damage = 60f;
    export public float rotationSpeed = 2f;

Novamente, tudo é público:

    export float damage = 60f;
    export float rotationSpeed = 2f;

e você não precisa especificar o tipo de dados.

    export var damage = 60f;
    export var rotationSpeed = 2f;

As exportações são uma exceção porque o inspetor precisa saber qual widget mostrar a você, portanto, o tipo é apenas uma informação extra para a palavra-chave de exportação.

    export(float) var damage = 60f;
    export(float) var rotationSpeed = 2f;

Então a diferença entre este código C#

    using GodotEngine;

    public class Spikeball : RigidBody2D {

    [Export] public float damage = 60f;
    [Export] public float rotationSpeed = 2f;

e este código GDScript

extends RigidBody2D

export(float) var damage = 60f;
export(float) var rotationSpeed = 2f;

é simplesmente que todos os caracteres e palavras-chave foram removidos que não descreviam as opções que você tem no Godot.
Estou assumindo que agora está bem claro o que as pessoas gostam no GDScript. Você não é forçado a digitar coisas sem sentido ou redundantes e a sintaxe reflete as opções que você tem em vez de sugerir opções ou recursos de linguagem que não existem no Godot.

Vindo de um background em C++/C#/TorqueScript, devo dizer que o paradigma de Godot leva alguns dias para se acostumar, mas uma vez que sua simplicidade "clica", você pode passar da ideia à execução tão rápido quanto você pode digitar.

@vnen :

é só que esses argumentos se aplicariam a muitas outras linguagens e mecanismos também

Justo o suficiente, não estou prendendo a respiração nem espero ser acomodado - este não é o meu território.

agora estamos tentando fazer um guia Godot para usuários do Unity

Talvez eu possa ajudar com isso? Eu uso o Unity há vários anos e conheço a coisa muito bem em comparação com qualquer outro mecanismo - eu seria um bom rato de laboratório para este guia.

@Warlan :

Estou assumindo que agora está bem claro o que as pessoas gostam no GDScript. Você não é forçado a digitar coisas sem sentido ou redundantes e a sintaxe reflete as opções que você tem em vez de sugerir opções ou recursos de linguagem que não existem no Godot.

Isso faz todo o sentido - está de acordo com a ideologia do Perl de reduzir a quantidade de teclas necessárias para digitar um script. Mas, na verdade, a quantidade de pressionamentos de tecla que eu digitaria para esse exemplo seria a mesma - eu uso o preenchimento automático do VS ao máximo e raramente tenho que digitar mais de 3 caracteres para qualquer palavra-chave, tipo ou nome de variável antes de pressionar espaço ou abrir suporte para completá-lo. E quanto aos caracteres 'desnecessários' extras reais, eu prefiro tê-los lá, esse é apenas uma preferência sintática de açúcar.
Godot tem preenchimento automático, mas é lento, demora tanto que muitas vezes digitei minha linha inteira de código antes mesmo de aparecer na maioria das vezes.

Então, o que as pessoas gostam no GDScript é que ele é reduzido para ser o mínimo possível, fornecendo a funcionalidade exata que está disponível para uso e nada mais, além de reduzir o pressionamento de teclas.

Eu entendo isso, mas não faz nada para me ajudar a apreciá-lo mais - eu não me sinto confortável digitando GDScript, mas posso lê-lo perfeitamente bem. Eu não estou lutando para aprender, eu só não gosto, parece.
Talvez mais algumas horas fazendo um clone do Space Invaders ajudariam a me convencer - eu quero gostar de GDScript mais do que gosto.

Reflexão tardia:
É possível usar apenas C++ no Godot? Sinceramente, acho que preferiria aprender C++ e usar isso em vez de GDScript.

Talvez eu possa ajudar com isso? Eu uso o Unity há vários anos e conheço a coisa muito bem em comparação com qualquer outro mecanismo - eu seria um bom rato de laboratório para este guia.

@StraToN fez um post no grupo do facebook pedindo esse tipo de ajuda. Entre em contato com ele (não tenho certeza se há alguém trabalhando nisso também).

@neikeq Obrigado, feito!

@Warlaan Eu entendo sua comparação de código, mas para mim isso prova principalmente que o C# tem mais recursos e, como tal, é mais detalhado.

Você precisa de using porque existem namespaces para evitar colisão de nomes com muitas classes (o que já acontece comigo no meu próprio projeto de jogo).
Você precisa public porque existe uma noção de encapsulamento para evitar erros de codificador ao longo do tempo.
Você tem [SomeClass] porque podemos estender as anotações integradas para atender às diferentes necessidades do projeto e melhorar as ferramentas.
Quanto aos colchetes... não vejo vantagem, a não ser definir escopos.

Esses recursos estão aqui por um motivo. Entre eles, eu diria escalabilidade. Você desenvolveria um enorme jogo 3D multiplataforma com toda a base de código em GDScript? Bem, você pode. Mas muitos usuários preferem C++, C# ou Java, por causa dos profissionais que listei (e falo puramente sobre a linguagem, não sobre o framework).

Mas, ao mesmo tempo, não há nenhum projeto de jogo "enorme" que eu saiba que esteja sendo desenvolvido com Godot, então não há tantos exemplos :p
Além disso, vejo alguns recursos ruins em C# (aviso: opinião pessoal à frente):

Você pode ter variáveis ​​estáticas. Isso está errado, muitos erros vêm de estados/singletons globais. Ao contrário do carregamento automático, eles não estão vinculados a nenhum escopo de cena.
Você pode digitar incorretamente um ponto e vírgula no final de uma instrução while() de if(), tornando-a inútil e difícil de encontrar.
Você pode sobrecodificar. Concordo que, quando usado de maneira errada, o código C# pode se tornar muito complicado, enquanto outro código mais simples faria o mesmo. Mas depende das pessoas/experiência.

Oh. Eu não mencionei preload() . Isso simplesmente não pode chegar a C#/Java, a menos que você confie em truques de compilador: p

Alguém já começou a experimentar um módulo Mono?

Para adicionar minha mais humilde opinião, como alguém que é desenvolvedor C#, a isso...

Eu não acho que há muito valor em adicionar C# a Godot, pois você ainda teria que aprender as classes de Godot para fazer qualquer coisa e a única coisa que você realmente ganharia adicionando C#, é o estilo C mais familiar (para muitos) sintaxe e tipagem estática.
A questão da sintaxe é discutível, o Python tem a reputação de ser fácil de aprender para iniciantes e, como o GDScript é muito semelhante ao Python, acho que o mesmo vale para ele.
Programadores um pouco experientes não devem ter problemas para entender essa sintaxe de qualquer maneira, é consistente e tem consideravelmente menos armadilhas do que a sintaxe de estilo C de forma mais livre.

Agora, a digitação estática, por outro lado, pode ter algum valor, além de ajudar no desempenho, também pode ajudar na velocidade de desenvolvimento em alguns aspectos. As ferramentas de preenchimento automático adoram ser informadas de que tipo uma função/método de entrega espera e retorna, mas as dicas de tipo sozinhas podem conseguir isso.
No entanto, isso pode ser adicionado ao GDScript, sem necessidade de nenhuma linguagem adicional.

Também a implementação do C# provavelmente não seria tão fácil e uma quantidade considerável de tempo e esforço seria gasto apenas para colocar o mecanismo no estado em que está atualmente, mas agora com C# no topo ou em vez de GDScript.

Como comentário de encerramento, que eu sei que algumas pessoas vão tomar o caminho errado, eu tenho isso a dizer:

Tenho observado que alguns programadores que podem não ter os pés tão sólidos quanto deveriam em nosso ofício têm a tendência de se apegar às coisas que conhecem com toda a força disponível para eles.
Esse fenômeno me parece especialmente difundido nas comunidades de desenvolvedores C#, embora isso possa ser apenas meu viés.
Se alguma das pessoas lendo isso achar que pode se encaixar nessa descrição, só posso recomendar sair dessa caixa familiar e começar a aprender algo novo, não é uma tarefa tão assustadora quanto você pode pensar e, uma vez que você tenha uma empresa compreensão dessa coisa nova, você provavelmente também terá aumentado sua compreensão do que você já sabia. Vale a pena.

Eu adoraria os tipos estáticos, mas se isso acontecesse, como você lidaria com os genéricos? Você simplesmente usaria um tipo dinâmico nessa instância ou gostaria de poder usar restrições? - permitir apenas ints e bools, por exemplo.

Namespaces seriam extremamente bem-vindos, estou surpreso que eles ainda não existam no GDScript.

A opção de usar chaves em vez de dois pontos para métodos também seria adorável, eu sei que eles são desnecessários, mas eu gosto de tê-los lá - é como ler um livro sem pontos finais, é chocante.

As dicas de tipo podem fechar a lacuna impedindo que a conclusão do código funcione totalmente. Uma vez eu trabalhei em um projeto usando Lua, e eles queriam ter isso também. A pesquisa me levou aqui: https://github.com/andremm/typedlua/blob/master/examples/http-digest/http-digest.tl#L48
Isso é o que um parâmetro de função pode se tornar, se você mergulhar muito na dica de tipo xD
Mas acho que deveria haver uma troca. Basta ver como o TypeScript ou o Haxe fazem (ambos permitem misturar variantes e digitados). Além disso, a dica de tipo já existe no Godot. É usado apenas em export() :)

Alguém já começou a experimentar um módulo Mono?
@Zylann

Confira GodotSharp . O estado atual no repositório ainda não pode ser usado. No meu repositório local, consegui implementar coisas suficientes (apenas Vector2 e Matrix32 estão disponíveis como tipos básicos) para traduzir a demonstração 2d/platformer para C#, exceto para instâncias de inimigos e balas que são feitas a partir do GDScript, pois as referências ainda não estão funcionando.
Este é um exemplo da classe player: https://github.com/neikeq/GodotSharp/blob/master/platformer_cs/Player.cs

@Pikl

Reflexão tardia:
É possível usar apenas C++ no Godot? Sinceramente, acho que preferiria aprender C++ e usar isso em vez de GDScript.

Sim, é possível, mas atualmente não é tão fácil e/ou conveniente e você tem que recompilar Godot do zero. Por favor, mostre algum suporte para #3936 se você estiver interessado em C++ ser um cidadão de primeira classe, para que possa ser usado junto com GDScript (ou exclusivamente) sem muito trabalho.

@Zylann Pikl perguntou sobre como alterar a sintaxe do GDScript para se parecer com a do C#, para que fique mais fácil de ler para os desenvolvedores do Unity. Era isso que eu estava comentando. Sim, o C# tem mais recursos, que é a única razão pela qual as palavras-chave e os caracteres que eu removi estavam lá em primeiro lugar. E é por isso que adicioná-los apenas para ter o código GDScript que se parece com o código C# não é apenas desnecessário, mas está errado, já que você estaria usando uma sintaxe que sugere recursos de linguagem que o GDScript não possui.

@Pikl Não é sobre a quantidade de teclas, é sobre a quantidade de escolhas e o significado implícito dos caracteres adicionais. O GDScript simplesmente não possui alguns dos recursos que legitimariam as palavras-chave adicionais. Por exemplo, cada variável, classe e função teria que ser precedida pela palavra-chave "public", já que o modificador de visibilidade padrão do C# não é público (exceto para namespaces - ele muda com base no caso de uso ... outra situação em que a Microsoft decidiu que KISS é apenas uma banda dos anos 80) e já que no GDScript tudo é público.

Então, por que não adicionar C# com todos os seus recursos?
Como Zylann já mencionou, o efeito de adicionar C# ao Godot não é tão simples de prever. Se você ainda não fez, eu agradeceria se você lesse meu longo post neste tópico (https://github.com/godotengine/godot/issues/5081#issuecomment-225226235). Como desenvolvedor, eu sempre teria pedido linguagens mais poderosas. No meu tempo livre, estou olhando para o Kotlin apenas porque o paper-pauper o mencionou no primeiro post.
Mas desde que tive a oportunidade de observar o efeito das linguagens de programação no resultado e no comportamento dos desenvolvedores de jogos, percebi o quão importante é escolher uma linguagem adequada em vez de uma linguagem poderosa.
Como expliquei no post vinculado, tenho certeza de que o C# tem uma influência notável na cultura da comunidade Unity, que vê os programadores como pessoas que

• escrever coisas para a loja de ativos
• escrever tutoriais
• corrigir erros.

Na minha experiência, não há muita cultura de programação de jogabilidade no Unity. Assim que você se depara com qualquer tipo de problema, você começa a procurar padrões ou recursos pré-construídos para resolvê-lo. Na verdade, há um número significativo de pessoas que escolhem seus padrões antes mesmo de saber qualquer coisa sobre um projeto, e esse tipo de inflexibilidade mental afeta os resultados da jogabilidade.

E esse é apenas o meu contra-argumento favorito, houve vários outros bons nos primeiros posts. ;-)

O problema com a JVM é que ela é muito pesada. Alguém deu uma olhada no Avian ? Quão compatível é com o mundo Java?

@neikeq Isso não significa que tenha pior desempenho - AFAIK a JVM tem melhor desempenho que o CLR, e também um Garbage Collector muito mais adequado para desenvolvimento de jogos. Ele também é instalado na maioria dos computadores, independentemente de serem Windows, Mac ou GNU/Linux.

Ele também possui uma grande variedade de bibliotecas FLOSS de alta qualidade e, independentemente do que algumas pessoas dizem, melhor suporte multiplataforma.

Eu diria que entre os dois, a JVM é claramente melhor para o desenvolvimento de jogos (mas eu evitaria tanto ela quanto o CLR da mesma forma).

Avian parece interessante. Eu não tenho experiência com isso, então não posso responder sua pergunta, e temo que sua compatibilidade possa se tornar tão problemática quanto a versão Mono do Unity, o que torna muito estranho usar bibliotecas de terceiros, a menos que você acontecer de encontrar um para uma das versões .NET fornecidas.

Mas ter uma implementação Java leve como uma opção adicional além de GDScript e C++ para casos em que você precisa de tempos de resposta rápidos e pode sacrificar a qualidade do código (como game jams ou prototipagem rápida de novas ideias de back-end) seria bom.

@neikeq Avian foi

@paper-pauper Eu quis dizer pesado em tamanho, supondo que será empacotado com o jogo. Mas como você disse, ele está instalado na maioria dos computadores e, considerando a popularidade de frameworks como libGDX, pode ser a melhor opção.
Meu problema com C++ como alternativa ao GDScript é que sua sintaxe é horrível. Isso é um assassino de produtividade. É bom para o desenvolvimento de motores e módulos, mas eu não escreveria um jogo inteiro com ele. Dito isso, sou a favor do #3936 e de ter algo parecido com o que o Unreal faz, mas não o veria como uma linguagem alternativa de "script".

@kubecz3k Suporta outras linguagens JVM? Ex: Kotlin

@neikeq sim, tanto quanto eu sei, é totalmente compatível com java bytecode, por isso suporta qualquer linguagem pronta para jvm (kotlin, scala, jpython e assim por diante)
Acho que podemos fazer algumas perguntas no avian google group: https://groups.google.com/forum/#!forum/avian
parece ser bem ativo

+1 para não ver C++ como uma linguagem de script alternativa. Como eu disse antes, é bom que Godot tenha uma linguagem otimizada para scripts e outra para desenvolvimento de back-end, em vez de ter uma linguagem meio "meh" em ambas as áreas.

Isso não quer dizer que o suporte a bibliotecas dinâmicas e o desenvolvimento C++ mais rápido não fossem algo que eu adoraria ver.

Mas para não ficar muito entusiasmado com o Avian, aqui está o post do blog do desenvolvedor principal do libGDX no qual ele explica por que o libGDX não está usando o Avian para portas ios. http://www.badlogicgames.com/wordpress/?p=3925 (desça até a parte Avian)
Eu não sou um programador/hacker de jvm (mas o autor é - já que ele também estava trabalhando no RoboVm (mais um jvm que foi comprado e fechado pela Microsoft)) então não sei quanto disso realmente se transformaria no situação em que o Avian é usado apenas como uma linguagem de script (não alimentando o mecanismo principal)

A maioria de vocês provavelmente são programadores com mais experiência do que eu, mas há meus 2 centavos. Um ano atrás, eu torcia para C#. Mas aprendi a sintaxe GDScript muito rapidamente. No final do dia, você ainda precisa aprender a API e essa é provavelmente a coisa mais demorada para aprender. Então, sim, eu não preciso de C#. @Warlaan tirou muitas boas razões contra o C#. Implementar C# também levaria muito tempo. Isso também significaria mais bugs. Sim, temos uma grande comunidade que contribui com a base de código, mas ainda temos apenas um @reduz acho que o tempo necessário para implementar C# deve ser investido em recursos que realmente precisamos. Quantos desenvolvedores Godot estão satisfeitos com o GDScript? Sim, poderia ser mais rápido, mas não tenho outros problemas com isso. Eu preferiria ter uma linguagem de script incrível do que duas não tão boas. Até o Unity está ficando para trás com o antigo Mono.

O que eu gostaria de ter é a digitação estática em GDScript. Não C++ como linguagem de script, não C#. Vamos nos concentrar no GDScript e torná-lo ainda melhor do que é agora.

Como o mecanismo no qual liderei o desenvolvimento por 14 anos foi mencionado no tópico Visual Scripting, pensei em adicionar meus 2 centavos aqui, pois estávamos desenvolvendo um novo mecanismo escrito completamente em nossa própria linguagem semelhante a C#.

Escrevemos nosso próprio compilador (também escrito em nossa própria linguagem depois de inicializá-lo em C++) que compilava para código C++ (quase C puro) que era então alimentado nos compiladores de todas as plataformas que suportamos (XBox/PS/PC/Wii/ etc). Escrevemos nosso próprio coletor de lixo geracional para poder ajustar seu desempenho conforme necessário - fazer isso dessa maneira significava que ele era usado em todo o mecanismo, o que significava que ele foi bem testado e perfilado. E como estávamos compilando para C++, poderíamos facilmente escrever código C++ em funções 'nativas' que poderiam chamar APIs do sistema conforme necessário ou incluir operações específicas de plataforma (SIMD).

Eu realmente não posso imaginar o quão frustrante deve ser para o Unity ter que mesclar um monte de código C++ com o Mono - o que provavelmente explica por que está ficando para trás como @GlaDOSik apontou. Certamente não era algo que qualquer um de nós estava interessado em fazer.

Nosso principal objetivo era unificar as linguagens usadas entre a engine, o editor e as ferramentas, e o código do jogo em uma única linguagem. Anteriormente, o mecanismo e as ferramentas eram inteiramente C++ e uma linguagem de script visual (parecia pelo menos código C) era usada para toda a jogabilidade que era preferida pelos designers de nível, mas incomodava a maioria dos programadores de jogabilidade que estavam escrevendo a maioria do código. Também nos permitiu adaptar a linguagem às coisas que poderíamos precisar para o desenvolvimento da jogabilidade (como suporte à máquina de estado).

_Você não pode agradar a todos, no entanto._ Se eu tivesse que trabalhar ou tentar ajudar alguém a depurar uma bagunça desagradável de "código" baseado em nó de diagrama de espaguete/etc, eu iria querer arrancar meus olhos em retaliação. Eu esperaria que um artista tentando ler código C++ fizesse o mesmo. O que você pode fazer é perder muito tempo discutindo qual é a _melhor_ solução e ainda mais tentando agradar a todos. Em algum momento, você só precisa se concentrar em criar as ferramentas mais produtivas que puder para as pessoas certas - e às vezes isso significa que algumas pessoas podem ter que aprender algo novo.

"Se não é C++, é lento" parece ser o mantra, mas eu diria que a maioria dos jogos _enviados_ são escritos com algo diferente de C++ para código de jogo nos dias de hoje. Na verdade, não vi alguém postar problemas de desempenho especificamente do GDScript, embora certamente estivesse curioso para ouvir deles o que estava lento.

No que diz respeito à minha introdução ao GDScript, foi algo assim:

• OMG Python-like!? Isso é loucura, espaço em branco não deveria importar!
• Hmm, não sou fã do estilo "minúsculas" (veja que você não pode agradar a todos).
• Bem, ok, isso é realmente meio legal e bem pensado.
• Sim, isso está bem integrado com o editor, eu certamente poderia ver ser muito produtivo com isso para código de jogo e alguns plugins de editor!

Parece que muito esforço e tempo foram dedicados ao GDScript, e parece ser a ferramenta certa. Então, eu realmente só queria dizer parabéns para aqueles que trabalharam para fazê-lo!

@Ziflin Oi! prazer em conhecê-lo por aqui, Vicious foi um dos primeiros mecanismos de jogo que usamos profissionalmente (embora tenhamos sido contratados com @punto- para hackear e corrigir problemas com ele mais do que realmente usá-lo).

A linguagem de script visual era realmente um pesadelo, mas o código-fonte estava muito bem feito, limpo e organizado. Depois de trabalhar com o Torque, foi uma felicidade. Aprendi muito trabalhando com isso. A Sony fez um ótimo trabalho vendendo na América Latina porque todo mundo estava usando aqui há uma década.

Acho que o momento mais incrível que me lembro de trabalhar com ele é acidentalmente tropeçar em um pedaço de código que listava os idiomas, e havia um comentário "Português não suportado"

Nós estávamos rindo muito e fazendo piadas, e o produtor do jogo (que estava atrás de nós e não notamos ele) tremia de medo e disse: "Espera o quê? só falta traduzir o jogo para o português , Isso é uma piada, certo?"

Mas usamos apenas chinês para português, tudo funcionou bem e o jogo foi enviado. Fico feliz em saber que vocês ainda estão desenvolvendo!

(citação de @Ziflin ) Na verdade, não vi alguém postar problemas de desempenho especificamente do GDScript, embora certamente estivesse curioso para ouvir deles o que estava lento.

Pessoalmente, cheguei a um gargalo de CPU / Gdscript neste projeto: http://godotdevelopers.org/index.php?topic=15519.0

Eu escrevi um pouco de IA básica e pseudofísica básica da velha escola em GDscript para controlar cada um dos 8 carros.
Eu não chorei em público sobre esse problema de desempenho porque ainda havia alguns pequenos espaços para otimização.
Mas se eu quisesse adicionar mais carros, eu teria sido forçado a largar o Gdscript para C++ ( edit : o que eu gostaria de evitar já que eu realmente não quero ter que compilar de novo e de novo).

Além disso, acho que encontrei o mesmo gargalo de CPU / Gdscript no ano passado com este outro projeto que estava usando GDscript para IA básica para cada bug (animais): http://ludumdare.com/compo/ludum-dare-32/? ação=visualizar&uid=50893
Quanto mais eu adicionava bugs (animais), menor era o desempenho.

Eu poderia compartilhar minha experiência sobre isso, se alguém quiser.

@SuperUserNameMan Por favor, vá em frente, mas acho que este outro ticket que abri #5049 (que fala especificamente sobre o desempenho do GDScript) é mais adequado para isso.

@paper-pauper: não tenho certeza se poderia contribuir com # 5049 (que é mais sobre adicionar JIT, sobre o que eu poderia adicionar um polegar para cima). A experiência que eu poderia compartilhar é mais sobre que tipo de gargalo eu atingi, quais foram os sintomas específicos, como eu tive que contornar, como eu otimizei e quais "benefícios de design do Godot" eu tive que sacrificar.

@SuperUserNameMan Ainda não pensei muito em implementar o JIT por meio de inferência de tipos, mas para isso a VM deve suportar a digitação estática primeiro

Eu estaria mais interessado em ouvir a que tipo de código de IA você está se referindo.
Meu preconceito seria que qualquer código que possa causar problemas de desempenho quando executado em apenas 8 entidades provavelmente não é realmente código de jogo e, como tal, deve ser colocado em uma classe C++ de qualquer maneira, é por isso que estou perguntando.

@reduz Haha, bem, aparentemente é um mundo pequeno! E sim, o script visual meio que ficou fora de controle (na verdade, era apenas para lidar com gatilhos e pequenos pedaços de lógica de eventos). A Vicious na verdade fechou suas portas no início deste ano, mas foi muito divertido trabalhar lá.

@paper-pauper Vou dar uma olhada no outro tópico que você mencionou. Eu realmente não queria que as pessoas começassem a postar problemas de desempenho neste tópico.

Se o GDScript fosse adicionar tipagem estática, _pode_ ser mais fácil ter apenas uma opção para convertê-lo diretamente para C++, o que evitaria sobrecarga extra de transições IL->C++ e manteria o tempo de execução pequeno (sem compilador JIT, etc). Você pode então prototipar em GDScript ou fazer mods com ele, mas também pode convertê-lo automaticamente em C++ para obter velocidade extra quando necessário para compilações finais.

Fazer isso também manteria os IDEs existentes (VC++, etc. e o editor Godot) que as pessoas estavam acostumadas a usar. Na verdade, usamos VC++ para depurar nossa linguagem e nosso compilador gerou diretivas #LINE nos arquivos .cpp para que você pudesse percorrer facilmente o código original e definir pontos de interrupção. Então, em teoria, você seria capaz de prototipar e depurar com GDScript normal no editor, mas durante compilações habilitadas para 'GDScript->C++' você ainda poderia usar seu IDE/Depurador C++ e definir pontos de interrupção/depuração nos arquivos gdscript. Para nós, os arquivos C++ gerados eram temporários e só os analisamos se houvesse um problema de geração de código.

De qualquer forma, apenas um pensamento. O fato de você ter uma boa linguagem de script agora é definitivamente uma vantagem e certamente torna possível fazer coisas como mods criados pelo usuário, prototipagem rápida e adição de novos recursos à linguagem.

Na verdade, eu não entendi que eu deveria postar meus problemas de desempenho neste tópico também. Aqui era mais adequado: https://github.com/SuperUserNameMan/kart-zero/issues/1

@Ziflin Na verdade, o que estávamos discutindo em outras questões é primeiro, adicionar uma API C mínima para escrever módulos/scripts godot usando C simples por meio de uma API mínima que expõe toda a API de reflexão de Godot, isso resolveria um problema comum que temos em relação à distribuição de ligações para diferentes tipos de bibliotecas sem ter que recompilar Godot

Exemplos disso são caras que querem vincular a API steam, ODBC, SQLite, Kinect, etc. Todos os quais requerem módulos de escrita em C++. Fazer isso com uma API C resolve o problema de vincular dinamicamente a C++ (que é muito limitado devido a cada compilador ou versão do compilador ter sua própria ABI e os problemas de incompatibilidade de tamanho de símbolo que podem ocorrer entre as versões Godot). C não tem nenhum desses problemas.

Uma vez que isso funcione, deve ser muito fácil compilar o GDScript em C e carregá-lo em tempo de execução quando o jogo for executado ou exportado.

@reduz Ah legal. Então, basicamente, você está falando sobre ser capaz de escrever um 'plugin' DLL que pode expor o que deseja ao GDScript? (ou entendi errado?)

Uma vez que isso funcione, deve ser muito fácil compilar o GDScript em C e carregá-lo em tempo de execução quando o jogo for executado ou exportado.

Isso funciona para alguém que deseja escrever uma dll que tenha vários novos tipos derivados do nó C++ nela?

É um pouco triste que o novo suporte a 'módulos' C++ pareça ser suficiente para corrigir alguns dos problemas com DLLs.

Por que não usar uma linguagem de script incorporável como lua ou Ruby?

@jersten porque leia os documentos - http://docs.godotengine.org/en/latest/reference/gdscript.html

@Ziflin sim, mas você terá que usar a API C via reflexão (embora você possa pedir ponteiros de função via reflexão para que seja rápido o suficiente ..). O objetivo seria principalmente ter uma maneira fácil de carregar DLLs que evita o problema de ABI, e também uma maneira simples de compilar GDScript para C e carregá-lo como um .so.

Vou colocar meus 2 centavos aqui para o que vale a pena. Eu nunca codifiquei em C#, mas apenas em Java. Embora eu pessoalmente prefira Java por tê-lo usado e gostado, na verdade eu apoio C# em vez de Java. C # é o que os desenvolvedores de jogos do Unity usam, então tê-lo faria Godot parte desse ecossistema de desenvolvimento indie que o Unity criou. Além disso, Java nem é uma boa escolha se você deseja uma linguagem JVM. Existem outras linguagens melhores que compilam para JVM.

Acho que as pessoas estão perdendo o ponto de qualquer maneira. C#/Java != linguagem de script. GDScript é suficiente; fácil de aprender, etc.

Adicionar uma linguagem como Java (construir uma JVM para quais propósitos?! Sintaxe?! Requer uma JVM com uma versão específica para funcionar?!?) .

Se houver um problema com o GDScript, ele deve ser apontado; e, em seguida, tentou ser corrigido.

Discordo. Eu sinto que C# atrairia muitos desenvolvedores de Unity ou desenvolvedores que estão familiarizados com linguagens como C, fornecendo uma boa alternativa ao python como GDScript. A peça final do quebra-cabeça seria um script visual que atrairia artistas que não estão acostumados a codificar. Isso deve abranger praticamente todos.
Além disso, não importa o que você codifique, você ainda precisa aprender as classes e funções do Godot, que seriam as mesmas em qualquer idioma.

Para todas as pessoas que discutem C# porque os desenvolvedores do Unity o conhecem, considere o seguinte: muitos desenvolvedores do Unity não sabem porcaria sobre como programar em C#. O que eles sabem é como usar a API do Unity, que por acaso tem ligações C#. Você os traz para Godot, mesmo que seja C#, eles não saberão o que diabos estão fazendo de qualquer maneira e ficarão tão perdidos quanto fornecer a eles uma linguagem de programação diferente.

Incluir quaisquer idiomas adicionais é apenas mais sobrecarga e mais que o projeto precisa manter que não deveria.

Eu estava pensando muito sobre isso, e minha principal preocupação em suportar algo como C# é que a maioria das pessoas que o usariam seriam usuários do Unity vindo para Godot. Claramente, não incluiríamos C# com os templates oficiais, e duvido muito que eles mesmos construíssem o módulo...
Poderia acabar sendo um grande esforço para suportar uma linguagem que seria usada apenas por alguns.

Acho que há um equívoco:

• Eles veem o GDScript e pensam que o GDScript está no mesmo nível do C#; faltando o ponto fundamental de que C# não é uma linguagem de script.
• Por causa do fato acima, quando alguém diz "Java ou C#"; o que eles realmente estão pedindo é uma reescrita do mecanismo em C#/Java ou adicionar algumas ligações para suportar essas linguagens (lol não).

Já que estou assumindo o último; depurar em C#/Java é um pesadelo em várias plataformas; como ambas as linguagens não são independentes de plataforma (inb4 existem tempos de execução em praticamente todos os sistemas operacionais); ele se transforma em "Escrever uma vez, depurar em todos os lugares" (é por isso que os jogos escritos no Monogame saem primeiro no Windows; e depois no Linux/Mac porque os desenvolvedores precisam depurar para essas plataformas). É por isso que as atualizações da JVM interrompem os aplicativos.

Adicionar suporte para esses idiomas não agrega valor ao mecanismo.

Se o argumento for "moar Unity devs"; então a documentação deve ser feita para ajudar na transição dos desenvolvedores do Unity; que as diferenças de layout, etc.

É por isso que eu disse no final que não importa qual idioma você use, você ainda precisará aprender as classes da API Godot e tudo mais. Não é como se os desenvolvedores do Unity fossem especialistas em insta porque eles conhecem C#. Eu acho que é mais uma "aura de bondade" para Godot se ele suporta C#. As pessoas sentem que sabem mais e, de repente, Godot está mais acessível e não mais tão assustador. A primeira coisa negativa sobre Godot de usuários não Godot é que ele tem uma linguagem de script própria. Como um usuário Godot sabe que BS porque GDScript é uma linguagem divertida e simples, mas para quem está de fora pode parecer pouco convidativa.
Não posso falar do ponto de vista do desenvolvedor, mas talvez seja mais esforço do que vale a pena, a menos que os desenvolvedores obtenham algo da implementação do C#, então vale a pena. No final, é a decisão dos desenvolvedores principais e o que quer que eles decidam, eu vou seguir em frente. Tenho certeza que será uma boa decisão.

Concordo com você sobre o GDScript ser um pouco decepcionante porque é praticamente uma linguagem desconhecida. Mas, depois de ler por que Lua e Python foram removidos e os benefícios de adicionar GDScript, fiquei menos preocupado.

Outra coisa que pode ser relevante: existe outro motor licenciado pelo MIT que já suporta C# e é mais parecido com o Unity, o Atomic Game Engine . Sugiro que todas as pessoas que precisam desesperadamente de algo o mais próximo possível do Unity experimentem.

Vou adicionar meus 2 centavos aqui. Para mim, a grande vantagem do C# é o desempenho, embora ainda seja mais fácil de trabalhar do que o C++. O GDScript, sendo tipado dinamicamente e tudo, é muito rápido de escrever, mas nunca será ultrarrápido de executar (embora possa ser bastante otimizado, o que está planejado). Os módulos C++ são muito rápidos, mas são meio complicados de se trabalhar; C++ não é exatamente uma linguagem amigável, e ter que recompilar o mecanismo para usá-los não é realmente ideal. Para mim, C# é uma espécie de compromisso: muito mais rápido que GDScript, e com o suporte adequado, muito mais fácil de trabalhar do que módulos C++.

Tudo isso dito, não precisa ser C#. Qualquer outra coisa que tenha um efeito semelhante funcionaria bem, no que me diz respeito, seja compilado/JIT GDScript com tipagem estática ou algo como Swift ou algo assim. C# pode ser o melhor para 'fins de marketing'; mesmo sem uma API semelhante, os desenvolvedores de outros mecanismos/frameworks provavelmente ficariam mais à vontade com ela. O GDScript modificado pode ser mais fácil de implementar e provavelmente seria integrado muito melhor.

Eu sei que o tópico é muito longo agora, mas por favor leia todos os posts acima antes de postar algo por conta própria. O argumento de que o C# atrairia pessoas e era muito conveniente para os usuários do Unity não se torna mais válido se for mencionado uma dúzia de vezes mais.

Veja aqui porque imho C# é ótimo para Unity e ruim para Godot, veja aqui porque imho adicionar C# levará a código sujo, não apenas em seus próprios projetos, mas também em tutoriais online, na próxima loja de ativos etc. argumento de que as pessoas tiveram que aprender muitas coisas novas ao mudar de C# para GDScript é inválido.

Deixe-me adicionar um comentário sobre o argumento de que C# traria novas pessoas.
Por que queremos que mais pessoas usem Godot? Eu entendo perfeitamente que projetos de código aberto precisam de uma comunidade que

• adiciona recursos
• corrige bugs
• cria ativos reutilizáveis
• faz sugestões para novos recursos
• encontra bugs ou problemas com o fluxo de trabalho
• escreve tutoriais

mas todos os itens acima precisam de pessoas que entendam e apreciem a ideia central do mecanismo. As pessoas que adicionam recursos desnecessários a uma biblioteca não estão ajudando e houve mais de um projeto que sofreu com esses recursos, às vezes até o ponto em que o projeto foi abandonado ou dividido.
O Unity sofre especialmente com pessoas que escrevem tutoriais mesmo que não entendam realmente o que estão fazendo, o que em grande parte é culpa do C#.

Se as pessoas não estão dispostas ou são capazes de aprender uma linguagem tão simples quanto o GDScript, então é altamente questionável se elas vão dedicar algum tempo para entender completamente a filosofia de design por trás do Godot antes de começarem a contribuir ativamente para a comunidade. ("Contribuindo ativamente" significando qualquer coisa, desde enviar solicitações de pull até postar sua opinião sobre Godot no Facebook.)

Godot não é um motor comercial. A Unity tem interesse em atrair o maior número de pessoas possível, porque todos são clientes em potencial e anunciam o mecanismo. Com certeza seria bom ter uma grande comunidade de usuários que apreciam Godot como ele é, mas não faz sentido sacrificar algumas das qualidades de Godot para atender a uma comunidade maior.

As pessoas do @Warlaan geralmente não querem perder tempo e usarão quaisquer trechos de código que encontrarem ao construir seus projetos, especialmente no início, quando você estiver aprendendo. Para iniciantes, seus pontos são levemente relevantes porque eles acabarão aprendendo qualquer linguagem em que os trechos de código que eles usam estejam escritos. Eu sei disso porque foi assim que aprendi olhando exemplos e não conhecia nenhum GD Script, mas aprendi. A questão não é o que é melhor ou como isso irá impactar ou complicar os tutoriais etc. A questão (para mim) é C# mais do que qualquer outra linguagem fará Godot parte deste ecossistema de desenvolvimento indie do qual Unity faz parte. Isso nem é sobre Unity, é sobre Godot.

EDIT: removeu alguma linguagem desnecessariamente dura ;-)

@trollworkout Sem ofensa, mas você realmente não entendeu meu ponto e tenho a sensação de que você também não pensou no que disse.

1. Sim, as pessoas não querem perder tempo. As especificações completas do GDScript: algumas telas. Livros explicando C#: geralmente pelo menos 500 páginas. Passei alguns dias aprendendo GDScript e tenho certeza de que não tem um único recurso que eu não conheça. Eu tenho trabalhado profissionalmente e no meu tempo livre com C# há anos (usando Window Forms, WPF, XNA e Unity) e ainda encontro trechos de código que usam recursos que não entendi completamente. Pedir C# porque era menos perda de tempo não faz sentido.
2. "os iniciantes acabarão aprendendo qualquer linguagem em que os trechos de código que eles usam estejam escritos" - veja o ponto 1. A noção de que você poderia aprender C# a partir de trechos de código está longe de ser verdade. As coisas que você pode aprender dessa maneira são tão básicas que não levará mais do que alguns dias para "aprender" um idioma diferente. Você mesmo disse que aprendeu GDScript dessa maneira.
3. "C# fará Godot parte deste ecossistema de desenvolvimento indie". E o que isso quer dizer?
   Você poderia usar trechos de código do Unity em C#-Godot? Não.
   Você poderia reutilizar os ativos do Unity em C#-Godot? Não.
   Você poderia ler os tutoriais do Unity e aplicá-los palavra por palavra ao C#-Godot? Não.
   Então, o que é esse "ecossistema de desenvolvimento independente" ao qual você está se referindo?

Como o paper-pauper disse, existem muitos mecanismos e bibliotecas para escolher.
Você quer um sistema de componentes como o do Unity? Veja o Atomic Game Engine.
Você deseja continuar usando C# em um mecanismo, mas deseja abandonar o sistema de componentes? Veja CryEngine / Luberyard.
Você quer continuar usando C#, mas quer abandonar o mecanismo? Veja o MonoGame.

O pensamento de que adicionar C# a Godot estava ajudando iniciantes é falho, já que você mesmo disse que aprendeu scripts em Godot olhando trechos de código. Se é assim que você aprende a trabalhar com um mecanismo, você não gostaria de uma linguagem que informasse implicitamente como o mecanismo funciona, em vez de uma linguagem projetada para milhares de casos de uso diferentes?

Vou adicionar meus 2 centavos aqui. Para mim, a grande vantagem do C# é o desempenho, embora ainda seja mais fácil de trabalhar do que o C++. O GDScript, sendo tipado dinamicamente e tudo, é muito rápido de escrever, mas nunca será ultrarrápido de executar (embora possa ser bastante otimizado, o que está planejado). Os módulos C++ são muito rápidos, mas são meio complicados de se trabalhar; C++ não é exatamente uma linguagem amigável, e ter que recompilar o mecanismo para usá-los não é realmente ideal. Para mim, C# é uma espécie de compromisso: muito mais rápido que GDScript, e com o suporte adequado, muito mais fácil de trabalhar do que módulos C++.

Todos os problemas que você mencionou com C++ que você mencionou são válidos e podem ser corrigidos via #3936. Já discutimos isso muitas vezes, mas apenas para maior clareza, aqui estão os problemas com o GDScript que podemos reconhecer objetivamente:

1. Suporte ruim para bibliotecas de terceiros
2. Desempenho ruim

Ser capaz de escrever partes em C++ corrige facilmente ambos. C# (ou outra linguagem) também corrigiria isso, mas com um tempo de execução adicional, pior desempenho e suporte multiplataforma e muito trabalho adicional necessário (enquanto Godot já está escrito em C++). Portanto, a escolha racional é usar o que já existe (C++) e torná-lo melhor e, claro, corrigir esses problemas com o GDScript.

Eu li rapidamente este tópico e vi que o GDScript para C foi planejado.

Se este for o caminho escolhido, seria bom considerar embutir o compilador tcc C no editor para compilar o C gerado. Ele tem um tempo de compilação muito rápido, é muito pequeno e facilmente embutível. Talvez esta seja a melhor maneira de acelerar as coisas.

TCC é distribuído sob a GNU Lesser General Public License.

(fonte)

Isso o torna provavelmente inadequado para inclusão no Godot. Também não parece ser mantido mais.

@Warlaan Não preciso pensar muito. Neste ponto, todos nós dissemos a mesma coisa cerca de 10 vezes, acho que sabemos muito bem onde todos estamos de pé. Além dos meus 2 centavos e algumas ideias, não tenho muito mais a contribuir, já que não sou um dev e não conheço bem o motor de dentro para fora. Vou deixar aqueles que sabem melhor falar. Eu só queria expressar meu apoio e isso é tudo.
Fora do assunto:
Mas sim em relação ao ponto 2. sobre o qual você fez muito barulho e teve que editar seu comentário. ENTÃO você está dizendo que não pode aprender um idioma com base em exemplos? Eu acho que você ASSUME que as pessoas são incapazes de aprender a menos que leiam manuais de 500 páginas que C# é conhecido por você dizer o motivo 1 para rejeitá-lo. Bem, eu sou a prova viva de que você está errado. Como você acha que eu aprendi GDScript? Com a API e exemplos de demonstração e fazendo perguntas. Lembre-se de que eu tinha 0 conhecimento de Python antes de começar, então tudo sobre isso é muito estranho. Como uma nota lateral, eu me pergunto quantas pessoas compram manuais da libGDX versus quantas pessoas realmente pesquisam no Google "como fazer X na libGDX", provavelmente por que a loja de ativos é tão foda no Unity. E com isso estou pronto por enquanto porque não tenho mais nada a dizer.

( @Calinou : Bellard permitiu que um fork do TCC se tornasse BSD ou MIT. Mas da última vez que verifiquei, o desenvolvedor do fork não liberou o código-fonte. Então, talvez Bellard aceite permitir que a comunidade Godot relicencie o TCC também?)

Não tenho certeza se o TCC é tão bom quanto o GCC ou o Clang como compilador - seu tamanho equivale a suporte para muitas arquiteturas e para geração de código bastante otimizada (melhor desempenho).

E o Godot opcionalmente dependendo do GCC ou Clang para compilar C? Eles são instalados nas máquinas da maioria das pessoas que construiriam os jogos de qualquer maneira (portanto, o tamanho não é realmente uma preocupação), e é a forma como outras linguagens que compilam para C (como Chicken ) fazem isso. Eles também suportam C++, caso seja necessário.

Se forem feitas dependências opcionais, aqueles que não têm GCC ou Clang instalados (o que é estranho para um desenvolvedor que deveria construir um jogo para distribuição, mas de qualquer maneira) pode simplesmente usar o interpretador GDScript como está agora.

Sugeri usar o TCC como JIT para GDScripts. Portanto, o recurso mais importante foi a velocidade de compilação. E acho que os resultados já podem ser muito mais rápidos do que a solução atual.

A maioria das pessoas quer C/C++ por desempenho e Lua/Javascript por ser mais fácil e rápido de escrever, então por que não ter o melhor dos dois mundos?

Nim - http://nim-lang.org/

Eficiente como C, expressivo como Python e flexível como Lisp

Prós:

• Compila em C, C++, Obj-C ou JS ( http://nim-lang.org/docs/backends.html )
• (Python / Pascal) como ( https://learnxinyminutes.com/docs/nim/ )
• GC ou Manual ( http://nim-lang.org/docs/gc.html )
• Pode ser usado em outro lugar que não seja Godot
• Multiplataforma (windows, linux, osx, mobile)
• Ajuda a converter o código C em Nim
• Suporta Clibs
• Compilador ajustável
• Licenciado pelo MIT
• Código aberto
• Tipo seguro

Contras:

• Requer um compilador C/C++ no computador do desenvolvedor -> gcc , vcc , llvm_gcc , icc , clang ou ucc _(não é realmente um golpe, na minha opinião)_
• Pequena comunidade
• Ainda não é 1.0

A lista de TODO do Nim é pequena, está perto de 1.0:
https://github.com/nim-lang/Nim/blob/devel/todo.txt

como paper-pauper disse (sobre ter um compilador no computador do desenvolvedor):

Eles são instalados nas máquinas da maioria das pessoas que construiriam os jogos de qualquer maneira
https://github.com/godotengine/godot/issues/5081#issuecomment -227706106

https://hookrace.net/blog/what-is-special-about-nim/
https://hookrace.net/blog/what-makes-nim-practical/

https://github.com/nim-lang/Nim/wiki/Nim-for-C-programmers
https://github.com/nim-lang/Nim/wiki/Nim-for-Python-Programmers

Não é minha solução favorita, mas se você deve seguir esse caminho, sugiro fortemente que você use Haxe ( haxe.org ) em vez de Nim.

Não posso comentar sobre a licença do Haxe (o próprio compilador está usando "GPLv2+", a biblioteca padrão está usando o MIT), mas todos os outros fatores o tornam uma escolha superior imho.
É uma plataforma testada (atualmente na versão 3.2.1) ao contrário do Nim ainda não ser a versão 1.0, mas o que para mim é muito mais importante a sintaxe é muito mais próxima de outras linguagens conhecidas. Lendo os exemplos do Nim me parece que os desenvolvedores por trás dessa linguagem tentaram encontrar soluções inusitadas e/ou feias.

Mas, como mencionei, não é minha solução favorita e aqui está o porquê:
Linguagens intermediárias como Nim ou Haxe têm muitas "dependências semânticas". Não quero dizer dependências de bibliotecas ou executáveis ​​que precisam estar presentes, quero dizer que se relacionam com outras linguagens. Agora, como eu disse antes, as línguas não são mais ferramentas, são culturas. E mesmo que você os veja apenas como ferramentas, eles têm diferentes domínios principais para os quais foram criados. Por exemplo, faz todo o sentido que o comando "echo" imprima texto na saída padrão quando inserido na entrada padrão. É apenas importante usar o mesmo comando em um script em lote. Seguindo essa lógica é compreensível que o PHP use o mesmo comando. Usá-lo em uma linguagem de propósito geral como Nim não faz sentido, já que basicamente todas as outras linguagens de propósito geral têm métodos chamados algo com "escrever" ou "imprimir" no nome.
Não tenho ideia de por que o Nim ainda usaria "echo" como o nome desse comando, mas esse é o tipo de coisa que você pode observar muito com o Haxe e que eu esperaria do Nim no futuro, se não já na primeira versão . Por exemplo, a biblioteca padrão do Haxe contém um método substr(int, int) e um método substring(int, int). Um dos dois retorna a substring do primeiro para o segundo índice, o outro retorna a substring do primeiro índice com o comprimento do segundo argumento. A razão pela qual ambos existem é que, como a linguagem pode ser usada para substituir linguagens de diferentes tipos, ela tem usuários que vêm de diferentes plataformas, e a menos que haja alguém com uma mão muito forte decidindo o que entra nessa biblioteca de código aberto e o que não você acabará facilmente com essa mistura de estilos de codificação.

É muito importante escolher as ferramentas certas para o trabalho certo. Linguagens como Haxe (ou C# para esse assunto) tentam fornecer uma linguagem que serve para todos, então na maioria das vezes você acaba usando "apenas uma ferramenta" que infelizmente se parece com isso .

Eu gostaria de adicionar meus 2 centavos depois de trabalhar com Godot por um tempo.
O que eu gostaria de ver (e também tenho observado, com... sucesso limitado) é C++ como uma linguagem de primeira classe em Godot.
Escrevendo a lógica de computação pesada (resolução de colisões, física, transformações e IA) em C++ e scripting dos nós usando GDScript (triggers, condições, animações e sons).

GDScript É muito fácil de aprender, colocando Godot um pouco mais perto do Gamemaker do que do Unity nesse aspecto.
Mas depois de escrever 3 pequenos jogos e brincar com um monte de demos, devo dizer que o GDScript está faltando para qualquer coisa além de jogos muito básicos.

Os arquivos de código ficam muito longos e o editor de código não possui muitos recursos úteis encontrados em outros IDEs, como: redução de escopos, regiões, salto para o início/fim do escopo atual.

O GDScript também carece de muitos recursos básicos de linguagens procedurais, como: apropriado _ para _ loops, apropriado _ do... while _ loops (suporta _ while _ loops), _ switch...case _, _ operador ternário _ , _ enumerações _.
_ Não há consciência de relacionamento classe-cena _ então se não for pré-construído é uma classe "externa" e tem que ser pré-carregada.

Além disso, dada a natureza do GDScript, não há referências de função e nenhum modelo.
Não é nada espetacular, mas é muito chato.

Olho776; O GDscript só é inutilizável para mais do que jogos simples se você decidir ignorar os outros recursos (como usar nós e retornos de chamada sempre que possível) em vez de se ater exclusivamente a funções como _get_overlapping_bodies()_

A razão é que os retornos de chamada e o uso de nós são muito mais rápidos do que tentar fazer tudo com um script grande e muito poucos nós. A árvore fica maior, mas não é um problema com o sistema de instância de cena de Godot.

Por exemplo, objetos que precisam de uma taxa constante de rotação podem usar apenas uma animação para isso, em vez de definir a rotação manualmente usando GDscript, coisas que dependem de tempo podem usar nós de temporizador e assim por diante. Acho que uma maneira imediata (e direta) de permitir jogos mais rápidos seria mais tipos de nós para escolher (cada um com seus próprios retornos de chamada e conexões).

Arquivos de código ficam muito longos

Você quer dizer scripts como este? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd
Você acha que C# pode impedir que isso aconteça? Pessoalmente não. Na verdade, fica mais fácil refatorar e detectar erros mais cedo nesses scripts longos por causa das ferramentas (sim, quando as pessoas querem dizer C#, geralmente significam VS implicitamente) e da digitação estática, embora os erros de caminho de nó sejam indetectáveis ​​até que o jogo seja executado. Mas, além disso, um bom design e uso de nós podem simplificar bastante os scripts.

o editor de código não possui muitos recursos úteis encontrados em outros IDEs, como: redução de escopos, regiões, salto para o início/fim do escopo atual.

Estes podem ser adicionados no futuro se você pedir, embora você possa usar um editor externo sem problemas (https://atom.io/packages/lang-gdscript), Godot ainda tem serviços de auto-completar.

Se você realmente faz um jogo ENORME, é provável que queira estender Godot usando C++.
Na verdade, acho isso um pouco assustador atualmente por causa do processo de reconstrução do mecanismo, mas há razões para isso .

Não há consciência da relação classe-cena

O que você quer dizer? Você sabe que pode colocar um roteiro na raiz de uma cena, certo? Além disso, os editores de C# não podem adivinhar o que está na cena em que são usados, enquanto o GDScript pode.

Além disso, dada a natureza do GDScript, não há referências de função e nenhum modelo.

Há funcref e signal se você procurar algo semelhante a lambdas e eventos, e modelagem não é uma coisa porque a linguagem é dinâmica. As linguagens dinâmicas geralmente preferem usar a tipagem de pato em vez de interfaces e genéricos. Além disso, a composição sobre a herança funciona muito bem se você quiser coisas reutilizáveis.

O GDScript também carece de muitos recursos básicos de linguagens procedurais

Eu concordo um pouco. Alguns deles foram solicitados, mas não me lembro dos problemas, você terá que pesquisar. Por exemplo, eu gostaria de ver um for que pode iterar em algo além de intervalos de inteiros e contêineres (float?), então eu uso while . Isso é realmente um pouco chato, mas nada muito sério.

Você quer dizer scripts como este? https://github.com/Algorithmus/CastlevaniaClone/blob/master/game/players/player.gd

Devo dizer que, mesmo que o arquivo seja longo, já vi muito pior e ainda é bastante legível, apesar do código ser bastante procedural. Agora eu finalmente entendi porque uma sintaxe simples é melhor para GDScript: é a melhor para lógica de jogo média, que é principalmente if se chamadas de função.

Eu gostaria de ver alguém argumentar que o mesmo arquivo escrito em C# é mais fácil de ler ou escrever, ou oferece alguma vantagem prática além do desempenho (que é pior que o de C++). Eu acho que C# seria um exagero para esse tipo de script, que é mais complicado do que o script usado em alguns jogos 2D profissionais.

Eu concordo um pouco. Alguns deles foram solicitados, mas não me lembro dos problemas, você terá que pesquisar. Por exemplo, eu gostaria de ver um for que pode iterar em algo diferente de intervalos de inteiros e contêineres (float?), então eu uso while. Isso é realmente um pouco chato, mas nada muito sério.

Você poderia aprofundar um pouco mais a parte for e alguns exemplos do que você está se referindo no pseudo-GDScript?

@paper-pauper as coisas que faltam no GDScript não estão relacionadas ao C#, mas por exemplo for i in range(-PI, PI) não funciona no GDScript, assim como for i=0, i < size and stuff, ++i . Eu também gostaria de escrever ternário em vez de ter que escrever um se de três linhas. Mas como eu disse, já existem problemas no rastreador para isso e isso não vai me impedir de usar GDScript :p

Mas mesmo que todos os seus scripts tenham 200 linhas no máximo e sejam relativamente bem projetados, se você tiver milhares deles em seu jogo, você terá problemas para manter e refatorar essa base de código: e isso não é muito por causa da linguagem, mas por causa das ferramentas : Uma grande parte da popularidade do C# é porque o Visual Studio é um ótimo IDE para ele. Tenho certeza de que se Godot integrar ferramentas adequadas (definição goto, renomeação confiável de classe/função/membro, encontrar todas as referências, etc.), trabalhar em grandes bases de código GDScript será muito mais fácil. De um modo mais geral, isso é o que eu gostaria de ver no Godot, como ele pode escalar bem para GRANDES jogos, porque até agora não vi nenhum (incluindo meus próprios projetos).

for i in range(-PI, PI)

Isso faz minha cabeça girar em seu eixo até chegar a uma divisão por zero e começar a destruir a entropia. Espero que nenhuma linguagem implemente uma declaração tão imprevisível. O que isso faz? Iterar sobre inteiros entre -PI e PI (ou seja -3, -2, ..., 2, 3), ou entre múltiplos de PI (ou seja -PI e 0), ou iterar sobre floats que algum passo padrão de voodoo como 0.176 ou ln(2) que algum programador de linguagem achou mais apropriado?

@akien-mga oops desculpe. Eu deveria ter adicionado um argumento de passo de fato xD, mas ainda não funciona. Aqui está o problema que fiz para ele https://github.com/godotengine/godot/issues/4164

Concordo que Godot sente falta de ferramentas. O principal problema é a natureza do tipo pato do GDScript, que torna mais difícil saber o que é o quê e, portanto, dificulta a execução de algumas ações como "encontrar referências" ou "ir para definição".

Está planejado adicionar dicas de tipo ao GDScript, mas como isso será opcional, não tenho certeza de quanto pode ser melhorado. Certamente fará muito para completar o código e pode facilitar o trabalho em ferramentas melhores.

@vnen Um modo EMACS para GDScript em (M)ELPA já seria um passo na direção certa, no meu livro :)

Ah, sim, quase me esqueci desses dois problemas que, engraçado o suficiente, na verdade me atrasaram na prática:

• Os argumentos não fazem parte da assinatura de uma função. Isso significa que você não pode substituir funções.
  Na prática, ter function doFoo(a,b,c,d) e function doFoo(a,b) na mesma classe resultará em falha na compilação. Acabei renomeando-os para doFoo4(a,b,c,d) e doFoo2(a,b) e refatorando vários arquivos de script.
• Como não há suporte para enumerações, todos os sinalizadores e códigos de retorno são, por necessidade, ints, então você precisa adivinhá-los e muitos ainda não estão documentados no momento.

PS: Obviamente as funções não foram literalmente nomeadas doFoo . ;)

EDIT: @Ace-Dragon: Outros mecanismos me ensinaram que nós/componentes/etc. pode e vai mudar, quebrando o jogo no processo. É por isso que, além dos retornos de chamada de gatilho básicos (colisões, valores, temporizadores), prefiro evitar confiar muito neles.
Eu também não sou um grande fã do paradigma de slot de sinal, então eu tendo a evitá-lo, se possível. Então, novamente, eu também prefiro threads a corrotinas, me chame de ludita :)

@Zylann : ~1200 LOC?... pffft Não, estou falando sobre o negócio real... 20k+ LOC por arquivo. Um desenvolvedor de RPG que usa Unity, que deve permanecer sem nome (não, eu não trabalho para eles), rotineiramente tem classes com 25k+ loc. Então, novamente, eles tornam todas as suas funções estáticas e usam C# como se fosse C. :fearful:

Desculpem o off-topic.

@eye776 Não consigo pensar em nenhuma linguagem dinâmica que permita a substituição (pode ser falsificada com argumentos padrão em alguns casos), mas seria uma boa ideia tê-la no GDScript.

E as mudanças de quebra de jogo no mecanismo podem ser facilmente detectadas e revertidas em um programa livre como Godot, então elas não devem ser uma preocupação.

@eye776 Eu também nunca vi linguagens dinâmicas com substituição de função. O GDScript tem parâmetros padrão, para que possam ser usados.

Além disso, quem é o louco fazendo 20K+ LOC em um único arquivo? O problema aqui não está na ferramenta... Em toda a fonte Godot não há um único arquivo que eu possa encontrar com 10K LOC.

O que eu concordo é dar um pouco mais de amor ao C++. Mas para os usos que você citou anteriormente, concordo apenas com a IA. E também geração processual, para citar mais uma. Agora, se você está refazendo a física do motor, renderizando, etc., então eu digo que você não está mais usando Godot, você acabou de fazer um fork. Se você não pode confiar nos tipos internos, para que você precisa do mecanismo?

Claro, GDScript não é perfeito (nenhuma linguagem é). Também não é esculpida em pedra. Enumerações, switch/case e operações ternárias são algumas adições prováveis ​​no futuro (já existem questões em aberto sobre isso). Só porque não tem algo agora, não significa que nunca terá.

Finalmente, as "dúvidas" não ajudam muito. O que precisamos são benchmarks e casos de uso. Já existem jogos bastante complexos escritos em GDScript, então não vejo o que realmente está faltando.

@vnen apenas por diversão: godot/drivers/gles2/rasterizer_gles2.cpp é 11K LOC :p (é o maior que encontrei, mas é uma rara exceção).

@vnen

Se você não pode confiar nos tipos internos, para que você precisa do mecanismo?
Bem, como um contexto multiplataforma de qualidade para iniciantes. Mas isso não significa que escreverei minhas próprias classes de sprite ou model.

Godot me queimou uma vez em março (v 2.0.1). Eu estava brincando com uma câmera e personagem de terceira pessoa e tentei usar a própria física de Godot para movimento (arraste e forças) e consegui que funcionasse.
A próxima atualização da versão secundária (v 2.0.2) basicamente quebrou a velocidade do personagem (2-3x mais rápido) para os mesmos valores exatos.
Descobri que era melhor apenas mantê-lo cinemático e fazer minha própria "física".

Além disso, não relacionado a Godot, eu me queimei muitas vezes confiando em coisas automatizadas como os storyboards do XCode.
Eu meio que parei de ser cortejado pelo brilhante e rezando para que qualquer código gerado automaticamente pelo IDE nas minhas costas não mexesse com o meu.

De qualquer forma, eu realmente sinto muito por descarrilar o tópico.

@eye776 Você verificou a diferença de confirmação de 2.0.1 para 2.0.2 para ver o que quebrou seu jogo? Poderia ter sido um bug e reportá-lo poderia beneficiar toda a comunidade.

Mono ou CoreCLR? E porque?

Mono:

• MIT licenciado
• estábulo
• possibilidade de ser abandonado
• boa documentação

CoreCLR:

• MIT licenciado
• ainda não é 1.0 (atualmente é RC2)
• pequena
• documentação ruim

Estamos usando o Mono porque ele é implantado em dispositivos móveis e na web. acho que aqui é
chance zero de ser abandonado porque é muito mais portátil. Meu palpite
é que ambas as bases de código acabarão por se fundir.

Em quinta-feira, 4 de agosto de 2016 às 13h45, Hubert Jarosz [email protected]
escreveu:

Mono ou CoreCLR? E porque?

Mono:

• MIT licenciado
• estábulo
• possibilidade de ser abandonado
• boa documentação

CoreCLR:

• MIT licenciado
• ainda não é 1.0 (atualmente é RC2)
• pequena
• documentação ruim

—
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/5081#issuecomment -237611905,
ou silenciar o thread
https://github.com/notifications/unsubscribe-auth/AF-Z2zRjC8u_owFzCCyeqIhF8W5XqCtLks5qchchgaJpZM4Ivn7R
.

Além do que @reduz mencionou acima, a API é encapsulada, então não é muito difícil mudar para CoreCLR posteriormente, se necessário.

CoreCLR: ainda não é 1.0 (atualmente é RC2)

Atingiu 1,0 estável em 14 de junho.

Mono: possibilidade de ser abandonado

Com base no que?

Mono: boa documentação

ahahah

Com base no que?

Por que a Microsoft desenvolveria três pilhas de .NET? Não é bom em termos de recursos. (.NET Framework, Mono, .NET Core)

ahahah

Eu verifiquei os dois documentos sobre a interoperabilidade C++/C# (o que precisamos para godot) e está tudo bem documentado em Mono. No coreCLR eu tive que cavar um pouco do código deles e pedir ajuda aos desenvolvedores para fazer meu aplicativo funcionar.

O guia de referência tem muitas funções não documentadas, links quebrados...

Na teoria estou sendo tendencioso aqui... Mas espero que meus argumentos sejam objetivos...

• Não estou vendo nenhum declínio no desenvolvimento do Mono: https://github.com/mono/mono/graphs/contributors
• O desenvolvimento para Mono no Windows nunca foi tão forte quanto hoje (meio à prova (sem vincular toneladas de commits) https://github.com/mono/mono/pull/3231 Miguel dizendo "já que agora temos mantenedores reais") Fazendo ponto anterior ainda mais claro
• A API de incorporação no Mono é testada em batalha (não apenas o Unity, existem muitos outros usuários privados)
• Mono TODAY roda em PS4, Android, Windows, iOS BITCODE (anos de trabalho foram para isso), AppleTV e muitas outras plataformas...

Então, imho, se você quiser entregar isso em um futuro próximo (menos de 3 anos) e na maioria das plataformas de jogos... Vá com o Mono.

Olá,

Alguns comentários:

• Além das plataformas listadas por David Karlas, também estamos adicionando suporte nativo a WebAssembly, XboxOne, UWP e Win64.
• A amostra que está sendo compartilhada também pode ser feita com métodos virtuais (expedição mais rápida) ou com eventos C#.
• O C# historicamente esteve na frente de muitas inovações de linguagem, extraindo boas ideias de qualquer lugar. Ele popularizou e trouxe para o mercado de massa muitas idéias de pesquisa de linguagem e que agora tomamos como garantidas, coisas como iteradores, genéricos não apagados, lambdas, programação assíncrona, propriedades, invocação de plataforma, mas é uma das linguagens que são mais ativamente desenvolvido em público . Por exemplo, a próxima versão está adicionando uma série de novos recursos, incluindo minha correspondência de padrões favorita.
• Em geral, o Unity não mostra o C# moderno, pois está usando um tempo de execução mais antigo. Espero que isso mude em breve. Dito isso, o Mono atual suporta todos os novos recursos do C#, entre aqueles de programação "assíncrona" que é ideal para código de jogo, pois você pode escrevê-lo linearmente, e o compilador automaticamente reescreve seu código como uma máquina de estado - como corrotinas ou o avançado versão de "yield" como usado no Unity.
• Contextos de sincronização significa que você pode escrever código assíncrono que é executado em um contexto específico. Por exemplo, você pode ter execução vinculada ao jogo, execução vinculada à E/S ou execução vinculada ao thread principal vs em segundo plano, tudo isso faz parte do sistema.
• Durante a implantação, você tem a opção de compilação JIT ou compilação estática (AOT) com ou sem LLVM, para que você seja o mais rápido possível em C++, modulo o fato de que C# faz verificações de limites de matrizes (ou seja, se você usar buffers, você recupera seu desempenho, em detrimento da segurança)
• Nos últimos anos, devido ao forte foco do Mono em dispositivos móveis, o GC do Mono foi ajustado não para servidores, mas para cargas de trabalho interativas. Nosso novo GC é geracional com pequenos viveiros que podem ser coletados muito rapidamente e não exigem a varredura de toda a pilha.

Quanto ao motivo pelo qual a Microsoft está desenvolvendo vários CLRs (temos três: CoreCLR para cargas de trabalho JIT; família CoreRT, para compilação estática em UWP; Mono para cargas de trabalho móveis), é porque todos servem para propósitos ligeiramente diferentes. Os internos estão convergindo sempre que possível, por exemplo, o Mono agora substituiu cerca de 60% do código principal por um código que é compartilhado diretamente com o resto do .NET. É apenas uma questão de descobrir qual carga de trabalho é mais adequada para você.

Você pode começar com uma VM hoje e alternar para outra no futuro. Atualmente o Mono tem uma superfície de API maior, funciona em dispositivos móveis, foi otimizado para cargas de trabalho interativas e suporta mais arquiteturas (como ARM64).

A boa notícia é que trocar uma VM por outra, ou dar suporte a ambas, custa alguns dias de trabalho, então você não está se prendendo a uma implementação específica.

@migueldeicaza Bem vindo! Incrível que você decidiu participar da nossa discussão e que está interessado em Godot :+1: Espero que você fique conosco por um tempo :)

Obrigado pelo belo detalhamento @migueldeicaza! Tenho duas perguntas rápidas para você ou outros desenvolvedores do Mono.

1) Qual é a configuração atual para depurar o Mono incorporado no Windows com o Visual Studio? O Unity tem seu plugin, mas não consegui encontrar nada além de plugins que se conectam a máquinas Linux/OSX.

2) Qual é a maneira recomendada de lidar com a recompilação em tempo de execução (compilar, descarregar e recarregar, digamos, um assembly para jogabilidade ou plugins de ferramentas no editor)? C# (muito) infelizmente não expõe um método Assembly.Unload() e lidar com AppDomains e problemas de AppDomain cruzados parece ser muito irritante para essa situação.

Para referência, não apenas o Unity usa Mono - https://github.com/xamarin/urho (ligações C#/Mono para mecanismo Urho3D) - que está na licença MIT, para que possamos pesquisar facilmente sua solução.

Meus dois centavos:

C# é muito superior para programação de jogos do que outras linguagens de nível semelhante, pois oferece suporte a tipos de valor personalizados. Este é um recurso extremamente importante para o desempenho, que Java (e JVM em geral) literalmente _no_ alternativa a ele.

Você obtém:

• Tipos matemáticos alocados em pilha, que suportam operações matemáticas e objetos temporários sem nenhuma alocação de heap.
• Coleções contínuas otimizadas e amigáveis ​​ao cache.
• Genéricos usando tipos de valor (incluindo tipos primitivos)

Além disso, o C# tem outros recursos que facilitam sua vida. Não vejo mérito em usar Java no lugar de C# quando C# simplesmente supera Java em praticamente tudo o que importa na programação de _game_.

Olá a todos,
eu não li tudo acima (simplesmente demais :))
mas eu tive alguns feriados, então fiz um módulo protótipo para godot que atua como msDotNetHost, então posso fornecer algumas descobertas que passei, talvez elas sejam úteis. infelizmente minhas férias terminaram e eu tenho que codificar por dinheiro novamente :), mas é/foi divertido :)

estado atual é:
o) o módulo estende a classe Node para expor os eventos do nó ao netCode
(init, tree_entered, ready, process, fixedprocess....)),
o) "módulo de host/wrapper de rede" concluído (usando o mecanismo de host dotNet da Microsoft)
está encapsulado em uma biblioteca dinâmica, então uma mudança para Mono deve ser fácil mais tarde
o) os métodos dotNet são vinculados e chamados (init, tree_entered, ready, process, fixedprocess....)
o) a classe do nó é encapsulada e vinculada ao netAssembly (código escrito manual para prototipagem)
o) chamadas para godot (de netCode) estão funcionando através de um mecanismo de ligação auto-escrito
(de dll para godot-exe ) para que o exe não precise exportar funções.
o) devido ao uso do msDotNet, está vinculado ao Windows em um futuro próximo.

meu roteiro para incluir .Net seria:

1. módulo para Godot usando o mecanismo de hospedagem microsoft .Net (concluído)
2. embrulhar godotClasses
   (meu estado atual: escrevendo um gerador de wrapper, que analisa o código Godot C++,
   análise é feita, geração em andamento)
3. tire o projeto do estado de protótipo (complete as arestas, teste...)
4. escreva o mecanismo de hospedagem Mono, para se livrar dos títulos do Windows
5. de alguma forma, habilite o Visual Studio para depurar o mono, para se livrar do xamarin/monodev (como unity vs-plugin )
6. divirta-se com centenas de novos desenvolvedores Godot .net :)

algumas perguntas:

1. gostaria de saber se eu poderia reutilizar o mecanismo de ligação usado para gdscript. mas eu não tenho tempo para avaliar tudo isso, há algum bom tutorial ou algumas dicas de highlvl para mim?

2.
atualmente eu gero um wrapper que envolve todos os métodos godot em funções para que eles possam ser chamados facilmente via limite de dll e limite de c++/netCode. (mecanismo de ligação auto-escrito para netCode)
eu não quero alterar o código godot (exceto o código do meu módulo) para permanecer compatível.
também estático, não estático, virtual não virtual me fez chorar, por isso escolhi esse caminho.
alguma solução melhor para isso?

alguns pensamentos adicionais:

Microsoft .Net vs Mono:

eu acho que não importa se você usa mono ou msDotNet, porque na maioria dos casos o código dotNet é executado inalterado em ambos. O único esforço para suportar ambos é escrever um "host" para cada um deles (é a menor parte de um "GodotDotNet"). Eu escolhi msDotNet para prototipagem.
bem, mono suporta muitas plataformas msDotNet apenas janelas, então por que suportar/usar msDotNet?
A resposta: produtividade, depuração

msDotNet:
Especialmente ao escrever/prototipar o DotNetModule, eu preciso/quero compilar e depurar FAST, significa que seu depurador deve pular para o netCode do c++ e vice-versa.
eu escolho VisualStudio, porque pode depurar ambos. MAS apenas se você usar msDotNet.
Fazendo isso você muda um pedaço do netCode, clica em executar e em 1sek! está compilado e rodando!!! incluindo a possibilidade de depurar em godot. (se você não mudou algo no Godot, então você tem que esperar os 30 segundos a 1 minuto... caramba, você é lento! :))

Mono:
Mono deve ser o alvo final, não há discussão sobre isso (independência de plataforma), mas:
se alguém usa mono, você tem um grande problema quando se trata de depuração: o mono tem seu próprio mecanismo de depuração!
para mim, é um grande sucesso para a produtividade, porque, a menos que você escreva um plug-in monodebug para o visualstudio (a unidade fez isso), você não pode depurar o código de rede hospedado mono no visual studio e depurar no código c++ (existem soluções de hack, mas ...).
Tentei configurar uma solução baseada em Mono, mas acabei usando ambos em paralelo, VisualStudio (para c++) e xamarin/monodev (netcode).

Conclusão:
estado do protótipo: msDotNet
lateron: mono, para usuários não interessados ​​em depurar em godot/c++ e independência de plataforma
depois disso: crie um vs-plugin para depurar mono

c# vs java:
a resposta é clara c#! java é para scritpkids! (oh, o que o codificador c++ pensa sobre c# devs :))
Não, isso foi uma piada :)
eu não entendo a discussão... quando o sistema .net é implementado, você pode usar todos os idiomas que suportam dotNet, incluindo os dois idiomas e mais.
este não é o caso se o sistema java for suportado ...

@Ziflin :
questão 1:
fiz essa pesquisa também ... apenas monoRemotedebugger é a (não) solução atm :(
minha recomendação é, como dito acima: use microsofts dotNet hosting para prototipagem
então, em algum ponto posterior, mude para mono.
alternativo:
inicie o xamarin em seu modo hackeado, deixe-o ouvir localhost, defina os pontos de interrupção e inicie seu projeto no vs. já testei, funciona, mas ...
para mim não tem solução! eu quero um "hit run and debug in 1 second" - mecanismo e isso com 1 clique!
eu não tenho muito tempo no meu tempo livre, então a produtividade é meu principal objetivo.

Questão 2:
Ainda não conheço o mono tão bem, mas acho que você precisa fazer isso em c++, implementar hospedagem mono, gerenciá-lo "de fora" em c++.

@CharlesWoodhill C#-bindings oficiais já são WIP e podem ser vistos aqui https://github.com/neikeq/GodotSharp/

legal tnx, então eu sei como vou passar alguns dos meus próximos feriados ;)

Oi, acabei de encontrar godotSharp, mas isso caiu.

isso caiu.

A versão oficial que ouvi no IRC era algo como:

@neikeq não gosta de enviar código inacabado, então ele trabalha em seu branch local

Bem, bom saber, eu estava prestes a fazer meu próprio módulo, mas acho que também poderia para Godot 2.2 ou 3.0

Não haverá lançamento 2.2, os desenvolvedores Godot moveram todos os recursos 2.2 para 3.0.

Esta é a primeira vez que comento. Eu vim do Unity e a mudança para o GDscript foi um sonho. Eu aprendi o idioma em menos de um dia. Eu amo o quão bem a linguagem é implementada no mecanismo e minha produtividade aumentou consideravelmente.

Minha principal preocupação é que, com suporte adicional a C#, o GDscript será deixado para trás ou verá menos desenvolvimento após uma enxurrada de desenvolvedores do Unity. C # é uma boa linguagem, mas não é minha favorita

Também estou preocupado em ver Godot tentando ser mais como outro motor em vez de ficar sozinho. Unity é uma história de sucesso fabulosa, mas não é a melhor engine que já usei. Está inchado e cheio de bugs. Uma vez que apagou todo o meu projeto sem confirmação. Lidar com bugs e coisas que não funcionavam como deveriam era uma luta constante. Não posso contar quantas vezes tive que reconstruir completamente uma cena em que estava trabalhando porque as coisas não estavam funcionando direito. Certa vez, copiei e colei todo o conteúdo de uma cena de buggy antiga em uma nova cena para que funcionasse de repente, apesar de ambas as cenas serem idênticas. Perdi semanas caçando bugs físicos que apareciam e desapareciam magicamente.

Eu realmente gosto que Godot seja enxuto e simples de entender. Trabalhar com Godot foi como usar um instrumento musical bem afinado. Depois de quase um ano trabalhando nele, eu sei fazer qualquer coisa que eu precise fazer, mesmo que eu não tenha feito isso antes. Só espero que o fluxo de usuários do Unity não direcione a direção do mecanismo mais para o Unity. Se eu quisesse o Unity, estaria usando o Unity.

@zaywolfe Sua preocupação foi expressa algumas vezes por outros usuários. Você não tem nada com o que se preocupar. GDScript continuará sendo a linguagem principal na Godot.

Eu não gosto de GDScript . Eu entendo que foi modelado após o Python, mas me sinto muito insignificante. C++ ou Java incluído (fora da caixa) seria uma ótima ideia na minha opinião. Pessoalmente, sinto nojo de usar GDScript em desenvolvimento, a ponto de questionar se deveria deixar Godot e voltar quando uma nova (ou alternativa) linguagem foi implementada. Desculpe, mas se você quiser os fatos concretos de um programador, você os tem.

Além disso, gostaria de mencionar que às vezes até uso Godot para alguns protótipos de software simples. Assim, uma linguagem de programação profundamente integrada possivelmente abriria portas para desenvolvimento de software dentro do mecanismo. Isso seria realmente um assassino do Unity. (Se, é claro, Java ou C++ foi escolhido)

Obrigado aos desenvolvedores leais por seu trabalho árduo, admiro todos vocês e aguardo os futuros lançamentos atualizados!

@VenHayz Não sei se você lê a documentação do Godot, mas já pode escrever seus jogos em C++, desde a primeira versão do Godot - http://docs.godotengine.org/en/stable/reference/custom_modules_in_c++.html

que tal usar o microsoft .net core? é multiplataforma e focado em desempenho, bem como também é de código aberto e é desenvolvido ativamente

Olá apenas um cara aleatório passando

Eu queria que você soubesse que não estou usando Godot porque não gosto da linguagem de script que você usa

Se você adicionar Java ou C #, instalarei e usarei o godot logo após o seu anúncio :)

@RUSshy adeus então, a perda é sua, godot é incrível, GDScript é ótimo, se você é um programador de verdade, levará literalmente duas horas para saber mais do que o suficiente para iniciar qualquer projeto. Programadores de verdade devem dominar muitas linguagens, você pode ficar com seu java/C# e ser um cara "aleatório" passando como um hobby para sempre. Não estou tentando ser rude, apenas relatando fatos. Se você não gosta de algo sobre esse mecanismo, contribua com algum código, é gratuito, diferente da maioria dos outros mecanismos.

Deus do Marketing favorece C#. :rindo:

@RebelliousX Escolher Java ou C# significa que você terá em mãos LOAD de biblioteca para usar

Limitar-se à linguagem de script caseira é simplesmente inútil, seu novo conhecimento não será aplicável em outro lugar e você não poderá encontrar toneladas de bibliotecas ou não poderá reutilizar seu conhecimento ou recursos de aprendizado existentes

A escolha é insana hoje em dia, não tenha a mente fechada

@RUSshy Você está brincando comigo? Eu (e vários outros) escrevi literalmente páginas de explicações sobre os benefícios do GDscript sobre C# e você acha que poderia resolver a discussão com um pequeno parágrafo sem ler nada do que foi dito antes?

"Não tenha a mente fechada" - ótima ideia, que tal você começar com a mente aberta sobre o GDscript?
"seu novo conhecimento não será aplicável em outro lugar" - isso é simplesmente falso. Você não poderá compensar a falta de conhecimento copiando e colando código que não entendeu.
"você não poderá encontrar toneladas de bibliotecas" - aprenda a diferença entre uma linguagem de script e uma linguagem de back-end. Ou - ideia maluca - leia o que escrevi sobre isso.

Sério, a audácia de algumas pessoas...

Foi dito várias vezes em vários lugares que um módulo de integração C# está em andamento. Vai tão rápido quanto a quantidade de tempo que as pessoas têm para fazê-lo. A única maneira de torná-lo mais rápido é contribuir para essa integração :)

@Warlaan sobre o segundo ponto: se você escreveu muito código em C# antes, não poderá reutilizá-lo, a menos que o porte todo. Você também não precisa entender o código de uma biblioteca para poder usá-la. O ponto é, se você precisar de algo que estava em C# antes (um único arquivo ou um conjunto de bibliotecas, código potencialmente fechado), você precisa portar tudo isso, incorporar um tempo de execução C# ou encontrar uma implementação C. Isso não é impossível, mas demorado.
Isso não significa que Godot não pode usar um monte de bibliotecas existentes... C/C++ tem toneladas delas também.

Isso corre o risco de se tornar uma guerra de chamas.
O log é tão longo que as pessoas repetirão as mesmas perguntas ou tópicos em vez de lê-lo.
Não há muito material técnico restante para discutir também.

O futuro de Godot em termos de script já está bem claro:

• O GDScript permanecerá como a linguagem principal e existem planos ou ideias para otimizá-lo (mas este não é o lugar certo para discutir isso).
• A partir da versão 3.0, C# terá suporte como alternativa de script. Forneceremos binários separados para evitar forçar o tamanho extra causado pelo tempo de execução mono em pessoas que não o usarão.
• DLScript também está em andamento. Ele permitirá que as pessoas usem bibliotecas compartilhadas para scripts. Essas bibliotecas podem ser escritas em qualquer linguagem que suporte c linkage e bibliotecas compartilhadas (espere linguagens como Rust e D). Ainda não está claro se estará pronto para o 3.0 (a menos que eu esteja desatualizado).
• Não se esqueça que haverá Visual Scripting na versão 3.0 também!

Se alguém planeja contribuir com outra coisa, este também não será o lugar certo para discutir isso.

Acho que esta questão pode e deve ser encerrada.

Acordado.

Poderia fornecer um link para os códigos-fonte de integração C#?

https://github.com/neikeq/GodotSharp

Como integração GodotSharp funcional? Está pronto para uso para testes?
Pode ser usado com a compilação de origem do godot master?

@nictaylr Não está construindo com o mestre atualmente. Se você quiser testá-lo, precisará usar o 2.2-legacy. Está funcionando muito bem com essa versão

Estou trabalhando para tê-lo pronto para um alfa 3.0 em abril.

Ideia aleatória, mas depois de pensar profundamente em C++ com Godot, pensei em algo possivelmente melhor. A linguagem D. Ele se enquadra em uma cota de linguagem indiscutivelmente "de baixo nível", com interface para C e (alguns) suporte a C++. Tem classes, e é muito moderno. Embora pareça assustador, parece muito com GDScript , e pude vê-lo sendo usado para impulsionar projetos muito grandes. É poderoso o suficiente para competir com C e C++ (gcc/g++) com um compilador chamado GDC. (O DMC também pode ser usado para compilar, mas o GDC compila diretamente para o gcc) veja mais sobre o GDC aqui

De qualquer forma, apenas uma sugestão rápida ou talvez para idéias.

@VenHayz Estou trabalhando em um módulo que permite o uso de bibliotecas compartilhadas para scripts. Eu já fiz algum esforço para tornar o C++ mais fácil de usar com ele. Você também pode usar D para criar essas bibliotecas. Se você estiver interessado em fazer ligações D, me procure no IRC ou no Discord.

@karroffel isso é muito legal. Não tenho experiência em escrever bibliotecas e APIs (referência à sua menção a "bindings"), embora provavelmente pudesse pesquisar sobre isso por um dia e fazê-lo; Eu sou orgulhosamente um aprendiz rápido. Eu gostaria de entrar em contato com você no Discord, se você não se importa? Meu discord: _hasCat#3941

@VenHayz Eu não posso te adicionar, você não está permitindo que outros te adicionem. Karroffel#8409 ou entre no servidor Godot

@neikeq Seu repositório GodotSharp é a base de código que está sendo usada para o suporte a C# no Godot 3.0? Só estou perguntando porque estou tentando ter uma ideia aproximada de quais recursos estarão disponíveis e, em caso afirmativo, darei uma olhada nessa base de código. Obrigado!

eu pareço godotsharp, está desatualizado? novo recurso? ou está pronto para usar na compilação de desenvolvimento?

como posso compilar godosarp do soruce para mim?

@nictaylr Você precisará usar o branch 2.2 legado como uma compilação de desenvolvimento.

Acho que li o suficiente para descobrir se alguém mencionou isso.

Pessoalmente, não quero aprender mais uma língua que não possa usar em nenhum outro lugar. Não estou planejando fazer muita programação 3D, apenas algumas coisas aqui e ali.

Sim, há muitos contra-argumentos contra isso, mas... é um projeto de código aberto. Não há necessidade de odiar alguém contribuindo com uma nova linguagem de programação.

Imagine levar cerveja para uma festa infantil. Você diria que "não há necessidade de odiar alguém contribuindo com uma nova bebida"? Há uma boa chance de que adicionar C# prejudique o desenvolvimento do GDscript. Eu sei que todos estão determinados a manter o GDscript como a linguagem principal para Godot, mas ainda me incomoda quando foi explicado várias vezes por que adicionar novos recursos tem desvantagens e as pessoas ainda estão perguntando "qual é o mal?".

Também pedir C# em vez de GDscript porque "você não quer aprender" é um argumento realmente estúpido. De todas as linguagens que conheço no desenvolvimento de jogos, o GDscript tem menos recursos e o C#, de longe, o mais. Se você não quer aprender, deveria ser grato pelo GDscript.

Eu realmente não quero esquentar essa discussão uma e outra vez, então, por favor, se alguém quiser comentar sobre este tópico, POR FAVOR, LEIA DE CIMA.

Também pedir C# em vez de GDscript porque "você não quer aprender" é um argumento realmente estúpido.

Eu não me importaria de aprender C# porque eu poderia usá-lo em outro lugar.

Apenas tranque o tópico, está ficando ruim.

É verdade que este tópico serviu ao seu propósito, vamos bloqueá-lo.