Burnhouse Lane #2 Endings

Burnhouse Laneは、隠されていない実績の一つにGolden Endingがあり、マルチエンディングの存在が示唆されている。もちろん、過去作にもそれらは存在しており、プレイした人にとってはお馴染みだろう。
それらエンディングの条件について。

今作では、Golden Endingの条件は多岐に渡り、単一スロットのセーブポイント制になったこともあるため、意識しないでそれに辿り着くとことは困難になっていると思われる。Downfall (2016)もそれが難しいのだけれど、The Cat LadyとLorelaiは初見でも不可能ではないだろう。

なるべくプレイ経験を損なわないように本当に核心的なことは省略して記述しているが、以降ネタバレあり。

続きを読む →

Burnhouse Lane #1 First Playthrough Impressions

Devil Came Through Here Trilogy というか、名作 The Cat Lady (以降 TCL)とそのシリーズ(Downfall, Lorelai)の、Harvester Gamesの新作 Burnhouse Lane。

タイトルメニューからすぐにアクセスできる Extras には謝辞や色々書いているんだけれど、Burnhouse Lane は当初 The Cat Lady 2 として開発されていたことが記載されている。実際にプレイしてみるとTCLを彷彿とさせるエッセンスが至る所にあって、むしろどうして2としてタイトルしなかったのかを知りたくなる。

以降、軽微なネタバレを含む。

続きを読む →

Note: Real-time GPU Color Quantization

https://github.com/longod/pixelism

Compute ShaderでModified Median Cutを実装してGPU上でColor Quantizationをリアルタイム実行可能にしたので、その際に調べたことの一部を整理しておく。

Introduction

Color Quantizationとは、要するに画像の減色処理のことだ。
ここではさらに狭義のIndexed Color(カラーパレット)を使用して任意の色数未満に収める処理を扱い、さらにそのIndexed Colorを求めることにフォーカスしている。

昨今では、ハードウェアリソースが潤沢になったこともあり、Indexed Colorを使用してまで減色する必要性は減り、研究分野としてもやはり比較的ニッチになっている。そのため伝統的なアルゴリズムも結構通用する。伝統的ゆえに、特に最適化せずマシンパワーに任せて強引に実行しても、“一般的”にリアルタイムな処理速度で実行できてしまう。
ここでいう一般的とは、画像処理ソフトとかで減色したときに何分何時間も待つような規模ではなく、人間がストレスなく完了を待つことができる秒単位の実行時間のことである。

しかし、ゲーム的な意味での真のリアルタイムとなると話は別である。60FPS実行されるゲームの場合、16.6ms以内にすべての処理を完了させなくてはならない。
このミリ秒単位の時間内に、CPU上でIndexed Colorを普通に求めようとしても、まだ収まりきらないのが昨今のマシンパワーである。今ではニッチな研究分野であると述べたが、高速化においてもそこまで発展していない。掘り下げていく余地がある。
今回、ベースラインとして並列処理で最適化したModified Median CutのCPU版も作成してあるが、フルHD(1980×720)のような解像度となると、16色のIndexed Colorを求めるにも20ms以上要している。伝統的なシングルコア実行だと言うまでもない結果だろう。

Pixelismでは、工程の最初から最後までGPUをCPUとの同期無しに活用することで、16ms以内の実行を達成している。それどころか2ms程度で済む。リアルタイムレンダリングの感覚としては2ms”も”なんだけれど…

Median Cut

Median Cut は1980年にPaul S. Heckbertによって考案された、代表的なColor Quantizationアルゴリズムの一つだ。40年前のアルゴリズムだが今日まで通用する優れたアルゴリズムだ。名前の通り、中央値を用いて分割していく。

Bad Median Cut

さて、どこで誰が言い出したのをコピペしてまわっているのかどうか知らないが、ネット上で言及されているいくつかの Median Cut アルゴリズムはいい加減だ。それらは、大体次にようになっている。

  1. 画像の全ピクセルを処理しやすいように一次元配列にする
  2. ピクセル配列を調べてRGBのうち最も範囲が大きいチャンネル調べる
  3. 2で求めたチャンネルをキーとしてピクセル配列をソートする
  4. 中央値で分割する
  5. 最も大きい配列を次の分割対称とする
  6. 所定の数になるまで2~4を繰り返す
  7. それぞれ平均値を求めて最終的なカラーとする

だが、コピペする前に少しは自分の頭で考えて欲しい。Median Cutアルゴリズムが考案されたのは1980年だ。今日のPCと比べて当時のスパコンですら処理速度が極めて低い時代だ。そんな時代に、1回の分割をするたびに、(2)で都度大量のピクセルを捜査 O(N) して分割軸を求めて、あまつさえ(3)で大量のピクセルをソート O(N logN)していただろうか?
1980年はそんな富豪的なことが許容されていた時代ではないはずだ。

Original Median Cut

では、本来の考案されたアルゴリズムとは何か。発表元の論文を読めばよいのである。古い時代のものだが、幸いにもPaul S. Heckbertご本人がウェブサイトで公開しているので、ACM会員にならなくとも読むことが出来る。

http://www.cs.cmu.edu/~ph/

  • Color Image Quantization for Frame Buffer Display, SIGGRAPH ’82, July 1982, pp. 297-307. (Postscript, missing figures)
  • Color Image Quantization for Frame Buffer Display, Bachelor’s thesis, Architecture Machine Group, MIT, May 1980, 57 pp. (text file, missing most equations, and all 20 figures). My 1982 paper above is based on this work. For a complete copy of this thesis, contact the CMU or MIT library.

これで述べられている Color Quantization 全体は、次のような工程で行われる。

  1. 元画像をサンプルして色の分布を求める
  2. 分布情報を元にカラーマップを選択する
  3. 元の色に最も近いカラーマップをマッピングする
  4. カラーマップを適用して量子化する

このうち Median Cutなどのカラーマップ(Indexed Color)を求めるアルゴリズムは(2)にあたる。

  • 分布情報には、RGBそれぞれ5ビットからなる15ビットのヒストグラムを用いる。
  • RGB各要素の最小最大値からなるboxを分割する。
    • 分割対象となるboxをどのように選択するか、については具体的に明記されていない
      • 直前に既存手法の The Popularity Algorithmを比較対象として挙げていることから、暗黙的にPopularity、すなわちピクセル数を指標としているようである。
  • 分割は、RGBのうち最も範囲の広い成分を対象として、名前通り中央値を使用して分割する。

ヒストグラムを求めておけばそれを参照することで、都度ピクセル全てを捜査することもなく、ソートも必要ないのである。

ヒストグラムにおいてRGBの各チャンネルを一旦8ビットから5ビットの計15ビットに減らすのは、当時のコンピュータが16ビットであり、これに収まることが主要因である。64ビット時代の現代においては、この5ビットに縛られる必要は無く、パフォーマンスとメモリを考慮してビットを決定すればよさそうである。
また、切り捨てられる3ビット分は、Popularity Algorithmを実装した当時のプログラム「IMAGE」では、(3)を高速化するためにハッシュとして使用されていたようだ…が、このプログラムは現存するのだろうか?
IMAGEでは、全工程を実行するのに2.5分要している、とも記述されている(恐らく512×512程度の画像)。いかに富豪的なアルゴリズムが当時現実的でないことが読み取れる。

ところで、ネット上の実装では、分割成分の決定において知覚的な色の選択としてR=1.0, G=1.2, B=0.8の重みがつけられていることがある。この数値の出どころについて誰も言及がなされていないが、論文内で改善手法の一つとして言及されており、Limb, J. O., C. B. Rubinstein, and J. E. Thompson, “Digital Coding of Color Video Signals – A Review,” IEEE Trans. on Communications, Vol. COM-25, No. 11, Nov. 1977, p. 1349. が元ネタであることが分かる。
残念ながら、この参照元の論文は読むことできなかったので、どのようにしてこの重みが提唱されたのかを知ることが出来なかったが、あくまで個人的な見解となるが、もっと良い値があるのではないかと思う。キリが良すぎる。

Modified Median Cut

Modified Median Cut は、Dan Bloomberg によるMedian Cutの改良版の一種である。改良点は以下のとおり。

  1. 分割時に中央値を新しい領域の範囲とするのではなく、(中央値-最小)と(最大-中央値)のいずれか大きい方の、さらにその中央値を分割値とする。
  2. 分割対象を選択する際に、最大となるピクセル数と、最大となる (ピクセル数 x 体積) を併用する。これらは係数によって割合を決める。

(1) は、分割時になるべく大きい方の領域が残らないようにしていき、小さい方の領域をなるべく維持していくことで、色の再現性を上げるという試みだ。

(2) は、色の分布状態によっては小さい領域に大量のピクセルが含まれているとき、そこが支配的になりその領域ばかりを分割しようとして、広範囲に分布する領域に対して分割が行われないという問題を解消するためだ。
この問題点は、Weighted median cut quantization and its applications でも指摘されていて改善が試みられているようだ。

Implementation on GPU

以上を踏まえて、Modified Median Cut を Compute Shaderで実装したが、ヒストグラムに使用するビット数をRGB各4ビット、計12ビットに減らしている。
これは、Thread Group Shared Memoryを使用した高速化を行う都合で、このメモリの最大値16kbないしは32kb(今どきはこちら)に収めるためだ。15ビットだと 32,768 * 4-byte = 131,072 bytes = 128 kbで超過するが、12ビットだと 4,096 * 4-byte = 16,384bytes = 16 kbと丁度収まるようになっている。

この世の果てで恋を唄う少女YU-NO (2019) #1 Double Direction

Steam版は2019年。移植元のリメイクは2017年のPS4, PS VITA版。
このPS版のリメイクが発表されたとき、どれくらい原作に忠実につくられるのか懐疑的だったし、そもそもPS4もVITAも所有していないので見送っていた。しかし、最近知るところによると、サターン版にかなり近いらしい。

少しプレイした感じだと、原作をリスペクトしていて良いと感じられる部分と、逆に全くそうでない部分が混在していて、まるで原作の理解度が異なるディレクターが複数人いて、それぞれでちぐはぐな判断になったのかなという印象がある。
以下は、PC-98版、サターン版プレイ済みでそういう観点での良し悪し。

良い

  • BGMは控えめにリミックスされていて違和感はない
    • それでも気に入らなかったら原作版に切り替えられる
  • キャラクターボイスはサターン版の声質を意識しているのか、似た感じで違和感があまりない
    • 特にたくやは若すぎず、渋すぎず、檜山修之のようなヒロイックさは無いが雰囲気は似ている
    • 存命の人は同じキャスティングでも良かったんじゃないかな
  • ヒント機能が便利そう
    • 切り替えもできるので、初見プレイなら無効でプレイして欲しいんだけれど、既にプレイ済みの人は最初から有効にして快適にプレイできそう。
  • クリック可能なポイントが全て表示されている
    • Point & Click できないデバイスの都合上こうしたようだけれど、無意味なクリックが減るので快適。初見プレイの人はしらみつぶしにクリックや選択肢の総当たりすることを味わって欲しい気もするけれど、今どきそれは厳しいという判断だろう。
    • 沢山表示されるとゴチャゴチャした感じはあるし装飾が過剰気味だし、キーボードやパッド入力だと鈍いカーソル移動じゃなくてもう瞬時にポイント上に移動して選択状態にすればいいじゃないかと思うが、全体的な印象はよい。

悪い

  • イントロデモ(アトラクトデモ)が無い
    • まず最初に期待しながらしばらく放置したんだけど…いきなりがっかり。
  • 代わりに、プロローグシーンが済むとムービーが流れるんだけれど、MAGESのゲームでお馴染みの、社長が作った有難い曲を流したいだけのイメージムービーに変更
    • 原作だと、広大の行動をたっぷり意味深にBGMに合わせてアニメーションさせるのに、そういう感じも無くただただネタバレダイジェスト
    • メタ攻略部分がほんの一瞬しか流れない。初見の人はまず見落とすし、記憶にも残らない。また、カットされてる内容もある。
    • しかも、ゲーム内でリプレイできない。ネット上で見られるけれど、そんなのは能動的に見にいかないといけないから駄目。
  • アートが見劣りする
    • キャラクターデザインは好みが分かれるところだが、割と(5年前の)今風でデフォルメされて情報量が少ないせいだろうか、原作よりも低彩度で描きこみ量が少ない。
      • それに合わせてか、背景も情報量が少な目になっている
      • さらに表情アニメーションの都合で塗りが簡素化されてしまっている
    • 個人的には、諸々の要因が合わさって全体的にヘタクソに感じる。 原作の方が魅力的だ。
      • キャラクターデザインの人が普段描くアートは知っていて、それよりも上手くないように感じられるので、全体の制作工程によるものだろうか。
  •  UIが世界観無視
    • リフレクターデバイスが画面上に常時表示されない
      • A.D.M.S.起動はただの文字ボタン
    • 鏡にいたってはUI上に全く存在せず、セーブはシステムメニューからペンのアイコンを選ぶ
      • ゲーム内に鏡が出てきても全く意味不明なんだけれど、プレイしたことあるの?
    • 無意味に不透明で過剰なウインドウ装飾でその背後が見えない
      • PC-98の頃は制約上ああいう風になってるだけなので

どちらとも言えない

  • 全体的にリメイク感があるのに、テキストだけは原作ママでいわゆるelfのエロゲーのノリで進むのがチグハグで違和感があるかもしれない
    • しかもフルボイスなのでテンポが悪い。馬鹿正直に読み聞きするようなダイアログじゃないぞそれ。
    • リメイクではなくて、全体的に忠実な移植にしないと解決が難しいと思う。

Disco Elysium #1 Bone-box

訳すの大変だっただろうなあ。
レイアウトが崩れたり、英語固有の表現に苦心しているのを感じられたり(翻訳方針として原文を重視しているのか、全く違う意訳にはならない)、ゲームでは珍しい訳注がときどき押しつけがましかったりするけれど(ゲーム内にglossaryがあれば良かったんだけれど)、期待以上の出来栄え。言語切り替え機能があるから、気になったら原文で確認できるしね。
以前に英語でやっていたんだけれど、一般的なゲームのような会話形式じゃないから、コンテキストが跳躍しがちで読むのが難しい。過去に文章が難解で量も多い Planescape: Torment を英語でやり通していてもそう思う。根気が必要だ。

このゲームは、さながら大人数で会話しているというニュアンスがあっているかもしれない。そいつらは気まぐれのように会話の主軸に沿ってお喋りすることもあれば、そうでないことも多々ある。そのため、テキストの大部分は読み飛ばして無視しても問題が無いし、対応する選択肢を適当に選んでもストーリーに影響を与えたりしないので、要点となる文章さえ押さえておけば話は分かるようになっている。
だがそれだと、このゲームらしさを堪能することが出来ない。そう思っていたころに、丁度日本語版のアナウンスがされたので待つことに。

最初からやり直して、前進めていたところくらいまで戻ってきて、改めてうーん…なところ。

スキルの上げ時がよく分からない。
頻繁にスキルチェックに成功したり失敗したりするけれど、失敗しても大抵は進行に支障がないからだ。経験値を得る機会を失っているようにも見えないし(そういうケースもありそうだけれど)、別の解決方法が用意されている。初期状態のまま進んで行けてしまう。
恐らく、キャラクタービルドに高い自由度があるため、どんな適当なビルドでもクリアできるようになっていると予想している。

スキルチェックが不定の確率ベースなのがイマイチ。
“コンピュータゲーム”なので、現実的な確率のスキルチェックはリロードでなんとかなってしまう。リロードするだけ時間の無駄である。ファンブル、クリティカルもあって絶対成功しないということが無いので、極めて低い確率でもなんとかなってしまう。それは意図的にそういう難易度にしてあるのでやらないけれど…
ハードコアモードよりも乱数固定モードがあった方が良かったんじゃなかろうか。

Thought Cabinet の説明が不足していてよく分からない。
ストーリーを進めると、チュートリアル的な状況は出てくるんだけれど、それをやっても説明されないことが多い。そして、初回プレイにおいては使用を躊躇させるようなことだらけで、良いデザインとは思えない。

  • リサーチは時間を要するので、そのために積極的にリサーチして使っていくのか、詰まったときだけ要所で有効にして使っていくべきなのか(リサーチやその結果はあくまで副産物)、想定された使用方法が分からない
  • リサーチ完了後の結果が全く予測できないし、その結果は必ずしも有効ではなく不利になる要素もある
  • 最大数は有限である
  • リサーチ完了後にそれを忘れるにはスキルポイントが必要(これはtipsみたいなところにあったかな)

つまり、時間をかけてリサーチしないと効果が分からないが、効果を把握するためになんでもかんでもリサーチしていると後で困るという問題を抱えている。