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

ユーザー機能

Twitterログイン、死んで久しいけど、有料API買ったし、復活できるかも。
昔いろいろ厳しくなったときにアプリごと消しちゃったのでアプリ作り直しからだけど。
2023年に潰れてたっぽいけど、あの頃のソースコードは動くかな…。

アンパンマンDB

商品DB、今はほぼ作品と直結するDVDやCDの情報がほとんどだけど、ぬいぐるみとかのグッズ情報も需要あるかな。
とりあえず、私も買ってて店頭でもよく見かけるプリちぃ★ビーンズで試してみるか。

オークストリートの異変

ﾐﾀｸﾅｯﾀ pic.twitter.com/LV4Miuvf6l

— 📛松田美文 (@matsuda323) August 16, 2026

浮き沈みランチャー2

実際使っていて、項目実行後に再初期開くとき、前回の結果が一瞬見えてから今の状態が表示される挙動が気になってきました。
後で課題でも立てとくか。

TGWS世界観測所

Bomber丸Worldの制作が全然進まないことから始まった「テヅカイ」というプロジェクトですが、これもこれで全然進んでいません。
一本のゲームを作ろうとすると、キャラグラフィックやシナリオだけでなく、ゲームを面白くするルール、遊びのバリエーションを増やす豊富なゲームデータ、町などの世界そのもの、音楽、効果音、途方もなくたくさんのものが必要となります。
ツールを使うことでプログラム作成の手間を極限まで減らせたとしても、それ以外もほとんどない今、作るのは途方もない話なのです。
ということで、この中で「世界そのもの」に絞って作ってみようかというのが、『TGWS世界観測所――TGWS World Observatory――』という構想です。
もちろん、世界そのものをつじつまを合わせて全部作るのも途方もない話ですなので、「観測所」から世界の断片を観測できるという形で、少しずつ世界の一部を作っていければと思うのです。
そして、実際にちゃんとしたゲームを作る段になったら、観測できる世界の一部を拝借してくれば、ゲーム作りの第一歩を踏み出しやすくなるのです。

kawax/niconico

Allow nullable search queries and update CI workflows (#6) · kawax/niconico@a867729
無事本家に取り込まれたようです。
…って、ついでの変更多いな。

浮き沈みランチャー2

• デバッグモードのデータ分離

実際使っていかないと開発のモチベも上がんないしなーということで、実際使いつつ開発も続けていくため、開発用データと実際使うためのデータを分けて扱うようにしました。

#if DEBUG
    private const string AppFolderName = "FLaunch2.Debug";
#else
    private const string AppFolderName = "FLaunch2";
#endif

まあ、プリプロセッサを使った古典的な制御ですな。

• #102 実行時に処理完了を待たずに画面を閉じる
• #103 オプションダイアログのサイズを可変に
• #104 項目表示サイズの調整オプション

で、モチベがわいた結果、気になってきたやつ。
#102は実行は非同期でやってUIは即閉じれば良さそう。
#103は初期実装時の設定がおかしかっただけなんで、プロパティ調整でいけるかな。
#104は、イマドキらしく余白の多いオシャレなデザインに寄せた結果、情報密度が下がり、マウス動かす量も増えて微妙だなってやつ。
オシャレに振るのも悪くないとは思うので、確定的な変更ではなく、ユーザーのお好みで変えられるオプションとして課題立てました。
オプションなら、前作以上のギュウギュウ詰めにできたっていいかもね。

美文のキャラ倉庫

美文のキャラ倉庫
Wiki版キャラ倉庫、正式公開しました。
調整したいことはまだあるけど、情報自体はすでに全部入っていて、これ以上オフラインで粘ってもいいことないなって思ったんで、現状で公開しました。
以前も言った年齢順大きさ順とか、人気のページとか、やってみたいですね。
全部情報が入ったとはいえ、Wikiのやり方に合わないものを無理やり入れている部分もあるので、そのあたりの調整を先にやっといたほうがいいかも。

C#用単位・数値変換クラス

年齢順大きさ順といえば、キャラ倉庫の前前前世にあたるCharaBoxに搭載されていて、その部分は一応ライブラリとしても公開されています。
しかし、MediaWikiで使うLuaと違うというのは仕方ないにしても、文字コードがShift_JISだし、C#2向けに作られているし、今となっては使いにくい代物です。
Luaに移植する前に、今使えるライブラリとして、形を整えてみたいですね。
テキストテンプレートかコードジェネレータ使えばdouble以外の型にも対応できるか？

美文のキャラ倉庫

基本データ表示のためのLuaスクリプトほぼできた！
どうせサイトを公開したらスクリプトも全体公開になるのでソースコード置いときます。

local p = {}

function p.process(frame)
    local args = frame:getParent().args
    local result = p.generate(args)

    return frame:preprocess(result)
end

function p.generate(args)
    local string_utils = require('Module:StringUtils')
    
    local fields = {
        { key = 'ふりがな', val = args['ふりがな'] },
        { key = '正式名称', val = args['正式名称'] },
        { key = 'フルネーム', val = args['フルネーム'] },
        { key = '英字表記', val = args['英字表記'] },
        { key = '他の名前', val = args['他の名前'] },
        { key = '公式サイト', val = args['公式サイト'] },
        { key = '登場作品', val = args['登場作品'] },
        { key = '種族', val = args['種族'] },
        { key = '性別', val = args['性別'] },
        { key = '年齢', val = args['年齢'] },
        { key = '大きさ', val = args['大きさ'] },
        { key = '一人称', val = args['一人称'] },
        { key = '二人称', val = args['二人称'] },
    }
    
    local info_rows = {}
    local cargo_rows = {}

    for _, field in ipairs(fields) do
        -- 値が存在し、空文字列でない場合のみ行を生成
        if field.val and field.val ~= '' then
            local key = field.key
            local value = field.val
            if key == 'ふりがな' then
                local sortkey = string_utils.sortkey(value)
                table.insert(cargo_rows, string.format('Furigana = %s', value))
                table.insert(cargo_rows, string.format('FuriganaSort = %s', sortkey))
                if args['表示用ふりがな'] and args['表示用ふりがな'] ~= '' then
                    value = args['表示用ふりがな']
                end
                value = string.format('%s{{DEFAULTSORT:%s}}', value, sortkey)
            elseif key == '登場作品' then
                local titles = mw.text.split(value, '、', true)
                local converted_titles = {}
                for _, title in ipairs(titles) do
                    if title == 'ふにゃ(ゲーム)' then
                        table.insert(converted_titles, '[[ふにゃ(ゲーム)|ふにゃ]][[Category:登場作品：ふにゃ]]')
                    else
                        table.insert(converted_titles, string.format('[[%s]][[Category:登場作品：%s]]', title, title))
                    end
                end
                value = table.concat(converted_titles, '、')
            elseif key == '種族' then
                local kinds = mw.text.split(value, '、', true)
                local converted_kinds = {}
                for _, kind in ipairs(kinds) do
                    table.insert(converted_kinds, string.format('[[%s]][[Category:種族：%s]]', kind, kind))
                end
                value = table.concat(converted_kinds, '、')
            elseif key == '性別' then
                value = string.format('%s[[Category:性別：%s]]', value, value)
            end
            table.insert(info_rows, string.format('<tr><th>%s</th><td>%s</td></tr>', key, value))
        end
    end


    local result = ""
    
    if next(info_rows) then
        result = string.format("%s<table class=\"wikitable\">%s</table>", result, table.concat(info_rows, ""))
    end
    
    if next(cargo_rows) then
        result = string.format("%s{{#cargo_store:_table = BasicData|%s}}", result, table.concat(cargo_rows, "|"))
    end

    return result
end

return p

local p = {}

function p.sortkey(furigana)
    if furigana == "" then return "" end

    local sortkey_table = {
        {"が", "か"}, {"ぎ", "き"}, {"ぐ", "く"}, {"げ", "け"}, {"ご", "こ"},
        {"ざ", "さ"}, {"じ", "し"}, {"ず", "す"}, {"ぜ", "せ"}, {"ぞ", "そ"},
        {"だ", "た"}, {"ぢ", "ち"}, {"づ", "つ"}, {"で", "て"}, {"ど", "と"},
        {"ば", "は"}, {"び", "ひ"}, {"ぶ", "ふ"}, {"べ", "へ"}, {"ぼ", "ほ"},
        {"ぱ", "は"}, {"ぴ", "ひ"}, {"ぷ", "ふ"}, {"ぺ", "へ"}, {"ぽ", "ほ"},
        {"ゔ", "う"},
        {"ぁ", "あ"}, {"ぃ", "い"}, {"ぅ", "う"}, {"ぇ", "え"}, {"ぉ", "お"},
        {"ゃ", "や"}, {"ゅ", "ゆ"}, {"ょ", "よ"}, {"っ", "つ"}, {"ゎ", "わ"},
        {"あー", "ああ"}, {"いー", "いい"}, {"うー", "うう"}, {"えー", "ええ"}, {"おー", "おお"},
        {"かー", "かあ"}, {"きー", "きい"}, {"くー", "くう"}, {"けー", "けえ"}, {"こー", "こお"},
        {"さー", "さあ"}, {"しー", "しい"}, {"すー", "すう"}, {"せー", "せえ"}, {"そー", "そお"},
        {"たー", "たあ"}, {"ちー", "ちい"}, {"つー", "つう"}, {"てー", "てえ"}, {"とー", "とお"},
        {"なー", "なあ"}, {"にー", "にい"}, {"ぬー", "ぬう"}, {"ねー", "ねえ"}, {"のー", "のお"},
        {"はー", "はあ"}, {"ひー", "ひい"}, {"ふー", "ふう"}, {"へー", "へえ"}, {"ほー", "ほお"},
        {"まー", "まあ"}, {"みー", "みい"}, {"むー", "むう"}, {"めー", "めえ"}, {"もー", "もお"},
        {"やー", "やあ"},                   {"ゆー", "ゆう"},                   {"よー", "よお"},
        {"らー", "らあ"}, {"りー", "りい"}, {"るー", "るう"}, {"れー", "れえ"}, {"ろー", "ろお"},
        {"わー", "わあ"}, {"ゐー", "ゐい"},                   {"ゑー", "ゑえ"}, {"をー", "をお"},
    }

    for i, v in pairs(sortkey_table) do
        local from = v[1]
        local to = v[2]
        furigana = string.gsub(furigana, from, to)
    end
    
    return furigana
end

return p

まあ、おおむね引数で渡された項目を表に表示して、一部項目に特殊対応を入れている程度です。
ソートキー生成は、アンパンマンDB用にPHPで作っていたものをLuaに移植したもの。
文字列連結を繰り返すと遅くなるらしいので、ある程度はテーブルやstring.formatを使って連結を減らしています。
どこまで効果あるのか知らないですけどね。

欲を言えば、年齢や大きさも特殊対応入れたい。
昔作ったC#用単位・数値変換クラスをLuaに移植して、年齢順一覧とか大きさ順一覧とか作りたいんですよね。
ただ、ここで欲張ると公開がさらに先になっちゃいますからね。

kawax/niconico(TGWS内部処理)

PHPのバージョンを8.5に上げたいとか言ってましたが、思わぬところで問題が出ました。

kawax/niconico: ニコニコ動画API

ニコニコ動画の情報取得に使ってるこのライブラリ、誤動作とか致命的なエラーはないんですが、PHP8.4でDEPRECATEDが出るようになったのです。
場所を修正方法は把握していて、niconico/src/Search/Query.phpの16行目と、同29行目のパラメータです。
これが、null許可しないと明示されているのに初期値null扱いされているので、将来のバージョンでエラーにするから今のうちに直しとけよという警告を出してくれているというわけです。
昔のバージョンでは、null許可すると明示しなくても初期値nullにしておけば、暗黙的にnull許可扱いにしてくれていたんですが、それをやめることになったんですね。
だから、修正方針としては以下のように、型指定に「?」を付けて、null許可を明示します。

-    public function __construct(array $query = null)
+    public function __construct(?array $query = null)

-    public static function create(array $query = null): static
+    public static function create(?array $query = null): static

…というIssueとプルリクを明日出しとこう。そうしよう。

日記

さっきDIFFっぽいもの書きましたが、DIFFとしてのシンタックスハイライトは入れていません。
「```diff-php」とやればPHPのDIFFが出ると期待したんですが、コードブロック機能が壊れてしまいました。
なので、今は「```php」として、普通のPHPコード扱いでシンタックスハイライトを入れています。
今使っているシンタックスハイライトがDIFFに対応しているのかはわからないのですが、コードブロック機能が壊れるのは避けたほうがよさそうな気がします。
このコードブロック機能は私が作ったTgwsMarkの機能なんで、Issueとプルリクというより、自分で直すべき案件ですね。

美文のキャラ倉庫

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

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のために作ろうと思っていた機能ですが、同じシステムを日記でも使いまわしているので、あっちで作ればこっちでも有効になります。
イメージとしては、きらめけ！アイスの国のバニラ姫のページの折り畳みみたいな感じです。
これは無理やりタグを書いて実現していますが、果てしなく面倒臭いやり方なので、短時間で書いてしまいたい日記には徹底的に不適なのです。
楽に実装できるアイディアはすでに思いついているので、それをうまくコードに落とし込むだけ。