Godot: イベントシートスタイルのビジュアルスクリプト

より多くのより良い機能で現在のビジュアルスクリプティングを強化することによって、これの多くを軽減することができませんでしたか？

多くの例は、UE4の青写真では簡単です。 「キーを押すWで、このアクターを前方に移動します」。
これらのほとんどを青写真で非常によく似た方法で構築でき、視覚的な違い（これが唯一のもの）でさえ最小限に抑えられます。

直感的でスムーズな方法で動作するIMOのビジュアルスクリプトを使用できるようにすることに重点を置く必要があります。 現状では、私たちがすでに持っているビジュアルスクリプトているように感じ、あまり愛されていないようです。 2つのビジュアルスクリプティングシステムを使用すると、この状況をどのように改善できますか？

プラグインの良いアイデア。 しかし、2つのビジュアルスクリプティングシステムを公式に維持することは苦痛であり、ほとんど利益がありません。

@mhilbrunner残念ながら、ブループリントはビジュアルスクリプティングとはまったく異なるアプローチです。 あなたにとってそれらは些細なことですが、クリックチームのフォーラムまたはコンストラクトのフォーラムでそれを言うことをあえてします。 彼らはこのアプローチをどれほど愛していて私を信じているので、彼らが使用しているエンジンに固執しています-彼らの多くはUnity、非現実的なエンジン、そしてgodotを含む他のエンジンで青写真を試しました。 ブループリントよりもイベントシートを好むため、construct2またはclickteamの融合に固執しています。 彼らはまだUnityのフォーラムでイベントシートアプローチを要求しています。
Godotのビジュアルスクリプトはフォーラムで言及されており、そこでのユーザーは依然としてイベントシートを好みます。 私は個人的にgdscriptに移行し、ブループリントの代わりにgdscriptを使用することを好みます。これは、gdscriptの利点がブループリントよりもイベントシートに近いためです。

それはバナナが好きな人に代わりにトマトを食べるように言うようなものです-それは好みの問題です:)

@groudしばらく同じことを考えていましたが、どこから始めればよいのかさえわかりません。プラグインとしても、誰かがプラグインを保守する必要があります。

@reduzはFacebookのアイデアに対して暖かく感じているように見えましたが、彼はもっと重要なことでいっぱいになっていることを理解しています

いずれにせよ、私はこれをドキュメンテーションのためにここに投稿しています-イベントシートシステムの概要を説明するために-それが何をするのか、そしてそれが青写真とどのように違うのか。 他の誰かがgodotまたはアドオンとしてそれを実装することに興味があるなら、私たちに知らせてください。 私は間違いなく袖をまくり、助け、ニュースを広め、クリックチーム/コンストラクトユーザーからフィードバックを得るでしょう。

これまでのところ、godotのGUIクラスとのインターフェースを適切に実装する方法すら知りません。 同じ列のセル間でロジックブロックをドラッグできる必要があります。 ブロック/行もコピー/貼り付け-行をネストして
他のユニークなもの。 小さな仕事ではないと思います

@blurymindええ、そしてこれを指摘し、詳細な記事を書くために時間を割いてくれてありがとう。 それでも、これはプラグインとしてはおそらく良いと思います。

開発者：最小限の複雑さでこれを追加するための最良の方法は何ですか？ たぶん、現在のビジュアルスクリプティングがどのように機能するかを調べる時間を見つけるでしょう。 ほとんどの場合、ビジュアルスクリプティングUIを置き換えるか、GDScriptを生成するか、これを動的に行う他の方法が可能かどうか疑問に思います。

ただし、これについてはまだ調べていないので、ポインタを歓迎します。 :) nilポインタはありません、お願いします！

@mhilbrunnerより直感的にするために、godotのブループリントシステムに必要なもののリストを使用して、トラッカーで別の問題を開くことができます。 できたらリンクしてください

ここでの私の投稿は、現在実装されているアプローチの変更ではなく、代替アプローチの提案です。 とにかくイベントシートはあまりにも異なっています

このようなイベントシートはNativescriptを介して実装できると思いますが、visualscriptingと同じコードベースに依存する必要がある理由はわかりません。

@groudそれは実際に良い点です。 現在のビジュアルスクリプティングコードベースのどれだけを再利用できますか？ nodegraphインターフェースにどの程度具体的ですか？

@blurymindええ、VSのそのようなリストに取り組んでいて、そうするでしょうが、しばらく時間がかかります。

NativeScriptを調査する必要があります:)

スクリプト言語（C ++、C＃、さらにはpython）には複数の選択肢があります。 ビジュアルスクリプティングの選択肢も複数あるのはなぜですか:)

これは、ビジュアルスクリプティングインターフェイスを構築するためのgodotのAPIの柔軟性にも依存すると思います。
ビジュアルスクリプティングコードベースを再利用する必要がありますか？それとも、完全に代替のコードベースをNativescript（c ++）で作成する必要がありますか？
これはgdscriptアドオンとして実装できますか？

ビジュアルスクリプティングの選択肢も複数あるのはなぜですか:)

組み込みとしてすでにサポートしている言語が多すぎるためです。 ほとんどのユースケースはすでにカバーされているので、維持するために新しい言語を追加する理由はあまりありません。 基本プログラミング用の言語（GDscript）、パフォーマンス用の言語（C＃およびC / C ++）用の言語、アーティスト/ゲームデザイナー用の言語（ビジュアルスクリプト）があります。 一部の人々が新しい言語の学習を処理できないという理由だけで、組み込みとして別の言語を追加する理由はありません。

正直なところ、これをコアに追加するべきではないと私は確信しています。 他の言語バインディングと同様に、プラグインを介して追加する方がよいでしょう。 現在の言語を維持するための十分な作業がすでにあります。

いいえ、ビジュアルスクリプティングのコードを再利用できるとは思いません。

@groudそれは良い点ですが、gamedevのアーティストに対するプログラマーの比率を考慮してください。 最高で最も美しいレトロな2Dゲームのいくつかは、自分の考え方に合った直感的な方法でゲームを作りたいと考えていたアーティストによって、fusion2で作成されました。 これがFusion製ゲームの少し時代遅れのショーリールです：
https://www.youtube.com/watch?v=3Zq1yo0lxOU

彼らは多くの成功したキックスタータープロジェクトとスチームでのゲームを持っています-多くのプラットフォームでのゲーム。 人々はこのアプローチをビジュアルプログラミングで使用するのが好きです-プロのチームでさえ。 ユーザーベースを拡大する可能性が見当たらない場合は、ここでは紹介しません。

たぶん、でも、イベントシートは理解できるが、VisualScriptingは理解できない人はどれくらいいるでしょうか。 あなたは「彼らはこのアプローチをどれほど愛していて私を信じているので、彼らが使用するエンジンに固執している-彼らの多くはUnity、非現実的なエンジン、そしてgodotを含む他のエンジンで青写真を試した」と言っていますが、あなたは実際にはそれを尋ねる最初の人。

これが一般的な需要である場合は、はい、コアに追加できます。 しかし、今まではそうではありませんでした。

私にとっては、すでにすべてのユースケースをカバーしています。 少なくとも最先端のプロのゲームエンジンにとっては。 また、子供や愛好家ではなく企業をターゲットにしているため、時間をかける価値はありません。 Fusion 2、Construct、またはRPGMakerでさえ、別のオーディエンスに焦点を合わせています。たとえ美しいゲームがそれらで作成されたとしても、それらのごく一部だけがプロのプロジェクトです。

@groudこれらの統計を

また、イベントシートのアプローチがブループリントよりも優れている理由を指摘しています。たとえば、クリック数を減らして作業を進めたり、プレゼンテーションを明確にしたり、gdscriptへの移行を学習したりすることができます。

私に言わせれば、RPGツクールエンジンは本当にレベルエディタです。 Fusionやconstruct2と同じレベルの柔軟性はありません

ブループリントで同じ例を説明するよりも、イベントシートがどのように機能するかを誰かに説明する方が簡単です-彼らははるかに少ない概念を学ぶ必要があります-ノード間の接続の種類、入力と出力の種類を教える必要はありません-フローの設定方法。
代わりに、イベントは上から下に流れ、左が条件、右がアクションです。 何も接続する必要はありません。

これは

これほど理解しにくいですか？

確かに、godotは達成するためにより多くのイベントブロックを使用しますが、それでもノードグラフよりも明確です。
gdscriptでさえ、それよりもはっきりと見えます。 現在のビジュアルスクリプトシステムは、一見すると複雑に見えます

私は両方のシステムを使用し、現在それらを比較している人として話します-どちらも同等に強力であり、一方は明らかに学び、理解するのが簡単です
ぜひお試しください。 あなたはここで無料であなたのウェブブラウザでconstruct3を試すことができます：
https://www.scirra.com/
息子や若い兄弟がいる場合は、試してみるように依頼してから、godotを試してください-彼らが何ができるか、指示なしでそれを行うのにどれくらいの時間がかかるかを確認してください-ここでより多くの学校がgodotを採用する潜在的な市場があります-プログラミングの概念を学習するためのビジュアルスクリプティングを改善し、エンジンを使用してより若い人口統計を取得します

現在のビジュアルスクリプトを使用しているのは何人ですか？

手がかりはありませんが、今のところあまり信じていません。 FacebookやYoutubeでVisualScriptingに関する質問やコンテンツをあまり見ないので、今のところほとんどの人がGDScriptを使用しているようです。 VisualScriptingがすべてのユースケースに答えないことを確認する前にイベントシートを追加することは、大胆な賭けです。 今のところ、VisualScriptingで十分かどうかを見てみましょう。人々が別のシステムを大量に要求した場合は、後で追加する可能性があります。

@groudは、学校の環境でgodotのビジュアルスクリプトをテストできれば素晴らしいと思います。子供たちは基本的なコーディングの概念を学びます。
Construct2の最大のセールスポイントの1つは、子供たちにコーディングを教えることであり、彼らは何年もの間、特殊教育ライセンスを販売してきました。

私の主張は、現時点でgodotのビジュアルスクリプトは非コーダーにはあまり魅力的ではなく、コーディング方法を学ぶのに実際には役立たないということです-そのアプローチは純粋にステートマシン中心であり、基本的なプログラミングの概念はノードグラフを追加するとさらに複雑になるためです上に中心的なルール。

経験豊富なプログラマーは、これを販売するのに最適な対象者ではありません。イベントシートは、私たちがすでに持っているものを単純化したものと見なし、設計図は、設計者がステートマシンとして使用できる新しいツールと見なすためです。

基本的なイベントシートアドオンをgdscriptで作成してみたいのですが、ネイティブスクリプトアドオンを作成するのに十分な経験がありません。 それが可能であり、どこから始めるべきかについていくつかの指針がある場合-私はそれらを聞きたいです
たぶん、十分な関心があれば、誰かがネイティブスクリプトでそれを作るかもしれません

そのアプローチは純粋にステートマシン中心であるため

何 ？ なぜそう思うのか分かりません。 VisualScriptingはステートマシンとは何の関係もありません。

現時点で使用するのが簡単なのは、BlueprintsとGdscriptのどちらですか？ ビジュアルスクリプティングの目標は何であり、ターゲットユーザーは誰ですか

VisualScriptingは、アーティスト/ゲーム開発者にとってGDscriptよりも単純である必要があります。 今のところ、実際にはそうではないことを認めなければなりません。おそらく、ノードの束が単純化され、より魅力的になる可能性があります。 しかし、正直なところ、イベントシートはVisualScriptよりも理解しやすいと誤解していますが、私にはそうではありません。

あなたが示す例で実際に違いを生む唯一のものは、物事をより理解しやすくするテキストとアイコンです。 縦の構成ではなく、物事をより明確でわかりやすくするのはテキストとアイコンです。 VisualScriptingは、そのようなアイコンを追加し、最も一般的なアクション用のより優れたGUIを作成し、機能を適切なカテゴリにグループ化すると、同じように理解できるようになります。

@groudは、実行の順序と接続のタイプでもあります。 ノードグラフでは、イベントシートよりも注意すべき概念がはるかに多くあります。 ノードにアイコンを追加した場合でも、イベントの順序は白い線で決まり、他の色の意味も説明する必要があります。 あなたはまだ読みにくいスパゲッティグラフになってしまいます-あなたの目は他の誰かのグラフで何が起こっているのかを理解するために至る所を移動する必要があります

あなたは適切なターゲットオーディエンスではありません-あなたは経験豊富なc ++プログラマーです。 プログラマーではない人たちとこれをテストしてください。そうすれば、私が何を意味するのかがわかり始めます。

さあ、理解するのはそれほど難しいことではありません。もう一度、私たちは子供を対象としていません。
また、コード編成に関しては、問題はイベントシートでも同じです。 ノードのグループ化とコードの整理を気にしないと、長いイベントシートや巨大なノードグラフが原因であるかどうかに関係なく、コードが読み取れなくなります。

@groudはblenderのようにvisualscriptノードをグループ化することもできますか？ 私はそれを見たのを覚えていません。 おそらく@mhilbrunnerはそれを彼のリストに追加する必要があります
https://github.com/godotengine/godot/issues/12418
もう1つの重要な点は、gdscriptを介して再利用可能な高レベルのアクション/条件ロジックブロックを作成できることは、イベントシートシステムまたはブループリントシステムにとって非常に有益であるということです。 ブループリントシステムにはすでにそれがありますが、それ用に作成されたプラグインはありません。

繰り返しますが、construct2は私たちよりはるかに進んでいます。 彼らのコミュニティは、カスタム条件とアクションを追加するインストールが簡単なプラグインを数多く作成しています-そして、アクションと条件を登録するためのAPIは非常にシンプルです
https://www.scirra.com/forum/completed-addons_f153
https://www.scirra.com/manual/19/actions-conditions-and-expressions

完全にblurymindに準拠
私にとっては、Construct and Fusionイベントシステムを理解する方がはるかに簡単です。このシステムは、ラインでいっぱいのシステムよりもはるかに高速にゲームを開発できます。

笑これはgdscriptよりも読みやすいです

@groudはblenderのようにvisualscriptノードをグループ化することもできますか？ 私はそれを見たのを覚えていません

わからない。 しかし、それが実装されていなければ、実装されるべきだと思います。

笑これはgdscriptよりも読みやすいです

これはここでのポイントではありません。

@groudええそうです。 単純なgdscriptコードよりもはるかにまとまりがなく、読みにくいのに、ゲーム開発者がイベントシートを使用したいのはなぜですか？ それがこの機能提案の核心ですよね

@groudええそうです。 単純なgdscriptコードよりもはるかにまとまりがないのに、ゲーム開発者がイベントシートを使用したいのはなぜですか？

いいえ、そうではありません。VisualScripting（またはイベントシート）とGDscriptは同じ人を対象としていません。 VisualScripting（またはイベントシート）はアーティストまたはゲーム/レベルデザイナー向けですが、gdscriptにはプログラミングの経験が必要です。

イベントシートとGDscriptを比較しても意味がありません。

イベントシートとGDscriptを比較しても意味がありません。

さて、それは私たちが異なるところです：P私はそれらを比較することは合理的であると思うので。 特に、gdscriptはすべてを実行するため、はるかに単純なレベルで実行されます。

また、「プログラミングの経験が必要」についても同意しません。 レベルデザイナーが_イベントシートまたはビジュアルスクリプトで_アクションのブロックを作成している場合、gdscriptを使用するための基本的な構成要素は_すでに_あります。

つまり、JITでコンパイルされたgdscriptはロードマップ上にあり、イベントシートやビジュアルスクリプトの追加よりもはるかに有益です（godot開発者の大多数はすでにそれから大きな恩恵を受けている可能性があるため）。 VS /イベントシートの潜在的なユースケースは現在かなり低いです。 あなたの最近の投稿はすでにほのめかしているので、私が求めているのは、リード開発時間について注意してください

@girngどの時点で、ロードマップ上の他の重要な機能の優先順位を盗もうとしていると判断しましたか？ この投稿では、現在の方法とは別の方法でビジュアルスクリプティングの利点を探っています。
それはロードマップにも載っていませんが、朝食を食べるためにここにいるかのようにジャンプします。 ：p
アイデアを探求することは、時間を要求することとまったく同じではありません。

コンストラクトやクリックチームフュージョンに触れたことはありません。それについて話し合いたい場合は、少なくともしばらくの間はイベントシートを使用して、プラットフォーマーを作成してください。
アカウントの登録やログインを必要としないconstruct3のオンラインデモにリンクしました。
https://www.scirra.com/
文字通り3クリックです

イベントシートを試して、それで何かを作ってください。 次に、godotが持っているビジュアルスクリプトの青写真を使用します

Gdscriptはシンプルです-はい、私も同意し、気に入っています。 jitでコンパイルされたgdscriptは素晴らしいでしょう！ そのより重要なことにも同意しました。
しかし、この議論はそれらのことについてはまったくありません

さて、それは私たちが異なるところです：P私はそれらを比較することは合理的であると思うので。 特に、gdscriptはすべてを実行するため、はるかに単純なレベルで実行されます。

あなたが理解していないのは、多くの人にとって、コーディングとコーディングしないことの間に心の障壁があるということです。 今のところVSに入るのは少し難しいことを認めなければなりませんが、多くの学習資料が作成され、いくつかのVSの改善が行われる可能性があるため、将来的にはGDScriptよりも簡単になるはずです。

また、「プログラミングの経験が必要」についても同意しません。 レベルデザイナーがイベントシートまたはビジュアルスクリプトでアクションのブロックをすでに作成している場合、gdscriptを使用するための基本的な構成要素がすでにあります。

ええ、私もプログラマーとしてはかなり同意しますが、これは経験が示すものではありません。
Unrealは完璧な例です。多くの人が、特に専門分野でUnrealの青写真を使用しています。これは、プログラマー以外の人がより歓迎的な方法でコードを記述できるためです。 （私の意見では）実際のコードとそれほど変わらないとしても、それは人々の心に違いをもたらします。 専門家がそれを使用する場合、それはそれが本当の必要性であり、同じものであると私たちが考えるので私たちが落とすべきガジェットではないことを意味します。 そのため、それらを比較しても意味がありません。両方が利用可能であり、正しく機能している必要があります。

とにかく、ここでこの議論をやめます。 VSに関するバイクシェディングまたはVSでないバイクシェディングはすでに処理されています。

@blurymind私はあなたのエネルギーを賞賛し、あなたは良い点を作ります。 以前にコンストラクトでイベントシートを試したことがあり、最初はクールでしたが、ゲームが高度になるにつれて、すぐにコードに戻りたいと思いました。 そうです、私は過去にそれらを試しました。

マーベルヒーローズはAAA ARPGだったと、彼らは/ Unrealのワット青写真を使用して@groudは、それらについての良い議論を行います。

私は彼らが彼らのユースケースを持っていることに同意しません、私は次の基準に基づいて正当化するのは難しいと思います：

• 限られた開発マンパワー
• すでに現在の問題の量
• 混乱/読みにくい（ここを参照）
• ほとんどのgodot開発者はむしろgdscriptを使用したいと思います
• gdscriptはすでにgodotと非常にうまく結びついています
• コアに
• すでにgdscriptを使用しているgodot開発者の現在の90％には公平ではありません（アクティブなユースケースを満たすjitコンパイル済みgdscriptに開発時間が使用できる場合）

プラグインとして私は完全にサポートすることができましたが、それが公式にサポートされている場合は良い考えではないかもしれないと私の心は言っています

@girngありがとうございます。 繰り返しになりますが、これはgdscriptまたはビジュアルスクリプトを置き換える要求ではありません。
これは、一般的なビジュアルスクリプトに関する観察であり、現時点でのgodotのビジュアルスクリプトは、非コーダーにとって実際にはユーザーフレンドリーではありません。

Gdscriptは、イベントシートや青写真など、あらゆるビジュアルスクリプティングシステムと美しく連携できます。
私の最初の投稿で述べたように（イベントシートアプローチも式を使用します）、gdscriptはすでに使用できます。 より高いレベルのロジックブロックは、gdscriptおよびgodotのプラグインシステムを介して作成することもできます。これは、ビジュアルスクリプトシステムと美しく連携します。

実際、イベントシートシステムは、現在のブループリントシステムよりもgdscriptとの結合がはるかに優れている可能性があります。このシステムでは、単純なテキストフィールド入力ではなく、10億ノードのグラフを使用して表現が行われます。 必要に応じて、1 +1を実行します-ノードを使用します。 式内の単純な変数をアドレス指定する場合は、別のノードを使用します。 単純な表現のための10億の基本ノードのスパゲッティの混乱に終わります。これは、はるかに少ない労力と冗長性で、小さなテキストフィールドに同じように簡単かつはるかに明確に記述できます。

現在のビジュアルスクリプトでは、クリック数、ノード数、冗長性が多すぎて、最も単純なことを実行できません。 これが、gdscriptがより単純なimoであるもう1つの理由です。つまり、10ノードと100接続ではなく1行のコードです。

これは基本的にイベントシートシステムのもう1つの利点です。つまり、コードブロックの入力フィールド内に式を記述するだけです。 Construct2とFusionの両方に、オートコンプリートエディタと式エディタがあり、シートがスコープ内でアクセスできるすべてのノードのリストを使用して、ノードが持つすべてのメソッドに簡単にアクセスできます。

Godotは、同じことを行うときに式にgdscriptを非常に簡単に使用できますが、これらの式は単純なスプレッドシート構造に配置されています。

godot-のメソッドをロジックブロックとして想像してみてください。 そのメソッド（そのブロックは同じパラメーターを取ります）と同じように、ノードにフックする必要はありません。 入力フィールドにgdscriptを入力するだけです。
godotのノードは、construct2の動作として機能でき、godotのイベントシートは、construct2よりもはるかに柔軟で強力です。 彼らのエンジンが持っている不利な点はありません

オブジェクトをペアリングするためのConstructのアプローチは、とりわけ恐ろしいものですが、それはイベントシートのデザインとは何の関係もありません。

現在のビジュアルスクリプトでは、クリック数、ノード数、冗長性が多すぎて、最も単純なことを実行できません。

これはVSに固有の欠陥ではありませんが、現在制限されている実装の欠陥です。 これは修正する必要があり、その隣に別のビジュアルスクリプティングメソッドを実装するための引数として使用しないでください。 それ以外の場合は、現在のVSを廃棄する必要があります。

また、GDscriptのJITについて議論することは話題から外れています。 機能のメリットは、次の方法でのみ測定できます。

• 同じユースケースで役立つ可能性のある他の同様の機能と比較した場合の有用性
• それは、それがテーブルにもたらす複雑さ、追加された技術的負債、およびGodotの保守負担に対する有用性です。

したがって、これを行う必要があるかどうかは、GDScript用のJITを実装するかどうかとは関係ありません。 それ以外の場合は、すべての主要なバグが修正されるまで、つまり永久に、すべての機能リクエストの99％を閉じる必要があります。 これらは、GDScriptのJITよりもさらに重要です。

@mhilbrunner JIT for GDScriptは実際に発生しますが、すでに公式ロードマップに含まれています：P。 私はこれが開発時間をそれから奪うことができると言っていました。 また、godot開発者の90％がすでにgdscriptを使用しているため、正当化するのは困難です（そして、多くの人がイベントシートよりも優れていると考えており、独自の感情を持っています）。 きちんと自分を伝えられなかったらごめんなさい。 はい、私はこれがそれを置き換えていないことを知っていますが、私は開発時間についてもっと言っています。

そうは言っても、 @ blurymindは本当に良い点なので、あなたが言ったことに異議を唱えることはできません。 Godotにイベントシートを置くことは_持っている素晴らしい機能になる_でしょうか？ 確かに、しかしそれはすぐに現実に起こることでしょうか？ よくわかりません。 （2014年以来、熱心なユーザーであり、これは私の意見です）

以前に自分でアクションゲームメーカーとゲームメーカーのイベントシートを使用したことがありますが、VisualScriptよりも使いやすく理解しやすく（行をたどらずに上から下に読む）、画面スペースをあまりとらず、有限を実装できることに同意しますステートマシンをより簡単に（イベントの終了後にトリガーできるイベントをフィルタリングすることにより）。

それは非常に素晴らしい追加になるでしょう。 GDScriptで十分なので、おそらく自分で使用することはありませんが、GDScriptがオプションでない場合（初心者やプログラマー以外の人が経験している可能性があります）、問題なく使用できると想像できます。

ええと、私は約1年間Godotユーザーです。 私はGDScriptが大好きで、構文は単純です。
しかし、私は8年以上Constructを使用しており、イベントシートよりも簡単なビジュアルスクリプトを見たことがないと言えます。Blueprintは好きではなく、blenderやUnityなどの他のVS BluePrintsスタイルを使用しました。ブループリントはイベントシートよりも簡単だと人々が言う方法を理解できません。おそらく、アーティストはノードを使用してシェーダーやグラフィックスをセットアップするのに慣れているため、この美学に慣れています。 しかし、イベントシートシステムをUnrealのようなエンジンに入れると、人々はブループリントを落とすでしょう。

私は子供と10代の若者にプログラミングロジックを教える学校で働いています。 子供には、イベントシートを使用して何かを作成するのが非常に簡単なので、Construct2を使用します。 10代の若者には、GDScriptを使用しており、良好な結果が得られました。 Godot 3.0がリリースされたとき、Godot VSを使用するためにConstruct 2を削除するというアイデアを検討しましたが、現在VSはGDScriptよりも難しく、理解と使用が非常に複雑であるため、アイデアを放棄しました。 Godotにイベントシートのようなものがあれば、学校ではオープンソースソリューションを好む傾向があるため、コースは完全にGodotに基づいて作成します。

イベントシートがもたらすその他のメリットは、Godotのユーザーベースを増やすことです。これは、GDCでは、中規模から大規模のスタジオがGodotを好むのに対し、小規模なスタジオはUnityやその他のソリューションを好むためです。 Construct、Fusion、GameMakerのユーザーがGodotに移行し始めると思います。

先生として、私はイベントシートに大きな価値を見出しています。それは非常に理解しやすく、生徒がGDscriptに移行したときに、すでに論理的思考を発達させており、イベントシートの構造はブループリントよりもコードに似ているからです。

とにかく、私はGodotが行っていることと、GDscriptが大好きです。イベントシートとGDscriptの両方を使用して教えるので、自分の経験を捨てたかっただけです。 素晴らしい仕事を続けてください！

Godot 3.0がリリースされたとき、Godot VSを使用するためにConstruct 2を削除するというアイデアを検討しましたが、現在VSはGDScriptよりも難しく、理解と使用が非常に複雑であるため、アイデアを放棄しました。

それは非常に興味深いフィードバックです。 :)
実際のところ、Construct2形式のイベントシートは、VSやGDscriptよりもはるかに低レベルです。 確かに、彼らは子供たちがゲームプログラミングに入るのを助けることができますが、それはゴドットの目標ではありません。 そのようなシステムは組み込みとして出荷されるべきではなく、プラグインを介して利用可能であるべきだと思います。 reduzからのこのコメントもこれを表現していると思います。

@DrZanuffは、この非常に重要な点を指摘してくれてありがとう-同じ線に沿ったものはkidscancodeyoutubeチャンネルと@NinkuXによっても注目されてい

おそらく、Godotは、ゲームメーカーと同じようにこれに取り組むことができます。ドラッグアンドドロップのビジュアルコードは、リアルタイムでプレビューすることもできるgmlコードに直接変換されます。 そうすれば、非コーダーはエンジンのビジュアルスクリプティングシステムを使用しながらgmlを学習できます。これは、yoyoゲームが非コーダーをgmlに徐々に導入するために採用している正確な戦略です。
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changing_dnd.html

式にgmlを使用する場合と、ビジュアルプログラミングが実行していることをプレビューする場合の両方

アドオンとしても-godotのイベントシートオブジェクトは最終的にgdscriptに変換されるべきだと私は考え続けています。 イベントシートは、非コーダーにgdscriptの使用方法を教えるためのツールになります。これは、式にgdscriptを使用できる簡単なインターフェイスを提供し、最終的にはgdscriptを生成してプレビューするためのものです。

GodotのAPIには、gdscriptファイルを生成してノードにアタッチするメソッドがあります。 したがって、イベントシートは、ゲームの実行時にgdscriptに変換することも、ゲームメーカーのようにイベントシートを編集しているときにも変換できます。

クリックチームフュージョンとconstruct2の両方で採用されている追加の学習支援は、組み込みノードメソッド/メンバーのクリックベースのメニューリストです。

学生がリスト内の項目のいずれかをクリックすると、適切な構文が入力フィールドに追加されます。 学習を開始するとクリックしますが、クリックすると構文とメソッドを学習して記憶します。 後でクリックする代わりに、オートコンプリートで入力していて、APIを学習したことに気付かずに

その意味で、Godotのイベントシートシステムの実装は、非コーダーにgdscriptと基本的なプログラミングの概念を構文で混乱させることなく導入することを主な目標とすることができます。これにより、Godotは10代前半にプログラミングを教えるより多くの学校に配置されます。 進むにつれて、construct2やゲームメーカーではなく、gdscriptとgodotのAPIを学習します。

私はよく説明しなかったと思います... :(

私が線と言うとき、私は視覚的なスクリプト、ノードを接続する線を指します

コンストラクトおよびフュージョンイベントシステムは、Godotビジュアルスクリプトよりもはるかに直感的で、簡単で、すばやくゲームを作成できます。

このタイプの代替案を検討するのは良いことです

godotのビジュアルスクリプトブループリントの
現在のブループリントシステムの高レベルの関数を作成および維持するのにかかる作業は、プラグインとして高レベルの関数のイベントシート機能とまったく新しいイベントシートベースシステムを最初から作成するよりもはるかに少なくて済みます。

イベントシートシステムの低レベルの実装があれば、それに対する高レベルのアクション/条件を作成および維持する方がはるかに簡単です。
アドオンとしても、まず、低レベルのアクセスとインターフェイスを備えたベースのイベントシートアドオンを作成します。これは、新しいメソッドで肥大化することなく、godotのアーキテクチャに従います。 次に、他のプラグインで、より高いレベルのもののためにオプションのアドオンを分離して書き込むことができます。

アセットリポジトリには、ビジュアルスクリプトアドオン用の特別なセクションを含めることができます

私は7歳から17歳までの子供たちのためにプログラミングを教えています。 現在、若い生徒はCosntructを使用しており、年長の生徒はGodotを使用していますが、私の生徒全員がGodotを使用できれば、このゲーム開発者の世界での旅の始まりから子供たちがGodotを使用していることに心から感謝します。

イベントシートシステムだけではありません。 また、プラグイン/動作/ファミリ、UID、およびオブジェクトのプロパティがどのように機能するかについても説明します。

たとえば、C2の1つのオブジェクトスプライトでは、装飾、プレーヤー、敵などの静的/アニメーションを含むすべてのゲームアートを、衝突などですべて持つことができ、レイアウトに配置して、開始時にどのフレームを選択するかを選択できます。そして、「type =」と呼ばれるオブジェクトのインスタンス変数を使用して、イベントで敵、プレーヤー、オブジェクト、破壊可能などであるかどうかを判断し、彼の行動を設定します。 また、スプライトごとに、基本的なペイントプログラム、アニメーターのプロパティなどがあります。

Godotで、ビジュアルスクリプティングでPongの例を試しました。これを見ると、プレーヤーに1つのスプライトを使用し、衝突に他のスプライトオブジェクトを使用しています。 。 また、C2には「推測ポリゴン形状」があり、ワンクリックで8ポイントを使用してスプライトを衝突させます。 その後、ポイントを追加してより正確になるように調整したり、プラグインやトリックを使用してピクセル精度を取得したりできます。

つまり、godotがC2のようにイベントシートシステムを適用するが、すべてを使いやすくするために同じ哲学に従わない場合、機能しないため、時間の無駄になります。 そして、実際のGodotエンジンでこれをすべて行うと、本当にクレイジーな作業になる可能性があります。

先に進む場合は、RexRainbow、R0j0houndなどのC2の大物に尋ねたり、雇ったりする必要があります。これは、最高と最悪のことを知っており、C2 / C3の間違いなしで本当に良いイベントシートシステムを作成します。 。 しかし、私が言ったように、それは多くの仕事とお金を意味します。

@matriaxここではあなたが正しいとは思いません。
Godotは、Construct2よりもはるかに柔軟でわかりやすいアーキテクチャを備えています。
前述のように、オブジェクトのペアリングは、特にコンストラクトの苦痛です。たとえば、コンストラクトよりもイベントの順序を明確にすることができます。 イベントシートを任意のノードに添付できます。これにより、構成 '2よりも優れた編成が可能になります。
タイプ/ファミリの場合-godotには「グループ」があります-godotのグループの実装は、実際には構成の実装よりも優れています。
ビヘイビアーをオブジェクトにアタッチする場合-子ノードをアタッチして、アタッチされたイベントシートを含むルート親ノードのビヘイビアーとして使用できます。 これは、実際には再度構築するよりも優れています。
godotでは、衝突形状ノードを衝突のあるノードの子にする必要があります。 これはロケット科学ではなく、実際には子供たちにプログラミングについて教えるのに適しています

あなたが要求していることのいくつかはアドオンとして行われるべきであり、すでにアドオンとして作られています（例えばポリゴンの形を推測します）

godotの現在のアーキテクチャに適合するイベントシートシステムをgodotに実装すると、コンストラクトよりも優れたイベントシートシステム/学習プラットフォームが得られます。これは、godotによってコーディングスタイルの柔軟性が大幅に向上し、アーキテクチャが向上するためです。 プラグインを介してより高いレベルの機能でそのシステムを拡張すると、construct2と同じくらいユーザーフレンドリーになります

godotをConstruct2と同じくらいユーザーフレンドリーにするためには、godotのコア開発者とそのコミュニティの両方が協力して取り組む必要があります。 コミュニティは、イベントシートアドオンを介してより高いレベルの機能を作成する必要があります。 ただし、godotをconstruct2とまったく同じにしようとしないでください。 それは多くの点で優れています。

@blurymind C2と同じアーキテクチャを適用することについて言っているのではありません。それは意味がありません。また、グループや子ノードなど、Godotがすでに持っているものすべてを知りません。

つまり、C2 / C3のようにすべての作業を簡単に達成するために、同じ哲学に従わずにGodotにイベントシートシステムを追加するのは時間の無駄です。 私が言ったように、スプライト/衝突またはすべてのゲームアート用に1つのオブジェクトを持ち、代わりにそれぞれに1つのオブジェクトを持ちます。

たぶん、彼らはコミュニティに実際のビジュアルスクリプトを使用している人の数と、イベントシートシステムを好む人の数を尋ねて決定を下す必要があります。

@matriaxあなたはそのような主張をする前にGodotを学ぶ必要があります:)

ここでの提案は、construct2のエンジンコピー全体ではなく、イベントシートに対するものです。

両方のエンジンを知っている-イベントシートはgodot中心の方法で実行でき、若い子供たちにプログラミングについて教えるためのより良いツールではないにしても、godotを優れたものにするだろうと強く信じています。

その意味で、イベントシートエンティティはスクリプトファイルと同じになります。ゲームメーカーのDNDと同様に、エンジンやその動作方法を変更する必要はありません。 他のconstruct2機能が必要な場合は、いくつかのアドオンを作成できます

アドオンの実装としても-godotのイベントシートは、gdscriptファイルを生成するための別のインターフェイスを作成するだけです。

@blurymindそしてまた同じことで、それを忘れてしまいました。

@matriaxフィードバックは良い考えです。 あなたはその点で正しいです。
インターネット上の誰かだけでなく、ターゲットグループの人々に尋ねるのは良いことです。 ターゲットグループは若い学生や教師である可能性があります-それは実際にはイベントシートシステムの完璧なターゲットになります。
教師は生徒が何に苦労しているのかをよく知っていると同時に、GodotとConstructを知っています。 学生と非コーダーは良いフィードバックを与えることができます

ここでgodotトラッカーについて質問すると、ほとんどの場合、中級のプログラマー、つまりgdscript、エンジンのapi、さらにはc ++をすでに知っていて愛している人々に経験を積むことができます。
gdscriptでコードを記述し、これよりエンジン。 もっと重要な目標があるのは事実です。
運が良ければ、godotに来る前に、構築/ゲームメーカー/クリックチームの融合から始めた人もいるでしょう。プログラミング言語をまだ知らない人にとって、その価値がどこにあるかを知っているでしょう。

シェーダーの作り方をすでに知っているので、3Dアーティストが青写真を好むという良い点を誰かが指摘しました。 これは非常に良い点です。3Dアーティストはプログラマーではありませんが、ノードグラフシステムの概念を学んだ技術者です。

この価値に立ち返ると、Godotが、将来、より多くの子供たちの最初のエンジンになるとしたら、それは素晴らしいことではないでしょうか。
学校でConstructを置き換えてみませんか：）Scirraの開発者は今それを簡単にしすぎています。 彼らが学校とのコラボレーションについて自慢している様子を見てください
https://www.construct.net/gb/blogs/construct-official-blog-1/construct-3-a-year-in-review-947?utm_campaign=blog1postemailsub&utm_medium=email&utm_source=947&utm_term=txt4-read-laura_d% 2527s-post＆utm_campaign = marketing＆utm_source = sendgrid＆utm_medium = email

アドオンとしてアイデアを試すという点で、私はWIPの概念実証GUIを作成しました。 現時点では何もしていません。インターフェースがどのように機能し、godotのアーキテクチャと結びつくかを理解するだけです。 ドラッグしてセル内の要素をシャッフルし、インデントする方法がまだわからない

godotのrichtextlabelノードが内部のgodotエディターアイコンを使用できると便利です。

時間があれば、条件/アクションエディタのモックアップをもう1つ作成します:)
アクション/条件エディターは、セル/ロジックブロックを編集するためのツールになります。 私は、godotの内部コードエディターを式エディターとして使用するConstruct2のアプローチに似たものを考えています。
たぶん、いくつかのヘルパーエイドが後で追加される可能性があります-construct2やfusionのもののように

インターフェイスが作成されると、残りはシーン内のデータを保存/保存し、クリーンなgdscriptを生成できるようにするだけですが、何かが足りない可能性があります

@blurymindニース、私はコンセプトが好きだった。
たぶん、アクションと条件を追加するためのボタンは、構成2のように、背景ボタンなしである必要があります

そして、私は条件を行動から分離するための線がいいと思います

私はこれが判明している方法が好きです。

それは本当にすてきなモックアップです。 最初、私はあなたが何をしているのか本当に理解していませんでした。 さて、それは本当に明らかです...プログラミングと私たちがすでに持っている種類のビジュアルスクリプティングの間の一種の中間ステップですか？

@DrZanuffフィードバックありがとうございます
@ Zireael07ありがとうございます:)
はい、正確に言えば、両方のエンジンを使用してプログラミングを教える学校で、Construct2をGodotに完全に置き換えるのに役立つツールです。
その下には、gdscriptファイルを生成するための単なるビジュアルインターフェイスがあります。これは、ゲームメーカー2でDnDが使用される方法と似ています。godotの優れたアーキテクチャへの変更は要求していません。
イベントシートは、Godotのビジュアルスクリプティングオプションであり、非コーダー（青写真はそうではありません）やプログラミングの概念を学ぶ幼児にとってユーザーフレンドリーです-gdscriptにそれらを容易にします

Godotには、この機能を実現するための要素がすでにたくさんありますが、Construct2とまったく同じにすることはできません。 godotのやり方では、それが起こった場合、それは多くの点でより良くなるでしょう。 Construct2のイベントシートは、いくつかの非常に悪いコード編成の慣行を可能にし、いくつかのひどい制限/癖があります。 私たちは実際に、ユーザーフレンドリーでプログラミングをよりよく教える、彼らのものよりも優れたイベントシートを作成することができます-癖はありません。

私が見ているように（多くの作業はイベントシートを編集するためのインターフェイスの作成にあります）、godotの特典を利用してこれを改善する方法についてはもう少しアイデアがありますが、概念実証の開発には時間がかかりますなるほどね。 時には絵は言葉よりも価値があります。 アドオン-写真以上のもの

これに関するあなたの仕事が大好きです。 作業中にレポで利用できるようにしますか（そうする場合）？ 見て、それを突いて、遊んでみたいです。

@mhilbrunnerもちろんできますが、皆さんがそれを気に入るはずです。 見栄えを良くするために少し時間が必要です。 :)

私はGUIをgdscriptプラグインとしてgodotのエディターに統合する過程にあります-それはまだ十分にインタラクティブではありません:)

基本的なGUIがインタラクティブに機能してデザインのアイデアを伝えるときにgithubに公開します:)今日、イベントシートのGUIをタブとしてロードしました-sketchfabプラグインからインスピレーションを得ました：

おそらく、イベントシートは他の場所からアクセスする必要がありますか？

より多くの更新スクリーンショットを投稿し、最終的にはgithubへのリンクを投稿します-私の最初の投稿をいくつかの計画メモと他のイベントシートエンジンのオンラインデモへのリンクで更新しました

• bbcodeを介してリッチテキストラベルノード内にgodotノードアイコンを表示する簡単な方法を知っていますか？
  以前のモックアップでは[img]タグを使用しましたが、godotエディターが使用するすべてのノードアイコンをダウンロードしてアドオンと一緒に保存する必要があるため、これはかなり貧弱なアプローチです。

• また、アドオンAPIを介して新しいイベントシートスクリプトタイプのリソースを登録する方法を理解するのに苦労しています

@blurymindとても良いです！ 今ではもっと読みやすくなっています。 アクションリストがユーザーにどのように表示されるかを考える必要があります。

古いConstructClassicで気に入った点の1つは、アクションや条件を開かずにイベントシートの値を編集するオプションでしたが、値をダブルクリックして編集します。

誰かがこれを（プラグイン、アドオン、gdnativeなどを介して自分で）追加したい場合は、害もファウルもありません。 そうでなければ、ビジュアルスクリプティングを改善してこれを不要にすることができることに同意します。 GDscriptは簡単で、本当に簡単です。 そして、おそらくいくつかのぎこちないビジュアルスクリプト（青写真ベースでさえ）よりも子供に教えるのに役立つでしょう誰かが構成を必要とするなら、私は言います、彼らに構成を使い続けるように勧めます。 Godotは、コア内にある他のすべてのシステムをエミュレートする必要はありません。 ソフトウェアに焦点を合わせ続け、焦点が拡散しているために「すべての取引のジャック、誰のマスター」にならないようにします。

@spyresは、 @ reduzとgodotチームが学校の若い学生をターゲットにするかどうかによって異なります。
個人的には、学校の構成を完全にgodotに置き換えることができると思います。
現在の設計図システムはそのためには機能しません。 gdscriptよりも使用が複雑であり、前述のように、独自のルールセットがあるため、プログラミングパラダイムを誰かに紹介するための最良の方法ではありません。
これの目標は、gdscriptまたは現在の青写真システムを置き換えることではなく、逆に、子供たちにgdscriptを支援することによって学ぶ方法を提供することです。 これは、yoyoゲームがDnDビジュアルスクリプティングシステムを使用して、プログラマー以外の人にGmlbtwを徐々に紹介する方法です。
プログラマー以外の人にとってよりアクセスしやすく、gdscriptに移行するように設計されたビジュアルスクリプティングシステムを使用しても、害はないと思います。 なぜあなたはやる？

アドオンとして作成しようとしていますが、ドキュメントやAPIが不足しているという点でいくつかの制限があります。 新しいスクリプトリソースタイプを登録し、myscript.esファイルを編集するためにイベントシートエディターを[スクリプト]タブ内に挿入したいと思います。
誰かがこれをどのように行うことができるか知っていますか-またはそれが行われている例がありますか？
独自のタブを持つのは醜いimoであり、エディターの元のデザインに従わない-godotのデザインとシームレスな方法でアドオンを統合したい。

@DrZanuff Godotには、ノードに存在するすべてのメソッドを一覧表示する方法がありますが、それらをアクションまたは条件にフィルターする方法はまだわかりません。 それを行うには、よりゴドット中心の方法を考え出す必要があるかもしれません。 まだそれを探求していて、アイデアを開いています:)

いずれにせよ、完全に機能するアドオンがない可能性があります。 これは、ここでゴドット中心の方法でそれを行う方法のアイデアを探求するためだけのものです-少なくとも今のところは

ビジュアルスクリプトを大幅に改善できない（または改善しない）、または年少の子供がそれを使用できない、または構成からgdscriptに成長できないという仮定は、実際にはちょっとばかげているようです。 特にビジュアルスクリプトはかなり新しいので。

非常に幼い子供向けのソリューション_（開発者がGodotの主要な人口統計として言及しているのを見たことがない）_がこれほど大きい場合は、構成概念使用してから、GDscriptを介した実際のプログラミングに移ります。彼らは準備ができています。

アドオンとして作成し、そのアドオンをサポートしたい場合は、いじめます。 しかし、重複するものとして、コアを肥大化し、（おそらく）将来のサポートや統合などで限られた公式の開発時間を無駄にします。 _

@spyresはあなた自身の開発者ですか？ それとも先生？ 自分のプロジェクトで実際にgodotのビジュアルスクリプトを使用したことがありますか？ もしそうなら、プログラミングについて人々に教えるためのより良いツールになるためにどのように改善することができますか？

@blurymindあなたのアイデアは良いと思います。 さらに、あなたはすでにそれについてかなりしっかりしたビジョンを持っているようです。

しかし、「学校の構成をGodotに置き換える」ことは、この機能を備えている正当な理由ではないと思います。 GodotがUnityやUnrealなどの他のエンジンを置き換えるビジョンを持っていることを覚えていません。Godotは他のツールを粉砕しようとはしていません。 生産性を上げることが理由なら、私はそれに同意します。

また、Godotが教育分野をターゲットにする必要がないという@spyresにも同意します。 Godotがプログラミング（ゲーム開発者でさえも）教育ツールとして適していない場合は、そうしてください。 そもそもそれを意味するものではありませんでした。 しかし、誰かがどういうわけかgodotをプログラミング教育ツールとして使用/変換できれば、私はそれで問題はありません。

それでも、このイベントシートは興味深いアイデアだと思います。

@blurymind godotは教育ツールではなく、ゲームエンジンであることを忘れていると思います。 コンストラクトのようなものを外部モジュールとして実装したい場合は、問題なく自分次第ですが、ゲーム開発用のものを子供向けのおもちゃに変換しようとしないでください。 本当に必要なのが構成であるのに、なぜgodotを構成に変換しようとするのですか？ godotの代わりに使ってみませんか？

@zaniar @ ni-codeその通りです。 確かに、私は現在の青写真のアプローチよりも効率的で明確なビジュアルスクリプティングツールを作成することに個人的に興味があります。 私はConstruct2-が好きではないので、Godotをそれに変えたいのは真実ではありません。 前に述べたように、私はそのデザインと癖がかなり悪いと思います。 そのため、イベントシートを見つける場所は、Godotほど良くないのでイライラします。

正直なところ、設計図が改善されたとしても、イベントシートほど明確で迅速に作成することはできないと思います。その点で、イベントシートは、過小評価されることが多いラピッドプロトタイピングに最適なツールです。 しかし、Clickteamフュージョンによって作成されたタイトルはそれ自体で語るべきです。 おもちゃのように見える人もいるかもしれませんが、私にとっては、この方法でゲームロジックを構築するのは楽しいことです:)

私はconstruct2とFusionの両方を使用したことがあるので、イベントシートのアプローチが大好きで、godotのAPIで、イベントシートシステムの美しい候補を見ることができます。
Godotのノードネスティングデザインは、gdscriptの表現の明瞭さと組み合わせて、これと非常にうまく機能します。
私はそれがgodotに実装されることを期待していませんが、有用なフィードバックとAPIの助けを得ることを期待して、ここでプラグインの進捗状況を共有し続けます。 ここの開発者の何人かはConstruct2を使用していて、Godotを本当によく知っているので、議論から良いアイデアが生まれるかもしれません。

私は実際に、経験豊富なユーザーであっても、gdscriptを使用するだけで少し優位に立つイベントシートシステムのアイデアを持っています。 gdscriptの代わりではなくgdscriptで使用することになっています-それを忘れないでください

必然的なビジュアルスクリプティングの改善が（完全に統合/サポートされているため）、ぎこちない「コンストラクトライト」キディ中心のプラグインよりも便利である（そしておそらくより人気がある）ことを楽しみにしています。

@spyresトーンをダム」または、彼らは単に「janky構造-liteの児童中心の」ものになるだろうに（無料！）仕事を投資しているプラグイン潜在的なことをしている他の人に伝える必要はありません。

確かに、人々は彼らが望むように彼らの時間を自由に過ごすことができます（私はそれが最終的には役に立たないと感じます）が、それがそうであるかもしれないので、Godotのコアデザインを助長しません。

礼儀正しさの利益のために、人口統計ゴドーのコアに焦点を当てていない、期待されている何かがコア開発者の時間を無駄にしないだろうぎこちないとして構築物スタイルのデザインシートを記述して行こう（OPはここを求めているもの_exactly_です！「児童中心」が） 、など。

_実際のコンストラクトエンジンがすでにその機能を堅牢な方法で提供しているする必要があるのですか？_

7歳の子供の人口統計は本当にその種の重複を叫んでいますか？

@mhilbrunnerが自分の投稿に答えると、7歳のトロールに返信したように感じます：D
彼はここで私の投稿のほとんどを親指で下ろしました-すべての親指を下ろしたのは実際には彼です。
彼は実際には質問に答えていないので、彼と議論する意味はないようです-私は彼にいくつかのフィードバックを得るのに役立ついくつかの有効な質問をしました。 私が見返りに得たものはもっと同じです

githubには、悪用されている場合に投稿をブロックする方法がありますか？

私は確かにいくつかのアイデアを疑問視している間、うわー、私は_never_実際に誰かの名前を呼ばれてきました。 _それ_はかなり虐待的だと思います。

Godot内でコンストラクトの機能を複製すると、まだ十分に提供されていないものが提供されます...コンストラクト。

単に7歳の子供にアピールするために、Constructの機能セットを（おそらくより少ない方法で）godotに複製することには、正当な利点がありますか？

なぜあなたは単に構成を使わないのですか？ 彼らのセットアップ（一部は複製したいと思っているようです）は本当に不足していますか？

子供がコンストラクトを超えてしまうと、gdscriptまたはビジュアルスクリプトに移行できなかったと考える正当な理由はありますか？

@spyresは、イベントシートやイベントシートを使用する人々を表すために一般的に不快な用語を使用しています。
彼らは「子供」ではなく、システムは「ジャンキー」ではありません。 神のためにそれらのコミュニティを尊重してください。 このエリート主義の態度はどこから来ているのですか？

Construct2には非常に経験豊富なjavascriptプログラマーがたくさんいます。私が書いたものを実際に読んで、提供したリンクをたどるのに苦労したことがあれば、それは明らかなはずです。 彼らが作成したアドオンの中には、babylonやthree.jsなどの3Dエンジンと統合するものもあります。そのため、経験豊富な開発者もイベントシートを使用してゲームを作成することを楽しんでいます。

Clickteamフュージョン製のゲームは、Steam、Kickstarter、さらにはアプリストアでのGodot製ゲームの数と収益の数を大幅に上回っています。 これは完全にイベントシートベースのエンジンで、10〜80歳で使用されます。 それはすべての年齢の混合物です。 ユーザーの中には映画製作者もいれば、アーティストもいます。ライセンスや輸出業者などにお金を使う仕事をしている人です。 一体、私はこれまでのところ、godotに関係する他の何よりも、彼らのアセットストアで物を売ってより多くのお金を稼ぎました。
ここにいくつかの例があります-映画製作者のアロンソ・マーティンはゲームを作ることにしました：
https://www.kickstarter.com/projects/alonsomartin/heart-forth-alicia
7歳の束がゲームを作る
https://www.kickstarter.com/projects/galaxytrail/freedom-planet-high-speed-platform-game

こちらをご覧ください
http://indiegames.clickteam.com/
それらの7歳の子供たちは確かにゲームを作ってお金を稼ぐ方法を知っています
https://thinkgaming.com/app-sales-data/publisher/3107/scott-cawthon/

プログラミングを教えるためのより良いツールとしてこれを販売するという私の見方は、そのように誤ったラベルを付ける理由にはならないはずです。 ユーザーの人口統計が広くなると、エンジンを使用してゲームを作成するユーザーが増えることになります。 それは明らかではないでしょうか？ なぜこれは明白ではないのですか：D

私がConstruct2のカーボンコピーを要求していないことを繰り返す必要があるのは何回ですか？ 実際に何も読まずに同じメッセージを繰り返すようなものです。 私が提案しているのは、Construct2のイベントシートのコピーではなく、Godot中心のイベントシートです。

では、システムが「ジャンキー」であるというあなたの投稿をどのように読んで、godotの無料アドオンを作成するように私を動機付けているのでしょうか。 これについて少し考えてください

うわあ！ にもかかわらず、ゴールポストをシフトする...

はっきりさせておきます。

構築は、それが何をするかでかなり成功しています。 したがって、その機能セットを（全体的または部分的に）完全に異なるエンジンに移植/複製する必要性（？！）は、私を免れます。

実際の利益に関する質問は同じままですが、一部の人は（不可解に）それらを「不快」と感じるかもしれません。

完全に異なるエンジンに移植されたアドオンは、コンストラクトを使用するよりも何とか優れているという提案はありますか？ 何かが組み込まれていること（アドオンを介してさえ）は、多くの人々が堅牢なソリューション（つまり構築）で使用することを期待するものですか？ 私はそれを疑います。

しかしねえ、なぜそこで止まるのですか？ 子供向けプログラミングを教えるための優れたツール（構成を超えたもの）が存在します（例： Scratch 、 Styncl 、 code.orgなど）。それらをGodotにも組み込んでみませんか。

またはおそらくそうではありません... ;-)

Godotのビジュアルスクリプティングを使用したことがあり、Godotのビジュアルスクリプティングのみを使用しているように見える人はいますか？

@Zonacas Godotのビジュアルスクリプティングはまだ十分に成熟しているとは思いませんが、間違っている可能性があります。 VSは、この時点で2か月ほどしかリリースされていないことに注意してください。 :)

@ZonacasはdiscordサーバーでVSチャネルを調べてみましたが、1つか2つの自称非プログラマーがそれを気に入っているのを見ました（しかし、非プログラマーには良くないと言うプログラマーも

みなさん、こんにちは。概念実証アドオンの進捗状況を更新しました。

これがあなたのための新鮮なgifです：

それが行うことのいくつかの背景-基本的に、イベントシートはセルで作られています。 セルは、条件（ゲッター/式）またはアクション（ゲッター/式でフィードできるセッター）のいずれかになります。
GUI側では、イベントセルは、gdscriptから生成されたrichtextlabelノードとbbcodeを介して作成されます。 それをダブルクリックすると、richtextlabelは実際のgdscript式を含むエディットボックスノードに変わります。

したがって、イベントシートセルには2つのモードがあります。

• 編集モード-gdscriptで入力できるtextEditノード。
  唯一の違いは、ユーザーがIf / else / whileを入力する必要がないことです。これは、スクリーンショットに示されているように、親コンテナーのコンテキストに依存します。 すべての行は新しい条件であるため、ユーザーが「or」などで行を開始していない場合、パーサーは新しい行に「and」という口実があることを自動的に認識します。

クリックすると、表示モードに切り替わります。

• ビューモード-リッチテキストラベル-ビューモードに切り替えると、bbCodeは編集モードのgdscriptから解析され、インタラクティブなリッチテキストラベルを介して表示されます。 インタラクティブで変更が簡単なことは別として、目標はgdscriptコードをより明確な方法で提示することです。 これは、ノードの名前とアイコンのみ（パス全体ではなく）を表示し、明らかな場合は一部の単語（get_やset_など）を削除することを意味します。 クリック可能なすべての部分は実際にはURLタグであるため、たとえばノード名にカーソルを合わせると、ユーザーはノードのフルパスなどの情報を取得できます。

[新しい条件の追加/アクション]メニューについて：
これは、条件またはアクションの新しいgdscriptコード行を作成するものです。 シーン内のすべてのノードとそのメソッドを簡単に参照できることは素晴らしいことです。これは、gdscriptのエディターでのオートコンプリートの動作とは逆の方法で機能します。 すべてのノードとそのすべてのセッター、ゲッター、または両方のメソッドが表示されます。 次に、フィルターを使用して必要なものに絞り込むことができます。
条件セルからcallendの場合、このメニューにはゲッターのみが表示され、アクションセルから呼び出された場合は、setterメソッドとgetterメソッドの両方が表示されます。

これを機能させるための次の作業は次のとおりです。

• イベントの順序を簡単に変更できるように、セルのドラッグを行う方法を理解する必要があります。
• また、プレビューモードでのコピーと貼り付け。
• 次に、特定のタイプのプレビューモードのセルのURLがクリックされたときにポップアップする式エディターを作成する必要があります
• プレースホルダーアイテムの処理方法を理解します。 コメントを入れることを考えましたが、残念ながらgodotはインラインコメントをサポートしていません： https ：

このアイデアは、単なる教育ツール以上のものに進化しています。 gdscriptをすでに知っていて愛している人には、実際に時間を節約できる便利な機能を提供できると思いますが、これを開発して、その方法を紹介できるようになるまでには、もう少し時間がかかります。

皆様のご支援に感謝します

プラグインの良いアイデア。 しかし、2つのビジュアルスクリプティングシステムを公式に維持することは苦痛であり、ほとんど利益がありません。

XKCD：標準

これが単なる概念実証ではなく、実際のアドオン/プラグインにならない理由がわかりません。 デフォルトですべてをエンジンにバンドルする必要はありません。 それがGDNativeが開発された理由ではないのですか？

@Megalomaniakそれは真実であり、godotのAPIについて十分な知識があれば、これをgdnativeアドオンとして書き直すと言ったときに信じてください。 しかし、ここまで到達しても苦労し、これを実際に使用できるツールに変えるためのいくつかの重要な要素が実際に欠けています。 私はここで質問を提起しましたが、これまでのところ、誰も私に答えを教えたり、例を示したりしていません。

• 新しいスクリプトリソースタイプをgodotエディターに登録し、ユーザーがそれを任意のノードに接続できるようにするにはどうすればよいですか？ 現時点では、アドオンはシーンのルートとそのハッキーから動作しています。
• 次に、godotがイベントシートのGUIを開くようにするにはどうすればよいですか？現在のブループリントシステムと同じように統合されています
• editTextノードをgodotのgdscriptエディターのように動作させるにはどうすればよいですか-構文の色付けとオートコンプリートを有効にします。 さらに、どのようにカスタムコンテキストを与えるのですか？

APIの知識が非常に低い人がこれを行うことができます。 そのようなものはドキュメントにありません-それの既存の例もありません。
私はデザインのアイデアを持っていますが、それを実現するための全体像はまだありません

これまでのところ、私はデザインコンセプトを推し進め、APIについてさらに学ぶことができますが、これが実際に完全に機能するアドオンに変換できることを確実に保証することはできません。 これまでのところ、人々はそれをとても気に入っているようです

このようなものについては、開発者の希望を尊重することを好みます。

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

Godotをより良くする素晴らしいアイデアがあります。

あなたの考えは間違いなく無視されます。

Godotが良くなるので、これをやってみましょう
別のゲームエンジンがそれを行うので、Godotでこれを行いましょう
必要ないと思うので削除しましょう
雑然とした膨満感を取り除き、Godotの見栄えを良くしましょう
それを好む人々のための代替ワークフローを追加しましょう

@spyres私は実際にこれを作成しており、ドキュメントで見つけられないことについてAPIで他のgodotユーザーからのサポートを求めています-godotに貢献しようとしています。
あなたはここで何をしているの？

あなたはすべてを殴り書きし、すべての投稿で同じことを繰り返す唯一の人です。 それはトロールがすることと非常によく似ています、あなたは同意しませんか？ あなたは、デザインのアイデアについて話し合うことから離れて、会話を追跡しています。

@blurymindある人の「貢献」は、別の人（またはエンジン）の気晴らしです。 異なる意見（公式ドキュメントの一部として投稿するのに十分重要であると感じた開発者の意見でさえ）の概念があなたにとって非常に不快に思われることを残念に思います。

アドオンで頑張ってください。 ：ニヤリ：

@spyresですが、実際に何か作ったことはありますか？ godotのアドオンを作成したことがありますか？ godotを使用していますか？

なぜあなたはここにいるのですか？ あなたは議論に貢献しようとはしていません

@blurymindうわー、さまざまな意見が本当にあなたをそんなに悩ませますか？ なんて悲しいことでしょう。

@spyresここにいる誰もがあなたの意見を見ることができます-あなたはそれでスレッドをスパムしています。 ここにあるすべての親指はあなたのものです。 それは意見ではありません-そのスパム。 少なくともデザインと特定のものについてのちょっとしたことはありますか？ 私は以前にいくつかの質問をしました-あなたは何も答えませんでした

明確にするために、私は時間を使っている人を完全にサポートしますが、彼らはこのようなものをアドオンとして作成したいと思っています。これは、私のような価値のない人々が平和的に無視できるものです。

代替ワークフローとして、実際にgodotコアに統合されていますか？ うーん、お願いします、いいえ。 私はそのようなことについての開発者の意見を持っています。

@spyresはい、あなたはすでにそれを言いました。 上にスクロールして、さらに5回読みます。 あなたの一人がいます..しかし何度も

@blurymindそしてそれはどういうわけかあなたを悩ませているようですか？ うわー、別の意見など。

_あなた_は何も繰り返していないと思いますか？ （あなたは誰ですか、なぜあなたはここにいます、あなた自身を正当化してください！） ：ニヤリ：

開発者によって書かれた公式のドキュメントコメントが少し消化不良を引き起こしたと思いますか？

ええ、その超心温まる

@blurymindありがとう、その頃はハグ！

私は本当にあなたと一緒にgdnativeを介してこれを実装する幸運を祈ります。その時点で、そのような非公式なものを欲しがる人たち（私が思うに非常に少数です）のためにそこにあります。

ただし、情報を入手できない場合は、これを実現するために必要な支援が必要です。おそらく、この代替言語の可用性が実際にあなたにとってどれほど意味があるかを再評価する時期かもしれません。

@spyresスパムを止めてください。 これらのメールや通知は必要ありません。 あなたはあなたの意見を表明しました、それは素晴らしいです、しかしあなたはそれを繰り返し続ける必要はありません。

@mhilbrunner私の意見の違いが

@spyres以前の投稿で、このアドオンはgdscriptを使用することを目的としており、代替言語としては機能しないことを指摘しました。 そして、はい、誰もこのトラッカーをモ​​デレートしていないようです

さて、あなたが早く終わるほど、私たち全員が正しくにしますか？ 他の多くのアドオンと同じように、実際にそれを望んでいる少数の人々にとっては素晴らしいことだと確信しています。 これがあなたに過度の苦痛を引き起こしているのを見るのは難しいので、あなた自身の世話をし、情報の不足/進歩があなたを失望させないようにしてください。 公的支援の圧倒的なうねりがあれば、すぐに必要なすべての情報/ヘルプを手に入れることができると確信しています。

賢者の言葉を借りれば、「心配しないで、幸せになりなさい」。 ：ニヤリ：

または「誰かが目を離さない限り、それはすべて楽しくてゲームです！」 （ええと、待ってください、それは私が探していた見積もりではなかったと思います...）

わお。 正直なところ、これは素晴らしいです！

私が最初にあなたの投稿を読んだとき、私は同意しましたが、大きな議論があるのではないかと少し心配しましたが、あなたがやって来て、あなたがすべての樹皮と噛み付きではなく、実際にアドオンの開発を始めたことを示したとき、私は感銘を受けました。

GDScriptとの相互作用は、ゲームメーカースタジオの大きな機能（視覚的および適切なスクリプトの互換性）であり、ノードベースのシステムでは実際には実現できなかったため、気に入っています。

これが完了すると、それは多くの人々を助けるつもりです

私は過去6年間、Constructユーザーであり、最も速くて単純なビジュアルスクリプティングにアプローチするための最良の方法であると断言できます。

素晴らしいアイデアです！

これはとても便利です。 発売まで待ちきれません！

素晴らしいアイデア、SnailOnとのコラボレーション。

1. 彼は天才です。
2. 彼は約3年間Godotを使用しています。
3. 彼はTGF以来Clickteamエンジンを使用していました
4. 理想的な候補。

@boruok私は初期の頃からsnailonのytチャンネルのファンでした。 😄彼のチュートリアルは私がずっと前に融合を学ぶのを助けてくれました。 彼はgithubアカウントを持っていますか？ 私は彼の心をいくつかのことに気づかせたいと思います。

ところで、私は、Construct2がセルの設定方法を決定するために使用しているものよりも、クリックメニューのようなFusionに傾いていることを認めなければなりません。 アップデート1で提供されるヘルパーメニューは、Clickteamのデザインに間違いなく影響を受けています。 このアドオンでは、私がエンジンのカーボンコピーを作成しているのではなく、イベントシートのゴドテスクなアプローチに適したアイデアを借りていることがわかります。 ゲームメーカーも少しあります-ビジュアルスクリプトがシームレスに実際のスクリプトに切り替えることができる方法で-より上級のユーザーが喜ぶかもしれません

このアドオンの進捗状況をフォローしてくれた皆さんに感謝します。 最初の反応は圧倒的にポジティブです
これは私がアイデアをさらに推し進め、同時にそれをシンプルでエレガントに保つことを試みる大きな動機になります。

インラインコメントがないと、gdscriptとvisualscriptを簡単に切り替えるのは難しいですが、それを乗り越えて実験する方法についていくつかのアイデアがあります。そのため、私はそのATMに取り組んでいます。
gdscriptで、式が期待される空のプレースホルダーを定義する方法が必要です。
式はある種の値を返すので、プレースホルダーをマークするためにgodotの値変換メソッドを使用することを考えました。
float() ## this will turn into a bbcode item that expects an expression resulting in a float
しかし、最終的に生成されたgdscript内に多くの不要な変数型変換メソッドが生成されるため、これはやや醜い可能性があります。

godotがインラインコメントを実行できれば、代わりにgdscriptからbbcodeを作成するメソッドにそれらを解析することができます。 これにより、追加情報を提供できるようになります

本当に最善のアプローチは、私のいまいましいgdscriptからbbcodeパーサーメソッドをよりスマートにすることです-これは私が今やろうとしていることです

@ blurymindgit -accountについては

@blurymind私はこれを100％サポートします！
（英語は事前に申し訳ありません）

人々を荒らしするために使用できるものを超えてaboutページを適切に見ると、これが私たちが見ることができるものです：

開発者は（たとえば）に興味があります：

ソフトウェアの使用経験と問題（これは、ソフトウェアを改善する方法に関するアイデアよりもはるかに重要です）。
プロジェクトに必要なため、実装してもらいたい機能。
ソフトウェアを学ぶために理解するのが難しかった概念。
ワークフローの最適化したい部分。
明確なチュートリアルを見逃した部分、またはドキュメントが標準に達していない部分。

これを念頭に置いて：

• 現在のビジュアルスクリプトは、実際のコーディング方法を知っている場合にのみ使用できます。 そして、ハードコードよりもすぐに混乱します。 誰が助けてくれますか？ また、非常に具体的な技術的背景がない限り、青写真もそれほど役に立ちません。

• 高レベルのイベントシートはうまく機能します。 上記のすべてのアプリの成功に見られるように。 うまくいけば、それらは実際に把握し、非コーダーのために使用するのがより簡単です。

• なぜGodotは非コーダーに対応するのでしょうか？
  専門的なプロジェクトに取り組んでいる多くの人々にとって、これには多くの用途があります。
  小規模、中規模、大規模の多くのプロジェクトでは、チームの一部がコーディングを行い、別のプロジェクトが独自の作業を行います。 音楽とサウンド、ビジュアル/アニメーション/ SFX / UI、ゲームデザイン、ライターなど...
  時にはそれは一人のチーム、あるいはこの映画製作者のような業界外の人々がかなり成功したゲームをしていることさえあります。
  プログラミングをしたいが、さまざまな理由でコーディングをしたくない人もいます。
  失読症のような問題の例では、コードは悪夢になりますが、イベントシートのようなより視覚的なアプローチを介してプログラミングは可能です。
  ほとんどの場合、これらの人々は、ゲームで必要なものを作成している間、コーディング以外のことをする必要があります。
  イベントシートを使用すると、グラフィスト、サウンド、またはゲームデザイナーは、生のコードに飛び込むことなく、自分の作業を非常に簡単にテストまたは実装できます。
  また、概念実証をテストするための超高速プロトタイピングも可能になります。 たくさんのストック画像を投げて、こことそこに少しクリックして、あなたのアイデアが今楽しいかどうかを確認することができます。 優れたコーダーや有名人/スタジオでさえ、プロジェクトの開始時に反復するために可能な限り単純なものを使用します。
  ここでそれらすべてについてのより多くのフィードバックと議論、そして私はOPに強く同意します。
  （Githubはこれに関するフィードバックに最適な場所ではありません。ここに来る人々は通常、コーディングに深く関わっており、実際には少数派であるにもかかわらず、その必要性を理解できません。）

• 結論：Godotと対話するためのシンプルで効率的なツールを人々に提供することは、専門的なプロジェクトに取り組んでいる多数の真面目な大人にとって、多くの異なるレベルでの天の恵みとなるでしょう。
  （子供や学校だけでなく、それが実際に彼らにも役立つとしても。）

• ちなみに、もっと多くの例を見たい場合は、イベントシートを使用するGDevelopという別のツールがあります。 以前のインターフェース（バージョン4）はかなりいいですが、現在のインターフェース（v 5）はちょっと悪いですが、アプリにはいくつかの良いアイデアがありますが、いくつかの欠点があり、その方向性もまだ少し不明確ですが、それはあなたに与えるかもしれませんいくつかのアイデア、または少なくとも別の比較ポイント。

すでに行われた作業、特定の反応にもかかわらず前向きでやる気を維持し、あなたのアイデアを信じてくれたことを祝福します。 私もそれが本当に非常に有用であり、私にとって大きな問題を解決するであろうことを確認します。

@TheGoklayeh親切な励ましの言葉をありがとう。 私はあなたが何を意味するのかを正確に知っています。 ここで前述したように、成功したインディーClickteamフュージョンゲームは、成功したインディーGodot製ゲームを大幅に上回っています。
公開されているゲーム、Steam、モバイル、キックスターターのタイトルの販売数は目標を達成しています。
これは、「子供」だけでなく、プロのアーティストやデザイナーがそれを使用していることを示す十分な証拠となるはずです。

Gdevelopの新しいIDEのトピックに関しては、それは素晴らしいと思いますが、完全な機能ではありません。 主な開発者が行った賢明な動きの1つは、ideをjavascriptに移植することでした。これにより、c ++以外の開発者が貢献できるようになりました。 私はこれまで、遊んで学ぶためだけに、小さな修正を加えて実際に貢献してきました。 今週末、私はpiskelをそれに統合するためのいくつかのステップを試してみるつもりです😃-すべてがうまくいけば、組み込みのピクセルエディタを取得している可能性があります。
メインの開発者は最近、別の開発者による貢献を統合し、箱から出してドラゴンボーンのサポートを追加しました。 必要に応じて、オンラインデモではなく、githubからの最新リリースを試してください。 商品あり
https://github.com/4ian/GD/releases

私もこのアドオンの進歩はまだ遅いです。 さらに先に進む前に、いくつかのことをリファクタリングする必要があります。

おそらく、ここでgodotを使用するすべてのfusionユーザーとconstruct2ユーザーを取得することをお勧めします。 このスレッドを見せて、デザインに関するフィードバックをもらいましょう。
Snailonはまだ私に連絡していませんが、そうです。彼はイベントシートに関しては非常に経験豊富なプログラマーです。 彼もgodotユーザーだとは知りませんでした。

これはすごいですね！ これを開発/プッシュしてくれてありがとう、blurymind。
私はgamedevを23年ほどやっていて、基本的にすべてを試しました-すべての人気のあるgamedevツール/エンジン、プログラム言語など。そして、ゲームを終了できるので、一日の終わりにイベントシートを好みます。 :)
トップダウンリストのアプローチで条件とアクションに分割することで、他のどのシステムよりも整然とした簡潔なものになります。 私はより視覚的な方向性を持っているので、垂直/水平の堅い構造を持つことで、プログラム/イベントを簡単に流れることができます。
スパゲッティ接続を必要とする他のビジュアルスクリプティングは非常に厄介で気が散ります-視覚的な詳細は、視覚に関心のある人々の集中力を壊す騒々しい美学に散らばっています（同じ人々のビジュアルスクリプティングが狙われていると思われます）。
イベントシートは私にとって最高です。 私は23年間、blitzbasic、gamesfactory、unity、c ++、javascriptなどすべてを使用してきましたが、これは確かです-イベントシートが大好きです!!

ブループリント/ノードスタイルの編集は、「スパゲッティコード」を整理/回避するのが非常に困難です。 Clickteam / Construct / GDevelopスタイルのイベントと同じだと思っている人には申し訳ありませんが、根本的に異なり、イベントシートは客観的に優れています（ゲームは本質的にルールベースのIF / THENであり、はるかに簡単に移行できますイベントからコードまでですが、一般的にイベントはゲームロジックをコーディングするよりも高速です）。

ノードベースの編集が便利な瞬間があると確信していますが、イベントベースの編集がベースのGodot Visual Scriptingに含まれていれば、すぐに推奨されるオプションになります。

@bigelod @prominentdetailイベントシートが非常に優れている理由について、コーディングを学んでいる人だけでなく、経験豊富なプログラマーにもフィードバックを提供していただき、ありがとうございます。

あなたは絶対に正しいと思います。 @prominentdetailと同じように、私はフュージョンのイベントシートから始めて、さまざまなエンジンを

また、イベントシートゲームエンジンコミュニティのATMのトレンドにも気づいています。これは、godotがユーザーベースを拡大するために実際に利用できることです。

• イベントシートを使用する開発者のコ​​ミュニティは、イベントシートを使用する3Dエンジンを切望しています。 クリックチームフュージョンコミュニティは両方とも、それをアドオン（ホタル）とコンストラクト（多数のプラグインを試しました）として統合しようとしましたが、これらのアドオンは3Dシーン編集機能を提供しませんでした-イベントシートを3Dエンジンで動作させるためのハックでした-トップ2dに配置3Dゲーム用に設計されていないエンジンエディタ。 イベントロジックを含む3Dシーンのみを作成できます。オブジェクトを配置したり、マテリアルを設定したりするのは面倒です。
• 学習しているプログラマーも経験豊富なプログラマーも、今でもイベントシートが好きで、教えるだけでなく、プロトタイピングにも使用しています。
• 多くのインディーチームは、イベントシートを使用して成功したタイトル（キックターター、スチーム、その他のプラットフォーム）を作成してきましたが、最初のポイントのために3Dプロジェクトはほとんどありません。

これをgodotのアドオンとして機能させるのは難しいです。これは、エンジンにアクセス方法がわからないことがいくつかあるためです。 私が持っている現在の実装は迅速で面倒であり、GUIを実行する方法の一部を示す以外に何もしません。 もっと見栄えのする状態にしようと思い、ここに投稿します

ちなみに、私はPiskelをGdevelopにバンドルして統合することができました。 これは私をここ数週間忙しくさせていました。 あなたがしたい場合はそれを試してみることができます:)
gdevelopでもイベントシートがどのように行われるかを見てきました

@blurymind OK、ここでこの投稿を無視しようとしたとしましょう。2つのビジュアルスクリプトのアイデアが気に入らなかったからです。

しかし、いよいよ議論を始める時が来たと思います。 GUIを構築するためにドキュメントを使用したに違いないと思います。 モックアップはかなり良い作業です。コードを少し見ることができるかもしれないリポジトリがあるかどうかを尋ねたかったのです。 おそらく、それをEventSystemのように、そしてより実行可能にすることについて何かをすることができるかもしれません。

私は現在のビジュアルスクリプティングシステムでいくつかの作業を行うことを計画していました。 そして、GDevelopに出くわして気に入ったとき、私はここに来て尋ねました。 結論を1時間読んだ後、私たちは妥協点を見つける必要があります。

2つの異なるビジュアルスクリプティングシステムを維持することは不可能であり、そのうちの1つは死ぬ必要があります。 しかし、私を含む誰も、ブループリントノード構造を手放したいとは思っていません。
しかし、このEventSystemは美味しすぎて（少なくとも基本的なプロトタイピングには）食べられません。

VisualScriptingをもっとプロトタイピングツールにしたかったのです。 限られた機能は、実際にユーザーベースを増やすことができるかどうかは関係ありません。
以前に誰もこれに気づかなかった場合は、より多くのユーザーがより多くの寄付に等しいことも考慮されるべきです。

しかし、Blueprintsは業界レベルのツールであるため、その用途があり、Godotにとっても重要なGodotにとってより大きな魚をもたらす可能性があります。 そして、私はそれについてもあまり知らないかもしれないと言いました。

質問は簡単です、何をすべきか？ -両方を選択することは不可能です。
しかし、ハイブリッドはGodotをより人気のあるものにするかもしれません。
あなたは少なくとも私よりも両方のビジュアルスクリプティングスタイルを経験しているので（私はアーティストというよりはコーダーなので、自分のやり方でコーディングするのが好きです）解決策を考えてみませんか。

これにより、EventSystemだけの場合よりも多くの人が参加する可能性があります。 また、ノードシステムを存続させることも良い動きです。

それで、中間点が達成できない場合はどうなるでしょうか。 何かが消えてしまいます。 それが何であれ。

個人的には、以前にブループリントを使用した経験があるので、ブループリントに投票する可能性があります。より大きな魚のアンリアルと比較してもらいたいと思います。
しかし、比較のために、15分以内にGDevelopを入手しました。 GDScriptは別の日に数時間で、ブループリントはGDScriptの2倍になります。
プログラマーとしての私の経験レベルも示していますが。

決められない。 こちらをご覧ください。

1. Unity：4011
2. 非現実的：316
3. ゲームメーカー：274
4. 構成：223
5. Godot：75
   _グローバルジャムのエンジンごとのReduzのツイート数からのリスト。_

Godotを一番上に置きたい。 ですから、VSの愛がそれを達成するのに役立つことを願っています。
しかし、Unreal + Godot + GameMaker + Constructはまだそれをカットしていません。 しかし、少なくとも2位になります。

Godotのビジュアルスクリプティングの将来をどう計画するか、私は地獄のように混乱しています。 現在のシステムを待っている、または壊れているものを無意識に改善しようとする原因は役に立ちません。

「EventSystemは、ある程度のScratchを使用したプログラミングのようなものです。一方、ブループリントは完全に一意ですが、EventSystemよりも強力であるため、EventSystemは深さを混乱させ、読みやすさが低下します。」

何？？ 特に他のイベントシートを含めたり、グループを使用したりして、Constructのイベントシステムを試してみると、まったく逆になります。

最良のノードシステムは、平均的なEventSystemと比較して、常にコードスパゲッティになります。

@bigelod確かに、そのように言うべきではありません。 似ていると思いました。 EventSystemsを学びながら、2時間かけてそのコメントを書きました。 申し訳ありませんが、修正されます。

はい、私が最もよく知っているのは青写真であり、そのようなものがあるのは素晴らしいことですが、イベントシステムはより初心者に優しいものを追加します。 また、プログラミングの学習にも役立ちます。

@swarnimarun何年も前に、私はこの同じトラッカーでイベントシートをgodot開発者に売り込みました。 しかし、当時私は素晴らしい仕事をしていませんでした。多くのgodotユーザーも元ユニティ/アンリアルユーザーだったため、ブループリントのサポートはすでに増えていました。 ブループリントはすでに勝利しており、現在はGodotにあります。

現在、クリックチームフュージョン、ゲームメーカー、コンストラクトなどのエンジンを実際に使用している多くのユーザーは、イベントシートをサポートしており、設計図の使用を非常に嫌っています。 彼らはあなたが言っていることの反対を言い、すでに説明されたことを説明します-イベントシートやスクリプトと比較したときに青写真が混乱する理由。 私もすでにやりました。

他のビジュアルプログラミングエンジンフォーラムを見ているときでさえ、新しい設計図システムエンジンに対する否定的な反応を見ることができます。
https://rpgmaker.net/forums/topics/23922/?post=857285#post857285

結局のところ、両方のシステムが存在できない理由はわかりません。 ブループリントがgdscriptノードと連携する方法です。

実際、理想的な世界では、イベントシートを作成し、きめ細かいロジックと青写真を使用してラピッドプロトタイピングを行い、ステートマシンで整理する必要があります。
どうして？ どちらのシステムにも長所と短所があるからです。

ノードを使用して単純な式を作成し始めると、Godotの青写真はすぐに混乱する可能性があります。 この同じ式は、イベントシートまたはスクリプトではるかに明確にすることができます。

オープンソースプロジェクトは民主的です。コミュニティがアイデアをサポートすればするほど、それが現実のものになる可能性が高くなります。 しかし、それは別のアイデアを殺さなければならないという意味ではありません。 どちらのアイデアも広く好きか嫌いかです。

ここにいる全員は、イベントシートと青写真の両方を使用して、ゼロからプログラミングすることを理解する必要があります。 最も重要なのは、システムがロジックを構造化できるようにすることがどれほど明確かということです。 ブループリントを使用すると、実行の順序が混乱し、デバッグが困難になる可能性があります。 また、イベントシートと比較すると、クリック数と設定手順が多くなります。 これが私のメインピッチです-プロの開発者とビジュアルプログラミングのファンの両方に。 しかし、それは個人的な好みの問題であることも忘れないでください。 ブループリント開発者にこれをファンにしようとはしません。 代わりに、多くのビジュアルプログラミング開発者は青写真が好きではなく、イベントシートを好むことを指摘します。

イベントシートはその表現にgdscriptを使用でき、そのようにして実際にイベントシートタイプのエンジンから来た人がそれを非常に速く学ぶのを助けます

おそらく、イベントシステムはカスタムノード作成ツールとして使用できます。

何かについて指摘したいのですが、正直なところ、イベントシートはプロトタイプ用ではないと思います。 偶数シートはプロトタイピング専用であるという考え方の問題の一部は、それらを使用するツールの多くが、プログラミング方法を知らなくても簡単に作成できるという概念を推し進めているためだと思います。 イベントシートを実際にかなりの時間使用する人なら誰でも、それが基本的なプログラミングの概念を理解する必要があるプログラミングの実際の方法であり、それを使用して完全で機能豊富なゲームを作成できることを知っています。
問題の一部は、イベントシートを使用するツールが、ゲーム開発の経験があまりないアマチュアや人々を引き付けようとして、イベントシートの技術的性質を軽視しようとすることです。 これは事実上、イベントシートのイメージを傷つけ、他のツールの使用経験が豊富な他の人にはそれほど能力がないように見えます。 また、プログラミングを理解する必要がないと言われたために何をしているのかわからないイベントシートを使用している人もたくさんいます。そのため、人々がそれを使って作成した例は、それをうまく表現していません。 それは素晴らしい例がないという意味ではありません。 それはそれが特定の先入観を発達させたというだけです。

..ハイブリッドは、その先入観を打ち破る方法かもしれません-人々がおそらくもっと深刻な口調を持っている新しい方法でそれを解釈することを可能にします。 おそらく、以前のシステムの問題を解決し、ハイブリッドがインスピレーションを得たシステムよりも優れているように見せることができるでしょう。

@prominentdetailは非常に良い点を提起します。
それに追加するために、私はこれを言うでしょう：
Godotには、イベントシートをサポートする最初の適切な3Dゲームエンジンになる機会があります。 これは、定義上、現時点で他のすべてのイベントシートエンジンよりも高くなります。
前に述べたように、これはClickteamフュージョンとConstructの両方で、ゲームメーカーでもプラグインとして以前に試みられました。 そして、それらのエンジンの編集者はゼロの3D機能を持っているので、そこには不格好な混乱があります。

Clickteamフュージョン-ホタルエンジン：
http://clickstore.clickteam.com/firefly
https://store.steampowered.com/app/267655/Firefly/
ひどいバグのあるアドオンなので、Steamでパンされています

コンストラクト2-q3d
https://www.scirra.com/tutorials/9456/building-your-first-3d-game-with-the-q3d-plugin

3Dシーンエディタを使用せずに単純な3Dシーンを設定するのが面倒なことを見てください。
https://youtu.be/VUGsTdBpRCQ?t=6m17s

IMHOハイブリッドは、両方の欠点を解決するための優れた方法のように聞こえます。

アプローチは、その価値を示し、フィードバックを得るためにイベントシートのプロトタイプを作成することです。

システムを約1時間以上テストした後、それはかなり有能であるように見えます。 そして興味深いのは、動きやヘルパー機能が追加された最も基本的なもの以外のほとんどのものを作成するのは、おそらくGDscriptと同じくらいのプログラミング知識です。

GDScriptの存在下でプログラミングを必要とする可能性があるのは、恐らくプログラミングを試すことができない人だけだと思います。

イベントシートは、特にGodot APIを使用して、プログラミングを学習するためのツールになります。 Godotにはすでに同じヘルパー関数の多くがあります。 したがって、EventSheetを実装すると、実際にGDScriptを使用できる可能性があります。
なぜなら、基本的に、EventSheetをGDScriptに変換し、コンパイル時に更新されてエンジンで使用できる別の隠しフォルダーに格納するシステムを作成できるからです。 少なくともそれは私が理解したことです。 これが最も簡単な解決策になる可能性があります。

ビジュアルスクリプティング/ブループリントの代わりにはなり得ないことがわかりますが、ほとんどの場合、列にコードを記述して理解しやすくすることはあまり視覚的ではありません。

EventSheetを使用したプログラミングの基本的な知識を持っている人がもっと面倒であることが判明しない限り、なぜそれがそのように公表されているのかわかりません。

現在、ビジュアルスクリプティング側が修正されるのを待っている間、時間があればこれを使って何かを作成しようとするかもしれません。 EventSheetの基本バージョンを実装しようとするのは楽しいかもしれません（Godot APIを学ぶのに役立ちます）。 進捗があれば、必ずここで更新してください。

イベントシートはgdscript /スクリプト言語とどのように異なりますか？

初心者の場合（コーディングよりも魅力的なもの）：

• ロジックの視覚的表現がいくつかあります-アイコン、色、および可能な限り少ないテキストを使用します
• 条件は左側の列に、アクションは右側に示されています-コーディングでは、条件とアクションの両方が1つの列にあります-他の人のロジックを読み取るときに、2つを区別するのが難しくなります。
• 長いテキスト文字列の代わりに、メソッドは単純な単語として表示されます-英語で、可能な場合は構文記号が削除されます-構文のノイズを取り除くと、読みやすくなります
• Intelisense / autocompletionは、ユーザーにAPI全体を提示します。これにより、ユーザーは利用可能なすべてのセッターまたはゲッターを確認し、必要なものをフィルターで絞り込むことができます。IDEのコーディングでの動作とは逆になります。ここで、入力を開始すると自動補完が表示され、API全体が表示されます。エンジンのドキュメントにはまだ隠されています。 また、物を見つけるための視覚的な手がかり（アイコン）もあります。 返される変数または期待される変数のタイプを直接示します
• グループ化ロジックを使用すると、折りたたみ/折りたたみ解除して移動できる独自のフォルダを作成できます。 折りたたみ可能であると判断したロジックのブロックを折りたたむ機能は、コードを整理していて、作業していないコードの一部を非表示にしたい場合に非常に便利です。

より経験豊富なユーザーの場合：

• 設定されたセルをドラッグアンドドロップすることで、イベントの実行順序を非常に簡単に変更できます。 これは何を意味するのでしょうか？ ide-でコーディングしているときに、ctrl + xとctrl + vでこれを行うことができます。 イベントシートシステムでは、論理行またはセルをある行から別の行にドラッグアンドドロップするだけで並べ替えることができます。
• すでに確立されているロジックは、色分けの上に視覚的な手がかりと左右の列のレイアウトがあるため、コードよりも視覚的に見つけて読むことができます。これは、何かをプロトタイプ化するときに非常に優れています。
• イベントシートは、デフォルトでユーザーのノードパスを自動的に処理できるため、イベントシートをまとめるときに、何かに関連するパスを把握して他のノード（親または子）にアクセスする必要はありません。 コードの柔軟性については引き続きオプションがありますが、ノードが親子関係を動的に変更しない場合は、システムがこれを処理します。
  ノードに到達するために行うのは、ヘルパーメニューからノードを選択することだけです。 これは物事をスピードアップします
• それでもgdscriptに非常によく似ています。すべての式がgdscriptであるためですが、生産性の向上が得られます。 うまくいけば、これはgdscriptユーザーが気に入るはずのことだと思います。

特典を要約する必要があるかどうかを推測します。
初心者の場合-コードは一見するとはるかに明確であり、エンジンのAPIがどのように提示され、彼らが置くロジックに視覚的なヒント（ノードのアイコン）があるため、より魅力的です。

経験豊富な方は、すべての式フィールドにgdscriptを記述できますが、プロセスの一部を高速化（コードを入力して他のノードに移動する必要がないなど）したり、ロジックをドラッグして実行を変更したりすることもできます。注文または要件（カットアンドペーストの必要はありません）

私はちょっとjavascriptのもので脇道になり、他の人がこれを試してみたらそれが大好きです:)しかし、それに戻ってきます

@mhilbrunnerは独自のシステムである必要があることに同意しますが、プロジェクトでgdscriptとブループリントを組み合わせる方法であるブループリントシステムと組み合わせることができれば素晴らしいと思います。

@blurymind
だから、あなたはそのようなプラグインに取り組んでいると言いましたか？
リポジトリの名前は何ですか？ すでにgithubにありますか？

イベントシーの方がわかりやすいことを確認できました。10〜11歳くらいで英語が苦手で（ネイティブスピーカーではありません）、英語の習得にかなりの時間と知識が必要でした。コード。

コードを書くよりも速い場合もありますが、慣れると思いつく限り速くクリックできます。

私が見る唯一の欠点は、繁体字コードを学ばなければならないときに怠惰になることです。

私はこれに取り組み始めていましたが、あなたのコードは私のものよりも進んでいるようです、私は役に立たないのではないかと思いますが、とにかくそれを試してみたいです

@Elmapul彼のリポジトリがあまり役に立たないと思います。
そして、そのような考えを持っている場合、コーディングは実際にははるかに高速です。つまり、Pythonのような言語を扱った優れたプログラマーではないということです。
EventSheetは初心者にとってより便利で寛大ですが、それはそれです。

何年にもわたってさまざまなツールに手を出してきましたので、何か言及しようと思っただけです。
私は何よりもアーティストなので、ほとんどの時間をアートの作成に費やしています。 それは私が最も時間をかけて取り組んでいることであり、私の心が強くなっていることです。 フリーランスなど、他の芸術的なことをしているときに、コーディングから長い休憩を取ることがたくさんあります。
アーティストとして、これは特定の構文パターンを必要とする特定のgamedevツールに鋭敏にとどまるのを難しくします-あなたが把握を維持するために一貫してしなければならないパターン。
したがって、アーティストとして、アーティストは構文ベースのコーディングスタイルと同じ一貫性と優先順位を持たない可能性が高いと予想されます。
イベントシートは、プログラミングを休んだときにそのこぶを回避する方法です（アーティストとして、コーディングだけで継続的な時間を費やすことはないと予想されるため）。イベントシートは、そのために簡単に戻ることができます。コーディングに慣れている構文構造とパターンのメモリが少なくて済みます。
このため、常に再学習するのではなく、生産性を高めることができるので、イベントシートを好みます。より芸術的なタスクやプロジェクトに頭を使った後、戻ってくるだけです。精神的に流れやすくなります。

..基本的に、私が強調したいのは、あなたがその職業にすべての時間を捧げ、その考え方を支持する精神的能力を構築した場合、yes-コーディングはより速くなるということです。 彼らは単にそれをタイプして行くだけです-彼らはこのライフスタイル/行動から実際に回避されることは決してありません。 他の人にとっては、これは決して現実的な選択ではありません。なぜなら、彼らは行動と実践の異なるパターンを強化した他の仕事に人生を捧げてきたからです。
そうそう..あなたはただのようになることができます..ああ何でも-あなたになるのは残念です..あなたはフルタイムのプログラマーになることにあなたの時間を捧げないなど、決して満員になることのない多くの人々を遠ざけるでしょう-時間プログラマーまたは技術的に気にされているように。 そして、それが開発者の権利であることを確認してください。
しかし、他のタイプの個人を招待し、技術的な可能性に関係なく、実際にツールを使用する人を増やしたい場合は、物事に対してよりオープンになり、好みのシステム/ワークフローに一致しない人を支援しようとするのに役立ちます、など。
イベントシートは、人が離れたり戻ったりするたびに発生するドロップアウト効果がなく、実際にゲームの開発を進めるのに大いに役立つと感じているので、私は応答し続けるだけです。私のような人が諦めるのを防ぐことはほとんどありません。 、そして彼/彼女の通常の仕事に戻るだけです。 ですから、最終的には、技術的なレベルで少し時間がかかったり、印象が少し劣ったりしても、実際にはもっと多くのことを達成できます。

@prominentdetailすべての目的と目的で、ビジュアルスクリプティングはまさにそれを実行できるため、実装が完了したら、構文を覚えるという芸術的な問題のほとんどを解決することを心配する必要はありません。

コーディングを完全に終了した後、ブループリントを使用しましたが、それでも数分以内に自然で適切な感じがしました。 ですから、ほとんどの人はそれで大丈夫だと思います。

知っている言語は関係ありません。適切にグループ化されたイベントとアクションのオプションを使用したビジュアルスクリプトは、非常に短い変数名とデータ型を入力しない限り、かかる時間よりも高速になります。

とはいえ、イベントがキーボードショートカットにマップされている場合は、もう一度「入力」する方が確かに高速ですが、それでも、標準のコードよりも最初から高速なのはイベント/アクションです（アクションと条件は複雑な関数全体を表すことが多いため） 、事前に作成されており、ほとんどの用途に柔軟に対応できます）。

私の主張は、イベントシートはどちらも学ぶのが簡単であるということです。
設計図とセットアップの高速化。

さらに、移行に優れています
実際のスクリプト言語の新しい人々。

うまく設計されていれば、イベントシートシステムは書くのと同じくらい速くなります
gdscript。 私のモックアップGIFを見ると、入力するのとよく似ています。
ヘルパーメニューフィルタリングを使用する場合は、オートコンプリートを使用してコーディングしてください。

とにかく、私はまだこれを行う方法を考えていますそしてありがたいことにgodot
gdscriptは、型付きスクリプトを取得する予定です。これは、より適切です。
イベントシートのbbcodeを生成してくれました。
たとえば、素敵なものの1つ
イベントシートシステムの式フィールドの特徴は、
期待する変数のタイプを明確に示し、さらに点灯します
有効な場合は緑色（クリックチームフュージョンを参照）。
私は現在、次のことができる式フィールドを実行する方法を理解しようとしています。
gdscriptを使用するだけでなく、私が作成したヘルパーメニューも使用します。 繰り返しますが、これはそれがどのように機能するかを実験しているだけです。 これは、使用可能なATMとはほど遠いものです。

2018年5月30日水曜日22：59Daven Bigelow、 notifications @ github.comは次のように書いています。

あなたが知っている言語は関係ありません、適切にビジュアルスクリプティング
グループ化されたイベントとアクションのオプションは、かかる時間よりも速くなります
非常に短い変数名とデータ型を入力している場合を除きます。

とはいえ、イベントがキーボードショートカットにマップされている場合は、
確かに、もう一度「入力」する方が速いですが、それでもイベント/アクションが
ゼロからの標準コードよりも高速です（アクションと条件が頻繁に発生するため）
複雑な機能全体を表し、ほとんどの用途で事前に作成され、柔軟性があります）。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/17795#issuecomment-393333602 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AGMbVT30aPs63RYwxtFqDTHWVqclenRBks5t3xZTgaJpZM4S8wyr
。

@blurymind C ++で実行することをお勧めしました。この方法を使用すると、より適切で、より完全になります。 数週間前にC ++を開始した私でも、C ++を使用して、バグ修正や新機能を作成できるようになりました。 ですから、それほど難しくはありませんが、おそらく少しです。 私はまだstackoverflowを使用する必要があります。

しかし、GDScriptを使い続けて、他の人が完全なツールに変換するためのプロトタイプを作成するだけの場合は、どんなに不完全であっても、ここでリポジトリを共有する必要があると思います。
喜んでお手伝いさせていただきます。 私はEventSystemのアイデアが本当に好きです。 そして、VisualScriptingは現在壊れているので、私がすることはあまりありません。

問題は、イベントシステムを実装するのが面倒になる可能性があることです。Godotでは、スクリプト言語として実装する可能性があります。 しかし、それはイベントマネージャーの意図ではないので、グローバルであるか、シーン全体を単独で処理できる必要があり、グループを使用して作業をセクションに分割する必要があります。
これはすべて可能であり、実装するのに問題はないはずです。

@swarnimarun新しいUIを作成したり、既存のUIを変更したりするHello Worldモジュールはありますか？
あなたを助けた良い入門チュートリアルをお勧めできますか？

いずれにせよ、私は今、ヘルパーメニューが生成するgdscript構文を型付きgdscriptに変更することを考えています。
https://github.com/godotengine/godot/pull/19264
次に、インタラクティブなイベントシートのセルインターフェイスをレンダリングするbbcodeに変換されます

このフローチャートを作成して、現時点でどのように機能するかを説明しました
https://www.draw.io/#Hblurymind％2FGodot-eventSheetPrototype％2Fmaster％2FEventSheetDiagramPlan.xml

@blurymindチュートリアルではなく、実際の練習や他の開発者から学ぶことをお勧めします。
誰も私を本当に助けてくれませんでした。 私もあまり助けを必要としませんでした。 私は物を拾うのが得意なので、すべてうまくいきました。 それでも私はまだ始めたばかりです、それは経験豊富な開発者と比較されます。

そして、あなたはGDScriptを使用してすべてのプログラミングを行っているか、C ++を使用していると思います。
デフォルトで、または開始時に何かを実行できるモジュールがないためです。 あなたはすでにそこにあるものから学ぶ必要があります。 そして、あなた自身を作成し​​ます。

GDScriptを使用している場合、およびC ++を使用している場合、型付きGDScriptへの変換は簡単である必要があり、移植はほとんど必要ありません。 そして私が知る限り、PRはいつでも統合されるべきです。 確認済みで問題ないようです。 まだ試していませんが、本当に興奮しています。

そして、現在推測させてください。あなたはおそらくget_method_list（）とget_property_list（）でGDScriptを使用しています。 ただし、シグナルとグループも使用することをお勧めします。シグナルはGodotイベントの発火メカニズムです。 EventSystemについてはよくわかりませんが、Godotでそのようなものを作成したい場合。 Godotを最大限に活用してください。

そして最後に、助けが必要な場合は、TwitterまたはDiscordで私にメッセージを送ってください。 私は今、数日間自由になります。

@swarnimarunアドオンを作成するためにgdscriptを使用していますが、イベントのトリガーなどのために、すでにシグナルが使用されています。
はい、get_method_list（）とget_property_list（）を使用してヘルパーメニューもレンダリングします

TwitterとDiscordで同じハンドルを持っていますか？

今のところ、私の計画は、c ++よりも知っているものとしてgdscriptでGUIのプロトタイプを作成することです。
私もjavascritの経験がありますが、それはここではあまり役に立ちません

入力されたgdscriptは、ヘルパーメニューが式モード用に生成するものです-リッチテキストラベルでUIをレンダリングするためにbbcodeに変換するのにちょうど良いです

@blurymindそれではとても良いです。 上記のgifではそれはわかりませんでした。 だから私はいくつかのことを想定しました。

私のハンドルはDiscordのものがSwarnimです。 そして、あなたは私のツイッターをすでに知っていると思います。

@ blurymind-すばらしい仕事です。 GDScriptと比較した場合のGodotのパフォーマンスの向上により、文字通りC ++の学習を開始しました（メトリックに応じて3〜4倍高速です。bunnymarkを参照してください）。 可能であれば、金を手に入れてC ++を使用することをお勧めします。たとえそれが仕事で学ぶことを意味するとしても、それだけの価値はあります。 C ++の感触をつかむために数週間お待ちください。よろしければ、私もお手伝いさせていただきます。

@colludium 3〜4倍速い速度は、C ++を学ぶ努力の価値がありません。 より最適化されたゲームを作成する方法を学びたい場合は、代わりにC＃を学習してください（Godotで成熟するにつれて速くなります）。 また、型指定されたGDScriptが登場したことで、GDScriptの動作が以前よりも速くなります。 C＃に近いと信じています。

C ++は苦痛です。 私を信じて。 ポインタと参照、およびコードのコンパイルは、すべて苦痛に他なりません。 大企業のゲーム開発者として未来を作りたい、大学で勉強している、またはGDScriptを完全に知っているか、プログラマーとしてプロレベルにいるほど頭が良い場合を除きます。

言語のエクスポートシステムを作成するのは面倒であることがわかっているので、GDScriptコードを動的に作成する方法を学び続けたい場合は、GDScriptコードを直接生成すると、すべてがはるかに簡単になります。
また、追加のボーナスとして、ビューコードのビューを作成し、初心者がコーディングをより速く学習できるようにすることができます。

@blurymindベースとして使用しているEventSystemのバージョンを尋ねたいので、システムのプロトタイプをC ++モジュールとして作成したかったので、少なくともベースレベルでシステムと同期させたいと思います。

@ swarnimarun-アドバイスをありがとうre：C ++。 私はJavaScriptからやってきた趣味のプログラマーなので、最小の痛み/最大のパフォーマンスの移行が私が探しているものです。 GDScriptをはるかに高速化するために計画されている改善については知りませんでした。知っておくとよいでしょう。 今、私は難問を抱えています-C＃またはGDScriptを学ぶのがはるかに簡単です...

@colludium簡単に見つけたものは何でも、背景がJavascriptであると考えて、GDScriptも動的型付けを備えていることをお勧めします。静的型付けを入力すると、完璧なコンパニオンになるはずです。
また、C ++が学習すべき言語であると考えている場合は、フォーラムのRust vs C ++ページを確認してください。

@swarnimarun私は
これが私がプロジェクトを追加したテストリポジトリです
https://github.com/blurymind/Godot-eventSheetPrototype
誰でも自由にフォークしたり、プルリクエストを行ったりできます👍

お気軽にc ++モジュールの作成を開始してください。 私がこれまでに機能しているのは、インターフェイスのコアビルディングブロックであるロジックセルコンテナです。

bbcodeパーサー（正規表現を使用するだけです）とヘルパーメニューのレンダリングは、私が個人的にそれらの動作方法を変更することを考えていますが、あなたにとって最も役立つかもしれないものです-それらは仕事と他のプロジェクトの間の私の自由な時間に一緒に打ち砕かれました。 物事はATMコードの面で混乱しているので、より経験豊富なプログラマーがいることは私にとって大きな助けになるでしょう。

残りは、スクリーンショットの目的で配置された静的インターフェイスです。

行うことが非常に重要なことの1つは、シーン内のすべてのノードとそのパスを追跡する編集可能な辞書を作成することです。したがって、静的ノードパスの代わりに、ヘルパーメニューで辞書からのパスを使用するgdscriptを生成する必要があります。それらを自動的に更新し、ノードがユーザーによって削除され、イベントシートのロジックで見つからない場合は、再リンクできます

いずれにせよ、基本的なものであっても、何かあれば共有してください。 私はもう少しC ++を学び、モジュールとしてそれを書くことに参加しようとします:)

@blurymindついに！ Godot Engine 3.xのビジュアルスクリプティングは役に立たないことを非常に明確に理解している人（初心者には複雑すぎ、専門家には役に立たない）。

GDevelopイベントシステムは素晴らしいです！ これは、完全な2Dゲームテンプレートを作成し、後でGDScriptを介してより高度な機能を追加する場合に特に便利です。 これにより、Godotゲームエンジンはより魅力的で人気があり、広く普及するでしょう！

私はGodotEngineが大好きですが、モバイルデバイス用の2Dゲームを作成することは、最も簡単で直接的な解決策ではありません。 簡素化されたシステム/イベントシステムでさらに多くのことを提供できます）。 Godotには優れたアニメーションエディタがあり、それは本当に素晴らしく機能的です。何千行ものコードを記述せずに2Dプラットフォーマーを作成したい場合にのみ、よりユーザーフレンドリーなシステムが必要です（基本的なスーパーを作成するのに役に立たないと思います。 NES用のスタイルテンプレートマリオブラザーズ）。

私は@blurymindのアイデアは素晴らしいであることを見つけて下さい！ Godotコミュニティは非常に成長しており、私はそれに満足しています。 イベントシステムが次のリリースで実装されることは間違いありません。 ビジュアルスクリプティング（繰り返します）は、現時点ではまったく役に立ちません（チュートリアルも見つからず、Webで見ることができるものからは誰も使用していません）。

ご挨拶、そして素晴らしい仕事をありがとう！

@XenonCoderあなたは最後に興味深い点を指摘します

ビジュアルスクリプティング（繰り返します）は、現時点ではまったく役に立ちません（チュートリアルも見つからず、Webで見ることができるものからは誰も使用していません）。

これは、何かが本質的に使用するのが難しい場合の良い例であり、後でそれが行われるべきではない理由を説明するための自己達成的予言として使用されます（例：「SEE！誰もビジュアルスクリプトを望んでいない！」）、それが単に魅力的または初心者に優しい方法で行われなかったことを認めるのではなく。

フォロースルーがなければ、それは確かに役に立たないので、それは半分の贈り物のようなものです。

十分に文書化されていない、または例が提供されていないエンジンへの追加についても同じことが言えます。

@bigelod絶対にあなたに同意します。 あなたが私の意図を誤解しなかったことを嬉しく思います、そしてあなたは私が何を意味するかを完全に理解しました。

Godotゲームエンジンは素晴らしかったです！ それは信じられないほどの可能性を秘めています。 2Dゲームを作るために、それはナンバーワンです！ 何年もの間、私は既存のすべてのゲームエンジンとフレームワークを試してきましたが、Godotは素晴らしいことを約束するプロジェクトであると絶対に確信できます。

たとえば、新しいビジュアルシェーダーは非常に見栄えがよく、将来に向けて素晴らしいことを約束します。 私はいくつかのテストを行いましたが、アイデアとして非常に気に入っています。 しかし、ビデオゲームのロジックを実現するために、ビジュアルスクリプティングは罠です。

チュートリアル、ドキュメント全般、そしてとりわけBuild 3、GDevelop、Game Maker Studio 2のスタイルの簡略化されたシステムが必要です。当初は主に2Dゲームを実現するためのアドオンとして、将来的には改善され、正式に実装されます。 これは簡単な作業ではなく、Godot Game Engineを愛好家、学生、ビデオゲームの専門家にとって理想的なソリューションにするためのアイデアにすぎないことを理解しています。

皆さん、ありがとうございました。

ゲームエンジンの周りに店ができました。 アドオンを商用ベースで作成するのが普通になりました。 含む構成の場合。 最後の重要なC2プラグインはすべて商用です。 これは、市場の形成だけでなく、製品の複雑さ、互換性エラーのテストと修正に多大な時間を費やしたことによるものです。
私は... Godotは別のニッチにあり、Juanが単純化されたプログラミングのアプリケーションを作成してサポートしていなければ、他の誰かがこの作業を終わらせる可能性は低いでしょう。

私はKlik'n Play、The Games Factory、Multimedia Fusionで育ち、最近はConstruct2を使用しています。 イベントシートを使用したビジュアルスクリプティングは、相互に接続されたブループリントスタイルのステートマシンノードを使用する場合とはまったく異なります。イベントシートに慣れている人にとっては、プログラミングの最も簡単で効率的な方法です。 イベントシートを使用してGoDotでスクリプトを作成する方法を喜んで歓迎します。

gdscript、ドキュメント、プラグインAPIにいくつかの制限があり、アドオンとしてのビジョンを完全に実行できません。 機能状態になったとしても、おそらく制限があります。

私がそこにたどり着くのに非常に役立つことの1つは、オプションの型付きgdscriptです。これが、godotに入るまでこれに取り組むのをやめた理由です。 これでマージされました。時間があるときはいつでも、概念実証アドオンとしてこれに取り組むことに戻ります。

アイデアは、イベントシートの生成されたgdscriptが入力されるということです。 入力されたデータは、イベントシートのGUIに、どのタイプのパラメーターが期待されるかに関する追加のコンテキストデータを提供します。

適切なc ++モジュールまたはgdnativeアドオンとしてこれに関心がある場合は、誰でも自由にこれを実装できます。

何人の人がそれを望んでいるかを見ると、これをgodotの一部にすること、または少なくともgodotの一部として機能させることほど幸せなことはありません。

残念ながら、私にはフルタイムの仕事があり、現時点では私の時間の大部分を占めています:(
更新が遅くなってすみません

この議論に追加するために、ここですべての人に、ノード接続ベースのビジュアルプログラミングアプローチを使用したビジュアルスクリプトエンジンの素晴らしい例を紹介したいと思います。
https://youtu.be/b8GZ21YCh50?t=4m12s
https://www.reddit.com/r/unrealengine/comments/4nt0up/need_help_debugging_this_blueprint/にいくぶん似てい

Gamesfromscratchが提示する代替案に注意してください

この設計提案でここで避けたいことの1つは、ノードがすでにgodotで実行している動作の範囲外の動作を事前定義することです。また、多くのタブとGUIを作成します。
godotイベントシートはgdscriptコードとまったく同じように機能する必要があります-より触覚的/視覚的な方法でのみ
godotの上に使いやすいゲームエンジンを構築しようとするのではなく、godotの機能をよりアクセスしやすく、より速くまとめることができます。

多分ビジュアルスクリプトでそれはあなたのタッチスクリーンでさえアクセス可能でしょうか？

実際、イベントシートスタイルのビジュアルスクリプトはタッチに非常に適しています
画面

2018年8月1日水曜日06：46Elmapul、 notifications @ github.comは次のように書いています。

多分ビジュアルスクリプトでそれはあなたのタッチスクリーンでさえアクセス可能でしょうか？

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/17795#issuecomment-409456475 、
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AGMbVdqoa3AdMNfiM986iwIpNeqzqjVLks5uMUCvgaJpZM4S8wyr
。

@blurymindプラグインシステムでこれを改善する必要がある場合は、問題を開いてください。他のプラグインが特に何かを必要としていたため、すでに変更されています。

それは素晴らしいアイデアです！ 私はこれらの青写真を本当に理解したことはありませんが、イベントベースのアプローチは、特にWarcraft III WorldEditorなどの改造コミュニティでよく知られています。

画面の例：


カテゴリとトリガーのクリーンリストは、少なくとも私にとっては見栄えがします。 最初の投稿の画面よりも簡単に認識できます。

それはあなたが言ったのとほとんど同じですが、アクションとして条件を追加し、それらの中にさらにアクションをネストする可能性があります。

@Wiadomy
この画像は小さすぎて何も表示/読み取りできません

@Elmapul
申し訳ありませんが、何か問題がありました。 更新しました。

@Elmapul私のコンセプトアドオンはまだネストを実行できませんが、私が提案しているイベントシートにはネストが含まれています。 gdevelopとconstructの両方が行のネストをサポートします-必要に応じて今すぐ試すことができます:)

@blurymindはついにイベントシートの実装に取り​​組み始めました。研究論文やその機能と実装に関する記事など、その実装について詳細に説明しているリソースを知っていますか？
それは大きな助けになります。 Godotのイベントシートシステムの設計を開始します。
なぜなら、Godotの動作はまったく異なり、シグナルと呼ばれるものがあり、これも統合する必要があるため、ConstructまたはGDevelopメソッドを使用するのは正確ではありません。

一般的な情報が必要な場合は、ここに構成のイベントシートに関する情報があります： https ：
異なる企業は、イベントシートを互いに少し異なる方法で実装しているため、それぞれに独自の癖があります。
構成方法のさまざまな部分をまとめたビデオを作成できるかもしれません（これが現在のところおそらく最良の方法であるため）。研究論文は知りませんが、それを見つけるのは興味深いことです。

@prominentdetailリンクをありがとう、コンストラクトシステムのようにイベントをより使いやすくする方法を確認する必要があるようです。
私の最初のアイデアは、 @ blurymindのアドオンに似たものを

では、イベントシステムに使いやすさを高めるために追加する別のAPIがあるか、GDScriptのラッパーになるべきか、皆さんはどう思いますか。

@swarnimarunが本当に最善の方法は、エンジンをしばらく使用して、これをよりゴッドな方法で実行する方法を考えることです。 コンストラクトクラシックとgdevelopは素晴らしい例です。

私の見解では、godotのシグナルは組み込みの関数イベントと同じです。 信号の接続はすでにgodotで視覚化されています:)

イベントシートからのシグナルの設定は、ヘルパーメニューで使用できるアクションにすぎません。内部では、セッターメソッドにすぎません。 したがって、gdscriptの場合と同じになります。

ノードに組み込みメソッドが含まれている場合は、[組み込み関数の追加]をクリックしたときに表示されるメニューで使用できるはずです。

シンプルに保ち、型付きgdscriptのラッパーにする必要があると強く思いますが、それが不可能または実用的でない場合は、別のAPIである可能性があります。 godotに実装されている現在のビジュアルスクリプトが抽象化としてどのように機能するかを調査する価値があります。

コンストラクトでカスタム関数がどのように作成されるのか疑問に思われる場合は、ここにそれらのドキュメントへのリンクがあります
https://www.scirra.com/tutorials/823/creating-function
:)

@blurymind GDScriptのラッパーとして保持する方が実際にははるかに簡単で、作業もはるかに少なくて済みますが、イベントシートの機能の多くは、少なくともそのようにすると面倒になります。それが私が理解している方法です。
ですから、初心者でも同じように保ち、必要に応じて後で追加すると思います。

@swarnimarunこれを試してみてくれてありがとう

最大の問題は、VisualScriptが、Godotのスクリプトを作成するために使用できる他のすべての言語と同様に、関数、変数、シグナルなど、GDscriptの機能にできるだけ近づけようとしていることだと思います。 多くの機能が失われるため、イベントシートシステムではこれを実現できませんでした。 （私はそれが可能であることを知っています、しかしそれは速く肥大化するでしょう）

@Jummitは、完全にできることを除いて、Construct2を試してください。標準コードよりも肥大化することはありません。

そしてそれはGDscriptのすべての機能を持つことができますか？ では、何を待っているのでしょうか。 Godotでイベントシートを入手しましょう！

@Jummit godotには、「ノード」の形式で必要なすべての機能があります

godotの「ノード」はconstruct2の「動作」のようなものです
Construct2のプラットフォーマーの動作は、それほど強力ではないkintematicbody2dノードのようなものです:)
すべてを最初からスクリプト化する必要はありません。

さらにクールなのは、これらのノードを親子関係にネストできる一方で、動作がモジュールのように単一のゲームオブジェクトにアタッチされるように制限されていることです。

イベントシート機能が組み込まれ、コミュニティからのいくつかの追加プラグインを備えたgodotは、construct2または3よりも高速なプロトタイピングエンジンになる可能性があると強く信じています。
未開拓の可能性を秘めています。

C2でのプロトタイピングの速度は、主にセルの対話性によって決まります。セルはドラッグ、コピー、および条件オブジェクトを含むホットキーで変更できますが、ドロップダウンリストはエラーをほぼ完全に排除します。

@swarnimarun 、私はさまざまな構成要素の一般的な概要を作成しました： https ： v = ioz3gHtA-Lg
それは基本的に、構造にあまり精通していない人がそれを感じることができない人のためのものです。 すべてを計画していなかったので、色々なことを見落としていたのかもしれませんが、基本的な理解はあるかもしれません。 いろいろなことをぶらぶらするのではなく、ワークフローの側面をアピールするために、実際にもっと開発を行っているビデオをいくつか作成する必要があります。 何かカバーしたり、調べたりしたい場合はお知らせください。

それは私にとってf ** kのように醜いです。 つまり、ビデオのスクリプトです。

@Wiadomyそれはそのビデオよりも使用する方がはるかに優れています。 最終的には、イベントシートは、ノードベースのシステムよりも常にすっきりと読みやすくなります。

@Wiadomy 、画面の記録のため、1台のモニターを使用し、テキストサイズも比較的大きくする必要がありました。 コンストラクトは、長い連続した式を入力した場合に画面スペースのためにいくつかのものがまとまる可能性があるように、テキストをフォーマットします。
その一部を解決するには、テキストをズームアウトし、別のモニターを使用してスペースを解放し、イベントをより適切に一覧表示することもできます。
式を少し分割して、よりきれいにすることもできますが、これは私の古いプロジェクトであり、もう少し実験的です。
また、イベントシートの構造の視覚的な手がかりとパターンに精通しているため、イベントのさまざまな部分すべてを簡単に追跡できます。 このような標準的な構造を持つことは、あらゆるプロジェクトに適応できるという点で非常に役立ち、ワークフローが非常に高速になります。

このプロジェクトは今死んでいますか？

@ Amr512死んでいるとは思わない。 この機能をgodotに導入したいという要望は確かにたくさんあります。
@reduzは最近ツイッターでgdevelopに興味を持っています
https://twitter.com/reduzio/status/1085206844275081218

しばらくアドオンに取り組んでいませんでしたが、実際に行ってgdevelop自体に貢献し始めることにしました。これは、イベントシートがどのようにプログラムされているかを学び、有料の代替としてより良いものにするためです。オプション。
https://github.com/4ian/GDevelop/

いくつかの大学はプログラミングコースを教えるためにgdevelopを取り上げ始めました
https://github.com/4ian/GDevelop/issues/882

私のバグのあるgodotアドオンは現在、プレゼンテーションのみを目的としており、機能させるには多くの作業が必要です。 もちろん、誰でも自由にフォークして、さらにプッシュしようとします。
私のアドオンに現在欠けている大きなものの1つは、イベント行のソート可能なツリーGUI要素です。 また、イベントシートを実際にgdscriptにレンダリングする機能もありません。また、構文のオートコンプリートと色付けを備えた適切な式テキストエディターもありません（構文に標準のgdscriptを使用するという考え方です）。 イベントシートを作成するための多くの重要な要素が欠落していますが、主な目標は、式の構文にイベントシートをgdscriptと組み合わせて使用​​する方法を示すことです。 この2つは、経験豊富な開発者であっても、ゲームのプロトタイピングに非常に強力な組み合わせになると思います。

@blurymindあなたのプロジェクトにチケットを残しました（Godot 3.1beta3のエラー）。
私はそのアイデアが大好きです。

偶然この問題に遭遇しましたが、このようなものが他のエンジン/フレームワークですでに一般的に使用されていることにまったく気づかなかったので、ちょっと自分で書く必要がありました。 👀

ルール=イベント
イベントシート=スキーム

以前の実装では、かなり「低レベル」のプロパティチェックとそれぞれのアクションを使用していましたが、この種のシステムは、より「高レベル」の条件/アクションベーススクリプトを拡張することで、ゲームプレイの「ビルディングブロック」を定義するのに実際に役立つと思いました。抽象化のレベル」。 それが、私が最初に「ルール」という用語を選んだ理由です。

これを最大限に活用するには、ゲームプレイとゲームフレームワークがすでに確立されている必要があります。そのため、コーディングせずにゲームを作成するためのすぐに使えるエクスペリエンスは提供されませんが、実際には、さまざまな方法で既存の機能を組み合わせて効率的に整理し、プレーンなGDScriptを使用してさまざまな条件とアクションで新しいルールを作成するだけです。

そして、ええ、プレイヤーがモッディングを介して独自のゲームモード/ミッション/チャレンジを作成できるようにすることは、そのようなシステムを使用するもう1つの理由です。

@Xrayez gitリポジトリを共有できますか？ 私の実装がきめ細かすぎるのは正しいと思いますが、gdscriptとgodotのAPIがどのように機能するかは真実です。
また、スクリーンショットを見るだけで、要点を見逃していると思います。3列ではなく2列である必要があります。 左=条件、右=アクション。 また、セル間でイベントをドラッグアンドドロップしたり、行をドラッグアンドドロップしてネストしたりできる必要があります。 これを構築するには、ソート可能なツリーを使用する必要があります。 gdevelopとconstructを試してみると、これらのイベントシートがとても素敵な理由がよくわかります。

おそらく、私の実装はDSLに似たものと見なすことができるので、そこで違いが生じる可能性があります。 多くのルールは、特定のゲームプレイ要件に合わせて調整された関数のサンドボックス化された実装にすぎません。 本質的に、条件とアクションは、子クラスに実装する必要のあるメソッドを使用して、これらの小さなスクリプトを継承するだけです。

class_name SchemeCondition extends Node

func is_met(object): # override
    return true

class_name SchemeAction extends Node

func perform(object): # override
    pass

ルールは、これらの条件とアクションの単なるコレクションであり、すべてまたはいずれかの条件が満たされているかどうかに基づいて実行されます。実際には、それほど凝ったものではありません。

コーディングのようなものに貢献して実装する人々は、コーディングなしのプログラミングの魅力をすべて理解しているわけではありませんが、実際には他の多くの人々がそれに興味を持っています。

Construct、Gdevelop、Stencyl、Game Maker、Playmaker、Bolt、Fungus for Unity、Unrealのブループリント、CryEngineのフローグラフとSchematycなど...

非コーダー向けの多くのツールが作成され、使用されています。 これらのおかげでたくさんの良いゲームが作られています。
たとえば、HollowKnightはplaymakerで行われました。

Dreamsのようなものでかなり騒がしいものもあります。

この種のツールは、多くの魅力とアクセシビリティをもたらし、したがって、新しい人々をGodotにもたらします。

私は最近、このようなドロップダウンを介してイベントシートに新しい指示を追加する方法をgdevelopに実装しました

これは、godotでうまく機能すると思うようなものです。

リッチテキストラベルを使用して各セルをレンダリングします。これらのセルは左右の列にネストされ、行の子になります。 行はソート可能なツリーによって管理されます。 各行には実際のgdscriptが含まれており、インタプリタはサムネイルとクリック可能な領域を使用して式を入力する簡単な短い説明にレンダリングします。
これは実際にゲームメーカーが行うことです。 それらのビジュアルプログラミングデータは、実際のgmlとして保存されます。

gdscript拡張機能として実行を開始したときに見つけたトリッキーな部分は、式フィールドを実行することでした。 入力フィールドにコードエディタを配置して、オートコンプリートを実行させるにはどうすればよいですか？ 完了と検証のコンテキストをどのように提供しますか？ 検証済みのオートコンプリート式フィールドがないと、これは水中で死んでしまいます。

これをgodotで構築するためのすべてのUIパーツがありますが、文字通り、経験豊富な開発者が1人もそれに対して何かをしているわけではありません。 私はこれまでに行われた作業を見たことがありません

とにかく、私のc ++の知識がもっと良ければ、試してみたでしょう:)しかし、私はjavascriptを知っているので、私の貢献は代わりにgdevelopに行きます

godotでイベントベースのソリューションを見たいです。 過去にgodotを試しましたが、ワークフローに慣れることができませんでした。 ゲームを開発する場合、私の心はイベントシートに適しています。

私は今プログラマーであり、エンジン開発にも取り掛かっています。 しかし、私はまだかなり自信を持ってイベントシートを保証することができます。

構成2は、実際、高校で受けたクラスを通じて、多くの基本的なプログラミング概念に初めて触れたものです。 これにより、学習プロセスが大幅に簡素化され、迅速化されたと感じています。エンジン全般とプログラミング全般の両方で、イベントシートからの移行で完全に失われたとは感じられなかった実際のコードに十分に密接に変換されています。通常の古いテキストスクリプトに。 これを100％確信することはできませんが、代わりにスパゲッティタイプのビジュアルスクリプティングであったとしても、これらの利点のどちらも同じ程度に得られたとは思いません。

しかし、2つの異なるビジュアルスクリプトシステムを維持することはおそらく悪い考えであることに同意します。 とはいえ、すでに手に入れているからといって、現在のシステムに固執するべきではないと思います。 データが許せば、他のシステムへの切り替えを本当に検討すべきだと思います。 つまり、イベントシートシステムが現在のシステムと比べてどれだけ親しみやすいかをよりよく理解するように努めるべきだと思います。 ビジュアルスクリプティングの目標は、通常のスクリプティングに慣れていない、または自信がない人にとってエンジンをより使いやすくすることです。 堅実なビジュアルスクリプティングシステムは、Godotの親しみやすさに大きな違いをもたらす可能性があり、そうでなければGodotを考慮しなかったであろうより多くの人々のサポートと採用を得ることを意味する可能性があります。

実際、私が最初にコンストラクト2から切り替えた主な理由は、すでに3Dに移行したかったからです。 Unity、Unreal、Godot、Amazon Lumberyardを試してみましたが、開いて使用するのが簡単で、インポートプロセスが良くなったという理由だけで、Godotを使用することになりました。 しかし、Godotがイベントシートスタイルのシステムを持っていたとしたら、私はおそらくすぐにGodotをデフォルトにしたでしょう。 確かに、個人的には実際には違いはありませんが、これは、Godotをプログラマー以外の人（つまり、新しい/意欲的なゲーム開発者のかなりの部分）にできるだけ友好的にすることです。

現在非表示になっている112の投稿を読んでいないので、繰り返したり見逃したりした場合はお詫びしますが、アイデアのプロトタイプを作成するか、テストして検討することに完全に興味があります。

データが許せば、他のシステムへの切り替えを本当に検討すべきだと思います。 つまり、イベントシートシステムが現在のシステムと比べてどれだけ親しみやすいかをよりよく理解するように努めるべきだと思います。

現在のビジュアルスクリプティングシステムのメンテナはすでにほとんどいません。 私たちの生涯で完全な切り替えが完了することはないと思います：slightly_smiling_face：

現在のビジュアルスクリプティングシステムのメンテナはすでにほとんどいません。 私たちの生涯で完全な切り替えが完了するとは思いません🙂

最初にイベントシートの実用的なプロトタイプを入手したとすると、コードはすでにほとんど完成しているので、代わりにそのシステムに切り替えるかどうかが問題になりますよね？

また、Construct 2から始めて、イベントシートが2を解決するのに最適であることがわかりました。
問題：

• ビジュアルスクリプティングのように、あらゆる可能性を公開します
  module / plugin / add-on / function、これは新しいコードを学ぶのに非常に便利です。
  ビジュアルノードはかなり速くスパゲッティコードに変わります（私はブレンダーの男です、
  コンポジターとシェーダーのスパゲッティについて知っています）。
• イベントシートはRestAPIの闊歩のようなもので、十分に文書化されたものから始めます
  イベントシートのドロップダウンメニューに入力するコードを使用すると、クリーンなGUIを取得できます
  あなたのコードを消費する方法、あなたは厄介になることで拡張することができます、そしてあなたは
  それからコードを生成します（Construct2からのJS）、したがって私の質問：
  それからコードを生成しますか？

はいの場合、使いやすさのために、イベントシートを優先する必要があると思います。
全員と最適化された低レベルのコード生成。
Godotを使用してpython / C＃/ ... APIをクリーンなセットに変換できる場合
イベント、次にユーザービルドイベント、そしてGodotがそれからコードを生成します。
非常に難しいユーザーの問題を解決する：単純なUIからコーディングする方法を学びます。

イベントシートがすべての問題を解決するわけではないことは知っていますが、少なくとも500をコーディングできます
視覚的に失われることなくスプレッドシートで行っているようなイベント
どこにでもリンクします。

7時44分PMジェイの水、2020年4月8日に[email protected]書きました：

現在のビジュアルスクリプティングのメンテナはすでにほとんどいません
システム。 私たちの中で完全な切り替えが完了することはないと思います
生涯🙂

イベントシートの実用的なプロトタイプを入手したと仮定すると、コード
すでにほとんど行われているでしょう、それは私たちが
代わりにそれに切り替えたいですよね？

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/17795#issuecomment-611096608 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAAP6LM4PU6RYLO5NK5IL23RLSZWHANCNFSM4EXTBSVQ
。

私はConstruct2を使い始め、最終的にJavaScriptを使用したプラグインの開発に移ったので、イベントシートが私の心の中にあります。 それらは、初心者にとって簡単で直感的であり、各クラス（プラグイン）で使用可能なメソッド（アクションと条件）を簡単に視覚化することによる魔法のほとんどがありました。 正直なところ、VSCodeのGDScriptは今と同じように優れており、完全なインテリセンスとオートコンプリートによって生活が楽になります。 私は2年前はこのアイデアの大ファンでしたが、今では考えが変わりました。 むしろ、Godotの開発ヒーローが他のエンジンの改善を追加することに時間と労力を集中させたいと思います。

それからコードを生成できますか？

もっと調べなければならないのですが、正直なところ、そうするのはかなり簡単だと思います。実際、それがおそらく最善の方法です。 つまり、イベントシートスタイルのものを処理する最良の方法は、基本的に、通常のgdscriptファイルのグラフィカルフロントエンドとして機能させることだと思います。 イベントシートエディタで実行されるアクションは、gdscriptファイルを編集するだけです。 たとえば、イベントシートエディタでブロックをある場所から別の場所に移動すると、基本的には、gdscriptファイルへの仮想カットアンドペーストのように機能します。 また、任意のgdscriptファイルは、スクリプトエディターまたはイベントシートエディターのいずれかで表示および編集できます。 これは、使いやすさの観点からも実装の観点からも、それを行うための最良の方法のように思われます。 そうは言っても、私はまだエンジン開発についてあまり知識がないので、間違っているかもしれません。

むしろ、Godotの開発ヒーローが他のエンジンの改善を追加することに時間と労力を集中させたいと思います。

私はほとんど同意します。 これを実現する理想的な方法は、実用的なプロトタイプを一緒に試してみて、そこからコミュニティがメインのビジュアルスクリプトシステムとして切り替える価値があるかどうかを判断することです。 決定が下されるまで、または少なくともそれに近いまで、私はこのアイデアの主な開発時間を求めません。

私もGdscriptやGodotに参加していません。
しかし、私がVS Code拡張機能として開発したものも、このように幅広い方向に進んでいます。
（https://github.com/j2l/blocklight）。
コードのチャンクを操作して視覚的にコードを理解する
変数と結果（ほとんどのビジュアルスクリプトのノード、または色）をリンクする
私の拡張では）多くの人にとって欠けているコーナーストーンです。
実際、私たちはコードを学び終えたときに理解しますが、
すべてを取得する前に、変数とチャンクのリンクを確認してください
コード。
コーディング前の設計:)

20:08ジェイの水、2020年4月8日に[email protected]書きました：

それからコードを生成できますか？

もっと調べないといけないのですが、正直、きれいだと思います
そうするのは簡単で、実際、それはおそらくそれを行うための最良の方法です。 あれは、
イベントシート風のものを扱うのに一番いいのは基本的に
通常のgdscriptファイルのグラフィカルフロントエンドとして機能させます。 行動
イベントシートエディタで取得すると、gdscriptファイルを編集するだけです。 引っ越し
イベントシートエディタのある場所から別の場所へのブロックは基本的に
内部的には、gdscriptファイルへの仮想カットアンドペーストのように動作します。 と
gdscriptファイルは、スクリプトエディタまたはで表示および編集できます。
イベントシートエディタ。 これは、両方からそれを行うための最良の方法のようです
使いやすさの観点と実装の観点から。 それは私が
エンジン開発についてはまだあまり知識がないので、誤解されるかもしれません。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/17795#issuecomment-611108712 、
または購読を解除する
https://github.com/notifications/unsubscribe-auth/AAAP6LN7GFGSBDZ537XXA6DRLS4Q5ANCNFSM4EXTBSVQ
。

通常のGdscriptファイルを生成するというアイデアが大好きです。 学ぶのに本当に素晴らしいでしょう

私がゲームを作り始めたとき、Klik＆Playのイベントシステムは、プログラミングロジックに頭を悩ませるための本当に素晴らしい方法でしたが、それでも私はそれに戻るのが大好きです。

通常のGdscriptファイルを生成するというアイデアが大好きです。 学ぶのに本当に素晴らしいでしょう

私がゲームを作り始めたとき、Klik＆Playのイベントシステムは、プログラミングロジックに頭を悩ませるための本当に素晴らしい方法でしたが、それでも私はそれに戻るのが大好きです。

これは、現在のスパゲッティシステムに比べて最大の利点の1つである可能性があると思います。その設計により、プログラミングやgdscript / godotのAPIを簡単に学ぶことができます。

ここの何人かの人々はコメントしました-しかしなぜそれをするのをわざわざするのか-それはプレゼンテーションのスクリプティングにあまりにも似ています。
それに対する私の答えは-正確に。 あなたはスパゲッティを学びます、あなたはスパゲッティを残されます。 イベントシートを学び、gdscriptが何を生成するかを確認し、それらの式フィールドを使用することで、gdscriptを理解できます。

実行順序とコードの読み方について説明します。

ゲームメーカーでGMLへの変換が何をするかを見る
https://docs2.yoyogames.com/source/_build/3_scripting/1_drag_and_drop_overview/changing_dnd.html

本当に面白いblurymind！ 私も同じ考えを持っていて、これを完全にサポートしています。
私はまだClickteamFusion 2.5の拡張機能を作成していますが、Fusionに追加したいものはすべてGodotにあります。
必要なのは、開発を容易にするために、Godotにもう1つの抽象化レイヤー（イベントシート）を配置することです。
スレッド全体を読んだわけではありませんが、Godotのビジュアルスクリプティングと他のゲームエンジンのイベントシートの主な違いは、ビジュアルスクリプティングはコードの「単なる」ビジュアルビューであり、イベントシートは簡略化されたビューのコード。 それはより人間が読める形式であり、1行に数行のコードが必要なものを因数分解し、信号/スロットのリンクは自動的に行われます。
実際、いくつかのテンプレート（事前定義されたシーン）を抽象CF2.5組み込みオブジェクトに追加し、それでもGDScriptを使用すると、ほとんどの作業が実行されますが、イベントシートを使用すると、CF2.5で実行しているよりもGodotで効率的になります。今。

本当に面白いblurymind！ 私も同じ考えを持っていて、これを完全にサポートしています。
私はまだClickteamFusion 2.5の拡張機能を作成していますが、Fusionに追加したいものはすべてGodotにあります。
必要なのは、開発を容易にするために、Godotにもう1つの抽象化レイヤー（イベントシート）を配置することです。
スレッド全体を読んだわけではありませんが、Godotのビジュアルスクリプティングと他のゲームエンジンのイベントシートの主な違いは、ビジュアルスクリプティングはコードの「単なる」ビジュアルビューであり、イベントシートは簡略化されたビューのコード。 それはより人間が読める形式であり、1行に数行のコードが必要なものを因数分解し、信号/スロットのリンクは自動的に行われます。
実際、いくつかのテンプレート（事前定義されたシーン）を抽象CF2.5組み込みオブジェクトに追加し、それでもGDScriptを使用すると、ほとんどの作業が実行されますが、イベントシートを使用すると、CF2.5で実行しているよりもGodotで効率的になります。今。

私はマルチメディアフュージョンと呼ばれていた頃はCFを使用していましたが、英語を話さない子供として学ぶのは簡単でした。それを使って練習した後は、何をしているかによって、非常に速くすることができます。入力するよりも速くなります。
コンストラクトとCFは、優れたビジュアルスクリプトがどのように見えるかを示しています（gdevelopがそこに到達しています）

ありがとう
私はこの素晴らしいアイデアを支持します
彼らはコンストラクト2が引退す​​ると言います！
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

イベントシステムのオープンソース化のためにコンストラクト2の開発者と交渉し、godotやunityなどで使用できるのではないかと思います。
コンストラクト2イベントシステムが未使用の棚で無視されているのは損失です

ありがとう
私はこの素晴らしいアイデアを支持します
彼らはコンストラクト2が引退す​​ると言います！
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

イベントシステムのオープンソース化のためにコンストラクト2の開発者と交渉し、godotやunityなどで使用できるのではないかと思います。
コンストラクト2イベントシステムが未使用の棚で無視されているのは損失です

godotでconstruct2のコードを使用できるとは思えません。これらは完全に異なるコードベースです。

オープンソースの代替案に対する最善の策は、gdevelopに移行することです
https://github.com/4ian/GDevelop

この発行チケットは間もなく終了する可能性が高いため、godotのこのイベントシートに関心がある場合は、すぐに別の場所に移動する必要があるかもしれません：）（またはgdevelop）

この発行チケットは間もなく終了する可能性が高いため、godotのこのイベントシートに関心がある場合は、すぐに別の場所に移動する必要があるかもしれません:)

何？ どうして？

@TheGoklayeh機能の提案をgodot-proposalsに移行しているため、閉鎖される可能性があります。

そうは言っても、 @ blurymindは最初の投稿を編集して提案テンプレートに一致させることができます。 次に、この問題を提案リポジトリに移動できます。

イベントシートを利用した3Dエンジンが本当に必要です。

ありがとう
私はこの素晴らしいアイデアを支持します
彼らはコンストラクト2が引退す​​ると言います！
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505

イベントシステムのオープンソース化のためにコンストラクト2の開発者と交渉し、godotやunityなどで使用できるのではないかと思います。
コンストラクト2イベントシステムが未使用の棚で無視されているのは損失です

それは彼らのビジネスを台無しにするかもしれません。 さらにクリックチーム。

ありがとう
私はこの素晴らしいアイデアを支持します
彼らはコンストラクト2が引退す​​ると言います！
https://www.construct.net/en/blogs/construct-official-blog-1/sunsetting-construct-1505
イベントシステムのオープンソース化のためにコンストラクト2の開発者と交渉し、godotやunityなどで使用できるのではないかと思います。
コンストラクト2イベントシステムが未使用の棚で無視されているのは損失です

それは彼らのビジネスを台無しにするかもしれません。 さらにクリックチーム。

何かが彼らを殺すなら-クリックチームは彼らのソフトウェアへのアップデートの欠如によるでしょう（最後のものは2019年にあります）、Scirraは彼らのユーザーに毎年支払うか取得することを強制するソフトウェアレンタルライセンスに切り替えることを強制するでしょうロックアウトされ。 どちらの会社にも欠陥があり、彼らのコミュニティはソフトウェアに何が起こるかを制御できません。 これがオープンソースの魅力です

@TheGoklayeh機能の提案をgodot-proposalsに移行しているため、閉鎖される可能性があります。

そうは言っても、 @ blurymindは最初の投稿を編集して提案テンプレートに一致させることができます。 次に、この問題を提案リポジトリに移動できます。

誰かが私の代わりにそれをすることができますか？ :)
この機能が（拡張機能ではなく）ネイティブにgodotに到達することへの期待を失いました。 スパゲッティアプローチは、godotユーザーと開発者に勝ちました

@blurymindこの提案をサポートしなくなった場合は、閉じる方がよいと思います。 イベントシートアプローチに取り組むことに興味のある他の誰かが、 godot-proposalsに関する新しい提案を開くことができます。 （非常に多くの作業が必要なため、技術的に誰もそれを実行できない場合、提案を開くことは意味がないと思います。）

それでも、このスレッドには多くの貴重な議論が含まれているので、とにかくありがとう：slightly_smiling_face：

この提案は非常にばかげていると思います:)
しかし、コンストラクト3エンジンでイベントシステムを作成できますか？！
ゲームはコードを生成し、それらをテキストファイルでnode.js経由でgodotエンジンに送信できると思います

これはばかげています..しかし、コンストラクト3はイベントシステムを作成するのに十分強力だと思います
これは現時点では何もないよりはましです

はい、少なくとも私たちは、godotでそのようなシステム、現在のビジュアルコーディングシステムに対するその利点、およびそれを使用している他のエンジンについての意見についてのアイデアに到達することができたと思います

私は正直に言って、GDevelopがそれをどのように行うかが好きですが、Godotがイベントスクリプトを実行することは、私が今（最近）好んでいることではありません。
一度実装してみたところ、Godotにはビジュアルスクリプティングシステムから直接公開できる非常にきめ細かい/低レベルのAPIがあることに気づきました。
含まれている現在のビジュアルスクリプティングシステムと、カスタム抽象化レイヤーを備えながらも堅牢であることが望ましい理由。
サブイベントスクリプト言語のように、それぞれがエンジンの特定の部分に使用される複数のDSLを使用しない限り、このような実装をイベントスクリプト用に作成するのはめちゃくちゃ難しいです。

シンプルで使いやすい一般化されたビジュアルスクリプティングシステムは、実現するのが非常に難しく、私が「ユニコーンプロジェクト」と見なしているものです。
一般化の増加は、前述のシステムの複雑さの大幅な増加につながる可能性が非常に高いためです。

ビジュアルスクリプティングは、エンジンのすべての部分に特化したインターフェイスを持つことができる方向に徐々に進む予定です。
ブループリントのように、式ノードを持つプリミティブ複合ノードのタイプごとに異なる編集方法を想像してみてください。
https://docs.unrealengine.com/en-US/Engine/Blueprints/UserGuide/MathNode/index.html

しかし、明確にするために、私はイベントスクリプティングに反対していません。誰かが、Godotの特定のシステムをカバーできる提案を考え出し、それがなぜ、どのように役立つのかを考えてもらいたいと思います。 個人的には、GDevelopがどのように動作するかをプログラミングするのに非常に便利だと思います。
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors
http://wiki.compilgames.net/doku.php/gdevelop5/behaviors/events-based-behaviors

適切なゲームを書くためには使用しませんが、ドロップダウンして遊ぶことができる単純な動作があれば、ゲームの作成を学ぶ子供たちのためにプロジェクトを最適化するための非常に楽しい方法だと思います。
または、ゲームジャムにそれを使用してプログラミングすることに慣れていない人。

VisualScriptについても同じことが言えますが、モジュール性はおそらくそれを使用してはるかに簡単に実現できるでしょう。 問題は統一性と一貫性です（Visual ShaderとVisualScriptは完全に異なるコードベースを使用し、類似性のみが使用されるUIノードです）。
それでも、コミュニティで維持し、必要に応じてGodotに追加できるプラグイン（C ++プラグイン、4.0以降で簡単に実行できるようになることを願っています）としてイベントスクリプトシステムを作成することは確実にできます。 （私はモジュラーゲームエンジンに少し偏っています）

とにかくそれは私の2セントです。

コメントがオフトピックとしてマークされたのはなぜですか？ 誰かがコミュニティを検閲していますか、そして誰ですか？ それは良い前兆ではありません。 私のほかに、もっと話題から外れたコメントがあります。

@prominentdetailこれが私のアンチバンプ通知メッセージです。貼り付けるのを忘れました：slightly_smiling_face：

重要な新しい情報を提供せずに問題をぶつけないでください。 代わりに、最初の投稿で：+ 1：リアクションボタンを使用してください。

（GitHubにプライベートメッセージを送信する方法、または少なくとも非表示にするカスタム理由を指定する方法があればいいのにと思います。そのため、コメントスレッドにこれを散らかす必要はありません。）

PS：これはGitHubの典型的なエチケットです。 このリポジトリに固有のものではありません。

私はこの提案を支持しますが、誰もそれを実行することに時間を費やすとは思わないでください。
それは実際にそれを実現することができる開発者からの十分な強力なサポートを持っていません。

試してみる価値があり、議論は確かに面白かったです:)

@blurymindは、あなたがまだ提案を支持していて、GIPに必要な形式でそれを書くのに時間を割いて喜んでいるなら。 IMOを行う価値があります。

Godotで物事が追加される方法は、機能に興味のある人がそれを実装するのに時間がかかる場合です。 それは非常にランダムで散発的です。 ただし、機能の追加をランダムに決定する寄稿者にほぼ完全に依存しています。

したがって、現在アクティブな開発者のセットがあなたの提案に興味を持っていないからといって、誰かがやって来てそれを実装しないという意味ではありません。