2019年神奈山県立ハイ高等学校は 地盤が弱く校舎の老朽化も進んだため、 とうとう廃校にする以外方法がなく なってしまった。

ところで大変な情報を手に入れた。 それは、

「ハイ高校にＡＴＯＭＩＣ ＢＯＭＢが仕掛けられている。」

と、いうものだ。 どうやらハイ高が廃校になった時、 気が狂った理科の先生がＡＴＯＭＩＣ ＢＯＭＢを 学校のどこかに仕掛けてしまったらしい。

お願いだ。我が母校のコナゴナになった 姿を見たくはない。 早くＡＴＯＭＩＣ ＢＯＭＢを取り除いてくれ……！！

行動は英語で、“<動詞>” 或いは、“<動詞>”+“<目的語>“のように入れていただきたい。 例えば、”look room”と入れれば部屋の様子を見ることが出来るという訳だ。

それでは Ｇｏｏｄ Ｌｕｃｋ！！！…………

様々なプラットフォームに移植し続けているハイハイスクールアドベンチャーですが、待望の(?)Windows版の登場です。 ハイハイスクールアドベンチャー SDL版を作った勢いを買って、Windowsネイティブ版を一気に作り上げました。

開発は Visual Studio 2022 Community Editionを使い WPF版として実装してあります。

インストーラを作ってないので、GitHubから一式を取り出したら、VIsual Studioでビルドし、AppData\Local\HHSAdvWin を $env:LOCALAPPDATA\HHSAdvWin にまるっとコピーしてから実行してください。 そのうち気が向いたらインストーラを作るかもしれません。

インストーラをダウンロードして展開したら、Setup.exe を実行してください。

初回実行時に、データフォルダを勝手に作って勝手にデータを放り込みます。

あとは High High School Adventure for Windowsをメニューから起動してください。

Windows版は、ほぼハイハイスクールアドベンチャー SDL版からの流用でできています。 このゲームの実装に当たっては、ダブルバッファを使って、任意のピクセルに点を打ったり、打たれた点の色を読み出したりできるかどうかが鍵なのです。

SDL2版を作ったときに、もうこれでWindows版っていっていいんじゃないのか？と思ったのですが、SDL2-CS.dll, SDL2.dll, SDL2_ttf.dll, SDL2_image.ddl, そして SDL2_mixer.dll ととにかく依存するライブラリの多いこと。

遊ぶための手順が多いのと、そこら辺からDLLを拾ってくるリスクを考えると、やっぱりネイティブ版を作った方がいいのではないか？ そう思ったので、Windowsのビットマップイメージに対して、ダブルバッファでの読み書きが可能かどうか AIに尋ねたら、できるよ、というので、実験コードを作って、思ったように動くことを確認し、一気に移植しました。

そもそも、SDL1番も C#で開発しており、SDL2にべったり依存している部分以外はそのまま流用可能なので、移植にかかった時間は非常に短かったといえます。

SDL2に依存していた描画、サウンド機能、そしてイベントループはすべてWPFのそれで置き換わっています。

さらに、SDL2版では実装がめんどくさすぎてさぼっていた、設定画面を含む、ダイアログなどの様々なウィジェットを利用可能。 実装難易度はSDL2比でずっと低かったです。 最初からこっち作っとけよって感じでした。

オープニングとエンディングでスクロール画面でメッセージを流すのですが、思いもよらぬ落とし穴がありました。 そもそも、この部分に関してはあれこれと問題があったのですが、ようやく想定通りの動作になったと思って喜んでいたところ、まだ罠があったのです。

開発は、自作のデスクトップPC上で行っています。 理由は、Visual Studio入れてるとばかばかWindows SDK関連がインストールされて、あっという間にCドライブを食いつぶすからです。 自作デスクトップにはぜいたくに2TBのSSDをCドライブに割り当ててあります。

まあ、それはいいのです。 このマシンは1920×1080の96DPIの環境なのですが、リビングにある Surface Pro7からRDPして操作することもあります。 こっちのマシンは144DPIなのです。

ことは、デバッグの続きとばかりに、RDPした状態から起動したところ、流れるメッセージの右1/3ほどが欠落、さらに下1/3ほども欠落。 文字のサイズなどは変わってないのに、2/3くらいの領域を残して、残りが黒くなってしまっているのです。 何もいじってないのにどうした？

で、デバッガで潜っていくと、メインウィンドウからDPI情報を引き抜いてビットマップを作るところで144DPIって出てる。 96/144 = 2/3 ですね。 はい、犯人確保！

で、どうしたらいいか AIに聞いたら、いろいろ御託を並べた後に、最終的に、

WPFは96DPIが基本だから96決め打ちにすればいいんじゃない？

とか言い放ってきましたよ！ そもそもメインウィンドウからDPI引き抜いてくるやり方提案したのもあんたじゃんか！

とりあえず、その辺を全部96にしたらあっさり動きましたよ。 DPI指定する意味ってなんなのさ？！

インストーラのなかった時分、遊ぶための手順が多すぎてめんどくさかったわけです。 まず、ビルドしないといけないですしね。

そもそも、SDL2版についてもインストーラを検討したんですが、あれ、SDL2のDLLへの依存性があるじゃないですか。 SDL2-CS.dllについては、nugetで持ってくるのですが、他のは手で放り込んでいるので、再配布とかするときにめんどくさいじゃないですか。

なので、そういう余計な依存性がないバージョンが欲しいなと思ったのも、WPF版を作った理由の一つなので、ここでインストーラを作らないっていうのはなあって思っていました。

めんどくささがわからなかったので「作るかも」みたいな濁し方してましたが、一応朝ごはん食べながら完成させることができる程度のめんどくささでした。

とはいえ、そこそこめんどくさかったので、ここに諸々を記しておきます。

このゲームのデータは、%LOCALAPPDATA%\HHSAdvWin においてある想定です。 なので、インストーラにはここにデータを展開してほしいなあって思ったんです。

で、やり方はありますか～、ってAIに聞いたら「管理者権限でユーザデータ書くとあとあとめんどくさいよ。とりあえずアプリケーションフォルダに突っ込んどいて、プログラム自身でコピーしな。」というようなご宣託。

なるほど。 どうして、Windowsのアプリってば、データフォルダがアプリケーションフォルダにいるのかと思っていましたが、そんな罠があったんですね。

とりあえず、データ用のフォルダがなかったら、作ってデータを放り込んでから動作開始する方式にしました。

インストーラ作るの簡単だよ。 そんな噂をAIから聞いて、Visual Studio 2022にセットアップ用の拡張突っ込んで、プロジェクトを追加したところ、ぼろぼろ問題噴出。

多くは些細な問題だったんですが、致命的なのはEXEがパッケージされない問題。

DLLはいくのに。

AIに聞いたら、「ライブラリプロジェクトじゃないの？」とかいうわけですが、そんなことない。 ちゃんとWPFのアプリケーションプロジェクトになってる。 そもそもEXEは生成されているのだ。

最終的には、それはWPFのNETプロジェクトに関するあるある問題で、理由はよくわかりませんがEXEを生成物として認識できないらしいのです。 じゃあどうするかというと「発行」という機能を使って、ビルドしたものを「発行」してやって、発行されたものをインストーラに突っ込むというやや迂遠な処理をすればいいらしい、ということがわかりました。

そもそも、ちゃんと認識しろよって思うんですけれどね。