簡単に言うと、今回のテストは長く、使用中に改善すべき点が多数ありました。他のソフトウェアの使用経験も踏まえ、初心者として私の考えを述べさせていただきます。
一、ビジュアルコードで最適化が必要な部分
-
状態機械やオブジェクトの内容に対するより曖昧なフィルタ検索またはタグのサポート：
一般的に、特定のアクションを実行したり数値を変更したりする際には、具体的な単位を選択する必要があります。しかし、GDEVELOP などのソフトウェアでは、手動で数値を入力し、オプションの曖昧または正確な検索を通じて、対応する状態やアニメーションを見つけることが可能です。特定のオブジェクトを指定して実行するのではなく、これにより複数のターゲットまたは単一のターゲットに対して、より効率的に選択を行うことができます。例えば、敵の状態を「気絶」に変更したい場合、敵の状態機械内で条件に合致し「気絶」を含むものがあれば、自動的に気絶状態になります。関数やシグナルなど、より複雑な方法でこれらの機能を実現できることは理解していますが、なぜ制作者がより素早くアイデアを実現できるようにしないのでしょうか？ -
計算式または関数の入力をサポート：
数値定数を変更する際、現在はアクションを通じて変更できますが、式や関数の入力をサポートする方がより良い方法だと考えます。AGM のロジックを維持しつつ、新しい数値変更方式をサポートし、計算式で「カスタム」を選択することで、特定の関数や var の値を用いて計算できるようにします。例えば「a+1+b」と入力すれば、自動的に計算結果が算出され、現在のように数値のみを入力する制限がなくなります。 -
ビジュアルスクリプトの適用範囲の拡大：
子ノードにアタッチされ計算に参加する専用の AGM ノードを提供し、メモリ消費を削減することを検討できます。
二、AGM ノードに関する部分
-
UI ノードおよび UI ノードへのサポートの追加を強く推奨：
現在の UI システムは、依然として Godot 標準の UI に依存しています。数行のコードで済むことですが、なぜビジュアルスクリプトがこの分野をカバーしないのでしょうか？例えば、ボタン、クリック、選択など、よく使われる要素をすべて実装できるはずです。それほど複雑ではないと思います。AGM を購入する人々はプログラミングから離れたいと考えている人々であり、なぜ UI という重要な部分が軽視されるのでしょうか？ -
シグナルを処理または追加するための専用ノードの追加を推奨：
題名通り、これにより制作がより簡単になります。 -
機能的なノードの追加：
queue_free()のような機能的なノードをいくつか追加し、アニメーション内で直接アクティブ化することで対応する動作を完了できるようにし、多くの手間を省けるようにします。