SVX日記

　 世はAI流行りである。

　 計算機の最底辺部分から理解している自分からすると、平均的な日本人のAIに対する期待は少々過大であるように感じる。まぁ、自分が現在所属する「割と日本を代表するIT企業である○○」の平均的な社員のそれも、ほぼ似たようなものと感じるので、無理もないところであろうが。

　 IT技術に関する知識レベルが完全にゼロである自分の母親は、8bit機が主流の頃ですら「(オセロなどで)コンピュータに勝てるわけないでしょ」とノタマっていた。総じて仕組みに疎いほど、仕組みに対する期待が高い傾向にあると言えるだろう。そういうことなので自分のAIへの期待は平均よりだいぶ低い。それらしく模倣をしているだけにしか見えないのだ。まぁ、それらしく模倣ができることはスゴいことなのだけれど。

　 そのように、ややAIに対して否定的な自分であるが、なぜか「AI調査チームの長」をやらされることになった。あまり積極勧誘もしなかったのでメンバも数人。チーム名は「AIを診る会」と命名した。「診る」とか「桜？」とかいうあたりに皮肉を込めている。仕事の一環ではあるが、楽しむことが第一、という基本方針。そうしても咎められないし、関連書籍もホイと買ってくれるあたりは、ウチの会社もそこそこだと思えるが。

　 基本、自分はメンバを誘導することが責務なのだが、自分で手を動かさずにいるのは性に合わない。なので、少しは何かをやろうと、買った書籍が「初めてのTensorFlow.js」であった。やはりAIの基本は多項式。Pythonには吐気がするが、CoffeeScriptがある限りJavaScriptが許せるという自分にとって、JavaScriptでTensorFlowが使えるというのは天の恵みと思えたのである。

　 ところが、だ。この本は内容が薄い(と最初は思った)。サンプルを動かすだけで、肝心の機械学習の方法についてほとんど触れられていない。機械学習を行う記述がないまま、画像認識に進んでしまっている。そういう「使うだけ」っていうのは、自分の指向ではないのだ(と最初は思った)。

　 んが、実際にサンプルを動かしてみて気づいたのである。既に「AIはゼロから組み上げるものではないのだ」ということに。暗号通信を伴うプログラムを作る時、暗号技術の学習から始めるべきか？ 3D表示を伴うゲームを作る時、ベクトル演算の学習から始めるべきか？ ノーである。普通は既存のライブラリを使うべきなのだ。写真中の物体識別を行いたい時は、それ用の既存のモデルである「Inception v3」を使うべきなのだ(いや、基盤部分に取り組むのも価値のある仕事だけれども)。

　 今回、AIの調査を始めて最大の収穫が、上記の事実に気づいたことなのであった。それに気づいた後に「初めてのTensorFlow.js」を読み直せば、実にバランスのよい内容であると思える。実用的な使い方を示した後には、訓練方法にも触れているし、既存のモデルに独自の学習内容を加える「転移学習」も扱っているのだから(まだ十分に読んでないけど)。

　 で、写真中の物体識別のサンプルを動かしてみると、なかなかにいい感じの識別具合であり、ムズムズと自分のものにしたくなってくるのである。自分にとって「自分のものにしたくなる」とは、自分が自由に使える状態にするということである。具体的には、ブラウザ上で動いていてもその先はないので、Node.jsで手元で動くようにサンプルを改変し、環境ごとコンテナ化し、PV経由で写真を食わせられるようにし、連続して識別ができるようにし、CoffeeScript化し、結果をテキストファイルに出力できるような状態にする、ということである。

　 というわけで、コンテナの定義ファイルを置いておく。

　 前置きが長くなったが、上記のコンテナを使い、同ブログで2023年に掲載したすべての画像をAIに食わせ「sports car」と判定されたのが以下の画像群だ。

　 期待(の低さ)に反して、ほぼ100%と言ってもいい識別具合である。うぅむ。ちなみに、コンテナは以下のような結果を吐くようにできている。

# 1
carton, /var/lib/pv/svxdiaryimages2023/s20230128_0.jpg, 1
envelope, /var/lib/pv/svxdiaryimages2023/s20230128_0.jpg, 2
packet, /var/lib/pv/svxdiaryimages2023/s20230128_0.jpg, 3
# 2
shower cap, /var/lib/pv/svxdiaryimages2023/s20230128_1.jpg, 1
envelope, /var/lib/pv/svxdiaryimages2023/s20230128_1.jpg, 2
plastic bag, /var/lib/pv/svxdiaryimages2023/s20230128_1.jpg, 3
 :

　 上記までくれば、それをHTMLに変換するスクリプトを書くのは容易であり、変換した結果がこれである。

　 「sports car」で絞り込まず、2023年の全ての写真を判別した結果がこれである。「Inception v3」は海外で訓練されたモデルであり、識別結果は1001の英名詞に限られるので、やや不自然な識別結果も含まれるが、それでも高水準の識別結果であると思える。例えば「ごはん」は「mashed potato」と識別されているが、見た目も位置づけ(?) も大きく間違ってはいない。

　 ちなみに、このブログは外部のVPSで独自に動かしているものなので、手元のコンテナに画像データを食わせるため、VPSの「/home/user」上に「cp -lr」で画像のハードリンクを含むディレクトリを作成し、そこを「sshfs」でリモートmountし、それをPVとしてポイントして処理を行った。なので、今回は画像のベタなコピーを行うことなく処理を完了している。我ながら、これはノウハウだな(別にVPS上でコンテナを動かしてもよかったのだけれども)。

　 また、画像の識別は、内部的に画像を299x299にリサイズしてから行われるので、フルサイズ(主に1200x800)の画像を食わせるのは無駄でしかなく、サムネイル(主に320x213)の画像を食わせている。その場合、識別に必要な処理時間は、ちょっと前のノートPCのCPUパワーでも1枚あたり1秒前後と割と高速である。

　 つうわけで、想定を越えるような結果が得られてしまった感がある。平均よりだいぶ低かった自分のAIへの期待はちょっとだけ上がってしまったかな、悔しいながら。でもさ、やっぱりさ、エンジニアを名乗るなら、生成AIとちょっとお話しをして、お話しのコツを見つけました、なんてレベルでAIを語ってほしくないのだよね。

　 で、ドルアーガである。以前に5機設定でアンチョコ見ながら1コインクリアしたことはあるのだが、天野でアンチョコがない状態を見たら、ムクムクと再挑戦したくなってきたのである。改めて目指すはアンチョコなしオリジナル基板で3機設定での1コインクリアである。

　 以前にも書いたが、若い頃にX1版を買ったりしたことがあるものの、その時はゲームの本質を理解せず、ぜんぜん興味も湧かずに、むしろドラゴンバスターの方が好きだったりしたのだ。実際、ドルアーガは宝箱の出し方の理不尽さがフィーチャーされがちで、アンチョコを見ながらひと通りクリアしたら終わり、的な遊び方をしたプレイヤがほとんどだったと思う。しかし、1コインでクリアしようとすると、改めてそのゲーム性の奥深さに気付かされる作品なのである。

　 誰しもプレイすればすぐに気づくことではあるが、ゲーム性の大半はマジシャン対応なのだ。基本は柱の間で待って呪文を受けてから刺しに行く。しかし、その基本に忠実すぎると残り時間が足りなくなるのである。そこに、他の敵や、宝箱の出し方が絶妙なランダム性で絡んでくるので、実にアドリブ力が試されるのだ。だからこそ繰り返し遊んでもちっとも飽きないのである。つうか、ゲームにこれほどの奥深さを与えるこのマジシャンの特性、いったいどうやったら思いつくんだろう。

　 何十年経っても色褪せない奇跡とも言えるつくりも、それを作ったゲームデザイナ(遠藤雅伸)のスゴさも、とはいえ妙につくりの甘い部分があることも、このゲームが上手いことの価値も、このゲーム性を知っているプレイヤしか理解できないのだが、それでいい。それでいいのだ。

　 つうわけで、天野での1コインクリアを目指し、宝箱の出し方を暗記し、家で練習しているのだが……オレこんなにヘタだったっけ？ 今日はだいぶ調子がよかったが、31面でウィザードに殺された。中央付近に出現するとキツいんだよな、これが。宝箱の出し方の暗記も思った以上に進まないし。

　 改めて考えると、以前の5機設定の1コインクリアも、後半20階をノーミスで抜けているわけで、別に実力ではなく恐ろしいラッキーが重なっただけだったと思える。うーむ、年齢による反応速度の衰えもあるのかなぁ。この調子でいったら「リタイアしたら縁側でゼビウスを16エリアをクリアする」とか無理じゃね!?

　 「姫様"拷問"の時間です」って、なんなんだ？ 「暗殺教室」に負けない不穏なタイトルだな……と思って、期間限定公開されている原作のマンガを読んだら……そんなアプローチがあったとは。こういうナンセンスギャグ、好きなんだよなぁ。すっかり気に入ってアニメを観たら、コレがまた恐ろしくデキがいい。声優さんが熱演すぎるし、1話の最初と最後にソレをそう持ってくるとは。

　 一方で「BASTARD!!」だ。2期がテレビでオンエアされると聞いて、初めて1期の後半をスルーしてしまっていたことに気づいたわ。原作がメチャクチャ好きなのに、デキが微妙であまり乗れなかったんだよな。で、2期の第1話を観たら……寝かけたよッ!! なんでだよッ!! 1期の1話の感想と全く同じだよ。原作の漫画を読み返すと、原作の方が圧倒的にグッとくるトコロまでッ!!

　 軽く「原作のとおりに映像化」っていうけれど「BASTARD!!」は特段の改変もなく「原作のとおりに映像化」されている。でも、何だかわからないが全然ダメだ。一方で「姫様"拷問"の時間です」は、映像化で何倍も輝きを増しているのだ。この差はなんなんだ？

　 考えてみれば簡単なことだ。うまく「翻案」するかどうかだ。いま「脚本家」が渦中にあるが(以下、この文章では原作の映像化に関するあらゆる関係者をまとめて「翻案家」と呼ぶ)、映像化で作品が輝くかどうかは「翻案家」の手腕がほぼすべてなのだ。まさに、上記の例で自分が実感したことだ。「翻案家」は実にスゴい仕事なのだ。「原作のとおりに映像化」なんて簡単に言うけれど、視聴者に「原作のとおりに映像化」だと感じさせるためには、恐ろしくスキルや工夫が必要なのだ。それはきっと並大抵のことではないのである。

　 例の事件に関連して「ただ原作を脚本化する仕事は楽しくない。自分のオリジナリティを発揮するために原作を改変したくなるのだ」という発言を見かけたが、本当にそんなことを思っている翻案家がいるのだろうか？ 上記の例のように、改変なんてしなくたって、オリジナリティを発揮する場所なんていくらでもあるように思えるのだ。例えが適切かはわからないが、ヴォーカリストはオリジナリティを発揮したいからといってメロディや歌詞を改変して歌ったりはしないだろう？ 歌い方ひとつで、オリジナリティを発揮する場所なんていくらでもあるからだ。

　 今回の事件では「原作の改変」に起因して原作者が自殺に至ってしまったとされているが、詳しい経緯について知りもせずに、脚本家の「9,10話を書いたのは私でなく原作者」というコメントが直接の引き金であるかのように語られている。自分はそれに強烈な違和感を感じるのだ。

　 そこに至るまでにはいろいろあったのだろうけど、脚本家が言いたいのは「9,10話のデキが悪いのは私のせいではない」ということだろう？ 9,10話のデキついて少なくない批判を受けたからで、それは脚本家から仕事をムリヤリに奪い取った原作者側が招いた結果だ。改めて考えれば原作者が脚本家にダメ出しして脚本を書くって、前代未聞ではないのか？ 脚本家は猛烈に不快だっただろうことは想像に堅くない。それはやっていいことだったのだろうか？ そこに至るまでにはいろいろあったのだろう。に、してもだ。

　 「ハンロンの剃刀」という言葉がある。「無能で説明できることに悪意を見出すな」という意味だが、それは「悪い結果は悪意の結果と思いがちだ」という傾向の裏返しでもある。原作者としてドラマの出来に不満があったのはわかるが、もしかしたらそこに必要以上の悪意を見出したりしてはいなかったのだろうか。

　 というのも、いくら他人の仕事がマズくても、それが自殺の引き金になるとは思えないんだよね。脚本家から仕事をムリヤリに奪い取ってまで書いた脚本だけど、それでも思ったような結果を残せなかったことの方が、はるかに大きなダメージを受けそうに思える。そりゃ、脚本家に任せていてもよい結果にはならなかったのかもしれないが、餅は餅屋。そこは立ち入るべきではない領域だったのではないだろうか。各々の領域のプロとして、リスペクトが不足していたのはお互い様だったのではないだろうか。

　 自分は自宅を注文住宅として建てたが、刻一刻と進んでいく建築現場で「そこ違う！」ということが何度もあった。しかし、そう思った時点でそう仕上がってしまっているわけで、よほどでなければその修正は言い出せない。複数の人がスケジュールに従って動いていて、その成果物をどうこうするのは半端なく難しいのだ。今回、その結末から、原作者側に立った意見ばかりが溢れていて、そのほとんどは至極もっともな意見なのだけれど、翻案側の価値や立場をまったく考えないのも違うだろうと。

　 つうか、それはそれとして、現在も進行形で松本ワールドをぶっ壊し続けている福井晴敏を誰か糾弾してくれッ!! アイツこそ、なんなんだよッ!! ……ほら、そこッ!! 無関係だと思っているガンダマーッ!! 彼奴がファーストのリメイクの脚本家になってから泣いてもしらんぞッ!!

　 追記。なんだか出版社に問題があったという話になってきている。あー、そっちなのか。そっちもよくない話を漏れ聞くよなぁ。作家ファーストでない出版社なんて存在できないと思っていたが、なんか存在してそうな話だなぁ。まぁ、エンジニアファーストでない企業なんて普通に存在してるからなぁ。

　 自分の職場では、なんやかんやとPC環境の締め上げが続いている。どうもワードエクセルな仕事しか想定していない方策のように見えて、開発系エンジニアの不満は増大しているんじゃないだろうか。なんつうか「セキュリティ事故防止のためならどれだけ効率が下がってもいい」という「健康のためなら死んでもいい」みたいな指向を感じる。まぁそれは上が決めることなのだけれど、上は開発系エンジニアの気持ちを理解していない、もしくは、重要でないと考えている、と受け取られても仕方ない。例え業績が下がろうと、事故の責任を取らさせる可能性を下げたいのだろう。

　 そして遂には「机上のデスクトップPCも全廃」ということらしいのだが……そこで「こんなこともあろうかと」である。フフン。ちょっと前に準備しておいた「リモートデスクトップコンテナ」の出番である。要するに自製の「クラウドデスクトップ」だ。

　 以前に作った「crd」は、それはそれとして完成形なので、日本語対応＋オレカスタムは「crdplus」として「crd」を継承する形でチューニングしていく。とりあえずrubyやemacsやgcc程度を入れたら、アッサリと自製のメーラであるmaveが動き出し、割と普通に仕事環境として使えるようになってしまった。/homeはPVに出してあるので、FirefoxやIMの設定も残るし、コンテナを再起動した場合の影響は想像以上に少なかった。

　 ユーザの登録と英語キーボードの設定は手持ちのノウハウで解決した。困ったのは、時間の経過でTCPセッションが切れる問題と、ブラウザでタブが増えるとページを開く動作が不安定になる問題。しかし、前者は無駄にプロキシを経由していたことが原因で、コンテナ環境側の問題ではなかった。後者はまさかのリソースの問題で、docker-compose.ymlのdeployにresourcesの設定を加えたら、ウソのように安定して動くようになった。最後、言語とタイムゾーンの設定の問題が残ったが、それも起動直後に/etc/localtimeと/etc/locale.confを修正する形で解決。特段、不満のない環境になってしまった。既に数週間程度は使っているが、一度も落ちたりしていない。

　 しかし、だ。完全に原因を特定したわけではないが、頻繁にシフトやコントロールの押下を取りこぼすんだよね。タイプミスを直そうとすてhh……ってなる。上記の環境につなぐ時にはWindoze環境を経由しなければならなんだが、その環境でも起きるってことは、要するにその品質が悪いってことだ。手元の環境では起きないし……TCP使ってて取りこぼす理由がわからない。さらには、また別の環境への移行を求められているんだが、そっちに移行すると輪をかけて遅延が大きくなる。挙句には、センタークリックをすると8秒近く固まってしまう症状もある。控えめにいっても、クソをコネ上げたような環境だといえよう。

　 今に始まったことではないんだが、歳を取るにつれ「作業中に思いついたアイデアを瞬時に忘れてしまい、直前の作業をトレースしたりして思い出す」という頻度が増えてきている。で、そこにデスクトップ環境の遅延が加わると、この頻度を倍増させてしまうのだ。結果、極端な効率低下が起きるので、モチベーションはダダ下がりである。自分は、趣味だろうが、仕事だろうが、基本的には高回転でコトを進めたいのだ。

　 同じ金をもらえたとしても、気分良く仕事ができない環境で作業するのは不満だ……とはいえ、マズローの5段階欲求ではないが、それ以下がある程度は満たされているから感じる不満、と言えなくもないんだよな。うぅむ……。

　 前回「最後、言語とタイムゾーンの設定の問題」をクリアしたかように書いたが、よく見れば、左上のメニューも、ターミナルのメニューも、「Applications」や「File」などの表記のままであり正しく日本語化できてはいない。別に実用上は問題ないのだけれど、ロケールを正しく設定しているにもかかわらず、なんでなの？ という気持ちは残る。

　 で、調べ始めて、最後には解決に至ったのだけれど、これが複雑怪奇。結論だけ知りたい人は、さっさと当エントリの最後にどうぞ。

　 まず、ロケールの設定が不十分である可能性。あまり詳しくないが、様々な切り口で見ても問題が見当たらない。そもそも、メニューの中身の一部は日本語化しているしなぁ。それも意味わからんけど。

# localectl
System Locale: LANG=ja_JP.UTF-8
    VC Keymap: us
   X11 Layout: us
    X11 Model: pc105
 
# locale
LANG=ja_JP.UTF-8
LC_TIME="ja_JP.UTF-8"
LC_MESSAGES="ja_JP.UTF-8"
LC_ALL=
 
# env | grep LANG
LANG=ja_JP.UTF-8

　 気づけば、GUI環境でなく、CUI環境もヘンだ。lsの冒頭が「total」になっている。日本語環境なら「合計」になるはず。

# ls -l
total 12
-rw-r--r-- 1 root root 2162 11月 26 16:48 anaconda-post-nochroot.log
-rw-r--r-- 1 root root  150 11月 26 16:48 anaconda-post.log
-rw------- 1 root root 3533 11月 26 16:48 original-ks.cfg

　 そこでフト、日本語化を含む、多言語化の方式について思い出した。多くのアプリケーションはgettextという共通の枠組みを使って、英語表記を望みの言語表記に置き換えている。その辞書に当たる「言語ファイル」が「.po」から作られる「.mo」ファイルだ。

# strace ls -l 2>&1 | grep '\.mo'
openat(AT_FDCWD, "/usr/share/locale/ja/LC_TIME/coreutils.mo", O_RDONLY) = -1 ENOENT (そのようなファイルやディレクトリはありません)
openat(AT_FDCWD, "/usr/share/locale/ja/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (そのようなファイルやディレクトリはありません)

　 ビンゴ。「ls」の実行時、探しに行っているものの見つかっていない。「言語ファイル」が入っていないことが原因だ。じゃ、その「言語ファイル」はどこに入っているのかというと「coreutils-common」パッケージだ。というか「言語ファイル」は、それを参照する「ls」コマンドと同じパッケージに入っている。つまり、各パッケージを横断して英語表記のままという症状が出ているということは、各パッケージの問題ではなくインストール機構の問題だということだ。

# rpm -qf /usr/share/locale/ja/LC_MESSAGES/coreutils.mo
coreutils-common-9.3-4.fc39.x86_64
 
# rpm -ql coreutils-common | grep ja
/usr/share/locale/ja/LC_MESSAGES/coreutils.mo
/usr/share/locale/ja/LC_TIME
/usr/share/locale/ja/LC_TIME/coreutils.mo

　 しかし、この状況はヘンだ。「coreutils-common」パッケージは入っているのに「言語ファイル」だけ入っていない。パッケージの導入状態を検証する。

# rpm -qV coreutils-common

　 何も出ない。ノーエラー。そんなアホな。冗長モードにする。

# rpm -qVv coreutils-common | grep ja
.........    /usr/share/locale/ja/LC_MESSAGES/coreutils.mo (not installed)
.........    /usr/share/locale/ja/LC_TIME (not installed)
.........    /usr/share/locale/ja/LC_TIME/coreutils.mo (not installed)

　 「(not installed)」と出た。え。入ってないのにノーエラーってどんな状況よ。

　 そこでフト、コンテナ環境の特性について思い当たる。コンテナはイメージ化して持ち運んだりするので、余計なファイルは極力含まれないほうが望ましく、特にサーバ用途に利用する場合に必要度の低い言語ファイル等を含めないような機構があるのではないかと。

　 調べると、dnfには「tsflags」というパラメータがあり、これを指定するとドキュメント系のファイルのインストールがスキップされる仕組みがあるようだ。コンテナ内の「/etc/dnf/dnf.conf」を見ると、確かに「tsflags=nodocs」という記述がある。

　 じゃ、コンテナビルドの序盤でこの記述をコメントアウトしてやればいい……試しに現状の環境でやってみる。

# rpm -qVv coreutils-common
.........    /usr/share/locale/ja/LC_MESSAGES/coreutils.mo (not installed)
.........    /usr/share/locale/ja/LC_TIME (not installed)
.........    /usr/share/locale/ja/LC_TIME/coreutils.mo (not installed)
 :
.........  d /usr/share/man/man1/ls.1.gz (not installed)
 
# diff /etc/dnf/dnf.conf.org /etc/dnf/dnf.conf
< tsflags=nodocs
> #tsflags=nodocs
 
# dnf reinstall coreutils-common
 
# rpm -qVv coreutils-common
.........    /usr/share/locale/ja/LC_MESSAGES/coreutils.mo (not installed)
.........    /usr/share/locale/ja/LC_TIME (not installed)
.........    /usr/share/locale/ja/LC_TIME/coreutils.mo (not installed)
 :
.........  d /usr/share/man/man1/ls.1.gz

　 しかし効果なし。いや、ドキュメント系のファイルはインストールされたので、その効果はあったのだが「言語ファイル」は入らない。なんだよもぅ。

　 挙げ句の果てには、coreutilsパッケージのソースをバラしてspecファイルの中身まで確認してみる……

# dnf download --source coreutils
# rpm2cpio coreutils-9.3-5.fc39.src.rpm | cpio -div
# view coreutils.spec 
 :
%find_lang %name
# Add the %%lang(xyz) ownership for the LC_TIME dirs as well...
grep LC_TIME %name.lang | cut -d'/' -f1-6 | sed -e 's/) /) %%dir /g' >>%name.lang
 : 
%files common -f %{name}.lang

　 ……が収穫なし。いや、%filesって記述で言語ファイルを扱っているらしいけど、これは主にパッケージングに関係する記述で、インストーリングに関係する記述じゃないっぽいング。

　 さすがにdnfのソースコードまでは追いたくない……ええいクソ、こうなったらstraceでdnfの挙動を絨毯爆撃じゃ。

# strace -o dnf.str dnf reinstall coreutils-common
# cat dnf.str | grep open | grep -v NOENT | less

　 ……と、半ばヤケクソで見ていくと、妙なファイルを読み込んでいる様子に気づいた。中を見ると、ちょっとニオう内容。

openat(AT_FDCWD, "/etc/rpm/macros.image-language-conf", O_RDONLY) = 3
 
# cat /etc/rpm/macros.image-language-conf
%_install_langs en_US

　 通常の環境にはこのファイルは存在していない。削除してreinstallしてみると……

# rm /etc/rpm/macros.image-language-conf
# dnf reinstall coreutils-common
# rpm -qVv coreutils-common
.........    /usr/share/locale/ja/LC_MESSAGES/coreutils.mo
.........    /usr/share/locale/ja/LC_TIME
.........    /usr/share/locale/ja/LC_TIME/coreutils.mo
 :
.........  d /usr/share/man/man1/ls.1.gz

　 入ったーッ！ ……つーか、そんなんわかるかーッ！

　 つうか、上記のファイルについてググってみても、どうも後付けっぽい理由で追加され、未だ完全に意図した挙動にはなっていないような雰囲気だ。ということは、この対処もテンポラリなものと考えておいたほうがいいことになるな。

　 とはいえ、＜かきかけ＞

　 もう、書くのは何度目かになるが「歳を取って粘り強くなった」気がする。何でも楽しい取り組みとして、継続ができるようになった。筋トレも、ヴォーカルも、ドルアーガも。

　 結局、何事も上達するためには「ケーススタディ」の繰り返しであり、大きく物を言うのは回数だ。それを通じて「筋肉」や「小脳」を鍛え上げる。筆記も、楽器の演奏も、マニュアルトランスミッションの操作も、いわゆる体に覚えさせる系の技術は小脳だ。一連の動作をマクロ化し、考えなくても体が動くようにする、という感じ。

　 ドルアーガの場合、例えば「マジシャンが残っているのに剣を出したまま歩く」は禁じ手である。しかし「ナイトが近づいてきている」など、状況によっては避けられない場合もある。そういう複合した難しい状況が引き起こされるか否かは運によるところが大きいのだが、それを「運が悪かった」と片付けていては、60階に到達することはできない。1時間近くの間、幸運が連続する可能性は低いからだ。

　 ここがドルアーガの実に面白いところで、不運のパターンは数限りないものの、常に納得性が高いので、ミスをするたびに学習が行われ、それは「小脳」に刻みつけられていく。大脳で考えることも重要だが、小脳で感じることの方がより重要なのだ。まさに「考えるな、感じろ」というやつ。感覚的にヤバい状況を避ける。それがミスの可能性をジワリジワリと下げていく。

　 よって、すぐには結果は出ない。確率の問題だから、不運の多少に影響を受ける。だから、日々「どこまで登ったか」だけを目標にすると心が折れる。結果は重要だが、結果だけを求めすぎてはいけない。人間はよほどのことがない限り「継続していれば進化し、決して退化することはない」のだから。

　 つうわけで、一時期はスランプもあったが、今日は57階まで登ることができた。上の方まで行くと、ウィルオーウィスプへの対処法も必要になってくるんだよなぁ。

　 改めて言うが、何事も上達するためには「ケーススタディ」の繰り返しが必要であり、大きく物を言うのは回数であり、それには時間が必要だ。「時間は夢を裏切らない」。この言葉を松本零士御大が使い出したのは晩年だったと思うが、若者にはなかなか理解しづらい言葉だと思えるなぁ。

　 例によって、常に何かに取り組んでいないと気がすまない人なので、ドルアーガで遊びながらも、プログラミングを進めている。まぁ、それ以外の細かいネタもいくつか並行しているんだけど。

　 というのも、結構なペースでレトロゲーの類似品を作っている人をツイッターで見て、ちょっと触発されてしまったのだ。自分は、ゲームっぽいものを作るのは好きなのだが、ゲームシステムを作った辺りで満足して終わってしまうのだよな。レベルデザインに興味がないと言うか。

　 しかし、ちょっと思いついたのだ。せっかく「WebAssemblyでトラディショナルな回転技術を再現」したのだから、それを生かしたゲームができないだろうか。しかも、ほとんどレベルデザインをする必要なしに、だ……あるんだ……あるんだよ。

　 こういう感じのヤツだ。コースを作ることなく、世界中のサーキットでレースをすることができる。通信対戦できるようにしたいなぁ。

　 と思いつつ、あまりにユルユルとやっているので、任意の場所を映して、それを回転させた辺りで、着手から1ヶ月も経ってしまい、しかも、重大な問題に気づいてしまった。というのは、オブジェクト(キャラクタ/スプライト)の回転機能とバックグラウンドの回転機能は違うということだ。

　 キャラクタの回転機能は、特定の「正方形のパターン」を元に、回転後の「正方形のパターン」を得るものだ。当初、バックグラウンドを表示するなら、それを敷き詰めればいいと思い、アルゴリズムを考えたのだが、「パターンの特定位置を中心に、回転後のパターンの表示位置」を求めようと思うと、どうにもパターン中心までのベクトルを求める必要が生じて、アークタンジェントを計算することが避けられそうにない。

　 これまで、すべて整数演算で済ませていたのに、そこに逆三角関数が出てくるのは美しくなさすぎる。数表で済まそうとしても、済ませられない規模になるし、誤差も出るだろうから、敷き詰めたパターンにスキ間が出ることも予測される。しかし、当時のアーケード(A-JAX, アサルト, スーパーフォーミュラなど)に一切のスキ間は見当たらない。つまり、当時からバックグラウンドの回転機能は、回転パターンを敷き詰めて実装しているワケではないのだ。

　 で、気づいた。気づいたら簡単なことだ。たぶん、当時もそうだったのだろうと思える。バックグラウンドの回転機能とは、大きな正方形の領域が用意されていて、そこの回転前のパターンを描画し、それに対する「開始位置、サンプリングベクトル(角度)」を指定することで、画面全面に回転後のパターンを表示するという機能なのだ。それならば整数演算で済む。回転という概念が加わっても、オブジェクトとバックグラウンドは異なる実装になるんだなぁ。

　 そういうことになると、以前に作った「WebAssemblyによるトラディショナルな回転技術」はそのまま使えないことになる。まー、最初から作り直しではないものの、作り替えという感じにはなるなぁ。それはそれで、ガッカリ半分、ウキウキ半分だけれども。

　 公開されてからしばらくして、突然に観たくなってきて「SEED FREEDOM」を観てきた。結論からいうと面白かった。大満足。以下、失礼な言い方を多数しているが、ほぼポジティブな意味で書いている。まさに「こういうのでいいんだよ」という映画だった。ホント、面白いって、なんだろう？

　 振り返ればSEEDはDESTINYの途中くらいから、サカノボる形でハマったのだが、十分に楽しんだ反面、DESTINYでは、終盤で主人公を「戻す」という展開があり、どうもそれがネットの評判に影響を受けた結果のように感じて、なんだか安っぽいなぁ、というのが最後に残った印象であった。なので、しばらくして劇場化を計画中という話を聞いた時は、あんなグダグダの続きをどうしたいってんだ、と醒めていた。

　 しかし、だ。時間のもたらす効果なのだろうか。無性に観たくなってしまった。どうせ、いつものペラい内容なのだろうし、ご都合主義なのだろうが、たぶん絶対に面白い予感しかない。

　 で、観た。せっかくなので4DXで観た。これまで4DXで観て損したと感じたことはないし、今回のモーションもバッチリであった。いや、肝心の映画の内容は安っぽい。20年前から、まったく進歩していない。登場人物は、パイロットであり政治家でありガキンチョだ。主にスキだのキライだので行動する。不殺というテーマらしいが、そんなのまったく感じさせないし、どうでもいい。でもそれでいい。もう、調味料をコレでもかコレでもかとブッかけすぎたトリプルチーズバーガーである。足せば足すほどウマいに違いないと思ってる。全部入りが正義だと思ってる。「面白ければなんでもいーんだよー」と思ってる。

　 変に作家性を出さずに、同窓会に徹したのは、なかなかの選択ではないかと思う。目新しいテーマを立てたかっただろうし、新型モビルスーツを活躍させたかっただろうし、新曲を流したかっただろう、と思う。でもそこは、特段に妙なテーマを押し付けるわけでもなく、新型、新曲は序盤に片付けwて、クライマックスでは「いつもの」ですよ。「ストライクフリーダム」と「Meteor-ミーティア」ですよ。「オマエラが観たかったのはコレ」だろ、と。そうなんだよ「オレタチが観たかったのはソレ」なんだ、と。

　 そういう意味では「トップガン マーヴェリック」にも似ているが、アッチはそれなりに時間の経過を感じさせているよね。コッチは、相変わらず「僕たちは何も守れてない」とか言って主人公がスネちゃうからね。成長していないにもホドがある。まぁ、劇中の時間では2年だからそれで妥当なのかもしれんが。

　 こういう同窓会的な作り方をすると、次作が作りにくい気もするが、また10年後くらいにヒョコっと作る分にはいいかもしれない。DESTINYで「グフ」「ドム」まで、FREEDOMで「ギャン」「ズゴック」「ゲルググ」まで使ったから、まだ「ビグザム」「ジオング」あたりは残っているしなw。こういう過去ネタ頼りも、DESTINYの頃にはアザトさを感じたが、もう芸風として許せちゃう。ナイスバカ。あー、もう一回みたい。小ネタを全部回収したい。

　 観終わって、深夜、雨の止んだ季節外れの暖かさの中を、オープンにしたロードスターでチンタラと帰りつつ振り返る。ロードスターも二番煎じな企画から始まって、代を重ねても「楽しければなんでもいーんだよー」だけで、ある意味、進歩させずに来たクルマなんだよな、と。なんだかシアワセを感じるな。

　 自分は、以前エヴァのラストは新鮮味がないのがイマイチな原因だと書いたが、逆だったのかもしれないな。観たかったのが「いつもの」じゃなかったのが原因だったのかも。きっと「こういうのでいいんだよ」っていう感じのが観たかったんだ。

　 マクロスもやりません？ こういうの。なぜか、ミンメイが輝に迫ってきて、グラっときて、新型バルキリーで逃避行して、行き先で壊されて、なぜだかそこにあったVF-1で脱出するけど、ピンチになったところに、マクロスが来てダイダロスアタックして、美沙とモトサヤって感じでいいのでw。

　 ホント、面白いって、なんなんだろう……？w

　 先日の思いつきを得て、BGの回転処理を作り始めたのだが、wasmのロード処理が非同期なのがどうにも扱いづらい。以前には悩んだ末にどうにかできたと思っていたのだが、ワザとヒドく遅延するプロキシを作って試しに通してみたら、以前に回っていたものも実はダメだった。JavaScriptの非同期処理はややこしく、検索すると多数ヒットするので悩んでいる人は多いようだ。

　 結局、それだけで4日くらい地獄を這い回ってしまった。いや、Promiseとかasyncとかawaitとか、必要なときには便利なんだろうけど、必要じゃないときには邪魔すぎるんですが。UNIXのブロッキングみたいな扱いにできないもんすかね。ホント、本質じゃないところに時間かかり過ぎて殺意が湧きましたわ。まぁ、そのへんのコードは一段落したところで公開予定。

　 その問題がクリアできたら、以前に自分が書いた回転処理を参考に、BGの回転処理を書くのだが、何しろアセンブラは可読性が悪く、自分の書いたコードとはいえ、再度、脳に染み込むまでには時間がかかる。んが、結局は大きくない修正でBGが回転するようになった。回転のサンプル画像には、知っている人なら知っている、回転するにふさわしい画像を使ってみたw。

　 BGの回転処理ではパターンのキャッシュは行わないので、都度の生成だが、手元の環境だと、240x320、60FPSでのCPU使用率は、Firefoxで20%、Chromeで6%程度。ちなみに240x320というサイズは、スーパーフォーミュラへのオマージュであるが、その前提であれば処理速度にはまだ十分に余裕があるといえよう。SIMD命令は、まぁ気が向いたら、で。次は、地球上の任意の場所を走り回れるようにするのがマイルストーンかな。

　 そして、引き続きドルアーガ。上達するにつれて、難しい印象のフロアが変わってくるんだな。最近は、フロア10のレッドスライム、フロア45のナイトの重なり、ダークグリーンスライム、ブルーウィルオーウィスプが出てくるフロアがツラい。要するに「運が悪かった」で済まそうとしないと、テキが変わってくるというワケなのだ。

　 高次面で終わってそのままだと、その先が上達しないので、コンティニューしてクリアする。フロア59もだいぶ運が絡むよなぁ。もう少し練習したら、天野に出陣しようかしらん。

　 先日から取り組んでいるBGの回転処理が完成した。

　 特定の位置を中心に回転拡大縮小ができるようになり、非常に使い勝手がよくなった。十分な速度であり、描画の結果も非常に正確だ。我ながら傑作コードである。

　 動きを見てみる。コード(wasm部分)を見る。コード一式をダウンロードする。

　 自分で言うのも何だが、今回のコードには無駄な部分が一切存在しない。極めてシンプル。書きながら、煮詰めていくうちに、自然にそうなった。そこで、ハッと気づかされたのだ、当時の回転拡大縮小機能は「こう実装されていた」のかと。

　 今回のコードは、ループの終了をゼロフラグで判断する(値比較で判断するより命令が減らせる)都合で、右下から左上にラスタースキャンするように回転パターンを生成しているが「ラスタースキャンするように生成している」のがミソだ。原理は同じなのだ。当時の回転拡大縮小機能も、ブラウン管モニタに「ラスタースキャンしながら回転パターンを生成していた」に違いないのである。PCG、スプライトなどと同様、CRTCに搭載されていた機能だったのだ。左上から順に、VRAMアドレス空間を「斜めに」参照しながら塗りつぶしていくという原理だったのだ。

　 思えば、なんとなーく手を染め始めたWebAssemblyであったが、往年の回転拡大縮小機能の実装を再発明してしまうとは、気づけばエラいトコロに着地したもんだ。さて、レーシングゲームの実装を進めよう。