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

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

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

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

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

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

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

Android版勝手アプリです。 Google Play Storeには登録していないので、インストールにはちょいとひと手間かかります。

Android 12, 13, 14での動作は確認しましたが、他のバージョンでの動作については不明です。

こちらからAPKファイルをダウンロードして、インストールしてください。

AndroidはもともとはJavaを主たる開発言語としていたが、現在は Kotlinもサポートしている。 というか多分 Kotlinが推奨される言語だと思う。

なので、ハイハイスクールアドベンチャーもKotlin化すべきかと思ったのですが、他のことも忙しかったので、できるところから。 ということで、KotlinとJavaの混在になってるのが現状である。

新しく書き足すものはKotlinにしていたのだけれど、さすがに混在していると、自分が何を書いているのかわかりにくいし、Java部分とやりとりするために @JvmFieldをプロパティにつけて getter/setterを抑制したりめんどくさい。

なので、全面的に Kotlinにした。

その過程で、あれこれ問題が噴出したのでここに整理しておく。

基本的に、Java → Kotlinのコード変換はAndroid Studioが面倒を見てくれる。 もともと Javaのプリプロセッサみたいな形でスタートしたので、変換は大体大過なく行われる。

ところが、理由は不明だが、EditTextウィジェットにくっつけていたリスナーがごっそり抜け落ちていた。

とりあえず、欠落した部分は自分で補ったが、他にも抜けている部分があるかどうかはわからない。 ゲームはクリアできたので特に問題はないとは思うが。

全面的にKotlin化したら、なぜか落ちるようになった。 それもランダムに。

AIに尋ねたら「メモリ不足か、NDK側のコードのバグで不正なアクセスをしているか、無限ループなどでOSから強制終了されているかじゃないか」といわれた。

まあ、メモリーについては結構雑に使っている自覚はある。 Android版の後に作った M5版などでは結構けちけちやっているが、地図データを全部オンメモリで持っていたり、とにかくざっくりなので、その辺を、全面的に書き直して、けちけち使う分だけメモリにロードするように変更したが改善はない。

仕方がないので、デバッガで、ゲームの処理部分をステップ実行で、落ちるまで繰り返して、原因を特定した。

おちるのは先生が現れる瞬間。 ようするに先生の描画で落ちていた。 ランダムに発生するのは先生の出現がランダムだからだ。 それにしても、こんな枯れたコードでなぜ？

で、デバッガで追ってみると、座標がなぜかところどころ負数になっている。

これが原因でペイントなどが破綻して死んでいた。

何故そんなことになっていたのか？

原因は強烈な思い込みにあった。

Kotlinの Byte型は符号付8ビット整数なのだ。 C頭なわたしは、byte_tみたいなやつはすべからく符号なし8ビット整数だと思い込んでいたのだ。

地図や、先生などの画像データは、バイト配列で座標や色コードを格納している。 座標は、まあ、ものによっては127を超えている。 これを、符号付整数として取り出せば、もれなく負数の出来上がりである。

val buf: ByteArray
...
var o = 0
...
var x = buf[o++].toUByte().toInt()
var y = buf[o++].toUByte().toInt()
...

のように、いったん、UByte型¹⁾に変換してから、整数に拡張すれば問題は起きない。 肩の定義は言語ごとに類似性はあっても独自のものであるので、先入観はすててちゃんと調べないとダメ。

Android StudioというかIntellijには KotlinのLintが組み込まれている。 勿論、ありがたい場合も多いのだが、とにかくうるさい。 Javaから移行したコードなので、Kotlinの推奨と違う命名規則などがとにかく大量に引っかかって、改めるべき問題が見つけにくいのだ。 勿論、すべてが改めるべきものだ、というのはそうなのかもしれないが。