HN 日本語サマリー

← 一覧へ戻る
プログラミング

Aspect-Oriented Programming を使用して DRL エージェントのデータを記録する

Using Aspect-Oriented Programming to Record DRL Agents' Data (blog.ptidej.net)

4 pointsby luca-sctr1 コメント

要約

この記事では、ゲーム開発におけるプレイテストの課題に対処するため、深層強化学習(DRL)エージェントを活用したPEAKプロジェクトを紹介しています。特に、ゲームコードの変更を最小限に抑えつつ、エージェントの行動データを効率的に収集・集計・可視化するために、Aspect-Oriented Programming(AOP)とデコレーター、設定ファイルを用いたアプローチについて解説しています。これにより、ゲームバランスの評価やデバッグを支援するダッシュボードの開発を目指しています。

全文翻訳

背景 プレイテストはゲーム開発において最も重要なプロセスの一つです。バグの発見、ゲームのUXの評価、ゲームバランスの調整、そして最も重要なのは、ゲームがどれだけ楽しいかを評価するのに役立ちます。ここで開発者は、ゲームのアイデアが良いかどうかを判断し、修正すべき欠点を発見します。これはプロジェクト全体を通して継続的に行われる反復的なプロセスですが、非常に時間がかかり、このプロセスのいくつかを自動化する信頼できるツールはありません。 PEAKは、この問題に対処することを目指していますが、プレイテスターを置き換えることを目的としているわけではありません。このプロジェクトの背後にあるアイデアは、設計者がいつでもゲームをテストするために展開できる、統合された深層強化学習(DRL)エージェントを備えたゲームエンジンを開発することです。 PEAKのGUIダッシュボード PEAKを使用する設計者のワークフローは次のようになります。 PEAK内のレベルエディターを使用して新しいレベルを設計する。 テストしたいエージェントのプレイスタイルを選択して、そのレベルでDRLエージェントをトレーニングする。 エージェントはデータを収集し、定義されたしきい値に基づいて、レベルがどの程度バランスが取れているかを伝え、プラットフォームのいずれかでの難易度の上昇などの問題があるかどうかを示します。 PEAKパイプラインのバランス調整 PEAKは、オンタリオ工科大学のクリスティアーノ・ポリトウスキー、アル・シファン、ケビン・チュアによって開発されています。私はプロジェクトの後半で参加しただけです。現在、2Dプラットフォーマーゲーム、あるいは多くの類似点があるため、メトロイドヴァニアにも対応している可能性があります。その範囲は後で拡張できるかもしれませんが、今のところ2Dプラットフォーマーは概念実証として使用されています。 問題 このプロジェクトでの私の焦点は、ユーザーのためのデータ収集、集計、および視覚化にあります。基本的に、エージェントがプレイ中にデータを収集し、そのデータを使用してゲームがバランスが取れているかどうかを判断する(例として)ステップを担当しています。 簡単そうですよね?もしジャンプの回数が基準の一部であれば、tracked_jumps 変数を追加し、それを持っているモジュールの jump メソッドに処理を追加すればよいですよね? しかし、いくつかの要件と問題がそれをそれほど単純にしません。 1- これはまだ成熟したプロジェクトではありません。私が取り組んだ最初の数ヶ月で、2回のメジャーリファクタリングを経ました。 2- これは複数のゲームをサポートするエンジンであり、それらを結びつけるアーキテクチャがないため、データの収集方法はどのゲームにも依存しないようにする必要があります。そうしないと、大量のコードの重複が発生します。 3- 追跡および処理する新しいデータを追加するには、コードベースへの変更を最小限に抑える必要があります。そうしないと、コアゲームコードとデータ収集コードの間に分離がなくなります。 変数を直接追加することは、すべての要件に違反します!これを解決するために、Observer Pattern と Aspect-Oriented Programming を使用します。 Aspect-Oriented Programmingとは? このプロジェクトに取り組む前は、Object Oriented Programming、そしてData OrientedやFunctional Programmingについても少し知っていましたが、Aspect(アスペクト)とは何か、そしてProgrammingをそれにOrientする方法は知りませんでした。 心配しないでください、私がそれを使っている間はAOPを使っていることを知りませんでした!教授が会議で指摘するまで、私は知りませんでした。Aspectとは、コードに直接追加できない、追加したい機能のことです。そうでなければ、複数の責任を同じモジュールに絡ませてしまいます。したがって、この特定のプロジェクトでは、収集および処理したいデータがAspectです。AOPでは、Aspectを追加したいプロジェクトの部分を指定します。この指定はpointcut(ポイントカット)と呼ばれ、Aspectを適用できるコードの点はjoin point(ジョインポイント)と呼ばれます。開発者は、何を、いつ実行するか、そしてAOPでjoin pointをどのように指定するかだけを気にすればよいのです。 AOPを使用する教科書的な例はロガーです。コアファイルにそれらを入れたくはありません。単一責任の原則に違反するか、高いカップリングにつながります。 デコレーターの使用 Python 2.4 は、メソッドのラッパーを定義できる非常にクールな機能を紹介しました。これは、ターゲットメソッドに注釈を付けるだけで適用できます。 下の画像はデコレーターの例を示しています。ここでは、緑色の矢印が元の関数を指し、赤色の矢印がデコレーターを指し、オレンジ色の矢印が注釈を指しています。この簡単な定義で、注釈を付けるだけで、関数呼び出しの前後に何を行うかを定義できます。 Geeks4Geeks デコレーター関数の例 私がデコレーターを使用した方法は次のとおりです。 1- 興味のあるデータの変数を保持する stats_observer というクラスを作成し、各変数に対して、どのように記録するかを決定する record メソッドを作成しました(単純なインクリメントか、他のチェックが必要か)。 2- パラメータとして record メソッド名を取る汎用的な track デコレーターを定義し、リフレクションを通じて、注釈が付けられたメソッドの呼び出し後にそのメソッドを呼び出します。 3- これにより、stats_observer に record_something を定義し、何かを記録すべきメソッドに @track(