Godot: Script visual de estilo de folha de eventos

Muito disso não poderia ser aliviado ao capacitar o Visual Scripting atual com mais e melhores funções?

Muitos dos exemplos são triviais no projeto do UE4. "Ao pressionar a tecla W, mova este ator para frente".
Você poderia construir a maioria deles de uma maneira muito semelhante no blueprint e até as diferenças visuais (que seriam as únicas) seriam mínimas.

Devemos nos concentrar em tornar o Visual Script que temos utilizável e trabalhar de maneira intuitiva e suave, IMO. Do jeito que está, o Visual Script que já temos parece um pouco esquecido e não parece receber muito amor. Como ter dois sistemas de Visual Scripting melhoraria essa situação?

Uma boa ideia para um plugin. Mas manter oficialmente dois sistemas de scripts visuais seria uma dor e pouco ganho.

@mhilbrunner infelizmente não , Blueprints são uma abordagem completamente diferente para scripts visuais. Para você eles são triviais, mas eu te desafio a dizer isso no fórum do clickteam ou no fórum do construct. Esses caras estão presos aos motores que usam por causa do quanto eles amam essa abordagem e acredite em mim - muitos deles tentaram projetos em Unity , irreal e outros motores - incluindo Godot. Eles ainda estão presos à fusão construct2 ou clickteam porque preferem folhas de eventos a Blueprints. Eles ainda solicitam a abordagem da folha de eventos no fórum da unidade.
O script visual de Godot foi mencionado em seus fóruns e os usuários de lá ainda preferem folhas de eventos. Eu pessoalmente fiz a transição para gdscript e prefiro usar gdscript em vez de blueprints - porque gdscript está mais próximo em suas vantagens das folhas de eventos do que os blueprints.

É como dizer a alguém que gosta de bananas para comer tomates - é uma questão de gosto :)

@groud Pensei o mesmo por um tempo, mas nem sei por onde começar - e mesmo como plugin - alguém terá que manter o plugin.

@reduz pareceu se sentir mais à vontade com a ideia no facebook, mas entendo que ele está

De qualquer forma, estou postando isso aqui para documentação - para delinear o sistema de folha de eventos - o que ele faz e como difere dos planos. Se alguém estiver interessado em implementá-lo no Godot ou como um complemento, por favor nos avise. Eu definitivamente arregaçaria as mangas e ajudaria, espalharia as notícias e obteria feedback dos usuários do clickteam/construct.

Até agora eu nem sei como implementar sua interface com a classe GUI do godot corretamente. Você deve ser capaz de arrastar blocos lógicos entre células da mesma coluna. Copie/cole blocos/linhas também - aninhe linhas e
outras coisas únicas. Eu não acho que é uma tarefa pequena

@blurymind Sim, e obrigado definitivamente por apontar isso e

devs: Qual é a melhor maneira de adicionar isso com complexidade mínima? Talvez eu encontre algum tempo para ver como os scripts visuais atuais funcionam. Gostaria de saber se é possível apenas substituir a interface do usuário do Visual Scripting ou gerar GDScript ou alguma outra maneira de fazer isso dinamicamente.

Ainda não analisei nada disso, então dicas são bem-vindas. :) Nenhum ponteiro nulo, por favor!

@mhilbrunner , talvez possamos abrir outro problema no rastreador com uma lista de coisas que o sistema blueprint no godot precisa para ser mais intuitivo. Por favor, link para ele se você fizer isso

Meu post aqui é uma proposta para uma abordagem alternativa, não para uma mudança da atualmente implementada. As folhas de eventos são muito diferentes de qualquer maneira

Acredito que essa folha de eventos possa ser implementada via Nativescript, mas não vejo nenhuma razão pela qual precisaria contar com a mesma base de código que o visualscripting.

@groud que é um bom ponto, na verdade. Quanto da base de código visualscripting atual pode ser reutilizada? Quão específico é para a interface do nodegraph?

@blurymind Sim, você está trabalhando nessa lista para o VS e fará, mas levará algum tempo.

Precisa investigar o NativeScript :)

Agora temos várias opções para linguagens de script (C++, C# e até python). Por que não também ter mais de uma opção para scripts visuais :)

Eu acho que isso também pode depender de quão flexível é a API do Godot para construir interfaces de script visual.
A base de código visualscripting deve ser reutilizada - ou uma completamente alternativa deve ser escrita com Nativescript (c++)?
Isso pode ser implementado apenas como um complemento gdscript?

Por que não também ter mais de uma opção para scripts visuais :)

Porque já suportamos muitos idiomas integrados. A maioria dos casos de uso já está coberta, portanto, não há muitos motivos para adicionar uma nova linguagem para manter. Temos uma linguagem para programação básica (GDscript), duas para performances (C# e C/C++) e uma para artistas/designer de jogos (scripts visuais). Não há razão para adicionar outro idioma como embutido apenas porque algumas pessoas não conseguem aprender um novo idioma.

Honestamente, eu definitivamente não acho que isso deve ser adicionado ao núcleo. Seria melhor adicionado por meio de um plug-in como qualquer outra ligação de idioma. Já temos trabalho suficiente para manter os idiomas atuais.

E não, acho que não podemos reutilizar o código do visualscripting.

@groud Esse é um bom ponto, mas considere a proporção de programadores para artistas no gamedev. Alguns dos maiores e mais belos jogos 2D retrô foram feitos com o fusion 2 por artistas que queriam fazer jogos de uma maneira intuitiva que se adaptasse à sua maneira de pensar. Aqui está um showreel um pouco desatualizado de jogos feitos pelo Fusion:
https://www.youtube.com/watch?v=3Zq1yo0lxOU

Eles têm muitos projetos bem-sucedidos de kickstarter e jogos no Steam - jogos em muitas plataformas. As pessoas gostam de usar essa abordagem na programação visual - até mesmo equipes profissionais. Eu não o apresentaria aqui se não visse potencial de expansão da base de usuários

Bem, talvez, mas quantos deles são capazes de entender Folhas de Eventos, mas não VisualScripting? Você está dizendo que "esses caras estão presos aos motores que eles usam por causa do quanto eles amam essa abordagem e acredite em mim - muitos deles tentaram projetos em Unity, irreal e outros motores - incluindo Godot", mas você está realmente o primeiro a perguntar isso.

Se esta for uma demanda popular, sim, podemos adicioná-la ao núcleo. Mas até agora não é.

Para mim, já cobrimos todos os casos de uso. Pelo menos para um motor de jogo profissional e de última geração. E como não temos como alvo crianças ou hobistas, mas empresas, não vale a pena gastar tempo com isso. Fusion 2, Construct ou mesmo RPGMaker focam em outro público, mesmo que belos jogos tenham sido feitos com eles apenas uma ínfima parte deles são projetos profissionais.

@groud essas estatísticas são difíceis de encontrar. Quantos estão usando o script visual atual?

Também estou destacando por que a abordagem da folha de eventos tem vantagens sobre os projetos - como menos cliques para fazer as coisas funcionarem, apresentação mais clara e melhor transição de aprendizado para gdscript.

O mecanismo de criação de rpg é realmente um editor de níveis, se você me perguntar. Não tem o mesmo nível de flexibilidade que Fusion e construct2

É mais fácil explicar a alguém como funciona uma folha de eventos, do que explicar o mesmo exemplo em um blueprint - eles precisam aprender muito menos conceitos - não precisam ser ensinados sobre o tipo de conexões entre nós, tipos de entradas e saídas - como definir o fluxo.
Em vez disso, os eventos fluem de cima para baixo, a esquerda é a condição e a direita é a ação. Você não precisa conectar nada.

Isso

olhar tão difícil de entender como este?

Claro, godot usaria mais blocos de eventos para alcançar, mas ainda seria mais claro do que um gráfico de nó.
Até o gdscript parece mais claro para mim do que isso. Nosso atual sistema de script visual parece complicado à primeira vista

Falo como alguém que usou os dois sistemas e agora os está comparando - ambos são igualmente poderosos, um é claramente mais simples de aprender e entrar
Experimente por favor. Você pode experimentar o construct3 no seu navegador gratuitamente aqui:
https://www.scirra.com/
Se você tem um filho ou um irmão mais novo, peça a eles para experimentá-lo, então tente Godot's - veja o que eles podem fazer e quanto tempo eles levam para fazê-lo sem instruções - há um mercado potencial para mais escolas adotarem Godot aqui - melhore o script visual para aprender conceitos de programação e obteremos um público mais jovem usando o mecanismo

Quantos estão usando o script visual atual?

Não faço ideia, mas acredito que não muito por enquanto. A maioria das pessoas parece usar GDScript por enquanto, já que não vejo muitas perguntas/conteúdo sobre VisualScripting no Facebook ou Youtube. Adicionar folhas de eventos antes de ter certeza de que o VisualScripting não responde a todos os casos de uso seria uma aposta audaciosa. Vamos ver por enquanto se o VisualScripting é suficiente, e se as pessoas pedirem massivamente por outro sistema, podemos adicioná-lo mais tarde.

@groud seria ótimo se pudéssemos testar o script visual do godot em um ambiente escolar - com crianças aprendendo conceitos básicos de codificação.
Um dos maiores pontos de venda da construct2 tem sido ensinar programação para crianças e eles vendem uma licença educacional especial há anos.

Meu argumento é que o script visual no godot no momento não é muito convidativo para não codificadores e realmente não ajuda as pessoas a aprender a codificar - porque sua abordagem é puramente centrada na máquina de estado e os conceitos básicos de programação ficam ainda mais complicados com o nodegraph adicional regras centradas no topo.

Programadores experientes não são realmente o melhor público para vender isso - porque eles veriam a folha de eventos como uma simplificação do que já temos - gdscript e verão os blueprints como uma nova ferramenta que poderia ser usada como uma máquina de estado pelos designers.

Eu adoraria tentar escrever um addon de folha de evento básico em gdscript, eu realmente não tenho experiência suficiente para fazer um addon de script nativo. Se isso for possível e você tiver algumas dicas por onde começar - eu adoraria ouvi-las
Talvez, se houver interesse suficiente, alguém possa fazê-lo em script nativo

porque sua abordagem é puramente centrada na máquina de estado

Que ? Não faço ideia por que você pensaria isso. VisualScripting não tem nada a ver com máquinas de estado.

Qual é mais simples de usar no momento - Blueprints ou Gdscript? Qual é o objetivo do script visual e quem é o usuário-alvo

VisualScripting deve ser mais simples que GDscript para artistas/desenvolvedores de jogos. Eu tenho que admitir que não é realmente para agora, provavelmente um monte de nós pode ser simplificado / tornado mais atraente. Mas honestamente, você está errado pensando que as Folhas de Eventos são mais fáceis de entender do que o VisualScript, para mim não são.

A única coisa que realmente faz a diferença nos exemplos que você mostra são o texto e os ícones que tornam as coisas muito mais compreensíveis. São o texto e os ícones que tornam as coisas mais explícitas e diretas, não a organização vertical. O VisualScripting seria tão compreensível se adicionássemos esses ícones, se fizéssemos uma GUI melhor para as ações mais comuns e agrupássemos as funções em categorias pertinentes.

@groud também é a ordem de execução e os tipos de conexões. Há muito mais conceitos a serem observados no gráfico de nós do que na folha de eventos. Mesmo se você adicionar ícones aos nós, ainda terá que explicar que a ordem dos eventos é ditada pelas linhas brancas, também o que as outras cores significam. Você ainda acaba com um gráfico de espaguete que é mais difícil de ler - seus olhos precisam viajar por todo o lugar para descobrir o que está acontecendo no gráfico de outra pessoa

Você não é o público-alvo certo - você é um programador c++ experiente. Por favor, teste isso com pessoas que não são programadoras e você começará a ver o que quero dizer.

Vamos lá, não é tão difícil de entender, mais uma vez não estamos visando crianças.
E em relação à organização do código, o problema é o mesmo para as folhas de eventos. Se você não se incomodar em agrupar nós e organizar seu código, acabará com um código ilegível, seja devido a folhas de eventos longas ou gráficos de nós enormes.

@groud podemos até agrupar nós visualscript como no blender? Não me lembro de ter visto isso. Talvez @mhilbrunner deva adicioná-lo à sua lista
https://github.com/godotengine/godot/issues/12418
Outro ponto importante é que a capacidade de criar blocos lógicos de ação/condição de alto nível reutilizáveis ​​via gdscript seria muito benéfico para um sistema de folha de eventos ou o sistema de blueprint. O sistema de blueprint já o possui - mas não vejo nenhum plugin feito para ele ..

Novamente - construct2 está muito à nossa frente. Sua comunidade criou muitos plugins fáceis de instalar que adicionam condições e ações personalizadas - e sua API para registrar uma ação e uma condição é super simples
https://www.scirra.com/forum/completed-addons_f153
https://www.scirra.com/manual/19/actions-conditions-and-expressions

Totalmente de acordo com blurymind
Para mim é muito mais fácil entender o sistema de eventos Construct and Fusion, que também oferece muito mais rapidez para desenvolver qualquer jogo do que um sistema cheio de linhas

lol como isso é mais fácil de ler do que o gdscript

@groud podemos até agrupar nós visualscript como no blender? não lembro de ter visto isso

Eu não sei. Mas se não for implementado, acho que deveria ser.

lol como isso é mais fácil de ler do que o gdscript

Este não é o ponto aqui.

@groud sim, é. por que um desenvolvedor de jogos gostaria de usar folhas de eventos quando é muito mais desorganizado / confuso de ler do que um simples código gdscript? esse é o cerne desta sugestão de recurso, não é

@groud sim, é. por que um desenvolvedor de jogos iria querer usar folhas de eventos quando é muito mais desorganizado do que um simples código gdscript?

Não, não é, VisualScripting (ou Event Sheets) e GDscript não tem como alvo as mesmas pessoas. VisualScripting (ou folhas de eventos) são para artistas ou designers de jogos/níveis, enquanto o gdscript requer experiência em programação.

Comparar folhas de eventos e GDscript não faz sentido.

Comparar folhas de eventos e GDscript não faz sentido.

bem, é aí que nos diferenciamos :P porque acho mais do que razoável compará-los. especialmente porque o gdscript faz tudo o que eles fazem, em um nível muito mais simples.

Além disso, discordo sobre o "requer experiência em programação". se um designer de nível está criando blocos de ações _em uma folha de eventos ou scripts visuais já_, eles _já têm os blocos de construção fundamentais_ para usar o gdscript.

com isso dito: gdscript compilado por JIT está no roteiro e seria muito mais benéfico do que folhas de eventos ou adições de scripts visuais (já que a maioria dos desenvolvedores Godot já poderia se beneficiar muito com isso). e os casos de uso potenciais do VS/Event Sheets são muito baixos atualmente. Então, tudo o que estou pedindo, por favor, seja cauteloso com o tempo de desenvolvimento do lead, pois sua postagem recente já fez alusão a

@girng em que ponto você decidiu que estou tentando roubar a prioridade de outros recursos importantes no roteiro? Este post está explorando os benefícios do script visual por meio de um método alternativo ao que temos no momento.
Não está nem no roteiro, mas você pula nele como se estivesse aqui para tomar seu café da manhã. :p
Explorar uma ideia não é exatamente o mesmo que demandar tempo.

Você obviamente nunca tocou em construct ou clickteam fusion , se quiser ter uma discussão sobre isso - pelo menos use a folha de eventos por um tempo - faça um jogo de plataforma com ele.
Eu vinculei a uma demonstração online do construct3, que não exige que você registre uma conta ou faça login.
https://www.scirra.com/
está literalmente a três cliques de distância

Experimente a folha de eventos, faça algo com ela. Em seguida, use os projetos do Visualscript que Godot tem

Gdscript é simples - sim, eu concordo e adoro também. Um gdscript compilado em jit seria incrível! Concordo que é mais importante também.
Mas esta discussão não é sobre essas coisas

bem, é aí que nos diferenciamos :P porque acho mais do que razoável compará-los. especialmente porque o gdscript faz tudo o que eles fazem, em um nível muito mais simples.

O que você não entende é que para muitas pessoas há uma barreira mental entre codificar e não codificar. Eu tenho que admitir que o VS é um pouco difícil de entrar no momento, mas no futuro deve ser mais fácil do que o GDScript, já que muito material de aprendizado pode ter sido criado e várias melhorias no VS devem ser feitas.

Além disso, discordo sobre o "requer experiência em programação". se um designer de nível já está criando blocos de ações em uma folha de eventos ou script visual, ele já possui os blocos de construção fundamentais para usar o gdscript.

Sim, eu concordo bastante também como programador, mas não é isso que a experiência mostra.
Unreal é o exemplo perfeito: muita gente usa blueprints com Unreal, principalmente na área profissional, pois permite que não programadores escrevam código de forma mais acolhedora. Mesmo que não seja tão diferente do código real (na minha opinião), isso faz as diferenças na mente das pessoas. Se os profissionais usam, significa que é uma necessidade real, não um gadget que devemos descartar porque achamos que são a mesma coisa. Por isso não faz sentido compará-los, ambos devem estar disponíveis e funcionando corretamente.

Enfim, vou parar essa discussão aqui. O bikeshedding sobre VS ou não VS já foi tratado.

@blurymind admiro sua energia e você faz bons pontos. Eu tentei folhas de eventos na construção antes e elas eram legais no começo, mas quanto mais avançado meu jogo se tornava, eu instantaneamente queria voltar ao código. então sim, eu tentei-los no passado.

@groud faz um bom argumento sobre eles, já que Marvel Heroes era um aRPG AAA e eles usavam blueprints com Unreal .

não discordo que eles tenham seus casos de uso, apenas acho que será difícil justificar, com base nos seguintes critérios:

• mão de obra dev limitada
• quantidade de questões atuais já
• desorganização / difícil de ler (veja aqui )
• eu sinto que a maioria dos desenvolvedores Godot prefere usar o gdscript
• gdscript se encaixa tão bem com godot já
• se adicionado ao core , novos problemas podem surgir em torno das folhas de eventos, o que pode eliminar os problemas do gdscript
• não é justo para os atuais 90% de devs godot que já usam gdscript (se o tempo dev puder ser usado para gdscript compilado por jit, que atende a casos de uso ativos)

como um plugin eu poderia suportar totalmente, mas meu coração está dizendo que pode não ser uma boa ideia se for oficialmente suportado

@girng obrigado. Mais uma vez - este não é um pedido para substituir gdscript ou script visual.
É mais uma observação sobre scripts visuais em geral e como os scripts visuais da Godot no momento não são realmente fáceis de usar para não codificadores.

O Gdscript pode combinar lindamente com qualquer sistema de script visual - folhas de eventos ou projetos.
Conforme observado no meu primeiro post - a abordagem da folha de eventos também usa expressões - para as quais o gdscript já pode ser usado. Blocos lógicos de nível superior podem ser criados via gdscript e o sistema de plugins do godot também - ele se encaixa lindamente com um sistema de script visual.

Na verdade, um sistema de folha de eventos pode ser muito melhor casado com o gdscript do que o sistema blueprint atual - onde as expressões são feitas com um bilhão de gráficos de nós em vez de uma simples entrada de campo de texto. Se você quiser fazer 1+1- use um nó. Se você quiser endereçar uma variável simples em uma expressão, use outro nó. Você acaba com uma bagunça de espaguete de um bilhão de nós básicos para uma expressão simples que poderia ser escrita com a mesma facilidade e muito mais clareza em um pequeno campo de texto com muito menos esforço e verbosidade.

O script visual atual que temos leva muitos cliques, nós e verbosidade para fazer as coisas mais simples. Essa é outra razão pela qual o gdscript é mais direto imo - uma linha de código em vez de 10 nós e 100 conexões.

Essa é basicamente a outra vantagem de um sistema de folha de eventos - você pode simplesmente escrever suas expressões dentro dos campos de entrada do bloco de código. Tanto o construct2 quanto o fusion possuem editores de autocomplete e expressão com fácil acesso a todos os métodos que um nó possui com uma lista de todos os nós aos quais a planilha tem acesso no escopo.

Godot poderia facilmente usar gdscript para expressões ao fazer a mesma coisa - mas essas expressões são colocadas em uma estrutura de planilha simples.

Imagine um método em godot- como um bloco lógico. Assim como seu método - esse bloco usa os mesmos parâmetros - mas você não precisa conectá-lo a nós. Você pode simplesmente digitar algum gdscript em seu campo de entrada.
Os nós em godot podem atuar como os comportamentos em construct2 e uma folha de eventos em godot seria muito mais flexível e poderosa do que construct2's. Não terá nenhuma das desvantagens que seu motor tem

A abordagem do Construct para emparelhar objetos é horrível - entre outras coisas - mas isso não tem nada a ver com o design da folha de eventos

O script visual atual que temos leva muitos cliques, nós e verbosidade para fazer as coisas mais simples.

Essa não é uma falha inerente do VS, mas de sua implementação atualmente limitada. Isso deve ser corrigido, não usado como argumento para implementar outro método de script visual próximo a ele. Caso contrário, o VS atual deve ser descartado.

Além disso, discutir JIT para GDscript é offtopic. O mérito de um recurso só pode ser medido por:

• é a utilidade versus outros recursos semelhantes que podem ser úteis para o mesmo caso de uso
• sua utilidade versus a complexidade que traz para a mesa, a dívida técnica adicional e a carga de manutenção para Godot

Portanto, se isso deve ou não ser feito não tem nada a ver com a implementação ou não de JIT para GDScript. Caso contrário, devemos fechar 99% de todas as solicitações de recursos até que todos os principais bugs sejam corrigidos, ou seja, para sempre. Esses são ainda mais importantes do que JIT para GDScript.

O @mhilbrunner JIT para GDScript vai realmente acontecer, já está no roteiro oficial :P. Eu estava apenas dizendo que isso poderia tirar o tempo de desenvolvimento disso. e é difícil justificar isso, já que 90% dos desenvolvedores do godot já usam gdscript (e muitas pessoas acham que é melhor do que folhas de eventos e têm seus próprios sentimentos). desculpe se não me expressei direito. sim, eu sei que isso não está substituindo, mas estou dizendo mais sobre o tempo de desenvolvimento.

com isso dito, @blurymind não posso discordar de nada que você disse porque são pontos realmente bons. ter folhas de eventos em Godot _seria um bom recurso para ter_? com certeza, mas é algo que vai acontecer na realidade em breve? eu não tenho certeza. (apenas um usuário ávido desde 2014, e esta é apenas a minha opinião)

Tendo usado a planilha de eventos do Action Game Maker e do Game Maker anteriormente, concordo que é mais fácil de usar e entender do que o VisualScript (você lê de cima para baixo, não seguindo linhas), não ocupa tanto espaço na tela e pode implementar finito máquina de estado mais facilmente (filtrando quais eventos podem ser acionados após o término de um evento).

Seria uma adição muito legal. Eu provavelmente não o usarei, pois o GDScript é suficiente para mim, mas posso me imaginar usando-o muito bem se o GDScript não for uma opção (que iniciantes e não programadores provavelmente estão experimentando).

Bem, eu sou um usuário Godot por cerca de um ano. Eu amo GDScript e sua sintaxe simples.
Mas eu uso o Construct há mais de 8 anos e posso dizer que nunca vi um Visual Script mais fácil do que o Event Sheets. Não entendo como as pessoas podem dizer que o Blue Print é mais fácil do que o Event Sheets. Talvez seja porque os artistas estão acostumados a usar nós para configurar shaders e gráficos, eles estão acostumados com essa estética. Mas aposto que se você colocar um sistema de folha de eventos em um mecanismo como o Unreal, as pessoas abandonarão os Blueprints.

Eu trabalho em uma escola que ensina lógica de programação para crianças e adolescentes. Para as crianças, usamos o Construct 2 porque é dolorosamente fácil para elas criar algo com as Folhas de Eventos. Para adolescentes usamos GDScript e tivemos bons resultados com ele. Quando Godot 3.0 saiu, estudamos a ideia de largar o Construct 2 para usar Godot VS, mas abandonamos a ideia porque agora VS é mais difícil que GDScript, muito complicado de entender e usar. Se Godot tivesse algo como o Event Sheet nós faríamos nosso curso totalmente baseado em Godot, pois tendemos a privilegiar soluções Open Source na escola.

Outro benefício que eu acho que o Event Sheets traria, seria aumentar a base de usuários do Godot, já que no GDC vimos estúdios médios e grandes preferirem Godot, mas os pequenos preferem Unity e outras soluções. Acho que usuários de Construct, Fusion e Game Maker começariam a migrar para Godot.

Bem, como professor eu vejo um grande valor nas Folhas de Eventos, porque é muito fácil de entender e quando os alunos passam para o GDscript, eles já desenvolveram um pensamento lógico e a estrutura das Folhas de Eventos são mais como código do que Blue Prints.

De qualquer forma, eu amo o que Godot está fazendo e amo GDscript, eu só queria jogar minha experiência, pois uso tanto a Folha de Eventos quanto o GDscript para ensinar. Mantenha o ótimo trabalho!

Quando Godot 3.0 saiu, estudamos a ideia de largar o Construct 2 para usar Godot VS, mas abandonamos a ideia porque agora VS é mais difícil que GDScript, muito complicado de entender e usar

É um feedback bem interessante. :)
O fato é que as Folhas de Eventos, na forma Construct2, são muito menos de baixo nível do que VS ou GDscript. Na verdade, eles podem ajudar as crianças a entrar na programação de jogos, mas não é o alvo de Godot. Acredito que tal sistema não deve ser enviado como embutido, mas disponível através de um plugin. Eu acho que este comentário de reduz expressa isso também.

@DrZanuff obrigado por trazer esse ponto realmente importante - algo na mesma linha também foi observado pelo canal do youtube kidscancode e

Talvez Godot possa abordar isso da maneira que o criador de jogos faz - seu código visual de arrastar e soltar é traduzido diretamente em código gml que pode até ser visualizado em tempo real. Dessa forma, os não-codificadores podem aprender gml enquanto estão usando o sistema de script visual do mecanismo - é a estratégia exata que os jogos yoyo empregam para que os não-codificadores sejam introduzidos gradualmente no gml
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/ Changing_dnd.html

Tanto ao usar alguns gml para expressões quanto ao visualizar o que sua programação visual está fazendo

Mesmo como um complemento - continuo pensando que os objetos da folha de eventos do godot devem no final ser traduzidos para gdscript. A folha de eventos pode ser uma ferramenta para ensinar os não codificadores a usar o gdscript - dando a eles uma interface fácil que ainda permite o uso de gdscript para expressões e, no final, gera e visualiza o gdscript de qualquer maneira.

A API do Godot tem um método para gerar arquivos gdscript e anexá-los aos nós. Portanto, uma folha de eventos pode ser traduzida para gdscript ao executar o jogo ou até mesmo durante a edição da folha de eventos, como o criador de jogos faz.

O auxílio de aprendizado adicionado que tanto o clickteam fusion quanto o construct2 empregam é uma lista de menu baseada em cliques de métodos/membros de nós integrados

À medida que o aluno clica em qualquer um dos itens da lista, a sintaxe apropriada é adicionada ao campo de entrada. Quando eles começam a aprender, eles clicam, mas conforme eles clicam eles aprendem e memorizam a sintaxe e os métodos. Mais tarde em vez de clicar, eles estão digitando com autocompletar e sem perceber aprenderam a api

Nesse sentido, a implementação de um sistema de folha de eventos da Godot pode ter como objetivo principal introduzir não codificadores ao gdscript e conceitos básicos de programação sem confundi-los com qualquer sintaxe - isso colocará Godot em mais escolas ensinando programação para pré-adolescentes. À medida que avançam, eles aprenderão gdscript e api do godot, em vez de construct2 ou game maker

Acho que não expliquei bem... :(

Quando digo linhas, refiro-me ao script visual, às linhas que conectam os nós

O sistema de eventos de construção e fusão é muito mais intuitivo, fácil e rápido de criar um jogo, do que o script visual Godot

Seria bom explorar uma alternativa deste tipo

Os recursos de nível superior do
Levaria muito menos trabalho para criar e manter funções de nível superior para o sistema de blueprint atual, do que seria escrever a funcionalidade de folha de eventos de funções de nível superior E um sistema base de folha de eventos totalmente novo do zero como um plug-in.

Se tivéssemos uma implementação de baixo nível de um sistema de folha de eventos, seria muito mais fácil criar e manter ações/condições de alto nível para isso.
Eu acho que mesmo como um addon - eu faria primeiro o addon base Event Sheet com apenas acesso de baixo nível e uma interface - que segue a arquitetura do godot sem inchar com novos métodos. Então addons opcionais separados para coisas de nível mais alto podem ser escritos em cima em outros plugins.

O repositório de ativos pode ter uma seção especial para complementos de script visual

Eu ensino programação para crianças entre 7 anos e 17 anos. Atualmente os alunos mais novos estão usando o Cosntruct e os mais velhos estão usando Godot, mas se todos os meus alunos pudessem usar o Godot ficaria muito grato pelas crianças estarem usando o Godot desde o início de sua jornada neste mundo de desenvolvedores de jogos.

Não é apenas o sistema de folha de eventos. É também como funcionam os plugins/behaviours/families , os UIDs e as propriedades dos objetos.

Por exemplo em C2 em um sprite de objeto eu posso ter toda a arte do jogo, incluindo estática/animações de decoração, jogador, inimigos,etc... todos com suas colisões,etc... e colocar no layout selecionando qual frame no início e usando uma variável de instância no objeto chamada "type=" para dizer se é um inimigo, jogador, objeto, quebrável, etc... para nos eventos definir seu comportamento. Também para cada sprite você tem algum programa básico de pintura, propriedades do animador, etc...

Em Godot eu tentei o exemplo Pong no script visual e quando eu vi ele usa um sprite para o jogador e outro objeto sprite para a colisão, e eu fiquei tipo, O que!? . Também o C2 tem uma "forma de polígono de adivinhação" que com um clique faz a colisão do seu sprite usando 8 pontos. Depois disso, você pode adicionar mais pontos e ajustar para ser mais preciso ou usar alguns plugins ou truques para obter precisão de pixel.

Quer dizer, se godot aplicar o sistema de folha de eventos como no C2, mas não seguir a mesma filosofia de tornar tudo fácil de usar, será perda de tempo porque não funcionará. E bem, fazer tudo isso no motor Godot real pode ser um trabalho muito louco.

No caso de ir em frente, talvez eles devam pedir/contratar os grandes caras do C2 como RexRainbow, R0j0hound, etc... . Mas como eu disse, isso significa muito trabalho e dinheiro.

@matriax Eu não acho que você esteja correto aqui.
Godot tem uma arquitetura muito mais flexível e direta que o Construct2.
Como o emparelhamento de objetos observado é uma dor na construção, entre muitas outras coisas - poderíamos, por exemplo, ter uma ordem de eventos mais clara do que a da construção. Podemos anexar folhas de eventos a qualquer nó - permitindo uma melhor organização do que construct'2.
Para tipos/famílias - em godot temos "grupos" - a implementação de grupos de godot é realmente melhor que a de construção.
Para anexar comportamentos a objetos - Você pode simplesmente anexar nós filho e usá-los como o comportamento do nó pai raiz que contém a folha de eventos anexada. Isso é realmente melhor do que Construir novamente.
No godot, você tem que fazer de um nó de forma de colisão um filho do nó que tem a colisão. Não é ciência de foguetes e é realmente melhor para ensinar crianças sobre programação

Algumas das coisas que você está solicitando devem ser feitas como complementos e já foram feitas como complementos (adivinhe a forma do polígono, por exemplo)

A implementação de um sistema de folha de eventos no Godot que se encaixa com a arquitetura atual do Godot resultaria em um sistema de folha de eventos/plataforma de aprendizado melhor do que o do construct - porque o Godot permite muito mais flexibilidade nos estilos de codificação e possui uma arquitetura melhor. Expandir esse sistema com funcionalidade de nível superior por meio de plugins o tornaria tão amigável quanto o construct2

Tornar o Godot tão amigável quanto o Construct 2 precisaria ser um esforço conjunto imo - tanto dos principais desenvolvedores do Godot quanto de sua comunidade. A comunidade precisaria criar a funcionalidade de nível superior por meio de complementos da folha de eventos. Por favor, não tente fazer o godot exatamente igual ao construct2. É em muitos aspectos melhor.

@blurymind Não estou dizendo sobre aplicar a mesma arquitetura que em C2, isso não faz sentido, também não conheço todas as coisas que Godot já tem como os grupos, nós filhos, etc. você disse.

O que quero dizer é que adicionar um sistema de folha de eventos no Godot sem seguir a mesma filosofia para realizar todo o trabalho de maneira fácil como no C2/C3 será uma perda de tempo. Como eu disse, ter um objeto para sprites/colisions ou todo gameart em vez de um objeto para cada coisa.

Talvez eles devam perguntar à comunidade quantas pessoas estão usando o script visual real e quantas pessoas preferirão o sistema de folha de eventos e então tomar uma decisão.

@matriax você precisa aprender Godot antes de fazer tais afirmações :)

A proposta aqui é para uma folha de eventos, não para uma cópia completa do motor do construct2.

Conhecendo os dois mecanismos, acredito fortemente que uma folha de eventos pode ser feita de maneira centrada no godot e tornaria o godot uma ferramenta tão boa, se não melhor, para ensinar crianças mais novas sobre programação.

Nesse sentido, uma entidade de folha de eventos seria igual a um arquivo de script - semelhante ao que o DND no criador de jogos faz, nada no mecanismo ou como ele funciona precisa ser alterado. Se você quiser outros recursos do construct2, você pode fazer alguns addons

Mesmo como uma implementação de complemento - uma folha de eventos no godot não deve fazer nada além de apenas criar outra interface para gerar arquivos gdscript imo

@blurymind E novamente com a mesma coisa, ok esqueci.

@matriax o feedback é uma boa ideia. Você está certo nesse ponto.
Seria bom perguntar a um grupo-alvo de pessoas - não apenas a qualquer um na internet. Um grupo-alvo poderia ser jovens estudantes e professores - esse seria o alvo perfeito para um sistema de folha de eventos.
os professores saberiam muito bem com o que seus alunos estão lutando e, ao mesmo tempo, conhecerão Godot e Construct. Estudantes e não codificadores podem dar um bom feedback

Se você apenas perguntar no rastreador godot aqui - você ficará mais experiente para programadores intermediários - pessoas que já conhecem e amam o gdscript, a API do mecanismo e até o c ++
Eles reagirão de forma protetora - como você pode ver no início do post - pensando que o que você está propondo não é o que eles precisam e o motor precisa - naturalmente porque já sabemos escrever código em gdscript e vemos objetivos mais importantes para o motor do que este. É verdade que existem objetivos mais importantes.
Se você tiver sorte, alguns deles teriam começado com a fusão construct/game maker/clickteam antes de vir para a Godot, e saberão onde está seu valor para pessoas que ainda não conhecem nenhuma linguagem de programação.

Alguém disse que os artistas 3d gostam de plantas, porque eles já sabem como fazer shaders. Esse é um ponto muito bom - um artista 3D não é um programador - mas ainda é um indivíduo técnico que aprendeu os conceitos de um sistema gráfico de nós.

Voltando ao valor disso - não seria maravilhoso se Godot, talvez algum dia no futuro, se tornasse o primeiro motor de mais crianças?
Por que não tentar substituir o Construct nas escolas :) Os desenvolvedores do Scirra estão tendo muito fácil agora. Veja como eles se gabam de colaborar com as escolas
https://www.construct.net/gb/blogs/construct-official-blog-1/construct-3-a-year-in-review-947?utm_campaign=blog1postemailsub&utm_medium=email&utm_source=947&utm_term=txt4-read-laura_d% 2527s-post&utm_campaign=marketing&utm_source=sendgrid&utm_medium=email

Em termos de experimentar a ideia como um complemento, fiz uma prova de conceito WIP. Ele não faz nada no momento - é apenas descobrir como a interface poderia funcionar e se relacionar com a arquitetura do godot. Não tenho certeza de como arrastar para embaralhar elementos dentro das células e recuar ainda

Seria legal se o nó richtextlabel no Godot pudesse usar ícones internos do editor Godot

Farei outra maquete para um editor de condições/ações quando tiver tempo :)
O editor de ações/condições seria a ferramenta para editar células/blocos lógicos. Estou pensando em algo semelhante à abordagem do Construct2 com o editor de código interno do Godot como o editor de expressão.
Talvez alguns auxiliares possam ser adicionados mais tarde - como os do construct2 ou fusion

Uma vez que uma interface é feita, o resto é apenas fazer com que ela salve / armazene os dados dentro da cena e seja capaz de gerar gdscript limpo - mas pode estar faltando algo

@blurymind Legal, gostei do conceito.
Talvez os botões para adicionar ações e condições devam ser sem o botão de fundo, como na construção 2

E eu acho que seria legal uma linha para separar a condição da ação

Eu gosto do jeito que isso está acontecendo.

Essa é uma maquete muito legal. No começo eu realmente não entendi aonde você queria chegar. Agora está bem claro... uma espécie de passo intermediário entre a programação e o tipo de script visual que já temos?

@DrZanuff Obrigado pelo feedback
@Zireael07 Obrigado :)
Sim exatamente - uma ferramenta que nos ajudaria a substituir o Construct2 completamente pelo Godot nas Escolas que usam os dois mecanismos para ensinar programação.
Por baixo, há apenas uma interface visual para gerar arquivos gdscript - semelhante a como o DnD é usado no Game maker 2. Não estou solicitando nenhuma alteração na excelente arquitetura do Godot.
As folhas de eventos podem ser uma opção de script visual no Godot que é amigável para não codificadores (os projetos não são) e crianças pequenas aprendendo conceitos de programação - facilitando-os em gdscript

Godot já tem muitos elementos para fazer isso funcionar, mas não pode ser exatamente o mesmo que no Construct2. À maneira de Godot, será melhor de várias maneiras se isso acontecer. A folha de eventos do Construct2 permite algumas práticas de organização de código muito ruins e tem algumas limitações/peculiaridades terríveis. Podemos realmente fazer uma folha de eventos melhor do que a deles, que seja amigável ao usuário e ensine melhor a programação - sem peculiaridades.

A meu ver - muito do trabalho está na criação da interface para editar folhas de eventos - tenho mais algumas idéias de como melhorar isso aproveitando as vantagens do godot - mas levará algum tempo para desenvolver a prova de conceito isso explica. Algumas vezes uma imagem vale mais que palavras. Um addon - mais do que uma imagem

Ame seu trabalho sobre isso. Você estaria disposto a disponibilizá-lo em um repositório enquanto trabalha nele (se o fizer)? Gostaria de dar uma olhada e cutucá-lo e brincar.

@mhilbrunner Claro que você pode - e eu realmente vou adorar se vocês mexerem com isso. Só precisa de algum tempo para torná-lo mais apresentável. :)

Estou no processo de integrar o gui ao editor do godot como um plugin gdscript - ainda não é interativo o suficiente :)

Vou publicá-lo no github quando eu conseguir que a GUI básica funcione interativamente para comunicar as ideias de design :) Hoje eu consegui carregar o gui da folha de eventos como uma guia - inspirando-me no plugin sketchfab:

Talvez a folha de eventos deva ser acessada de outro lugar?

Irá postar mais screenshots de atualização e eventualmente um link para o github - atualizei meu primeiro post com algumas notas de planejamento e links para demonstrações online de outros mecanismos de folha de eventos

• Vocês conhecem uma maneira fácil de exibir ícones do nó godot dentro do nó do rótulo de texto rico via bbcode?
  Na minha maquete anterior, usei as tags [img] - mas essa é uma abordagem muito ruim, pois exigirá que eu baixe todos os ícones de nó que o editor godot usa e armazene-os com o complemento

• Também estou lutando para descobrir como registrar um novo recurso de tipo de script de folha de eventos por meio da API de complemento

@blurymind muito bom! Agora está mais legível. Precisamos pensar em como a lista de ações será exibida para o usuário.

Uma coisa que gostei do antigo Construct Classic foi a opção de editar os valores da folha de eventos sem abrir a ação ou a condição, mas clicar duas vezes sobre o valor para editá-lo:

Se alguém quiser adicionar isso (por conta própria através de um plug-in, addon, gdnative, etc.), não há mal, não há falta. Caso contrário, concordo que o script visual pode ser melhorado tornando isso supérfluo. GDscript é fácil, muito fácil. E provavelmente mais útil para ensinar as crianças do que alguns scripts visuais estranhos (mesmo baseados em plantas). Godot não precisa emular todos os outros sistemas em seu núcleo. Deixe o software manter seu foco e não se tornar um "pau para toda obra, mestre de nada" devido ao foco difuso.

@spyres depende se @reduz e a equipe godot querem atingir alunos mais jovens nas escolas.
Pessoalmente, acho que podemos substituir o constructo nas escolas por godot completamente.
O sistema de blueprint atual não vai funcionar para isso. É mais complicado de usar do que o gdscript e, como mencionado anteriormente - não é a melhor maneira de introduzir alguém aos paradigmas de programação - porque tem seu próprio conjunto de regras.
O objetivo disso não é substituir o gdscript ou o sistema de blueprint atual - mas pelo contrário - dar às crianças uma maneira de aprender o gdscript ajudando-as. É assim que a yoyo games usa seu sistema de script visual DnD para introduzir gradualmente os não-programadores ao Gml btw.
Não acho que haja nenhum mal em ter um sistema de script visual que seja mais acessível a não programadores e seja melhor projetado para fazer a transição para o gdscript. Por que você?

Estou tentando torná-lo um addon, mas estou atingindo algumas limitações em termos de falta de documentação ou API. Quero registrar um novo tipo de recurso de script e quero injetar meu editor de folha de eventos dentro da guia de scripts - para editar arquivos myscript.es.
Alguém sabe como isso pode ser feito - ou tem um exemplo disso sendo feito?
Ter sua própria guia é feio, e não seguir o design original do editor - quero que meu complemento seja integrado de uma maneira que seja perfeita com o design do godot.

@DrZanuff Godot tem uma maneira de listar todos os métodos que existem em um nó, mas ainda não tenho certeza de como filtrá-los para ações ou condições. Talvez tenha que inventar uma maneira mais centrada em Godot de fazer isso. Ainda estou explorando e estou aberto a ideias :)

De qualquer forma, talvez nunca tenhamos um complemento totalmente funcional. Isso é apenas para explorar a ideia de como isso poderia ser feito de uma maneira centrada em godot aqui - pelo menos por enquanto

A suposição de que o script visual não pode (ou não será) muito melhorado ou que as crianças mais novas não serão capazes de usá-lo, ou crescer em gdscript a partir de construção) parece meio idiota realmente. Especialmente porque o script visual é muito novo.

Se a solução para crianças muito pequenas _(que eu nunca vi os desenvolvedores mencionarem como um demográfico primário para Godot)_ for tão grande, deixe-as usar construção ou alguma outra solução infantil focada e depois passe para uma programação real via GDscript quando eles estão prontos.

Se você deseja criá-lo como um complemento e oferecer suporte a esse complemento, faça bullying por você. Mas como algo duplicado, inchando o núcleo e (provavelmente) desperdiçando tempo de desenvolvimento oficial limitado com suporte futuro, integração, etc., _ não, obrigado. _

@spyres você é um desenvolvedor? Ou um professor? Você realmente usou o script visual do Godot em algum de seus próprios projetos? Em caso afirmativo, como pode ser melhorado para ser uma ferramenta melhor para ensinar as pessoas sobre programação?

@blurymind Acho que sua ideia é boa. Além disso, você parece já ter uma visão bastante sólida disso.

Mas, acho que "substituir o constructo nas escolas por Godot" não é uma razão válida para ter esse recurso. Não me lembro de Godot ter visão para substituir outros motores como Unity, Unreal, etc. Godot não está tentando esmagar outras ferramentas. Se o motivo é aumentar a produtividade, estou de acordo.

Também concordo com @spyres que a Godot não precisa segmentar o segmento educacional. Se Godot não é adequado para ser uma ferramenta de ensino de programação (nem mesmo de desenvolvimento de jogos), que seja. Nunca quis ser em primeiro lugar. Mas se alguém puder de alguma forma usar/transformar o godot para ser uma ferramenta de ensino de programação, não tenho nenhum problema com isso.

Ainda assim, acho que esta folha de eventos é uma ideia interessante de se ver.

@blurymind Acho que você está esquecendo que Godot não é uma ferramenta de ensino, Godot é um mecanismo de jogo. Se você quiser implementar algo como construir como um módulo externo, tudo bem e depende de você, mas não tente transformar algo destinado ao desenvolvimento de jogos em um brinquedo para crianças. Por que tentar transformar godot em constructo se o que você realmente quer é construir? por que não usá-lo em vez de godot?

@zaniar @ni-code Você está certo. É verdade que, pessoalmente, estou mais interessado em criar uma ferramenta de script visual que seja mais eficiente e clara do que nossa atual abordagem de projeto - uma que seja apenas mais agradável de usar. Eu não gosto de Construct2 - então não é verdade que eu quero transformar Godot nele. Como mencionei anteriormente, acho seu design e peculiaridades muito ruins. É por isso que é tão frustrante para mim que os únicos lugares para encontrar folhas de eventos não sejam tão bons quanto Godot.

Sinceramente, acho que, mesmo que os projetos sejam aprimorados, eles nunca serão tão claros e tão rápidos de construir quanto uma folha de eventos - nesse sentido, as folhas de eventos são uma ótima ferramenta para prototipagem rápida que muitas vezes é subestimada. Mas os títulos criados pela Clickteam fusion devem falar por si. Alguns podem vê-lo como um brinquedo - mas para mim é divertido construir a lógica do jogo dessa maneira :)

Como alguém que usou tanto o construct2 quanto o Fusion, adoro a abordagem da folha de eventos e vejo na api do godot um belo candidato a um sistema de folha de eventos - sem as falhas dos mecanismos que o inspiram.
O design de aninhamento de nós de Godot funcionará muito bem com isso, combinado com a clareza do gdscript para expressões.
Não estou esperando que ele seja implementado no godot, mas continuarei compartilhando o progresso do plugin aqui, com a esperança de obter feedback útil e ajuda com a API. Alguns dos desenvolvedores aqui usaram Construct2 e conhecem Godot muito bem, então boas idéias podem surgir da discussão.

Na verdade, tenho uma ideia para o sistema de folha de eventos que nos dará uma ligeira vantagem sobre apenas usar gdscript - mesmo para usuários experientes. Deve ser usado com gdscript, não em vez de gdscript - não se esqueça disso

Estou ansioso para as inevitáveis ​​melhorias do Visual Scripting que serão (por serem totalmente integradas/suportadas) mais úteis (e provavelmente mais populares) do que qualquer plug-in centrado em crianças "construct-lite".

@spyres Por favor, mantenha o tom civilizado. Você não precisa dizer aos outros que suas suposições são " burras " ou que o plug-in em potencial que eles estão investindo (gratuito!) no trabalho será apenas uma coisa " centrada em crianças de construção janky-lite ".

Claro, as pessoas são livres para gastar seu tempo (inútil, eu sinto que isso pode ser) como quiserem, por mais que não seja propício para o design central de Godot.

No interesse de civilidade (embora "kiddie centric" é _exactly_ o que o OP está pedindo aqui!) Vamos com descrevendo folhas do projeto do estilo construção como desajeitado, não focada em núcleo demográfico, algo de Godot que se esperava não vai perder tempo desenvolvedor do núcleo , etc

Por que se preocupar em recriar a construção dentro do Godot _quando o mecanismo de construção real já fornece essa funcionalidade de maneira robusta?_

A demografia infantil de 7 anos está realmente gritando por esse tipo de duplicação?

@mhilbrunner respondendo seu post é como responder a um troll de 7 anos :D
Ele diminuiu a maioria dos meus posts aqui - todos os polegares para baixo na verdade são dele.
Parece não haver sentido em discutir com ele, porque ele realmente não responde às perguntas - eu fiz algumas perguntas válidas que poderiam me ajudar a obter algum feedback. O que eu tenho em troca é mais do mesmo

O github tem uma maneira de impedir que as pessoas postem se forem abusivas?

Uau, embora eu certamente tenha questionado algumas idéias, eu _nunca_ realmente _Isso_ é muito abusivo, eu diria.

O que a duplicação da funcionalidade do construct dentro do Godot forneceria que já não é bem fornecida pelo er... Construct.

Existe uma vantagem legítima em duplicar o conjunto de recursos do Construct (provavelmente de uma maneira menor) em godot simplesmente para atrair crianças de 7 anos?

Por que você não usaria apenas o construct? A configuração deles (que alguns parecem ansiosos para duplicar) realmente está faltando?

Existe alguma razão legítima para supor que as crianças não podem migrar para o gdscript ou script visual depois de superar a construção?

@spyres você está usando termos geralmente ofensivos para descrever pessoas que usam folhas de eventos e folhas de eventos.
Eles não são "crianças" e o sistema não é "incompetente". Tenha algum respeito por essas comunidades pelo amor de Deus. De onde vem essa atitude elitista?

Construct2 tem muitos programadores javascript muito experientes - o que deveria ter sido evidente para você se você se deu ao trabalho de realmente ler o que escrevo e seguir os links que forneci. Alguns dos addons que eles fizeram integram-no com motores 3D como babylon e three.js mesmo assim, sim, desenvolvedores experientes também gostam de usar folhas de eventos e fazer jogos com isso.

Os jogos feitos pela fusão da Clickteam superam em muito os jogos feitos pela Godot no Steam, no kickstarter e até nas lojas de aplicativos em termos de número e receita que eles geram. Esse é um mecanismo inteiramente baseado em folha de eventos, usado por pessoas de 10 a 80 anos. É uma mistura de todas as idades. Alguns dos usuários são cineastas, outros são artistas - pessoas com empregos que gastam dinheiro com licenças, exportadores e assim por diante. Caramba, ganhei mais dinheiro vendendo coisas em sua loja de ativos do que qualquer outra coisa a ver com godot até agora.
Aqui alguns exemplos - Alonso Martin, cineasta decide fazer um jogo:
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia
Um bando de 7 anos faz um jogo
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game

dê uma olhada aqui
http://indiegames.clickteam.com/
Essas crianças de sete anos com certeza sabem fazer jogos e ganhar dinheiro eh
https://thinkgaming.com/app-sales-data/publisher/3107/scott-cawthon/

Meu ângulo de vender isso como uma ferramenta melhor para o ensino de programação não deve ser uma razão para rotulá-lo erroneamente assim. Com uma demografia mais ampla de usuários, você acaba com mais pessoas fazendo jogos com o mecanismo. Isso não deveria ser óbvio? Por que isso não é óbvio :D

Quantas vezes você precisa que eu repita que não estou pedindo uma cópia carbono do Construct2? É como se você repetisse a mesma mensagem sem realmente ler nada. O que estou propondo é uma folha de eventos centrada em Godot, não uma cópia daquela em construct2

Agora, como a leitura de seus posts sobre o sistema ser "insatisfatório" vai me motivar a fazer um addon gratuito para o Godot? Pense um pouco sobre isso

Uau! Deslocamento de postes apesar de...

Deixe-me esclarecer.

Construct é muito bem sucedido no que faz. Portanto, a necessidade (?!) de enxertar / duplicar seu conjunto de recursos (no todo ou em parte) em um mecanismo totalmente diferente (sem nenhum benefício discernível) me escapa.

As questões relativas aos benefícios reais permanecem as mesmas, embora alguns possam (inexplicavelmente) considerá-las "ofensivas".

A sugestão de que um complemento enxertado em um mecanismo completamente diferente será de alguma forma melhor do que usar o construct? De que ter algo incorporado (mesmo via add-on) é algo que esperamos que muitas pessoas usem na solução robusta (ou seja, construção)? Eu duvido disso.

Mas ei, por que parar por aí? Existem excelentes ferramentas (além da construção) para ensinar programação às crianças (por exemplo, Scratch , Styncl , code.org etc.) Por que não incorporá-las ao Godot também!

Ou talvez não... ;-)

Existe alguém que tenha usado o script visual de Godot e parece tão bom que ele está usando apenas o script visual de Godot?

@Zonacas Eu não acho que o Visual Scripting de Godot esteja maduro o suficiente para isso ainda, mas posso estar errado. Tenha em mente que o VS só foi lançado por dois meses neste momento. :)

@Zonacas tente olhar para o canal VS no servidor do discord, eu vi um ou 2 autoproclamados não programadores que gostaram (mas também está cheio de programadores que dizem que não é bom para não programadores).

Olá a todos, tenho uma atualização de progresso no meu complemento de prova de conceito.

Aqui está um novo gif para você:

Algumas informações sobre o que ele faz - Basicamente, a folha de eventos é feita de células. Uma célula pode ser para condições (getters/expressões) ou ações (setters que podem ser alimentados com getters/expressions).
No lado da GUI, a célula de evento é criada por meio de um nó richtextlabel e bbcode que é gerado a partir do gdscript. Quando você clica duas vezes nele, o richtextlabel se transforma em um nó de caixa de edição contendo a expressão gdscript real.

Portanto, uma célula da folha de eventos tem 2 modos:

• modo de edição - nó textEdit que pode ser digitado com gdscript.
  A única diferença é que o usuário não precisa digitar If/else/while - que é sensível ao contexto do contêiner pai, conforme visto na captura de tela. Cada linha é uma nova condição, então se o usuário não iniciou a linha com "ou" ou qualquer outra coisa, o analisador automaticamente sabe que uma nova linha tem o pretexto "e"

Quando clicado, muda para o modo de visualização.

• modo de visualização - rótulo richtext - Ao alternar para o modo de visualização, um bbCode é analisado a partir do gdscript que está no modo de edição e apresentado por meio de um rótulo richtext interativo. Além de ser interativo e fácil de alterar, o objetivo é apresentar o código gdscript de forma mais clara. Isso significa mostrar apenas o nome e o ícone do nó (não o caminho inteiro) e se livrar de algumas palavras, quando for óbvio (como get_ e set_). Como cada parte clicável é na verdade uma tag de URL, ao passar o mouse sobre o nome de um nó, por exemplo, o usuário pode obter algumas informações, como o caminho completo do nó.

Sobre o menu Adicionar nova condição/ação:
Isso é o que cria uma nova linha de código gdscript para uma condição ou ação. O que é ótimo é que ele permite que você navegue facilmente por todos os nós dentro de uma cena e seus métodos - ele funciona de uma maneira invertida de como o autocompletar funciona no editor do gdscript. Ele mostra todos os nós e todos os seus métodos setter, getter ou ambos. Você pode restringir o que deseja por meio de um filtro.
Se callend de uma célula de condição, este menu mostra apenas os getters, se chamado de uma célula de ações, mostra os métodos setter e getter.

O que vem a seguir para fazer isso funcionar:

• Eu preciso descobrir uma maneira de arrastar células - para poder alterar facilmente a ordem dos eventos.
• Também copiando e colando no modo de visualização.
• Em seguida, tenho que criar um editor de expressões que aparece quando um tipo específico de url de célula do modo de visualização é clicado
• descobrir como lidar com itens de espaço reservado. Eu pensei em colocar comentários, mas infelizmente Godot não suporta comentários inline : https://github.com/godotengine/godot/pull/18258 então eu posso ter que voltar para a prancheta naquele

A ideia está evoluindo para algo mais do que apenas uma ferramenta de ensino. Acho que posso oferecer algumas funcionalidades úteis que economizam tempo para pessoas que já conhecem e amam o gdscript, mas levarei mais tempo para desenvolver isso a um ponto em que eu possa apresentar a você como.

Obrigado a todos pelo apoio

Uma boa ideia para um plugin. Mas manter oficialmente dois sistemas de scripts visuais seria uma dor e pouco ganho.

XKCD: Padrões

Não vejo por que isso não pode ser um complemento/plugin real, em vez de apenas uma prova de conceito. Nem tudo precisa ser empacotado com o mecanismo por padrão. Quero dizer, não é por isso que o GDNative foi desenvolvido?

@Megalomaniak Isso é verdade e acredite em mim quando digo que se eu tivesse conhecimento suficiente sobre a API do Godot, eu reescreveria isso como um addon gdnative. Mas, mesmo chegando até aqui, tive dificuldades e, na verdade, estou perdendo alguns elementos-chave para transformar isso em uma ferramenta útil real. Eu levantei as questões aqui, mas até agora ninguém realmente me disse nenhuma resposta ou mostrou exemplos:

• Como registramos um novo tipo de recurso de script no editor godot e permitimos que o usuário o anexe a qualquer nó? No momento o addon está operando a partir da raiz da cena e é hacky.
• Como podemos fazer com que godot abra meu gui de folha de eventos - tão integrado quanto o sistema de blueprint atual
• Como fazemos com que o nó editText funcione como o editor gdscript do Godot - habilitar a coloração de sintaxe e o preenchimento automático. Além disso, como damos contexto personalizado?

Alguém com conhecimento de nível muito baixo da API pode fazer isso. Esse tipo de coisa não está na documentação - também não há exemplos existentes.
Eu tenho as ideias de design, mas não a imagem completa para realizá-la ainda

Até agora, posso continuar avançando nos conceitos de design e aprender mais sobre a API, mas não posso garantir com firmeza que isso possa ser transformado em um complemento que realmente funcione totalmente. As pessoas parecem gostar muito até agora

Para coisas assim, prefiro honrar os desejos dos desenvolvedores:

https://godot.readthedocs.io/en/3.0/about/faq.html

Tenho uma grande ideia que tornará Godot melhor.

Sua ideia certamente será ignorada.

Vamos fazer isso porque vai deixar Godot melhor
Vamos fazer isso em Godot porque outro motor de jogo faz isso
Vamos remover isso porque acho que não é necessário
Vamos remover a desordem e o inchaço e deixar Godot mais bonito
Vamos adicionar um fluxo de trabalho alternativo para pessoas que preferem

@spyres Na verdade, estou fazendo isso e buscando suporte de outros usuários do godot na API sobre coisas que não consigo encontrar na documentação - tentando fazer uma contribuição ao godot.
O que você está fazendo aqui?

Você é a única pessoa que despreza tudo e repete as mesmas coisas em todos os posts. Isso é muito parecido com o que um troll faz, você não concorda? Você está acompanhando a conversa para longe de discutir as ideias de design

@blurymind A "contribuição" de um homem é a distração de outro homem (ou motor). Desculpe que o conceito de opiniões divergentes (mesmo aquelas dos desenvolvedores que eles acharam importante o suficiente para postar como parte dos documentos oficiais) parece tão censurável para você.

Boa sorte com seu complemento. :sorriso:

@spyres, mas você realmente fez alguma coisa? Você já criou um addon para Godot? Você usa Godot?

Por quê você está aqui? Você não está tentando contribuir para a discussão

@blurymind Uau, opiniões diferentes te incomodam tanto assim? Que triste para você.

@spyres todos aqui podem ver sua opinião - você está enviando spam para o tópico. Cada polegar para baixo aqui é seu. Não é a opinião - é o spam. Pelo menos nitpick em design e coisas específicas? Eu fiz algumas perguntas antes - você nunca respondeu nada

Para ser claro, eu apoio totalmente qualquer pessoa que use seu tempo, no entanto, deseja criar algo assim como um complemento que pode ser pacificamente ignorado por pessoas como eu, que não encontram valor nisso.

Como um fluxo de trabalho alternativo realmente integrado ao Godot Core? Ugh, por favor, não. Estou com a opinião devs desse tipo de coisa.

@spyres sim, você já disse isso. Role para cima e leia mais 5 vezes. Há um de vocês .. mas tantas vezes

@blurymind E de alguma forma parece incomodá-lo? Uau, opiniões alternativas e tal.

Suponho que _você_ não repetiu nada correto? (Quem é você, Por que você está aqui, Justifique-se dagnabbit!). :sorrindo:

Eu acho que alguns comentários de documentação oficial escritos pelos desenvolvedores causaram um pouco de indigestão, hein?

sim, é super emocionante

@blurymind Obrigado, abraços a todos então!

Eu realmente com você a melhor sorte implementando isso via gdnative, e nesse ponto ele estará lá para aqueles (muito poucos, eu suspeito) que desejarão algo não oficial assim.

No entanto, se você não conseguir obter as informações, a assistência necessária para que isso aconteça, talvez seja hora de reavaliar o quanto a disponibilidade desse idioma alternativo realmente significa para você.

@spyres Por favor, pare de

@mhilbrunner Se minhas opiniões divergentes o incomodam, clique no meu avatar e selecione "bloquear usuário". Qualquer dor causada pela leitura de meus comentários cessará imediatamente. :risonho:

@spyres Observei em postagens anteriores que este complemento visa usar o gdscript, não servir como uma linguagem alternativa. E sim, ninguém está moderando este rastreador, parece

Bem, quanto mais cedo você terminar, mais felizes estaremos todos, certo ? Tenho certeza de que será ótimo para algumas pessoas que realmente querem, assim como muitos outros complementos. É difícil ver isso causando muita dor indevida, então, por favor, cuide-se e não deixe que a falta de informação/progresso o derrube. Tenho certeza de que, se houver uma onda esmagadora de apoio público, em breve você terá todas as informações/ajuda de que precisa.

Nas palavras de um homem sábio, "Não se preocupe, seja feliz". :sorrindo:

Ou "É tudo diversão e jogos até que alguém dê um tiro no olho!" (hum, espere, eu não acho que era a citação que eu estava procurando...)

UAU. Vou ser honesto, isso é incrível!

Quando li seu post pela primeira vez, concordei, mas fiquei um pouco preocupado que haveria uma grande discussão, mas quando você apareceu e mostrou que não estava latindo e nem mordendo e, na verdade, comecei a desenvolver um addon, fiquei impressionado.

Eu AMO a interação com o GDScript, pois esse era um grande recurso no estúdio de criação de jogos (intercambialidade de scripts visuais e adequados) que não era realmente viável com um sistema baseado em nós.

Quando isso terminar, vai ajudar uma tonelada de pessoas

Sou usuário do Construct nos últimos 6 anos e posso dizer com certeza que é a melhor maneira de abordar scripts visuais mais rápidos e simples.

Excelente ideia!

Isso vai ser muito útil. Não vejo a hora de ser lançado!

Ideia brilhante, colabore com a SnailOn.

1. Ele é gênio.
2. Ele usando Godot cerca de 3 anos.
3. Ele usou motores Clickteam desde TGF
4. Candidato ideal.

@boruok Sou fã do canal yt do snailon desde os primeiros dias. 😄 Seus tutoriais me ajudaram a aprender fusão há muito tempo. Ele tem conta no github? Eu adoraria pegar sua mente em algumas coisas.

Aliás, devo admitir que estou inclinado para um menu de clique mais Fusion do que o que o Construct2 está usando para decidir como preencher as células. O menu auxiliar apresentado na atualização 1 é definitivamente influenciado pelo design do Clickteam. Neste addon, você verá que não estou criando uma cópia carbono de nenhum mecanismo, mas sim emprestando idéias que funcionariam melhor para uma abordagem godotesco de uma folha de eventos. Há um pouco de Game maker também - na maneira como o script visual pode alternar perfeitamente para o script real - algo que os usuários mais avançados podem apreciar

Obrigado a todos por acompanhar o progresso neste addon. A reação inicial é extremamente positiva
Isso me motiva muito a continuar levando a ideia adiante, ao mesmo tempo em que tento mantê-la simples e elegante.

Sem comentários embutidos, é difícil manter a alternância fácil entre gdscript e visualscript, mas tenho algumas idéias sobre como superar isso e experimentar - então estou trabalhando nesse caixa eletrônico.
Eu preciso de alguma maneira de definir no gdscript um espaço reservado vazio onde uma expressão é esperada.
Como as expressões retornarão um tipo de valor, pensei em usar apenas o método de conversão de valor em godot para marcar o espaço reservado:
float() ## this will turn into a bbcode item that expects an expression resulting in a float
Mas isso pode ser um pouco feio, pois gerará muitos métodos desnecessários de conversão de tipo de variável dentro do gdscript gerado final

Se godot pudesse fazer comentários embutidos, eu seria capaz de analisá-los para o método que cria bbcode a partir do gdscript. Isso me permitiria alimentá-lo com algumas informações extras

A melhor abordagem realmente é apenas tornar meu maldito gdscript para o método do analisador bbcode mais inteligente - que é o que estou tentando fazer agora

@blurymind eu não sei sobre git-account. btw, ele abriu vídeos novamente. Já enviei algumas pm para ele via, youtube e facebook. Vamos torcer para que ele apareça aqui.

@blurymind Eu apoio isso 100%!
(Desculpe antecipadamente pelo inglês)

Se dermos uma boa olhada na página sobre além do que pode ser usado para trollar as pessoas, é isso que podemos ver:

Os desenvolvedores estão interessados ​​em (por exemplo):

Sua experiência usando o software e os problemas que você tem (nos preocupamos muito mais com isso do que com ideias sobre como melhorá-lo).
Os recursos que você gostaria de ver implementados porque você precisa deles para o seu projeto.
Os conceitos que eram difíceis de entender para aprender o software.
As partes do seu fluxo de trabalho que você gostaria de ver otimizadas.
Partes em que você perdeu tutoriais claros ou em que a documentação não estava à altura.

Tendo isso em mente:

• O script visual atual só pode ser usado se você souber codificar de verdade. E fica muito mais bagunçado do que o código rígido. Quem é que está ajudando? E os projetos também não são tão úteis, a menos que você tenha um conhecimento técnico muito específico.

• As folhas de eventos de nível superior funcionam bem. Como visto com o sucesso de todos os aplicativos mencionados acima. Se bem feito, eles realmente são mais simples de entender e usar para não codificadores.

• Por que Godot atenderia a não-codificadores?
  Vejo muitos usos para isso para muitas pessoas que trabalham em projetos profissionais.
  Em muitos projetos, pequenos, médios e grandes, uma parte da equipe fará a codificação e outra fará sua própria coisa. Música e sons, visuais/animações/SFX/UI, design de jogos, escritores, etc...
  Às vezes, são equipes de um homem só, ou pessoas de fora da indústria, como esse cineasta, fazendo um jogo de muito sucesso.
  Algumas pessoas até querem programar, mas não codificar por diversos motivos.
  Por exemplo, problemas como ter dislexia torna o código um pesadelo, mas a programação ainda seria possível por meio de uma abordagem mais visual, como folhas de eventos.
  Na maioria das vezes, essas pessoas têm outras coisas a fazer além de codificar enquanto produzem coisas necessárias no jogo.
  Uma folha de eventos permitiria que um grafista, um designer de som ou de jogos testasse ou implementasse seu trabalho com muita facilidade sem mergulhar no código bruto.
  Também permitiria uma prototipagem super rápida, para testar a prova de conceito de alguém. Jogue um monte de imagens, clique aqui e ali um pouco e você pode verificar se sua ideia é divertida agora. Mesmo bons programadores e grandes nomes/estúdios usam as coisas mais simples possíveis para iterar no início de um projeto.
  Mais comentários e discussões sobre tudo isso aqui , e concordo plenamente com o OP.
  (O Github não é o melhor lugar para feedback sobre isso, as pessoas que vêm aqui geralmente são profundas na codificação e não conseguem ver a necessidade, apesar de serem uma minoria.)

• Conclusão: Dar às pessoas ferramentas simples e eficientes para interagir com Godot seria uma dádiva de Deus em muitos níveis diferentes para um grande número de adultos sérios que trabalham em projetos profissionais.
  (Não apenas crianças e escolas, mesmo que isso os ajudasse também.)

• A propósito, existe outra ferramenta chamada GDevelop que usa folhas de eventos se você quiser ver mais exemplos. A interface anterior (versão 4) é muito boa, a atual (v 5) é meio ruim, o aplicativo tem algumas boas ideias, mas algumas desvantagens, e sua direção ainda é um pouco incerta, mas pode lhe dar algumas idéias, ou pelo menos outro ponto de comparação.

Parabéns pelo trabalho já feito, por se manter positivo e motivado apesar de certas reações, e por acreditar na sua ideia. Também confirmo que seria de fato crucialmente útil e resolveria grandes problemas para mim.

@TheGoklayeh Obrigado pelas amáveis ​​palavras de encorajamento. Sei exatamente o que você quer dizer. Como observado anteriormente aqui, os jogos indie bem-sucedidos da fusão Clickteam superam em muito os jogos indie bem-sucedidos da Godot.
Jogos sendo publicados, número de vendas no Steam e títulos móveis e kickstarter atingindo seu objetivo.
Isso deve ser prova suficiente de que artistas e designers profissionais o usam - não apenas "crianças"

Sobre o novo IDE do Gdevelop, acho ótimo, mas não completo. Uma jogada inteligente que o desenvolvedor principal fez foi portar o ide para javascript - tornando-o muito acessível a desenvolvedores não C++ para contribuir. Na verdade, tenho contribuído para isso com pequenas correções até agora - apenas para brincar e aprender. Este fim de semana vou tentar fazer alguns passos para integrar o piskel nele 😃 - se tudo estiver ok, pode estar recebendo um editor de pixel embutido.
O desenvolvedor principal recentemente fundiu uma contribuição de outro desenvolvedor - adicionando suporte de ossos de dragão fora da caixa. Se você quiser, experimente a versão mais recente do github - não a demonstração online. Tem as mercadorias
https://github.com/4ian/GD/releases

Eu também ainda estou fazendo um progresso lento neste addon. Algumas coisas precisam ser refatoradas antes que eu possa avançar com isso.

Talvez seja uma boa ideia obter todos os usuários do fusion e build2 usuários que também usam godot aqui. Mostre-lhes este tópico e peça-lhes feedback sobre o design.
Snailon ainda não entrou em contato comigo - mas sim - ele é um programador muito experiente quando se trata de folhas de eventos. Eu não sabia que ele é um usuário godot também.

Isso parece incrível! Obrigado por desenvolver/empurrar isso, blurymind.
Eu fiz gamedev por mais ou menos 23 anos, basicamente tentei de tudo - todas as ferramentas/motores populares de gamedev, linguagens de programa, etc. e eu prefiro folhas de eventos no final do dia porque me permite terminar os jogos. :)
Tê-lo em uma abordagem listada de cima para baixo dividida entre condições e ações o torna mais ordenado e conciso do que qualquer outro sistema. Como sou mais visualmente orientado, ter uma estrutura rígida vertical/horizontal me permite fluir pelo programa/eventos à vontade.
Outros scripts visuais que requerem conexões de espaguete são muito confusos e distraem - os detalhes visuais são espalhados em uma estética barulhenta que quebra a concentração para pessoas com mente visual (as mesmas pessoas que o script visual deve ser direcionado).
As folhas de eventos são as melhores para mim. Passei 23 anos, usando tudo - blitzbasic, gamesfactory, unity, c++, javascript, etc, e tenho certeza disso - adoro folhas de eventos!!

Só queria entrar em contato, a edição de Blueprints / estilo de nó é extremamente difícil de organizar / evitar "código de espaguete". Para quem pensa que é o mesmo que os eventos de estilo Clickteam/Construct/GDevelop, sinto muito, mas eles são radicalmente diferentes, e as folhas de eventos são objetivamente melhores (os jogos são baseados em regras IF/THEN por natureza, e você pode fazer a transição muito mais facilmente de eventos para código, mas eventos em geral são mais rápidos do que codificar a lógica do jogo de qualquer maneira).

Tenho certeza de que há momentos em que a edição baseada em nós é útil, mas a edição baseada em eventos rapidamente se tornaria a opção preferida se fosse incluída no Godot Visual Scripting básico.

@bigelod @prominentdetail obrigado por fornecer mais feedback sobre o que torna as folhas de eventos tão boas - não apenas para aqueles que estão aprendendo a codificar - mas também para programadores mais experientes.

Eu acho que você está absolutamente certo. Assim como @prominentdetail , comecei com as planilhas de eventos em fusão e depois passei por muitos mecanismos diferentes. Aprendi python, depois gdscript, depois javascript. Ainda as folhas de eventos me atraem como uma maneira preferida de prototipar jogos - é essa clareza extra que eles adicionam à lógica do jogo

Também estou percebendo tendências na comunidade de mecanismos de jogos da folha de eventos atm, que Godot poderia realmente aproveitar para expandir sua base de usuários:

• A comunidade de desenvolvedores que usam folhas de eventos está ansiando por um mecanismo 3D que use folhas de eventos. Ambas as comunidades do clickteam fusion tentaram integrar isso como um addon (firefly) e Construct (vários plugins tentados) - mas esses addons não forneciam nenhum recurso de edição de cena 3d - eles eram hacks para fazer com que as folhas de eventos funcionassem com mecanismos 3d - coloque 2d no topo editor de motor não projetado para jogos 3D. Você só pode construir uma cena 3D com lógica de evento nelas - tornando difícil colocar objetos, definir materiais, etc.
• Tanto os programadores experientes quanto os experientes ainda gostam de folhas de eventos e as usam para prototipagem - não apenas para ensino.
• Muitas equipes independentes usaram com sucesso (e ainda usam) planilhas de eventos para criar títulos de sucesso - kicktarter, steam e outras plataformas - mas muito poucos são projetos 3D por causa do primeiro ponto

Agora, fazer isso funcionar como um addon no godot é complicado, por causa de algumas coisas no mecanismo que não tenho certeza de como acessar. A implementação atual que tenho é rápida e confusa e não faz nada além de demonstrar partes de como o gui pode ser feito. Vou tentar deixar ele em um estado mais apresentável e postarei aqui

Em uma nota lateral, consegui que o Piskel fosse empacotado e integrado ao Gdevelop. Isso estava me mantendo ocupado nas últimas semanas. Pode experimentar se quiser :)
Eu tenho observado como as folhas de eventos são feitas no gdevelop também

@blurymind Ok, vamos apenas dizer que tentei ignorar este post aqui, porque não gostei da ideia de dois Visual Scripts.

Mas finalmente foi o suficiente, acho que finalmente é hora de começar alguma discussão. Acredito que você deve ter usado os documentos para construir a GUI. Mockup é um trabalho muito bom, eu queria perguntar se existe um repositório que eu possa ver um pouco o código. Provavelmente pode ser capaz de fazer algo para torná-lo mais parecido com o EventSystem e mais viável.

Eu estava planejando fazer algum trabalho no atual sistema de Visual Scripting. E quando encontrei o GDevelop e gostei, vim aqui perguntar. Depois de uma hora de leitura a conclusão é clara, precisamos encontrar um meio-termo.

Manter dois sistemas de Visual Scripting diferentes simplesmente não é possível, um deles tem que morrer. Mas ninguém, incluindo eu, quer se separar da estrutura do nó Blueprints.
Mas este EventSystem é muito delicioso (pelo menos para prototipagem básica) para não comer.

Eu queria que o VisualScripting fosse mais uma ferramenta de prototipagem. Recursos limitados não importam se podem realmente aumentar a base de usuários.
Mais usuários também equivalem a mais doações, se ninguém notou isso antes, então deve ser considerado.

Mas Blueprints é uma ferramenta de nível industrial, então tem seus usos e pode trazer o peixe maior para Godot, o que também é importante para Godot. E eu disse que talvez não saiba muito sobre isso também.

Então a pergunta é simples, o que fazer? - Escolher os dois não é uma possibilidade.
Mas um híbrido pode tornar Godot mais popular.
Como você tem experiência com ambos os estilos de Visual Scripting, pelo menos mais do que eu. (Eu sou mais um codificador do que um artista, então gosto de codificar meu caminho) Por que não tentar encontrar uma solução.

Isso provavelmente atrairá mais pessoas do que apenas o EventSystem sozinho poderia. E manter o sistema de nós ativo também será uma boa jogada.

E daí se nenhum meio-termo pode ser alcançado? Algo vai simplesmente morrer. Não importa o que seja.

Pessoalmente, eu poderia votar no Blueprints porque tenho experiência anterior com ele e gostaria que o peixe maior Unreal fosse comparado.
Mas apenas para comparação, peguei o GDevelop em menos de 15 minutos. GDScript em poucas horas em dias separados e Blueprint o dobro do GDScript com certeza.
Embora também mostre meu nível de experiência como programador.

Eu simplesmente não consigo decidir. Aqui veja.

1. Unidade: 4011
2. Irreal: 316
3. Criador de jogos: 274
4. Construção: 223
5. Godot: 75
   _Lista do tweet do Reduz de número de jogos por engine no Global Jam._

Quero Godot no topo. Então, espero que algum amor VS ajude a conseguir isso.
Mas Unreal + Godot + GameMaker + Construct ainda não funciona. Mas torna-o número 2, pelo menos.

Estou confuso como o inferno o que planejar para o futuro do Visual Scripting de Godot. Porque esperar no sistema atual ou tentar melhorar algo que está quebrado não vai ajudar.

"EventSystem é como programar com Scratch em algum nível. Enquanto o Blueprint é completamente único, mas é mais poderoso que o EventSystem, o EventSystems fica mais confuso com a profundidade e tem menor legibilidade."

O que?? É exatamente o oposto se você tentar o sistema de eventos do Construct, incluindo outras folhas de eventos e usando grupos.

O melhor sistema de nós sempre será um espaguete de código comparado a um EventSystem médio.

@bigelod É verdade que não deve ser dito assim. Achei parecido. Eu escrevi esse comentário durante um período de 2 horas enquanto aprendia EventSystems. Desculpe por isso vai corrigi-lo.

Sim, eu sei que o melhor são os projetos e é simplesmente incrível ter algo assim, mas um sistema de eventos adiciona coisas mais amigáveis ​​para iniciantes. E também ajuda no aprendizado de programação.

@swarnimarun muitos anos atrás eu lancei as folhas de eventos para os desenvolvedores godot neste mesmo rastreador. Mas eu não fiz um grande trabalho naquela época e já havia mais suporte para blueprints, porque muitos usuários do godot também eram ex-usuários do Unreal/Unreal. Blueprints já venceram e agora estão em Godot.

Agora, muitos usuários que realmente vêm de mecanismos como clickteam fusion, game maker e construct são a favor de folhas de eventos e não gostam muito de usar blueprints. Eles dirão o oposto do que você está dizendo e explicarão o que já foi explicado - por que os blueprints são confusos quando comparados a uma folha de eventos e até scripts. Eu também já fiz.

Inferno, mesmo ao olhar para outros fóruns de mecanismos de programação visual, você pode ver as reações negativas a qualquer novo mecanismo de sistema de blueprints:
https://rpgmaker.net/forums/topics/23922/?post=857285#post857285

Agora, no final do dia, não vejo uma razão pela qual ambos os sistemas não possam existir. Eles podem trabalhar juntos - da mesma forma que os blueprints podem trabalhar juntos com nós gdscript.

Na verdade, em um mundo ideal, você gostaria que as folhas de eventos construíssem e prototipassem rapidamente com lógica granular e planos para organizá-los em máquinas de estado.
Por quê? Porque ambos os sistemas têm prós e contras.

Os projetos de Godot podem rapidamente se tornar uma bagunça quando você começa a fazer uma expressão simples com nós. Essa mesma expressão pode ser muito mais clara em uma folha de eventos ou em um script.

Projetos de código aberto são democráticos - quanto mais uma comunidade apóia uma ideia, mais provável é que ela se torne real. Mas isso não significa que outra ideia deva ser eliminada. Ambas as ideias são amplamente apreciadas ou não.

Todos aqui devem perceber que, tanto com as folhas de eventos quanto com os projetos, eles estarão programando do zero. O mais importante é a clareza com que o sistema permite que eles estruturem sua lógica. Com os blueprints, a ordem de execução pode se tornar uma bagunça difícil de depurar. Também são necessários muito mais cliques e etapas para configurar quando comparado a uma folha de eventos. Este é meu argumento principal aqui - tanto para desenvolvedores profissionais quanto para fãs de programação visual. Mas também não podemos esquecer que é uma questão de gosto pessoal. Eu não vou tentar fazer com que os desenvolvedores do blueprint sejam fãs disso. Em vez disso, vou apontar que muitos desenvolvedores de programação visual não gostam de blueprints e preferem folhas de eventos.

A folha de eventos pode usar gdscript para suas expressões e dessa forma realmente ajudar aqueles que vêm de um mecanismo do tipo folha de eventos a aprender muito rápido

Provavelmente os sistemas de eventos podem ser usados ​​como uma ferramenta personalizada de criação de nós.

Só gostaria de levantar um ponto sobre algo - honestamente, não acho que as folhas de eventos sejam apenas para protótipos. Acho que parte do problema com a mentalidade de que as planilhas são apenas para prototipagem é porque muitas das ferramentas que as usam empurram o conceito de que torna mais fácil criar coisas sem saber programar. Qualquer pessoa que realmente usa as folhas de eventos por um período considerável de tempo sabe que é uma maneira real de programar que requer a compreensão de conceitos fundamentais de programação e que você pode criar jogos totalmente completos e ricos em recursos com ela.
Parte do problema é que as ferramentas que usam eventsheets tentam minimizar a natureza técnica do mesmo na tentativa de atrair amadores e pessoas sem muita experiência em desenvolvimento de jogos. Isso, na verdade, prejudica a imagem das folhas de eventos e faz com que pareça não ser tão capaz para outras pessoas que têm mais experiência no uso de outras ferramentas. Você também tem muitas pessoas usando folhas de eventos que não têm certeza do que estão fazendo porque foram informadas de que não precisam de nenhum entendimento de programação - portanto, os exemplos que as pessoas criam com ela não a representam muito bem. Isso não significa que não existam grandes exemplos. É só que desenvolveu um certo preconceito.

..Um híbrido pode ser uma maneira de quebrar esse preconceito - permitindo que as pessoas o interpretem de uma maneira nova que talvez tenha um tom mais sério. Você talvez tenha a oportunidade de resolver os problemas dos sistemas anteriores e fazer o híbrido parecer melhor do que os sistemas dos quais foi inspirado.

@prominentdetail levanta um ponto muito bom.
Para complementar, direi apenas o seguinte:
Godot tem a oportunidade de ser o primeiro motor de jogo 3D adequado para suportar folhas de eventos. Isso, por definição, o elevará acima de todos os outros mecanismos de folha de eventos no momento.
Como mencionei antes, isso já foi tentado antes no Clickteam fusion e no Construct - como plugins, mesmo no criador de jogos. E é uma bagunça desajeitada porque os editores desses mecanismos não têm recursos 3D.

Fusão Clickteam - Motor Firefly:
http://clickstore.clickteam.com/firefly
https://store.steampowered.com/app/267655/Firefly/
Está sendo criticado no Steam - pois é um terrível addon com bugs

construção2 - q3d
https://www.scirra.com/tutorials/9456/building-your-first-3d-game-with-the-q3d-plugin

Veja como é complicado configurar uma cena 3D simples sem ter um editor de cena 3D
https://youtu.be/VUGsTdBpRCQ?t=6m17s

IMHO um híbrido soa como uma ótima maneira de obter as desvantagens de ambos.

A abordagem deve ser criar um protótipo de folha de eventos para mostrar seu valor e obter feedback.

Depois de testar o sistema por mais de uma hora, ele parece bastante capaz. E a parte interessante é que provavelmente tanto conhecimento de programação quanto GDscript para criar a maioria das coisas, além de movimento ou coisas mais básicas para as quais recursos auxiliares foram adicionados.

Acredito que pessoas com muito medo de experimentar programação são provavelmente as únicas que podem precisar disso na presença de GDScript.

O Eventsheet pode ser facilmente uma ferramenta para aprender programação, especialmente com a API Godot. Como Godot já tem muitas das mesmas funções auxiliares. Portanto, a implementação do EventSheet pode realmente usar o GDScript.
Porque você pode essencialmente criar um sistema que converte o EventSheet para GDScript e armazena em uma pasta oculta separada, que é atualizada em tempo de compilação e pode ser usada pelo mecanismo. Pelo menos é o que eu descobri. Esta pode ser a solução mais simples.

Embora eu possa ver que ele simplesmente não pode substituir o Visual Scripting/Blueprints porque é verdade, não é muito visual, principalmente o código na coluna, tornando a coisa mais fácil de entender.

Não entendo por que é divulgado do jeito que é, a menos que alguém tenha conhecimento básico de programação usando o EventSheet possa ser mais um aborrecimento.

Atualmente, enquanto aguardo a correção do lado do Visual Scripting, posso tentar criar algo com isso se encontrar tempo. Pode ser divertido (vai me ajudar a aprender a API Godot), tentar implementar uma versão básica do EventSheet. Se eu fizer algum progresso, certifique-se de atualizar aqui.

Como as folhas de eventos diferem das linguagens gdscript/script?

Para iniciantes (coisas que o tornam mais convidativo do que codificação):

• Há alguma representação visual da lógica - usando ícones, cores e o mínimo de texto possível
• As condições são descritas na coluna da esquerda, as ações na direita - Na codificação, tanto as condições quanto as ações estão em uma coluna - tornando mais difícil para alguns distinguir entre as duas ao ler a lógica de outra pessoa.
• Em vez de uma longa seqüência de texto, os métodos são mostrados como palavras simples - em inglês e os sinais de sintaxe são removidos quando possível - remover o ruído da sintaxe torna muito mais claro para ler
• O Intelisense/autocompletion apresenta ao usuário toda a API - para que eles possam ver todos os setters ou getters disponíveis e filtrar os que desejam - invertido para como funciona na codificação IDE - onde o autocompletion é exibido depois que você começa a digitar e toda a API ainda está escondido na documentação do motor. Também tem pistas visuais para encontrar coisas (ícones). Mostra diretamente o tipo de variáveis ​​retornadas ou esperadas
• A lógica de agrupamento permite que você crie sua própria pasta que você pode recolher/recolher e mover. A capacidade de recolher blocos de lógica que você decidiu que deveriam ser recolhíveis é muito bom quando você está organizando seu código e deseja ocultar partes dele nas quais não está trabalhando.

Para usuários mais experientes:

• Você tem a capacidade de alterar muito facilmente a ordem de execução do evento arrastando e soltando células preenchidas. O que isto significa? Ao codificar em um ide- podemos fazer isso por ctrl+x e ctrl+v. Em um sistema de folha de eventos, você pode reordenar simplesmente arrastando e soltando uma linha lógica ou células de uma linha para outra.
• A lógica já estabelecida é visualmente mais clara para encontrar e ler do que o código - novamente devido às pistas visuais e ao layout da coluna esquerda e direita - no topo do código de cores. Isso é realmente ótimo quando você está prototipando algo
• A folha de eventos pode cuidar dos caminhos dos nós para o usuário automaticamente por padrão - portanto, ao montar uma folha de eventos, você não precisará acessar outros nós (pais ou filhos) descobrindo seus caminhos relativos a algo. Você ainda tem a opção de flexibilidade de código, mas o sistema cuida disso para você nos casos em que os nós não vão alterar dinamicamente seus relacionamentos pai-filho.
  Tudo o que você faz para chegar a um nó é selecioná-lo no menu auxiliar. Isso acelera as coisas
• Ainda é muito parecido com gdscript - porque todas as expressões estão em gdscript, mas oferece algumas vantagens extras de produtividade. Eu acho que se for bem feito, isso é algo que os usuários do gdscript vão adorar - experientes ou não.

Acho que se eu tiver que resumir as vantagens:
para iniciantes - o código é muito mais claro à primeira vista, é mais convidativo por causa de como a API do mecanismo é apresentada a eles e a lógica que eles colocam tem dicas visuais (ícones de nós)

para mais experientes - você ainda pode escrever gdscript em todos os campos de expressão, mas agora também pode fazer com que algumas partes do processo sejam mais rápidas (como não precisar navegar para outros nós com código de digitação), capacidade de arrastar a lógica para alterar sua execução pedido ou requisitos (sem necessidade de cortar e colar)

Eu meio que me desviei com algumas coisas de javascript e adoraria se outros tentassem :) Mas voltarei a isso

Eu concordo com @mhilbrunner que deveria ser seu próprio sistema, mas seria ótimo se fosse possível combiná-lo com o sistema de blueprints - da maneira que você pode combinar gdscript com blueprints em um projeto

@blurymind
então, você disse que estava trabalhando em um plugin como esse?
qual o nome do repo? já está no seu github?

posso confirmar que o eventshee é mais fácil de entender, eu aprendi quando eu tinha cerca de 10 ~ 11 anos e tinha um inglês ruim (não sou um falante nativo), enquanto levei muito mais tempo e conhecimento de inglês para aprender como código.

às vezes pode ser mais rápido do que escrever código, quando você se acostumar pode clicar o mais rápido que puder.

a única desvantagem que vejo é que você fica preguiçoso quando precisa aprender código tradicional.

eu estava começando a trabalhar nisso, mas seu código parece ser mais avançado que o meu, receio não poder ser útil, mas gostaria de tentar de qualquer maneira

@Elmapul Não acho que seu repo ajude muito.
E a codificação é muito mais rápida na realidade, se você pensa assim, significa que você não é realmente um bom programador que trabalhou com linguagens como Python.
Embora o EventSheet seja mais útil e tolerante para iniciantes, é isso.

Apenas pensei em mencionar algo - já que me envolvi em várias ferramentas ao longo dos anos ..
Eu sou um artista acima de tudo, então passo a maior parte do meu tempo criando arte. É com o que mais dedico meu tempo e é o que minha mente foi fortalecida para favorecer. Houve muitos casos em que faço pausas prolongadas na codificação, enquanto faço outras coisas artísticas, como freelance, etc.
Como um artista, isso torna difícil ficar afiado em qualquer ferramenta de desenvolvimento de jogos específica que requer padrões de sintaxe específicos - padrões que você deve fazer consistentemente para manter o controle.
Portanto, como artistas, espera-se que os artistas provavelmente não tenham a mesma consistência e prioridade do estilo de codificação baseado em sintaxe.
As folhas de eventos são uma maneira de contornar esse problema sempre que você tira uma licença da programação (porque, como artistas, espera-se que você não gaste tempo contínuo apenas codificando). requer menos memória da estrutura de sintaxe e padrões com os quais você se familiariza na codificação.
Por causa disso, sou a favor do eventsheeting porque posso ser mais produtivo em vez de ter que reaprender constantemente. Eu apenas volto depois de usar minha mente em tarefas e projetos mais artísticos - é um fluxo mental mais fácil.

..Então, basicamente, o que eu quero enfatizar, é que a codificação sim é mais rápida se você dedicar todo o seu tempo a essa ocupação e desenvolver as faculdades mentais que favorecem essa linha de pensamento. Eles simplesmente digitam e vão - eles nunca se afastam desse estilo de vida/comportamento. Para outros, essa nunca será uma escolha realista, pois dedicaram sua vida a outras linhas de trabalho que fortaleceram um padrão diferente de comportamento e prática.
Então sim .. você pode apenas ser como .. oh tanto faz - é ruim ser você .. pena que você não dedica seu tempo a ser um programador em tempo integral, etc. programadores de tempo ou com mente técnica. E claro que é direito do desenvolvedor fazê-lo..
Mas se você quiser convidar outros tipos de indivíduos e fazer com que mais pessoas realmente usem a ferramenta, independentemente de seu potencial técnico, ajuda ser mais aberto às coisas e tentar ajudar aqueles que não são capazes de corresponder ao seu sistema/fluxo de trabalho preferido , etc.
Eu só continuo respondendo, porque sinto que o eventsheet ajuda muito a realmente progredir no desenvolvimento de jogos, sem os efeitos de abandono que ocorrem sempre que uma pessoa vai e volta, etc. Há menos impedindo que uma pessoa como eu desista , e apenas voltando para sua linha normal de trabalho. Então, no final, eu realmente consigo mais, mesmo que demore um pouco mais ou seja um pouco menos impressionante em nível técnico.

@prominentdetail Para todas as intenções e propósitos, o Visual Scripting pode fazer exatamente isso, então não há necessidade de se preocupar quando a implementação estiver mais completa, ela resolverá a maioria dos problemas artísticos de memorização da sintaxe.

Eu usei Blueprints depois de deixar a codificação para uma lágrima inteira e ainda parecia natural e adequado em alguns minutos. Então eu acho que a maioria das pessoas vai ficar bem com isso.

Não importa qual idioma você conhece, scripts visuais com eventos agrupados adequadamente e opções de ação serão mais rápidos do que o tempo necessário, a menos que você esteja digitando nomes de variáveis ​​e tipos de dados muito curtos.

Dito isto, se os eventos fossem mapeados para atalhos de teclado, seria realmente mais rápido "digitar" novamente, mas ainda são os eventos/ações que são mais rápidos do que o código padrão do zero (já que ações e condições geralmente representam uma função complexa inteira , pré-fabricados e flexíveis para a maioria dos usos).

Meu argumento permanece que a folha de eventos é mais fácil de aprender do que
plantas e mais rápido para configurar.

Além disso, é melhor na transição
novas pessoas para linguagens de script reais.

Se bem projetado, um sistema de folha de eventos pode ser tão rápido quanto escrever
gdscript. Se você olhar para o meu gif de maquete - é bastante semelhante a apenas digitar
Código com preenchimento automático ao usar a filtragem do menu auxiliar.

De qualquer forma, ainda estou descobrindo como fazer isso e felizmente Godot
gdscript receberá scripts digitados, o que é mais adequado
para gerar bbcode para minha folha de eventos.
Por exemplo, uma das gentilezas
de um campo de expressão em um sistema de folha de eventos é que ele fornece uma
indicação clara do tipo de variável que espera e até acende em
verde quando válido (ver fusões de clickteam).
Atualmente estou tentando descobrir como fazer um campo de expressão que pode
pegue o gdscript, mas também use o menu auxiliar que fiz. Novamente, isso é apenas experimentar como isso poderia funcionar. Isso está longe de ser algo utilizável atm ..

Em qua, 30 de maio de 2018 22:59 Daven Bigelow, [email protected] escreveu:

Não importa qual idioma você conhece, scripts visuais com
eventos agrupados e opções de ação serão mais rápidos do que o tempo que leva
a menos que você esteja digitando nomes de variáveis ​​e tipos de dados muito curtos.

Dito isso, se os eventos fossem mapeados para atalhos de teclado, seria
de fato ser mais rápido para "digitar" novamente, mas ainda são os eventos/ações que
são mais rápidos do que o código padrão do zero (já que ações e condições geralmente
representam toda uma função complexa, pré-fabricada e flexível para a maioria dos usos).

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

@blurymind Eu recomendo fazer isso com C++, será mais adequado e mais completo usando esse método. Mesmo eu que comecei o C++ há algumas semanas agora posso usá-lo, criar correções de bugs e novos recursos. Então não é tão difícil, provavelmente um pouco. Eu ainda preciso usar o stackoverflow.

Mas se você está procurando ficar e usar GDScript e apenas criar um protótipo para outros converterem em uma ferramenta completa, acho que você deve compartilhar o repositório aqui, não importa o quão incompleto.
Eu ficarei feliz em ajudar. Eu realmente gosto da idéia de EventSystem. E o VisualScripting está atualmente quebrado, então não há muito o que fazer.

O problema é que o sistema de eventos pode ser um aborrecimento de implementar, no Godot você provavelmente o está implementando como uma linguagem de script. Mas essa não é a intenção, é o gerenciador de eventos, portanto, deve ser global ou deve ser capaz de lidar com toda a cena sozinho e, em seguida, usar grupos para separar o trabalho em seções.
Tudo isso é possível e também não deve ser um problema para implementar.

@swarnimarun existe um módulo hello world que cria uma nova interface do
Você pode recomendar algum bom tutorial de introdução que o ajudou?

De qualquer forma, estou pensando agora em alterar a sintaxe do gdscript que o menu auxiliar geraria para o gdscript digitado:
https://github.com/godotengine/godot/pull/19264
Em seguida, isso é convertido em bbcode que renderiza a interface da célula da folha de eventos interativa

Fiz este fluxograma para explicar como funciona no momento
https://www.draw.io/#Hblurymind %2FGodot-eventSheetPrototype%2Fmaster%2FEventSheetDiagramPlan.xml

@blurymind Eu recomendo não fotografar para tutoriais, mas aprender com a prática real ou outros desenvolvedores.
Ninguém realmente me ajudou. Também não precisei de muita ajuda. Eu sou meio bom em pegar coisas, então tudo funcionou bem. Ainda estou apenas começando, isso é comparado aos desenvolvedores experientes.

E eu acredito que você está usando GDScript para fazer toda a programação, ou está usando C++.
Porque não há módulos que permitem fazer qualquer coisa por padrão ou ao iniciar. Você tem que aprender com o que já existe. E crie o seu próprio.

Converter para GDScript tipado deve ser simples se você estiver usando GDScript e se estiver usando C++, pouca portabilidade será necessária. E até onde eu sei, o PR deve ser fundido a qualquer momento. Foi revisado e parece bom. Ainda não experimentei, mas muito animado.

E deixe-me adivinhar atualmente, você está usando GDScript com get_method_list() e get_property_list() provavelmente. Mas eu recomendo que você use sinais e grupos também, os sinais são o mecanismo de disparo de eventos Godot. Eu realmente não sei sobre o EventSystem, mas se você quiser criar algo assim no Godot. Certifique-se de usar Godot ao máximo.

E, por último, se você quiser ajuda, basta me enviar uma mensagem no Twitter ou no Discord. Estarei livre por alguns dias agora.

@swarnimarun Estou usando o gdscript para escrever o complemento, já há algum uso de sinais para coisas como acionar eventos.
Sim, eu uso get_method_list() e get_property_list() para renderizar o menu auxiliar também

Você tem o mesmo identificador no twitter e no discord?

Por enquanto, meu plano é prototipar o gui em gdscript, pois é o que sei mais do que c++.
Eu tenho alguma experiência em javascript também, mas isso não vai ajudar muito aqui

O gdscript digitado é o que os menus auxiliares irão gerar para o modo de expressão - é melhor converter para bbcode para renderizar a interface do usuário com um rótulo de texto rico

@blurymind Isso é muito bom então. Não vi isso nos gifs acima. Então eu assumi algumas coisas.

Quanto ao meu identificador, o do Discord é Swarnim. E acho que você já conhece meu twitter.

@blurymind - Excelente trabalho. Eu literalmente comecei a aprender C++ por causa da melhoria de desempenho no Godot quando comparado ao GDScript (3 a 4 vezes mais rápido, dependendo da sua métrica - veja bunnymark ). Se for possível, eu recomendaria ir direto para o ouro e usar C++ para isso, mesmo que isso signifique um aprendizado no trabalho - valerá a pena. Dê-me algumas semanas para ter uma ideia do C++ e eu também estarei disposto a ajudar, se você quiser.

@colludium A

C++ é uma dor. Confie em mim. Pointer e Refs e compilar código não são nada além de dor. A menos que você queira ter um futuro como desenvolvedor de jogos para uma grande empresa ou esteja na faculdade estudando ou seja tão inteligente que conheça GDScript completamente ou esteja em um nível profissional como programador.

Se você ainda quiser continuar, tente aprender a criar código GDScript dinamicamente enquanto estiver nisso, pois sabemos que criar um sistema de exportação para uma linguagem é uma dor, portanto, gerar diretamente código GDScript tornará tudo muito mais fácil de fazer.
E como um bônus adicional, você poderá fazer uma visualização para visualizar o código e ajudar os novatos a aprender a codificar mais rapidamente.

@blurymind Queria perguntar qual versão do EventSystem você está usando como base porque eu queria criar um protótipo do sistema como um módulo C++, então gostaria de sincronizá-lo com o seu pelo menos no nível básico.

@swarnimarun - obrigado pelo conselho re: C++. Eu sou apenas um programador de hobby vindo do JavaScript, então uma transição de mínimo sofrimento / máximo desempenho é o que estou procurando. Eu não estava ciente das melhorias planejadas para tornar o GDScript muito mais rápido - é bom saber. Agora eu tenho um dilema - C # ou o muito mais fácil de aprender GDScript ...

@colludium Digamos que o que você achar mais fácil, vendo seu plano de fundo como Javascript, recomendo o GDScript, pois ele também possui tipagem dinâmica e, com a digitação estática de entrada, deve ser o companheiro perfeito.
E deixe-me dizer-lhe se você pensa que C++ é uma linguagem que você deve aprender, basta ir e verificar a página Rust vs C++ de algum fórum.

@swarnimarun estou usando o godot 3.0.2
Aqui está o repositório de teste ao qual adicionei o projeto
https://github.com/blurymind/Godot-eventSheetPrototype
Todos são livres para bifurcar ou fazer pull requests 👍

Sinta-se à vontade para começar a escrever um módulo c++. O que tenho funcional até agora é apenas o bloco de construção principal da interface - o contêiner da célula lógica.

O analisador bbcode (ele só usa expressões regulares) e a renderização do menu auxiliar são as coisas que podem ser mais úteis para você, embora eu esteja pensando pessoalmente em mudar como eles funcionam - eles foram reunidos no meu tempo livre entre o trabalho e outros projetos . A coisa é uma bagunça no código atm, então ter programadores mais experientes seria de grande ajuda para mim.

O resto é apenas interface estática colocada em prática para fins de captura de tela

Uma coisa que é muito importante fazer é criar algum tipo de dicionário editável que acompanhe todos os nós na cena e seus caminhos, então ao invés de caminhos de nós estáticos - o menu auxiliar deve gerar gdscript que usa caminhos de um dicionário que atualiza-os automaticamente e se um nó for excluído pelo usuário e não for encontrado pela lógica da folha de eventos - ele pode ser revinculado

De qualquer forma, compartilhe se você tiver algo - mesmo que seja básico. Vou tentar aprender um pouco mais de C++ e me juntar a você para escrevê-lo como um módulo :)

@blurymind Finalmente! alguém que entendeu muito claramente que o script visual do Godot Engine 3.x é inútil (muito complexo para iniciantes, inútil para especialistas).

O sistema de eventos GDevelop é magnífico! é muito útil especialmente para criar modelos completos de jogos 2D e, posteriormente, adicionar recursos mais avançados via GDScript. Isso tornará o Godot Game Engine muito mais convidativo, popular e difundido!

Eu sinceramente amo Godot Engine, mas fazer jogos 2D para dispositivos móveis não é a solução mais fácil e imediata. Poderia oferecer muito mais com um sistema simplificado/sistema de eventos). Godot tem um excelente editor de animação, é muito bom e funcional, só precisa de um sistema mais amigável se eu quiser criar um jogo de plataforma 2D sem ter que escrever milhares de linhas de código (o que acho inútil para criar um super- modelo de estilo mario bros para NES).

Eu acho que a idéia de @blurymind é fantástico! a comunidade Godot cresceu enormemente e estou feliz com isso. Não tenho dúvidas de que o sistema de eventos será implementado com os próximos lançamentos. O Visual Scripting (repito) é absolutamente inútil no momento (não consigo nem encontrar tutoriais e ninguém o usa pelo que posso ver na web).

Saudações, e obrigado pelo seu trabalho fantástico!

@XenonCoder Você faz um ponto interessante no final

O Visual Scripting (repito) é absolutamente inútil no momento (não consigo nem encontrar tutoriais e ninguém o usa pelo que posso ver na web).

Este é um bom exemplo de onde algo é difícil de usar por natureza, então mais tarde será usado como uma profecia auto-realizável para explicar por que não deve ser feito (por exemplo: "VEJA! Ninguém quer script visual!"), em vez de admitir que simplesmente não foi feito de uma maneira atraente ou amigável para iniciantes.

É como um meio-presente, porque sem o acompanhamento, é realmente inútil.

O mesmo vale para qualquer adição ao mecanismo que não esteja bem documentada ou fornecida com exemplos.

@bigelod Concordo absolutamente com você. Fico feliz que você não tenha entendido mal minhas intenções, e você entendeu perfeitamente o que eu quis dizer.

Godot Game Engine é simplesmente fantástico! Tem um potencial incrível. Para fazer jogos 2D, é o número 1! Durante anos experimentei com todas as Game Engine e frameworks existentes e posso dizer com absoluta certeza que Godot é um projeto que promete grandes coisas.

Por exemplo, o novo Visual Shader parece muito bom e promete grandes coisas para o futuro. Fiz alguns testes e gostei muito como ideia. Mas para perceber a lógica de um videogame, o Visual Scripting é uma armadilha.

Precisamos de tutoriais, documentação em geral, e acima de tudo um sistema simplificado no estilo Build 3, GDevelop, Game Maker Studio 2. Inicialmente como um addon para atingir principalmente jogos 2D, no futuro melhora e é implementado oficialmente. Percebo que não é uma tarefa fácil, é apenas uma ideia fazer do Godot Game Engine a solução ideal para entusiastas, estudantes e profissionais de videogames.

Obrigado a todos.

Em torno dos motores de jogo formaram-se lojas. Tornou-se normal - escrever complementos em uma base comercial. Para Construir incluindo. Todos os últimos plug-ins C2 significativos são comerciais. Isso se deve não apenas à formação do mercado, mas também à complicação dos produtos, um grande gasto de tempo para testes e correção de erros de compatibilidade.
Acho que... Godot está em outro nicho, e se Juan não escrever e apoiar a aplicação de programação simplificada, é improvável que outra pessoa leve esse trabalho até o fim.

Eu cresci com Klik 'n Play, The Games Factory e Multimedia Fusion, e uso o Construct 2 hoje em dia. A criação de scripts visuais com folhas de eventos é totalmente diferente de usar nós de máquinas de estado no estilo blueprints conectados uns aos outros e, para pessoas acostumadas com folhas de eventos, é a maneira mais fácil e eficiente de programar. Eu ficaria feliz em criar scripts no GoDot com folhas de eventos.

Eu atingi algumas limitações no gdscript, na documentação e na API do plugin que me impedem de executar totalmente minha visão disso como um complemento. Mesmo se eu chegar a um estado funcional - provavelmente terá limitações.

Uma coisa que me ajudará imediatamente a chegar lá é o gdscript opcional digitado - e é por isso que parei de trabalhar nisso até que esteja em godot. Agora que está mesclado - voltarei a trabalhar nisso como um complemento de prova de conceito sempre que houver tempo.

A ideia é que o gdscript gerado da folha de eventos seja digitado. Os dados digitados fornecerão à gui da folha de eventos dados contextuais extras sobre quais tipos de parâmetros são esperados.

Se houver interesse nisso como um módulo c++ adequado ou um complemento gdnative - todos são livres para tentar implementar isso.

Vendo quantas pessoas querem isso, nada me deixará mais feliz do que fazer com que isso seja parte do godot - ou pelo menos trabalhar como parte do godot.

Infelizmente eu tenho um trabalho em tempo integral que toma a maior parte do meu tempo no momento :(
Desculpem as atualizações lentas

Para adicionar a esta discussão, gostaria de apresentar a todos aqui um exemplo fantástico de um mecanismo de script visual usando uma abordagem de programação visual baseada em conexões de nó que atualmente está falhando em sua segmentação demográfica
https://youtu.be/b8GZ21YCh50?t=4m12s
É um pouco semelhante a https://www.reddit.com/r/unrealengine/comments/4nt0up/need_help_debugging_this_blueprint/

Observe as alternativas que o Gamesfromscratch apresenta

Uma coisa que eu quero evitar aqui nesta proposta de design é predefinir o comportamento que está fora do que os nós já fazem no godot - também criando muitas guias e gui .
Uma folha de eventos godot deve funcionar exatamente como código gdscript - apenas de uma maneira mais tátil/visual
Ele não deve tentar construir um mecanismo de jogo fácil de usar em cima do godot, mas sim tornar o que o godot tem mais acessível e mais rápido de montar

talvez com script visual possa ser acessível até mesmo em telas sensíveis ao toque?

De fato, o script visual de estilo de folha de evento é muito adequado para toque
telas

Em qua, 1 ago 2018 06:46 Elmapul, [email protected] escreveu:

talvez com script visual possa ser acessível até mesmo em telas sensíveis ao toque?

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

@blurymind se o sistema de plugins precisar de melhorias para isso, abra um problema, ele já foi modificado porque outros plugins precisavam de algo em particular.

É uma ótima ideia! Eu nunca entendi esses planos, mas a abordagem baseada em eventos é bem conhecida, especialmente em comunidades de mods, como Warcraft III World Editor.

Exemplo de telas:


Categorias e lista limpa de gatilhos parecem ótimas, pelo menos para mim. É mais fácil percebê-los do que as telas do primeiro post.

É basicamente o mesmo que você disse, mas com a possibilidade de adicionar condições como ações e aninhar outras ações nelas.

@Wiadomy
esta imagem é muito pequena para ver/ler qualquer coisa

@Elmapul
Desculpe, algo estava errado com ele. Atualizada.

@Elmapul enquanto meu complemento de conceito ainda não pode fazer o aninhamento, a folha de eventos que estou propondo inclui o aninhamento. Tanto o gdevelop quanto o build suportam o aninhamento de linhas - você pode experimentá-lo agora se quiser :)

@blurymind finalmente começou a trabalhar na implementação do Event Sheet, você conhece algum recurso que discuta sua implementação em detalhes, como um artigo de pesquisa ou um artigo sobre seu funcionamento e implementação?
Isso será uma grande ajuda. Para começar a projetar o sistema de folha de eventos para Godot.
Porque não seria preciso usar o método Construct ou GDevelop, pois o funcionamento do Godot é bem diferente e temos coisas chamadas sinais que também precisam ser integradas e mais um pouco.

há algumas informações sobre a folha de eventos do construct aqui se você precisar de informações gerais: https://www.scirra.com/manual/74/events
empresas diferentes implementam suas planilhas de eventos de forma um pouco diferente umas das outras e, portanto, cada uma tem suas próprias peculiaridades.
Talvez eu possa criar um vídeo que resuma as várias partes do método de construção (já que essa é provavelmente a melhor maneira atualmente). Não conheço nenhum trabalho de pesquisa - embora isso seja interessante de encontrar.

@prominentdetail Obrigado pelo link, parece que vou ter que ver como tornar os eventos mais fáceis de usar como sistema de construções.
Minha primeira ideia era ter algo parecido com o addon do @blurymind mas agora é mais provável que tenhamos uma API diferente para Event Sheet que facilite a codificação e não seja uma versão do GDScript em formato visual.

Então, o que vocês acham que o Event System deve ter uma API diferente para adicionar facilidade de uso ou apenas ser um wrapper para o GDScript.

@swarnimarun realmente a melhor coisa a fazer é usar os motores por um tempo e pensar em como isso pode ser feito de uma maneira mais boa. Construir classic e gdevelop são ótimos exemplos imo.

Do meu ponto de vista, os sinais no godot são como eventos de função incorporados. A conexão de sinais já é visual no godot :)

Definir um sinal de uma folha de eventos é apenas uma ação disponível no menu auxiliar - sob o capô, isso é apenas um método de configuração. Então seria o mesmo que com gdscript.

Se um nó contiver métodos integrados, isso deve estar disponível no menu que você obteria ao clicar em 'Adicionar função integrada'

Eu acredito fortemente que devemos mantê-lo simples e ser um wrapper para gdscript digitado , mas se isso não for possível ou prático - poderia ser uma API diferente. Valeria a pena investigar como o script visual atual implementado no godot funciona como uma abstração.

Se você quer saber como as funções personalizadas são feitas na construção, aqui está um link para o documento deles
https://www.scirra.com/tutorials/823/creating-function
:)

@blurymind Na verdade, é muito mais fácil e muito menos trabalhoso mantê-lo como um wrapper para o GDScript, mas o problema é que muitos dos recursos da Folha de Eventos se tornarão mais tediosos dessa maneira, pelo menos é assim que eu entendo.
Então, acho que vou manter o mesmo para os iniciantes e depois adicionar coisas, se necessário.

@swarnimarun obrigado por

Acho que o maior problema é que o VisualScript, como todas as outras linguagens que você pode usar para fazer o script do Godot, tenta ser o mais próximo possível da funcionalidade do GDscript, com funções, variáveis, sinais e tudo mais. Você não poderia conseguir isso com um sistema de folha de eventos, porque perderia muita funcionalidade. (Eu sei que é possível, mas ficaria inchado rapidamente)

@Jummit, exceto que você pode, tente o Construct 2. Ele não fica mais inchado do que o código padrão.

E poderia ter todas as funcionalidades do GDscript? Então o que estamos esperando? Vamos obter folhas de eventos em Godot!

@Jummit godot tem toda a funcionalidade que você deseja na forma de 'nós'

'Nós' em godot são como 'Comportamentos' em construct2
O comportamento do platformer no construct2 é como um nó kintematicbody2d menos poderoso :)
Você não precisa fazer o script de tudo do zero.

O que é ainda mais legal é que você pode aninhar esses nós em um relacionamento pai-filho, enquanto os comportamentos são restritos a serem anexados como módulos a um único objeto do jogo.

Eu acredito fortemente que um godot com um recurso de folha de eventos integrado e alguns plugins adicionais da comunidade pode se tornar um mecanismo mais rápido para prototipagem do que construct2 ou 3.
Tem muito potencial inexplorado.

A rapidez da prototipagem em C2 é amplamente determinada pela interatividade das células - elas podem ser arrastadas, copiadas e alteradas com teclas de atalho, incluindo objetos de condição, enquanto as listas suspensas eliminam quase completamente o erro.

@swarnimarun , criei uma visão geral genérica de várias coisas de construção: https://www.youtube.com/watch?v=ioz3gHtA-Lg
É basicamente para qualquer pessoa que não esteja muito familiarizada com a construção para ter uma ideia. Eu provavelmente esqueci várias coisas, já que não planejei tudo, mas isso pode fornecer algum entendimento básico. Eu provavelmente deveria fazer alguns vídeos onde eu realmente desenvolvo mais neles, para mostrar o lado do fluxo de trabalho em vez de divagar sobre várias coisas. Deixe-me saber se você gostaria de algo coberto ou explorado.

Isso é feio pra caralho pra mim. Quero dizer, scripts no vídeo.

@Wiadomy é muito melhor em uso do que naquele vídeo. As folhas de eventos no final sempre parecem mais limpas e legíveis do que qualquer sistema baseado em nó

@Wiadomy , devido à gravação de tela, tive que usar um monitor e também manter o tamanho do texto relativamente grande. Construct formata o texto para que algumas coisas possam ficar agrupadas devido ao espaço da tela se você digitar uma expressão longa e contínua.
Para resolver um pouco disso, você pode diminuir o zoom do texto e também usar outro monitor para liberar espaço para listar melhor os eventos.
Eu também poderia dividir um pouco as expressões para torná-lo mais legal também, mas este é um projeto meu mais antigo e também um pouco mais experimental.
Além disso, você se familiariza com as dicas visuais e o padrão na estrutura das folhas de eventos, tornando mais fácil rastrear todas as várias partes dos eventos. Ter uma estrutura padrão como esta é muito útil em termos de poder se adaptar a qualquer projeto e faz com que o fluxo de trabalho se torne muito rápido.

Este projeto está morto agora?

@ Amr512 Eu não acho que esteja morto. Certamente há muita vontade de trazer essa funcionalidade para a godot.
@reduz até se interessou pelo gdevelop recentemente no twitter
https://twitter.com/reduzio/status/1085206844275081218

Embora eu não tenha trabalhado no addon por um tempo, decidi realmente ir e começar a contribuir para o próprio gdevelop - para aprender mais sobre como sua folha de eventos é programada - bem como ajudar a torná-lo uma alternativa melhor ao pago opções.
https://github.com/4ian/GDevelop/

Algumas universidades começaram a pegar o gdevelop para ministrar cursos de programação
https://github.com/4ian/GDevelop/issues/882

Meu addon buggy godot é atualmente apenas para fins de apresentação e precisa de muito trabalho antes que possa ser funcional. Qualquer um é livre para fazer um fork e tentar empurrá-lo ainda mais, é claro.
Uma grande coisa que meu addon está faltando atualmente é um elemento gui de árvore classificável para as linhas de eventos. Também não há funcionalidade para renderizar folhas de eventos para gdscript ainda, nem há um editor de texto de expressão adequado com preenchimento automático de sintaxe e coloração (a ideia é usar gdscript padrão para sintaxe). Está faltando muitos elementos-chave que fariam uma folha de eventos, mas o objetivo principal é apresentar como uma folha de eventos pode ser usada em combinação com gdscript para sintaxe de expressão. Eu acho que os dois fariam uma combinação muito poderosa para jogos de prototipagem - mesmo para desenvolvedores experientes

@blurymind Deixei um ticket no seu projeto (erros no Godot 3.1beta3).
Eu amo totalmente a ideia.

Me deparei com esse problema por acidente, eu não sabia que esse material já é comumente usado em outros mecanismos/frameworks, então eu tive que escrever o meu próprio, parece muito semelhante, você não acha? 👀

Regra = Evento
Folha de Eventos = Esquema

A implementação anterior usava verificações de propriedade bastante "de baixo nível" e respectivas ações, mas percebi que esse tipo de sistema é realmente mais útil para definir "blocos de construção" de jogabilidade estendendo scripts básicos de condições/ações que são mais "de alto nível". nível" em abstração. Então essa é realmente a razão pela qual eu escolhi a terminologia "Regra" em primeiro lugar.

Você deve ter a jogabilidade e a estrutura do jogo já estabelecidas para fazer uso disso em toda a extensão, para que não sirva à experiência pronta para escrever um jogo sem codificação, mas na verdade o complementa de uma maneira que permite você pode combinar a funcionalidade existente de várias maneiras e organizá-la com eficiência, apenas componha novas regras com diferentes condições e ações usando seus GDScripts simples.

E sim, permitir que os jogadores criem seus próprios modos/missões/desafios de jogo por meio de mods é outra razão para usar esse sistema.

@Xrayez você pode compartilhar o
Além disso, apenas olhando para a captura de tela, acho que você está perdendo o ponto - deve ser apenas duas colunas, não três. Esquerda= condições, direita= ações. Além disso, você deve poder arrastar e soltar eventos entre células e também arrastar e soltar linhas e aninhá-las. Para construir isso, precisamos usar uma árvore classificável. Jogue com gdevelop e construct, você terá uma ideia melhor do que torna essas planilhas de eventos tão legais

Talvez minha implementação possa ser considerada algo semelhante ao DSL, então é aí que podem surgir as diferenças. Muitas regras são apenas implementações em sandbox de funções adaptadas para requisitos específicos de jogo. Em essência, as condições e ações apenas herdam esses pequenos scripts com os métodos que devem ser implementados nas classes filhas:

class_name SchemeCondition extends Node

func is_met(object): # override
    return true

class_name SchemeAction extends Node

func perform(object): # override
    pass

As regras são apenas uma coleção dessas condições e ações e são executadas com base no cumprimento de todas ou quaisquer condições, nada muito extravagante na verdade.

Entendo que as pessoas que contribuem e implementam coisas gostam de codificar e nem todas veem o apelo da programação sem codificação, mas muitas outras estão de fato interessadas nela.

Construct, Gdevelop, Stencyl, Game Maker, Playmaker, Bolt, Fungus for Unity, Blueprints em Unreal, Flow Graph e Schematyc em CryEngine, etc...

Muitas ferramentas para não codificadores estão sendo feitas e usadas. Muitos bons jogos são feitos graças a eles.
Hollow Knight foi feito com playmaker, por exemplo.

Você ainda tem coisas como Dreams fazendo bastante barulho.

Esse tipo de ferramenta traria muita atratividade e acessibilidade e, portanto, novas pessoas para Godot.

Recentemente, implementei uma maneira no gdevelop de adicionar novas instruções à sua folha de eventos por meio de um menu suspenso como este

É tipo o que eu acho que poderia funcionar bem para Godot.

Você usa o richtextlabel para renderizar cada célula, essas células são aninhadas nas colunas esquerda e direita, que são filhas de uma linha. As linhas são gerenciadas por uma árvore classificável. Cada linha contém gdscript real que um interpretador processa em simples descrições curtas com miniaturas e áreas clicáveis ​​para inserir expressões.
Isso é realmente o que o criador de jogos faz. Seus dados de programação visual são armazenados como gml real.

A parte complicada que encontrei quando comecei a fazer isso como uma extensão gdscript foi fazer os campos de expressão. Como podemos colocar um editor de código em um campo de entrada e deixá-lo fazer o preenchimento automático para nós? Como damos contexto de conclusão e validação? Sem campos de expressão autocompletados validados, isso está morto na água.

Temos todas as partes da interface do usuário para construir isso no godot, mas literalmente não temos um único desenvolvedor experiente fazendo nada nele. Eu não vi nenhum trabalho feito até agora

De qualquer forma, se meu conhecimento de c++ fosse melhor, eu teria tentado :) Mas eu conheço javascript, então minhas contribuições vão para gdevelop em vez disso

Adoraria ver uma solução baseada em eventos no Godot. Eu tentei godot no passado, mas não consegui me sentir confortável com seu fluxo de trabalho. Minha mente é mais adequada para folhas de eventos se eu estiver desenvolvendo um jogo.

Agora sou programador e estou começando a me dedicar ao desenvolvimento de motores. Mas ainda posso garantir com bastante confiança as folhas de eventos.

O Construct 2 foi de fato minha primeira exposição a muitos conceitos fundamentais de programação, através de uma aula que fiz no ensino médio. Eu sinto que simplificou e acelerou enormemente o processo de aprendizado para mim - tanto o mecanismo em específico quanto a programação em geral - ao mesmo tempo em que traduzia o código real o suficiente para que não me sentisse totalmente perdido na transição das folhas de eventos ao script de texto antigo regular. Embora eu não possa ter 100% de certeza disso, eu realmente não acho que poderia ter obtido nenhum desses benefícios na mesma medida, se fosse o tipo de espaguete de script visual.

Mas eu concordo que manter dois sistemas de scripts visuais diferentes é provavelmente uma má ideia. Dito isso, não acho que devemos ficar com o sistema atual só porque é o que já temos. Acho que deveríamos realmente considerar mudar para outro sistema, se os dados o justificarem. Ou seja, acho que devemos tentar ter uma ideia melhor de quão mais acessível é o sistema de folha de eventos em relação ao nosso sistema atual. O objetivo do script visual deve ser tornar o mecanismo mais amigável para pessoas não familiarizadas ou não confiantes com scripts regulares. Um sistema de script visual sólido pode fazer uma enorme diferença em quão acessível Godot é, e pode significar obter o apoio e a adoção de muito mais pessoas, que de outra forma não considerariam Godot.

Na verdade, a principal razão pela qual eu originalmente mudei do Construct 2 foi simplesmente porque eu já queria entrar no 3D. Acabei tentando Unity, Unreal, Godot e Amazon Lumberyard, e acabei indo com Godot praticamente só porque parecia mais rápido abrir e usar e o processo de importação parecia melhor. Mas se Godot tivesse o sistema de estilo de folha de eventos, eu provavelmente teria imediatamente padronizado para Godot. Concedido, isso realmente não faz diferença para mim agora, pessoalmente, mas, novamente, trata-se de tornar Godot o mais amigável possível para não programadores (ou seja, uma porção significativa de desenvolvedores de jogos novos/aspirantes) quanto possível.

Eu não li as 112 postagens que agora estão ocultas, então peço desculpas se repeti ou perdi alguma coisa, mas estou totalmente interessado em prototipar a ideia ou ajudar a testá-la e considerá-la.

Acho que deveríamos realmente considerar mudar para outro sistema, se os dados o justificarem. Ou seja, acho que devemos tentar ter uma ideia melhor de quão mais acessível é o sistema de folha de eventos em relação ao nosso sistema atual.

Já temos muito poucos mantenedores para o atual sistema de script visual. Eu não acho que uma mudança completa seria concluída em nossa vida :slightly_smiling_face:

Já temos muito poucos mantenedores para o atual sistema de script visual. Eu não acho que uma mudança completa seria concluída em nossa vida 🙂

Bem, supondo que primeiro tenhamos um protótipo funcional da folha de eventos, o código já estaria quase pronto, e seria apenas uma questão de saber se queremos mudar para esse sistema, certo?

Eu também comecei com o Construct 2 e descobri que as folhas de eventos são ótimas para resolver 2
problemas:

• Como qualquer script visual, você expõe todas as possibilidades de qualquer
  module/plugin/add-on/function, isso é muito útil para aprender um novo código.
  Nós visuais se transformam em código de espaguete bem rápido (eu sou um cara do liquidificador,
  Eu sei sobre espaguete no compositor e shaders).
• A folha de eventos é como a arrogância da API Rest, você começa com
  código que preenche o menu suspenso da folha de eventos e você obtém uma GUI limpa
  maneira de consumir seu código, você pode estender a ficar confuso e, você pode
  gerar código a partir dele (JS do Construct2), daí minha pergunta:
  gerar código a partir dele?

Se sim, acho que a folha de eventos deve se tornar uma prioridade, para facilidade de uso para
todos e geração otimizada de código de baixo nível.
Se Godot pudesse ser usado para transformar uma API python/C#/... em um conjunto limpo de
eventos, então eventos de construção do usuário, então Godot gera código a partir dele, você está
resolvendo um problema de usuário muito difícil: aprenda a codificar a partir de uma interface de usuário simples.

Eu sei que a folha de eventos não resolve todos os problemas, mas pelo menos você pode codificar 500
eventos como você está fazendo em uma planilha sem se perder no visual
links em todos os lugares.

Em quarta-feira, 8 de abril de 2020 às 19:44 Jay [email protected] escreveu:

Já temos muito poucos mantenedores para o script visual atual
sistema. Eu não acho que uma mudança completa seria completada em nosso
vida inteira 🙂

Bem, supondo que tenhamos um protótipo funcional da folha de eventos, então o código
já estaria feito, seria apenas uma questão de saber se
quer mudar para isso, certo?

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-611096608 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAAP6LM4PU6RYLO5NK5IL23RLSZWHANCNFSM4EXTBSVQ
.

Comecei a usar o Construct 2 e eventualmente passei a desenvolver plugins usando JavaScript, então as folhas de eventos têm um lugar no meu coração. Eles eram fáceis e intuitivos para os não iniciados, com a maior parte da mágica da fácil visualização dos métodos disponíveis (ações e condições) para cada classe (plugin). Honestamente, o GDScript no VSCode é tão bom agora, com o intellisense completo e o preenchimento automático facilitando a vida. Embora eu fosse um grande fã dessa ideia há 2 anos, agora mudei de ideia. Eu preferiria que os heróis dev Godot concentrassem seu tempo e esforço em adicionar outras melhorias no motor.

Poderíamos gerar código a partir dele?

Eu teria que pesquisar mais sobre isso, mas honestamente acho que seria bastante trivial fazê-lo e, na verdade, é provavelmente a melhor maneira de fazê-lo. Ou seja, acho que a melhor maneira de lidar com um estilo de folha de eventos é basicamente fazer com que ele atue como um front-end gráfico para um arquivo gdscript regular. As ações realizadas no editor da folha de eventos simplesmente editariam o arquivo gdscript. Por exemplo, mover um bloco de um lugar para outro no editor de folha de eventos basicamente seria como um corte e colagem virtual no arquivo gdscript. E qualquer arquivo gdscript pode ser visualizado e editado no editor de script ou no editor de folha de eventos. Essa parece ser a melhor maneira de fazer isso, tanto do ponto de vista da usabilidade quanto do ponto de vista da implementação. Dito isto, ainda não tenho muito conhecimento sobre desenvolvimento de motores, então posso estar enganado.

Eu preferiria que os heróis dev Godot concentrassem seu tempo e esforço em adicionar outras melhorias no motor.

Eu concordo bastante. Acho que a maneira ideal de fazer isso seria para qualquer pessoa interessada em tentar obter um protótipo funcional e, a partir daí, a comunidade pode tentar descobrir se vale a pena mudar para isso como o principal sistema de script visual ou não. Eu não pediria nenhum tempo de desenvolvimento principal dessa ideia até que uma decisão seja tomada ou pelo menos próxima.

Eu não estou em Gdscript ou Godot o suficiente também.
Mas o que eu desenvolvi como uma extensão do VS Code também está indo dessa maneira ampla
(https://github.com/j2l/blocklight).
Compreender visualmente o código brincando com um pedaço dele e visualmente
vinculando as variáveis ​​e resultados (nós na maioria dos scripts visuais, ou cores
na minha extensão) é a pedra angular que faltava para muitos.
Na verdade, entendemos o código quando terminamos de aprendê-lo, enquanto deveríamos
veja as variáveis ​​e os links dos pedaços antes de obter todos os
código.
Projete antes de codificar :)

Em quarta-feira, 8 de abril de 2020 às 20:08 Jay [email protected] escreveu:

Poderíamos gerar código a partir dele?

Eu teria que pesquisar mais sobre isso, mas sinceramente acho que seria bonito
trivial fazê-lo e, de fato, é provavelmente a melhor maneira de fazê-lo. Aquilo é,
Eu acho que a melhor maneira de lidar com um estilo de folha de eventos é basicamente
faça com que ele atue como um front-end gráfico para um arquivo gdscript regular. Ações
tirada no editor da folha de eventos simplesmente editaria o arquivo gdscript. Mudança
um bloco de um lugar para outro no editor da folha de eventos basicamente
sob o capô estar fazendo como um virtual recortar + colar no arquivo gdscript. E
qualquer arquivo gdscript pode ser visualizado e editado no editor de scripts ou no
editor de folhas de eventos. Esta parece ser a melhor maneira de fazê-lo, tanto de um
do ponto de vista da usabilidade e do ponto de vista da implementação. Isso disse que eu sou
ainda não tenho muito conhecimento sobre desenvolvimento de motores, então posso estar enganado.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/godotengine/godot/issues/17795#issuecomment-611108712 ,
ou cancelar
https://github.com/notifications/unsubscribe-auth/AAAP6LN7GFGSBDZ537XXA6DRLS4Q5ANCNFSM4EXTBSVQ
.

Eu amo a ideia de que ele geraria um arquivo Gdscript regular. Seria muito bom para aprender

Quando comecei a fazer jogos, o sistema de eventos do Klik & Play era uma ótima maneira de entender a lógica de programação, e ainda adoro voltar a ele.

Eu amo a ideia de que ele geraria um arquivo Gdscript regular. Seria muito bom para aprender

Quando comecei a fazer jogos, o sistema de eventos do Klik & Play era uma ótima maneira de entender a lógica de programação, e ainda adoro voltar a ele.

Eu acho que essa é potencialmente uma de suas maiores vantagens sobre o sistema de espaguete atual - devido ao seu design, facilitará as pessoas a aprender programação e a api do gdscript/godot.

Algumas pessoas aqui comentaram - mas por que se incomodar em fazer isso - é muito semelhante ao script na apresentação.
Minha resposta para isso é - precisamente. Você aprende espaguete, você fica com espaguete. Você aprende a folha de eventos, conhecerá o gdscript vendo o que ele gera e usando esses campos de expressão.

Ele vai te ensinar sobre a ordem de execução e como ler o código.

Veja o que a conversão para GML faz no criador de jogos
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/ Changing_dnd.html

Muito interessante blurymind! Eu tive a mesma ideia e estou totalmente apoiando isso.
Ainda estou fazendo extensões para o Clickteam Fusion 2.5, mas tudo o que quero adicionar no Fusion está no Godot.
Tudo que eu preciso é colocar mais uma camada de abstração (folha de evento) no Godot para facilitar o desenvolvimento.
Eu não li o tópico inteiro, mas a principal diferença do meu ponto de vista entre scripts visuais em Godot e folhas de eventos em outros mecanismos de jogo é que scripts visuais são "apenas" uma visão visual do código e folhas de eventos são uma abstração de o código com uma visão simplificada. É mais legível para humanos, está fatorando coisas que precisam de várias linhas de código em uma linha e a ligação de sinal/slots é feita automaticamente.
Na verdade, adicionar alguns modelos (cenas predefinidas) ao objeto interno abstrato do CF2.5 e ainda usar GDScript faria a maior parte do trabalho para mim, mas a folha de eventos definitivamente me tornará mais eficiente no Godot do que estou fazendo no CF2.5 agora.

Muito interessante blurymind! Eu tive a mesma ideia e estou totalmente apoiando isso.
Ainda estou fazendo extensões para o Clickteam Fusion 2.5, mas tudo o que quero adicionar no Fusion está no Godot.
Tudo que eu preciso é colocar mais uma camada de abstração (folha de evento) no Godot para facilitar o desenvolvimento.
Eu não li o tópico inteiro, mas a principal diferença do meu ponto de vista entre scripts visuais em Godot e folhas de eventos em outros mecanismos de jogo é que scripts visuais são "apenas" uma visão visual do código e folhas de eventos são uma abstração de o código com uma visão simplificada. É mais legível para humanos, está fatorando coisas que precisam de várias linhas de código em uma linha e a ligação de sinal/slots é feita automaticamente.
Na verdade, adicionar alguns modelos (cenas predefinidas) ao objeto interno abstrato do CF2.5 e ainda usar GDScript faria a maior parte do trabalho para mim, mas a folha de eventos definitivamente me tornará mais eficiente no Godot do que estou fazendo no CF2.5 agora.

eu costumava usar CF na época que era chamado de fusão multimídia, era fácil o suficiente para aprender como uma criança que não falava inglês, e depois de praticar com ele, você pode ser muito rápido, dependendo do que você está fazendo, pode ser mais rápido do que digitar.
construct e CF são referência de como é um bom script visual (gdevelop está chegando lá)

Obrigada
Eu apoio essa ideia maravilhosa
Dizem que a construção 2 vai se aposentar!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

Gostaria de saber se é possível negociar com o desenvolvedor do construct 2 a fim de opensource do sistema de eventos, e usá-lo em godot, unity etc.
É uma perda que o sistema de eventos de construção 2 seja negligenciado nas prateleiras sem uso

Obrigada
Eu apoio essa ideia maravilhosa
Dizem que a construção 2 vai se aposentar!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

Gostaria de saber se é possível negociar com o desenvolvedor do construct 2 a fim de opensource do sistema de eventos, e usá-lo em godot, unity etc.
É uma perda que o sistema de eventos de construção 2 seja negligenciado nas prateleiras sem uso

Duvido que possamos usar qualquer código do construct2 no godot - eles são uma base de código completamente diferente.

Sua melhor aposta para uma alternativa de código aberto é migrar para o gdevelop
https://github.com/4ian/GDevelop

Este ticket de emissão provavelmente será fechado em breve, portanto, se houver algum interesse nesta folha de evento em Godot - em breve teremos que movê-lo para outro lugar :) (ou para gdevelop)

Este ticket de emissão provavelmente será fechado em breve, portanto, se houver algum interesse nesta folha de evento em Godot - em breve poderemos ter que movê-lo para outro lugar :)

Que? Por quê?

@TheGoklayeh Pode ser fechado, pois estamos migrando propostas de recursos para godot-proposals .

Dito isso, @blurymind pode editar a primeira postagem para corresponder ao modelo de proposta . Poderíamos então mover este problema para o repositório de propostas.

Nós realmente precisamos de um motor 3D utilizando folhas de eventos.

Obrigada
Eu apoio essa ideia maravilhosa
Dizem que a construção 2 vai se aposentar!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

Gostaria de saber se é possível negociar com o desenvolvedor do construct 2 a fim de opensource do sistema de eventos, e usá-lo em godot, unity etc.
É uma perda que o sistema de eventos de construção 2 seja negligenciado nas prateleiras sem uso

Isso pode arruinar o negócio deles. e clickteam além disso.

Obrigada
Eu apoio essa ideia maravilhosa
Dizem que a construção 2 vai se aposentar!
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505
Gostaria de saber se é possível negociar com o desenvolvedor do construct 2 a fim de opensource do sistema de eventos, e usá-lo em godot, unity etc.
É uma perda que o sistema de eventos de construção 2 seja negligenciado nas prateleiras sem uso

Isso pode arruinar o negócio deles. e clickteam além disso.

Se algo os matar - o clickteam seria devido à falta de atualizações em seu software (a última em 2019), o Scirra seria por forçar seus usuários a mudar para uma licença de software de aluguel que os obriga a pagar todos os anos ou obter bloqueado. Ambas as empresas têm falhas e sua comunidade não tem controle sobre o que acontece com o software. É aqui que o código aberto brilha

@TheGoklayeh Pode ser fechado, pois estamos migrando propostas de recursos para godot-proposals .

Dito isso, @blurymind pode editar a primeira postagem para corresponder ao modelo de proposta . Poderíamos então mover este problema para o repositório de propostas.

Alguém pode fazer isso no meu lugar? :)
Eu meio que perdi a esperança de que esse recurso chegasse ao godot nativamente (não uma extensão). A abordagem de espaguete conquistou usuários e desenvolvedores da Godot

@blurymind Se você não apoia mais essa proposta, acho melhor fechá-la. Outra pessoa interessada em trabalhar em uma abordagem de folha de eventos poderia abrir uma nova proposta sobre godot-propostas . (Devido ao grande volume de trabalho necessário, não acho que faria sentido abrir uma proposta se ninguém for tecnicamente capaz de cumpri-la.)

Ainda assim, este tópico contém muitas discussões valiosas, então obrigado de qualquer maneira :slightly_smiling_face:

Acho essa proposta muito boba :)
Mas podemos criar o sistema de eventos com motor de construção 3?!
Eu acho que o jogo pode gerar códigos e enviá-los em um arquivo de texto para o mecanismo godot via node.js

Isso é ridículo .. mas acho que a construção 3 é forte o suficiente para fazer um sistema de eventos
Isso é melhor do que nada no momento

Sim, espero que pelo menos tenhamos conseguido chegar a uma ideia sobre esse sistema no godot, suas vantagens sobre o atual sistema de codificação visual e opiniões sobre outros motores que o utilizam

Eu honestamente gosto de como o GDevelop faz isso, mas Godot fazendo script de eventos não é algo que eu sou a favor agora (nos dias de hoje).
Tentei implementá-lo uma vez e percebi que Godot tem uma API extremamente granular/de baixo nível para ser exposta diretamente de um sistema de Visual Scripting.
O sistema de script visual atual incluído e por que eu preferiria que ele tivesse uma camada de abstração personalizada, mas ainda fosse robusto.
Essa implementação é incrivelmente difícil de escrever para script de evento, a menos que você use várias linguagens de script de sub-evento como DSL, onde cada uma é usada para uma parte específica do mecanismo.

Um sistema de script visual generalizado que é simples e fácil de usar seria bastante difícil de alcançar e é o que eu considero um "Projeto Unicórnio".
Como o aumento da generalização muito provavelmente levaria a um aumento muito maior da complexidade do referido sistema.

Eu pretendo levar o Visual Scripting gradualmente para uma direção em que ele possa ter interfaces especializadas para todas as partes do Engine.
Imagine uma maneira diferente de editar para cada tipo de nó complexo primitivo, como em Blueprints, tendo um nó de expressão.
https://docs.unrealengine.com/en-US/Engine/Blueprints/UserGuide/MathNode/index.html

Mas só para deixar claro, não sou contra Event Scripting, gostaria de ver alguém apresentar uma proposta que possa abranger alguns sistemas específicos do Godot, e por que e como isso pode ser útil. Pessoalmente, acho muito bom programar Comportamentos, como o GDevelop faz isso.
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors/events-based-behaviors

Não vou usá-lo para escrever um jogo adequado, mas se tivermos comportamentos simples com os quais podemos descer e brincar, vejo isso como uma maneira bastante divertida de otimizar o projeto para crianças aprendendo a fazer jogos.
Ou alguém que não está acostumado a programar usando-o para game jams.

Embora o mesmo possa ser dito sobre o VisualScript e a modularidade provavelmente será muito mais fácil de alcançar com ele. O problema seria unificação e consistência (Visual Shader e VisualScript usam bases de código completamente diferentes, apenas a semelhança sendo os nós de interface do usuário usados).
Ainda assim, certamente podemos tentar ter um sistema de Script de Evento como um Plugin (Plugin C++, espero que se torne fácil de fazer após 4.0) que possa ser mantido pela comunidade e adicionado ao Godot quando necessário. (Estou meio inclinado para um Game Engine modular)

De qualquer forma, são apenas meus 2 centavos.

Por que meu comentário foi marcado como offtopic? Alguém está censurando a comunidade, e quem? Isso não é um bom presságio. Existem outros comentários além do meu que são mais off-topic.

@prominentdetail Aqui está minha mensagem de aviso anti-bump, esqueci de colá-la :slightly_smiling_face:

Por favor, não aborde problemas sem contribuir com novas informações significativas. Use o botão de reação :+1: no primeiro post.

(Gostaria que o GitHub tivesse uma maneira de enviar mensagens privadas ou pelo menos especificar um motivo personalizado para ocultar, para que eu não precisasse encher o tópico de comentários com isso.)

PS: Esta é uma etiqueta típica no GitHub; não é específico para este repositório.

Eu apoio esta proposta, só não acho que alguém dedicaria tempo para implementá-la.
Ele não tem suporte forte o suficiente de desenvolvedores que podem realmente fazer isso acontecer.

Valeu a pena tentar e a discussão foi interessante com certeza :)

@blurymind se você ainda apoia a proposta e está disposto a escrevê-la no formato exigido para GIPs. Vale a pena fazer IMO.

A maneira como as coisas são adicionadas no Godot é quando alguém interessado em um recurso leva tempo para implementá-lo. É muito aleatório e esporádico. Mas dependemos quase completamente de contribuidores que decidem aleatoriamente adicionar recursos.

Então, só porque o conjunto atual de desenvolvedores ativos não se interessou por sua proposta, não significa que alguém não venha e a implemente.