当時の GAS の問題点は明白でした。それは、公式のドキュメンテーションとサポートが不十分であることに加えて、複雑であることでした。GAS は確かに複雑なシステムであり、会社によって、あるいは、プロジェクトによって利用方法がさまざまです。結局、このシステムを使う場合の、私たち自身のベストプラクティスを明確化するのに、私たちも若干時間が必要となったのです。
GAS を統合しながら、先に挙げた課題のために、基本的な仕組みをすべてチェックしてみると、どれも素晴らしい出来栄えでした。この時点で、私たちのアクション フィルター システムを GAS に完全に置き換えることが可能であるとわかりました。アビリティの実行を制御するための仕組みが私たちのシステムと似ているばかりか、格段に優秀だったからです。置き換えを終えると私たちは、すべてのプレイヤーのアクションを個別のアビリティに移動し始めました。これによって、AHBaseCharacter クラスと AHPlayerCharacter クラス (私たちのクラスには AH というプレフィックスがつきます) が、際立って軽量化されました。
GAS を利用した開発では、多数のアビリティ/エフェクト/タグ/ゲームプレイ キューを簡単に取得できます。だから、新たなアビリティを追加する場合は、そのことをちゃんと考慮しておく必要があります。さもなければ、もろくも「アビリティで立ち往生」状態に陥ってしまいます。この「アビリティで立ち往生」という言葉は、現在アクティブになっているある一つのアビリティによって、他の多数のアビリティがブロックされている状態を表現するために私たちが作った言葉です。つまり、プレイヤーが文字通り何もできない状態に陥る状態を示す用語です。私たちは、このような問題を回避するために、非常にシンプルで必要な情報を含むデバッグ メッセージをビューポートに表示させました。プレイヤー キャラクターに現在適用されているタグとエフェクトが表示されるのです。AI については、同じ情報をもつウィジェットを AI キャラクターの位置に表示しました。ただし、これには個々の AI キャラクターがもつアビリティがともなっています。