ヤマグチノボルよりも長く生きて

42歳になった。

「もう42歳だ」とは思わない。だって私がゼロの使い魔を読んでいた頃、ヤマグチノボル氏にはもっと長く生きて続きを書いてもらいたいと願っていたのだから。ゼロの使い魔だけじゃない。他の作品だってまだまだ読みたかった。

私がそう願った年齢を追い越して、自身の老いを嘆いたり焦ったりしたくないと思ったが、そもそも生来のんびりしている、しすぎているので、もう少し焦ったほうがいいのかもしれない。でも嘆く暇があったら今作っているものを作りたいと思う。


昨年作っていたロストアンファウンドは、ゆえっちの尽力で無事に完成した。

booth.pm

ゲームとしてはまだまだいろいろやりたいこと、できることがあったと思うけれど、そこをちゃんと諦められたのはよかったと思う。諦めたくなかったことが次のエンジンになる。

このゲームをもっとちゃんとPRしたいという気持ちはあるのだけど、とてもむずかしい。このゲームのいいところは、しんどくないところだ。「作業ゲー」から「作業感」を取り除きたかった。しかしその「作業感」のなさは実際に遊んでもらわないとわからない。遊べば手触りのよさが伝わると思うのだけど、それを伝えるのがとてもむずかしい。自分たちがどれだけ手触りがいいことをアピールしても、第三者の耳にはなかなか届かない。「面白そうさ」の演出がちゃんとできていないのが課題だと思う。

この「面白そうさ」を伝えるために、ロストアンファウンドの次回作、スローライフシリーズの二作目では、もうちょっと画面的にわかりやすいギミックをアピールするつもりでいる。「こういうことができる」は「こういう遊び方ができる」になる。手触りが見えやすい。


ところで、私は本業はプログラマで、最近はインフラエンジニアでもある。アーキテクトというには少し責任を負えない、やや中途半端なモチベーションのまま、ずるずると何でもやっている気がする。だからこそ、ここで一度自分が「デザイナー」であることを自覚し、看板を背負おうと思った。つまり自分は○○であると名乗ることが、その責任を引き受けるということなんだと思う。

自分が真似事でなくちゃんとデザインをはじめたのは、『フィクションのための名前の作り方』を書いたとき。ロゴも、表紙も、裏表紙も、本文も、全部自分デザインした。それ以前からウェブサイトを組んだりはしてきたけど、あくまで真似事の意識だった。でも『フィクションのための名前の作り方』は自分がデザインしたとちゃんと言える。もっとも、ロゴのデザインは当時なりにやりきったと思っているけど、今見ると拙さはある。

続けて『辺涯のガストロノーツ』のロゴを作ったり、半文庫のサイトをデザインしたり、『ロストアンファウンド』のUIをデザインしたり、ということをやって、自分が思いの外、デザインという作業に真摯に向き合いたいと思っていることに最近気付いた。

気付いた経緯は後日あらためて記事を起こすつもりだけど、そういうわけでデザイナーをちゃんと名乗ってやっていく、そういう決意表明を、あらためて今ここでしたい。あおたく、デザインをやります。やっていく。


体調は季節の変わり目で悪いがちなりに、やれることをやっていこうと思うし、やりたいと思うことは、やっぱりやっていきたい。

こちらからは以上です。また一年無事であるように。

アクアリウムは紐解けないのために新潟まで行ってきた

アクアリウムは踊らないのコラボ謎解きイベント、アクアリウムは紐解けない、というのが新潟市で開催されています。

nazoad.com

ので、GWに参加してきました。せっかくだしついでに新潟のうまいもんも食べようと。

なぜ新潟

作者の橙々さんが新潟の方でして、実際、長岡市寺泊水族博物館やマリンピア日本海といった新潟の水族館が作中のビアンカ水族館のモデルになっているらしい。

そういうわけで、新潟の謎解き制作団体のナゾトキアドベンチャーさんとコラボで開催されています。

コラボ謎解きどりゃ!

謎解きイベント

SCRAPがやっている「リアル脱出ゲーム」、あれです。「リアル脱出ゲーム」は商標なので、商標を使わない呼び方としては「体験型謎解きイベント」とかがあります。まあ実のところ脱出関係ない謎解きも結構あるし、実態としては「体験型謎解きイベント」が合ってると思う。

アクアリウムは紐解けない

アクアリウムは踊らないの世界観を再現した会場で、スーズやレトロと協力して異界化した水族館からの生還を目指す、という内容で、ゲーム未プレイでも楽しめるように、原作のネタバレ要素とかはほぼ出てきません。

スーズとレトロが参加者に話しかけてくる体験はゲームでは味わえないのでめっちゃ新鮮でした。

会場の雰囲気もめちゃめちゃよく出来てるし、あとなんなら会場の雰囲気の分、原作より怖いが?という気もする。まあね、他の参加者もいるし、同行者もいるので、深夜にひとりでプレイするよりはね。ジャンプスケアはないのでそこはよかったです。

謎解きの感想ですが、手応えとしてはちょうどよかったのですが、普段タンブルウィードにボコボコにされているせいで、ちゃんと大謎のギミックを解いて納得感ある解決を導いたのに、ほんのちょっとだけ物足りなさはある。雰囲気も最高で、いいイベントだったと言い切れるのに、こう……こう……! アクおどファンで謎解きイベント初心者だとちょっと難しいかもしれない。ちょうどいいじゃ物足りない体になってしまった……。でも楽しかったです。それは本当。

最高の体験ではあった

お昼

伊勢丹に入っているへぎそばの名店小嶋屋さんで、へぎそばとタレカツ丼のセットを注文。ランチタイムということで人出は多かったんですが、GWのわりにはすんなり着席できましたね。

へぎそばの盛り付けがうつくしい

タレカツ丼うっっっま! ほどよくタレが染みたサクジュワのカツ、タレのかかった新潟のコメ、うますぎて犯罪的。へぎそばは風味がよく、強いコシがあり、これもうまかった。

ヒラメキパーティー

GW期間中、新潟日報メディアシップでヒラメキパーティーという謎解きイベントが開催されていたので、それも参加してきました。

インペリアルダンジョン

突破型の謎解き。ファミリー向けの難易度ですが、楽しかったです。ちゃんと閃いたときの気持ちよさがあった。それはそれとして、60〜90分程度の想定プレイ時間で、1時間かからずに出てきてしまったので時間を持て余してしまった……。

ジーニアスボックス

カフェ謎。いわゆる謎箱、なんですが、なんか30~60分なのに30分かからずに解いてしまった。だから、時間潰すつもりだったのに!

ちょっと休憩

喫茶店にでも行こうということになり、ふらっと入ったのがカフェイタリアというジェラート屋さん。

km0-italia.com

ジェラートもさることながら、コーヒーがめっっちゃくちゃうまかった! エスプレッソ、香りもそうなんだけど味がめちゃめちゃいい。たっぷりめに砂糖入れると酸味と苦みのバランスがばっちりで、コク深い味わいでした。ふらっと入った店のコーヒーがうまい、旅の醍醐味だと思う。

バラ盛りのジェラート、見た目がたのしい。味はエルダーフラワー(外)とピスタチオ(内)

小謎の多い料理店

めちゃめちゃ面白かった! 30分でこの体験ができるのは本当にいいですね。楽しい部分がぎゅっとしてる。

STANDBY

これも楽しかった。こういう、体感型の謎解きからしか得られない栄養がある。

その他の旅の思い出たち

イベント前日に燕三条に寄り道して、燕背脂ラーメンを食べたり、

メタル丼。魔法瓶と同じ構造で外側は熱くなく、それでいて冷めにくい

ぽんしゅ館の唎酒番所で日本酒の飲み比べをしたり、

醸し香 翠はまじでメロンみたいな味でびっくりした。

新潟駅のだるまやで背脂麻婆麺を食べたり、

追い飯つき。追い飯じゃ足りねえ!となった

居酒屋で締めのつもりで注文しようとしたおにぎりがその瞬間に売り切れるという悲しい目に遭ったのでテイクアウトのおにぎりやさんでおにぎり買ったり、

マジで米がうまい

などしました。

ホテルのバイキングの朝食、米がうまいからもりもり食べてしまった

とにかく食べるもの飲むものがうまい。

バスセンターのカレーはGW中でめちゃ混雑してたので断念しました。また今度。

というわけで

めちゃめちゃいい旅でした。

それはそれとして水族館で謎解きしたいね。え、ある? あるの?

www.fwinc.co.jp

行くか……!

こちらからは以上です。

アクアリウムは踊らない、クリア

アクアリウムは踊らない、クリアしました。

アクアリウムは踊らないについて

作者である橙々さんはホラーゲームが苦手であることを公言していながらも、個人で8年がかりで今作を完成させています。狂気。しかも今作はもともと製作に誘われて参加したのに、他のメンバーは離脱して橙々さんだけが残ったという経緯。執念。この時点でエピソードが特異すぎますが、それもあってか公開2日で10万DLを達成。あっという間に商業版の企画が立ち上がり、総DL数は80万に登ります。すごい。これは話題性だけじゃなくてゲームの出来がよく、実況プレイや口コミで面白さがちゃんと届いたからだと思います。

内容はIbみたいな探索型のアドベンチャーゲームです。導入も、水族館にやってきた主人公が異界に入ってしまうまでの流れはかなりIbっぽい。でも、手触りはかなり違っています。Ibは画面の色彩からして不穏な雰囲気が漂っていますが、アクおどはちょっとものさみしいくらいの感じなんですよね。「水族館の温度の低さ」をうまく演出している。これが今作の個性です。

私もホラーゲームは苦手で、やむを得ない事情で夜な夜な流行り神のプレイを強要させられたことがあるんですが、あのときほど夜勤でよかったと思ったことはないです。明るい時間に寝るので怖くて夜眠れないということがなかった(夜勤でトイレに行くたびにビビったりはしました)。

ホラーゲームというかジャンプスケアが嫌いなんですよね。流行り神はチュートリアルでジャンプスケアを何回も出してくるので本当に許せないし、ジャンプスケア撲滅協会があったら入会するレベルなんですが、アクおどはジャンプスケアがかなり抑えめです。ほとんど出てこない。やさしい。

なんで急にアクおどを?

新潟で体験型謎解きゲームのコラボがあり、これに参加したかった! というか参加してきたので、後日コラボイベント『アクアリウムは紐解けない』についても話す予定ですが、そういう経緯で急遽プレイしました。一応未プレイでも楽しめるイベントではあるのですが、プレイしてから参加したかったため。

プレイした感想

予備知識ゼロでプレイを始めました。スーズのちょっと口悪いところかなりいいですね。ユーフォの黄前ちゃんっぽい。え?商業版だとボイス黒沢ともよさんなんですか?解釈一致すぎる。

レトロは、本当に頼もしいですね。異界化した水族館で一人心細く探索しているところで合流したときめっちゃホッとしました。

ネタバレを避けるんですが、初見ではトゥルーエンドに気付かず、途中のセーブデータからやり直してその要素に気付く。これ初見で気付いたら気持ちよかっただろうな……。ちゃんと違和感に気付けるようには作ってありつつ、でもそこから初見でトゥルーエンドに行くためにはちょっと手がかりが足りない、届かない感じ。でもちゃんと二周すれば分かるようには作ってある。本当に丁寧な作りだと思います。

一番好きなキャラクターはヤドカリくんですかわいい。

操作が下手すぎて何回も死にましたが、気軽に死んでもいいゲームなのはいいところだと思います。緊張や不安を煽っても、ミスしたプレイヤーに恐怖を突きつけない設計は本当に優しい。

語りたりねえよ

未プレイの人に配慮するとこれ以上のことは書けないので、後日既プレイ向けにここ好きポイントを書いた記事を上げる予定です。

それはそれとして次回は新潟でアクおどの謎解きをやってきた話をします。

こちらからは以上です。

Claude Designはデザインしない

Claude Designなるツールが登場して、ノンデザイナーの間ではこれでプロトタイプが捗る、と話題になっているみたい。

私のファーストインプレッションは、「これはHTMLとCSSを書いてるだけ」。つまり、Claude Designではロゴデザインはできないし、ゲームのUIデザインとかもできない。カバーデザインとかパッケージデザインも難しそう。DTPも無理じゃないかな。できるのは、ウェブページのプロトタイプを作ることだけ。つまりホームページビルダーみたいなもの。

あるいは、結局のところどういうデザインにするのか意思決定は人間がやる。じゃあ、ノンデザイナーが、今作っているプロダクトのキーカラーを何色にするか、どうやって決めるんだろう? 逆に言えばそれを設計して、決定の理由を言語化できる人がデザイナーなのであり、Claude Designでガチャをやって、直感でこれがいいな、しっくり来た色で行きましょう、をやっているうちは、デザインに再現性がない。

SUUMOとホームズはどちらもお部屋探しサービスだけど、SUUMOは緑でホームズはオレンジ。「LIFULLのコーポレートカラーがオレンジだからホームズ」それはそうかも。でも、じゃあLIFULLはなんでオレンジなんだろう? それを言語化できる? 逆にSUUMOはリクルートだけど、リクルートのコーポレートカラーは緑じゃない。LIFULLやホームズがオレンジなのは、同じ概念を商品として扱っているからで、リクルートとSUUMOは必ずしも同じではない。だから、やっぱり色の決定には理由がある。

LIFULLやホームズは、「生活」や「ホーム」をキーワードにしている。だから「住むところの温かさ」を伝えるためにオレンジを選んでる。

一方、SUUMOは「新生活のフレッシュさ」や「期待感」、あるいは住む「環境」をブランディングして緑を選んでるんじゃないかな。これはたとえばニトリにも同じことが言えると思う。家具を新しく買うのは、生活を新しくするため。ニトリは少し高級感を出すために青みがかったグリーンにしてるのもポイントだと思う。

もちろん、実際にどういう意図でこれらの色を選んだのかはわからない。でも見たときの印象の違いは確実にあって、こういう受け取り方をされる色が選ばれているとは言える。デザインをやるというのは、そこまで考えて色を選べるのか?ということ。

依然としてその知識はデザイナーの領分だと思っていて、デザイナーが不要になることはないし、なんならAIが代替するのは本質的に無理な気がする。あたらしいプロダクトを生み出すときに、そのプロダクトがどう育ってほしいのかAIに考えることはできない。今のAIの主流であるところのLLMは考えないし、知らないことについては知らないからだ。

逆に、分析はさせることができると思う。配色からどんな印象を与えやすいか、平均的にどうかということは出力させられる。レビュアーの一人にAIを使うというのはいい。でも結局最終的にそのプロダクトをどうしたいのかは人間が決めるしかない。究極、好きか嫌いかを決めるのは人間なのだから。

こちらからは以上です。

続・ちょっとした実験

以前 架空の食材を使った架空の食事を架空のキャラクターに食べさせ、感想を言わせる。 という実験をやったのですが、これを Gemma 4 31B が出たのでさっそく試してみました。

(……もぞもぞと、椅子に浅く腰掛け、目の前のボウルをじっと見つめています。期待で頬が少し赤くなっていて、指先をいじりながら、あなたの顔を伺っています)
「あ……。えっと……。できた……? いいにおい……。すごく、いいにおいがする……っ」
(スプーンを手に取り、恐る恐る、一口分をすくって口に運びます。ゆっくりと味わい、もぐもぐと頬を動かした後、ふわりと表情を緩ませました)
「……っ! ……おいしい……。あったかいです……っ」
(もう一口、今度は肉と野菜を一緒にすくって食べ、小さく声を漏らします)
「……ふふ。お肉……、もぐもぐ……。弾力があって、噛むたびに甘い脂が……じゅわってします。獣のにおい、全然しない……。ちゃんと、お料理になってる……。それに、ソバの実が……ぷつぷつしてて、お出汁をいっぱい吸ってるから……すごく、コクがあって……幸せな味がします……っ」
(少しだけ眉を下げて、崩れた野菜を見つめますが、すぐにまた微笑みます)
「お野菜……、ちょっととろとろになってるけど……。でも、これがいいと思う……。カブイモの優しい甘みが、お粥に溶け込んで……。センジンの薬っぽいところも、ちゃんと火が通ったから……不思議な、奥行きのある味になってます。……あ、あと、この白いところ……。発酵卵白……だよね? これが……とろっとしてて、爽やかな酸味があるから……、お肉の濃い味が、ちょうどいい感じにまとまって……、すっごく、飲み込みやすいです……っ」
(ボウルの中身を大切そうに、ゆっくりと食べ進めます。最後の一口を飲み干すと、恥ずかしそうに視線を逸らしながら、小さく提案します)
「……えっと、あの……。もし、次……また作ってくれるなら……。お野菜を入れるタイミングを、もう少しだけ、遅くしてみたら……もっと、シャキシャキして、いいかも……しれない、です。……でもっ! 今のままでも、十分……っ、ううん、すっごく、おいしかったです……!」
(顔を真っ赤にして、もじもじしながら)
「……ごちそうさまでした……。えへへ……。また……、楽しみにしてます……っ」

うん、Gemini 2.5 Pro くらいの性能は出てますね。来年の今頃にはローカルの8Bくらいのモデルでこの性能が使えるようになっても不思議ではない。マジでローカルLLMを積んだゲームが実用化する時代がそこまで来てると思います。

短いですが今回は、こちらからは以上です。

AIのボトルネックは人間?

AIにコードを書かせることがかなり普及していて、もう使うのが当たり前になりつつある中で、しばしば「AIを使っているのに速度が出ないのは人間の思考が遅すぎるからだ」という意見が出てくる。「人間ボトルネック論」だ。

ちょっと深堀りしてみよう。

今、AIにあるプロダクトを作らせている。仕様や設計は人間がやって、実装をAIがやる。テストも通るし、人間が実際に目で動作を確認してバグを報告して修正させて、動くものは出来上がっている。しかし、ある瞬間、突然型が壊れた。型エラーが消せなくなった。型を直すには根本的な型定義から書き直す必要がある、ということがわかった。

ここで型エラーをサプレスすれば、AIにこのまま書かせ続けることはできる。

それを選ばずに、型定義レベルの設計をやり直した。人間が型を書き、そのとおりに実装させることにした。この型定義には3日かかった。AIが実装したときは3時間でできた。しかし潜在的には壊れていた。

ボトルネックはどこにあったのか。

AIである。今のAIは、人間でも困難なことは、「やったように見える」状態にしか持っていけない。解決せず、解決したように見えるようなゴールを目指してしまう。結果、ゴールからは離れていく。この遠回りを修正するために人間が労力を支払っている。

AIのボトルネックはまだ人間などではなく、結局AI自身にある。

本当に人間がボトルネックになる時代は来るか? 原理的に、トランスフォーマーモデルの間は、そんな時代は来ないんじゃないかと感じる。

こちらからは以上です。

またツクール触ってる

ツクールの何がよくて何がよくないのか、ということをあらためて考えていた。

ツクールは、というかツクールMZは、JavaScript製のゲームエンジンで、PIXI v5の描画と、Effekseer統合があるので、2Dに限っては一定モダンなゲーム開発環境だと思う。んで、インディーで3Dをやりたい理由がなければぜんぜんUnityやGodotに行く必要がなくて、ツクールは選択肢に入る。

ツクールが苦手なもの

あくまで主観であって統計的な根拠がある話ではないです。

  • 大量のオブジェクトを動かす(ヴァンサバみたいなやつ)→ ECSを導入すれば……と思ったが、JSがECSをやるのに向いてない。できなくはないんだけど、メモリ最適化みたいなのをJSでがんばるのはけっこうしんどい。
  • 3D → three.jsとかbabylon.js があるので技術的には可能。ただ、ここのしんどさって「3Dのレベルエディタが統合されていない」ことなので、それをどう解決するか。babylon.jsにはシーンエディタがある。blenderをシーンエディタにすることもできる。でも実は筋がいいのはUnityをシーンエディタにしてエクスポートされたjsonを読み込めるようにすることかもしれん。そこまでしてなんとか……という感じだけど、でもそのしんどさはUnityだったら緩和されるかというとあんまそうでもないかもしれない。素直にBakinを使ったほうがいいと言われれば、それはそう。
  • Live2D → できなくはない。ただ、いくつかのゲームを見た感触では読み込みが重め。非同期ロードをどう最適化するかの設計が鍵になりそう。
  • Spine → いくつかのゲームを見た感触では、Live2Dよりは軽い印象がある。
  • ノードベースの状態遷移 → ツクールはコマンドリストベースなので、ノードベースを組み込むのはちょっとしんどい。局所的に取り入れるのはできるとは思う。ノードエディタを誰が用意するのかという問題はある。ノードベースの状態遷移があればNPCのAIの挙動を作りやすくなる。
  • 非グリッドベースの衝突判定 → 上に書いたものに比べれば導入可能性は高い。コリジョンマップの外付けで十分実現可能。
  • 物理演算 → 導入を検証したことがあるが、問題ない。matter.jsやrapier.jsは統合可能。重さも問題にならない。設計は相応に重い。アクションゲームが作りたいなら、GodotやAction Game Makerのほうが筋が良い。アクションRPGやアクション移動つきRPG(ヴァルキリープロファイルのような)を作りたいなら、ツクールMZの出番はある。
  • リアルタイム性が重要なゲーム → GC制御が困難なので、もしリアルタイム性が重要ならGodotやUnreal Engineで作ったほうがいい。リズムゲームなどは明確に不向き。
  • 暗号化 → とはいえ Unity も別に完全に暗号化できるわけではない。フォルダ除いただけでデータファイルが見えちゃう、くらいは防ぎたいが、これは技術的にはぜんぜん不可能ではない。正直、暗号化したからといってゲームが面白くなるわけではないので、こんなところに力を入れるくらいなら他にやることありそう。簡単に抜き出せなくするくらいの対応は十分できるし、それで十分と割り切るべき。これは Unity でもいっしょ。

ツクールが得意なもの

  • コマンドリストベースの状態遷移 → コマンドリストベースなので、復元が容易。任意の地点からレジュームできる作りは、たとえばアドベンチャーゲームのようなシーケンシャルなゲームデザインと相性がいい。処理の流れが上から下なので、シーケンスを追いやすい。ここは一長一短ある。
  • グリッドベースの衝突判定 → 実装が枯れていて、十分機能する。
  • セーブ・ロードできるゲームデータ管理 → ゼロから実装するのは意外と大変。
  • キャラクター・アイテム・スキル・敵のマスターデータ管理 → これもゼロから実装するのは大変。ただし拡張性はあまり高くない。拡張の実装自体の難易度は低いので、デメリットというほどでもないかも。
  • メッセージシーン → これを作るのがどれだけ大変かは、Unityでゼロからゲームを作ったことがある人は知っていると思う。

ツクール自体に起因しないが、問題になりやすいもの

  • 巨大なテクスチャーの読込・破棄を繰り返す → 一枚絵マップでありがちなんだけど、これをやると簡単にVRAMを食い尽くして死ぬ。我々に必要なのは最適化されたテクスチャーアトラスを使って、最小コストで描画する努力。そしてそれって、ツクールだけに求められるものではない。Unityでも雑に作れば重くなる。illusionのSBPRなんか今のマシンでプレイしても重いからね。

というわけで、ツクールMZにもそれなりのアドバンテージがあり、ここは見落とされていると思う。Unityにメッセージシーンのプラグインは、たしかにある。それを自分のゲームに組み込むには相応の設計スキルが必要で、一方ツクールはシーンに統合されている。より正確に言うと、マップシーンも戦闘シーンも、メッセージシーンを拡張して実装している。この作りが手堅い。

ツクールのよさをどう伸ばすか

ツクールの苦しさは、独自のシーンを作るために独自のUIを実装しようとすると、そのためのインターフェースがないので、自作シーンクラスを提供するプラグインを用意するか、さもなくば大量のピクチャボタンや文字列ピクチャを並べた複雑なコモンイベントの組み合わせ、という感じになる。とはいえ後者はウディタでもそうなりがち。ウディタとの違いは、ウディタにはイベントスコープがあること。イベント内に閉じた変数を使えることで、コモンイベントのポータビリティが高い。ツクールもこうなっていれば、苦しみは軽減される。

コモンイベントに引数と戻り値を用意し、イベントスコープのローカル変数を用意し、そしてデータベースや変数を名前解決できるようにすれば、原理上、ID固定の依存関係がなくなって、プロジェクト間を行き来して移植可能なコモンイベントが作れるようになる。リファクタリングもしやすい。そう思い、作り始めた。4割くらいできている。残りの6割は、名前解決を利用した既存のイベントコマンドの置き換えがまだ終わっていないから。イベントコマンドの大半がプラグインコマンド、というイベントを組むことになりそうだが、それで問題はなさそうに思う。文章の表示などはローカル変数を参照できればいいだけなので、そのまま文章の表示コマンドを使える。条件分岐はスクリプトを書くしかなさそう。evalしない内部コマンド呼び出しを行うスクリプトというアイデアはあってもいい気はする。

自作シーンクラスは大量のボイラープレートコードを繰り返し書くことになり、メンテ性も悪い。イベントで組んだほうがよくないか?と最近思い始めた。

イベントコマンドから汎用ウィンドウを並べられるようにできればいい。quince を使えば、ウィンドウや要素の自動レイアウトができる。今その仕組みを作っていて、3割くらいできている。3割というのは、quince統合ができてシンプルなテキスト描画や変数のデータバインディングなどが機能しているという状態。データバインディング層がまだスカスカなのと、画像描画などの機能が不足していて、これではまだ実用できない。あとテストも足りていない。quinceは十分テストされたライブラリだけど、ツクール上で機能するかはいろんなデモを組まないとわからない。

どちらも、思想的には「イベントコマンドで戦える範囲を広げる」であって、任意のプログラムコードで拡張可能にするというものではない。それはもうあるからね。


というわけで、地道にコードを書いたり、書かせたりしている。設計を自分ひとりで煮詰めなくてもよくなったこと、テストコードを書かせて検証しやすくなったこと、いろんな理由でこの試みがうまくいきそうな気はしている。うまくいったらいいなと思う。

こちらからは以上です。