「戦略ゲームAI解体新書」読書会ログ 4 章 前半

今週も読書会ログ。4章は結構長いので時間切れにつき分割。

第4章 指揮官としての人工知能

チーム全体を動かす場合に、ストラテジーゲームには2つのパターンがあるらしい。

  1. プレイヤーが指揮官となって各メンバーや小隊に命令を与える

この場合、人工知能は、指揮官の部下の各メンバーや小隊の頭脳として作る。

必要とされる構造は以下のような上下構造。

  • 上から下に向けての命令系統
  • 下から上に向けてのレポート報告

2. 各メンバーが自由にコミュニケーションをとって連携する

これはマルチエージェント技術に属する。

多くの場合、1 が採用されるようだ。

4.1 チーム・空間・時間の階層化

上から下へ命令をくだすストラテジーゲームに必要な階層の話。

  • チームの階層化
  • 空間の階層化
  • 時間の階層化

ストラテジーゲームにおいては、時間・空間の階層構造を、チームの階層構造で制御することになるが、その連携はそれぞれを同期させることで解決するらしい。

チームの階層化というのは、分かりやすく「指揮官 -> 中間のリーダー -> 末端のキャラクター」のような縦構造。

時間・空間の階層化というのは以下のように説明されている。

  • 指揮官が思い描く作戦と、それを世界に接地して具現化するキャラクターの関係
  • 指揮官の長期・大局のプランと、キャラクターの短期・局所的な行動の関係
  • 指揮官・キャラクターの中間に位置し、中期・一定領域の指揮をするリーダーの関係

4.2 チームの階層化

チームの階層化の基本は指揮官を頂点としたヒエラルキーであり、組織の階層図であるらしい。

その関係性を人工知能が理解するには、グラフ構造にする必要があり、階層グラフともいう。

アサイ

関係性を理解した人工知能は、各エージェントに役割を与えるが、それを role assingment と呼ぶよう。
このアサインはゲームの最初に静的に決まる場合もあれば、ゲームの進行状況に応じて動的に行われることもある。

よって、指揮官としての人工知能はこの role assignment 機能が必要になる。
また、複数のエージェントを連携して行動させる技術をマルチエージェント技術と呼ぶらしい。

時間・空間を階層化した意思決定

組織が大きくなると、階層ごとのエージェントが把握する時間・空間が異なってくる。

これが前述の、「指揮官は長期・大局」「リーダーは中期・一定領域」「キャラクターは短期・局所的」の階層化につながり、それに応じた意思決定が必要になるらしい。

4.3 空間の階層化

ストラテジーゲームで人工知能が空間全域を把握するのに、空間の階層化が必要という話。
大局のスケールから、小さく分割していき、マルチスケールで空間を認識する。
空間の階層化はナビゲーションAI の役割でもある。

4.3.1 空間階層化の具体例

ビヘイビアツリー

キャラクターの動作を定義するために最もよく使われる手法の一つでツリー状にノードを展開したグラフの形式をもつもの。
Unreal Engine で初めてその用語を聞いたので、てっきり UE の言葉かと思っていたが、一般的にゲームで使われる用語のようだった。

KILLZONE 2, Halo の例

Halo の場合は、上の階層から「ゾーン」「エリア(前衛・中衛・後衛)」「スタンディングポイント(移動用)」と分割。
KILLZONE2 の場合は下の階層から「ウェイポイント(移動用)」「ノード(ウェイポイントを正方形に集団化)」「グローバルマップ(ノードをさらに階層化)」と抽象化していく。

手法は異なっているが、全体的に階層化されているという点で似ている。

4.3.2 占有度マップ

近年のFPSはマップが広大になったため、ストラテジーゲームの技術も使われるらしい。KILLZONE2 では「影響マップ」を使って戦局における勢力バラウンスを検出し、戦略を立てている。 「指揮官AI (総指揮官)」「スカッドAI (部隊長)」「インディビジュアルAI (各兵士)」の3つの階層に分離し、階層間で情報網を持ちつつ、下から上へは状況を報告し、上から下へは情報から得た戦局に応じて戦略を指示する。

ここでは上位で「階層型タスクネットワーク」という意思決定手法を利用するらしい。(これは後で出てくる)

指揮官AIが戦局全体を把握する方法

  • (KILLZONE2でいう) ノードとして分割された領域を「1戦術ノード」とする。
  • 戦術ノード間を連結したグラフを「戦術グラフ」と呼ぶ。
  • 戦術グラフを連結したものを「戦略ノード」とみなす。
  • 戦略ノードを連結したグラフを「戦略グラフ」と呼ぶ。

上記を踏まえて、「影響マップ」が使用されるらしい。
「占有度(Occupancy)」という”そのノードをどちらが支配しているか” という考え方を使った影響マップの作る場合が多い。

占有度の計算は、ノード単位で計算する。計算方法には以下がある。

  • バイナリ占有度マップ -> 占有度を 1, 0 で表す
  • 確率的占有度マップ -> 味方のいる位置を 1, 周りを 0.8, その周りを 0.6 のように距離に応じて影響度を変更するもの

占有度を使って影響マップを作ると、勢力の分布が把握できるので、勢力の薄いところに兵を向かわせたり、占有度をコストとしてノード状のパス検索を行う「戦略的パス(strategic path)」を使うことができる。

4.4 時間の階層化

「時間の階層化」とは、人間で言えば、時間ごとの「するべきこと」、人工知能では「タスク」。(人間もタスクかも)
大きなタスクを小さくタスクに分割していくことで計画をしていく。

4.4.1 階層型タスクネットワーク

タスクそれ自体に知的機能を持たせることによって、階層的に命令を自動的に作り出していく手法として説明されている。
タスクの定義として、ドメイン、メソッド、プリコンディションの 3 つがあり、それぞれが「情報」「タスクの分解方法」「前提条件」と言い換えられる。

メソッド

タスクが「コンポジット・タスク」と「プリミティブ・タスク」に分類され、コンポジット・タスクをサブタスクに分解し、(最小単位である)プリミティブ・タスクにしていく手法をメソッドと呼ぶ。

階層型タスクネットワーク

分解されたタスクは「順序構造を持つ」 or 「並列に実行可能」という状態になる。それらはネットワーク化することができ、それをタスクネットワークと呼ぶ。

階層型という場合には、単に分解されたタスクの実行ツリーというだけではなく、それをここまでの「長期・大局」、「中期・一定領域」、「短期・局所的」なところに合わせて考える。

また、タスクの分解方法である「メソッド」は必ず一通りに決まるわけではなく、条件をつけて、異なる分解の仕方を定義できる。

よって、状況によって、様々な分解が発生するため、その組み合わせであるタスクネットワークも様々に生成されうるところが面白いところ。

UEの Behavior Tree も、条件を様々付けることができるが、階層型と考えた時には、単に一つの Behavior Tree というだけではなく、それらも組み合わせた大きなネットワーク(or ツリー or グラフ)を想像する必要がありそう。

4.4.2 応用例 / 4.4.3 輸送例

ここでは指揮官、部隊、敵がある状態での実例が説明されています。

輸送例に関しては、移動と敵基地攻略を含めたタスクネットワークがどのように構築されるかが示されていてとても面白いです。

今回はここまで、次回は 4.5 から。

Unity ML-Agents の環境構築

Unity ML-Agents を動作させるための環境構築を行います。

Unity ML-Agents 実践ゲームプログラミング v2.2対応版 | 株式会社ボーンデジタル

上記の書籍の 2 章をもとに作業していますが、個人の環境に合わせているためかなり異なっています。

環境

Python のパッケージ管理は Rye を使っています。

Installation - Rye

プロジェクト作成

3.9 系にしてプロジェクトを構成します。

rye init hello_unity_ml
cd hello_unity_ml
rye pin 3.9
rye sync

PyTorch の追加

Previous PyTorch Versions | PyTorch

今回は v2.0.0 を使います。特にこれに意図はありませんが、とりあえず2 系にしたかったぐらいです。(この記事公開時点だとマイナーバージョンがもう少しあがっています)

Conda ではないので、pip であれば以下になることがわかります。

# CUDA 11.8
pip install torch==2.0.0+cu118 torchvision==0.15.1+cu118 torchaudio==2.0.1 --index-url https://download.pytorch.org/whl/cu118

rye はデフォルトでは PyPI しか対象にしないのですが、バージョンの後に + を付ける場合は、PyPI に無いようなので以下を pyproject.toml に追加します。

[[tool.rye.sources]]
name = "torch"
url = "https://download.pytorch.org/whl/cu118"
type = "index"

Dependency Sources - Rye

上記の project source として追加している形になります。

では改めて、それぞれを追加していきます。

rye add "torch==2.0.0+cu118"
rye add "torchvision==0.15.1+cu118"
rye add "torchaudio==2.0.1"

ml-agents の追加

ml-agents は rye のプロジェクトディレクトリの隣にある状態です。

+ hello_unity_ml/
+ ml-agents-release_20/
  + ml-agents/
  + ml-agents-envs/

こちらも rye add していきます。ローカルなので path で追加します。

rye add mlagents --path ..\ml-agents-release_20\ml-agents
rye add mlagents-envs --path ..\ml-agents-release_20\ml-agents-envs

ここまでで pyproject.toml の dependencies は以下のようになっています。

dependencies = [
    "torch==2.0.0+cu118",
    "torchvision==0.15.1+cu118",
    "torchaudio==2.0.1",
    "mlagents @ file:///D:/UnityProjects/hello_unity_ml/../ml-agents-release_20/ml-agents",
    "mlagents-envs @ file:///D:/UnityProjects/hello_unity_ml/../ml-agents-release_20/ml-agents-envs",
]
rye sync

これで一旦完了です。(が、実際にはこれでは不十分でした 😓

プロジェクトの動作確認

書籍の 2-2, 2-3 で Unity 側の準備はされているものとします。

そして 2-4 で実際に学習を行います。

mlagents-learn の実行

これは Python の仮想環境での実行となっているのですが、mlagents-learn は ml-agents の方にあるので、rye のプロジェクトの外にあります。

なので、 rye shell して仮想環境を持ったままディレクトリを移動しようとしますが、、、

Windows 11 environment seems to be getting misconfigured · Issue #349 · astral-sh/rye · GitHub

rye shellWindows では使えないらしいです。

ということで、素直に venv を activate します。(ここで、いつも使っている nushell ではうまくいかず、Powershell コンソールを起動する必要がありました 🤣)

.\.venv\Scripts\activate
# hello_unity_ml から隣の ml-agents のディレクトリを移動
cd ..\ml-agents-release_20\
mlagents-learn .\config\samples\RollerBall.yaml --run-id=RollerBall-1

さっそく protobuf のエラーが出ました。3.20.x にしろと出ていたのでバージョンを下げます。

rye add "protobuf==3.20"
rye sync

すると無事実行できたようです 🍻

            ┐  ╖
        ╓╖╬│╡  ││╬╖╖
    ╓╖╬│││││┘  ╬│││││╬╖
 ╖╬│││││╬╜        ╙╬│││││╖╖                               ╗╗╗
 ╬╬╬╬╖││╦╖        ╖╬││╗╣╣╣╬      ╟╣╣╬    ╟╣╣╣             ╜╜╜  ╟╣╣
 ╬╬╬╬╬╬╬╬╖│╬╖╖╓╬╪│╓╣╣╣╣╣╣╣╬      ╟╣╣╬    ╟╣╣╣ ╒╣╣╖╗╣╣╣╗   ╣╣╣ ╣╣╣╣╣╣ ╟╣╣╖   ╣╣╣
 ╬╬╬╬┐  ╙╬╬╬╬│╓╣╣╣╝╜  ╫╣╣╣╬      ╟╣╣╬    ╟╣╣╣ ╟╣╣╣╙ ╙╣╣╣  ╣╣╣ ╙╟╣╣╜╙  ╫╣╣  ╟╣╣
 ╬╬╬╬┐     ╙╬╬╣╣      ╫╣╣╣╬      ╟╣╣╬    ╟╣╣╣ ╟╣╣╬   ╣╣╣  ╣╣╣  ╟╣╣     ╣╣╣┌╣╣╜
 ╬╬╬╜       ╬╬╣╣      ╙╝╣╣╬      ╙╣╣╣╗╖╓╗╣╣╣╜ ╟╣╣╬   ╣╣╣  ╣╣╣  ╟╣╣╦╓    ╣╣╣╣╣
 ╙   ╓╦╖    ╬╬╣╣   ╓╗╗╖            ╙╝╣╣╣╣╝╜   ╘╝╝╜   ╝╝╝  ╝╝╝   ╙╣╣╣    ╟╣╣╣
   ╩╬╬╬╬╬╬╦╦╬╬╣╣╗╣╣╣╣╣╣╣╝                                             ╫╣╣╣╣
      ╙╬╬╬╬╬╬╬╣╣╣╣╣╣╝╜
          ╙╬╬╬╣╣╣╜
             ╙

 Version information:
  ml-agents: 0.30.0,
  ml-agents-envs: 0.30.0,
  Communicator API: 1.5.0,
  PyTorch: 2.0.0+cu118
[INFO] Listening on port 5004. Start training by pressing the Play button in the Unity Editor.

実行してみる

書籍の指示通り、Unity Editor からプレイしてみます。うまく学習をしているように見え、 Mean Reward が 1.0 に到達したので停止すると、、

[INFO] RollerBall. Step: 161000. Time Elapsed: 2047.522 s. Mean Reward: 1.000. Std of Reward: 0.000. Training.
[INFO] Learning was interrupted. Please wait while the graph is generated.
============= Diagnostic Run torch.onnx.export version 2.0.0+cu118 =============
verbose: False, log level: Level.ERROR
======================= 0 NONE 0 NOTE 0 WARNING 0 ERROR ========================

Traceback (most recent call last):
  File "D:\UnityProjects\hello_unity_ml\.venv\lib\site-packages\torch\onnx\_internal\onnx_proto_utils.py", line 219, in _add_onnxscript_fn
    import onnx
ModuleNotFoundError: No module named 'onnx'

上記のエラーが発生しました。 onnx が無い。これは何でしょうか。

GitHub - onnx/onnx: Open standard for machine learning interoperability

これっぽい。

rye add onnx
rye sync

この後、numpy やらのバージョンのミスマッチがいくつか出た結果、protobuf のバージョン固定も外すことでシンプルに解決できました。よって、dependencies は以下のような感じです。

dependencies = [
    "torch==2.0.0+cu118",
    "torchvision==0.15.1+cu118",
    "torchaudio==2.0.1",
    "mlagents @ file:///D:/UnityProjects/hello_unity_ml/../ml-agents-release_20/ml-agents",
    "mlagents-envs @ file:///D:/UnityProjects/hello_unity_ml/../ml-agents-release_20/ml-agents-envs",
    "protobuf",
    "onnx",
]

これでうまく学習結果を onnx 形式で保存でき、かつそれを使った推論まで実行することができました 🎉🎉

「AGILE TESTING CONDENSED」読書会ログ 2, 3 章

Agile Testing Condensed… Yuya Kazama 著 et al. [PDF/iPad/Kindle]

友人の QA 担当者と話の流れから読書会をすることになったので、そのログ。QA も分野としては好きなのだけど、仕事が無い。

第2章:チーム全体のアプローチとアジャイルテストのマインドセット

チームとは

「チーム全体」とは、通常、デリバリーチーム(何を構築するかを理解し、それを構築し、最終的なプロダクトを顧客に届けるための責任を負う人々)を意味します

DevOps の動きでは「運用」もデリバリーの一環になるという。 DevOps の本は次にする予定だが、「(プロダクトやその価値を)理解し構築し届けて運用する」までが一つのチームでというのは、小さい組織なら当たり前だけど、大きくなると難しいというのも分かる。

Janet はデリバリーチームの外の人々を拡大家族と呼んでいます

この一文に関しては、読書会の中で「いい意味なのか悪い意味なのか?」と話にあがったが、英語版でも単に extended family となっており、まあ言葉通りの意味なのかなということになった。

品質に注目する

「チーム全体」でのアプローチとは、チームメンバー全員がプロダクトの品質に責任を負うことを意味します

テスターからすれば、当然こうあって欲しいですがなかなかそうはならないよね的な。

ここでは、「プロダクトの品質」に加えて「プロセスの品質」についても触れられていて、これらの焦点を当てることで、チームはより早く作業できるようになり、フィードバックループによって顧客に価値ある機能をテストすることに集中できるとあります。

「品質」を目標にする、つまりは「価値ある完成の定義」にテストも含めるというのは、確かにこれを同意しないとテストはおざなりになってしまうよなと感じました。

チームが欠陥に対処する方法

コーディングの完了後に欠陥を見つけるのではなく、欠陥の防止に焦点を当てる

品質の構築や、品質特性について考えることが述べられていますが、これをプロセスの中でしっかりやれれば理想的だなと思います。私も開発チームとテスト計画を作るときに、品質特性の項目を含めていましたが、たとえそれが開発の終盤であったとしても、そこで気付けるだけでデリバリー後に気付くよりは何倍もいいので役立ったと思います。

ここでは、「欠陥許容度ゼロ」についても触れられています。
読書会の中で、私が以前いたチームではここにあるように欠陥が発見されたら、まずはそれを再現するテストを書き、そこからそれをパスするコードを書くことを徹底していたことを話題にしましたが、後にも先にもそれを徹底できたチームはそこだけなので、稀有なチームだったなと思うと同時に、そのチームはそれに対して完全に同意できていたのが大きかったなと思います。

複数の視点

チームメンバーのスキルセットからなる観点を使おうということですね。

「ジェネラライズドスペシャリスト」という言葉がここで出てきますが、読書会の中で、友人が QA のカンファレンス内で、「品質に焦点を当てたチームのためには、結局フルスタックエンジニアみたいな人を揃えたチームを作らないと、実現できないんじゃないか」みたいな話題が出たと話してくれました。

私は「フルスタックエンジニア」という言葉があまり好きではないですし、定義もよく分かりませんが、まあ「なんでもできる」のだとして、そこに「テスト」も含まれるのであれば、確かにそういう人ばかりであれば理想的だろうと思います。

一方で、ここではチームメンバーのスキルセットの中からという話なので、ジェネラライズドスペシャリストであり、かつ個人特有の役割に応じたスキルセットもあるぐらいの話かなと思いました。

第3章:アジャイルにおけるテスト計画

7つあるアジャイルテストの重要な成功要因の一つは「広い視野を持つ」である

チーム

「少人数で同じ場所にいるチーム」と「大規模でグローバルに分散したチーム」では課題が異なることがまず述べられていました。

「大規模」の定義はさまざまだと思いますが、ここでは一つのプロダクトで「フィーチャーのサイロ」になることがあることが挙げられています。
そういう意味では、開発チームが 10 人を超えたあたりから、縦割りの機能別チームみたいのを作ったのは割と記憶にあるなと思います。

状況がどうあれ、デリバリーチームはすべてのテスト活動の計画と完了に責任を負わなければなりません

統合の問題や、人員の問題や、依存する他チームとの調整などもコーディングを始める前に取り掛かりたいとあります。これができたら理想だなと思います。
実際、依存する他チームとの調整とか難しいですよね、、設計のすり合わせもしないといけないけど、そうなると多少作り始めたりしたくなるし、結局他チームの人員リソースとの兼ね合いにもなってくる。

クロスファンクショナルチーム

読書会の中で「クロスファンクショナルチーム」の定義っていくつかあるよね、的な話になりました。
パッと検索しても文脈次第という感じです。

この節でのクロスファンクショナルチームは、一つのプロダクトに対して作業するいくつかのチームに対して使っているのでしょうか。

プロダクト

テストの主な目的の一つは、ユーザーとビジネスに対するリスクを特定して軽減することです。明らかに、このリスクはテスト計画のやり方に影響を与えます。

ビジネスドメインの内容から、デリバリーの方法にわたって、リスクの範囲は様々だと思います。つい、リスク分析となるとフィーチャーに焦点を当てがちですが、視野を広げる必要がありそう。

詳細レベルに応じた計画

リリースサイクルの中でチームがその「全体像」を理解しておくことが重要だと述べられています。
ストーリーに集中する開発者と、全体像を見ておくテスター、確かにこれはそうなっているような気がします。

リリース/フィーチャーレベル

ここでは、単一プロダクトに対して複数のチームが作業している場合に、チーム間の依存関係の解決や、全体のテストカバレッジを示すにはどうするかが書かれています。

テストマインドマップ・テストマトリクスが紹介されています。

アジャイルテストでの計画・管理のツール:Test MatrixとTest Mindmap - 千里霧中
以下は上記記事からの引用です。

テストマインドマップ、テストマトリクスいずれも、マネジメントとチームのコラボレーションを支えるためのモデルとして活用します。具体的には、話し合いながら、チームでアイデアを出し、チームでアクティビティを共有し、チームで進行状態を共有するための手段として、テストマインドマップ、テストマトリクスを活用しています。

テストマインドマップはよく使いますが、個人的にはテストケースの洗い出しのような形で使うことがほとんどで、このように「進行状態の共有」にまで利用することは考えたことがありませんでした。

一方で、確かに複数チームでの作業になるとこのように粒度は粗いものの、大きな視点で可視化できるツールは有用だなと思いました。

ヒント

この節のヒントに、

開発者が新しいストーリーに着手している間に、テスターや運用スタッフにデプロイに必要な準備作業をさせるような誤ちをおかさないでください。

とありますが、開発リソースを時間工数で見るような経営判断があると、「手が空いている」のような表現で、開発が終わったばかりの開発者をすぐに次のストーリーに着手させるようなことがあります。というかありました。結局テストが手戻りがあったりで、あんまりいい事ないので、ホントやらない方がいいと思います。。

ストーリーレベル

高レベルの受け入れテストから始めましょう

私はこれを実践できたことはありませんが、具体例を取得したら、それをテストにするというのはいい方法ですよね。

読書会の中で「チームがテストを計画し、各ストーリーの実装について話し合うと、テストの詳細が明らかになる」について話したのですが、テスト計画までいかなくても、ストーリーの計画ミーティングの中で、実装までざっくり話し合うチームにいた時はすごくやりやすかったのを思い出しました。

チームによっては、チームメンバーに対して「お手並み拝見」的に、ただストーリーだけ渡してやらせるチームがありますが、結局 PR で手戻りになったり、「事前に設計の相談ができるコミュニケーション能力が必要」とか訳のわからないことを言われることになるのを見たことがあります。最初から全員で実装の大体の合意しておけよ、とよく思います。
まあ、今はモブプログラミングとかで、色々カバーできるのだとは思いますが。

タスクレベル

TDD!

回帰テストの計画

回帰テストとは、システムが昨日やったことを確認することです。

なんかいいですね。友人の QA は、これが今の所一番メインの仕事らしいですが、なかなかストーリーでの機能の変更の中に、既存の回帰テストの修正までがセットになることは無いそうです。
それでも、落ちたら直してくれるらしいので、十分なのではとも思いました。

ここでは「リリースフィーチャートグル」についても触れられています。速度の速い開発チームのテストをしていると、リスク次第では先にデプロイさせて、そこからテストもありますが、リリースフィーチャートグルを使えば、顧客にデリバリーはできていないものの、より安全にテストできて良いなと思います。

「戦略ゲームAI解体新書」読書会ログ 3 章

「戦略ゲームAI解体新書」読書会ログ 1, 2 章 - You are done!

今週も読書会ログ。

第3章 ゲームAIの基礎事項

3.1 ゲームAI小史

まずはゲームと AI のおおまかな流れについて年表みたいなものが示されます。

3.1.1 スクリプティッド AI

Scripted AI の出自に関して。「あらかじめ準備された行動を反射的に行うだけ」というのは、ロジックで書けばそうなるのは理解できる。

現在でも小中規模のゲームではスクリプティッドAI は使われており、大規模になるにつれて「キャラクターAI」が使われるらしい。

3.1.2 MCS-AI 動的連携モデル

  • ゲームの 3D 化以降に、ゲームの中で AI が独立要素として「再発見」される。
  • それらを「メタAI」「キャラクターAI」「スパーシャルAI」として分類。
  • これらが動的に連携するモデルを「MCS-AI 動的連携モデル」と呼ぶらしい。
    • Meta-Character-Spatial AI Dynamic Cooperative Model

人工知能という用語的に、AI というとキャラクターAIが真っ先に想像できて、次にメタAI のようにゲーム展開を作るような AI も想像できるけど、スパーシャルAI のようなものも「AI」と呼ぶというのは、個人的には直感的ではない気もするけど、分類の仕方としては納得できる。

3.2 3つのAIの役割とスケールとプレイヤー体験

前述の 3 つの AI を分つの 役割とスケール

キャラクターAI

  • スケールは「局所・短時間」のユーザー体験
  • キャラクターに内蔵されるAIで、プレイヤーと直接対決を行う

メタAI

  • スケールは「大局・長時間」のユーザー体験
  • 「スパーシャルAI」の助けを借りて、ゲーム空間全域の変化やゲームの時間方向の展開を作る

スパーシャル AI + ナビゲーションAI

  • 「メタAI」「キャラクターAI」が活用できる空間情報を提供する
  • ユーザー体験を空間内でデザインする力を持つ

デジタルゲームの目的

ユーザー体験を作り出すこと

時間的・空間的に段階的にゲームがスケールしていくというのは、戦略ゲームでなくとも、いろんなゲームをしていると感じるところはある。

AI の影響

ストラテジーゲームの場合

  • 通常スパーシャルAIの影響が大きい(地形の特徴を捉えて活用することが戦略ゲームの本質)
  • メタAIはゲームの流れを作るので比重が大きい

アクションゲームの場合

  • まずキャラクターAIを作り「ユーザーとの局所・短時間のインタラクション」を構築
  • スパーシャル AI によって、地形をより活用可能にする
  • 最後にメタAIによってゲームの流れを作る

図もわかりやすい。

3.3 メタAI技術

俯瞰的にゲームをコントロールする人工知能

古典的メタAI

  • 「難易度自動調整」「ダイナミック・ディフィカルティ・アジャストメント (Dynamic Difficulty Adjustment, DDA)」とも呼ばれる
  • 難易度を動的に(ゲームを進行させながら)ユーザーのスキルに合わせる

例で出てくるゼビウスがどのように難易度調整をしていたかは以下の記事が理解の助けになりました🙏.
「ゼビウス」における動的難易度調整 - 大和但馬屋日記

現代的メタAI

  • アセットを自動生成する「プロシージャル技術」と結びつき、ゲームを創造的に変化させることができる
  • 「AIディレクター」と呼ばれる、キャラクター操作に限定したゲームをコントロールする仕組みがある
    • ユーザーの緊張度を測定し、それに応じて敵の出現数を決定
    • ユーザーの緊張度を人工的にアップダウンさせる

AI ディレクター (Director AI)という言葉は Left 4 Dead というゲーム自体が導入した言葉だと友人に教えてもらいました。

3.4 キャラクターAI

エージェント

  • デジタルゲームにおける、役割を果たすために作られたキャラクター
  • ゲームでは雑魚敵含め、ほぼ全てのキャラクターがエージェント

自律型エージェント

  • 自律型AIを持つエージェント
  • 「自分自身のことを自分で決めることができる」
  • 「目的(役割)」をもち、それに沿って感じ・考え・行動する

ストラテジーゲームの発展は、自律型エージェントの発展と結びついているらしい。

変遷みたいなもの

  • 80’s-90’s のゲームは、「スクリプティッドAI」で、「簡単なロジック」で動いていた
  • 現代の「キャラクターAI」は自律型エージェントとして機能する
  • クリプティッドAI: AI製作者の頭脳にゲーム状況と思考がある
  • 自律型エージェント: AI が自分の知識と思考を使い意思決定・行動

エージェント・アーキテクチャ

  • いかにエージェントに知識を持たせ、自分で考えさせるか
  • センサーで情報を収集、認識を形成、意思決定によって方針を決め、アクションメイキングで行動を生成する。また、これらを記憶するメモリを持つ。
  • このような全体のアーキテクチャのこと

2.5.5 の図がここで改めて理解の助けになる。

3.5 スパーシャルAI

ユーザーがキャラクターに知能を感じるとき

  • 空間を上手に使った時
  • 時間の中で賢く戦略を立てて行動した時
    • 空間と時間を利用することが、知能の特性であり証明

スパーシャルAI の機能

キャラクターAI、メタAI が空間を巧みに活用するための情報を提供する。

「パス検索」「位置検索」「オブジェクト表現」「勢力解析」の4つに分類。

パス検索

  • 目的地までの経路探索
  • 敵の目的地がわかっていれば、敵の現在地から目的地までの経路予測 => 予測経路を「ゴールデンパス」とも呼ぶ
  • ゴールデンパスを使って、敵ならば挟み撃ち、味方ならば護衛などができる

位置検索

  • 候補ポイントから評価値によって適切な場所を算出する
  • 「戦術的位置検索」という手法もある

オブジェクト表現

  • ゲームのオブジェクトに埋め込まれている補助データ
  • メタAI/キャラクターAI が認識し利用する
    • 動かせるか?伐採できるか?資源にできるか?

人工知能は「知識 x 思考」からなるので、環境やオブジェクトの知識を持っておき、オブジェクトを賢く使えるかが高度な人工知能を作る鍵と言えるらしい。

3.6 影響マップ

スパーシャルAIの「勢力解析」機能。
複数の駒が置かれた時に、「リアルタイムの勢力図」を作るために利用される。Influence Map ともいう。

原理

  • 敵を熱源、味方を冷却源とした簡単な熱伝播シミュレーション
  • 敵味方の中間にある、温度がゼロの領域を「フロントライン」と呼び、そこは勢力が均衡している

フロントライン

フロントラインは勢力の変化の目印でもあり、メタAI がフロントラインを動かすために、天候や風向きを変化させたり、敵の増援を行ったりする。

影響マップを使うことで動的にゲームをコントロールすることができる

3.7 知能方程式

知能感受性

ユーザーが AI に対して知能を感じる「知的体験」はキャラクターの賢さだけでなく、ユーザーの心理状態が影響する。
ポイントとしては以下がある。

  • プレイヤーの意図の強さ
  • プレイヤーの生存の危険度
  • 敵の人間との類似性

プレイヤーがキャラクターに感じる知能は、このユーザーの「知能感受性」の高さと、敵の賢さを掛け算したものになるらしい。これを知能方程式と呼ぶとなっている。

「敵知能の高さ」は純粋な人工知能の話であり、ゲームエンジニアの仕事であるのに対し、「知能感受性」はゲームデザインの領分とも言える。
どちらが欠けても「知能を感じる」ユーザー体験は作れない

ロジック中心のボードゲームとエンターテインメント要素のあるビデオゲームとの違いが、このユーザー体験にもつながっているのが面白い。

「戦略ゲームAI解体新書」読書会ログ 1, 2 章

戦略ゲームAI 解体新書 ストラテジー&シミュレーションゲームから学ぶ最先端アルゴリズム(三宅 陽一郎)|翔泳社の本

ここ数年で「AI」という言葉がいろんな文脈で使われるようになってしまい、個人的にも業務の中でシステムに OpenAI の API を組み込む部分が出てきたりしてたんですが、ゲームでいう AI 、例えば UE で想像するのは Behavior Tree みたいなものは、そもそもどういうものかってのが理解できてないので、一冊手に取ってみることにしました。
友人と週一で読書会をすることにしたので、ここではそのログをざっと記録することにします。

本書のスタンスとしては「ストラテジーゲームとその周辺の人工知能技術」を解説する、というのが正しいところです。

ストラテジーゲームというゲームも用語も正直あまり馴染みがないので、まずはそのスタンスの基盤になる「ストラテジーゲーム」についての説明から始まっています。

第1章 ストラテジーゲームとは

まずはアクションゲームとシミュレーションゲームと今回の主題であるストラテジーゲームの違いについて説明があります。
正直シミュレーションゲームとの違いが分かってなかったですが、「特定の現象のシミュレーションを含む」のがシミュレーションゲームであると理解しておけばいいようです。

ストラテジーゲームはプレイヤーに戦略的な思考を強いる、この時点ではまだ「戦略的な思考」は私はよくわかっていません。

1.1 ストラテジーゲームにおける人工知能技術

「ストラテジーゲームの本質は意思決定にある」とあります。よってストラテジーゲームの人工知能を学ぶことは、マネージメントの技術向上にも繋がるそうです。確かに業務の現場は意思決定の連続であり、特にマネージャー職はより大局を見る必要があるので、そう言えるのかもと思います。

本書の視点は「プレイヤーとしての人工知能」から見たゲームと人間のプレイヤーについてです。普段、プレイしているのとは視点が逆になります。人工知能がプレイヤーとなって人間のプレイヤーと対戦します。

UE で Behavior Tree をいじってるぐらいでは、この視点から考えることは個人的にはありません。とても楽しみです。

ここでボードゲームとの対比についても書かれていますが、当然ながらゲームでは「命令を出した対象が自動で移動・戦闘をする」ため「メンバーとしての人工知能」も存在することになります。

1.1.1 人工知能技術からみたストラテジーゲームの分類

こういう分類はすごく理解の助けになります。そして、シミュレーションRPGの分野ぐらいしか私には馴染みが無い。

図の横軸が「戦闘」「社会」になっていますが、シミュレーションにも「戦闘シミュレーション」「社会シミュレーション」の分類があるようです。
社会シミュレーションは、「社会の断面」や「日常的要素」などが絡み合う上に、心理学、認知科学社会学などとも接しているそうです。
こういうものが「典型的なストラテジーゲームの人工知能」と言えるようです。

図の縦軸は「世界発展」「育成」となっています。縦軸はゲーム世界側のダイナミクスを表しており、用いられる技術としては「シミュレーション技術」「マルチエージェント技術」のようなものがあり、その中間に「群知能」があるとなっています。
自律的なキャラクターとそれらを組み合わせた集団、想像できないですね。。

1.2 ターン制と想像力

個人的にはストラテジーゲームの分類として「ターンベーストストラテジーゲーム」「リアルタイムストラテジーゲーム」があることも知りませんでした。

  • 前者はゲームが静止しているため「最善手を考えるのが優先事項
  • 後者は時間軸でゲームが動くため「状況変化を想像(シミュレーション)することが必要

第2章 ストラテジーゲームと人工知能

2.1 ストラテジーゲームの定義

まずは、最も広義なストラテジーゲームの定義が展開されます。こういう定義はありがたいですね。なんとなく、ファイヤーエンプレムやピクミンを想像しながら読みます。

続いて、シミュレーションゲーム、ストラテジーゲーム、アクションゲームについて再考があります。

  • シミュレーションゲームといえば、現実をモデル化してゲームにしたもの
    • 例にあった列車を考えると、電車でGoもシミュレーションかぁなどと当たり前のことを思いました。
  • ストラテジーゲームの中でも、現実をモデル化した部分があれば、シミュレーションゲームと呼ばれることもある
  • つまり、多くの場所で上記2つは重なり合っている
  • 一方で、アクションゲームは対照的で、リアルタイムに自分の1体のキャラクターの身体を操作し、ゲームの大きな流れの中でミッション・戦闘をクリアする

ストラテジーゲームとアクションゲームは人工知能全体のフレームは変わらないが、重点的に開発する部分が異なるそうです。 - アクションゲームでは「敵キャラクター」 - ストラテジーゲームでは「キャラクターAI」および、対戦相手となる「プレイヤーの人工知能

2.2 ストラテジーゲームの3つの分類

まず、ストラテジーゲームの人工知能としては 3 つが基本であると説明されます。

  • プレイヤー
    • プレイヤーが指揮官となり、NPC に命令するゲーム
  • 世界
    • 自律的に発展していく世界にプレイヤーが干渉するゲーム
  • プレイヤー以外のキャラクター
    • プレイヤーが人工生物、人工社会を育成するゲーム

書籍内では、さらに 1章で出てきた図とのマッピングも書かれていますが、非常に整理として分かりやすいです。

2.2.1 プレイヤーが指揮官となるゲーム

ここでの人工知能はプレイヤーの指揮に従う「キャラクターAI」です。
AI が賢くなれば、プレイヤーの指示に「賢明に判断・行動・計画を自律的に」行えるようになるわけです。

書籍では「キャラクターとプレイヤーの距離感」と表現されており、これがこの分野のゲームで重要な要素のようです。
確かに、指示を送った AI が全く見当違いなことばかりするようでは、ゲームとして成立しませんね。。

2.2.2 自律的に発展していく世界に干渉するゲーム

ここでの人工知能は「街・惑星そのもの」となります。

元々は、「ライフゲーム」「オートマトン」といった自己発展プログラムをもとにしたようです。さっぱり聞いたことがありません。

どうやらこの分野はアカデミックには無い分野らしいです。自己発展・自己進化・自己成長(・自己増殖)とか夢があるのになぁ。

2.2.3 人工生物、人工社会を育成するゲーム

ここでの人工知能は「学習機能を持つキャラクター」となります。
このキャラクターが自律進化し、集団・社会を構成しそれに対してプレイヤーがどのように「教育」を行うかで学習・進化の方向が変化します。

ニューラルネットワーク」「遺伝的アルゴリズム」のような技術が使われます。今だと、LLM も活躍しそうな分野ですね。

友人が話していましたが、ドラクエ4の時は、パーティーに「命令させろ」がなかったので、動きは基本 AI だったようですが、(世間的にはアホなAIとも言われていたようですが)きちんと敵に対して戦術を試し、それを学習していっていたらしく、当時から学習する AI というものは身近にあったと言っていました。小学生の頃なので気にしたことなかったなぁ。

2.3 ストラテジーゲームにおいて人工知能がなぜ必要か?

これは、プレイヤーが指揮官となる場合だけでは無いと思いますが、
- 末端で動くキャラクターたちに知能をつけることで、プレイヤーに指揮官としての地位を与える

ということのようです。

また、プレイヤーからキャラクターへの指示は「命令(コマンド)」「操作(オペレーション)」の2つが基本のようです。

上記の指示を受け自律的に動作するキャラクターの人工知能を「キャラクターAI」と呼びます。これが賢ければ賢いほど「抽象的」な指示を与えることができるとあります。
そうなると、LLM が出てきた今だと、その抽象度はだいぶ上がっているのかもしれないなと感じます。

続いて、図を用いて、全体(戦略)レベル、チーム(戦術)レベル、個体レベルの AI について説明されています。
各レベルごとに AI があり、さらにこれまでも出てきていますが、「敵プレイヤーとしてのAI」が必要です。

キャラクターAI と対比して「プレイヤーAI (人工知能プレイヤー)」とも呼ぶようです。
そして、これはキャラクターAIと作り方は同じであるものおん、考える内容がより大きなスケールで、長時間に及ぶ計画になるようです。
実装したことの無い人間としては、それが個体レベルのキャラクターAI と作り方が同じというのが想像もできません。

2.4 ストラテジーゲームにおける時間と空間

ここでは、まずゲームの時間と空間の「離散的」「連続的」の分類と、それの組み合わせによるゲームのマッピングが説明されます。

「離散的」「連続的」という言葉は出てくるものの、ゲームとしては「リアルタイム or ターンベース」、「空間の単位の有無」みたいなもので整理できるようです。

2.4.1 で出てきますが、人工知能は時間・空間の両方で、「連続的なものが得意ではなく、離散的なものを得意とする」ようです。よって、無限も連続も扱えないプログラムにおいては連続的なものは離散的なもので近似して対応するようです。

2.4.2 ストラテジーゲームの時空間による分類

すでに図で説明されていますが、4つの分類を詳細に説明しています。

  1. 連続空間・リアルタイム
    • フィールドの上で敵味方ともにリアルタイムで進行
    • 絶え間なく命令を発し続けて、自分も自律的に動き続ける
  2. 離散空間・リアルタイム
    • フィールドはマス区切りなので、プレイヤー、AIともにマップの分割で思考を整理
    • リアルタイムに敵の陣地を攻略
  3. 連続空間・ターンベース
  4. 離散空間・ターンベース

2.5 ストラテジーゲームの人工知能の例題

2.5.1 ゲーム設定

まずは、例題のゲームの設定の紹介から。9人のメンバーがいて、3人のユニットを組み、同編成の敵と戦う。

特に意図はないと思うが、絵とパラメータが一致してなくて面白かった。(僧侶っぽいのに、パラメータでは物理で殴るキャラだったり)

2.5.2 ユニット編成メイキング

ユニット形成、チームビルディングとも呼ぶ。

人間プレイヤーと同様にプレイヤーAIもユニット編成を行うことがポイント。
AI 側はどのようにユニットを組むかを「方針 (Policy)」と「基準 (Criteria)」を用いる。
トップダウン型とボトムダウン型があり、それぞれが説明されている。

計算式なども出てくるが、確かに現実業務でのチーム編成もこういうことを感がているマネージャーがいるんだろうなぁと想像したりした。

2.5.3 出撃

ここでは、キャラクターの移動について説明がある。
「ナビゲーションAI」とその機能である「パス検索」が紹介されるが、そこでパス検索のために「連続空間(例えば地形)を離散化する」という方法が出てくる。

その方法に「ナビゲーションメッシュ」「ウェイポイントグラフ」が出てくる。ナビメッシュは UE でもお馴染みだが、「連続空間の離散化」の意味があるというのは理解に大きく役立った気がする。
実際、経路探索問題等になると、ここでも出てくるウェイポイントグラフの方が馴染みがある気がするので、ナビメッシュも同じであるというのはなるほどなと。

ナビメッシュは地形を「三角形」で離散化。ウェイポイントグラフはそのまま「ポイント」で離散化する。

2.5.4 ユニット移動とフォーメーション

陣形での移動について。この例題のゲームの絵が思い浮かんでいないが、ユニットの各メンバーもそれぞれパス検索して動いているんだなぁと思うと、アクションRPG のパーティーの移動も大変だなという気持ち。

2.5.5 遭遇

敵ユニットとのエンカウンターについて。ここで重要なのは「周囲を認識、記憶し、判断し、行動をする」ということらしい。
そしてその役割を担うものとして、「自律型エージェント」とそのアーキテクチャである「エージェント・アーキテクチャ」が紹介される。以降はエージェント・アーキテクチャが持つ各モジュールと先ほどの重要点のマッピング

  • センサー
    • 周囲を認識する
    • 敵キャラクターやオブジェクトを認識する
  • 記憶
    • 一般的には知識表現とも呼ばれる
  • 認識
    • 再びの認識であるが、ここではセンサーで取得し、記憶した情報を抽象的な形に変換する。
  • 意思決定
    • 認識の上で判断する
    • 意思決定のアルゴリズムは7つ存在する
    • ここではルールベースで IF THEN のように判断する方法が紹介
  • 行動生成
    • 意思決定に基づき行動が決まれば、その行動を生成する
    • 実際に攻撃する敵を判断する時にはさらに「ターゲティング問題」というものも出てくる。

2.5.6 基地推定

敵を発見した場合に、敵の基地を推定することがある。

ゲームによっては、展開をスピーディーにするために敵の基地も既知のものとする場合もあるが、そうではないものもある。

ここでは、敵に遭遇した事象から「ベイズ推定」を用いて推定する過程が説明されている。

2.5.7 決戦、ユニット間のコミュニケーション

敵の基地を攻撃するために、ユニット同士を協調させる。
正直、この手のゲームをしたことがないので、そこまでやるのかぁと感心した。

複数のキャラクターを協調させる技術を「マルチエージェント技術」と呼ぶらしい。 (1.1.1 のストラテジーゲームの分類でも出てきた)

手法としては二つあり、以下のようなもの。

  1. ユニットメンバー同士でメッセージを送り合い協調
    • エージェント用のコミュニケーションランゲージを用いる
  2. 上位の AI が各ユニットに指令を出すことで協調

アカデミックでは (1) が多いらしいが、ゲーム産業では複雑化を避けるために (2) を使うことが多いらしい。
いずれにしろ、コミュニケーションの流れを整理しないと情報の同期もできなくなるため、不具合が起きてしまう。

(2) の場合だと、チームAI にさらにそれを管理する何かがいる感じだろうか?または戦略AI がそれを担うのだろうか。と思ったらそれも書いてある。

「メタAI」「チームAI」の2つの手法がある。
おそらく「チームAI」はここまでで出てきた戦術AI・チームAI と同じものだと思う。敵・味方のどちらに属すか決まっていて、チームのキャラクターに指示を出す。想像と違ったのは、このチームAI は各チーム(ユニット)に対してのみ影響があるのではなく、複数のチーム(ユニット)に影響を及ぼせるということ。

「メタAI」は初めて出てきたが、ゲーム全体をコントロールするらしい。つまり、敵・味方は関係ない。
ここでは、天候やイベントのコントロールも含まれいるが、どの程度までゲームに影響を及ぼすのかは分からない。おそらく、ここの「決戦のためのユニット間コミュニケーション」に使うものというよりは、ゲームを盛り上げるための何かのような気がする。

面白い点として、キャラクターは「メタAI」「チームAI」から命令を受けるだけではなく、自分の周囲の情報を報告したり、行動の許可を申請したりもするらしい。

2.5.8 攻撃位置を決める、攻撃タイミングを同期させる

ここは計算式を使って判断(意思決定)させる例が出てくる。「ユーティリティ(効用)」という指標を使って、計算結果の妥当性を調整するようだ。

2.5.9 例題のまとめ

最後に、例題に沿って必要になった各人工知能技術が一覧されている。

まだ序章で説明されている内容が少ないとはいえ、多いな!という感想に尽きる。

ただ、ゲームエンジンを使う上でもこういう用語や分類、基礎知識があるだけで検索ワードやディレクトリの階層分けなどが捗りそうで、かなり良さそうに思う。

ASUS TUF Gaming F15 FX507ZV のメモリと SSD を増設した

先日セットアップした PC は ASUS TUF Gaming F15 FX507ZV でした。(バリエーションがあり過ぎる。。)
以下のページに一応スペックの比較表があります。

ASUS TUF Gaming F15 (2023) - Tech Specs|Laptops For Gaming|ASUS Global

そもそも娘と共有のサブマシンという位置づけだったので、メモリ 16GB 、SSD 512 GB でまあいけるかなと思っていたのですが、Unity 動かすとメモリが結構きついなと感じたので増設することにしました。

メモリ SSD
Crucial P5 Plus 1TB SSD PS5 Crucial 64GB Kit (2 x 32GB) DDR4-3200 SODIMM

参考にしたサイト

ASUS TUF Gaming A15にメモリ32GB、1TBSSDを増設した - gadgetpcgame’s diary

メモリと SSD 選びは上記を参考にしました。
実際の取り付けに関しては、レイアウトが FX507 と異なっていたのでそのままは適用できませんでした。

www.youtube.com

多少バージョンは異なりますが、メモリや SSD のレイアウトもほぼ同じで、ほぼこの動画を見ながら作業しました。

メモリのヒートシンク

メモリは元々刺さっていた 8GB x 2 のヒートシンクをそのまま剥がして利用しました。

SSD に関しては、一応別途ヒートシンクも買っていたのですが、厚み的に微妙な感じがしたのでそのまま挿しました。

結果

以下のようになりました。よしよし。

久しぶりに Windows の環境構築

子供と自分用に共用で一台ノートを買ったのでその環境構築のログです。

基本

OS: Windows 11 Home

キーボード・入力周り

IME

Google日本語入力

macOS の方は Google 日本語入力やめたのですが、Windows はまだ少し足りなかったので。

Ctr2cap

Ctrl2cap - Sysinternals | Microsoft Learn

どうして capslock はその場所にいるのか。。

VIA

Releases · the-via/releases · GitHub

Keychron を使っているのでインストール。

alt-ime-hack

Releases · karakaram/alt-ime-ahk · GitHub

Keychron のキーボードは MacBook と合わせてスペースの両サイドに alt (mac の場合は CMD) が配置されるようにしていて、macOS の方も CMD の単独クリックで IME が切り替わるようにしているので、同じようにできるようにします。

このあたりは、マシンが変わっても接続するキーボードは同じキーボードなのでなるべく同じ操作感になるようにしています。

alt-ime-hack は起動時に動いてほしいのでスタートアップに配置。

ULE4JIS

ULE4JISの詳細情報 : Vector ソフトを探す!

私は US 配列の MacBook を使っているのですが、今回子供と共用なので JIS 配列を買いました。

なので、@ の位置などを合わせるために導入します。以前は会社の支給PCと自分のキーボードのミスマッチの解消のために使っていたなぁと思い出しました。

こちらもスタートアップに配置します。

スクショをキーボードのマクロに登録

小ネタですが、Keychron Q11 の MACRO キーに Snipppig Tool のコマンドを登録しました。すぐ忘れてしまうので。。

Clibor

Windowsクリップボード履歴でもいいのだけれど、便利なので使っている。

応援・寄付のお願い | Clibor

公式サイトのリンクを探していたら、寄付の受付があったのでお礼として送ってみた。(メールアドレス間違ってないといいけどな。。)

scoop

GitHub - ScoopInstaller/Scoop: A command-line installer for Windows.

何はなくともまずは scoop 。といってもなんでもかんでも scoop で管理しているわけではなく、気づいたらインストーラーから入れてるものとかよくあります。

Git

scoop がインストール時に入れてくれますが一応アップデート。

> scoop install git

続いて Github CLI

> scoop install gh

長らく SSH で git を操作していたのですが、最近関わったプロジェクトで git の submodule が https で書かれていて、https で接続するしかなくなったところで Github CLI を使うようになりました。便利。

ターミナル

10 年ぐらい Cmder を愛用してきたのですが、Windows Terminal がだいぶこなれてきたのかなというのもあり、まずはこれで行くことにしました。(と書きつつ、vi とか cat とかさくっと打てないので早くも心が折れそうになってる)

Nushell + Starship

Nushell + Starshipで最速Windowsターミナル環境構築(2022)

上記の記事に感化されて導入。

> scoop install nu
> scoop install starship

Starship と Nushell の連携についてはまだ安定してなさそうです。とりあえず環境変数から設定ファイルを開いて編集。

> code $nu.env-path
> code $nu.config-path

Aliases | Nushell
上記の $nu.config-path の最後に alias g = git のように追記しておけばエイリアスを追加できる。

Nodejs

個別の言語についてはこの記事の関心ではないのですが、Zenn に記事を書くために Node が必要だったので。

nvm

GitHub - coreybutler/nvm-windows: A node.js version management utility for Windows. Ironically written in Go.

> scoop install nvm

インストール後に一度ターミナルを再起動。実はここで環境変数 (NVM_* )が設定されているようでそれを読み込む必要があります。

> nvm list available
> nvm install 必要なバージョン
> nvm list
# インストールされているか確認
> nvm use インストールしたバージョン

Task

Installation | Task

macOSWindows の混在プロジェクトだと、なにかと役に立つタスクランナー。

> scoop install task