「アイディア」に関する日記

美文のキャラ倉庫

いくつかの記事更新。
タグ追加中心です。

MediaWiki

キャラ倉庫、WordPressで実装されているわけですが、WordPressは基本的にはブログを想定したシステムで、次々流れる最新情報を発信するのには向いていますが、過去情報を蓄積し「まとめ」ていくのにはあまり向いていません。
まとめと言えば、そう、Wikiです。
そう思って過去にPukiWikiやら@wikiやら試したのですが、@wikiは昔試した限りではインポート・エクスポートが使えず、PukiWikiはメンテがほぼ止まっていて今となっては使い勝手があまりに残念、というか、PukiWikiやめようってんで始めたのがキャラ倉庫だし。
というわけで考えたのが、Wikipediaというぶっちぎりの実績を持つMediaWikiってわけです。
ただ考えただけで、まだ作業は初めていません。
考えるだけなら過去にもやってますけどね。

ドラゴンクエスト10(しろいコキン)

• 【コイン】デスマシーンをはじめて倒した！

今更討伐シリーズ！
当然写真は撮ってない！

ドラゴンクエスト10(ミフミン)

• クエスト「花風　剣を導く」をクリアした！

やっとこさストームカイザーに転職するクエストをやりました。
師父にめちゃくちゃため息つかれちゃったけど、見捨てられずに済みました！

他の写真は以下から。
写真置き場「2026/07/07」

TGWS内部処理

バイオ9の画像ページみたいに、たくさんある画像をいい感じに一覧表示する機能の、もっといい感じにやるやつ実装中。
ユーザー側からはあまり意識しないかと思いますが、URLが内部形式むき出しになっていたり、ページを最初に表示したときは表示しない画像も一気に生成するから重くなっていたりして、微妙だったんですよね。
なので、URLをすっきりした形に整理したり、必要な画像だけ作るようにしたり、ついでに画像形式をJPEGより高効率なWEBPにしたりしています。
いやあ、他でもないバイオ9の画像が、4K画像大量表示だから重いんですよね。

アンパンマンDB(アイディア)

トップページにもアフィリエイト入れようかなとか考え中。
別に生活が変わるほど売り上げがあるわけじゃないけど、売り上げが少なすぎるとAPI止められる可能性があるんですよね。
ただ、今でもトップページはかなりごちゃついているので、必ずやると決めているわけでもないです。

GitHub Copilot

技術記事のネタ探しをAIに頼るのはいいかもしれない。普段やっていることは自分の中では当たり前だから記事にするまでもないと思っちゃうけど、他の人からしたら未知の知識の可能性もあるしな。 pic.twitter.com/ZvMlFhlkSt

— 📛松田美文 (@matsuda323) June 29, 2026

アンパンマンDB(記事更新)

• 音楽「ロボ彗星からきた少女ロボリィと小鳥のコト」を追加
• 音楽「アンパンマンワールドのばいきんまんとベビーアンパンマンたち」を追加
• 音楽「ロボリィとみんなの胸にキラキラぽかぽかプレゼント」を追加

ロボリィのBGM追加。
ついでにロボリィ系のキャラ情報も追記しようと思ったけどそれはやっぱり後日ということで。

アンパンマンワンドロ

• 「バイキン仙人」、「ドクター・ヒヤリ」、「カマンベールくん」追加

今度は追加のほう。

今は新規追加されたお題は過去開催されたお題より確率が上がるようになってるけど、新規お題優遇をもっと進めていいかもしれない。
つまり、新規お題がある間は過去お題を出なくして、新規お題だけから抽選するってやつ。

ゲーム記の記事作るのに先駆けて、スクリーンショットの扱い考えてました。
1のときと命名規則違うし、余ってるSDカードでは転送できないし、ゲーム機からパソコンに移動する方法から考え直さなきゃいけないのです。
USB転送が引き続き使えて、フォルダ分けもされているので、このフォルダ名をうまいことウェブ用に変更すれば、最小限の手間でアップできそうです。
後は、1のときと似たようなシステムを作って一覧表示できるようになればよし。
せっかくだから動画も表示できてもいいかな？

アンパンマンDB(システム)

キャッシュ更新高速化の第一段階は成功。
期待したほど爆速にはなってないけどそれでも体感で半分ぐらいの時間になっています。

それとは別に、キャラ数検索が動いていないことが発覚したので、今度はそっちの修正にかかろうかと思っています。
検索結果「キャラ数：6」 | アンパンマンアニメDB

次期NeoMupl

今考えてるのはこんなところ。

• 様々な情報を表示できるように表形式にする
• オンラインストリーミングに対応
• DPIAwareness
• 一応オープンソースにする
• みんなが広く使うようなものは目指さない
• プラグイン式みたいな高度な柔軟性は提供しなくていい
• 映像や波形の表示はしない(引き続き音楽専用)
• 一曲を複数の設定で再生できるようにする
• 一時停止・再開対応
• UIスレッドと再生スレッドを分離(UI操作中は音が途切れがちだった)

アンパンマンDB(記事更新)

• 「ばいきんまんとえほんのルルン」の作品情報を更新

来週の放送情報。
前半はアンパンマンほぼ出番なしだった脚いいけど、後半はアンパンマンがちゃんと出てくる…はず！

NeoMupl

0から作り直しを検討中。
自分で使っていていろいろ残念な部分、時代に合わない部分が目立ってきましたからね。
そのときは、NeoMuplの新バージョンではなくて、コンセプトから異なる別ソフトにして、名前も別にするつもりです。
もうだいぶん古いのにNeoもないですしね。

ふにゃ1リメイクのほうもやり残しはまだあるわけですが、こっちも考えてることが。
フレームレートのことです。

ふにゃ1は20FPS、ふにゃふにゃは同じく20FPS、ふにゃさんは40FPS、ふわふわふにゃは30FPS、ふわふわふにゃ on web browserは30FPS(内部90FPS)でした。
funyakは、60FPS(描画は60FPSを上限とした可変で、内部は60FPSを維持)です。

一方、きょうび、結構ハイスペックを要求する3Dゲームでも、240FPSとか平気で叩き出したりします。
もちろん、それはハイスペックPCと、最高峰の最適化が両立したらの話ですが、シンプルな2Dゲームなら低スペック＋雑実装でも60FPSを当たり前に超えられるんじゃないかと。

まあ、普通のPC用モニタは60FPSが上限なので、映像の滑らかさという点では60FPS超えは意義が薄いと思われます。
しかし、内部処理は、時間を細かく刻めば刻むほど精度が上がり、変な挙動が抑えられます。
わかりやすいところでいうと、小さい物体を高速で移動させた場合、当たり判定を工夫しないと壁をすり抜けてしまうのですが、細かく刻むと、1フレーム当たりの移動量が抑えられるので、シンプルな当たり判定ですり抜けを防止できます。
ふにゃ特有の角抜け(するり)は細かく刻むことでは解決しませんが、これは工夫は工夫でも簡単な工夫で済むのでまあいいかと。

まだ思い付きレベルだし、まずはふにゃ1リメイクのほうを優先して、FPSの件は後回しにしようと思います。

ふにゃ1(開発状況)

ステージメーカーにいろいろ機能追加！

• ステージメーカーのツールバーに拡大縮小ボタンを追加

拡大縮小は連続でやりたいことが多いので、ツールバーにも追加。
等倍と自動は連続で使わないのでメニューの中に押し込めたままにしています。

• ステージメーカーのズームレベルが最大値を超えないように制御

拡大率自動だと最大値の200%を突破する、というのは想定通りの動作なのですが、その状態から縮小を使うと固定200%超えが発生してしまうので、そのあたりのケア。
「縮小の最大値」という、文面上気持ち悪い概念により、縮小時にも200%以下に収まります。

• ステージメーカー：マップ本体にもキーバインディング追加

これは昨日の残件。
PageUp/PageDownのキーがScrollViewerに吸い込まれるなら、そのScrollViewerでイベントをキャッチしてしまえばいいという発想です。
逆に、右側のエリアにフォーカスが当たっている間は、マップ本体への操作ではないという扱いで、普通のスクロールが発動します。

• ステージメーカー：マウスホイール操作によるズーム機能を追加

やっぱり今どきのエディタならCtrl+マウスホイールでの拡大縮小にも対応しないとね。
ただ、マウスポインタ―のある場所を中心に拡大みたいな気の利いた実装ではなく、メニュー操作と同じ単なるコマンドを実行しています。
新作じゃなくてあくまでも旧作の改良だからあまり気合い入れた実装をするのもね…。

タブレット端末なら指2本でピンチアウト操作もあるけど、これはさすがに対応外かな。

• ステージメーカー：マップ順序入れ替え

画面写真右下にさりげなく追加されてるボタン。
ふにゃさんにもあった機能を取り込みました。

• ステージメーカー：シフト移動

こっちもふにゃさんにあった機能の取り込み。
本当はふにゃの位置は画面端に行ってはいけませんが、それをやるとふにゃだけシフト移動の挙動が違うという気持ち悪い状態になるので、シフト移動ではお構いなしに画面端に行くようにしています。
その状態はもちろん不正(というよりクリア不可能)な状態なので、警告ぐらいは出してもいいかもしれませんね。

• #32 ステージメーカー：閉じたときの確認を1回にする

こっからは課題なので未実装。
ステージメーカーを編集して閉じるときに「はい」も「いいえ」も選ばすにキャンセルした場合にまた聞かれるというバグ。
原因まだわかってないですが、確かあれ実装するときになんか怪しいなと思った記憶があるので、その違和感の部分を重点的に調べればいいかも。

• #33 本体：2面以降でプレイ中に「スタート」を選んだ場合に確認を入れる

ツールバー実装により1面からやり直すのが簡単になりすぎて、10面まで進んでいたのが一瞬で台無しになる！みたいな事故が起こりそうだと思ったので、確認入れることにしました。
もちろん、ゲームオーバーやオールクリア後ならリスクはないので一瞬でリスタートしてもいいけど。

• #34 本体：ツールバーのアイコンをわかりやすくする

先日言ってた改善の余地も課題立てました。

• #23 ステージ仕様：画面端1マスを通行可能に

これは課題立てじゃなくて、課題中止。
ゲームのルールが変わってしまうような修正は、遺産と化した昔のゲームに対して行うことではないので。
あくまで今回のプロジェクトは、昔作り終わったゲームを今遊びやすくするのが目的であり、新作のゲームを作っているわけではないのです。
ver3ではいろいろ機能追加を予定していますが、ゲームの肝であるアクション周りは変えてはいけないと考えています。

funyak

逆に言うと、完成のめどは立ってないにせよ、funyakは新作です。
大胆に変えちゃってもいいってことです。
大昔に言った加加速度でもいいし、空中でもふわっと動かすために空気抵抗の計算を変えてもいい。
もちろん、ふにゃ1のステージをモチーフにしていても、画面端を通れてもいいでしょう。
ふにゃシリーズのあたりまえを変えていってもいいってことですね。
今はふにゃ1が優先だからまだ先になるけど、ふわっとした動きを中心に考えてみよう。

funyak

• タイルマップ読み込み · Issue #18 · mifumi323/funyak

マップエディタとして、汎用マップエディタTiledを使うというアイディア。
まあ、フルスペックで実装するのはしんどいと思うので、やったとしても一部の仕様を使う程度になると思いますが。

アンパンマンDB(記事更新)

• 用語「水あめアンパンマン」を追加
• 用語「蒸しアンパンマン」を追加
• 用語「メレンゲアンパンマン」を追加

コラムから転記。
違う顔系がそろそろ終わりそうだけど、弱体化系はどうしようかな。
「顔が濡れて力が出ない」とか、ちゃんとした名前らしい名前にならないわけですからね。
あと、オリガミアンパンマンとかの、キャラ扱いすべきかただの物扱いすべきか悩むやつもいるし。

funyakのプロジェクト、今実質ストップしてる状態だけど、それはそうとして一案。

ふにゃってそもそも体重の軽さによる独特な挙動が特徴です。
で、その挙動って、落下速度が遅いことなんですが、他にないかなーってことで、考えてみました。

体重が軽いなら、ちょっと粘着力をつければ簡単に壁や天井に張り付けるのでは？
例えば、タールのような粘液を浴びると壁を歩ける状態になり、一定時間経過か粘液を振り落とす操作で元に戻るとか。

実装するとなると、元のふにゃの挙動から全体的に変わることになるから、別クラスとして用意することになるかな。
しかしそうすると、状態変化のたびに新オブジェクトを作ってパラメータを受け渡す必要が出てくるのか…。

実は物理演算でふにゃの動きの再現を試みたときにも似た挙動はあったんですよね。
この場合は、ゆっくりずり落ちるしかできないし、原理も粘着力じゃなくて摩擦力だったけど。

ユーザー個人ごとのコメントミュート機能の需要がある様子。
簡単にできそうなら作ってみようか。

サブタイトルもなんですが、タイトル本体(h1タグによる大見出し)のほうの見え方も工夫したいなと思っているところです。
スマホなど、横方向が狭い端末だと、タイトルが改行されるわけです。
改行されるのはいいんですが、中途半端な位置で改行されて、例えば「しょくぱんまんといちごだいふくちゃん」が、

1行目：しょくぱんまんといちごだ
2行目：いふくちゃん

みたいになって、しょくぱんまんと苺について述べた後、謎の新キャラ「衣服ちゃん」が爆誕してしまったりします。
だからと言って、ちょうどいい位置にbrタグを置いて強制改行させると、PCとかの横長環境だと無駄に縦に長い見出しになってしまうわけです。

そういうわけで、縦長環境、横長環境両対応できるいい感じの自動改行を求めて調べものと実験をしていました。

自動改行の基本的な考え方を以下の記事を参考に。
Webブラウザの日本語改行問題 -改行を実現するHTML/CSS-（1） #JavaScript - Qiita

折り返しの細かいところは以下の記事を参考に。
文章の折り返し指定のCSS最新版 - ICS MEDIA

先日からCSV出力関連の機能を作っていたわけですが、普通の人はCSV出力機能なんかあったって使わないわけじゃないですか。
一方で管理人の私は、できるだけ多くのページでCSV出力に対応させたいと考えていまして。
今のところ、個別DBの検索結果では、設定を変更すればCSV出力のリンクを表示できるようになっています。
この仕組みをうまく全体に適用できれば、必要な人だけCSV出力機能に便利にアクセスできるようになると思うんですよね。
このあたりのこと、今ちょっと考え中です。

新バージョンか別バージョンか、どうするか決めかねているんですが、データの返し方を大幅に変えようかと思っています。
現状だと、全部連想配列で返しているんですが、今どきのPHPだと、型をしっかりつけたほうがいいんですよね。
まあ、それを想定しての現状の関数名ParseToArrayで、単純にParseToObject関数を生やすのも一つの手なんですが、もう一つやりたいことがあって、そっちが問題なんですよね。
現在、パーサーはParserクラスで、実際にパースするParseToArray関数は、static関数です。
パーサーオブジェクトを作らずに呼び出す形なので、パーサーオブジェクトにオプションを持たせてデフォルト以外の動作をさせるとか、クラスを継承して使用を拡張するみたいなことが一切できません。
だから、オブジェクトを作る前提の別クラスを新たに用意する、というのも考えたのですが、クラス名はParserが完璧すぎて別の名前使いたくないし…。
で、そこまでやると、使い方が根本的に変わってしまうので、そもそも同じライブラリである必要があるのか？って疑問もわいてくるのです。
しかし、別ライブラリとして作るなら、いったいどんな新しい名前にするの？って話にもなるわけで。
サーチに使うと限らないのでサーチの部分変えるか？
検索語の組み合わせを取り扱うのでフレーズという単語を使ったけど、もっとぴったりな単語はあるか？
パーサーの部分は今のところ完璧なので名前から外す気はない。

アンパンマンDB(みんなのタグ)

これまでの行いにより各ユーザーの投票の重みを可変にする仕組みを作成中。
具体的にどう重み付けするかっていうのは一応隠しておきます。
一応、ちゃんとした人が報われるように、という方針ではあります。

ゲーム記

Amazonのアフィリエイト、どうにもiframeでアフィリエイトリンクを埋め込む仕組み自体がなくなった模様。
アソシエイトツールバーにもURL生成しか出なくなりました。
ということは、アンパンマンDBみたいな商品リンクHTMLを自前で作るしかないかな。

ゼルダの伝説　ティアーズ オブ ザ キングダム

昨日は攻略途中で日をまたぎそうになって一言しか書かなかったので、昨日の分も含めて。

モンハンのラスボスみたいなツラしてますが、ストーリーの本筋に関わらない野良の強敵は日記では隠さず出す方針なので。
地底で、なんか闘技場っぽい場所があるなーと思って入ってみたら、グリオークの巣で、全グリオークの属性を併せ持つキンググリオークがいたのでした。
以前は別の場所で雷属性のグリオークにちょっかいをかけて即座に逃げたのですが、今回はそれなりに強い武器と、瘴気ダメージ回復のアイテムをたくさん持って来ていたので、挑んでみました。
前回で頭を弓で射ればいいのかなというところまではなんとなくわかったので、後はあの激しい攻撃をどういなすか、というところが焦点…だと思っていたのですが、案外一撃のダメージが少なかったので、守り方面はさほど大変ではなかったのでした。
ただ、ライネルとかと同じく、ブループリントで出したものの陰に隠れてやり過ごすみたいなことはできないようでした。
攻撃方面は、キースの目玉が八面六臂の大活躍！
最後は飛び上がったところを射落として、落下ダメージでとどめとなったのでした。
しかしこれ、戦い方はどの属性も変わらないみたいだし、全属性分のドロップアイテムがある分、こればっかり狩っていればいいのでは？

ゴロンシティのストーリーはまだ進めるつもりはないのですが、デスマウンテン登頂。
地図での様子から、山頂が深穴にでもなっているのかと思ったのですが、瘴気が噴き出しているだけで、火口はふさがっていました。
やっぱりデスマウンテンの異変も空に行くのかな？

地上絵探しも。
確認すべきポイントもわかってきたので、探索もスムーズになってきました。

で、昨日のメイン、水の神殿。
最初、興味本位でゾーラの里のストーリーを進めずに行ってみたら、神殿には入れたけどギミックが進行拒否して、それまでになってしまいました。
ちゃんとストーリー進めたら、入れました。
ダンジョンを進めて、ボスが現れたところあたりで、昨日は時間切れ。

日記を一言書いて日付が変わってから、ボス戦。
詳しいことは伏せますが、強くはないけど楽しいボスでした。

ゾーラの里のストーリーは、シド王子が（もう王子とは呼べないけど）相変わらず最高でした。

他の写真は以下から。ボスの写真もあるよ。
ゼルダの伝説　ティアーズ オブ ザ キングダム(2023/06/03)の写真
ゼルダの伝説　ティアーズ オブ ザ キングダム(2023/06/04)の写真

FNチェンジャー2

フォルダに対する処理（テストプロジェクトの自動ビルド設定調整） by mifumi323 · Pull Request #7 · mifumi323/FNChanger2
数年前に課題だけ建ててほったらかしだった件、やっと実装しました。
ついでに、CIビルドの設定も済ませて、masterブランチにマージするたびに最新のソースで自動的に実行ファイルが作られるようになりました。
昔書いていた悩みごとの1・8・9・10が、実質8の作業だけで完了するようになったのです。
GitHub Actionの結果ページに、Artifactsとして「Build Result」という名前で置いてあるので、正式公開前の開発中バージョンが欲しい人はここから一足先にダウンロードできます。

のんびりナマライザの自動ビルドも同じ方法でできそう。
こっちはもうちょっとアレンジが必要になりそうだけど。

ドラゴンクエスト10(ァォィョッュ)

• クエスト「聖戦への導き/香りでたどる軌跡」をクリアした！
• クエスト「万物を教え導く者/マスターを目指す者」をクリアした！
• クエスト「聖戦への導き/星辰武王の最終試練」をクリアした！

ァォィョッュのレベル上げ関連のクエスト、一気にいくつか攻略しました。
クリアには至っていませんが、ガーディアン転職クエストも、ボスを倒すところまでは済ませました。

それぞれのボス戦は、「よわい」モードでもァォィョッュにとっては激戦でした。
NPCに「今回は弱くてよかったな」的な皮肉を言われたのですが、何の皮肉にもなっていない事実でした。
ブレス耐性100%の装備を持って挑んだのですが、それができてやっと戦いになるレベルで、物理攻撃や呪文の苛烈さで負けることもありました。
自分天地雷鳴士、仲間ホイミスライムで全部挑んだのですが、この実質3人パーティでも安定はしませんでしたね。
幻魔は、最終的に回復重視のカカロンかダメージ重視のバルバルーの選択となりました。
物理攻撃を軽減しないと始まらないこの戦いは、そういうこと一切してくれないクシャラミとドメディはあまり効果的ではなく、スクルトでこちらの防御力を上げてくれるカカロンか、特技の追加効果で敵の攻撃力を下げてくれるバルバルー、という選択です。

ガーディアン転職クエストでは、自分の防御を上げるより相手の攻撃力を下げる方が有効だったので、時短も兼ねて、バルバルーを選びました。
こいつはブレスより呪文メインだったので、呪文耐性60%の装備をそろえて、マジックバリアで100%を目指す方向にしました。
まあ、なぜかマジックバリアなしの60%でもジゴデインがノーダメージになったんですがね。
あとはガーディアン転職のためのおつかい、もとい、儀式を済ませればこのクエストも完了です。

他の写真は以下から。やっぱりボスの写真あるよ。
写真置き場「2023/06/04」

日記

今回、ゼルダもドラクエも、ネタバレに配慮してボス画像は伏せたわけですが、ボス戦の激戦ってやっぱり日記に喜び勇んで書きたいじゃないですか。
ということで、ネタバレを折りたためる機能を開発しようかと思っています。
本当はアンパンマンDBのために作ろうと思っていた機能ですが、同じシステムを日記でも使いまわしているので、あっちで作ればこっちでも有効になります。
イメージとしては、きらめけ！アイスの国のバニラ姫のページの折り畳みみたいな感じです。
これは無理やりタグを書いて実現していますが、果てしなく面倒臭いやり方なので、短時間で書いてしまいたい日記には徹底的に不適なのです。
楽に実装できるアイディアはすでに思いついているので、それをうまくコードに落とし込むだけ。

カテゴリ再編を検討中。

あと「水中」とか「空中」みたいなやつ。上位概念的な分類項目にしたら色々入れられてよかろうと思ったら、漠然とした概念のため意味不明な判定基準になってしまった。

— 📛松田美文 (@matsuda323) March 26, 2023

アンパンマンDB(記事更新)

「クリームパンダとジャガじいさん」の作品情報を更新
「コキンちゃんとシュガーランド」の作品情報を更新
来週の放送情報。
再放送ですな。

アンパンマンDB(システム)

アンパンマンDBの検索方式として、細かいパラメータを指定できるストリクトクエリというのがあるのですが、言うほど表現力高くなくて、特にペアリスト項目の条件を細かく指定するのがつらいんですよね。
入れ子や配列の表現ができないというのが大きくて、同一行内で同時に条件を満たす場合みたいなのが表現できなかったのです。
そこで、その両方を表現できる、JSON形式のクエリを新たに作るのがいいんじゃないかなとか思いつきました。
確実に今までより大幅に長く複雑な表現になるので、やるとしても、普段表示されるルーズクエリや現行の細かい条件のストリクトクエリは残したまま、JSONクエリを追加することになるかと思いますが。

編集補助機能として何が欲しいかを洗い出してみました。

画像項目：サムネイル付きの選択画面か、リアルタイムプレビュー
読み項目：タイトルから自動生成
日付項目：表記ゆれを正しい形に自動整形
リスト・ペアリスト項目：途中までの入力内容から入力補完(従来もあったやつ)、
分類項目：入力補完、選択肢から記入(テキスト入力に変更したため)、他の項目を参考にサジェスト

リスト・ペアリスト項目の入力補完と分類項目の選択肢が必須、他はできればいいなというくらい。

これとは別に、書き方の説明などもわかりやすく画面に出しておきたいですね。
結構複雑な記法があったりして、作った自分でも忘れがちなので。

PairListのリンク検索、実装しました。
自動テストでは問題ないはずだけど、組み合わせパターンまで網羅はできていないので、リリースはもうちょって手元で確認してからにします。
だいぶ便利になるはずなんですよね。

後、この件とは関係ないですが、実現の目処を建てていない思い付きレベルの構想として、「すべてを名前で管理する」と言うのを考えています。
ミフミンのDQ10メモでやっていることで、例えば「おおきづち」は、装備可能な武器としての「おおきづち」もいれば、敵モンスターとしての「おおきづち」もいるんですが、これを同じページで取り扱います。
本来別物なんですが、「別ページに分かれていたせいで、名前で探したら目的の情報にたどり着けなかった」という事態が避けられます。
それに、「ナガネギマン」と「ネギーおじさん」みたいに、同一人物だけど別名義で活動しているキャラクターに、名義ごとのページを与えられるというのもあります。
ネギーおじさんのページって多分、私個人のこだわりと訪問者の期待がかなり剥離しているページだと思うんですよね。
とはいえ、「TGWSDQX(ミフミンのDQ10メモの旧名義)」の過去ログ(2018年ごろ)をさかのぼってもらったらわかると思うけど、これの実現には、とんでもなく手間がかかります。
あれより複雑なアンパンマンDBだと……さすがに無理じゃないかな、と、今は思うのです。