Godot: 非プログラマーのための使いやすいゲームデザイナー

ビジュアルスクリプティングはある時点で計画されています

2015年1月14日水曜日の午前6時20分、 RyanBramnotifications @ github.comは次のように書いています。

こんにちは、Godot開発者。

まず第一に、素晴らしいゲームエンジンを作成してくれた皆さんに感謝します
非常に寛容なライセンスで。 あなたの努力は多くの開発者と
夢を実現するための予算が厳しい学生。

Godotの現在の状況により、オープンソースゲームはより明るい未来を迎えます。
残念ながら、ゲームエンジンのオープンソースのほとんどは高度なもので設計されています
プログラミングに関する知識がほとんどないユーザーを念頭に置いてください。 まだ届かない
初心者のゲームメーカー。

私の提案は、使いやすいゲームデザイナー/エディターに
新しいプログラマーのタスクを容易にする直感的なGUIと事前定義されたクラス。 もっと
プログラマーとは、より多くのユーザーを意味します（Godotユーザーはゲームプログラマーであるため）。

私はこの仕事をうまくやっている1つのゲームエンジンを知っています。 Rubyから書かれています。
もともと日本から、そして世界中で英語に翻訳されました。 それはRPGと呼ばれています
メーカーVXエース
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace。 にもかかわらず
その名前の前にあるRPGの単語は、非RPGを作成するのに十分な能力があります
組み込みのRubyGame Scripting System（RGSS）を備えたゲーム。

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

次のリストは、RPGツクールエンジンで作成されたゲームの例です。

1. アレフ（RPGアドベンチャー） http://www.pioneervalleygames.com/
2. マナティーは約束されていません（アーケード） http://rpgmaker.net/games/5102/
3. Ragarokk-Bestiarium（カードゲーム） http://rpgmaker.net/games/5808/
4. 地球が攻撃中！ （シューター） http://rpgmaker.net/games/6561/
5. テラ（VisualNovel） http://rpgmaker.net/games/3956/
6. マナの思い出（アクションRPG）
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos-The Beginning（Horror） http://rpgmaker.net/games/6493/

GodotエンジンがRPGMakerと同じくらい人気になることを願っています。
RPGツクールよりも多くの機能。 初心者プログラマーは使いやすいものが必要です
インターフェース。 それが成功した場合、Okamスタジオは次のGOGまたはSteamになる可能性があります
これは、inde開発者によって作成された何千ものゲームを公開しています。

よろしく、ライアン

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220。

@ RyanBram-ここでは、アイデアに反対票を投じようとはしていません-将来的には役立つ可能性がありますが、ビジュアルスクリプティングが効果的なスクリプティング手段であるかどうかはわかりません。 はっきりとは言えませんが、あなたが投稿したより複雑なゲームは、視覚的ではなくテキストで書かれている可能性が高いと思います。 確かに、ビジュアルスクリプトは新しいユーザーが使用するもののように見えますが、プロジェクトを適切に完了するために必要な実際のツールの学習が遅れます。 しかし、それはエンジンをより親しみやすくする可能性があるので、私にはわかりません。

エンジンに組み込む必要のあるものとは対照的に、ユーザーがGDScriptを使用してすべてGodotでビジュアルプログラミングシステムを作成することも可能であるはずですよね？ でも、それについてはよくわかりません。

RPGツクールはもっと「改造」アプローチを取っているようで、GodotがRPGツクールのように見えるとしたら、別の種類のゲームを作るつもりの人は背を向けます。 つまり、基本的に提案しているのは、godotをGameMakerのように見せることです（これは理解できます。多くの人がゲームを作りたいと思っていますが、プログラミングを知りません）が、制限があります:)
おそらく起こることは、GodotがLeadwerksとBGEが持っているものと同様のノード動作グラフエディタを取得することです。 これはGUI要素で非常にうまく機能します。残りの部分は、可能な限り簡単かつ強力にするために、いくつかの調査と大量のコミュニティフィードバックが必要になります。

@ SolarLune 、Godotでゲームを構築し、その上にエディターを追加して、ゲームを細部までモッディングできるようにすることができます（GraphNodesとUIの残りの部分を使用して、遊ぶのがとても楽しいです）。余分なGDscriptコードを上に置くと、これが最善のアプローチだと思います。完全なゲームゲーム（RPG、FPS、RTS）を個別に出荷し、そのすべての側面を微調整できるようにするためです。 Godotで作られたコンストラクター。

@SolarLune ：ビジュアルスクリプティングは、
プログラマー、それはあなたが一緒に遊ぶためのブロックを作ることができます。 この
Unrealでのアプローチは便利です。 交換することはできないと思います
完全にプログラミング（あなたがマゾヒストでない限り）、しかしそれはのために働くことができます
プログラマー以外の人のためにテンプレートブロックを作る人もいます。

2015年1月14日水曜日の午後4時23分、 TheoXDnotifications @ github.comは次のように書いています。

RPGツクールはもっと「モッディング」アプローチを取っているようです。
RPGツクールのように見える-違うものを作るつもりのある人
ある種のゲームは背を向けます。 つまり、基本的に提案しているのは
godotをGameMakerのように見せます（これは理解できる、多くの人が
ゲームを作りたいがプログラミングがわからない）でも限界があります:)
おそらく起こることは、Godotがノード動作グラフを取得することです
LeadwerksとBGEが持っているものと同様のエディタ。 これは非常にうまく機能します
GUI要素、残りはいくつかの研究とたくさんのコミュニティを必要とします
フィードバック、それを可能な限り簡単かつ強力にするために。

@SolarLune https://github.com/SolarLune 、ゲームを構築することが可能
Godotで、ゲームをすべての人に改造できるエディターを上に追加します
（GraphNodesと残りのUIを使用して）詳細はほとんどなく、
上に追加のGDscriptコードを記述します。これが最善のアプローチだと思いますが、
完全なゲームゲーム（RPG、FPS、RTS）を個別に出荷し、微調整できるようにする
それのあらゆる側面。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-69974733 。

ええと、私が知っていることから、GodotにはすでにノードベースのUIコード（アニメーションツリーと現在はビジュアルシェーダーエディター用）があり、将来的には「ロジック」ツリータイプを作成するために使用できます。

ただし、最大限の柔軟性が必要な場合はGDscriptを使用し、ロジックノードを有用なものにするためにGDscriptを実行するためのスクリプトノードが必要になることに注意する必要があります（より複雑で高度なものの場合）。

UE4は現在、非常に複雑でない限りブループリントですべてを実行することはできません。GameMakerは、（コードブロックを使用して）最大限の柔軟性を得るためにGMLを使用することを期待しています。また、BGEは（コードブリックを使用して）最大限の能力を発揮するためにPythonでスクリプトを作成する必要があります。 ラピッドプロトタイピングやそれほど複雑でないロジックの状況でのビジュアル編集の有用性を軽視することはできませんが、コードで実行できるすべてのことを実行できないことがよくあります。

ビジュアルスクリプティングはある時点で計画されています

シンプルで前向きな反応をありがとう。

皆さん、この提案にコメントしてくれてありがとう。 手作業でコーディングを置き換えるのに十分な能力を備えた、簡単で視覚的なエディターはないと思います。 この機能は、その位置を置き換えるのではなく、通常のコーディングを補完するものとして提案します。

RPGツクールVXエースでは、高度な機能のほとんどが手作業でコーディングされています。 上級プログラマーは通常、カジュアルユーザー（キャラクター名、スキル、ポートレート、スプライトなど）がGUIエディターで値を編集できる高度な改造スクリプトを提供します。 Ruby Game Scripting Systemを使用すると、モンキーパッチを適用できます。 これが、互換性の問題を回避するために、上級ユーザーが提供するほとんどのスクリプトがRPGMaker開発者によって元の事前定義されたクラスを置き換えない理由です。

比較のために：
KDEおよびGNOMEプロジェクトは、Linuxの強力なシェルコマンドを置き換えることを意図していません。代わりに、プロジェクトは、使いやすさとLinuxのパワーの間のギャップを埋めようとしているだけです。

OkamスタジオがSteamのようなものであるというアイデアについて私は微笑んだ... :)）

2015年1月14日午後5時20分、RyanBramは次のように書いています。

こんにちは、Godot開発者。

まず第一に、素晴らしいゲームを作成してくれた皆さんに感謝します
非常に寛容なライセンスを持つエンジン。 あなたの努力は多くの人を助けます
夢を実現するための予算が厳しい開発者や学生。

Godotの現在の状況により、オープンソースゲームはより明るくなります
将来。 残念ながら、ゲームエンジンのオープンソースのほとんどは設計されています
プログラミングに関する知識がほとんどなく、上級ユーザーを念頭に置いています。 これ
まだ初心者のゲームメーカーに到達することはできません。

私の提案は、使いやすいゲームデザイナー/エディターに
新しいプログラマーのタスクを容易にする直感的なGUIと事前定義されたクラス。
より多くのプログラマーはより多くのユーザーを意味します（Godotユーザーはゲームプログラマーであるため）。

私はこの仕事をうまくやっている1つのゲームエンジンを知っています。 Rubyから書かれています。
もともと日本から、そして世界中で英語に翻訳されました。 です
RPGツクールVXエースと呼ばれる
http://www.rpgmakerweb.com/products/programs/rpg-maker-vx-ace。
その名前の前にRPGの単語があるにもかかわらず、それは十分に能力があります
組み込みのRubyGame Scripting System（RGSS）を使用して非RPGゲームを作成します。

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

次のリストは、RPGツクールエンジンで作成されたゲームの例です。

1. アレフ（RPGアドベンチャー） http://www.pioneervalleygames.com/
2. マナティーは約束されていません（アーケード） http://rpgmaker.net/games/5102/
3. Ragarokk-Bestiarium（カードゲーム） http://rpgmaker.net/games/5808/
4. 地球が攻撃中！ （シューター） http://rpgmaker.net/games/6561/
5. テラ（VisualNovel） http://rpgmaker.net/games/3956/
6. マナの思い出（アクションRPG）
   http://www.atelier-rgss.com/Project/Mana/Project_Mana_Story.html
7. Myhos-The Beginning（Horror） http://rpgmaker.net/games/6493/

GodotエンジンがRPGMakerと同じくらい人気になることを願っています。
RPGツクールよりもはるかに多くの機能。 初心者プログラマーはただ必要です
使いやすいインターフェース。 それが成功した場合、Okamスタジオは次になるかもしれません
inde開発者によって作成された何千ものゲームを公開するGOGまたはSteam。

よろしく、ライアン

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220。

Unrealには、実際にプロジェクトのテンプレートがあります。
ビジュアルスクリプティングまたはフルスクリプティングタイプのワークフロー...さらには
ビジュアル編集用のコードのブロックは、ビジュアルスタジオからアクセスできます。
カスタマイズ... :)

2015年1月15日午前3時44分、JuanLinietskyは次のように書いています。

@SolarLune ：ビジュアルスクリプティングは、
プログラマー、それはあなたが一緒に遊ぶためのブロックを作ることができます。
この
Unrealでのアプローチは便利です。 交換することはできないと思います
完全にプログラミング（あなたがマゾヒストでない限り）、しかしそれはのために働くことができます
プログラマー以外の人のためにテンプレートブロックを作る人もいます。

2015年1月14日水曜日の午後4時23分、 TheoXDnotifications @ github.comは次のように書いています。

RPGツクールはもっと「モッディング」アプローチを取っているようです。
RPGツクールのように見える-違うものを作るつもりのある人
ある種のゲームは背を向けます。 つまり、基本的に提案しているのは
godotをGameMakerのように見せます（これは理解できる、多くの
人
ゲームを作りたいがプログラミングがわからない）でも限界があります:)
おそらく起こることは、Godotがノード動作グラフを取得することです
LeadwerksとBGEが持っているものと同様のエディタ。 これは非常にうまく機能します
と
GUI要素、残りはいくつかの調査と大量の調査が必要になります
コミュニティ
フィードバック、それを可能な限り簡単かつ強力にするために。

@SolarLune https://github.com/SolarLune 、ゲームを構築することが可能
Godotで、ゲームをすべての人に改造できるエディターを上に追加します
（GraphNodesと残りのUIを使用して）詳細はほとんどなく、
に許可します
上に追加のGDscriptコードを書いてください。これが最高だと思います
アプローチ、
完全なゲームゲーム（RPG、FPS、RTS）を個別に出荷し、
微調整
それのあらゆる側面。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-69974733 。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-69978224 。

OkamスタジオがSteamのようなものであるというアイデアについて私は微笑んだ... :)）

私も前向きに微笑んだ。
何千人もの優れたゲーム開発者によって作成された、大量のゲームカタログ、オープン、DRM Freeを備えた、Steamと同じくらい大きな会社があれば、ゲーマーとして私にとって素晴らしいことになるからです。

Unrealには、実際にプロジェクトのテンプレートがあります。
ビジュアルスクリプティングまたはフルスクリプティングタイプのワークフロー...さらには
ビジュアル編集用のコードのブロックは、ビジュアルスタジオからアクセスできます。
カスタマイズ... :)

Godotで利用できるようになれば素晴らしいです。

よろしく、
ライアン

こんにちはライアン

コンストラクト2をチェックアウトしましたか？ それは私のお気に入りのビジュアルゲームデザイナーの1人であり、非常に使いやすいです。

Godotでのビジュアルプログラミングは、やや難しいと思います（Godotは2Dと3Dの両方を実行するため、スコープがはるかに大きくなります）。
また、エンジンの基礎となるすべてのブロックが配置されたときに、かなり後で組み込まれる可能性があります。

reduzにはこれに関する独自のロードマップがあることは知っていますが、他のエディター/エンジンの更新よりもこれを優先しないことを願っています。 私は、Godotを非プログラマーよりも、初心者または半熟練のプログラマーに使用してもらいたいと思っています。 しかし、それは私だけです。

こんにちはライアン

コンストラクト2をチェックアウトしましたか？ それは私のお気に入りのビジュアルゲームデザイナーの1人であり、非常に使いやすいです。

私はコンストラクト2を試しました。それは素晴らしくて素晴らしいです。 結果として得られるゲームもクロスプラットフォームなので、大きなプラスになります。 残念ながら、RPGゲームを簡単に作成するためのチュートリアルはまだ見つかりません。 今のところ、RPG Maker VX Aceを使い続け、 MKXP Projectを使用して、ゲームを多くのプラットフォーム（Androidを含む）に移植しようとしています。

共有していただきありがとうございます。 Godotでのビジュアルプログラミングを楽しみにしています。

よろしくお願いします、
ライアン

ビジュアルスクリプティングアプローチの場合-gdevelop、マルチメディアフュージョン、コンストラクト2からメモを取ることができます。これらのエンジンはビジュアルスクリプティングに100％依存しています。 式が必要な構文についてはまだ学ぶ必要がありますが、式エディターを使用すると、適切なコマンドを非常に簡単に見つけることができます。 これらの3つのエンジンにより、ゲームメーカーやRPGメーカーとは対照的に、ビジュアルスクリプトを使用してあらゆるタイプのゲームを自由に作成できます。

RPGツクールは非常に限られているため、実際には良い例ではありません。
ノードベースのスクリプトは、スペースの使用に関して非常に非効率的です。巨大なノードグラフをパンしたり、ズームインおよびズームアウトしたりします。 それをコンストラクト2と比較してください。ここでは、すべてが明確にレイアウトされており、タイトで読みやすいので、勝者が得られます。

BGEは、ノードベースのアプローチとロジックブロックを組み合わせようとするため、おそらくここでは最悪の例です。 私はこれがなぜ悪いのかについて書きました：
http://blenderartists.org/forum/showthread.php?323905-comparing-BGE-logic-bricks-with-Scirra-Construct-event-sheet-for-prototyping

ビジュアルスクリプティングを行う場合は、一般的なノードベースのエディタで半分お尻にしないでください。 より多くのプログラマー以外の人にエンジンを使用してもらいたい場合は、construct2やマルチメディアフュージョンなど、より優れたデザインで何かを実行してください。

プログラミングの二次的な方法として、このように実装された_only_のようなものを見たいと思います。 コードとは対照的に、ビジュアルスクリプトは、生産性をかなり大幅に低下させます。 また、デバッグとリファクタリングがはるかに困難になる傾向があります。 私が考えることができる1つの大きな利点は（プログラマー以外の人にとって魅力的であることに加えて）、ビジュアルスクリプティングが実際のGDScriptコード（IE。コード）を生成または少なくとも表示できる場合、優れた教育ツールになる傾向があることです。 org）。 逆にする必要はないと思います（つまり、GDScriptからVisual）。 これは、学校がGodotをクラスに採用するための優れた方法だと思います。

ここに、コードとビジュアルスクリプティングの2つの大きな違いがあります。これは、親しみやすさに関して最も重要だと思います。 これは、10フィートのポールでビジュアルスクリプトに触れない人から来ていますが、一部の人にとっては魅力的だと理解しています:)

コード：コードには、従う必要のある特定の構文規則がある傾向があります。 私の推測では、これが非プログラマーをオフにする主なものになる傾向があります。 IE。 GDScriptでは、関数宣言の最後にコロンがあります。if、for、whileループなどです。適切にインデントする必要があります。 「varmyInteger = 1」のような変数を宣言するときは、varキーワードを使用する必要があります。 ほとんどの言語では、従う必要のある主要な構文規則が約3つまたは4つある傾向があり、私の意見では、習得するのはそれほど難しくありません。 一握りの小さなスクリプトを書いた後、アーティストでさえそれらを学ぶことができます。 これは、アンサンブルスタジオでエイジオブエンパイアの3つのゲームすべてに取り組んだ2人の非常に才能のあるアーティストと仕事をしているためです。 1つはUnityScriptでかなりのコードを記述し、もう1つはC＃で大量のコードを記述しました。

ビジュアル：メソッド、変数、ステートメントなどのドロップダウンメニューが表示される傾向があります。ただし、探している関数、プロパティなど、それらが何をするのか、場合によってはどのように機能するのかを知る必要があります。 あなたはまだ問題を解決しなければなりません。 それでも変数を使用し、スクリプト全体で変数が何をしているかを追跡する必要があります。 コードを書くのと同じくらい簡単に論理エラーが発生する可能性があります。

実際にコードを記述できることは、生産性の観点から最終的にははるかに優れた方法だと思います。 ただし、どちらもあなたをより良い/より悪いプログラマーにすることはできません。 ビジュアルスクリプティングは本当に良い教育ツールだと思いますが、物事を適切に構成する方法、特に問題解決の方法がわからない（または学びたい）場合は、ビジュアルスクリプティングは少し役に立ちません。

私は少し異なるアプローチを取ります。 godotエディターはそれ自体で駆動されるため、純粋なGDscriptで同様のエディターインターフェイスを簡単に再作成できます。

したがって、私の提案は、コンストラクターを完全にgodotでスクリプト化して、個別に出荷することです。 これにより、プログラマーと非プログラマーは、異なるツールを使用しながら同じプロジェクトで作業することができます。 唯一の問題は、プログラマー以外の人が両方のツールを同時に処理しなければならないことですが、ちょっと、私はもっと悪いxDグリッドマップエディター、シェーダーエディター、アニメーションエディター、コードエディターを再作成できますが、colladaインポーターは凸型ですジェネレーター、エクスポーター-それほど簡単ではありません。 それでも車輪の再発明のように感じますが、多くのことを単純化することができます。

コンストラクターコアは、ダウンロード可能なコンテンツなどを備えたあらゆるゲームジャンル（FPS、RTS、GPS ....）に採用できます。コミュニティが維持されている場合は、すべてがGDscriptであるため、貢献が容易になります。
すぐにgodotにビジュアルスクリプトが登場する可能性は低いですが、他の人がその上にコンストラクターを作成するのを妨げることはありません。 誰かがBlender2.5を使って、インテリアをデザインするためのツールを作ったのを見たことがあります。

複数の編集者がいると、ゴドットの開発が断片化する可能性があると思います。 gdscriptの上に構築されるビジュアルスクリプティングツールのために、うまく設計された中央プロジェクトが1つ必要です。

怠惰にならないで、あなたの研究をしてください。 他の純粋にビジュアルなスクリプトエンジンを見てください。 ユーザーベース（人気度）を比較し、キックスターター、Steam、その他のプラットフォームでの柔軟性（ゲームの種類）を比較します。
彼らの設計アプローチを調べてください。

次に、紙にデザインします。 ノードアプローチをコピーするだけではいけません。 シェーダーにノードを使用することは問題ありませんが、ロジックに到達すると、スクロールして理解しようとすると、混乱が1つ発生します。

私を信じて、私はすべてを試しました。 Unityのプレイメーカー、UnrealのKismet、rpgメーカー、stencylなど。
Construct2は、マルチメディアフュージョンとともにトップになります。 これらは最も人気のあるものであり、最も柔軟なアプローチを採用しています。 そして、彼らは両方とも資産市場の店を持っています。
それらは非常に柔軟性があり、それらを使用して作成されたゲームを調べると、非常に多様なジャンルがあります。

これについてさらに賢くなったら、Gdevelopとチームを組むことができます。Gdevelopは、html5ゲームを作成するビジュアルスクリプトエディターをすでに備えている別のオープンソースプロジェクトです。
そのデザインとソースコードを調べてください。

このスレッドに投票する場合、主にプログラマーが投票に参加するため、完全に間違った場所になると確信しています。

ビジュアルスクリプティングシステムは、プログラマーではなく、アーティスト向けに設計する必要があります。 UnityのPlayMakerのようなものに対する私の完全な嫌悪について不満を言うことができる限り、真実はアーティストがそれを愛しているということです。 そのため、約2000件のレビューがあり、5つ星です。 投票でConstruct2のスクリプトのようなものを使用する場合は、A）プログラマーがGDScriptで直接プログラミングでき、B）多くのアーティストがプログラムできるため、視覚的なスクリプトをまったく使用しないことに投票します。それによって即座にオフになり、他の場所に移動します。 どちらもコーディングできる2人のアーティストの友人が、Construct 2を見ていて、コードを書くのとほとんど同じなので、Construct2のプログラミングインターフェイスを楽しんでいたからです。

ビジュアルスクリプト言語は、多くの単語ではなく、非常に視覚的である必要があります。 一見コードのように見えるべきではありません。 「視覚的な人々」に合わせて調整する必要があります。そうしないと、そもそもそれを作成しても意味がありません。 アーティストは、プログラムが何をしているかを視覚的に把握できるため、ノードグラフに慣れており、好む傾向があります。 繰り返しになりますが、私はノードグラフを我慢できないので自分自身は好きではありませんが、私はプログラマーであり、私の投票はこの分野で実際にカウントされるべきではありません。

アーティスト/デザイナー向けにデザインする必要があることに同意します。
しかし、words = complexityという論理には同意しません。

誰かを座らせて、2つのうちの1つを使用するように教えると、2つのうちの簡単なものとしてconstruct2が表示されます。 どうして？
ノードよりも明確だからです。 はるかに明確です。 条件とアクションがあります。 最初を左側に置き、もう一方を右側に置きます。
2つのうちのいずれかを追加するために、コマンドを知っている必要はありません。 それらはすべてそこにリストされており、1日として明確に追加できます。 それぞれにアイコンが付いています。これは視覚的なヒントです。

Playmakerやその他のノードベースのシステムでは、ノードを別のノードにフックするために、2つを接続できるかどうかを最初に理解する必要があるため、さらに多くの学習が必要です。 それは単に条件->アクションではありません。 ノードははるかに複雑で、視覚的なヒントがありません。 プレイメーカーのアイコンはどこで見ましたか？
間違いを犯しやすいです。 その中のロジックを読み取るのははるかに困難です。
https://www.scirra.com/tutorials/top
また、C2は優れたデザインのビジュアルプログラミングツールであるため、現時点では2Dゲームに限定されていますが、プレイメーカーよりもはるかに多くのアクティブユーザーのコミュニティがあります。 ウェブ上のはるかに多くのビデオチュートリアル（プレイメーカーよりも多くの人々がそれを使用する方法を理解しています）、はるかに多くの完了したプロジェクト、健全な活発な市場とフォーラム、そして開発者とユーザー間のすべての活発なコミュニケーションのほとんど。 したがって、開発者はアーティストユーザーが何を望んでいるかを知っています。

コンストラクトユーザーは、イベントシートのスクリーンショットを撮るだけで、その様子を1日で明確に把握できます。 フォーラムにアクセスして、自分の目で確かめてください。 プレイメーカーよりもはるかに多くのユーザーがいると私は主張します。

どのノードベースのシステムよりも、ロジックをセットアップするのにかかる作業が少ないと私は主張します。

あなたがそれらを気に入っていることはわかりますが、プログラマーのエンジンであると宣言する前に、少なくともconstruct2を試してください。
彼らのフォーラムとユーザーベースを見てください。 プレイメーカーよりも優れた担当者がいるとは言えません。 すでに成功しているエンジンのプラグインではなく、それ自体でうまく設計されていることで、その優れた担当者を獲得することができました。 これは、すべてのアーティストが使用できる純粋なビジュアルプログラミングツールです。 私はアーティストであり、playmakerを試しました-construct2よりも難しいです。 C2のフォーラムにアクセスして、プレイメーカーの方が使いやすいことを説得してみてください。笑うだけです。 ：D
あなた自身がプログラマーではありませんか？ あなたは私よりもgithubプロジェクトに貢献してくれました。 それはあなたが学びやすい声明を出すべきではないという意味ではありませんか？

プログラマーの視点からあなたのポイントを理解しています。 2つのうちどちらかを選択する必要がある場合は、Constructモデルも使用します。 ただし、私が言ったように、GitHubメーリングリストを読む人のほとんどはプログラマーであるため、これはこの決定を下すのに最悪の場所です。

私はプログラマーよりもアーティストに多くのキャリアを費やしてきました。 私は過去18年間、両方を定期的に行ってきましたが（そして両方に情熱を注いでいます）、プロのプログラマーになる前はプロのアーティストでした。 私が学位を持っていることさえ気にしないというわけではありません。私の学位はデジタルアニメーションと視覚効果です。 私の知る限り、私が取り組んだコマーシャルは、カンザスシティで数年経った今でも再生されています。 Hallmark、Sprint、Radio Shack、Honda、そして私が忘れそうな他のいくつかのショットに取り組んできました。 ブルース・ブラニットと一緒に「ワールドビルダー」でかなりの数のショットを制作するのもとても楽しかったです。

https://www.youtube.com/watch?v=QP3YywgRx5A
クレジットのネイサン・ウォーデンは私です

私はこれを自慢するために言っているのではありません、私はこれを主張するために言っています。 私は間違っているかもしれませんが、アーティストの周りで多くの時間を過ごしたアーティストとして、私はアーティストが好きなものを知っていると思います。 彼らはコンストラクターのようなものをあまり好きではない傾向があります。 彼らは親密に感じ、まったく異なるアプリを選択する傾向があります。 一般に、アーティストはプログラマーとは非常に異なるミンセットを持っています。 友達のエリックに教えようとしている技術的なことについて話すとき、こういう言葉が口から出てくることがよくあります。「ネイト、見せられないのなら、私はとても視覚的な人です。視覚的には壁に向かって話している方がいいでしょう。」

アーティストが線形シェーダーシステムではなく、ノードベースのシェーダーグラフのようなものを楽しむのには理由があります。 彼らは何が起こっているのかを視覚化することができます。 アーティストがお気に入りの3Dアプリケーションにリニアシェーダーシステムがないことについて不満を言うのを聞いたことがないと思いますが、ノードベースのシェーダーシステムがない場合は定期的に不平を言います。

アーティストがAfterEffectsよりもFusionのようなアプリを好むのには理由があります。 ほとんどの場合、より視覚的であるため、線形に基づいてノードを選択します。

したがって、ノードベースのシステムがアーティストにアピールするもう2つの理由は次のとおりです。

1）視覚的にはるかに魅力的に見えます。
2）それは彼らがすでに慣れている設計パラダイムの範囲内に収まります。 IEのシェーディングと合成

それが本当の意味です。 他のゲームエンジンがノードベースのプログラミングを使用しているために、アーティストが1つのルックを見て次のゲームエンジンに渡す場合、Godotはビジュアルスクリプティングをまったく使用しないでください。おそらく、ほんの一握りの人しかいないでしょう。誰がそれを使用するのか、それはその時点からより多くのコードを維持することを意味します。

あなたはConstruct2が何であるかについて何か考えを持っていると確信していますか？ あなたはその名前を正しく綴っていません。
「コンストラクタ」とは呼ばれません。

「一見コードのように見えるべきではない」という理由で、ノードを使用する必要があることに完全に同意しません。

見た目よりもはっきりしていることが重要です。 ロジックが何をするかを明確にすることは、エディターが一見したときよりも重要です。 Construct2はコードのようには見えません-テキストは平易な英語で書かれており、アクションまたは条件が何をするかは明らかです。 C2を使用している人は、ほとんどが視覚的な人である傾向があります。

イベントシートは常にノードに勝ちます-しかし、あなたはそれを見せようとします。 より少ないパンで画面により多くの情報を詰め込むことができます-ロジックが何をするかがより明白になります。 また、視覚的な手がかり（アイコン）は、アーティストの目ではるかに簡単に見つけることができます。
ノードにはアイコンがなく、テキストに大きな制限があります。
そのため、多くの場合、ノードのサイズが非常に限られているため、ノードはそれが何をするのかを明確に説明していません。デザインでは、平易な英語ではなく、あいまいな用語を使用する必要があります。

別のポイント：
イベントシートが読み取られ、上から下に実行されます。 これは明白で予測可能です。
ノードネットワークを使用すると、目はあちこちを移動し、枝に分かれます。 それはずっと複雑になります。

実際のユーザーエクスペリエンスではなく、最初の一瞥に関する第三者の意見の話は、ここで重要視されるべきではありません。 私も非常に視覚的な人ですが、すでに多くのビジュアルスクリプトエンジンを使用しています。 たとえば小さなプロジェクトで、実際のエンジンをしばらく使用せずに人々が議論をするのを見るのは、首の痛みです。

godotのデザイナー/開発者/ビジュアルの人々に、これらのエンジンを実際に小規模なプロジェクトで試してから結論を出すことをお勧めします。 これらのサードパーティの話は十分です。 実践的な調査と、一方が他方より優れている理由について論理的に述べられた事例が必要です。 信じられないかもしれませんが、視覚的な人々にも常識があります。

オフトピック：
Fusion vs AfterEffectsの例では、同じ効果を多くのレイヤーに複製できる複雑なシーンでレイヤーを使用すると非常に面倒になる可能性があるため、合成にはノードベースのアプローチが好まれます。 ノードを使用すると、合成に関してより柔軟性があり、1つのエフェクトを多くのレイヤーにフックするだけです。 ただし、ノードはレイヤーよりも複雑です。

私はほとんどすべての点であなたに同意しますが、それらの点はまだプログラマーの観点からです。 ビジュアルスクリプティングシステムを一日中使用する必要がある場合は、通常のコードに最も似ているものを選択します。 そのため、私はcode.orgを使用してプログラミングする方法を学びたい子供たちに教えるのが大好きです。 私は本当にこのスタイルの大ファンです。 プログラミング方法を「プログラムしたい」人に教えるのに適しています。

そして、はい、私は構築が間違っていると言いました、ごめんなさい。 いいえ、個人的には使用していません。 しかし、それが使用するスクリプトパラダイムは、想像力の範囲を超えた新しい概念ではないため、問題ではありません。したがって、私の主張は、Construct自体についてでさえありません。 プログラマーではなく、芸術家に関係するスクリプトのスタイルについてです。

ノードベースのシステムでは、各ノード内にいくつかの条件とイベントおよび機能を含めることができます。 次に、たとえば、ノードにInputのような名前を付けることができます。 その中にはすべてのジョイスティック入力が含まれ、ユーザーはどのイベントを使用するかを指示します。 IE。 彼らは「火」のようなイベントを指定するでしょう。 そのイベントは、それらが接続したノードへの遷移を引き起こします。

これは、発砲を単純に処理する武器で使用できる簡単な例です。 シンプルですが、強力であり、コードのようには見えないことに注意してください。

最後に、ブロックベースのスクリプトまたはノードベースのスクリプトの両方をインターフェイスの観点から見栄えよくすることができるので、その点について議論する時間を無駄にすることはありません。

しかし、「一見コードのように見えるべきではない」と言ったとき。 多くのアーティストは、無期限に毎日何を見ているのかを気にします。 アプリが魅力的でない場合や威圧的に見える場合は、アプリ全体を拒否します。 ブロックベースは、典型的なアーティストにとっては威圧的で混乱を招くように見えると思います。 それはプログラマーにとって何かのように見えます、そしてそれはそうです。

@blurymind 、

グラフノードは実際には概念的なUMLから来ました。 プログラミングを行っていないオーディエンス（プロジェクトマネージャー、コンシューマー、アーティスト）が理解できる方法で、コードをグラフィカルに表現します。 これはUE4 / Unityが使用するものです。 これは、業界の誰もが知っていることです。 コンストラクターは通常、異なるアプローチを取ります。このアプローチがどれほど優れているかは、それを使用するユーザーの数によって定義されません。

どこにでも学習曲線があり、Construct2も例外ではありません。 しかし、議論を裏付けることなく、C2のものをGodotに強制しないようにしましょう。 より複雑なゲームではイベントシートが長くなり、グラフノードよりも多くのスペースを浪費することになります。 「アクションの追加」ボタンだけが、それ自体に独自の行を持っています。 これは基本的に、プログラマーがコードのブロックを解釈する方法です。 だから、それほど悪くはない。

個人的には、両方を使用できない理由はわかりませんが、開発者はすでに十分な数を持っているので、すぐには発生しません。 これが、プログラマーと協力してプログラマー以外の人がほとんど推進する、より速く進化する別のアプローチを提案した理由です。

これは、ノードごとに複数のイベントを持つことができることを示すためのより良い例です。 また、各ノード（または状態）は非ブロッキングであるため、他のノードグラフを同時に実行できることにも注意してください。

しかし、ほら、あなたのスクリーンショットを見ただけでは、そのロジックが何をするのかわかりません。 「firePrimary」と「fireSecondary」とは一体何ですか？
次に、construct2の投稿したスクリーンショットまでスクロールします。
Construct2では、左側の条件は「R」が押されたとき」または短い平易な英語の何かを読み取ります-その横にキーボードアイコンがあります！

両方をアーティストに見せて、どちらがより明確かを尋ねます。

より複雑なノード設定も示してください：）C2スクリーンショットは、ゲームロジック全体を示しています。 あなたのイベントは1つだけです。 同じロジックをノードを含む1つのスクリーンショットに収めることができますか？ 私はそうは思いません。

ノードの例が情報を覆い隠していることを参照してください。
ノード内に何が設定されているかを確認するには、ノードを選択する必要があります。
人間の言葉ではなく、あいまいなプログラマーの用語を使用しています（「イベントの送信」、「結果の保存」は一体何ですか？）。
Construct2は、すべてを1つの場所に表示し、プログラマー以外の人にも理解できます。 ビジュアルプログラミングのポイントは、用語を学ぶ必要性を取り除くことです。

私はプログラマーではありません。 実際のコードを書いた経験はありません。 それでも、construct2を使用してゲームを簡単に作成できます。完全なゲームになると、ノードを使用するのは非常に困難です。

私は、誰もがすでにうまくやる方法を知っているものは何でも常に投票することを理解しています。 しかし、あなたが認めたように、あなたはプログラマーであり、実際にC2を使用したことはありません。 そして、私はコーディングの経験がなく、ノードとC2アプローチの両方を使用したアーティストであるという声明を守ります。

なぜ一方を他方の上に使用するのかについて、私はあなたに良い論理的な議論を与えています。
「ノードはより視覚的です」や「非現実的なノードの使用」などのステートメントを私に与えています。 それらは意見の表明です。 そして、あなたは両方ともプログラマーであることを認めます。

私が自分の主張を支持していないと言っているのは、construct2を調べたり、ノードの代替としての設計と見なしたりする必要がないことの確認にすぎません。 悲しいことに、他の方法であなたを説得するのは私の時間の無駄です。

@TheoXD
私があなたを正しく読んでいれば、私はあなたに完全に同意します。 両方を別々のプラグイン/モジュールとして持つといいでしょう。 したがって、その下には実際のGDScriptがありますが、必要なものを使用して視覚化することができます。 これは可能だと思います。 ノードベースのアプローチでは、ノードを区切るための特別なコメント（つまり、＃node name = "Input"と#endnode）などのフラグが必要になる場合がありますが、ノードグラフから始めた場合は自動的に行われるため、それほど大きな問題にはなりません。 ブロックアプローチは簡単だと思います。

そのようなことはあなたが意味したことですか？

上で述べたように、私はblock / Construct / code.orgメソッドが本当に好きです。それは、プログラミングを教えるのに非常にうまく機能するからです。 プログラミングを必要悪と見なす人には向いていないと思います。

@blurymind
それが意味をなさない理由は、あなたがそれに精通していないからです。 上のConstructイメージを見ると、何が起こっているのかまったくわかりません。悪いからではなく、慣れていないからです。

ノードをクリックするまでノードの下にあるものを見ることができない限り、ノードをセットアップした後は、すでにそこにあることがわかっているものをふるいにかけることに意味はありません。 左クリックと右クリックがあり、一次弾薬と二次弾薬が発射されることはすでに知っています。 プライマリファイアノードとセカンダリファイアノードが何をするかはすでに知っています。 作ってから変わってないのに、見るたびに細かいところまで見ないといけないのはなぜですか？ そのため、基礎となるロジックは雑然としています。 これが、ノードがアーティストやプログラマーにやさしいもう1つの理由です。 特定のロジックをより一般的なチャンクに分割できます。 これにより、全体像を把握し、どうしても必要な場合にのみ詳細を気にすることができます。

現在、実際に公開されているモバイルゲームの実際のプロジェクトを調べていますが、ほとんどすべてのノードグラフは最大で2〜4ノードであるため、通常、複雑な設定が必要ない場合は、より複雑な設定を示すのは困難です。

あなたが精巧になりたいのなら、これは彼らが来るのとほぼ同じくらい非プログラマーである人によって書かれた同じアプリからのものです。 これは、ゲームで最も複雑なグラフの1つです。 メインプレイヤーの動きを制御します。

（それはあなたがブロックでできないもう一つのことはそれらをサムスの船のように見せることです、ハハ）

プロンプトを表示せずに、Construct2イメージを一方の画面に表示し、上記のノードグラフをもう一方の画面に表示して、妻（プログラマーではない）に「使用する必要がある場合はどちらを使用しますか」と尋ねました。毎日？」と彼女はノードグラフを指差して「これだ」と言った。 それが決定的なものではないことは知っていますが、それがそれほど威圧的ではないという事実は、私が彼女にそれを学ばせ始める機会さえはるかに多いことを意味します。 それが恐ろしいように見える場合、私が彼女に基本を学ぶために座らせる前に、彼女は彼女の脳を遮断するかもしれません。

彼をどちらか一方に押しやることなく、昨日、ゲーム業界に20年近く携わっている（そしてConstruct2を使用している）アーティストの友人（3つのAge of Empiresゲームすべてに取り組んだ同じ人）に尋ねました。彼は他のアーティストが好むと思うものとノードグラフも言った。

とにかく、私は本当に議論を楽しんでいますが、死んだ馬を倒すことには意味がありません、ハハ:)

ええ、私も楽しんでいます。 悪い気持ちはありません:)

素晴らしいサムス船ところで。 投稿する写真が多ければ多いほど、ノードが枝に分かれて狂った方向に進む可能性があるため、ノードを視覚的に追跡するのが難しいという私のケースを支持します。
私にとって、ブロック間の線と矢印をたどらなければならないという追加の複雑さは、常に余分な作業のように感じられました。 最近、ノードにもう一度試してみる必要があると思います。 それがgodotが向かうところなら。

繰り返しますが、あなたは私たちに、証拠によって実際には裏付けられていない第三者の話を与えています。 ここで男を取得し、彼がなぜ一方を他方に好むのかを教えてもらいます:)
そうすれば、より強力なケースになります。 これまでのところ、ノードがより単純であるという説を支持する論理的に正しい点は得られていません。

はい、それは多くの情報を隠しているので、一見するとそれほど威圧的に見えません。 あなたの例は、私が投稿したスクリーンショットに示されているものよりもはるかに単純です。 これは誤解を招く恐れがあります。
これは、C2でプラットフォーマーのロジックをセットアップするためのホットなビデオです。
https://www.youtube.com/watch?v=5RlSmkSbleI
最初の1分をスキップ：P

リンゴとオレンジを比較しないでください。
Code.orgは、Construct2とは根本的に異なるアプローチです。Stencylに似ており、ノードの欠点の1つがあります。つまり、条件とアクションが明確に分離されていないため、何に何をアタッチできるかを理解するのが難しくなります。 適切に設計されたビジュアルプログラミングツール（マルチメディアフュージョン、construct2、gamedevelop）はすべて、ユーザーにとって明確にアクションから条件を分離します。 これにより、必要なものを推測して適切なタイミングで表示するソフトウェアによってロジックが整理されるため、ロジックの構築がはるかに簡単になります。 それはまたあなたがばかげた間違いをするのを防ぎます。

ノード/stencyl/code.orgでは、どの部分が条件であり、どの部分がアクションであるかを把握する必要があります。 条件を正しい方法で設定するには、さらに理解する必要があります。 ノードからどのような種類の情報が出ていますか？ 条件を設定するには、より多くのノードが必要になることがあります。ノードを接続する方法をさらに学習します。
さあ、あなたの研究をして、実際に少しの間他のツールを使ってください。 すべての非ノードのものを同じものとして見ることは役に立ちません。

@blurymind 、あなたのケースはこれまでのところ、Construct2を使用しているユーザーの数に支えられています。これは通常、ソフトウェアのビジネスモデルと彼らのマーケティング能力の結果です。 個人的な好み（論理的な議論）は、C2ワークフローをGodotに強制するのに十分ではありません。 しかし、それは良い参考資料です。

紙や黒板でゲームをどのように構築したいか（オブジェクトとオブジェクトの関係）を誰かに示すとしたら、どのように見せますか？ イベントツリーを書くことによって？ いいえ。ノードとラインを使用して概念ビューを描画し、それらをクラス、関数、メンバーの追加と見なします。
イベントテーブルはプログラマーによってのみ解釈されるコードのように見え、ユーザーが進歩するにつれて実際のプログラミングを学びたくなる可能性があることに同意します。 いくつかの用語と学習曲線もあることに気づきましたが、それを否定することはできません。 しかし、形状認識とオブジェクトのグループ化は実際には本物です。 私はデータの視覚化についてのコースを勉強しています、そしてそれがどれほど退屈になるかもしれないことに加えて-それは実際に良い点を作ります。

この問題のスコアが100を超えることを望んでいますが、開発者はそれらすべてを読むわけではありません。私たち一人一人ができる最善のことは、提案を含むPDFを作成し、メーリングリストで共有することです。 イベントツリーの形式で表すことができる、さまざまなレベルの抽象化、つまりグラフノードを最上位レベルにすることができない理由がわかりません。 これが機能する場合は、妥協する必要はありません。

" @ blurymind- ||-そして、あなたは両方ともプログラマーであることを認めます。" -私は自分自身を単なるプログラマーだとは思っていません。あなたが知っているアートもやってください。 私は自分の経験を利用して、客観的な視点から物事を見ていきます。

見逃したかどうかはわかりませんが、私はプログラマーであるだけでなく、プロのアーティストでもあります。 ほとんどのプログラマーは、しばらくの間アートに飛び込むことで本当に恩恵を受けると思います。 それはプログラミングをより意味のあるものにし、プログラマー/アーティストのライバル関係を橋渡しするのにも役立ちます、ハハ:)これはより理想的であり、ほとんどの人にとってあまり実用的ではないことを私は知っています。

ここに私の作品のいくつかへのリンクがあります（クレジットでNathan Wardenを探してください）

ワールドビルダー（ショットの約半分に関与）
https://www.youtube.com/watch?v=VzFpg271sm8

Teddy Scares（ほとんどのショットに関与していました）
https://www.youtube.com/watch?v=qCXIzS_iY0k

ホールマーククラウンセンター（サンタとの3番目のショット）
https://www.youtube.com/watch?v=biqBq3_Whqk

これが私のLouieの建物のレンダリングです。 World Builderを見ると、私がそこからリッピングしてフィルムに入れたアートワークの一部が表示されます。

そして、これがターミネーター1スタイルのHKタンクがスティーブンキングのクリスティンを粉砕した未完成のレンダリングです。 これらのモデルは両方とも私が作成したものですが、ショットの他の何もそうではなかったと思います。

そして、私が名前を挙げられるものはもっとたくさんありますが、要点は述べられていると思います。 :)

まあ、それらは素晴らしい静止画です-しかし、あなたは自分自身により多くの権威を与えるためにこれを行っています。 これは、ノードがイベントシートよりも優れているという考えを論理的にサポートするのに役立ちません:)

ノードを使用する場合は、ビジュアルプログラミングを使用する他の3Dゲームエンジンと同じようになります。

これはいくつかの理由で素晴らしいアイデアではないと思います。

-最近、Unrealはエンジンを無料にしました-これもマルチプラットフォームです。 これは、BGE / Godotよりもはるかに成熟したエンジンです。 したがって、ビジュアルプログラミングへのアプローチをコピーするときに、直接競合します。

-ノードは、ロジックシートよりも画面効率がはるかに低くなります。 それらは読み/フォローするのが難しいです。

-Scirraは、construct3がマルチプラットフォームになることを発表しました-エディターはWindows、Linux、Macで動作します。
ただし、それらはオープンソースではありません。
https://www.construct3.com/

これにより、scirraコミュニティでコメントの波が生まれました。 多くのユーザーは、ビジュアルプログラミングなしでgodotが提供できる多くのことを望んでいます。
-html5コンテナの代わりにネイティブexeファイル-パフォーマンスを向上させる
-3Dゲーム開発のサポート、構成でイベントシートスタイルを使用してプログラムします。
https://www.scirra.com/forum/construct-3_t90881

彼らがC2内の2Dツールのようなシンプルで理解しやすい3Dエディターを作成する場合、私はそれを完全に使用します

私はユニティ、ブレンダー、トルク3D、UDKを試しました。なぜなら、それらはより宣伝されており、いわゆる有名な開発者のほとんどが使用しているものだからです...そして同じ問題を共有しています：それらは（まったく）ユーザーフレンドリーではありませんこれまで3Dゲーム作成APIを使用したことはありません...まあ、あなたは3Doomed（bad joke ikno）です

重要なのは、基本をカバーし、複雑な2Dゲームを自由に作成できるようになると、構築は非常に直感的になり、同じ結果を得るさまざまなパスが得られることです（イベントシステムMAKE SENSEは言うまでもありません）。 この他のツールのほとんどがカバーできないか、不十分になっている詳細です

彼らが私がC2を使用しているのと同じ流れと感覚で3Dエンジンを作るなら; それなら試してみませんか？

彼らは現在巨大なユーザーベースを持っており（ビジュアルプログラミング用のイベントシートスタイルは大好きですが、これらの機能が必要です）、その一部は別のエンジンにジャンプする準備ができています。 ここでは、Godotが多くの新しいインディー開発者を参加させる大きな可能性があります-ノードよりもこれを好む開発者-Unrealエンジンを使用していない開発者-現在は無料で、godotよりもはるかに成熟しています。

ノードの代わりにそれを選択すると、そのvisプログラミング設計で完全な3Dゲーム開発をサポートする最初のエンジンになります。 Unreal（無料）、Unity（無料バージョンが利用可能）と競合する代わりに、新しいユーザーベースを利用することになります

まあ、それらは素晴らしい静止画です-しかし、あなたは自分自身により多くの権威を与えるためにこれを行っています。

静止画とリンクは私の権威の証拠ではありませんが、私が一緒に働いた人々の証拠であり、私はそれを作り上げているだけではありません:)これにはあなたが聞いたことがあるかもしれないいくつかの映画に取り組んだ私の良い友達の何人かが含まれますアバター、キングコング、セレニティ、そしてロスト、レボリューションなどのショー...そして15年以上ゲーム業界で働いてきた他の友達の何人か。 これらはすべて、線形のシートベースのワークフローよりもノードベースのワークフローを好みます。 必要に応じて、ロジックシートよりもノードグラフを好むという3〜4人の引用を得ることができますか？

最近、Unrealはエンジンを無料にしました-これもマルチプラットフォームです。 これは、BGE / Godotよりもはるかに成熟したエンジンです。 したがって、ビジュアルプログラミングへのアプローチをコピーするときに、直接競合します。

ビジュアルスクリプティングワークフローは、Godotをこれらのエンジンと比較するときに人々が最後に見るものです。 彼らが最初に気付くのは、UnrealがDirectX12とOpenGL4をサポートしていること、そして彼らのデモと例が見事に見えることです。その後、彼らは他のものを見始めます。 Godotがこれらの企業に対して持っている主なことは、それがFLOSSソフトウェアであり、それを使用する人は誰でもソフトウェアの完全な所有者であるということです。

ノードは、ロジックシートよりも画面効率がはるかに低くなります。 それらは読み/フォローするのが難しいです。

優れたノードベースのセットアップを使用していないことは明らかですが、画面の効率などが心配な場合は、ビジュアルスクリプトを使用するべきではなく、すでに利用可能な実際のスクリプトを使用する必要があります。 :)ビジュアルスクリプティングが画面スペースの観点から提供できるものなら何でも、コード領域の折りたたみのように、通常のスクリプティングでもそれを実行できることを保証します。

ノードの代わりにそれを選択すると、そのvisプログラミング設計で完全な3Dゲーム開発をサポートする最初のエンジンになります。

Unrealのように、多くの時間、お金、顧客のニーズの調査に費やすエンジンが、その形式のビジュアルスクリプトを使用せず、代わりにノードを選択するのには理由があります。

これについての私の見解は、それはすべて、意図するアプローチに依存するということです
解決しました。

Game Makerのようなアクションブロックは面白いですが、もっと多いと思います
プログラミングの置き換えに向けて設計されています。

Unrealのアプローチは、プログラミングを補完するもののようなものです。
デザイナーは自分でゲームで作業し、ゲームから仕事を奪うことができます
プログラマー。 これはチーム（アーティストやゲームデザイナー）ではるかに便利です
それをうまく使うことができます）そして間違いなく私が追加したいアプローチです
これのためにGodot。

Godotアーキテクチャのため、追加も非常に簡単なので、
それは1.2でのショット

2015年3月3日火曜日の午後4時37分、 Nathannotifications @ github.comは次のように書いています。

まあそれらは素晴らしい静止画です-しかし再びあなたは与えるためにこれをやっています
あなた自身より多くの権威。

静止画とリンクは私の権威の証拠ではなく、私が持っている人々の証拠です
一緒に働いて、私はそれを作っているだけではありません:)これには私のいくつかが含まれています
あなたが聞いたことがあるかもしれないいくつかの映画に取り組んだ良い友達
アバター、キングコング、セレニティ、そしてロスト、レボリューションなどの番組...そして
15年以上ゲーム業界で働いてきた他の友達の何人か
年。 これらはすべて、線形のシートベースよりもノードベースのワークフローを好みます
ワークフロー。 私はおそらくそれらの3-4からあなたにそれを言っている引用を得ることができました
必要に応じて、ロジックシートよりもノードグラフを優先しますか？

最近、Unrealはエンジンを無料にしました-これもマルチプラットフォームです。 それは
BGE / Godotよりもはるかに成熟したエンジン。 だからあなたは彼らと競争しています
ビジュアルプログラミングへのアプローチをコピーするときに直接。

ビジュアルスクリプティングワークフローは、人々が最後になることです
Godotをそれらのエンジンと比較するときに見てください。 彼らが最初にすること
UnrealはDirectX12とOpenGL4をサポートし、それらのデモは
例は見事に見えます、そして彼らは他のものを見始めるでしょう。
Godotがこれらの企業に対して持っている主なことは、それがFLOSSであるということです。
ソフトウェアとそれを使用する人は誰でも等しく完全な所有者です
ソフトウェア。

ノードは、ロジックシートよりも画面効率がはるかに低くなります。 彼らはするのが難しい
読む/フォローする。

あなたの声明から明らかですが、あなたは良いノードを使用していません
ベースのセットアップ、画面の効率などが心配な場合は、
とにかくビジュアルスクリプティングを使用するべきではありません、あなたは本物を使用するべきです
すでに利用可能なスクリプティング:)私はあなたに何でも保証します
ビジュアルスクリプティングは、画面スペースの観点から通常のスクリプティングを提供できます
コード領域を折りたたむように、それを行うこともできます。

ノードの代わりにそれを選ぶなら、あなたは最初のエンジンになります
そのvisプログラミング設計で完全な3Dゲーム開発をサポートします。

Unrealのように多くの時間とお金を費やすエンジンには理由があります
顧客のニーズの調査は、そのような形では進んでいません。
ビジュアルスクリプティングと代わりにノードを選択しました。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-77017857 。

私はPlaymakerを試してみましたが、それが好きだったと言わなければなりません。これは、unrealのkismet / blueprintsよりも優れています。

プレイメーカーでは、ノードはアクションを配置するコンテナのようなものです。 アクションのいくつかは、別のノードにつながる可能性のある条件のチェックです。

ノードコンテナを自分で作成して名前を付けることができるので、ノードコンテナ内のアクションは予測可能な方法で（上から下に）実行されます。これは私が生きることができるものです。 :)

また、ノード内に配置するアクションは、実際には視覚的な入力を備えた標準のユニティスクリプトです。 したがって、人々は独自のスクリプトを作成し、それらをカスタムアクションとして追加できるようになります。

Playmakerを調べて、Unrealではなくそれに類似したノードベースのシステムを実装してください。
もちろん、より少ないノードでより多くのことを実行でき、読み取りとデバッグがより簡単で、より予測可能であるという利点があります。

これがどのように機能するかの紹介です：
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10

非常に柔軟性があり、ユーザーはゲーム機能を簡単に追加および共有できます。再利用も簡単です。

魅力的な議論。 ノードとC2のイベントシート以外の別のタイプ/形式のビジュアルスクリプトを指摘したいだけですが、パズルのピースのように組み合わされたスクリプトのブロックです。 2DエンジンStencylで使用http://www.stencyl.com/

MIT Scratchに基づくhttp://wiki.scratch.mit.edu/wiki/Wait_Until_（）_（block ）

Unityで私が個人的に使用しているのは、Blox http://www.plyoung.com/blox/

私は個人的に、スクラッチのような「ビジュアル」プログラミングには確信が持てません。 私
プログラミングとほとんど同じだと思います。
Unrealがこれを行う方法は、ゲーム/レベルデザイナーにとって友好的だと思います

2015年3月21日土曜日午後11時57分、 todheilnotifications @ github.comは次のように書いています。

魅力的な議論。 別の種類/形式のビジュアルを指摘したいだけです
ノード以外のスクリプティングですが、次のように組み合わされたスクリプトのブロック
パズルのピース。 2DエンジンStencylで使用http://www.stencyl.com/
[画像：stencyl_blocks]
https://cloud.githubusercontent.com/assets/8675463/6767767/d52e7b16-d013-11e4-878c-29002dc04f8e.PNG
MITスクラッチに基づく
http://wiki.scratch.mit.edu/wiki/Wait_Until_ （）_（ブロック）
[画像：scratch_example]
https://cloud.githubusercontent.com/assets/8675463/6767792/57f50e5c-d014-11e4-8015-9228bb6001d8.PNG
Unityで私が個人的に使用しているのは、Blox http://www.plyoung.com/blox/
[画像：hello_blox]
https://cloud.githubusercontent.com/assets/8675463/6767796/7849f46a-d014-11e4-9244-9e45c601f883.PNG

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-84508001 。

_OkamStudio_

いい視点ね。 私にとって、ブロックはコードラインとフローチャートの中間です。

私はビジュアルプログラミングのスクラッチ/ステンシルな方法が好きではありません。 そのレイアウトは
construct2ブロックやノードよりも視覚的に追跡が困難です。 です
文字通りパズルのピースをまとめると、それはの問題に苦しんでいます
どの部分がどこに合うかを理解する。 彼らは置くのは簡単ではありません
一緒

2015年3月22日午前5時46分、 todheilnotifications @ github.comは次のように書いています。

いい視点ね。 私にとって、ブロックはコード行とフローの中間です
チャート。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-84511415 。

わかりました、私は今すべてを読むわけではありませんが、このトピックに関する私の2セントだけです。

イベントベースのエンジンは、プロトタイプや小さなゲームプロジェクトを作成するために作成されます
godotのようなエンジンは、あらゆる種類のプロジェクトを作成するために作成されています

つまり、それらは2つの異なるアプローチを持つ2つの異なるものであり、2つです。
別の通行料

正直なところ、うまく使えません。 （イベントベースの通行料）

私にとってより良いアプローチは、2つの並行した通行料です。

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

私はビジュアルプログラミングのスクラッチ/ステンシルな方法が好きではありません。 そのレイアウトは
construct2ブロックやノードよりも視覚的に追跡が困難です。 です
文字通りパズルのピースをまとめると、それはの問題に苦しんでいます
どの部分がどこに合うかを理解する。 彼らは置くのは簡単ではありません
一緒

2015年3月22日午前5時46分、 todheilnotifications @ github.comは次のように書いています。

いい視点ね。 私にとって、ブロックはコード行とフローの中間です
チャート。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-84511415 。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-84575752 。

デビッド・アギアル・デ・アキノ・パイバ

役に立つのは、団結の「行動」システムだけです。
基本的にそれは何かを作るスクリプトなので、これはgodotで
ノードごとに複数のスクリプトを追加する可能性として翻訳します。
もちろん、ノードを作成してクローンを作成することもできますが、スクリプトは
リソースをノードにロードし、動作を追加するだけです（
例、ジャンプスクリプト）
エディターでは、スクリプト名で分類されたエクスポートを確認できました。

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

わかりました、私は今すべてを読むわけではありませんが、このトピックに関する私の2セントだけです。

イベントベースのエンジンは、プロトタイプや小さなゲームプロジェクトを作成するために作成されます
godotのようなエンジンは、あらゆる種類のプロジェクトを作成するために作成されています

つまり、それらは2つの異なるアプローチを持つ2つの異なるものであり、2つです。
別の通行料

正直なところ、うまく使えません。

私にとってより良いアプローチは、2つの並行した通行料です。

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

私はビジュアルプログラミングのスクラッチ/ステンシルな方法が好きではありません。 そのレイアウトは

construct2ブロックやノードよりも視覚的に追跡が困難です。 です
文字通りパズルのピースをまとめると、それはの問題に苦しんでいます
どの部分がどこに合うかを理解する。 彼らは置くのは簡単ではありません
一緒

2015年3月22日午前5時46分、 todheilnotifications @ github.com
書きました：

いい視点ね。 私にとって、ブロックはコード行とフローの中間です
チャート。

—
このメールに直接返信するか、GitHubで表示してください
< https://github.com/okamstudio/godot/issues/1220#issuecomment -84511415
。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-84575752 。

デビッド・アギアル・デ・アキノ・パイバ

デビッド・アギアル・デ・アキノ・パイバ

やあみんな！ 素敵な議論がここにあります:)何かを追加したいと思います。

まず、私は芸術の学生ですが、プログラミングが私の趣味です。 私はJava、Python、そして（私のお気に入りの）Golangを知っています。 しかし、コーディングの方法を学ぶ前に（約3年前）、「プログラミングなしでゲームを作成する」ことができると主張するほぼすべてのプログラムを試しました。 これらの主張はすべてナンセンスです。

私が試したのは（順不同）：Click＆Play、GameMaker、The Games Factory、Multimedia Fusion、Construct 1、RPG Maker、Stencyl、BGEなど、覚えていないものもあります。 そして私の意見は次のとおりです。コードを書くことなくゲームを作ることはできますが、プログラミングをすることなくゲームを作ることはできません。 イベントシートまたはノードを使用している場合でも、_プログラミングのロジック_を理解する必要があります。 条件、イベント、変数、文字列などを知っている必要があります。したがって、プログラミングなしでゲームを作成することは不可能です。 コーディングの視覚的な方法はすべて、従来のプログラミング言語にあるロジックを表現するためのまったく異なる方法です。 この議論全体は明白に思えるかもしれませんが、プログラミングの冒険の初めには、私には明白ではありませんでした。

これから、それは私の次の考察に従います：

コーディング方法を学ぶ前に私が見つけた最高で最も直感的なビジュアルプログラミング言語は、Scrach / Stencylパズル/ブロックの方法です。 理由は次のとおりです。

• このソリューションは、従来のプログラミングに最も近いものです。 実際、これは基礎となるコードのシンタックスシュガーのようなものです（基本的にはStencylの動作方法です）私にとっては、ノードのグラフや雑然としたイベントシートよりも、よりクリーンで簡単にフォローしたり、カラフルなファンシーコードのように見えるものを作成したりできます。関数のような素敵な構造に。 私にとって_this_はめちゃくちゃです
  これは私の意見であることを忘れないでください

* Scrach / Stencylブロックは最も視覚的で、わかりやすい方法だと思います。 彼らは色を広く使用しています（そして色のような視覚志向の人々）黄色=条件とループ、緑=数学、青=変数など。また、実際のコードのように見えますが（ノードとは対照的に）、より親しみやすいです。

最後に、ビジュアルプログラミングがすぐに優先されるべきではないと思います。 やるべきことはもっとたくさんあり（ロードマップ全体とドキュメント）、これらのシステムの実装は迅速かつ簡単ではないと思います。 Godotは、今のように本当に働きやすいIMHOです。 これには、アーティストがゲーム開発者と協力して使用できる多くのツール（ビジュアルシェーダーエディター、アニメーションエディター、タイルマップノード）が含まれています。

ところで。 この機会を利用して、Godotのすべての作成者と貢献者に感謝します。 あなたは素晴らしい仕事をしました：+1：

ところで2。 英語でごめんなさい。 私は最善を尽くしていますが、それでも愚かな間違いを犯しています：cry：

それがconstruct2であろうとbloxであろうと、どちらもそれらのノードグラフよりも私には優れています。

システムがノードをアクションのコンテナーとして（状態として）のみ使用する場合（Playmakerの場合と同じように）、問題はありません。

bloxとconstruct2の両方の良いところは、エディターが使用可能なすべての条件とアクションを表示することです。 それはあなたのためにそれらを分離し、それらをカテゴリーに入れます。 これはプレゼンテーションの劇的な変化であり、コーダー以外の人が、コマンドの名前を知らなくても、エンジンですぐに多くのことを実行できるようになります。

ビジュアルプログラミングにノードを使用する場合、最大の課題は、イベントが実行されている順序でユーザーに通信することです。 Unityでは-playmakerとbloxの両方がそれを非常にきれいに行います。

プレイメーカーで、ノードコンテナ内にアクションをスタックします（状態-アクションを含みます）。 bloxの場合-関数を含む状態があります。

それらはUnityの機能のほとんどへの完全なアクセスを提供します。 これは、プログラマー以外の人にとっては本当に素晴らしいことです。
bloxはさらに「plygame」に発展しました。これは、RPGハックアンドスラッシュスタイルのゲーム全体を作成するためにbloxがアクセスできるカスタムメイドのスクリプトをblox +に持つ別のUnityアドオンです。

団結したBloxはSkrach / Stencylブロックと同じです。 そのスタイルのプログラミングが好きな人はたくさんいるようです:)
https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k

godotの開発者が試してみてください。
ところで、Skratch（https://scratch.mit.edu/）テクノロジーはオープンソースです！ そして、他の人たちはそれを採用しています-ステンシルだけではありません。 グーグルもそれに非常に興味を持っています：
https://developers.google.com/blockly/

提案-両方の長所を生かしてみませんか？ ステートマシンのノード-式の場合はblox / skratch / stencyl。
理想的な世界では、Playmakerのように、ノードが状態コンテナとして使用されます。 しかし、状態コンテナには、レゴシステムのようなblox / stencyl / skratchがあり、ユーザーはロジックを簡単に設定できます。そのように式を記述する方法を学ぶ必要はありません。ドラッグアンドドロップする準備ができています。

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

iCanScriptの開発者の1人は、VSアセットについて次のように述べています。

iCS2の技術的進歩により、Unityのみの製品から切り離され、市場機会が大幅に増加します。 最終的なビジョンは、iCS2が、他のゲームエンジンや標準のWindows / OSX / iOS / Androidアプリケーション用のスクリプトを作成するために使用できる開発支援になることです。
http://forum.unity3d.com/threads/icanscript-visual-script-modeling-engine-for-unity.280847/#post -2124402

ノードがiCanScriptを台無しにするのは何ですか！

いずれにせよ、私が判断する前に試してみる価値はあります。 多分誰かが入ることができます
開発者と連絡を取りますか？
godotに利益の機会がある市場があった場合-
Unityはそうします-多分それはUnity開発者を引き付けて
godotも。

2015年5月23日土曜日の午後4時24分、 todheilnotifications @ github.comは次のように書いています。

iCanScriptの開発者の1人は、VSアセットについて次のように述べています。

iCS2の技術的進歩により、iCS2はUnityのみから切り離されています。
製品は大幅に>市場機会を増やします。 エンドビジョン
iCS2は、スクリプトの作成に使用できる開発援助になるということです。
他のゲームエンジンおよび標準の> Windows / OSX / iOS / Android
アプリケーション。

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

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-104895405 。

コンストラクト2のイベントシートは本当に理解しやすく、プログラムしやすいと思います。

私の生活のためにグラフィックを作成することにほとんどの時間を費やしているアーティストとして、新しい言語を学ぶことは非常に困難で時間がかかります。 数か月で学ぶことができると言われていますが、1日2時間しかない場合は、最初から学ぶか、簡単な言語で作成するかを選択できます。 また、視覚的な人物であることは、視覚的なスクリプトであることがより理にかなっています。

私は学校でプログラミングをしていて、コードを簡単に読んで理解することができますが、それを書くには時間がかかります。 私もPythonを学ぼうとしていますが、これはもっと簡単ですが、それを使って何かを作成するにはまだ数か月かかります。

コンストラクト2のアプローチは単純なようです。 私にとっては次のようになります。

1イベント：アクション;

2イベント：アクション;
： アクション;

その基本的にプログラミングですが、非常に簡単に理解できる方法で。 もし彼らがブロックの代わりに言語だけを使っていたら、私は気にしなかっただろう。 このパターンを使用すると、ロジックを簡単に作成できます。

ノードの使用は、物事が広がり始め、実際にコーディングするよりもノードを探すためにより多くの時間を費やすため、すぐに手に負えなくなる可能性があります（UnityとPlaymakerから理解したように）。

したがって、ビジュアルスクリプトを実装しようとしている場合は、イベントシステムの構築について非常に真剣に考えてください。

また、私たちのような人々のためにダウンロード可能な拡張機能としてビジュアルスクリプティングシステムを作成することもできるので、プログラミングを好む人はその余分なペイロードをダウンロードする必要がありません。

Godotで素晴らしいゲームを作成することを楽しみにしています。

コンストラクトのアプローチに関する私の問題は、プログラミングのように感じることです。
それほど違いはないようです
チームの観点から、私はUnrealの青写真アプローチがより好きです。
プログラミングについて知らないデザイナーにとってよりフレンドリーです

2015年5月24日午前3時58分、 whoisdanotifications @ github.comは次のように書いています。

コンストラクト2のイベントシートは本当にわかりやすく、
のプログラム。

私の生活のためにグラフィックを作成することにほとんどの時間を費やすアーティストとして、
新しい言語を学ぶことは非常に困難で時間がかかります。 人々はあなたができると言います
数ヶ月でそれを学びますが、あなたが1日2時間しかないとき
自分でゼロから学ぶか、を使用して作成するかを選択できます
単純な言語。 また、ビジュアルパーソンであるビジュアルスクリプティングはより多くのことを行います
検出。

私は学校でプログラミングをしていて、コードを簡単に読んで理解することができます
しかし、それを書くには時間がかかります。 私はまた、より簡単なPythonを学ぼうとしています
しかし、それを使って何かを作成するには、まだ数か月かかります。

コンストラクト2のアプローチは単純なようです。 私にとっては次のようになります。

1イベント：アクション;

2イベント：アクション;
： アクション;

その基本的にプログラミングですが、非常に簡単に理解できる方法で。 もし彼らが
ブロックの代わりに言語だけを使っていたら、私は気にしなかったでしょう。 これを使用する
パターンを作成するのは簡単です。

物事が広がり始め、ノードを使用すると、すぐに手に負えなくなる可能性があります。
あなたは実際にコーディングするよりもノードを探すためにより多くの時間を費やします（私として
団結とプレイメーカーから理解）。

したがって、ビジュアルスクリプトを実装しようとしている場合は、
イベントシステムを構築するための真剣な考え。

ダウンロード可能なものとしてビジュアルスクリプティングシステムを作成することもできます
私たちのような人々のための拡張機能なので、プログラミングを好む人はする必要はありません
その余分なペイロードをダウンロードします。

Godotで素晴らしいゲームを作成することを楽しみにしています。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-104985159 。

しかし、あなたはプログラマーの視点です-すでに方法を知っている人
コード化する。
この場合の統計を確認することをお勧めします-の数
Construct2が他のビジュアルプログラミングよりも優れているプログラマー以外のユーザー
編集者は自分で話す必要があります。

また、あるスタイルのビジュアルプログラミングで作成されたさまざまなゲームを別のスタイルで調べる価値もあります。

Unrealには、確かにkismetで行われた膨大な数のプロジェクトがありますが、construct2よりもはるかに古いエンジンであり、それらの多くは単なる一人称シューティングゲームです。

2015年5月24日午前10時15分、Juan [email protected]
書きました：

コンストラクトのアプローチに関する私の問題は、プログラミングのように感じることです。
それほど違いはないようです
チームの観点から、私はUnrealの青写真アプローチがより好きです。
プログラミングについて知らないデザイナーにとってよりフレンドリーです

2015年5月24日午前3時58分、 whoisdanotifications @ github.comは次のように書いています。

コンストラクト2のイベントシートは本当にわかりやすく、
のプログラム。

私の生活のためにグラフィックを作成することにほとんどの時間を費やすアーティストとして、
新しい言語を学ぶことは非常に困難で時間がかかります。 人々はあなたを言う
できる
数ヶ月でそれを学びますが、あなたが1日2時間しかないとき
自分でゼロから学ぶか、を使用して作成するかを選択できます
単純な言語。 また、ビジュアルパーソンであるビジュアルスクリプティングはより多くのことを行います
検出。

私は学校でプログラミングをしていて、コードを簡単に読んで理解することができます
しかし、それを書くには時間がかかります。 私もPythonを学ぼうとしています
より簡単に
しかし、それを使って何かを作成するには、まだ数か月かかります。

コンストラクト2のアプローチは単純なようです。 私にとっては次のようになります。

1イベント：アクション;

2イベント：アクション;
： アクション;

その基本的にプログラミングですが、非常に簡単に理解できる方法で。 もしも
彼ら
ブロックの代わりに言語だけを使っていたら、私は気にしなかったでしょう。 使用する
これ
パターンを作成するのは簡単です。

物事が広がり始め、ノードを使用すると、すぐに手に負えなくなる可能性があります。
あなたは実際にコーディングするよりもノードを探すためにより多くの時間を費やします（私として
団結とプレイメーカーから理解）。

したがって、ビジュアルスクリプトを実装しようとしている場合は、
イベントシステムを構築するための真剣な考え。

ダウンロード可能なものとしてビジュアルスクリプティングシステムを作成することもできます
私たちのような人々のための拡張機能なので、プログラミングを好む人は持っていません
に
その余分なペイロードをダウンロードします。

Godotで素晴らしいゲームを作成することを楽しみにしています。

—
このメールに直接返信するか、GitHubで表示してください
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-104985669 。

プログラミングに対するConstruct2のアプローチは、
Clickteamフュージョン。これにも多くのユーザーがいます。 それへの容易さはから来ます
プログラミングに似ていますが、いくつかのことがあります。

• 可能なすべての条件をリストし、ユーザーが選択できるようにする
  平易な英語でクリック/ドラッグして追加する-これは非常に貴重です
  彼らは魔法の言葉を学ぶ必要がないからです。 彼らはただドラッグして
  それらをドロップします。
• 可能なすべてのアクションをリストし、ユーザーが選択できるようにする
  わかりやすい英語でクリック/ドラッグして追加-これは非常に貴重です
  彼らは魔法の言葉を学ぶ必要がないからです。 彼らはただドラッグして
  それらをドロップします。
• 設定と設定の両方で任意の種類の式を実行する場合も同じです
  アクションまたは条件。 式を書くとき、エディターはあなたを助けます
  内の既存のオブジェクトから取得するものの簡単なドロップダウンリスト
  シーン。 それらのプロパティに到達する方法を学ぶ必要はありません
  すでに数回クリックするだけで利用できます。

おそらくそれの最良の側面は、それが非プログラマーに
新しいプログラミングを学ぶという学習曲線のないプログラミング理論
言語。

2015年5月24日午前10時17分、 TodorImreorovblurymind @ gmail.com
書きました：

しかし、あなたはプログラマーの視点です-すでに知っている人
コーディング方法。
この場合の統計を確認することをお勧めします-の数
Construct2が他のビジュアルプログラミングよりも優れているプログラマー以外のユーザー
編集者は自分で話す必要があります。

2015年5月24日午前10時15分、Juan Linietsky < [email protected]

書きました：

コンストラクトのアプローチに関する私の問題は、プログラミングのように感じることです。
それほど違いはないようです
チームの観点から、私はUnrealの青写真アプローチがより好きです。
プログラミングについて知らないデザイナーにとってよりフレンドリーです

2015年5月24日午前3時58分、 whoisdanotifications @ github.com
書きました：

コンストラクト2のイベントシートは本当にわかりやすく、
のプログラム。

私の生活のためにグラフィックを作成することにほとんどの時間を費やすアーティストとして、
新しい言語を学ぶことは非常に困難で時間がかかります。 人々はあなたを言う
できる
数ヶ月でそれを学びますが、あなたが1日2時間しかないとき
自分でゼロから学ぶか、を使用して作成するかを選択できます
単純な言語。 また、ビジュアルパーソンであるビジュアルスクリプティングはより多くのことを行います
検出。

私は学校でプログラミングをしていて、コードを読んで理解することができます
簡単に
しかし、それを書くには時間がかかります。 私もPythonを学ぼうとしています
より簡単に
しかし、それを使って何かを作成するには、まだ数か月かかります。

コンストラクト2のアプローチは単純なようです。 私にとっては次のようになります。

1イベント：アクション;

2イベント：アクション;
： アクション;

その基本的にプログラミングですが、非常に簡単に理解できる方法で。 もしも
彼ら
ブロックの代わりに言語だけを使っていたら、私は気にしなかったでしょう。 使用する
これ
パターンを作成するのは簡単です。

物事が広がり始めると、ノードの使用はすぐに手に負えなくなる可能性があります
と
あなたは実際にコーディングするよりもノードを探すためにより多くの時間を費やします（私として
団結とプレイメーカーから理解）。

したがって、ビジュアルスクリプトを実装しようとしている場合は、
イベントシステムを構築するための真剣な考え。

ダウンロード可能なものとしてビジュアルスクリプティングシステムを作成することもできます
私たちのような人々のための拡張機能なので、プログラミングを好む人は持っていません
に
その余分なペイロードをダウンロードします。

Godotで素晴らしいゲームを作成することを楽しみにしています。

—
このメールに直接返信するか、GitHubで表示してください
< https://github.com/okamstudio/godot/issues/1220#issuecomment -104985159
。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-104985669 。

また、複雑なロジックのコーディングを学び、最終的にはコーディングを学ぶのに十分な自信を持ちたいと考えている設計者の観点から見てください。 システムがデザイナーとプログラマーのチームによって使用されるのを見ると、あなたがどこから来ているのかわかります。 私は個人的に、多くのインディーゲーム開発者のようなプログラマーとのチームではなく、シングルユーザーとしてGodotを使用したいと思っています。 イベントシステムは寛容であり、1000以上のイベントがある場合、グループを使用してより整理されたように感じます。

これ以外はノードシステムに問題はありません。godotが現在よりも優れたシステムを作成できた場合は、それを使用します。

また、可能であれば、コードブロック/ノードを簡単に見つけるための検索機能を作成してください。

Construct2 / clickteamのイベントシートは学習する必要がないことに注意してください
構文-したがって、ユーザーは物をどこに置くかを知る必要はありません-つまり
非常に明白です。 左側の条件、右側のアクション。 の順
イベントの実行も非常に明白です。
スクラッチ/ステンシル/ユニティブロックのレゴピースはそれほど明白ではありませんが、それでも
「iCanScript」で提示されたノードの悪夢よりもはるかに優れています。 見ましたか
彼らのビデオチュートリアルで。 それは非常に複雑なビジュアルプログラミングデザインです
かなり急な学習曲線で。 あげても
プログラマー彼らはそれを理解するのに苦労するでしょう

2015年5月24日午前10時33分、 whoisdanotifications @ github.comは次のように書いています。

また、学びたいデザイナーの視点から見てください
複雑なロジックをコーディングし、最終的にはコーディングを学ぶのに十分な自信を得ることができます。
システムがによって使用されるのを見ると、あなたがどこから来ているのかわかります
デザイナーとプログラマーのチーム。 個人的にはGodotを
多くのインディーゲームのようなプログラマーとのチームではなく、シングルユーザー
開発者。 イベントシステムは寛容であり、
1000以上のイベントがある場合のグループ。

これ以外はノードシステムに問題はなく、godotが
現在よりも優れたシステムを作成します
それ。

また、可能であれば、コードブロック/ノードを見つけるための検索機能を作成してください
簡単に。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-104988595 。

彼らはもはやユニティアセットストアで「icanscript」を販売していません。
そこでの売上高を見てください-利用可能なビジュアルプログラミングの1つ
システムが最も使用されており、完全なプロジェクトがあります。

私はあなたにこのビデオを残しておきます：
https://www.youtube.com/watch?v=3Zq1yo0lxOU
クリックチームフュージョンで作られた167のゲームがあります-持っていない人によって
プログラミング経験。

また、フュージョンで成功したキックスターターゲームもご覧ください。
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

また、Five Nights at Freddy's（クリックチームフュージョンで作成）についても言及する必要があります。
http://en.wikipedia.org/wiki/Five_Nights_at_Freddy%27s_%28video_game%29
そのゲームはベストセラーです。 ここにあなたのためのいくつかの数字があります：
https://thinkgaming.com/app-sales-data/8779/five-nights-at-freddys/

ビジュアルプログラミングフレームワークのアイデアは、プログラマーを必要とせずにアーティストがゲームを作成できるようにすることです。その過程で、プログラミングについて少し学びます。

プログラマーがまだ必要な場所で作成する場合（ビジュアルプログラミングフレームワークは実際には作成していません）、プログラマーがデザイナーが使用できるようにセットアップできるステートマシンを作成しただけですが、ゲーム内の単純なものには使用できません。ゲームのコアロジック。 したがって、ここで説明した他のビジュアルプログラミングツールほど優れた完全なものを実際に作成することはありません。 あなたは、アーティストにロジックを設定する権限を与えたり、プログラミングの基本的な概念を学ぶようにアーティストを招待したりしていません。 あなたはそれらをプログラマーに依存させ、それらの概念の暗闇の中で維持しています。

2015年5月24日午前10時42分、 TodorImreorovblurymind @ gmail.com
書きました：

Construct2 / clickteamのイベントシートは学習する必要がないことに注意してください
構文-したがって、ユーザーは物をどこに置くかを知る必要はありません-つまり
非常に明白です。 左側の条件、右側のアクション。 の順
イベントの実行も非常に明白です。
スクラッチ/ステンシル/ユニティブロックのレゴピースはそれほど明白ではありませんが、
「iCanScript」で提示されたノードの悪夢よりもはるかに優れています。 やりました
あなたは彼らのビデオチュートリアルを見ます。 超複雑なビジュアルです
かなり急な学習曲線を持つプログラミング設計。 たとえ
あなたはそれをプログラマーに与えると彼らはそれを理解するのに苦労するでしょう

2015年5月24日午前10時33分、 whoisdanotifications @ github.com
書きました：

また、やりたいデザイナーの視点から見てください。
複雑なロジックのコーディングを学び、最終的には
コード。 システムがによって使用されるのを見ると、あなたがどこから来ているのかわかります
デザイナーとプログラマーのチーム。 個人的にGodotを使いたい
多くのインディーのようなプログラマーとのチームではなく、シングルユーザーとして
ゲーム開発者。 イベントシステムは寛容で、より組織化されていると感じています
1000以上のイベントがあるときにグループを使用します。

これ以外はノードシステムに問題はなく、godotが
現在よりも優れたシステムを作成します
それ。

また、可能であれば、コードブロック/ノードを見つけるための検索機能を作成してください
簡単に。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-104988595 。

それがあなたが取りたい方向ではない場合、私はあなたを別のゲームエンジンのためにうまく機能するシステムを使用するようにあなたを押し込むのは賢明ではないと思います。

同じように、ビジュアルスクリプティングを実装するためのより直感的な方法を見たいと思います。 面倒なノードや時間のかかるブロック（Androidアプリクリエーター）を使用していないか、プログラミングのように見えるイベントシステム（私は他のすべてよりも好んでいます）を使用していません。 それらすべてを最大限に活用する何か。

たぶん、ユーザビリティの設計者に相談して、いくつかのパスをクリアし、いくつかの数値を調べてください。

結局、Godot独自の方法を見て、Godotを優れたエンジンにして、1人の初心者が1週間で最初のゲームを設計し、開発チームが協力してAAAゲームを作成できるようにするのは素晴らしいことです。

エンジンを変えたり、言語を学んだりすることなく、素晴らしいゲームを作成するのに役立つシステムを頻繁に目にすることができてうれしいです。

乾杯。

それらがplaymakerのもののように行われる場合、私はノードを気にしません-として
アクションコンテナ（状態）。
そこにあるノードは、アクションまたは条件を設定するために実際に使用されていません。

ただし、「iCanScript」のように作成すると、完全に混乱します。

1. イベントが実行される順序を判断するのは難しい
2. どのノードをどのノードに接続できるかわかりません
3. 単一のアクションを設定するには、それよりも多くのノードと手順が必要です。
   ドラッグアンドドロップして式を設定します（construct2 / clickteam style
4. 構文を支援する場所-これは、導入するのに最適な方法です。
   たくさんの人を読まなくてもプログラミングできる人
   ドキュメント-すべてがドロップダウンメニューにあります
   物体）。

2015年5月24日午前11時20分、 whoisdanotifications @ github.comは次のように書いています。

うまくいくシステムを使うようにあなたを押し込むのは賢明ではないと思います
それがあなたがする方向ではない場合、別のゲームエンジンに最適です
取りたい。

同じように、私はビジュアルよりも直感的な方法を見たいと思います
スクリプトが実装されています。 乱雑なノードを使用しない、または時間がかかる
ブロック（Androidアプリクリエーター）またはプログラミングに見えるイベントシステム（私は
他のすべてよりも優先します）。 それらすべてを最大限に活用する何か。

たぶん、ユーザビリティの設計者に相談して、いくつかの道を切り開き、いくつかを見てください。
数字。

結局、Godot独自の方法を見るのは素晴らしいことです。
一人の初心者の両方が彼のデザインを可能にする素晴らしいエンジンをGodot
1週間で最初のゲームと、開発チームが協力して
AAAゲームを作成します。

素晴らしいゲームを作るのに役立つシステムを見てうれしいです
エンジンを変更したり、言語を学習したりすることなく、これまでにないほど頻繁に。

乾杯。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-104990083 。

Godotのために/で革新されている何かに関して@whoisdaに投票します。 ただし、1）ノード、2）イベントシート、3）ブロックの3つのビジュアルスクリプティングスクールがあるようです。 これらの3つのノードのうち、3D環境でこの分野をリードしているようです。 それについて言えば、スクリプト/プログラミングが線形（テキスト、ブロック、イベントシート）または水平（ノード）形式から抜け出し、構造を使用して3Dでプログラムすることを提案するアイデアをどこかで読んだことがあります。 それがどのように機能するかはわかりませんが、魅力的に聞こえます。

言及されたビジュアルスクリプティングスクールは実際にテストされており、
すでにユーザーがいます。 Playmakerとのデザインを組み合わせることをお勧めします
団結したブロックス。

ステートマシンを作成するためのノード。
各ノード（状態）内にアクションを作成するためのブロックまたはイベントシート。

2015年5月24日午後1時56分、 todheilnotifications @ github.comは次のように書いています。

何かに関して@whoisdahttps ：//github.com/whoisdaに投票します
Godotのために/ Godotで革新されています。 しかし、3つのビジュアルがあるようです
スクリプトスクール：1）ノード、2）イベントシート、3）ブロック。 これらの3つのうち
ノードは3D環境でこの分野をリードしているようです。 そういえば
スクリプト/プログラミングのブレイクアウトを示唆するアイデアをどこかで読んだことがあります。
線形（テキスト、ブロック、イベントシート）、または水平（ノード）形式と
構造を使用して3Dでプログラムします。 それがどのように機能するかはわかりませんが、聞こえます
魅力的な。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-105001411 。

ノードとイベントを一緒に使用できれば素晴らしいと思います。 ノードは、単純なロジックに従うと、他のノードにプラグインできるか、スクリプト/ブロック/イベントシートのコンテナーになることができる状態にすることができます。このように、ノードはそれほど大きくなく、チームとして共同作業することもできます。 しかし、これは開発者にとっては多すぎるかもしれません。 それでも、アイデアは非常にきちんとしているようです。

Playmakerではそのようなものです-人々はそれをとても気に入っているようです。
ここの多くの人々はまた、stencylも好きなようです-技術は
オープンソースで、最初からgithubWebサイトで入手できます。 私はそれを共有しました
前の投稿。

個人的には、ビジュアルプログラミングの最初のステップを見てみたいです。
方向。 開発者がgdで動作するステートマシンを作成したとしても
スクリプト-それは上級プログラマーでさえ驚くべき始まりになるでしょう
よろしくお願いします。

その後、おそらくその後、stencylや
Construct2-これはコードに似ていますが、コードよりもはるかに簡単です。
州。

つまり、実際にはこれらは2つの機能要求です。

• ステートマシン用に1つ（ノード）
• もう1つは、gdscriptの学習に代わるビジュアルスクリプティングフレームワークです。
  ドラッグアンドドロップコーディングで。 しかし、学習に向けた良い一歩でもあります
  gdscript。

結局、メインの開発者は、godotのデザインに最適なものを知っています。

2015年5月26日火曜日の午前11時43分、 whoisdanotifications @ github.comは次のように書いています。

ノードとイベントを一緒に使用できれば素晴らしいと思います。 ノードは
単純なロジックに従う場合、他のノードにプラグインできるか、または
スクリプト/ブロック/イベントシートのコンテナになることができます。
非常に大きなノードであり、チームとして共同作業することもできます。 しかし、これもかもしれません
開発者にとっては大いに役立ちます。 それでも、アイデアは非常にきちんとしているようです。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-105446984 。

慣れていないので、すぐにstyencylをチェックします。
この時点で、私が見た/読んだすべてのものから、私はそれを集めることができます：

1）青写真：ゲーム/レベルデザイナーには最適ですが、あまり適していません
ビジュアルプログラミング
2）Stencyl：ビジュアルプログラミングにははるかに優れていますが、
ゲーム/レベルデザイナー

私のゲーム制作の経験は常にチームで行われていたので、1）
非常に便利ですが、それでも私は偏見を持っています。 そんなにたくさんの人がいますか
Stencylのようなビジュアルプログラミングに興味がありますか？

2015年5月26日火曜日午前6時10分、Todor [email protected]
書きました：

Playmakerではそのようなものです-人々はそれをとても気に入っているようです。
ここの多くの人々はまた、stencylも好きなようです-技術は
オープンソースで、最初からgithubWebサイトで入手できます。 私はそれを共有しました
前の投稿。

個人的には、ビジュアルプログラミングの最初のステップを見てみたいです。
方向。 開発者がgdで動作するステートマシンを作成したとしても
スクリプト-それは上級プログラマーでさえ驚くべき始まりになるでしょう
よろしくお願いします。

その後、おそらくその後、stencylや
Construct2-これはコードに似ていますが、コードよりもはるかに簡単です。
州。

つまり、実際にはこれらは2つの機能要求です。

• ステートマシン用に1つ（ノード）
• もう1つは、gdscriptの学習に代わるビジュアルスクリプティングフレームワークです。
  ドラッグアンドドロップコーディングで。 しかし、学習に向けた良い一歩でもあります
  gdscript。

結局、メインの開発者は、godotのデザインに最適なものを知っています。

2015年5月26日火曜日午前11時43分、 whoisdanotifications @ github.com
書きました：

ノードとイベントを一緒に使用できれば素晴らしいと思います。 ノードは
単純なロジックに従う場合、他のノードにプラグインできることを示します
また
この方法では、スクリプト/ブロック/イベントシートのコンテナになることができます。
持ってる
非常に大きなノードであり、チームとして共同作業することもできます。 しかし、これは
それも
開発者にとっては大いに役立ちます。 それでも、アイデアは非常にきちんとしているようです。

—
このメールに直接返信するか、GitHubで表示してください
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105446984
。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-105458142 。

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

これは、stencilの「コード」がどのように見えるかの標準的な例ですか？ もしそうなら、それは恐ろしい考えのように思えます：それは幼稚園のビジュアルラッパーの標準的なコーディングのように見えます。 さあ、Pythonはすでに妻が読むのに十分簡単なので、基本を学ぶ努力をしてみませんか？

ビジュアルプログラミングについて話す場合、Godotがすでに持っているものははるかに優れています-シェーダーグラフまたはアニメーショングラフ：ビジュアルノードにラップされたコード。
https://frenchdog.files.wordpress.com/2009/09/specular_reflexion_vops.jpg-ビジュアルノードベースプログラミングの別の例（Sidefx Houdini、またはXSI）。 それは成熟していて、子供のおもちゃのようには見えません。また、Godotノードを思い出させます。

私はconstruct2アプローチが好きでしたが、スクラッチを詳しく調べた後、いくつかの理由から、より良い選択のように思われます。

• プログラミングデザインはconstruct2よりも人気があるようです
• プログラミング言語を人々に教えるのに役立つツールとしてすでに確立されています
• それはオープンソースであり、他の人は過去に彼らのエンジンのためにそれを再利用しました

Stencylの開発者は、オープンソースの「スクラッチ」テクノロジーを採用しました。 それは彼らのデザインではありません。
https://scratch.mit.edu/about/
http://en.wikipedia.org/wiki/Scratch_（programming_language ）
http://wiki.scratch.mit.edu/wiki/Scratch_1.4_Source_Code

プログラマー以外を対象とした他のゲームエンジンで使用されているScratchの例：

• Stencyl（最も人気のあるもの） http://www.stencyl.com/
  
• Craftstudio（http://craftstud.io/）
  
• google blockly（https://developers.google.com/blockly/）
• Godotに最も近いのは、Unityの「Blox」ビジュアルプログラミングアセットです。
  
  https://www.youtube.com/watch?v=Nd6Qy5ZipSs&list=PLuaBtUXEKcdIAA7_yjFNcLXM5YOf3WE9k
  Luaの代わりに、C＃を生成します。
  完全なドキュメントはここにあります：
  http://www.plyoung.com/blox/
  ここで販売されています： https ：//www.assetstore.unity3d.com/en/#！/ content / 12859

経験豊富なプログラマーにとっては恐ろしい考えのように思えるかもしれませんが、プログラマー以外の人にコードの書き方を教えたり、魔法の言葉や構文を知らなくてもプログラムを実行できるようにするのに最適な方法です。 スクラッチを使用すると、それらすべてをドラッグアンドドロップで使用できるようになります。視覚的な手がかりを使用して正しい構造を強制します。 私が投稿した「UnityBlox」ビデオプレイリストを見て、実際の動作を確認してください。 何よりも、それは実際に何度も何度も証明されています。 それは最も安全な賭けのように見えます。

@reduzの意見に同意します。一方はレベルデザインが得意で、もう一方はビジュアルスクリプティングが得意であり、どちらか一方を使用することについてはもはや主張していません。

両方を使用するのが最善の方法のようです。 Unity bloxでない場合は、Playmakerを見ても、ノードは実際にはコンテナーであり、アクションをスタックできるコンテナであることがわかります。これは、stencylと非常によく似ています。 リストからドラッグアンドドロップします。

「しかし、それはプログラマー以外の人にコードの書き方を教える方法や、魔法の言葉を知らなくても単にプログラムできるようにするための最良の方法です。」

それでは、このターゲットがどのオーディエンスなのかわかりません。 Godotは、市場に出回っているビッグボーイ（Unreal Engine、Unityなど）と競争することを目指していますか、それともScratchのように子供たちにプログラミング/ゲームの作成を教えることを目指していますか（https://scratch.mit.edu/）？

私はノードが何であるかを知っています（入力->パラメータ付きの関数->出力）、私はプレゼンテーションに同意しません。

StencylとPlaymakerは、子供たちにコーディング方法を教えるのに優れているかもしれませんが、プログラマー以外の人（スタジオとインディーの両方）がゲームを成功させるためにうまく使用しており、さまざまなプラットフォームで販売されています。
Unityをビッグボーイとして分類する場合、ビッグボーイもビジュアルプログラミングを行うことを知っておく必要があります。
http://www.hutonggames.com/showcase.html

godotには、ビッグボーイが使用できる機能がたくさんあると思います。 より小さな/インディーを可能にするいくつかの機能は、エンジンのより迅速な採用に役立つ可能性があります。 そして、オープンソースの性質と無駄のないライセンスは、初心者にとって非常に有利です。

@blurymind
私はビジュアルプログラミングに反対しません。 Godotにはすでに必要なもの（ShaderGraphs）があると思います。同じビジュアルアプローチをステートマシンロジックプログラミングまたは一般的なプログラミングに拡張できます。 私が反対しているのは、子供たちを怖がらせない、さらに別の視覚的パラダイム（〜scratch）を採用することです。

前に述べたように、それは子供だけのものではありません。 でも、子供でも理解して使えるとしたら、それはいいことだと思います。 恥ずかしいことではありません。

ここで私が言いたい最大のポイントは、次のとおりです。

• アクションの実行順序は明確でなければなりません！ ノードを使用してすべてのロジックを実行すると、非常にすぐに混乱する可能性があります。 したがって、ノードは状態imoに使用する必要があります。
• Playmaker開発者はその問題を非常に巧妙に予測していたため、ノードはアクションコンテナであり、Stencylと非常によく似ており、リストから使用可能なアクションをドラッグアンドドロップします。
  
  イベントをそのようにスタックします

最終的には、非常にクリーンで効率的なノードのセットアップになります。

Godotの開発者がプレイメーカーにも試してみることをお勧めします。
イベントスタックをStencylロジックに置き換えると、godotのアプローチがはるかに柔軟で強力になります。

それは、ステンシルアプローチを介してのみである必要はありません。 経験豊富なプログラマーがgdスクリプトをノードにアタッチできるようにできると思います。 stencylアプローチを使用してgdscriptを作成するオプションがあると、非常に貴重なimoになります。 多くの新規ユーザーをgodotコミュニティに招待します。

@blurymind
わかりました、しかしそれは何か違うものです。 使いやすいということは、子供向けのように見える必要があるという意味ではありません。
特定のノードに適した入力/出力の実行順序と支援されたフィルタリングは、ノードベースのワークフローの一般的な問題です。 ソフトウェアが異なれば、解決方法も異なります。

自問自答する必要があります-プログラマー以外の人にGodotをもっと使用してもらいたいですか？ gdscriptの経験がない人でも楽しいものを作れるようにしたいですか？

答えが「はい」の場合、それを行うための最良の方法は、ビジュアルスクリプティングアプローチを提供することです。
ノードを子供向けのもののように見せることは提案していません。
私が提案しているのは、これを2つのプロジェクトに分割することです。

• Playmakerのようにステートマシンとして使用されるノード！ プログラマーは、各ノードに名前を付け、それにgdscriptsを添付できます-セットアップした入力と出力を使用します。 ですから、これは子供向けではありません。 実際、これはプログラマーにとってはるかに柔軟なアプローチであり、面倒ではありません。
• GDscriptを生成する別の方法として、ドラッグアンドドロップイベントシートまたはブロックインターフェイス。 したがって、ノードにアタッチするGdScriptを作成する代わりに、プログラマー以外の人は、Playmakerのように、godotで使用可能なすべてのイベントのリストからアクションをスタックすることができます。 それをさらに一歩進めて革新するには、単にアクションを積み重ねる代わりに、ブロックのようなStencylを使用する方がよいでしょう。

このようにして、プログラマーと非プログラマーの両方に役立つものが得られます。 ステートマシン（ノード）を使用でき、プログラマー以外の人はgdscriptをすぐに学習する必要はなく、代わりにgdBlocksを使用してノードのgdscriptを生成します（これもPlaymakerのように）。

@blurymind
私はそれがもっと好きです。 また、すでにGodotにあるShaderノードグラフとShaderテキストとの整合性もあります。

SideFX Houdiniには、VEX（https://goo.gl/TMWNKk）（「ベクトル式」はベクトル代数を対象としたcのような言語）と呼ばれるものがあります。 これはgdScriptと同義です。 また、「VOP」（http://goo.gl/Qpn2OE）（Vex Operators）と呼ばれるものもあります。これは基本的にVEXのサブセットの視覚的なラッパーであり、上記で参照したLeadWerksノードグラフイメージと非常によく似ています。 実際、VOPは必要に応じてテキストスクリプトに変換できます（ただし、その逆はできません）。

2つの共存は非常に自然であり、プログラマーでなくても、非常に厄介で非効率的なコードを作成することができます;）

ブループリントのアプローチは非常にゲームデザイナーなので、個人的には好きです。
のようですが、私は偏見があるかもしれないと主張します。

2時間前にStencylをダウンロードして、遊んでみました。 私は
間違っていますが、Stencylは学ぶのに良いツールだと思います。
プログラミング部分は単純化されていますが、エンジン部分も単純化されています。 組み合わせは
シンプルなゲームエンジンのためのシンプルなプログラミングアプローチなので、良いです。

しかし、Godotは（少なくともStencylと比較して）単純なゲームエンジンではないので、私は
単純化されたプログラミングがそれほど役立つとは思わないでください。 Stencylはに依存しています
単純に利用できない多くのハーコード化されたゲームロジックのもの
Godot、そしてそれを利用可能にしようとすると、Godotの目標と矛盾します
非常に汎用的なゲームエンジンです。

ノードとグラフのアプローチは、私の意見ではもっと興味深いものです。
より低いレベルでより柔軟な方法。

2015年5月26日火曜日午前11時29分、ウラジーミルロパチン< [email protected]

書きました：

@blurymind https://github.com/blurymind
私はそれがもっと好きです。 また、シェーダーノードグラフと一致しています。
シェーダー-すでにGodotにあるテキスト。

SideFX Houdiniには冷たいVEXがあります（https://goo.gl/TMWNKk）（ "vector
式」は、ベクトル代数を意味するcのような言語です。
gdScriptと同義です。 また、「VOP」と呼ばれるものがあります（
http://goo.gl/Qpn2OE）（Vex Operators）-本質的に視覚的なラッパー
LeadWerksノードグラフに非常によく似たVEXのサブセット
上記を参照してください。 実際、必要に応じて、VOPをスクリプトに変換できます。
（ただし、その逆ではありません）。

2つの共存は非常に自然であり、それは可能です
非プログラマー、非常に厄介で非効率的なコードを作成する;）

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-105543845 。

PlaymakerのアクションスタッキングとUnityのbloxはどうですか？ Unityは非常に単純なエンジンではありません。

stencylはあまり良い例ではないと思います。 Unityアセットストアで例を探すことをお勧めします。

私はプレイメーカーを理解しようとしましたが失敗しました、それはどのように機能するはずですか？

2015年5月26日火曜日12:16 PM、Todor [email protected]
書きました：

PlaymakerのアクションスタッキングとUnityのbloxはどうですか？ Unityは
非常にシンプルなエンジン。

stencylはあまり良い例ではないと思います。 探す方がいい
Unityアセットストアの例。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-105561760 。

プレイメーカーのチュートリアルをチェックしましたが、それはのstencylに似ているようです
無数の事前定義された動作が付属しているという感覚

2015年5月26日火曜日12:19 PM、Juan [email protected]
書きました：

私はプレイメーカーを理解しようとしましたが失敗しました、それはどのように機能するはずですか？

2015年5月26日火曜日12:16 PM、Todor Imreorov < [email protected]

書きました：

PlaymakerのアクションスタッキングとUnityのbloxはどうですか？ Unityは
非常にシンプルなエンジン。

stencylはあまり良い例ではないと思います。 探す方がいい
Unityアセットストアの例。

—
このメールに直接返信するか、GitHubで表示してください
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
。

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-105563777 。

_OkamStudio_

UnityでU4ブループリントに最も近いのはuScriptです。
https://www.assetstore.unity3d.com/en/#!/content/1808

設定されたロジックを理解しやすいため、人々はuscriptよりもPlaymakerを好むようです。 スクリーンショットからわかるように、単純なロジックでも非常に面倒になります。

@reduz @okamstudioは、プレイメーカーのプレイリストです。
https://www.youtube.com/watch?v=I9VwsVtbgFU&index=2&list=PLC759306A1E692A10
実際に少し使ってみるべきだと思います。 事前定義された動作とスクリプトを実行できますが、playmakerを使用すると、エンジンのコア機能にアクセスして、そのような動作を最初から作成することもできます。

はい、プレイメーカーはステートマシンであり、ユニティには多くの事前定義された動作があります。
Godotにもそれらがあります-それらはエンジンに組み込まれています。
Unityのstencylclone bloxを使用することで、スクリプト/動作を最初から実際に作成できると今でも信じています。

私はついにあなたが適切なゲームとこのアイデアを作るためにプログラマーが必要だと思います
ゲームデザイナーが自分でゲームを作るのは素晴らしいですが、それはたくさんあると思います
多くの場合、役に立たない作業の。 でももっとあれば
編集者のための機能それは他の誰かがプラットフォーマーデザイナーのように自分自身
別の問題で言及されているか、UIを簡単にするための他の便利なこと
フレンドリー。
2015年5月26日19:52、「OkamStudio」 [email protected]は次のように書いています。

プレイメーカーのチュートリアルをチェックしましたが、それはのstencylに似ているようです
無数の事前定義された動作が付属しているという感覚

2015年5月26日火曜日12:19 PM、Juan Linietsky < [email protected]

書きました：

私はプレイメーカーを理解しようとしましたが失敗しました、それはどのように機能するはずですか？

2015年5月26日火曜日12:16 PM、Todor Imreorov <
[email protected]

書きました：

PlaymakerのアクションスタッキングとUnityのbloxはどうですか？ ユニティは
ではありません
非常にシンプルなエンジン。

stencylはあまり良い例ではないと思います。 探す方がいい
Unityアセットストアの例。

—
このメールに直接返信するか、GitHubで表示してください
<
https://github.com/okamstudio/godot/issues/1220#issuecomment -105561760
。

—
このメールに直接返信するか、GitHubで表示してください
< https://github.com/okamstudio/godot/issues/1220#issuecomment -105563777
。

_OkamStudio_

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-105565084 。

uScriptのUnityアセットストアでのレビューは次のとおりです。

優れたツールですが、プログラマー以外の人がフォーラムでのヘルプリクエストへの応答が非常に遅いか、まったく存在しないかどうかを知るのは困難です。

最終的にGodotに入るものが何であれ、可能であれば、GDScriptへの一方向の変換を許可することをお勧めします。 これにより、デザイナーやアーティストなどが視覚的にすばやく設定できるようになり、チームのコーダーは、先のとがったクリックを使用せずに、さらに調整してやり直すことができます。

@adolsonそれは非常に望ましい機能です:)

これは、ビジュアルシェーダーエディターを使用して実行できます。
（実際には、シェーダーコードを生成します）
しかし、生成されたシェーダーコードはあなたが思うほど読みにくいと思います
期待する：P

2015年5月26日火曜日午後6時33分、 Nathannotifications @ github.comは次のように書いています。

@adolsonhttps ：//github.com/adolsonそれは大いに望まれるでしょう
特徴 ：）

—
このメールに直接返信するか、GitHubで表示してください
https://github.com/okamstudio/godot/issues/1220#issuecomment-105670945 。

@reduzいくつかのメタデータが必要です。
上記のように、VOPからの変換-> VEX変換の例を次に示します。
：
そして、これがコードの完全なリストです。それ以外の場合、純粋なVEXでは次のようになります。
@P + = vector（{0,1,0}）; //位置を取得し、ベクトル（0,1,0）を追加します

ご覧のとおり、メタデータの量は重要ですが、2つを分離することは難しくありません。おそらく、半自動または全自動で解析します。

@reduzそれは本当です。 私はそれについて本当に考えていませんでした。 ほとんどのプログラマーが時間を費やしたいと思うようなコードではないでしょう。ラベルが変数名などになるのを見ることができましたが、問題を軽減するために他にあまり見ることはできません。

すべての人に話すことはできませんが、コードの混乱を見つけた場合は、それから少しずつ取ってしまうかもしれませんが、通常は単に書き直したいと思っています。 ですから、もしそうなら、これは私にとって個人的には価値がないでしょう。

あなたたちは本当にオプションの全範囲を通り抜けました。 私はConstruct2を使用しましたが、それはすっきりしていますが、コードに触れて改良することはできず、オプションはかなり制限されていました。 タイルマップの更新では、基本的にプレハブが削除されたため、インスタンス化も行われました。 私が本当に気に入ったのはPlayMakerforUnityでした。

それについての何かはあなたの範囲とあなたがする必要があることを把握するのは非常に簡単でした。 これは本当に魅力的な要素です。私がビジュアルスクリプターを使用するのが好きな理由は、まさにこれによるものです。 自分が何をしていたのか、テキストコードで何をする必要があるのか​​を見失いましたが、すべてがどのように「接続」されているかを確認することは、私にとって絶対的に最も有益です。 NateWardogは、はるか以前にスクリーンショットに例を投稿し、最近ではblurrymindを投稿しました。

私はreduzと言います、あなたはそれのために行きます。 今のところ、気になるなら、1.3以降で撮影しますが、それでもフロントエンド側に焦点を当てます。 その後、準備ができたら、Blueprintのように読み取り可能なコードを出力することに焦点を当てます。これは、非常に難しいと思います。 これを過小評価しないでください！

購読する。 これにもとても興味があります！ 私はいくつかのスクリプトを知っていて、それを使用してもかまいません...しかし、可能であれば、それよりもノードを接続する方が好きです！ Blender Game Engineのロジックブリックのようなものは、Godotスクリプトの視覚的なショートカットとして機能し、手で書く代わりに機能します...これは素敵な機能であり、私が積極的に待っている機能です。

ビジュアルスクリプティングは、多くのクリエイティブな人々や、gdスクリプトのような新しいスクリプト言語を学びたくない人々を本当に惹きつけます。 私はゲームメーカーを見ていたのでとても人気があり、最も与えられた理由はビジュアルスクリプティングメカニックです。

ビジュアルスクリプティングは退屈で、愚かで、使いにくいです。
私は良い実装を見たことがありません。 視覚的な人々はグラフィックを描くべきです。 私
多くの人が書くことができないことを知っています、
しかし、これは彼らに何の役にも立たないでしょう。 プログラミングをしていない人は
読み書きのできない人。

のメインシステムであったビジュアルロジック構築ツールを知りません
任意のエンジンのゲームロジック。
視覚的な方法は多くの面で吸い込まれます。 視覚的な人々は通常考慮します
「技術的なもの」としてのプログラミング
配管とハードワークの実際の何かを意味し、上になりたい
それ。 この態度
通常、いくつかの知的問題が原因です。 私はこの人々はないと思います
ターゲットオーディエンスになることができます
基本的に彼らは彼らの創造性を制限します。

2016年4月14日木曜日午前8時33分、 RémiVerscheldenotifications @ github.com
書きました：

編集：「RPGツクール」を「ゲームメーカー」に変更したようですが、今ではさらに多くの
sense：p私の投稿を削除します。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/godotengine/godot/issues/1220#issuecomment -209770726

したくありませんが、言わなければなりませんが、それはビジュアルスクリプティングツールの非常に狭い視野です、Sergey。 それらを使用して完全に作成されたゲームについては、Constructなどの一部のエンジンが完全にオプトアウトしているため、通常のスクリプトで作成されたそのエンジンからのゲームは表示されません。 他の（より健全な、imo）エンジンには、UnityやUE4などのプラグインがあります。 個人的には、UnityでuscriptとPlayMakerの両方を通常のコードと一緒に使用するのが本当に好きでした。コーディングが簡単なものもあれば、視覚的にスクリプトを作成するのが簡単なものもあります。特に、PMのようなビジュアルスクリプターを使用すると、ブレークポイントswは、よりスコープの外のビューからプロジェクトを見るのが非常に簡単です。

一般的なビジュアルスクリプティングの本当のことは、
プログラマー以外の人がプログラミングにアクセスできるようにする、これは完全に間違っています
アプローチ。
ビジュアルプログラミングは、通常のテキストプログラミングよりも難しいです。 それを作るために
従来の生活の中で、ケースごとに多くのブロックを書く必要があります
方法と
これらの人々にそれらを使用させてください。 これらは、
コードを書くのに良いプログラマー。 「プログラミングは職業ではありません。
誰もがそれを行うことができます」は間違っています。
プログラミングは無駄です。

ステートマシンに関しては-私はこれをいつか実装することについて考えていました
前に、しかしそれはハイビジュアルプログラムを助けません。
これは、ツールスクリプトとノードエディタを使用してゲームで簡単に実行できます。
これは強力なツールであり、多くの人がゲームツールに使用しています。
ゲームダイアログエディター。

2016年4月14日木曜日の午前9:09に、Aaron [email protected]は次のように書いています。

私はそれを言う必要はありませんが、それは視覚の非常に狭い視野です
スクリプトツール、Sergey。 それらで完全に作られたゲームに関しては、
コンストラクトなど、一部のエンジンは完全にオプトアウトしているため、
通常のスクリプトで作成されたそのエンジンからのゲームは表示されません。 他の
（もっと正気で、imo）エンジンにはUnityやUE4などのプラグインがあります。 私は個人的に
Unityで通常のuscriptとPlayMakerの両方を使用するのが本当に好きでした
コーディングが簡単なものもあれば、コーディングが簡単なものもあるため、
視覚的に、特にステートマシンを視覚的にスクリプト化する
PMのようなスクリプターは、breakpointswで多くのフィードバックを提供します。
よりスコープの外からプロジェクトを見るのはとても簡単です。

—
コメントしたのでこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

スラピン、その通りです。 しかし、ビジュアルプログラミングやプログラミングブロックの失敗率は非常に低いことを忘れてしまいます。 それは制限のためです。
非常に限られたスクリプト言語を使用する場合も、基本的に同じです。 あなたは多くの間違いをすることはできません。

これは、ビジュアルスクリプティングかテキストスクリプティングかという問題ではなく、達成するための目標であるべきだと思います。

プログラミングを改善したい場合は、ツールを改善してください。 Codehighlighting、Codecompletion、Codevalidation、Codetemplates、aso。 デバッガーを改善し、Liveprogrammingを作成します。
私はいつも安定したライブプログラミング環境を探していましたが、今まで見つかりませんでした！

本当にビジュアルスクリプティングを作成したい場合は、Stingrayエンジンのように作成してください。 VisualでCodeBlocksを作成し、後で変更できるTextCodeを生成したり、後でVisualBlocksとして使用できるTextCodeを記述したりできます。

無駄だとは言いませんが、2について話していると思います
完全に異なる製品。

スタジオを運営していて、たとえば20〜80人でゲームを作っている場合は
毎月6桁の生産コストを費やしており、
あなたのゲームを作るためのエンジン、あなたは特定の製品が欲しいです。 その場合、あなたは
ビジュアルスクリプティングツールはまったく気にしないでください。他のツールは気になります。
エンジンのツールを使用してチームの生産性を高めるなどのこと
（彼らが1か月のスケジュールを超えた場合、あなたは最大$ 100,000を使い果たします）。 それらの
チームにはプログラマーがいて、コードを書くのがはるかに生産的になります
ビジュアルツールを使用するよりも（その例についてはVicious Engineを検索してください）

一方、あなたがクールなアイデアを持っていて、本当に方法がわからない場合
コードを書く、あなたは別の製品、何かをするための速いプロトタイプをしたい
あなたは周りを見せて、最終的にプログラマーに実際のものを作るために与えることができます
ゲーム。

これは2つの異なる製品であり、どちらがより価値があるかについて議論すると
持っている、私たちはそれを認めなければなりません。 ビジュアルスクリプティングと言えます
ツールは、プロトタイプを作成する1人以上に実際にスケールアップすることはありません。 として
フルゲームを作りたいと思ったらすぐに、またはチームが2〜3に成長したらすぐに
人々、あなたはすでに本当のプログラミング言語を必要としています。 だから私は最初が好きです
全体的な目標としての例（3番目の製品が必要な場合を除く）
「数百万を稼ぐ完全なインディーゲームを作るために使用できるエンジン
コードを書かずに」。それは存在しません）。

しかし、私たちは両方を持つことができます、そして私はどちらかを落胆させません。 ビジュアル
スクリプトツールは、初心者ユーザーを作成することにより、長期的には私たちを助けます
それは最終的に業界で機能し、決定する立場になります
実際のゲームにはgodotを使用してください。それは良いことです。 また、スクウェア・エニックスのCTO
エンジンに視覚的なプロトタイピング言語があるかどうかを尋ねられたので、
そのタイプのもの、おそらくもののための大企業にもニッチがあります
その価値は研究開発であり、
プリプロダクション/プロトタイピング/新しいアイデアの実験など（彼はまた言った
私たちのゲームはコンソールゲームのように見え、どの国に（2回）尋ねました
それらを作る方法を学ぶために行きましたか：p）。

2016年4月14日03：26、 SergeyLapinnotifications @ github.comは次のように書いています。

一般的なビジュアルスクリプティングの本当のことは、
プログラマー以外の人がプログラミングにアクセスできるようにする、これは完全に間違っています
アプローチ。
ビジュアルプログラミングは、通常のテキストプログラミングよりも難しいです。 それを作るために
従来の生活の中で、ケースごとに多くのブロックを書く必要があります
方法と
これらの人々にそれらを使用させてください。 これらは、
コードを書くのに良いプログラマー。 「プログラミングは職業ではありません。
誰もがそれを行うことができます」は間違っています。
プログラミングは無駄です。

ステートマシンに関しては-私はこれをいつか実装することについて考えていました
前に、しかしそれはハイビジュアルプログラムを助けません。
これは、ツールスクリプトとノードエディタを使用してゲームで簡単に実行できます。
これは強力なツールであり、多くの人がゲームツールに使用しています。
ゲームダイアログエディター。

2016年4月14日木曜日の午前9:09に、Aaron [email protected]は次のように書いています。

私はそれを言う必要はありませんが、それは視覚の非常に狭い視野です
スクリプトツール、Sergey。 完全に作られたゲームは
彼ら、
コンストラクトなど、一部のエンジンは完全にオプトアウトしているため、
通常のスクリプトで作成されたそのエンジンからのゲームは表示されません。 他の
（もっと正気で、imo）エンジンにはUnityやUE4などのプラグインがあります。 私は個人的に
Unityで通常のuscriptとPlayMakerの両方を使用するのが本当に好きでした
コーディングが簡単なものもあれば、コーディングが簡単なものもあるため、
視覚的に、特にステートマシンを視覚的にスクリプト化する
PMのようなスクリプターは、breakpointswで多くのフィードバックを提供します
ただ
よりスコープの外からプロジェクトを見るのはとても簡単です。

—
コメントしたのでこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
< https://github.com/godotengine/godot/issues/1220#issuecomment -209776732

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/godotengine/godot/issues/1220#issuecomment -209779422

あなたは私を過ぎてプントスラピンについて話しているだけです。つまり、私はデザイナーや単純化については何も言いませんでしたが、プログラマーにとっても使いやすさであり、私はそれが有用であることを経験しました。 正反対の逸話的な経験をしたとき、それは時間の無駄だとあなたが言うことができるわけではありません。 私は、スクリプトと一緒に利用できるオプションを非常に好みます。あなたは、どちらか一方しか選択できないように振る舞い、それをアーティストに渡すことを余儀なくされています。 まったくそうではありません。

素晴らしいスレッド、たくさんの意見😁

私のは簡単です。 大丈夫！

これらのアイデアはどれもgdscriptへの素晴らしい追加になります😁

登場したらぜひお試しください。

gdscriptは、よりユーザーフレンドリーになりたいという愛情を持って行うこともできると思います。

一部のノードは完全に文書化されていません。 多くは説明がありません。
Godotは、開発を簡素化するためにいくつかのヘルパー関数を利用できます。 Gamemakergmlは良い例です：
https://twitter.com/uheartbeast/status/724326557108461568

ここではドキュメンテーションが主要なPITAだと思います。それだけです。
開発自体は十分に単純です。 ドキュメントとチュートリアル
本当に必要です。 だからあなたのYouTubeアカウントを若々しくする（またはブログ、または
フォーラムに投稿するだけです）、
それは多くの助けになります。

2016年4月25日月曜日午前9時35分、Todor [email protected]
書きました：

gdscriptは、よりユーザーフレンドリーになりたいという愛情を持って行うこともできると思います。

一部のノードは完全に文書化されていません。 多くは説明がありません。
Godotは、開発を簡素化するためにいくつかのヘルパー関数を利用できます。
Gamemakergmlは良い例です：
https://twitter.com/uheartbeast/status/724326557108461568

—
コメントしたのでこれを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/godotengine/godot/issues/1220#issuecomment -214163012

さて、私はこれについていくつかの考えを持っています。
ビジュアルスクリプティングのようなものを含めることで、エンジンにアプローチしやすくすることができます。これは、ゲームの作成に取り掛かりたいがプログラミングの経験がないすべてのアーティストにとっては良いことですが、それは他のすべての人々を招待します。 、まったくスキルのない人。 テキストエディタでのプログラミングに移行する人々は、たとえそれが最終的なゲームに苦しむことを意味するとしても、決して彼らの議題になることはありません。 ゲームを作る上で難しいのはプログラミングだけだと考える人は、ビジュアルスクリプトを使用すると、突然、この制限が解除されます。 これも珍しいことではありません。 プログラマー以外の人にとって特定のことを簡単にする人気のあるすべてのエンジン、つまり何トンものショベルウェアを見てください。 ショベルウェアを入手するリスクがあるため、ビジュアルスクリプトを含めるべきではないと言っているのではありませんが、このような人々がGodotengineを使用してショベルウェアを作成できると思わないように実装する必要があります。
私の他の問題は、Godotengineが得意なことの1つであり、この機能を好む多くの人々は、gitで非常にうまく機能することです。 ビジュアルスクリプティングの問題は、多くの場合、バイナリ形式で保存されることです。また、何らかのソースコードリビジョンを使用する場合、管理するのは悪夢です。 ビジュアルスクリプトを実装する必要がある場合は、テキストに適した方法で保存する必要があります。 そして、それが不可能な場合は、非常に困難です。 gitでうまく機能しないビジュアルスクリプトを作成するよりも、gitに適した形式のプロジェクトファイルをGodotengineに作成したいと思います。
そして、ビジュアルスクリプティングシステムを実装するために必要なすべての作業と、機能、効率、パフォーマンスを損なうことなく、ビジュアルスクリプティングなしでGodotengineで特定の種類のゲームを作成できるという事実から判断すると、次のように実装するだけで何が問題になりますか？プラグイン？ それがエンジンのコア部分でなければならない理由はよくわかりません。

ビジュアルスクリプティングとそのアイデアが気に入らない理由について2セントを追加するだけです。

コード管理と習熟度の点で、gdscriptファイル内のノードを接続する機能ははるかに優れていると思います。

たとえば、ビジュアルスクリプト（またはC2と同様のイベントシートを使用）では、1000を超える関数がある場合はどうなりますか？ それは私がすべてをナビゲートすると信じていることをはるかに悪化させるでしょう。 私は今、HTML 5アクションRPGゲームをGodotに移植しています（これは1万行以上のコードと500以上の関数です）。 _（アニメーションを除いて、Path of Exileが持つすべての機能を基本的に備えており、マルチプレイヤーです）_

ビジュアルスクリプティングでこれが可能になる方法はありません。 私たちとここのgodot開発者は、ビジュアルコードイベントシートよりも機能/バグスクイーズに焦点を当てるべきだと思います。 しかし、それは私だけです:)

編集：他の人が言っているように、おそらく小さなプロジェクトの場合は...しかし、大きなものは何でもそれが有用であるとは思えません

Construct2のイベントシートは関数をサポートしており、それらはgodotsとまったく同じように機能します。 シンプルなフィルター/検索ボックスで、リストしたすべての問題を解決できます。

しかし、godotの開発者は、人気のあるATMであっても、イベントシートアプローチを実行したくありません。 設計図の非現実的なアプローチに似たものを取得する可能性が高いという印象を受けます。 そうすれば、プログラマーは自分たちの兵器庫に追加されたステートマシンエディターの恩恵を受けることができます

vonstruct2でビジュアルスクリプトコードを整理するには、折りたたむことができるグループにコードを配置します。 これはgdscriptでさえできないことです-コードのブロックを折りたたむことはできません。 したがって、いくつかの点で、イベントシートにはgodotsgdscriptエディターよりも優れた利点があります。

@reduz私はPureDataを見ていましたが、その方法は非常に単純です。 よくこれをチェックしてください

ご覧のとおり、「Bang」と入力すると、汎用オブジェクトがBangオブジェクトに変わります。

ビジュアルスクリプティングが単にGDスクリプトの拡張になるとしたらどうでしょう。 汎用ノードを配置し、exにVector2と入力するだけで、Vector2オブジェクトになります。 したがって、基本的に各クラス/オブジェクトはノードでもあります。

関数を実行するには、オブジェクトではなくプロセスノードである別のノードを取得し、Vector2.dotのように入力すると、ノードが2つの入力と1つの出力を持つドットノードに変わると思います。

ビジュアルスクリプティングはある時点で計画されています

あなたは失望しませんでした：）<3

VisualScriptingはすでに存在するので、この問題を解決する必要がありますか？

はい。

「私も前向きに微笑んだ。
何千人もの優れたゲーム開発者によって作成された、大量のゲームカタログ、オープン、DRM Freeを備えた、Steamと同じくらい大きな会社があれば、ゲーマーとして私にとって素晴らしいことになるからです。」
drmフリーゲームを販売しているgogを見てください。

2015年の声明にオフトピックで答えて、来てください:)