Godot: Designer de jogos fácil de usar para não programadores

o script visual é planejado em algum momento

Em quarta-feira, 14 de janeiro de 2015 às 6h20, RyanBram [email protected] escreveu:

Olá, Desenvolvedores Godot.

Em primeiro lugar, quero agradecer a todos vocês por criarem um ótimo mecanismo de jogo
com licença muito permissiva. Seu esforço ajudará muitos desenvolvedores e
alunos com orçamento apertado para realizar seus sonhos.

Com o status atual de Godot, os jogos de código aberto terão um futuro mais brilhante.
Infelizmente, a maior parte do código aberto do motor de jogo é projetado com recursos avançados
usuário em mente com pouco conhecimento sobre programação. Ainda não pode alcançar
um criador de jogos para iniciantes.

Minha sugestão é fornecer um designer/editor de jogos fácil de usar com
GUI intuitiva e classe predefinida para facilitar a tarefa do novo programador. Mais
programador significa mais usuário (porque o usuário Godot é programador de jogos).

Conheço um motor de jogo que faz esse trabalho bem. É escrito a partir de Ruby,
originalmente do Japão e traduzido para o inglês em todo o mundo. se chama RPG
Criador VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace. Apesar de
a palavra RPG na frente de seu nome, é capaz o suficiente para criar não-RPG
jogo com seu Ruby Game Scripting System (RGSS) integrado.

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d65736172656576696c2e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30312f7270676d616b6572322e6a7067

A lista a seguir é um exemplo de jogos feitos com a engine RPG Maker:

1. Aleph (RPG Adventure) http://www.pioneervalleygames.com/
2. Nenhum peixe-boi prometido (Arcade) http://rpgmaker.net/games/5102/
3. Ragarokk - Bestiarium (Jogo de Cartas) http://rpgmaker.net/games/5808/
4. Terra sob ataque! (Atirador) http://rpgmaker.net/games/6561/
5. Terra (VisualNovel) http://rpgmaker.net/games/3956/
6. Memórias de Mana (RPG de ação)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos - The Beginning (Horror) http://rpgmaker.net/games/6493/

Desejo que o motor Godot se torne tão popular quanto o RPG Maker, porque tem muito
mais recursos do que o RPG Maker. Programador iniciante só precisa de um programa fácil de usar
interface. Se foi sucesso, estúdio Okam pode se tornar próximo GOG ou Steam
que publicam milhares de jogos criados por desenvolvedores inde.

Atenciosamente, Ryan

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220.

@RyanBram - Não estou tentando rejeitar a ideia aqui - provavelmente pode ser útil no futuro, mas não tenho certeza de que o script visual seja um meio eficaz de script. Não posso dizer com certeza, mas imagino que os jogos mais complexos que você postou provavelmente foram roteirizados em texto, não visualmente. Parece que o script visual é algo que os novos usuários usam, com certeza, mas isso os atrasa no aprendizado das ferramentas reais de que precisam para concluir adequadamente seus projetos. Mas poderia tornar o motor mais acessível, então não sei.

Também deve ser possível para os usuários criarem um sistema de programação visual todo em Godot com GDScript ao invés de algo que precisa ser embutido no motor, certo? Eu não tenho certeza sobre isso, no entanto.

O criador de RPG parece ter mais uma abordagem "Modding", e se Godot se parecer mais com um criador de RPG - as pessoas que têm intenções de fazer diferentes tipos de jogos vão se afastar. Então o que você está basicamente sugerindo é fazer o godot parecer mais com o GameMaker (o que é compreensível, muitas pessoas querem fazer jogos, mas não sabem programação), mas existem limitações :)
O que provavelmente vai acontecer é que Godot vai ter o editor Nodal Behavior Graph, semelhante ao que Leadwerks e BGE têm. Isso funciona muito bem com elementos da GUI, o resto exigiria alguma pesquisa e toneladas de feedback da comunidade, para torná-lo o mais fácil e poderoso possível.

@SolarLune , é possível construir um jogo em Godot e adicionar um editor em cima que permite modificar o jogo em cada pequeno detalhe (usando GraphNodes e resto da interface do usuário, muito divertido de jogar), e até permitir escrever alguns código GDscript extra no topo, acho que essa é a melhor abordagem, para enviar um jogo completo (RPG, FPS, RTS) separadamente e permitir ajustar todos os aspectos dele. Construtores feitos em Godot.

@SolarLune : o script visual é útil quando você trabalha em conjunto com um
programador, que pode fazer blocos para você montar para brincar. Isto
abordagem no Unreal é útil. Acho que não é possível substituir
programação inteiramente (a menos que você seja um masoquista), mas pode funcionar para
algumas pessoas fazem blocos de template para não programadores também.

Em quarta-feira, 14 de janeiro de 2015 às 16h23, TheoXD [email protected] escreveu:

O criador de RPG parece ter uma abordagem mais "Modding", e se Godot
parecem mais com RPG maker - pessoas que tem a intenção de fazer diferente
tipo de jogos vai virar. Então, o que você está basicamente sugerindo é
fazer o godot parecer mais com o GameMaker (o que é compreensível, muitas pessoas
quer fazer jogos mas não sabe programar) mas tem um limite :)
O que provavelmente acontecerá é que Godot obterá o Gráfico de Comportamento Nodal
editor, semelhante ao que Leadwerks e BGE têm. Isso funciona muito bem com
elementos GUI, o resto exigiria alguma pesquisa e toneladas de comunidade
feedback, para torná-lo o mais fácil e poderoso possível.

@SolarLune https://github.com/SolarLune , é possível construir um jogo
em Godot e adicione um editor no topo que permite modificar o jogo para cada
pequenos detalhes (usando GraphNodes e resto da interface do usuário), e até permitiria
escreva algum código GDscript extra no topo, acho que essa é a melhor abordagem,
enviar um jogo completo (RPG, FPS, RTS) separadamente e permitir ajustes
cada aspecto dele.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -69974733.

Bem, pelo que eu sei, Godot já tem código de interface do usuário baseado em nó (para a árvore de animação e agora o editor de sombreamento visual) que pode, no futuro, ser usado para criar um tipo de árvore 'lógica'.

No entanto, é preciso notar que o GDscript continuará sendo o caminho a percorrer se você quiser flexibilidade máxima e tornar os nós lógicos úteis exigiria um nó de script para execução do GDscript (para coisas mais complexas e avançadas).

UE4 agora não pode fazer tudo em Blueprints sem complexidade insana, GameMaker espera que você use GML para máxima flexibilidade (através do uso de blocos de código), e o BGE requer scripts em Python para potência máxima (através do uso de blocos de código). Não se pode descartar a utilidade da edição visual para prototipagem rápida e situações lógicas menos complexas, mas muitas vezes não é possível fazer tudo o que se pode fazer no código.

o script visual é planejado em algum momento

Obrigado pela resposta simples e positiva.

Pessoal, obrigado por comentar esta sugestão. Acredito que um editor fácil e visual nunca seja capaz de substituir a codificação manualmente. Sugiro esse recurso como complementar para codificação regular e não para substituir sua posição.

No RPG Maker VX Ace, a maioria dos recursos avançados é codificado à mão. Um programador avançado geralmente fornece um script de modificação avançado cujo valor pode ser editado no GUI Editor por usuário casual (nome do personagem, habilidade, retrato, sprite, etc). O Ruby Game Scripting System possibilita a aplicação de patches de macaco. É por isso que a maioria dos scripts fornecidos pelo usuário avançado não substituirá a classe predefinida original pelos desenvolvedores do RPG Maker para evitar problemas de compatibilidade.

Para comparação:
Os projetos KDE e GNOME nunca pretendem substituir os poderosos Comandos Shell no Linux, em vez disso, os projetos apenas tentam preencher a lacuna entre a facilidade de uso e o poder do Linux.

Sorri com a ideia do estúdio Okam ser como o Steam... :))

Em 14/01/2015 17:20, RyanBram escreveu:

Olá, Desenvolvedores Godot.

Em primeiro lugar, quero agradecer a todos vocês por criarem um ótimo jogo
motor com licença muito permissiva. Seu esforço ajudará muitos
desenvolvedores e estudantes com orçamento apertado para realizar seus sonhos.

Com o status atual de Godot, jogos de código aberto terão mais brilho
futuro. Infelizmente, a maior parte do código aberto do mecanismo de jogo é projetada
com o usuário avançado em mente com pouco conhecimento sobre programação. Isto
ainda não consegue chegar a um criador de jogos iniciante.

Minha sugestão é fornecer um designer/editor de jogos fácil de usar com
GUI intuitiva e classe predefinida para facilitar a tarefa do novo programador.
Mais programador significa mais usuário (porque o usuário Godot é programador de jogos).

Conheço um motor de jogo que faz esse trabalho bem. É escrito a partir de Ruby,
originalmente do Japão e traduzido para o inglês em todo o mundo. Isto é
chamado RPG Maker VX Ace
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace.
Apesar da palavra RPG na frente de seu nome, ele é capaz o suficiente para
crie um jogo não-RPG com seu Ruby Game Scripting System (RGSS) integrado.

https://camo.githubusercontent.com/72746b38bc6f990eb5f1b9bb242bdce347af3c72/687474703a2f2f67616d65736172656576696c2e636f6d2f77702d636f6e74656e742f75706c6f6164732f323031332f30312f7270676d616b6572322e6a7067

A lista a seguir é um exemplo de jogos feitos com a engine RPG Maker:

1. Aleph (RPG Adventure) http://www.pioneervalleygames.com/
2. Nenhum peixe-boi prometido (Arcade) http://rpgmaker.net/games/5102/
3. Ragarokk - Bestiarium (Jogo de Cartas) http://rpgmaker.net/games/5808/
4. Terra sob ataque! (Atirador) http://rpgmaker.net/games/6561/
5. Terra (VisualNovel) http://rpgmaker.net/games/3956/
6. Memórias de Mana (RPG de ação)
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos - The Beginning (Horror) http://rpgmaker.net/games/6493/

Desejo que o motor Godot se torne tão popular quanto o RPG Maker, porque tem
muito mais recursos do que o RPG Maker. Programador iniciante só precisa de um
interface fácil de usar. Se foi sucesso, o estúdio Okam pode se tornar o próximo
GOG ou Steam que publicam milhares de jogos criados por desenvolvedores inde.

Atenciosamente, Ryan

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220.

Unreal realmente tem modelos para projetos se você quer fazer um
scripts visuais ou um tipo de fluxo de trabalho de script completo... e até mesmo o
blocos de código para edição visual são acessíveis via visual studio e podem ser
personalizado... :)

Em 15/01/2015 03:44, Juan Linietsky escreveu:

@SolarLune : o script visual é útil quando você trabalha em conjunto com um
programador, que pode fazer blocos para você montar para brincar.
Isto
abordagem no Unreal é útil. Acho que não é possível substituir
programação inteiramente (a menos que você seja um masoquista), mas pode funcionar para
algumas pessoas fazem blocos de template para não programadores também.

Em quarta-feira, 14 de janeiro de 2015 às 16h23, TheoXD [email protected] escreveu:

O criador de RPG parece ter uma abordagem mais "Modding", e se Godot
parecem mais com RPG maker - pessoas que tem a intenção de fazer diferente
tipo de jogos vai virar. Então, o que você está basicamente sugerindo é
fazer Godot parecer mais com o GameMaker (o que é compreensível, muitos
pessoas
quer fazer jogos mas não sabe programar) mas tem um limite :)
O que provavelmente acontecerá é que Godot obterá o Gráfico de Comportamento Nodal
editor, semelhante ao que Leadwerks e BGE têm. Isso funciona muito bem
com
elementos GUI, o resto exigiria alguma pesquisa e toneladas de
comunidade
feedback, para torná-lo o mais fácil e poderoso possível.

@SolarLune https://github.com/SolarLune , é possível construir um jogo
em Godot e adicione um editor no topo que permite modificar o jogo para cada
pequenos detalhes (usando GraphNodes e o resto da interface do usuário) e até
permitir
escreva algum código GDscript extra no topo, acho que este é o melhor
aproximação,
enviar um jogo completo (RPG, FPS, RTS) separadamente e permitir
ajustando
cada aspecto dele.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -69974733.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -69978224.

Sorri com a ideia do estúdio Okam ser como o Steam... :))

Eu também sorri de forma positiva.
Porque será ótimo para mim como jogador se houver uma empresa tão grande quanto o Steam com toneladas de catálogos de jogos, abertos e DRM Free, criados por milhares de grandes desenvolvedores de jogos.

Unreal realmente tem modelos para projetos se você quer fazer um
scripts visuais ou um tipo de fluxo de trabalho de script completo... e até mesmo o
blocos de código para edição visual são acessíveis via visual studio e podem ser
personalizado... :)

Ótimo se estiver disponível em Godot.

Cumprimentos,
Ryan

Oi Ryan

Você já conferiu o Construct 2? É um dos meus designers de jogos visuais favoritos e extremamente simples de usar.

Programação visual em Godot, acho que será um pouco difícil de fazer (como Godot faz 2d e 3d, então o escopo é muito maior).
Além disso, provavelmente será incorporado muito mais tarde, quando todos os blocos subjacentes do mecanismo estiverem no lugar.

Eu sei que reduz tem seu próprio roteiro para isso, mas espero que ele não priorize isso em relação a outras atualizações de editor/motor. Eu prefiro que Godot seja usado por programadores iniciantes ou semi proficientes do que por não programadores. Mas isso sou só eu.

Oi Ryan

Você já conferiu o Construct 2? É um dos meus designers de jogos visuais favoritos e extremamente simples de usar.

Eu tentei Construct 2. É bom e impressionante. Os jogos resultantes também são multiplataforma, por isso é uma grande vantagem. Infelizmente ainda não consigo encontrar nenhum tutorial para criar jogos de RPG com facilidade. Por enquanto posso ficar com o RPG Maker VX Ace e tentar portar meu jogo para várias plataformas (incluindo Android) com a ajuda do MKXP Project .

Obrigado por compartilhar. Estou ansioso para programação visual em Godot.

Atenciosamente,
Ryan

Para abordagem de script visual - você pode fazer anotações do gdevelop, fusão multimídia e construção 2. Esses mecanismos dependem 100% do script visual. Você ainda precisa aprender alguma sintaxe onde as expressões são necessárias, mas o editor de expressões torna extremamente fácil encontrar os comandos corretos. Esses três mecanismos dão a você a liberdade de criar qualquer tipo de jogo com scripts visuais - ao contrário do criador de jogos e do criador de rpg.

Rpg maker não é realmente um bom exemplo, pois é extremamente limitado.
Os scripts baseados em nós são muito ineficientes em termos de uso de espaço - você irá deslocar e ampliar e diminuir o zoom através de um gráfico de nós gigante. Compare isso com a construção 2, onde tudo é apresentado de forma clara e é apertado e fácil de ler - e você tem um vencedor.

O BGE é provavelmente o pior exemplo aqui, pois tenta combinar uma abordagem baseada em nós com blocos lógicos. Eu escrevi sobre por que isso é ruim:
http://blenderartists.org/forum/showthread.php?323905-comparing-BGE-logic-bricks-with-Scirra-Construct-event-sheet-for-prototyping

Se você faz scripts visuais, não faça metade com um editor genérico baseado em nós. Se você quer que mais pessoas não programadoras usem seu motor, faça algo com um design melhor - como construct2 ou fusão multimídia.

Eu gostaria de ver algo assim implementado _somente_ como uma forma secundária de programação. O script visual, ao contrário do código, diminui a produtividade em uma grande ordem de magnitude. Também tende a tornar a depuração e a refatoração muito mais difíceis. A única grande vantagem em que posso pensar (além de ser atraente para não programadores) é que o script visual tende a ser uma ótima ferramenta de ensino se for capaz de gerar, ou pelo menos mostrar, código GDScript real (ie. code. org). Eu não acho que precisaria fazer o contrário (IE. GDScript para Visual). Acho que essa seria uma ótima maneira de as escolas adotarem Godot em suas aulas.

Aqui estão duas diferenças principais entre código e script visual que eu acho que são as mais importantes no que diz respeito à acessibilidade. Isso vem de alguém que não toca em scripts visuais com um poste de três metros, mas eu entendo que isso agrada a algumas pessoas :)

Código: O código tende a ter regras de sintaxe específicas que precisam ser seguidas. Meu palpite é que isso tende a ser a principal coisa que desativa os não programadores. IE. em GDScript você deve ter dois pontos no final de uma declaração de função, if, for, while loops etc. Você deve recuar corretamente. Você deve usar a palavra-chave var ao declarar uma variável como "var myInteger = 1". Para a maioria das linguagens, tende a haver cerca de 3 ou 4 regras de sintaxe primárias que tendem a precisar ser seguidas e, na minha opinião, não são tão difíceis de aprender. Depois de escrever um punhado de pequenos roteiros, até mesmo um artista pode aprendê-los. Digo isso porque trabalho com dois artistas muito talentosos que trabalharam nos três jogos do Age of Empires com a Ensemble Studios. Um escreveu bastante código em UnityScript e o outro já escreveu uma tonelada de código em C#.

Visual: Você tende a obter um menu suspenso para o método, variável, instrução, etc. No entanto, você ainda deve saber quais funções, propriedades, etc. você está procurando e o que elas fazem e, às vezes, como elas funcionam. Você ainda deve resolver o problema. Você ainda deve usar variáveis ​​e acompanhar o que elas estão fazendo em todo o seu script. Você ainda pode ter erros lógicos tão facilmente quanto escrever código.

Eu acho que ser capaz de realmente escrever o código é, em última análise, uma maneira muito superior de ir do ponto de vista da produtividade. No entanto, nenhum dos dois fará de você um programador melhor/pior. Eu acho que o script visual é uma ferramenta de ensino muito boa, mas se você não sabe (ou quer aprender) como estruturar as coisas corretamente e especialmente como resolver problemas, o script visual não o ajudará nem um pouco.

Eu faria uma abordagem um pouco diferente. Como o editor godot é dirigido por si mesmo - é fácil recriar uma interface de editor semelhante em GDscript puro.

Então minha proposta seria fazer um construtor roteirizado inteiramente em godot e enviá-lo separadamente. Isso permitiria que programadores e não programadores trabalhassem no mesmo projeto usando ferramentas diferentes. O único problema é que os não programadores às vezes terão que lidar com as duas ferramentas ao mesmo tempo, mas ei, já vi pior xD Gridmap editor, editor de sombreamento, editor de animação, editor de código - pode ser recriado, enquanto importador collada, convexo gerador, exportadores - não tão facilmente. Ainda parece reinventar a roda, mas pode simplificar muitas coisas.

O núcleo do construtor pode ser adotado para qualquer gênero de jogo (FPS, RTS, GPS ....) com conteúdo para download e outras coisas, e se for mantido pela comunidade - será mais fácil contribuir, porque tudo é GDscript
Não é provável que haja scripts visuais no godot em breve, mas isso não impede que outros criem um construtor em cima dele. Já vi alguém pegar o Blender 2.5 e fazer uma ferramenta para projetar interiores.

Acho que ter vários editores poderia fragmentar o desenvolvimento de Godot. É preciso haver um projeto central bem projetado para uma ferramenta de script visual que seja construída em cima do gdscript.

Não seja preguiçoso e faça sua pesquisa. Veja outros mecanismos de script puramente visuais. Compare sua base de usuários (quão populares eles são), compare quão flexíveis eles são - os tipos de jogos que foram feitos com eles - seja no kickstarter, steam ou outras plataformas.
Olhe em sua abordagem de design.

Em seguida, desenhe no papel. Não basta copiar a abordagem do nó. Usar nós para shaders é bom, mas quando chega à lógica, você acaba com uma bagunça infernal para percorrer e tentar descobrir.

confie em mim, eu tentei de tudo. craque da Unity, Kismet da Unreal, criador de rpg, stencil, etc etc.
Construct2 vem em cima, junto com fusão multimídia. Esses são os mais populares, com a abordagem mais flexível. E ambos têm uma loja de mercado de ativos.
Eles são extremamente flexíveis e se você olhar para os jogos feitos com eles - há uma enorme variedade de gêneros.

Se você ficar ainda mais esperto sobre isso, você pode se juntar ao Gdevelop - outro projeto de código aberto que já possui um editor de script visual que faz jogos html5.
Olhe para o seu design e código-fonte ..

Se fôssemos votar neste tópico, tenho certeza que seria o lugar completamente errado, porque principalmente os programadores apareceriam para a votação.

Um sistema de script visual deve ser projetado para artistas, não programadores. Por mais que eu possa reclamar da minha total antipatia por coisas como PlayMaker no Unity, a verdade é que os artistas adoram. É por isso que tem quase 2000 comentários e é 5 estrelas. Se o voto é para ter algo mais parecido com o script do Construct 2, meu voto é para não ter script visual, pois não acredito que seja de nenhum benefício real, pois A) Os programadores podem programar diretamente em GDScript e B) Muitos artistas será instantaneamente desligado por ele e simplesmente irá para outro lugar. Eu sei, porque meus dois amigos artistas, que sabem codificar, estavam olhando para o Construct 2 e zombando da interface de programação que ele tem, já que é quase o mesmo que escrever código.

Uma linguagem de script visual deve ser muito visual, sem muitas palavras. Não deve parecer código à primeira vista. Deve ser adaptado para "pessoas visuais", caso contrário não faz sentido fazê-lo em primeiro lugar. Os artistas estão acostumados e tendem a gostar de gráficos de nós, pois eles dão uma noção visual do que seu programa está fazendo. Novamente, eu não gosto de gráficos de nós porque não os suporto, mas sou um programador e meu voto realmente não deveria contar nesta área.

Concordo com você que deve ser projetado para artistas/designers.
Mas discordo da lógica de que palavras = complexidade.

Se você sentar alguém para ensiná-lo a usar um dos dois - construct2 será o mais fácil dos dois. Por quê?
Porque é mais claro que os nós. Muito mais claro. Você tem condições e ações. Você coloca o primeiro no lado esquerdo e o outro no lado direito.
Para adicionar qualquer um dos dois, você não precisa conhecer os comandos. Eles estão todos listados lá para você adicioná-los - claro como um dia. Cada um vem com um ícone - que é uma dica visual.

O Playmaker e outros sistemas baseados em nós requerem muito mais aprendizado, porque conectar um nó a outro requer que você primeiro entenda se pode conectar os dois. Não é simplesmente condição -> ação. Os nós são muito mais complexos e carecem de dicas visuais. Onde você viu ícones no playmaker??
É muito mais fácil errar nele. É muito mais difícil ler a lógica nele.
https://www.scirra.com/tutorials/top
Eu também argumentaria que, como o C2 é uma ferramenta de programação visual melhor projetada, ele tem uma comunidade muito maior de usuários ativos do que o playmaker - embora esteja limitado a jogos 2D no momento. Número muito maior de tutoriais em vídeo na web (mais pessoas entendem como usá-lo do que playmaker), projetos muito mais concluídos, um mercado e fórum ativo e saudável e, acima de tudo, comunicação ativa entre desenvolvedores e usuários. Assim, os desenvolvedores sabem o que os usuários do artista querem.

Os usuários do Construct podem simplesmente tirar uma captura de tela de sua folha de eventos e fica claro como um dia como eles fizeram isso. Vá para os fóruns ver por si mesmo. Eu diria que tem muito mais usuários do que playmaker.

Eu diria que é preciso menos trabalho para configurar a lógica nele do que em qualquer sistema baseado em nó.

Eu posso ver que você gosta deles, mas por favor tente pelo menos construct2 antes de declarar que é um motor de programador.
Olhe para o seu fórum e base de usuários. Tem tanto se não mais boa reputação do que o craque. Ele conseguiu obter essa boa reputação por ser bem projetado - por conta própria - não por ser um plug-in para um mecanismo já bem-sucedido. É uma ferramenta de programação visual pura que qualquer artista pode usar. Eu sou um artista e tentei playmaker - é mais difícil do que construir2. Vá ao fórum do C2 e tente convencê-los de que o playmaker é mais fácil de usar - apenas para rir. :D
Você não é um programador mesmo? Você contribuiu para projetos do github mais do que eu. Isso não significa que você não deveria fazer a declaração que é mais fácil de aprender?

Eu entendo seus pontos da perspectiva de um programador. Se eu tivesse que escolher entre os dois, eu iria com o modelo Construct também. No entanto, como eu disse, este é o pior lugar para tomar essa decisão, porque provavelmente a maioria, se não todas as pessoas que lêem as listas de discussão do GitHub, são programadores.

Passei mais da minha carreira em torno de artistas do que em torno de programadores. Embora eu tenha feito os dois regularmente nos últimos 18 anos (e tenha sido apaixonado por ambos), eu era profissionalmente um artista antes de ser profissionalmente um programador. Não que eu me importe que eu tenha um diploma, meu diploma é em Animação Digital e Efeitos Visuais. Até onde sei, os comerciais em que trabalhei ainda são reproduzidos depois de vários anos em Kansas City. Trabalhei em fotos para Hallmark, Sprint, Radio Shack, Honda e algumas outras que provavelmente estou esquecendo. Eu também me diverti muito trabalhando em algumas cenas em "World Builder" com Bruce Branit.

https://www.youtube.com/watch?v=QP3YywgRx5A
Nathan Warden nos créditos sou eu

Não estou dizendo isso para me gabar, estou dizendo isso para fazer um ponto. Posso estar errado, mas como um artista que passou muito tempo com artistas, acho que sei do que os artistas gostam. Eles não tendem a gostar muito de coisas como Constructor. Eles tendem a se sentir íntimos e escolhem um aplicativo totalmente diferente. Artistas em geral têm uma mentalidade muito diferente dos programadores. É como quando falo com meu amigo Erik sobre coisas técnicas que estou tentando ensinar a ele, essas palavras saem da boca dele com bastante frequência: "Nate, sou uma pessoa muito visual, se você não pode me mostrar visualmente você pode estar falando com a parede".

Há uma razão pela qual os artistas gostam de coisas como gráficos de sombreamento baseados em nós, em oposição a sistemas de sombreamento lineares. Eles podem visualizar o que está acontecendo. Acho que nunca ouvi um artista reclamar por não ter um sistema de sombreamento linear em seu aplicativo 3D favorito, mas eles reclamam regularmente quando não têm um sistema de sombreamento baseado em nó.

Há uma razão pela qual os artistas preferem aplicativos como o Fusion ao After Effects. Em praticamente todos os casos, eles escolherão algo baseado em nó em vez de linear porque é mais visual.

Então, mais 2 razões pelas quais um sistema baseado em nó atrairá artistas:

1) Eles parecem visualmente muito mais atraentes.
2) Encaixa-se no paradigma de design ao qual já estão acostumados. IE Sombreamento e Composição

Isso é realmente o que importa. Se o artista vai dar uma olhada e passar para o próximo motor de jogo porque o outro tem programação baseada em nós, então Godot não deveria ter scripts visuais, porque provavelmente não haverá mais do que um punhado de pessoas quem irá usá-lo e isso significa apenas mais manutenção de código a partir desse ponto.

Tem certeza de que tem alguma ideia do que é Construct2? Você nem está soletrando seu nome corretamente.
Não é chamado de "Construtor" .

Eu discordo completamente que devemos usar nós porque "não deve parecer código à primeira vista".

É mais importante quão claro é do que como parece. A clareza do que a lógica faz é mais importante do que a aparência do editor à primeira vista. Construct2 não se parece com código - o texto é escrito em inglês simples e é óbvio o que uma ação ou uma condição faz. As pessoas que usam C2 tendem a ser principalmente pessoas visuais também.

Uma folha de eventos sempre vencerá os nós - no entanto, você tenta fazer com que pareça. Ele pode empacotar mais informações na tela com menos movimento - é mais óbvio o que a lógica faz. E as pistas visuais (ícones) são muito mais fáceis de encontrar pelo olho do artista.
Os nós não têm ícones e uma enorme limitação de texto.
Portanto, em muitos casos, um nó nem sequer descreve claramente o que faz, devido ao tamanho limitado dele - forçando o design a usar terminologia obscura em vez de inglês simples.

Outro ponto:
Uma folha de eventos é lida e executada de cima para baixo. Isso é óbvio e previsível.
Com uma rede de nós, seus olhos viajarão por todo o lugar, eles se dividirão em ramificações. Fica bem mais complicado.

Histórias de opinião em terceira pessoa nos primeiros vislumbres e não na experiência real do usuário não devem ter peso aqui. Eu também sou uma pessoa muito visual, mas que já usou muitos mecanismos de script visual. É uma dor de cabeça absoluta ver as pessoas argumentando sem usar os motores reais por um tempo - com um pequeno projeto, por exemplo.

Peço aos designers/desenvolvedores/pessoas visuais da Godot que realmente experimentem esses motores em um projeto de pequena escala e então cheguem a conclusões. Chega dessas histórias de terceiros. Precisamos de pesquisa prática e casos logicamente declarados de por que um é melhor que o outro. Acredite ou não, as pessoas visuais também têm bom senso.

Fora do assunto:
No exemplo de Fusion vs Aftereffects - as pessoas preferem uma abordagem baseada em nó para composição, porque usar camadas pode ser muito complicado em uma cena complicada onde o mesmo efeito pode ser duplicado em muitas camadas. Com nós, você pode ter mais flexibilidade em termos de composição e apenas conectar um efeito a muitas camadas. Mas os nós são mais complicados do que as camadas.

Concordo com você em praticamente todos os pontos, mas esses pontos ainda são da perspectiva de um programador. Se eu tivesse que usar um sistema de script visual o dia todo, escolheria aquele que mais se parecesse com o código normal. É por isso que sou um grande fã de ensinar crianças que querem aprender a programar usando code.org. Eu sou realmente um grande fã do estilo. É bom para ensinar as pessoas que "querem" programar a programar.

E sim, eu disse Construir errado, desculpe. Não, eu não usei pessoalmente. Mas, isso não importa, porque o paradigma de script que ele usa não é um conceito novo por qualquer extensão da imaginação, então meu argumento nem é sobre o Construct em si. É sobre esse estilo de script no que diz respeito aos artistas, não aos programadores.

Em um sistema baseado em nó, você pode ter várias condições, eventos e funções contidos em cada nó. Você pode então nomear o nó como Input, por exemplo. Dentro dele, ele conterá todas as entradas do joystick e o usuário informará qual evento usar. IE. eles especificariam um evento como "Fogo". Esse evento causaria uma transição para qualquer nó ao qual eles o conectassem.

Aqui está um exemplo simples que você poderia ter em uma arma que simplesmente lidaria com o disparo. Observe que, embora seja simples, também é poderoso e não se parece com código:

Em uma nota final, você pode fazer scripts baseados em blocos ou scripts baseados em nós parecerem muito bons do ponto de vista da interface, então não vou perder meu tempo discutindo esse ponto.

No entanto, quando eu disse "Não deve parecer código à primeira vista". Muitos artistas se preocupam com o que vão ver o dia todo, todos os dias, por um período indefinido de tempo. Eles rejeitarão um aplicativo inteiro se não parecer atraente ou se parecer intimidador. Eu diria que o bloco baseado parece intimidante e confuso para um artista típico. Parece algo para programadores, e é.

@blurymind ,

Os nós de gráfico na verdade vieram da UML conceitual. Você faz a representação gráfica do código de uma forma que o público não programador (gerentes de projeto, consumidores, artistas) possa entender. Isso é o que o UE4/Unity usa. Isso é algo que todos na indústria estão cientes. Os construtores geralmente adotam uma abordagem diferente, e quão boa essa abordagem é - não é definida pelo número de usuários que a usa.

Há sempre uma curva de aprendizado em todos os lugares, e o Construct2 não é uma exceção. Mas não vamos forçar coisas C2 em Godot sem apoiar os argumentos. A folha de eventos se tornará mais longa com jogos mais complexos e acabará desperdiçando mais espaço do que os nós do gráfico. Apenas o botão "Adicionar ação" tem sua própria linha. É basicamente como um programador interpretaria um bloco de código. Então não é tão ruim.

Pessoalmente, não vejo por que não podemos ter os dois, mas os desenvolvedores já têm o suficiente para fazer isso não acontecerá tão cedo. É por isso que propus uma abordagem diferente que evoluirá mais rapidamente, praticamente impulsionada por não programadores em cooperação com programadores.

Aqui está um exemplo melhor para mostrar que você pode ter mais de um evento por nó. Observe também que cada nó (ou estado) não é bloqueante, portanto, permitirá que outros gráficos de nós sejam executados simultaneamente:

Mas veja, apenas olhando sua captura de tela, não tenho ideia do que essa lógica faz. O que diabos é "firePrimary" e "fireSecondary" ??
Agora role até a captura de tela que postei de construct2.
Em construct2, a condição à esquerda lerá "em "R" pressionado" ou algo que esteja em inglês simples - com um ícone de teclado ao lado!

Mostre os dois a um artista e pergunte qual é mais claro.

Mostre-nos também uma configuração de nó mais elaborada :) A captura de tela do C2 mostra toda a lógica do jogo. O seu é apenas um evento. Você pode encaixar a mesma lógica em uma captura de tela com nós? Acho que não.

Veja o exemplo de nó que está obscurecendo informações.
Você tem que selecionar um nó para ver o que está definido dentro dele.
Ele está usando terminologia de programador obscura em vez de linguagem humana ("Enviar evento", "Armazenar resultados" que diabos?).
O Construct2 mostra tudo em um só lugar e é compreensível para quem não é programador. O objetivo da programação visual é livrar-se da necessidade de aprender terminologia.

Eu não sou um programador. Eu não tenho nenhuma experiência em escrever código real. No entanto, posso fazer um jogo com construct2 facilmente e, para mim, usar nodes é muito mais difícil - quando se trata de um jogo completo.

Entendo que todos sempre votarão no que já sabem fazer bem. Mas como você admitiu, você é um programador e não usou C2. E mantenho a afirmação de que sou um artista sem experiência em codificação - que usou os nós e a abordagem C2.

Estou lhe dando bons argumentos lógicos sobre por que usar um sobre o outro.
Você está me dando declarações como "nós são mais visuais" e "nós de usos irreais". Essas são declarações opinativas. E vocês dois admitem ser programadores.

Dizer que não estou apoiando meus argumentos é apenas uma confirmação de que você não deseja examinar construct2 ou considerar seu design como uma alternativa aos nós. Infelizmente, é um desperdício do meu tempo convencê-lo do contrário.

@TheoXD
Concordo plenamente com você se estou lendo corretamente. Seria bom ter ambos como um plugin/módulo separado. Então, por baixo estaria o GDScript real, mas você pode visualizá-lo usando o que quiser. Eu acho que isso é possível. A abordagem baseada em nó pode precisar de alguns sinalizadores como comentários especiais para separar nós (IE. #node name="Input" e #endnode), mas não é um grande problema, pois seria automático se você começasse com o gráfico de nó. Eu acho que a abordagem do bloco seria direta.

É algo assim que você quis dizer?

Como eu disse acima, gosto muito do método block/Construct/code.org, pois funciona muito bem para ensinar programação. Só não acho que seja uma boa opção para pessoas que veem a programação como um mal necessário.

@blurymind
A razão pela qual não faz sentido é porque você não está familiarizado com isso. Quando olho para a imagem do Construct acima, também não tenho ideia do que está acontecendo, não porque seja ruim, mas porque não estou familiarizado com ela.

No que diz respeito a não ser capaz de ver o que está sob um nó até clicar nele, uma vez que você configurou um nó, não há sentido real em filtrar o que você já sabe que está lá. Eu já sei que eu cliquei com o botão esquerdo e direito e que eles disparam munição primária e secundária. Eu já sei o que os nós de fogo primário e secundário fazem. Não mudou desde que o fiz, por que tenho que ver os detalhes toda vez que olho para ele? Então, agora a lógica subjacente é apenas desordem. Esta é outra razão pela qual os nós são mais amigáveis ​​para artistas e não programadores. Eles podem quebrar sua lógica específica em pedaços mais gerais. Isso faz com que eles possam obter uma visão geral e se preocupar apenas com os detalhes quando for absolutamente necessário.

Estou olhando para um projeto real para um jogo móvel publicado real agora e quase todos os gráficos de nós são de 2 a 4 nós no máximo, então é difícil mostrar uma configuração mais elaborada quando você normalmente não precisa de uma configuração elaborada.

Se você quiser elaborar, isso é do mesmo aplicativo que foi escrito por uma pessoa que é tão não programadora quanto possível. Este é um dos gráficos mais complexos do jogo. Ele controla o movimento do jogador principal:

(Isso é outra coisa que você não pode fazer com blocos é fazê-los parecer o navio de Samus, haha)

Sem nenhum aviso, apenas coloquei sua imagem Construct2 em uma tela e coloquei o gráfico de nós acima na outra e perguntei à minha esposa (que definitivamente não é programadora): "Qual você gostaria de usar se tivesse que usá-lo todos os dias?", e ela apontou para o gráfico de nós e disse: "Este aqui". Eu sei que isso não é definitivo, mas o fato de ser menos intimidante significa que eu tenho muito mais chance de começar a fazê-la aprender. Se parecer intimidante, ela pode desligar o cérebro antes mesmo de eu conseguir que ela se sente para aprender o básico.

Sem empurrá-lo para um ou outro, também perguntei ontem ao meu amigo artista (o mesmo que trabalhou nos três jogos do Age of Empires), que está na indústria de jogos há quase 20 anos (e que usou o Construct2) o que ele acha que outros artistas prefeririam e ele também disse que o gráfico de nós.

De qualquer forma, eu realmente gosto da discussão, mas não faz sentido bater em um cavalo morto, haha ​​:)

Sim, eu também gosto. Sem sentimentos ruins :)

Incrível navio Samus btw. Quanto mais fotos você postar, mais você apóia meu argumento de que os nós são visualmente mais difíceis de seguir, pois eles podem se dividir em ramificações e seguir em direções malucas.
Para mim, a complexidade adicional de ter que seguir linhas e setas entre os blocos sempre pareceu um trabalho extra. Acho que devo dar aos nós outra tentativa um dia desses. Se for para onde Godot estará indo.

Novamente, você está nos dando histórias em terceira pessoa que não são realmente apoiadas por evidências. Traga o cara aqui e peça para ele nos dizer PORQUE ele prefere um pelo outro :)
Então você terá um caso mais forte. Não estou recebendo nenhum ponto logicamente sensato que apoie a tese de que os nós são mais diretos até agora.

sim, parece menos intimidante à primeira vista porque está escondendo muitas informações. Seus exemplos são muito mais simples do que o mostrado na captura de tela que postei. Isso é enganoso.
Aqui está um vídeo que mostra quente para configurar a lógica para um jogo de plataforma em C2.
https://www.youtube.com/watch?v=5RlSmkSbleI
pule o primeiro minuto :P

Não vamos comparar maçãs com laranjas.
Code.org é uma abordagem radicalmente diferente do Construct2 - parece mais com o Stencyl e tem uma das desvantagens dos nós: Suas condições e ações não estão claramente separadas - então é mais difícil descobrir o que você pode anexar ao quê. Ferramentas de programação visual bem projetadas (Multimedia fusion, construct2, gamedevelop) separam todas as condições das ações claramente para o usuário. Isso torna muito mais fácil construir a lógica, pois eles são organizados para você pelo software que está adivinhando o que você pode precisar e mostrando para você no momento certo. também evita que você cometa erros bobos.

Com nodes/stencyl/code.org você tem que descobrir qual peça é uma condição, qual é uma ação. É preciso mais descobrir para configurar suas condições da maneira certa. Que tipo de informação está saindo de um nó? Algumas vezes são necessários mais nós para configurar uma condição - mais aprendizado como conectá-los.
Vamos lá, faça sua pesquisa e realmente use as outras ferramentas um pouco. Ver todos os que não são nós como mais do mesmo não está ajudando.

@blurymind , seu caso é até agora respaldado pela quantidade de usuários que usam o Construct2, que geralmente é resultado do modelo de negócios do software e de quão bons eles são em marketing. A preferência pessoal (seus argumentos lógicos) não é suficiente para forçar o fluxo de trabalho C2 em Godot. Mas é uma boa referência.

Se você mostrasse a alguém como você gostaria de construir seu jogo (relação objeto-objeto) no papel ou no quadro-negro, como você o mostraria? Escrevendo uma árvore de eventos? Não. Você desenharia uma visão conceitual com nós e linhas, então pensaria neles como classes, adicionaria funções, membros.
Eu concordaria que a tabela de eventos se parece mais com um código, apenas interpretado por um programador, e pode fazer com que os usuários queiram aprender programação real à medida que avançam. Eu notei que tem alguma terminologia e curva de aprendizado também, você não pode negar isso. Mas o reconhecimento de formas e o agrupamento de objetos são realmente uma coisa real. Eu estudo um curso sobre visualização de dados e, além de quão chato pode ficar - na verdade, faz bons pontos.

Por mais que eu queira ver essa edição com mais de 100 comentários, os desenvolvedores não vão ler todos, o melhor que cada um de nós pode fazer é fazer um PDF com as propostas e compartilhá-las na lista de discussão. Não vejo por que não podemos ter diferentes níveis de abstração, nós Graph como nível superior, que podem ser representados na forma de uma árvore de eventos. Se isso funcionar, não haverá necessidade de compromisso.

" @blurymind -- || -- E vocês dois admitem ser programadores." - Eu não me considero apenas um programador, faço arte também sabe. Eu uso minha experiência para olhar as coisas de um ponto de vista objetivo.

Não tenho certeza se isso passou despercebido, mas também não sou apenas um programador, mas também um artista profissional. Eu acho que a maioria dos programadores realmente se beneficiaria pulando na arte por um tempo. Faz programar certas coisas fazer muito mais sentido e também ajuda a superar a rivalidade programador/artista, haha ​​:) Eu sei que isso é mais ideal, e não muito prático para a maioria das pessoas.

Aqui estão alguns links para alguns dos meus trabalhos (procure Nathan Warden nos créditos)

World Builder (envolvido em cerca de metade dos tiros)
https://www.youtube.com/watch?v=VzFpg271sm8

Teddy Scares (estava envolvido na maioria dos tiros)
https://www.youtube.com/watch?v=qCXIzS_iY0k

Hallmark Crown Center (O terceiro tiro com o Papai Noel)
https://www.youtube.com/watch?v=biqBq3_Whqk

Aqui está uma renderização do prédio do meu Louie. Se você assistir World Builder, verá algumas das obras de arte que eu tirei dele e coloquei no filme.

E aqui está uma renderização inacabada de um tanque HK estilo Terminator 1 esmagando Christine de Stephen King. Ambos os modelos são feitos por mim, mas acho que nada mais foi feito na foto.

E muitos mais que eu poderia citar, mas acho que o ponto está feito. :)

Bem, essas são fotos incríveis - mas, novamente, você está fazendo isso para se dar mais autoridade. Isso não está ajudando a apoiar logicamente a ideia de que os nós são melhores que a folha de eventos :)

Se você for com nós, será como qualquer outro mecanismo de jogo 3D que usa programação visual.

Eu acho que isso não é uma boa ideia por uma série de razões.

-Recentemente, a Unreal liberou seu motor - também é multiplataforma. É um motor muito mais maduro que o BGE/Godot. Então você está competindo diretamente com eles ao copiar sua abordagem de programação visual.

-Os nós são muito menos eficientes na tela do que uma folha de lógica. Eles são mais difíceis de ler/seguir.

-Scirra anunciou que construct3 será multiplataforma - o editor funcionará em windows, linux e mac.
No entanto, eles não são de código aberto.
https://www.construct3.com/

Isso criou uma onda de comentários na comunidade scirra. Muitos usuários querem uma série de coisas que Godot pode oferecer sem a programação visual:
-Arquivos exe nativos em vez de contêineres html5 - para melhor desempenho
-suporte para desenvolvimento de jogos 3d, usando o estilo folha de eventos na construção para programá-lo:
https://www.scirra.com/forum/construct-3_t90881

se eles fizessem um editor 3D simples e compreensível como a ferramenta 2D dentro do C2 eu usaria totalmente

eu tentei unity, blender, torque 3D, UDK, porque eles são os mais anunciados e os que a maioria dos chamados devs famosos usam ... e eles compartilham os mesmos problemas: eles não são amigáveis ​​​​(nada) e se você nunca usei uma API de criação de jogos 3D antes... bem, você é 3Doomed (ikno de piada de mau gosto)

o fato é que o construct é muito intuitivo uma vez que você cobre o básico e te dá liberdade para fazer jogos 2D complexos, te dá vários caminhos para fazer o mesmo resultado (sem contar que o sistema de eventos FAZ SENTIDO para mim); qual é o detalhe que a maioria dessas outras ferramentas não cobrem ou o tornam mal

se eles fazem um motor 3D com o mesmo fluxo e sentimento que eu tenho usando C2; então por que não experimentá-lo?

Eles têm uma enorme base de usuários no momento (que adora o estilo de folha de eventos para programação visual, mas deseja esses recursos) e alguns deles estão prontos para dar um salto para outro mecanismo. Há um grande potencial aqui para Godot trazer muitos novos desenvolvedores independentes a bordo - aqueles que preferem isso a nós - aqueles que não estão usando o mecanismo Unreal - que agora é gratuito e muito mais maduro que o Godot.

Se você optar por ele em vez de nós, será o primeiro mecanismo que suporta o desenvolvimento completo de jogos 3D com esse design de programação vis. Você estará acessando uma nova base de usuários, em vez de competir com Unreal (gratuito), Unity (versão gratuita disponível)

Bem, essas são fotos incríveis - mas, novamente, você está fazendo isso para se dar mais autoridade.

As fotos e links não são prova da minha autoridade, mas das pessoas com quem trabalhei e que não estou apenas inventando :) Isso inclui alguns dos meus bons amigos que trabalharam em alguns filmes dos quais você já deve ter ouvido falar Avatar, King Kong, Serenity, e shows como Lost, Revolution, etc... E alguns de meus outros amigos que trabalham na indústria de games há mais de 15 anos. Todos preferem um fluxo de trabalho baseado em nó em vez de um fluxo de trabalho linear baseado em folha. Eu provavelmente poderia obter uma cotação de 3-4 deles dizendo que eles preferem gráficos de nós em vez de folhas de lógica, se você quiser?

Recentemente, a Unreal liberou seu mecanismo - também é multiplataforma. É um motor muito mais maduro que o BGE/Godot. Então você está competindo diretamente com eles ao copiar sua abordagem de programação visual.

O fluxo de trabalho de script visual é a última coisa que as pessoas verão ao comparar Godot com esses mecanismos. A primeira coisa que eles notam é que o Unreal suporta DirectX 12 e OpenGL 4 e que suas demos e exemplos são impressionantes, então eles começarão a olhar para as outras coisas. A principal coisa que Godot tem sobre essas empresas é que é um software FLOSS e que qualquer um que o use é igualmente um proprietário pleno do software.

Os nós são muito menos eficientes na tela do que uma folha lógica. Eles são mais difíceis de ler/seguir.

Embora seja óbvio pela sua declaração que você não usou uma boa configuração baseada em nós, se você está preocupado com coisas como eficiência da tela, então você não deveria estar usando scripts visuais de qualquer maneira, você deveria estar usando o script real que já está disponível :) Eu garanto a você que qualquer coisa que o script visual possa oferecer em termos de espaço na tela, o script regular também pode fazer isso, como o colapso de regiões de código.

Se você optar por ele em vez de nós, será o primeiro mecanismo que suporta o desenvolvimento completo de jogos 3D com esse design de programação vis.

Há uma razão pela qual mecanismos como o Unreal, que gastam muito tempo, dinheiro e pesquisa sobre as necessidades de seus clientes, não adotam essa forma de script visual e escolhem nós.

A minha opinião sobre isso é que tudo depende da abordagem que pretende ser
resolvido.

Blocos de ação como Game Maker são interessantes, mas acho que é mais
projetado para uma substituição da programação.

A abordagem do Unreal é mais como um complemento à programação, então
designers podem trabalhar no jogo eles mesmos e tirar o trabalho do
programador. Isso é muito mais útil em equipes (Artistas e Game designers
pode usá-lo bem) e é definitivamente a abordagem que eu gostaria de adicionar
Godot por causa disso.

Devido à arquitetura Godot, também seria muito fácil adicionar, então darei
é um tiro em 1.2

Em terça-feira, 3 de março de 2015 às 16h37, Nathan [email protected] escreveu:

Bem, essas são fotos incríveis - mas, novamente, você está fazendo isso para dar
você mesmo mais autoridade.

As fotos e links não são prova da minha autoridade, mas das pessoas que eu
trabalhei e que não estou apenas inventando :) Isso inclui alguns dos meus
bons amigos que trabalharam em alguns filmes dos quais você já deve ter ouvido falar, como
Avatar, King Kong, Serenity, e shows como Lost, Revolution, etc... E
alguns dos meus outros amigos que trabalharam na indústria de jogos por mais de 15
anos. Todos preferem um fluxo de trabalho baseado em nó em vez de um fluxo de trabalho linear baseado em folha
fluxo de trabalho. Eu provavelmente poderia obter uma citação de 3-4 deles dizendo que
eles preferem gráficos de nós em vez de folhas de lógica, se você quiser?

Recentemente, a Unreal liberou seu mecanismo - também é multiplataforma. É um
motor muito mais maduro do que BGE/Godot. Então você está competindo com eles
diretamente ao copiar sua abordagem à programação visual.

O fluxo de trabalho de script visual é a última coisa que as pessoas serão
olhando ao comparar Godot a esses motores. A primeira coisa que eles vão
aviso é que o Unreal suporta DirectX 12 e OpenGL 4 e que suas demos
e exemplos parecerem impressionantes, então eles começarão a olhar para as outras coisas.
A principal coisa que Godot tem sobre essas empresas é que é FLOSS
software e que qualquer pessoa que o use é igualmente um proprietário pleno do
Programas.

Os nós são muito menos eficientes na tela do que uma folha lógica. Eles são mais difíceis de
ler/seguir.

Embora seja óbvio pela sua declaração que você não usou um bom nó
configuração baseada, se você está preocupado com coisas como eficiência da tela, então você
não deveria estar usando scripts visuais de qualquer maneira, você deveria estar usando o real
script que já está disponível :) Eu garanto que qualquer coisa
scripts visuais podem oferecer a você em termos de espaço na tela scripts regulares
pode fazê-lo também, como recolher regiões de código.

Se você optar por ele em vez de nós, será o primeiro mecanismo que
suporta o desenvolvimento completo de jogos 3D com esse design de programação vis.

Há uma razão pela qual motores como o Unreal, que gastam muito tempo, dinheiro
e a pesquisa sobre as necessidades de seus clientes não combinam com essa forma de
scripts visuais e escolheu nós em vez disso.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -77017857.

Eu dei uma boa chance ao Playmaker e devo dizer que gostei - mais do que o kismet / blueprints da irreal.

No playmaker, os nós são como recipientes nos quais você coloca ações. Algumas das ações são Verificando uma condição que pode levar a outro nó.

Como você mesmo cria os contêineres de nó e pode nomeá-los, as ações neles são executadas de maneira previsível (de cima para baixo) - é algo com o qual posso conviver. :)

Além disso, as ações que você coloca dentro de um nó são, na verdade, scripts de unidade padrão com entradas visuais. Assim, as pessoas poderão escrever seus próprios scripts e adicioná-los como ações personalizadas.

Por favor, olhe para o playmaker e implemente um sistema baseado em nó que seja mais parecido com ele, em vez de Unreal.
A vantagem é, claro, que podemos fazer mais com menos nós, eles são mais fáceis de ler e depurar e são mais previsíveis.

Aqui está uma introdução de como funciona:
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10

É muito flexível e permite ao usuário adicionar e compartilhar facilmente a funcionalidade do jogo - fácil de reutilizar.

Discussão fascinante. Só quero apontar outro tipo/forma de script visual além de nós e folha de eventos do C2, mas blocos de script que se encaixam como peças de quebra-cabeça. Usado no motor 2d Stencyl http://www.stencyl.com/

baseado no MIT Scratch http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(block)

e no Unity eu uso pessoalmente, Blox http://www.plyoung.com/blox/

Pessoalmente, não estou convencido com a programação "visual" semelhante a arranhões. eu
acho que é praticamente como programação.
A maneira como a Unreal faz isso eu acho que é amigável para designers de jogos/níveis

Em sáb, 21 de março de 2015 às 23h57, todheil [email protected] escreveu:

Discussão fascinante. Só quero apontar outro tipo/forma de visual
scripts diferentes de nós, mas blocos de script que se encaixam como
peças de quebra-cabeças. Usado no motor 2d Stencyl http://www.stencyl.com/
[imagem: stencil_blocks]
https://cloud.githubusercontent.com/assets/8675463/6767767/d52e7b16-d013-11e4-878c-29002dc04f8e.PNG
baseado no MIT Scratch
http://wiki.scratch.mit.edu/wiki/Wait_Until_ ()_(bloco)
[imagem: scratch_example]
https://cloud.githubusercontent.com/assets/8675463/6767792/57f50e5c-d014-11e4-8015-9228bb6001d8.PNG
e no Unity eu uso pessoalmente, Blox http://www.plyoung.com/blox/
[imagem: hello_blox]
https://cloud.githubusercontent.com/assets/8675463/6767796/7849f46a-d014-11e4-9244-9e45c601f883.PNG

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84508001.

_OkamStudio_

Bom ponto. Para mim, os blocos são o meio termo entre as linhas de código e os fluxogramas.

Eu não gosto da forma de programação visual de rascunho/estêncil. Seu layout é
visualmente mais difícil de seguir do que blocos construct2 e até nós. Isto é
literalmente juntando peças de quebra-cabeça e sofre com a questão de
descobrir qual peça se encaixa onde. Não são fáceis de colocar
juntos

Em dom, 22 de março de 2015 às 5h46, todheil [email protected] escreveu:

Bom ponto. Para mim, os blocos são o meio termo entre as linhas de código e o fluxo
gráficos.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415.

ok, eu não vou ler tudo agora, mas apenas meus 2 centavos sobre este tópico.

motores baseados em eventos são criados para fazer protótipos e pequenos projetos de jogos
motores como o godot são criados para fazer todo tipo de projetos

Então são duas coisas diferentes com duas abordagens diferentes, são duas
pedágios diferentes

para ser honesto, eu não posso usá-los bem. (pedágios baseados em eventos)

Para mim, a melhor abordagem são dois pedágios paralelos.

22/03/2015 6:49 GMT-03:00 Todor Imreorov [email protected] :

Eu não gosto da forma de programação visual de rascunho/estêncil. Seu layout é
visualmente mais difícil de seguir do que blocos construct2 e até nós. Isto é
literalmente juntando peças de quebra-cabeça e sofre com a questão de
descobrir qual peça se encaixa onde. Não são fáceis de colocar
juntos

Em dom, 22 de março de 2015 às 5h46, todheil [email protected] escreveu:

Bom ponto. Para mim, os blocos são o meio termo entre as linhas de código e o fluxo
gráficos.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84575752.

David Aguiar de Aquino Paiva

a única coisa que seria útil é o sistema de unidade "comportamental",
basicamente é um script que faz algo, então isso em godot seria
traduzir como a possibilidade de adicionar mais de um script por nó.
Claro, eu poderia criar um nó e apenas cloná-lo, mas um script seria um
recurso e, em seguida, seria apenas carregá-lo em um nó e adicionar um comportamento (por
exemplo, um script de salto)
No editor podemos ver as exportações categorizadas sob o nome do script.

2015-03-26 13:15 GMT-03:00 David Paiva [email protected] :

ok, eu não vou ler tudo agora, mas apenas meus 2 centavos sobre este tópico.

motores baseados em eventos são criados para fazer protótipos e pequenos projetos de jogos
motores como o godot são criados para fazer todo tipo de projetos

Então são duas coisas diferentes com duas abordagens diferentes, são duas
pedágios diferentes

para ser honesto, eu não posso usá-los bem.

Para mim, a melhor abordagem são dois pedágios paralelos.

22/03/2015 6:49 GMT-03:00 Todor Imreorov [email protected] :

Eu não gosto da forma de programação visual de rascunho/estêncil. Seu layout é

visualmente mais difícil de seguir do que blocos construct2 e até nós. Isto é
literalmente juntando peças de quebra-cabeça e sofre com a questão de
descobrir qual peça se encaixa onde. Não são fáceis de colocar
juntos

No domingo, 22 de março de 2015 às 5h46, todheil [email protected]
escreveu:

Bom ponto. Para mim, os blocos são o meio termo entre as linhas de código e o fluxo
gráficos.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415
.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -84575752.

David Aguiar de Aquino Paiva

David Aguiar de Aquino Paiva

Ei pessoal! Boa discussão está aqui :) Gostaria de acrescentar algo.

Primeira coisa: sou estudante de arte, mas programar é meu hobby. Conheço Java, Python e (meu favorito) Golang. Mas antes de aprender a codificar (cerca de 3 anos atrás), tentei quase todos os programas que afirmam permitir "criar jogos sem programação". Todas essas alegações são um disparate.

Tentei (sem ordem específica): Click & Play, GameMaker, The Games Factory, Multimedia Fusion, Construct 1, RPG Maker, Stencyl, BGE e alguns outros que nem lembro. E minha opinião é: Você pode fazer um jogo sem _escrever_ código, mas não sem _programar_. Mesmo se você estiver usando folhas de eventos ou nós, você ainda precisa entender a _lógica de programação_. Você tem que saber o que é condicional, evento, variável, string etc. Então é impossível criar um jogo sem programação. Todos esses métodos visuais de codificação são apenas uma maneira diferente de expressar a lógica que está nas linguagens de programação tradicionais. Todo esse argumento pode parecer óbvio, mas garanto que não era óbvio para mim no início da minha aventura com programação.

A partir disso, segue minha próxima consideração:

A melhor e mais intuitiva linguagem de programação visual que encontrei antes de aprender a codificar é o Scrach/Stencyl puzzle/blocks way. Aqui está o porquê:

• esta solução é a mais próxima da programação tradicional. Na verdade, é apenas algo como açúcar de sintaxe para código subjacente (basicamente é como o Stencyl funciona) Para mim, é mais limpo e fácil de seguir ou criar algo que pareça um código sofisticado colorido do que gráficos de nós ou folhas de eventos desordenadas que você não pode colocar em estruturas agradáveis ​​como funções. Para mim _isso_ é uma bagunça
  Lembre-se que esta é apenas a minha opinião

*Acho que os blocos Scrach/Stencyl são o método mais visual e fácil de seguir. Eles usam cores extensivamente (e pessoas com visão visual gostam de cores) É fácil lembrar que amarelo = condicionais e loops, verde = matemática, azul = variáveis ​​etc. Também parece código real (em contraste com nós), mas mais amigável.

Finalmente, não acho que a programação visual deva ser prioridade tão cedo. Há muitas coisas mais importantes a fazer (roteiro completo + documentação) e suponho que implementar qualquer um desses sistemas não seja rápido e fácil. Godot é IMHO muito fácil de trabalhar como é agora. Ele contém muitas ferramentas que podem ser usadas pelo artista em cooperação com os desenvolvedores do jogo (editor de sombreamento visual, editor de animação, nó tilemap).

POR FALAR NISSO. Gostaria de aproveitar esta oportunidade e agradecer a todos os criadores e colaboradores da Godot. Você fez um excelente trabalho :+1:

BTW2. Me desculpe pelo meu Inglês. Estou fazendo o meu melhor, mas ainda estou cometendo erros bobos :cry:

seja construct2 ou blox - ambos são melhores para mim do que esses gráficos de nós.

Se o sistema usa nós apenas como contêineres para ações (como estados) - do jeito que está no Playmaker, vou ficar bem com isso.

O bom tanto do blox quanto do construct2 é que o editor mostra todas as condições e ações disponíveis. Ele os separa para você e os coloca em categorias. Essa é uma mudança dramática na apresentação que permite que um não codificador faça muito com o mecanismo imediatamente - sem precisar saber os nomes dos comandos para fazer as coisas.

se você usar nós para programação visual - o maior desafio seria comunicar ao usuário em que ordem os eventos estão sendo executados. No Unity - tanto o craque quanto o blox fazem isso de forma muito limpa.

No playmaker, empilhando ações dentro de contêineres de nós (estado - contém ações). Em blox - onde você tem estados que contêm funções.

Eles dão acesso completo à maioria dos recursos do unity. Isso é muito bom para não programadores.
O blox foi desenvolvido em "plygame" - outro addon de unidade que possui blox + alguns scripts personalizados que o blox pode acessar para criar um jogo inteiro no estilo rpg hack and slash.

Blox em unidade é o mesmo que blocos Skrach/Stencyl. Parece haver muitas pessoas aqui que gostam desse estilo de programação :)
https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k

Espero que os desenvolvedores de Godot experimentem.
Aliás, a tecnologia Skratch (https://scratch.mit.edu/) é de código aberto! E outros vêm adotando - não apenas stencil. O Google também se interessou muito por isso:
https://developers.google.com/blockly/

proposta - Por que não tentar ter o melhor dos dois mundos! Nós para uma máquina de estado - blox/skratch/stencyl para expressões.
Em um mundo ideal, você teria nós sendo usados ​​como contêineres de estado - como no Playmaker. Mas os contêineres de estado teriam blox/stencyl/skratch como o sistema lego que permite ao usuário configurar facilmente a lógica - não há necessidade de aprender a escrever expressões dessa maneira - eles estão prontos para serem arrastados e soltos.

http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

Um dos desenvolvedores do iCanScript disse isso sobre seu ativo VS:

O avanço técnico do iCS2 o desvincula de ser um produto somente Unity, aumentando significativamente as oportunidades de mercado. A visão final é que o iCS2 será um auxílio ao desenvolvimento que pode ser usado para criar scripts para outros mecanismos de jogo, bem como para aplicativos Windows/OSX/iOS/Android padrão.
http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post -2124402

que confusão de nós é o iCanScript!

De qualquer forma, vale a pena tentar antes de julgar. Talvez alguém possa entrar
contato com o desenvolvedor?
Se a godot tivesse um mercado com oportunidades de lucro - como aquele
unity faz - talvez isso atraia desenvolvedores de unity para criar ativos para
Godot também.

No sábado, 23 de maio de 2015 às 16h24, todheil [email protected] escreveu:

Um dos desenvolvedores do iCanScript disse isso sobre seu ativo VS:

O avanço técnico do iCS2 o separa de ser apenas um Unity
produto, aumentando significativamente as oportunidades de mercado. A visão final
é que o iCS2 será um auxílio ao desenvolvimento que >pode ser usado para criar scripts
para outros motores de jogo, bem como padrão > Windows/OSX/iOS/Android
formulários.

http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post -2124402

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104895405.

Eu acho que a folha de eventos do construct 2 é realmente fácil de entender e programar.

Como um artista que passa a maior parte do tempo criando gráficos para minha vida, aprender um novo idioma é muito difícil e demorado. As pessoas dizem que você pode aprender em alguns meses, mas quando você tem apenas 2 horas por dia para si mesmo, você pode optar por aprender do zero ou criar usando uma linguagem simples. Além disso, sendo uma pessoa visual, o script visual faz mais sentido.

Eu fiz programação na escola e posso ler e entender código facilmente, mas escrevê-lo leva tempo. Também estou tentando aprender python, que é mais fácil, mas ainda levará meses para criar algo com ele.

A abordagem do Construct 2 parece simples. Para mim parece:

1 Evento: Ação;

2 Evento: Ação;
: Açao;

É basicamente programação, mas de uma maneira muito facilmente compreensível. Se eles tivessem usado apenas linguagem em vez de bloqueio, eu não teria me importado. Usando este padrão é fácil criar uma lógica para mim.

O uso de nós pode ficar fora de controle muito rapidamente à medida que as coisas começam a se espalhar e você gasta mais tempo procurando os nós do que realmente codificando (como entendi da unidade e do craque).

Portanto, se você está tentando implementar um script visual, pense seriamente em construir um sistema de eventos.

Você também pode criar o sistema de script visual como uma extensão para download para pessoas como nós, para que aqueles que preferem programar não precisem baixar essa carga extra.

Ótimo trabalho com Godot ansioso para criar grandes jogos nele.

Meu problema com a abordagem do Construct é que parece programar,
não parece ser muito diferente
Do ponto de vista da equipe, gosto mais da abordagem blueprint da Unreal porque
é mais amigável para designers que não têm ideia de programação

Em domingo, 24 de maio de 2015 às 3h58, whoisda [email protected] escreveu:

Eu acho que a folha de eventos do construct 2 é realmente fácil de entender e
programa em.

Como um artista que passa a maior parte do tempo criando gráficos para minha vida,
aprender um novo idioma é muito difícil e demorado. As pessoas dizem que você pode
aprendê-lo em poucos meses, mas quando você tem apenas 2 horas por dia para
você mesmo, você pode escolher aprender do zero ou criar usando um
linguagem simples. Além disso, ser uma pessoa visual, o script visual torna mais
senso.

Eu fiz programação na escola e posso ler e entender código facilmente
mas escrever leva tempo. Eu também estou tentando aprender python que é mais fácil
mas ainda levará meses para criar algo com ele.

A abordagem do Construct 2 parece simples. Para mim parece:

1 Evento: Ação;

2 Evento: Ação;
: Açao;

É basicamente programação, mas de uma maneira muito facilmente compreensível. Se eles
tivesse usado apenas linguagem em vez de bloco eu não teria me importado. Usando isso
pattern é fácil criar uma lógica para mim.

O uso de nós pode sair do controle muito rapidamente à medida que as coisas começam a se espalhar e
você gasta mais tempo procurando os nós do que realmente codificar (como eu
entendido a partir de unidade e craque).

Então, se você está tentando implementar um script visual, por favor, dê uma
pensamento sério para construir sistema de eventos.

Você também pode criar o sistema de script visual como um download
extensão para pessoas como nós, para que aqueles que preferem programar não precisem
baixe essa carga extra.

Ótimo trabalho com Godot ansioso para criar grandes jogos nele.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159.

Mas a sua é a perspectiva de um programador - alguém que já sabe como
codificar.
É melhor olhar para as estatísticas neste caso - o número de
usuários não programadores que construct2 tem sobre a outra programação visual
editores devem falar por si.

também vale a pena examinar a variedade de jogos criados em um estilo de programação visual em detrimento de outro.

O Unreal tem um grande número de projetos feitos no kismet - mas é um motor muito mais antigo que o construct2 e muitos deles são apenas jogos de tiro em primeira pessoa

No domingo, 24 de maio de 2015 às 10h15, Juan Linietsky [email protected]
escreveu:

Meu problema com a abordagem do Construct é que parece programar,
não parece ser muito diferente
Do ponto de vista da equipe, gosto mais da abordagem blueprint da Unreal porque
é mais amigável para designers que não têm ideia de programação

Em domingo, 24 de maio de 2015 às 3h58, whoisda [email protected] escreveu:

Eu acho que a folha de eventos do construct 2 é realmente fácil de entender e
programa em.

Como um artista que passa a maior parte do tempo criando gráficos para minha vida,
aprender um novo idioma é muito difícil e demorado. As pessoas dizem que você
posso
aprendê-lo em poucos meses, mas quando você tem apenas 2 horas por dia para
você mesmo, você pode escolher aprender do zero ou criar usando um
linguagem simples. Além disso, ser uma pessoa visual, o script visual torna mais
senso.

Eu fiz programação na escola e posso ler e entender código facilmente
mas escrever leva tempo. Eu também estou tentando aprender python que é
mais fácil
mas ainda levará meses para criar algo com ele.

A abordagem do Construct 2 parece simples. Para mim parece:

1 Evento: Ação;

2 Evento: Ação;
: Açao;

É basicamente programação, mas de uma maneira muito facilmente compreensível. Se
elas
tivesse usado apenas linguagem em vez de bloco eu não teria me importado. Usando
isto
pattern é fácil criar uma lógica para mim.

O uso de nós pode sair do controle muito rapidamente à medida que as coisas começam a se espalhar e
você gasta mais tempo procurando os nós do que realmente codificar (como eu
entendido a partir de unidade e craque).

Então, se você está tentando implementar um script visual, por favor, dê uma
pensamento sério para construir sistema de eventos.

Você também pode criar o sistema de script visual como um download
extensão para pessoas como nós, então quem prefere programar não tem
para
baixe essa carga extra.

Ótimo trabalho com Godot ansioso para criar grandes jogos nele.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985669.

A abordagem de programação do Construct2 é muito semelhante à do
Clickteam fusion, que também tem muitos usuários. A facilidade para isso vem de um
várias coisas, embora seja semelhante à programação:

• Ter todas as CONDIÇÕES possíveis listadas e disponíveis para o usuário selecionar
  para adicionar clicando/arrastando em inglês simples - isso é inestimável
  porque eles não têm que aprender as palavras mágicas. Eles podem simplesmente arrastar e
  largue eles.
• Ter todas as AÇÕES possíveis listadas e disponíveis para o usuário selecionar
  adicione clicando/arrastando em inglês simples - isso é inestimável
  porque eles não têm que aprender as palavras mágicas. Eles podem simplesmente arrastar e
  largue eles.
• mesmo vale ao fazer qualquer tipo de expressão na configuração e
  ação ou condição. Quando você escreve expressões, o editor está ajudando você
  com uma lista suspensa fácil de coisas para obter de objetos existentes no
  cena. Você não precisa aprender como chegar a essas propriedades, pois elas
  já estão disponíveis em poucos cliques.

Talvez o melhor aspecto disso seja que ele ensina não programadores sobre
teoria de programação sem a curva de aprendizado de aprender uma nova programação
língua.

No domingo, 24 de maio de 2015 às 10h17, Todor Imreorov [email protected]
escreveu:

Mas a sua é a perspectiva de um programador - alguém que já conhece
como codificar.
É melhor olhar para as estatísticas neste caso - o número de
usuários não programadores que construct2 tem sobre a outra programação visual
editores devem falar por si.

No domingo, 24 de maio de 2015 às 10h15, Juan Linietsky < [email protected]

escreveu:

Meu problema com a abordagem do Construct é que parece programar,
não parece ser muito diferente
Do ponto de vista da equipe, gosto mais da abordagem blueprint da Unreal porque
é mais amigável para designers que não têm ideia de programação

No domingo, 24 de maio de 2015 às 3h58, whoisda [email protected]
escreveu:

Eu acho que a folha de eventos do construct 2 é realmente fácil de entender e
programa em.

Como um artista que passa a maior parte do tempo criando gráficos para minha vida,
aprender um novo idioma é muito difícil e demorado. As pessoas dizem que você
posso
aprendê-lo em poucos meses, mas quando você tem apenas 2 horas por dia para
você mesmo, você pode escolher aprender do zero ou criar usando um
linguagem simples. Além disso, ser uma pessoa visual, o script visual torna mais
senso.

Eu fiz programação na escola e posso ler e entender código
facilmente
mas escrever leva tempo. Eu também estou tentando aprender python que é
mais fácil
mas ainda levará meses para criar algo com ele.

A abordagem do Construct 2 parece simples. Para mim parece:

1 Evento: Ação;

2 Evento: Ação;
: Açao;

É basicamente programação, mas de uma maneira muito facilmente compreensível. Se
elas
tivesse usado apenas linguagem em vez de bloco eu não teria me importado. Usando
isto
pattern é fácil criar uma lógica para mim.

O uso de nós pode sair do controle muito rapidamente à medida que as coisas começam a se espalhar
e
você gasta mais tempo procurando os nós do que realmente codificar (como eu
entendido a partir de unidade e craque).

Então, se você está tentando implementar um script visual, por favor, dê uma
pensamento sério para construir sistema de eventos.

Você também pode criar o sistema de script visual como um download
extensão para pessoas como nós, então quem prefere programar não tem
para
baixe essa carga extra.

Ótimo trabalho com Godot ansioso para criar grandes jogos nele.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104985669.

Veja também da perspectiva de um designer que gostaria de aprender a codificar lógica complexa e, eventualmente, ficar confiante o suficiente para aprender a codificar. Eu vejo de onde você está vindo, pois você vê que o sistema será usado por uma equipe de designers e programadores. Pessoalmente, gostaria de usar Godot como um único usuário e não em uma equipe com um programador como muitos desenvolvedores de jogos independentes. O sistema de eventos é tolerante e parece mais organizado usando grupos quando você tem mais de 1.000 eventos.

Fora isso não tenho nenhum problema com o sistema de nós e se godot conseguir criar um sistema que seja melhor que o atual eu vou usar a merda dele.

Além disso, se possível, crie um recurso de pesquisa para encontrar blocos/nós de código facilmente.

Observe que as folhas de eventos em construct2/clickteam eliminam a necessidade de aprender
sintaxe - para que o usuário não precise saber onde colocar as coisas - isso é
muito óbvio. Condições à esquerda, ações à direita. A ordem de
a execução do evento também é muito óbvia.
Peças de Lego em bloco de rascunho/estêncil/unidade não são tão óbvias, mas ainda são
muito melhor do que o pesadelo dos nós apresentado em "iCanScript". Você olhou
em seu tutorial em vídeo. É um design de programação visual super complicado
com uma curva de aprendizado bastante íngreme. Eu acho que mesmo que você dê a um
programador eles terão problemas para descobrir

Em domingo, 24 de maio de 2015 às 10h33, whoisda [email protected] escreveu:

Veja também da perspectiva de um designer que gostaria de aprender
para codificar lógica complexa e, eventualmente, ficar confiante o suficiente para aprender a codificar.
Eu vejo de onde você está vindo, pois você vê que o sistema será usado por um
equipe de designers e programadores. Pessoalmente, gostaria de usar Godot como
um único usuário e não em uma equipe com um programador como muitos jogos indie
desenvolvedores. O sistema de eventos é tolerante e se sente mais organizado usando
grupos quando você tem mais de 1000 eventos.

Fora isso, não tenho nenhum problema com o sistema de nós e se o godot conseguir
criar um sistema que seja melhor que o atual eu vou usar pra cacete
isto.

Além disso, se possível, crie um recurso de pesquisa para encontrar blocos/nós de código
facilmente.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104988595.

Eles não estão mais vendendo "icanscript" na loja de ativos da unidade.
Veja os números de vendas lá - qual das programações visuais disponíveis
sistemas está em uso mais - e tem projetos completos.

Deixo-vos com este vídeo:
https://www.youtube.com/watch?v=3Zq1yo0lxOU
Tem 167 jogos feitos com clickteam fusion - por pessoas que não têm
experiência em programação.

Veja também jogos de kickstarter de sucesso feitos em fusão.
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia/description
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game/description
https://www.kickstarter.com/projects/2064021040/tiny-trek

preciso mencionar também Five Nights at Freddy's (feito em fusão de clickteam):
http://en.wikipedia.org/wiki/Five_Nights_at_Freddy%27s_%28video_game%29
esse jogo é um best-seller. Aqui estão alguns números para você:
https://thinkgaming.com/app-sales-data/8779/five-nights-at-freddys/

A ideia de um framework de programação visual deve ser capacitar um artista a criar um jogo sem precisar de um programador - no processo aprenda um pouco sobre programação.

Se você fizer uma onde o programador ainda é necessário - então você não criou realmente uma estrutura de programação visual - você acabou de criar uma máquina de estado que os programadores podem configurar para os designers usarem - para coisas simples no jogo - mas não para a lógica central do jogo. Então você não vai realmente criar algo tão bom e completo quanto as outras ferramentas de programação visual mencionadas aqui. Você não está capacitando os artistas para configurar a lógica e convidando-os a aprender conceitos básicos de programação. Você os mantém dependentes de programadores e no escuro desses conceitos.

No domingo, 24 de maio de 2015 às 10h42, Todor Imreorov [email protected]
escreveu:

Observe que as folhas de eventos em construct2/clickteam eliminam a necessidade de aprender
sintaxe - para que o usuário não precise saber onde colocar as coisas - isso é
muito óbvio. Condições à esquerda, ações à direita. A ordem de
a execução do evento também é muito óbvia.
Peças de Lego em bloco de rascunho/estêncil/unidade não são tão óbvias, mas são
ainda muito melhor do que o pesadelo dos nós apresentado em "iCanScript". Fez
você olha para o seu tutorial em vídeo. É um visual super complicado
design de programação com uma curva de aprendizado bastante íngreme. Eu acho que mesmo se
você dá a um programador eles terão problemas para descobrir

No domingo, 24 de maio de 2015 às 10h33, whoisda [email protected]
escreveu:

Veja também da perspectiva de um designer que gostaria de
aprender a codificar lógica complexa e, eventualmente, ficar confiante o suficiente para aprender a
código. Eu vejo de onde você está vindo, pois você vê que o sistema será usado por
uma equipe de designers e programadores. Eu pessoalmente gostaria de usar Godot
como um único usuário e não em uma equipe com um programador como muitos indie
desenvolvedores de jogos. O sistema de eventos é indulgente e parece mais organizado
usando grupos quando você tem mais de 1.000 eventos.

Fora isso, não tenho nenhum problema com o sistema de nós e se o godot conseguir
criar um sistema que seja melhor que o atual eu vou usar pra cacete
isto.

Além disso, se possível, crie um recurso de pesquisa para encontrar blocos/nós de código
facilmente.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104988595.

Eu não acho que seja sensato empurrá-lo para usar um sistema que funciona de forma excelente para outro mecanismo de jogo se essa não for a direção que você gostaria de seguir.

Na mesma nota, gostaria de ver uma maneira mais intuitiva de implementar um script visual. Não usando os nós confusos ou blocos demorados (criador de aplicativos Android) ou muito programando o sistema de eventos (o que eu prefiro sobre todo o resto). Algo que leva o melhor de todos eles.

Talvez consulte um designer de usabilidade para limpar alguns caminhos e ver alguns números.

No final, seria ótimo ver um método exclusivo para Godot que torna Godot um ótimo mecanismo que permite que um iniciante de uma pessoa projete seu primeiro jogo em uma semana e uma equipe de desenvolvimento colaborando para criar um jogo AAA.

Eu ficaria feliz em ver um sistema que me ajudasse a criar jogos maravilhosos sem mudar de engine e aprender idiomas com tanta frequência.

Felicidades.

Eu não me importo com os nós se eles forem feitos como os do playmaker - como
contêineres de ação (estados).
Os nós não são realmente usados ​​para definir ações ou condições.

Se você, no entanto, os fizer como "iCanScript", você terá uma bagunça completa.

1. é difícil dizer em qual ordem os eventos são executados
2. Difícil descobrir qual nó pode ser conectado a qual nó
3. são necessários muitos nós e etapas para configurar uma única ação do que para
   arraste-o e solte-o e configure uma expressão nele (estilo construct2/clickteam
4. onde você é ajudado com a sintaxe - essa é uma ótima maneira de apresentar
   alguém para programar sem exigir que eles leiam toneladas de
   documentação - tudo está lá para eles no menu suspenso do
   objeto).

Em domingo, 24 de maio de 2015 às 11h20, whoisda [email protected] escreveu:

Eu não acho que seja sensato empurrá-lo para usar um sistema que funciona
excelente para outro motor de jogo, se essa não for a direção que você
quer pegar.

Na mesma nota eu gostaria de ver uma maneira mais intuitiva que um visual
script é implementado. Não usando os nós confusos ou demorando
blocos (criador de aplicativos Android) ou muito sistema de eventos com aparência de programação (que eu
prefere tudo o resto). Algo que leva o melhor de todos eles.

Talvez consulte um designer de usabilidade para limpar alguns caminhos e ver alguns
números.

No final seria ótimo ver um método exclusivo da Godot que
Godot um ótimo motor que permite que um iniciante projete seu
primeiro jogo em uma semana e uma equipe de desenvolvimento colaborando para
criar um jogo AAA.

Eu ficaria feliz em ver um sistema que me ajudasse a criar jogos maravilhosos
sem mudar de motor e aprender línguas com tanta frequência.

Felicidades.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -104990083.

Eu voto em @whoisda em relação a algo que está sendo inovado para/em Godot. No entanto, parece haver três escolas de Visual Scripting: 1) nós, 2) folhas de eventos, 3) blocos. Destes três nós parecem estar liderando o campo em ambientes 3D. Falando nisso, li em algum lugar uma ideia sugerindo que scripts/programação saiam de um formato linear (texto, blocos, folha de eventos) ou horizontal (nós) e programe em 3D usando estruturas. Não tenho certeza de como isso funcionaria, mas parece fascinante.

As escolas de script visual mencionadas foram testadas na prática e
já tem usuários. Sugiro combinar os designs de Playmaker e
blox em unidade.

Nós para criar uma máquina de estado.
Blocos ou folhas de eventos para criar as ações dentro de cada nó (estado).

Em domingo, 24 de maio de 2015 às 13h56, todheil [email protected] escreveu:

Eu voto em @whoisda https://github.com/whoisda em relação a algo
sendo inovado para/em Godot. No entanto, parece haver três Visual
Escolas de script: 1) nós, 2) folhas de eventos, 3) blocos. Desses três
nós parecem estar liderando o campo em ambientes 3D. Falando nisso
Eu li em algum lugar uma ideia sugerindo que scripts/programação saiam de um
formato linear (texto, blocos, folha de eventos) ou horizontal (nós) e
programa em 3D usando estruturas. Não tenho certeza de como isso funcionaria, mas parece
fascinante.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105001411.

Seria ótimo se pudéssemos usar nós e eventos juntos. Os nós podem os estados que seguindo uma lógica simples podem ser plugados em outros nós ou podem ser containers para scripts/blocos/folhas de eventos desta forma não teremos nós muito grandes e também podemos colaborar em equipe. Mas isso pode ser demais para o desenvolvedor. Ainda assim, a ideia parece ser muito legal.

É mais ou menos assim no Playmaker - as pessoas parecem gostar muito.
Muitas pessoas aqui também parecem gostar de stencil - a tecnologia é
código aberto e disponível no site do github do zero. Eu compartilhei em um
postagem anterior.

Eu pessoalmente adoraria ver QUALQUER primeiro passo na programação visual
direção. Mesmo que o desenvolvedor faça uma máquina de estado que funcione com gd
scripts - seria um começo incrível que até mesmo programadores avançados
gostaria.

Então talvez depois disso possamos ter algo visual como estêncil ou
construct2 - que é como código - mas muito mais fácil que código - dentro do
estados.

Então, na verdade, esses são dois pedidos de recursos!

• Um para uma máquina de estado (nós)
• outro para uma estrutura de script visual que substitui o aprendizado do gdscript
  com codificação de arrastar e soltar. Mas também é um bom passo para aprender
  gdscript.

No final, o desenvolvedor principal sabe o que é melhor para o design da godot.

Em terça-feira, 26 de maio de 2015 às 11h43, whoisda [email protected] escreveu:

Seria ótimo se pudéssemos usar nós e eventos juntos. Os nós podem
estados que, seguindo uma lógica simples, podem ser conectados a outros nós ou
podem ser recipientes para scripts/blocos/folhas de eventos desta forma não teremos
nós muito grandes e também podem colaborar como uma equipe. Mas isso também pode ser
muito para o desenvolvedor. Ainda assim, a ideia parece ser muito legal.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984.

vou verificar styencyl em breve porque não estou familiarizado com ele.
neste ponto de tudo o que vi/li, posso deduzir que:

1) Blueprint: É ótimo para designers de jogos/níveis, mas não tão bom para
programação visual
2) Stencyl: É muito melhor para programação visual, mas inutilizável para
designers de jogos/níveis

Minha experiência em fazer jogos sempre foi em equipes, então posso ver 1) como sendo
muito útil, mas isso também me torna tendencioso. Tem tanta gente
interessado em programação visual como em Stencyl?

Em terça-feira, 26 de maio de 2015 às 6h10, Todor Imreorov [email protected]
escreveu:

É mais ou menos assim no Playmaker - as pessoas parecem gostar muito.
Muitas pessoas aqui também parecem gostar de stencil - a tecnologia é
código aberto e disponível no site do github do zero. Eu compartilhei em um
postagem anterior.

Eu pessoalmente adoraria ver QUALQUER primeiro passo na programação visual
direção. Mesmo que o desenvolvedor faça uma máquina de estado que funcione com gd
scripts - seria um começo incrível que até mesmo programadores avançados
gostaria.

Então talvez depois disso possamos ter algo visual como estêncil ou
construct2 - que é como código - mas muito mais fácil que código - dentro do
estados.

Então, na verdade, esses são dois pedidos de recursos!

• Um para uma máquina de estado (nós)
• outro para uma estrutura de script visual que substitui o aprendizado do gdscript
  com codificação de arrastar e soltar. Mas também é um bom passo para aprender
  gdscript.

No final, o desenvolvedor principal sabe o que é melhor para o design da godot.

Em terça-feira, 26 de maio de 2015 às 11h43, whoisda [email protected]
escreveu:

Seria ótimo se pudéssemos usar nós e eventos juntos. Os nós podem
estados que, seguindo uma lógica simples, podem ser conectados a outros nós
ou
podem ser recipientes para scripts/blocos/folhas de eventos desta forma não iremos
ter
nós muito grandes e também podem colaborar como uma equipe. Mas isso pode ser
também
muito para o desenvolvedor. Ainda assim, a ideia parece ser muito legal.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984
.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105458142.

http://www.emanueleferonato.com/wp-content/uploads/2011/12/stencyl05.png

Este é um exemplo canônico de como é o "código" de estêncil? Se sim, parece uma ideia horrível: parece uma codificação padrão em invólucros visuais para o jardim de infância. Vamos lá, python já é fácil o suficiente para minha esposa lê-lo, então por que não fazer um esforço para aprender o básico?

Se você fala de programação visual, então o que Godot já tem é muito melhor - gráficos de sombreamento ou gráficos de animação: código embrulhado em nós visuais.
https://frenchdog.files.wordpress.com/2009/09/specular_reflexion_vops.jpg - outro exemplo de programação visual baseada em nó (Sidefx Houdini, ou XSI). É maduro e não parece um brinquedo de criança, também me lembra os nós Godot.

Gostei da abordagem construct2, mas depois de olhar mais para o zero - parece uma escolha melhor por vários motivos:

• O design de programação parece ser mais popular do que o construct2
• Já foi estabelecido como uma ferramenta para ajudar a ensinar às pessoas uma linguagem de programação
• É de código aberto e outros o adaptaram para seu mecanismo no passado

Os desenvolvedores do Stencyl adotaram a tecnologia "scratch" de código aberto. Não é o projeto deles.
https://scratch.mit.edu/about/
http://en.wikipedia.org/wiki/Scratch_ (programming_language)
http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

Exemplos de Scratch sendo usado por outros mecanismos de jogo direcionados a não programadores:

• Stencyl (o mais popular) http://www.stencyl.com/
  
• Craftstudio ( http://craftstud.io/ )
  
• google blockly ( https://developers.google.com/blockly/ )
• O mais próximo de Godot é o recurso de programação visual "Blox" da Unity:
  
  https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k
  Em vez de Lua, ele gera C#.
  a documentação completa está aqui:
  http://www.plyoung.com/blox/
  e é vendido aqui: https://www.assetstore.unity3d.com/en/#!/content/12859

Pode parecer uma ideia horrível para programadores experientes, mas é a melhor maneira de ensinar não programadores a escrever código ou simplesmente capacitá-los a programar sem conhecer as palavras mágicas ou a sintaxe. O Scratch disponibiliza todos eles para arrastar e soltar - forçando uma estrutura correta com dicas visuais. Assista à lista de reprodução de vídeos "Unity Blox" que publiquei para vê-la em ação. Mais do que qualquer outra coisa, isso foi comprovado na prática repetidamente. Parece a aposta mais segura.

Concordo com @reduz em seus pontos de que um é bom em design de níveis e o outro em scripts visuais e não estou mais discutindo o uso de um sobre o outro.

Usar ambos parece ser a melhor abordagem. Se não for o Unity blox, mesmo se você olhar para o Playmaker, verá que os nós são realmente contêineres - onde as ações podem ser empilhadas - de maneira muito semelhante ao stencyl. Você os arrasta e solta de uma lista!

"mas é a melhor maneira de ensinar não programadores a escrever código ou simplesmente capacitá-los a programar sem conhecer as palavras mágicas"

Então eu não entendo qual é o público-alvo dessa segmentação. Godot pretende competir com os grandes do mercado (Unreal Engine, Unity, etc.)

Eu sei o que são nós (input -> function with params -> output), discordo da apresentação.

Stencyl e Playmaker podem ser ótimos para ensinar as crianças a codificar, mas eles têm sido usados ​​com sucesso por não programadores (tanto estúdios quanto indie) para fazer jogos de sucesso - vendidos em diferentes plataformas.
Se você classifica o Unity como os grandes, então você deve saber que os garotos grandes também fazem programação visual.
http://www.hutonggames.com/showcase.html

Eu acho que Godot tem muitos recursos para serem usados ​​pelos garotos grandes. Alguns recursos que permitem menores/indies podem ajudar na adoção mais rápida do mecanismo. E a natureza de código aberto e o licenciamento enxuto são muito lucrativos para iniciantes.

@blurymind
Eu _não_ argumento contra a programação visual. Eu diria que Godot já tem o que precisa (ShaderGraphs): a mesma abordagem visual pode ser estendida para programação lógica de máquina de estado ou programação geral. O que eu discuto é contra a adoção de mais um paradigma visual (~scratch) que não afugente as crianças.

como observado antes, não é apenas para crianças. Mas se até mesmo as crianças podem entender e usá-lo - então eu acho que é uma coisa boa. Não é algo para se envergonhar.

O maior ponto que eu quero fazer aqui é que:

• a ordem de execução das ações deve ser clara! Fazer toda a lógica com nós pode ficar muito confuso muito rapidamente. Portanto, os nós devem ser usados ​​para estados imo.
• Os desenvolvedores do Playmaker anteciparam muito bem esse problema e é por isso que eles fizeram com que os nós sejam contêineres de ação nos quais - muito semelhante ao Stencyl - você arrasta e solta as ações disponíveis de uma lista:
  
  e empilhar eventos dessa maneira

O que você acaba é uma configuração de nó muito limpa e eficiente!

Sugiro que os desenvolvedores de Godot também experimentem o craque.
Substituir a pilha de eventos pela lógica Stencyl tornaria a abordagem da Godot muito mais flexível/poderosa!.

Não precisa ser apenas através de uma abordagem de estêncil. Acho que você pode permitir que programadores experientes anexem scripts gd aos nós. Ter a opção de usar uma abordagem de stencil para criar gdscripts seria inestimável imo. Ele convidará muitos novos usuários para a comunidade godot.

@blurymind
Ok, mas isso é algo diferente. Fácil de usar não significa que deva parecer destinado a crianças.
Ordem de execução e filtragem assistida de entradas/saídas adequadas para um determinado nó são problemas comuns para fluxos de trabalho baseados em nós. Diferentes softwares resolvem de forma diferente.

Você tem que se perguntar - Você quer que mais não programadores usem Godot? Você quer tornar possível para pessoas que não têm experiência com gdscript fazerem algo divertido?

Se a resposta for sim - então a melhor maneira de fazer isso é dando a eles uma abordagem de script visual.
Não estou sugerindo que os nós pareçam algo feito para crianças.
O que estou sugerindo é dividir isso em dois projetos!

• Nós usados ​​como uma máquina de estado - como no Playmaker! Os programadores podem nomear cada nó e anexar gdscripts a ele - com entrada e saída que eles configuram. Então, isso não é para crianças. Na verdade, esta é uma abordagem muito mais flexível para programadores que é muito menos confusa.
• Uma folha de eventos de arrastar e soltar ou uma interface de blocos como forma alternativa de gerar um GDscript. Então, em vez de escrever um GdScript para anexar a um nó, os não programadores podem simplesmente empilhar ações de uma lista de todos os eventos disponíveis no godot - muito parecido com o Playmaker. Para dar um passo adiante e inovar - em vez de simplesmente empilhar ações, seria ainda melhor usar o Stencyl como blocos.

Dessa forma, você tem algo útil para programadores e não programadores. Ambos podem usar a máquina de estado (nós) e os não programadores não precisam aprender o gdscript imediatamente e usar gdBlocks para gerar um gdscript para um nó (novamente - como no Playmaker).

@blurymind
Eu gosto mais disso. Também é consistente com o gráfico de nó do Shader versus o texto do Shader que já está no Godot.

SideFX Houdini tem algo chamado VEX (https://goo.gl/TMWNKk) ("expressão vetorial" uma linguagem semelhante a C destinada à álgebra vetorial). É um pouco sinônimo de gdScript. Também tem algo chamado "VOPs" (http://goo.gl/Qpn2OE) (Vex Operators) - essencialmente wrappers visuais de um subconjunto de VEX, que se parece muito com a imagem de gráfico de nó LeadWerks que você mencionou acima. Na verdade, os VOPs podem ser transformados em script de texto, se necessário (mas não o contrário).

A coexistência dos 2 é bastante natural e permite, mesmo não programadores, criar códigos muito confusos e ineficientes ;)

Eu pessoalmente gosto da abordagem Blueprint porque é muito designer de jogos
gosto, mas insisto que posso ser tendencioso.

Eu baixei Stencyl duas horas atrás e joguei com ele. eu posso ser
errado, mas acho que Stencyl é uma boa ferramenta para aprender porque não só o
parte de programação é simplificada, mas a parte do motor também. A combinação é
bom porque é uma abordagem de programação simples para um mecanismo de jogo simples.

Mas Godot não é um motor de jogo simples (pelo menos comparado ao Stencyl), então eu
não pense que a programação simplificada seria tão útil. Stencyl conta com
um monte de coisas de lógica de jogo codificadas que simplesmente não estarão disponíveis em
Godot, e tentar disponibilizá-lo irá contradizer o objetivo de Godot de
sendo um motor de jogo de propósito geral.

A abordagem de nós e gráficos é mais interessante na minha opinião porque é
um nível mais baixo e uma maneira mais flexível de fazer as coisas.

Em terça-feira, 26 de maio de 2015 às 11h29, Vladimir Lopatin < [email protected]

escreveu:

@blurymind https://github.com/blurymind
Eu gosto mais disso. Também é consistente com o gráfico de nó Shader vs.
Shader-texto que já está em Godot.

SideFX Houdini tem algo frio VEX (https://goo.gl/TMWNKk) ("vetor
expressão" uma linguagem semelhante a C que se destina à álgebra vetorial).
um pouco sinônimo de gdScript. Também tem algo chamado "VOPs" (
http://goo.gl/Qpn2OE) (Vex Operators) - essencialmente wrappers visuais de um
subconjunto de VEX, que se parece muito com o gráfico de nós LeadWerks que você
referenciado acima. Na verdade, os VOPs podem ser transformados no script, se necessário
(mas não o contrário).

A coexistência dos 2 é bastante natural e permite, mesmo
não programadores, para criar códigos muito confusos e ineficientes ;)

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105543845.

E quanto ao empilhamento de ação no Playmaker e blox no Unity? Unity não é um motor muito simples.

Acho que stencil não é um bom exemplo. É melhor procurar exemplos na loja de ativos da unidade.

tentei entender o playmaker mas falhei, como é suposto funcionar?

Em terça-feira, 26 de maio de 2015 às 12h16, Todor Imreorov [email protected]
escreveu:

E quanto ao empilhamento de ação no Playmaker e blox no Unity? A unidade não é uma
motor muito simples.

Acho que stencil não é um bom exemplo. É melhor procurar
exemplos no repositório de ativos da unidade.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760.

verifiquei o tutorial do playmaker, mas parece ser semelhante ao stencyl em
a sensação de que vem com um zilhão de comportamentos predefinidos

Em terça-feira, 26 de maio de 2015 às 12h19, Juan Linietsky [email protected]
escreveu:

tentei entender o playmaker mas falhei, como é suposto funcionar?

Em terça-feira, 26 de maio de 2015 às 12h16, Todor Imreorov < [email protected]

escreveu:

E quanto ao empilhamento de ação no Playmaker e blox no Unity? A unidade não é uma
motor muito simples.

Acho que stencil não é um bom exemplo. É melhor procurar
exemplos no repositório de ativos da unidade.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777.

_OkamStudio_

O mais próximo no Unity para os blueprints do U4 é o uScript:
https://www.assetstore.unity3d.com/en/#!/content/1808

As pessoas parecem preferir o Playmaker ao invés do uscript, pois é mais fácil entender a lógica que foi configurada. Como você pode ver nas capturas de tela, fica muito confuso, mesmo para uma lógica simples.

@reduz @okamstudio aqui está uma playlist no playmaker:
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10
Eu acho que você deveria realmente usá-lo um pouco. Você pode fazer comportamentos e scripts predefinidos, mas o playmaker também permite que você acesse os principais recursos do mecanismo e crie esses comportamentos do zero.

Sim, o craque é uma máquina de estado e a unidade vem com muitos comportamentos predefinidos.
Godot também os tem - eles são embutidos no motor.
Eu ainda acredito que você pode realmente criar um script/comportamento do zero usando o blox stencyl clone da unidade.

Acho que finalmente você precisa de um programador para fazer um jogo adequado e essa ideia
é ótimo que o designer de jogos faça o jogo sozinho, mas acho que é muito
de trabalho que não é útil em muitos casos. mas se tivermos mais
recurso para o próprio editor como o designer de plataforma que outra pessoa
mencionado em outra edição ou outras coisas úteis para facilitar a interface do usuário
mais amigável.
Em 26 de maio de 2015, 19h52, "Okam Studio" [email protected] escreveu:

verifiquei o tutorial do playmaker, mas parece ser semelhante ao stencyl em
a sensação de que ele vem com um zilhão de comportamentos predefinidos

Em terça-feira, 26 de maio de 2015 às 12h19, Juan Linietsky < [email protected]

escreveu:

tentei entender o playmaker mas falhei, como é suposto funcionar?

Em terça-feira, 26 de maio de 2015 às 12h16, Todor Imreorov <
[email protected]

escreveu:

E quanto ao empilhamento de ação no Playmaker e blox no Unity? A unidade é
não um
motor muito simples.

Acho que stencil não é um bom exemplo. É melhor procurar
exemplos no repositório de ativos da unidade.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
<
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
.

—
Responda a este e-mail diretamente ou visualize-o no GitHub
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777
.

_OkamStudio_

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105565084.

aqui está uma revisão na loja de ativos da unidade para o uScript:

Boa ferramenta, mas difícil de aprender se um não programador... as respostas aos pedidos de ajuda nos fóruns são muito lentas ou não existem.

O que quer que esteja no Godot, acho - se possível - seria uma boa ideia permitir a conversão unidirecional para GDScript. Isso permitiria configurar rapidamente as coisas visualmente, por designers e artistas e assim por diante, e então permitir que os codificadores da equipe o ajustassem e retrabalhassem sem ter que usar o botão de apontar.

@adolson Isso seria um recurso muito desejado :)

isso pode ser feito e também pode ser feito com o editor de sombreamento visual
(que, de fato, gera código de sombreador)
mas acho que o código do shader gerado não será tão legível quanto você poderia
espere :P

Em terça-feira, 26 de maio de 2015 às 18h33, Nathan [email protected] escreveu:

@adolson https://github.com/adolson Isso seria muito desejado
característica :)

—
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/okamstudio/godot/issues/1220#issuecomment -105670945.

@reduz Alguns metadados são esperados.
Aqui está um exemplo de conversão de VOPs -> conversão VEX, conforme indicado acima:
:
E aqui está a listagem completa do código , que, caso contrário, em VEX puro fica assim:
@P += vetor({0,1,0}); // pega a posição e adiciona o vetor (0,1,0)

Como você pode ver a quantidade de metadados é significativa, mas não é difícil separar os 2, possivelmente analisá-los de forma semi ou totalmente automática.

@reduz É verdade. Eu realmente não estava pensando nisso. Provavelmente não será o tipo de código em que a maioria dos programadores gostaria de gastar seu tempo. Eu poderia ver rótulos se tornando nomes de variáveis ​​e tal, mas não consigo ver muito mais para mitigar o problema.

Embora eu não possa falar por todos, se vejo uma bagunça de código, posso tirar alguns pedaços dele, mas geralmente me sinto inclinado a apenas reescrevê-lo. Então, se for esse o caso, isso não valeria a pena para mim pessoalmente.

Vocês realmente passaram pela gama de opções. Eu usei o Construct 2 e, embora seja legal, você nunca pode tocar em nenhum código para refiná-lo e as opções eram bastante limitadas. A atualização do tilemap basicamente se livrou de prefabs e, portanto, também instancia. O que eu realmente gostei foi o PlayMaker for Unity.

Algo sobre isso foi muito fácil de entender o seu escopo e o que você precisava fazer. Este é um fator realmente atraente, toda a razão pela qual eu gosto de usar scripts visuais é exatamente por causa disso. Perco de vista o que estava fazendo ou o que preciso fazer no código textual, mas ver como tudo 'conecta' tem o maior benefício para mim. NateWardog postou um exemplo em uma captura de tela muito antes e blurrymind muito mais recentemente.

Eu digo reduzir, você vai em frente. Por enquanto, se você se incomodar, eu atiraria para 1.3 ou posterior e, mesmo assim, focaria principalmente no lado do frontend. Então, quando estiver pronto, mais tarde, concentre-se em fazer com que ele produza código legível como o Blueprint pode, o que eu imagino que seria muito desafiador. Por favor, não subestime este!

Inscrevendo-se. Estou muito interessado nisso também! Eu conheço alguns scripts e realmente não me importo de usá-los... mas eu prefiro conectar nós quando possível! Algo como os tijolos lógicos no Blender Game Engine, que atuam como atalhos visuais para funções de script Godot como uma alternativa para escrevê-los à mão... isso seria um recurso adorável e pelo qual estou esperando ativamente.

scripts visuais realmente atrai muitas pessoas criativas ou pessoas que não querem aprender uma nova linguagem de script como o gd script. eu estava olhando para o criador de jogos é tão popular e a única razão mais dada é a mecânica de script visual.

O script visual é tedioso, estúpido e difícil de usar.
Eu nunca vejo uma boa implementação. Pessoas visuais devem desenhar gráficos. eu
sei que muitas pessoas simplesmente não sabem escrever,
mas isso não vai fazer nenhum bem a eles. A pessoa que não programa não significa
pessoa analfabeta.

Não conheço nenhuma ferramenta de construção de lógica visual, que era o principal sistema para
lógica do jogo em qualquer motor.
A forma visual é uma merda em muitos aspectos. Pessoas visuais geralmente consideram
programação como "coisas de tecnologia"
significando algo real de encanamento e trabalho duro, e quer estar acima
isto. Essa atitude
é geralmente por causa de alguns problemas intelectuais. Eu não acho que esse povo
pode ser público-alvo
basicamente eles limitam sua criatividade.

Na quinta-feira, 14 de abril de 2016 às 8h33, Rémi Verschelde [email protected]
escreveu:

Edit: vejo que você trocou "RPG Maker" por "Game Maker", agora rende mais
sense :p Removendo meu post.

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -209770726

Eu não quero, mas tenho que dizer, mas essa é uma visão muito limitada das ferramentas de script visual, Sergey. Quanto aos jogos que foram totalmente feitos com eles, alguns mecanismos optaram completamente por eles, como o Construct, então você não verá nenhum jogo fora desse mecanismo feito com scripts regulares. Outro mecanismo (mais sensato, imo) possui plugins como Unity e UE4. Pessoalmente, gostei muito de usar o uscript e o PlayMaker no Unity ao lado do meu código regular porque, embora algumas coisas sejam mais fáceis de codificar, muitas são mais fáceis de criar scripts visualmente, principalmente máquinas de estado, porque com um scripter visual como PM, ele fornece muito feedback com breakpointsw é muito mais fácil olhar para o projeto de uma visão mais ampla.

A coisa real sobre scripts visuais em geral, é uma tentativa fútil de
tornar a programação acessível a não programadores, o que é totalmente errado
aproximação.
A programação visual é mais difícil que a programação de texto regular. Para fazer isso
mais fácil você tem que escrever muitos blocos para cada caso na vida no tradicional
caminho e
deixe essas pessoas usá-los. Estes provaram ser menos eficazes do que pedir a um
bom programador para escrever código. O ditado "programação não é uma profissão,
todos podem fazer isso" está errado. Todas as tentativas de programação sem
programação é um desperdício.

Quanto à máquina de estado - eu estava pensando em implementar isso há algum tempo
atrás, mas isso não ajudará no programa de recursos visuais.
Isso pode ser feito facilmente para o seu jogo usando script de ferramentas e editor de nós,
que é uma ferramenta poderosa, muitas pessoas usam para ferramentas de jogos, como
editores de diálogos de jogos.

Em qui, 14 de abril de 2016 às 9h09, Aaron M [email protected] escreveu:

Eu não quero ter que dizer isso, mas essa é uma visão muito estreita do visual
ferramentas de script, Sergey. Quanto aos jogos que foram totalmente feitos com eles,
alguns motores optaram completamente por eles, como o Construct, então você
não verá nenhum jogo fora desse mecanismo feito com scripts regulares. De outros
(mais sensato, imo) tem plugins como Unity e UE4. Eu pessoalmente
gostei muito de usar o uscript e o PlayMaker no Unity junto com meu
código porque enquanto algumas coisas são mais fáceis de codificar, muitas são mais fáceis de
script visualmente, particularmente máquinas de estado porque com um visual
scripter como PM dá-lhe muito feedback com breakpointsw é apenas
muito mais fácil olhar para o projeto de uma visão mais ampla.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

Slapin, você está certo. Mas você esquece que a programação visual ou os blocos de programação têm uma taxa de falha muito baixa. É por causa das limitações.
É basicamente o mesmo quando você usa uma linguagem de script muito limitada. Você não pode cometer muitos erros.

Eu acho que esse deve ser o objetivo a ser alcançado, não a questão de ser Visual- ou Text-Scripting!

Se você quer melhorar a programação, melhore as ferramentas. Codehighlighting, Codecompletion, Codevalidation, Codetemplates, também. Melhore o depurador e faça Liveprogramming.
Sempre procurei um ambiente de Liveprogramming estável, mas até agora não encontrei!

Se você realmente quer fazer Visual Scripting, faça como o Stingray Engine. Você pode criar CodeBlocks no Visual e gerar TextCode que pode modificar posteriormente, ou escrever TextCode que poderá usar posteriormente como Visual Blocks.

Eu não diria que é fútil, mas diria que estamos falando de 2
produtos completamente diferentes.

Se você administra um estúdio e faz jogos com, digamos, 20 a 80 pessoas,
você está gastando 6 dígitos em custos de produção todos os meses e precisa de um
motor para fazer seus jogos, você quer um determinado produto. Nesse caso, você
não se importa com as ferramentas de script visual, você se importa com outras
coisas, como a produtividade de sua equipe com as ferramentas do mecanismo
(já que se eles ultrapassarem o cronograma por um mês, você perderá ~ $ 100k). Aqueles
equipes têm programadores, e eles serão muito mais produtivos escrevendo código
do que usar alguma ferramenta visual (procure o Vicious Engine para um exemplo disso)

Por outro lado, se você tem uma ideia legal e não sabe realmente como
escrever código, você quer outro produto, algo para fazer um protótipo rápido que
você pode mostrar ao redor e, eventualmente, dar aos programadores para fazer o real
jogos.

São 2 produtos diferentes, e se discutirmos sobre qual vale mais a pena
tendo, temos que reconhecer isso. Eu diria que o script visual
ferramenta realmente não escala para mais de 1 pessoa fazendo um protótipo. Como
assim que você quiser fazer um jogo completo, ou assim que seu time crescer para 2-3
gente, você já precisa de uma linguagem de programação real. Então eu gosto do primeiro
exemplo mais como um objetivo geral (a menos que você queira um 3º produto, que é
"o motor que você pode usar para fazer um jogo indie completo que faz milhões
sem escrever nenhum código". Isso não existe).

Mas podemos ter os dois, e eu não desencorajaria nenhum deles. Um visual
ferramenta de script nos ajudaria a longo prazo, criando usuários iniciantes
que eventualmente trabalhará na indústria e estará em posição de decidir
use godot para um jogo real, e isso é bom. Além disso, o CTO da Square Enix
nos perguntou se o motor tinha uma linguagem de prototipagem visual, então isso significa
há também um nicho em grandes empresas para esse tipo de coisa, provavelmente
que valorizam P&D e possuem longos estágios de
pré-produção/prototipagem/experimentação com novas ideias, etc (ele também contou
que nossos jogos pareciam jogos de console e perguntou (duas vezes) qual país
fomos aprender a fazê-los :p ).

Em 14 de abril de 2016 às 03:26, Sergey Lapin [email protected] escreveu:

A coisa real sobre scripts visuais em geral, é uma tentativa fútil de
tornar a programação acessível a não programadores, o que é totalmente errado
aproximação.
A programação visual é mais difícil que a programação de texto regular. Para fazer isso
mais fácil você tem que escrever muitos blocos para cada caso na vida no tradicional
caminho e
deixe essas pessoas usá-los. Estes provaram ser menos eficazes do que pedir a um
bom programador para escrever código. O ditado "programação não é uma profissão,
todos podem fazer isso" está errado. Todas as tentativas de programação sem
programação é um desperdício.

Quanto à máquina de estado - eu estava pensando em implementar isso há algum tempo
atrás, mas isso não ajudará no programa de recursos visuais.
Isso pode ser feito facilmente para o seu jogo usando script de ferramentas e editor de nós,
que é uma ferramenta poderosa, muitas pessoas usam para ferramentas de jogos, como
editores de diálogos de jogos.

Em qui, 14 de abril de 2016 às 09:09, Aaron M [email protected] escreveu:

Eu não quero ter que dizer isso, mas essa é uma visão muito estreita do visual
ferramentas de script, Sergey. Quanto aos jogos que foram totalmente feitos com
eles,
alguns motores optaram completamente por eles, como o Construct, então você
não verá nenhum jogo fora desse mecanismo feito com scripts regulares. De outros
(mais sensato, imo) tem plugins como Unity e UE4. Eu pessoalmente
gostei muito de usar o uscript e o PlayMaker no Unity junto com meu
código porque enquanto algumas coisas são mais fáceis de codificar, muitas são mais fáceis de
script visualmente, particularmente máquinas de estado porque com um visual
scripter como PM dá-lhe muito feedback com breakpointsw é
somente
muito mais fácil olhar para o projeto de uma visão mais ampla.

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub
< https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

—
Você está recebendo isso porque está inscrito neste tópico.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -209779422

Você está apenas falando além de mim punto slapin, quer dizer, eu nunca disse nada sobre designers ou simplificação, mas de facilidade de uso mesmo para programadores, que experimentei sua utilidade. Não é como se você pudesse me dizer que é uma perda de tempo quando eu tenho a experiência anedótica mostrando exatamente o oposto. Eu prefiro que a opção esteja disponível _ao lado_ do script, você está agindo como se eu só pudesse escolher um ou outro e sou forçado a entregá-lo ao meu artista. Não é o caso de forma alguma.

Ótimo tópico, muitas opiniões 😁

O meu é simples. Voce esta certo!

Qualquer uma dessas ideias será um ótimo complemento para o gdscript 😁

Estou ansioso para experimentá-los quando eles aparecerem.

Eu acho que o gdscript também poderia fazer um pouco de amor para ser mais amigável.

Alguns nós não estão documentados completamente. Muitos não têm descrições.
Godot poderia fazer uso de algumas funções auxiliares para simplificar o desenvolvimento. Gamemaker gml é um bom exemplo:
https://twitter.com/uheartbeast/status/724326557108461568

Eu acho que o material de documentação é o principal PITA aqui, e é isso.
O desenvolvimento em si é bastante simples. A documentação e os tutoriais
são realmente necessários. Então, faça sua conta do youtube você mesmo (ou blog, ou
basta postar no fórum),
isso vai ajudar muito.

Em segunda-feira, 25 de abril de 2016 às 9h35, Todor Imreorov [email protected]
escreveu:

Eu acho que o gdscript também poderia fazer um pouco de amor para ser mais amigável.

Alguns nós não estão documentados completamente. Muitos não têm descrições.
Godot poderia fazer uso de algumas funções auxiliares para simplificar o desenvolvimento.
Gamemaker gml é um bom exemplo:
https://twitter.com/uheartbeast/status/724326557108461568

—
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/godotengine/godot/issues/1220#issuecomment -214163012

Bem, eu tenho vários pensamentos sobre isso.
Você pode tornar um mecanismo mais fácil de abordar incluindo algo como scripts visuais, e isso seria bom para todos os artistas que queriam começar a fazer jogos, mas simplesmente não têm experiência em programação, mas isso convida todo um outro conjunto de pessoas - ou seja, , pessoas sem qualquer habilidade. Pessoas para as quais a mudança para a programação em um editor de texto nunca estará em sua agenda, mesmo que isso signifique que o jogo final sofrerá. Pessoas que pensam que a única coisa difícil de fazer um jogo é a programação, e que com scripts visuais, de repente, essa restrição é levantada. Isso também não é incomum. Basta olhar para todos os mecanismos populares que tornam certas coisas mais fáceis para não programadores - toneladas de pás. Não estou dizendo que você não deve incluir scripts visuais porque isso significa que corremos o risco de obter shovelware, mas que deve ser implementado de uma forma que desencoraje esse tipo de pessoa de pensar que pode usar Godotengine para fazer o referido shovelware.
Meu outro problema é que uma das coisas em que o Godotengine é bom, e muitas pessoas gostam desse recurso, é que ele funciona muito bem com o git. O problema com o script visual é que ele geralmente é salvo em algum formato binário, e é um pesadelo gerenciar se você usar qualquer tipo de revisão de código-fonte. Se você tiver que implementar scripts visuais, eles devem ser salvos de maneira amigável ao texto. E se isso é impossível, bem difícil. Eu prefiro ter arquivos de projeto no Godotengine em um formato que seja amigável com o git do que ter scripts visuais que não funcionam bem com o git.
E a julgar por todo o trabalho necessário para implementar um sistema de script visual, e o fato de que você pode fazer certos tipos de jogos no Godotengine sem script visual sem perda de funcionalidade, eficiência ou desempenho, o que há de errado em apenas implementá-lo como um plug-in? Eu realmente não vejo nenhuma razão para que seja uma parte central do motor.

Apenas para adicionar meus 2 centavos sobre scripts visuais e por que não gosto da ideia:

Acho que a capacidade de conectar nós em qualquer arquivo gdscript é muito melhor, em termos de gerenciamento de código e proficiência.

Por exemplo, com scripts visuais (ou usando uma folha de eventos semelhante a C2), o que acontece se você tiver mais de 1.000 funções? Isso tornará muito pior, acredito, navegar por tudo. Estou portando meu jogo HTML 5 Action RPG agora para Godot (que tem mais de 10k + linhas de código e muito mais de 500 funções). _(Ele tem basicamente todos os recursos do Path of Exile, exceto animações e é multiplayer)_

Não há como isso ser possível para mim com scripts visuais. Eu acho que nós, e os desenvolvedores do godot aqui, devemos focar mais em recursos/eliminação de bugs do que em uma folha de eventos de código visual. Mas isso sou só eu :)

Edit: Como alguns outros disseram, talvez para projetos menores, eu acho...

A folha de eventos em construct2 suporta funções e elas funcionam da mesma forma que godots. Um simples filtro/caixa de pesquisa resolverá todos os problemas que você listou.

Mas os desenvolvedores da Godot não querem fazer uma abordagem de folha de eventos, mesmo que seja um caixa eletrônico popular. Tenho a impressão de que é mais provável obter algo semelhante à abordagem irreal do projeto. Dessa forma, os programadores se beneficiarão de um editor de máquina de estado adicionado ao seu arsenal

Para organizar o código de script visual em vonstruct2 , você o coloca em grupos que podem ser recolhidos. Isso é algo que mesmo o gdscript não pode fazer - você não pode recolher blocos de código. Então, de certa forma, a folha de eventos tem vantagens sobre o editor gdscript godots.

@reduz Eu estava olhando a Pure Data e o jeito que eles fazem é bem simples. Bem, verifique isso

Como você pode ver, digitar "Bang" transforma o objeto genérico em um objeto Bang.

E se o script visual pudesse simplesmente se tornar uma extensão do GD Script. Simplesmente coloque um nó genérico e digite Vector2 para ex e ele se tornará um objeto Vector2. Então, essencialmente, cada classe/objeto também é um nó.

Para executar funções, estou pensando que você pode obter outro nó que não seja um objeto, mas sim um nó de processo e digite algo como Vector2.dot e o nó se transformará em nó de ponto com 2 entradas e 1 saída.

o script visual é planejado em algum momento

Você não decepcionou :) <3

Como já existe VisualScripting, esse problema deve ser encerrado?

sim.

"Eu também sorri de forma positiva.
Porque será ótimo para mim como jogador se houver uma empresa tão grande quanto o Steam com toneladas de catálogos de jogos, abertos e DRM Free, criados por milhares de grandes desenvolvedores de jogos."
basta olhar para gog, é uma loja que vende jogos grátis de drm.

Respondendo off-topic a uma declaração de 2015, vamos lá :)