Contents — 8 sections
Procedural GenerationでMapを300個作れるようになった。
次に困ったのは、
どれを選ぶか。
全部を人間が開いて見るのは重い。
かといって、壁の数や見た目だけで決めても、跳弾ゲームとして面白いかは分からない。
そこでRicochetTanksでは、Mapの良し悪しをいくつかのProxy Metricへ落とした。
まず「開幕で一方的に撃たれないか」
最初に見たのはSpawn直後。
片側だけが、動く前から安全な一回反射射線を持っていたら不公平になる。
そこで、
開幕の被弾方向数
を評価した。
上位候補では、ここが0になるものを優先した。
40×32の上位候補だったseed 53も、開幕の被弾方向は0だった。
中盤で一回反射が成立するか
RicochetTanksの核は一回反射。
だからMapが安全でも、
「結局まともな跳弾射線がほとんどない」
なら意味がない。
中盤の点対称な位置ペアについて、
一回反射で相手へ届く組がどれくらいあるか
を数えた。
40×32 seed 53では、対象組の64%で一回反射可。
32×26のseed 156では96%だった。
ただし、これだけで高scoreにすると別の偏りも出る。
同じ壁ばかり使うMapも避けたかった
一回反射できても、毎回同じ一枚の壁しか使わないなら、遊びが単調になる。
そこで、
実際に射線へ使われる反射面の種類数
も取った。
第2版の合格候補では、
- 32×26: 5〜16面、中央値8
- 40×32: 6〜23面、中央値12
だった。
seed 53は14種類。
単に「反射可能」だけでなく、
どの壁を使えるかの多様性
も候補選びへ入れた。
最初の脅威までの時間も見た
さらに、
「ゲーム開始から最初に脅威が成立するまで」
も取った。
第2版では、
- 32×26: 1.5〜4.9秒、中央値2.6秒
- 40×32: 1.5〜5.7秒、中央値2.2秒
だった。
長すぎると何も起きない。
短すぎると開幕事故になる。
その間に置きたい。
Scoreは「面白さ」ではない
ここは一番重要。
これらの数字で、
面白いMapを自動判定できたわけではない。
中盤の反射評価は2Dモデル。
Unity Physicsそのものではない。
実VRChat Clientでもない。
人間の読み合いも入っていない。
だからscoreは、300候補を並べるためのProxy。
最終判断は人間へ残す。
上位3件だけScene化した
40×32では、上位候補として
- seed 53
- seed 291
- seed 266
を確認用Sceneへ出した。
全部をScene化しない。
生成→機械評価→上位だけ人間確認。
この流れにしたことで、人間が見る量をかなり減らせる。
Proxy Metricは偏る
実際、score上位は障害物が少なく開けた配置へ寄る傾向もあった。
つまり、
測るものを増やすと、その指標に最適化されたMapが出る。
Scoreは便利だけど、目的関数そのものが偏っていないかも見る必要がある。
いまの結論
Procedural Generationで大事だったのは、Mapを大量に作ることだけではなかった。
人間が見る前に、何を数えて並べるか。
RicochetTanksでは、
- 開幕安全
- 一回反射可否
- 反射面の多様性
- 最初の脅威までの時間
をProxy Metricにした。
それでも最後は人間が見る。
Automationは決定を奪うより、候補を減らすために使う方が扱いやすかった。
Signal / 観測記録
この記録への観測を送る
反証、