ゲームエンジンGodot が4.0でVisualScriptを廃止
Godot のビジュアル スクリプト言語である VisualScript は、ほぼ 5 年前の Godot 3.0 で導入されました。私たちの絶え間ない努力にもかかわらず、それが勢いを増すことはなく、改善への道筋も明確ではありませんでした. このため、Godot 4.0 では、最初から採用したアプローチが適切ではなかったことを受け入れ、エンジンから削除することにしました。
Godot エンジン – Godot 4.0 は VisualScript を廃止します
Godot Visual Scripting is Dead – YouTube
明確にするために、これはビジュアル シェーダーではなく、VisualScriptスクリプト言語を指します。ビジュアル シェーダーはうまく機能し、多くのユーザーに高く評価されているため、どこにも行きません。
起源
Godot 2.1 が登場したときに最も要求の多かった機能の 1 つは、ビジュアル スクリプティングでした。当時、それは単なる別の機能要求のように思えました。それでも、これには特異な点がありました。それは、 Godot を使用するためにまだ Godot ユーザーではない多くの人が望んでいた機能でした。
Godot のほとんどの機能は、潜在的なユーザーではなく、実際にエンジンを使用しているユーザーによって要求されます。実際、現在、Godot 提案システムは、機能提案が実際のプロジェクトで必要とされるという要件を満たす必要があるように設計されています。当時はそうではありませんでした。
そこで、ユーザーがどの種類のビジュアル スクリプティングを望んでいて、最も言及されているブループリント スタイルを決定するためにアンケートを実施しました。この情報に基づいて、Godot 3.0 用の VisualScript が作成され、公開されました。
期待に応えられない
残念ながら、VisualScript は普及しませんでした。なぜそれを使わなかったのかをユーザーに尋ねたところ、主に 2 つの答えが得られました。
1.
この機能を必要とする多くの潜在的なユーザーにとって、GDScript が最適であることがわかり、最終的には VisualScript よりも GDScript を好むようになりました。
彼らは、GDScript がこれほど簡単に習得して使用できるとは思っていませんでした (プログラミングの予備知識がなくても)。当時の一般的なエンジンでこの種の高レベルのスクリプトが提供されていなかったためです。
これらのユーザーの多くにとって、Godot は最終的にプログラミングを学ぶためのツールになりました。
2.
ビジュアル スクリプティングの基本機能はありましたが、Godot にはそれを利用するための高レベルのコンポーネントがありませんでした。
Unreal、Game Maker、Construct などのエンジンは、ビジュアル スクリプティング ソリューションと一緒にパッケージ化された高レベルのゲーム機能を提供します。これが便利な理由です。
Godot は非常に汎用性の高いゲーム エンジンであり、これらの機能を自分で簡単に作成できますが、そのままではパッケージ化されません。そのため、VisualScript 自体はほとんど役に立ちませんでした。
VisualScript の人気が低いもう 1 つの理由として考えられるのは、VisualScript を使用するための適切なドキュメントを提供できなかったことです。公式ドキュメントには GDScript と C# の例がありますが、技術的な理由により VisualScript の例を含めることに成功しませんでした (例ごとに VS グラフのスクリーンショットを作成する必要があり、それらを維持することは非常に困難であることがわかります)。
いくつかのデモ プロジェクトがありましたが、それだけではユーザーが言語に習熟するには十分ではありません。視覚的な言語であってもです。Godot の API を学習するには、例を理解するために GDScript や C# に慣れる必要があります。
最新の調査 (5000 人以上の回答者による) によると、メインのエンジン言語として VisualScript を使用したユーザー ベースはわずか 0.5% でした。
進む道がない
VisualScript は例外で、有意義に改善するための十分なフィードバックを得るのに苦労しました。このことから導き出せる結論は、前に進む道はまったくなかったということです。つまり、私たちがビジュアル スクリプティングに対して採用したアプローチは、単に適切なものではありませんでした。
回顧
Godot の開発哲学は、ユーザーの問題と実際のユースケースの解決策を見つけることに重点を置いて非常に強力に形成されています。
VisualScript はこの方法で開発されていなかったため、有用なものを実装することができず、開発にかなりの時間が費やされました。これは素晴らしい学習体験であり、Godot は常に最初にユーザー向けに開発されなければならないという私たちの信念を強化します。
時々、機能がうまくいかないことがあります。Godot の VisualScript はそのような機能の 1 つと思われ、Godot 4.0 では Visual Scripting が削除されています。
マシュー・コーディル
その削除の根拠は不安定であり、いくつかのバイアスが含まれていることに同意します
少なくともGodotの開発の現時点では、それを削除するという実際の決定は正しいものです。リソースは、GDScript の低速で視覚的な複製を優先するのではなく、エンジンの残りの部分に集中できるようになりました。
Unreal には強力なビジュアル スクリプティングがあり、それが存在することが重要です。なぜなら、C++ は新規参入者にとって難しいためです (取り扱いを誤ると大変危険なことは言うまでもありません!) 一方で、GDScript は簡単です! その上、私は、誰かが非常に複雑なゲームを作成しようとしている場合、おそらくスクリプトを学ぶ必要があるという考えに賛成です. 高速で、強力で、用途が広く、すべてが優れた形容詞です。ここ
フィートトル
ビジュアル シェーダーが維持されていることを嬉しく思います。かなり基本的なシェーダーをコーディングできるようになり、上達していますが、ゲームに追加した複雑な水のようなレイヤーは、ビジュアル シェーダーなしでは実行できませんでした。ビジュアル スクリプティングがなくなってしまったのは残念です。私はいつもこのアイデアが好きで、ue4 のブループリントが大好きですが、godot がそれをうまくやったとは思いません。
アイビー/ダックレット
適切なビジュアル スクリプト言語は、テキストベースのプログラミング言語と同じレベルの注意を払って実装する必要があります。私は、中途半端な実装を出荷してから 2 年後に非推奨にするよりも、中途半端な実装をキャンセルしたいと考えています。
ロイ・ポーティロ 2 週間前
Unreal でブループリントと C++ を使い始めるまでは、ビジュアル スクリプティングにはまったく無関心でした。両方のソリューションの長所を一緒に使用する方法を理解しながら、一緒に使用するように構築されていることが、それが本当に優れている理由です.
プログラマーとして何をしているかを知っていれば、C++ でのコーディングはより高速ですが、ブループリントを使用すると、その問題点のいくつかを簡素化できます。OnHit、OnActorOverlap などのイベントへのバインディングの設定など (C++ だけを使用すると直感的ではなく、常に単純であるとは限りません) は、ブループリントとのバインディングでは非常に簡単です。マテリアルを操作するアニメーションは、ブループリントとビジュアル スクリプティングの優れたユースケースです。
