funyan
実装の前にまずはファイルフォーマット確定させなきゃということで。
チャンクの種類もいろいろあるのでそっちも整理していきたいところですが、ひとまずはコンテナ形式の確定ということで。
以前にも言いましたが、これができればfunyakにも応用可能だし、ステージエディタだけリメイクとかも可能性が見えてきます。
それはそうとして、GitHubのMarkdown、EBNFもシンタックスハイライト効くんですね。
ふにゃさんを.NETに移植するプロジェクト。開発リポジトリはhttps://github.com/mifumi323/funyan
実装の前にまずはファイルフォーマット確定させなきゃということで。
チャンクの種類もいろいろあるのでそっちも整理していきたいところですが、ひとまずはコンテナ形式の確定ということで。
以前にも言いましたが、これができればfunyakにも応用可能だし、ステージエディタだけリメイクとかも可能性が見えてきます。
それはそうとして、GitHubのMarkdown、EBNFもシンタックスハイライト効くんですね。
課題整理。
ゲームとして大幅に変わってしまうものはもはやベタ移植プロジェクトの範疇を超えてしまうので、いったんやめることにしました。
やるとしたら、もっとちゃんとしたリメイクプロジェクトとかでね。
これはゲーム性変えるものじゃないので進めることにしました。
ひとまずはAIに投げてみて、良さそうなら採用、ダメそうなら自分でやるってことで。
マージ押し通しました。
これで無事いくつかの課題も完了扱いになりました。
正直このプロジェクトはfunyak以上に完成の展望が見えないんですが、ステージファイル読み込みぐらいは対応しておきたいですね。
本体の移植が無理でもステージエディタのC#版とかはできるかもしれませんし。
「映画36作目も公開だし好きなアンパンマン映画を3つあげる」を追加しました。
とりあえず.NET8に上げるほうだけやっときました。
んんん???
このAIレビュー、ご指摘はごもっともな気がするけど、Suggested changeがしっちゃかめっちゃかに見えるぞ…?
よく考えたら指摘の内容も、コンパイラが追跡しきれないだけで処理の流れ上非null保証されてるとか、元のソースコードとの対照性のため誤字を護持したいとか、今回は従いたくないやつかもしれない。
レビューを却下してマージ押し通すか。
アストルティア防衛軍、銀甲の凶蟲兵団討伐も達成しました!
先日行ったのとは違い、なかなか強めでした。

七不思議コンプしたいのに雨が降ってて夢幻郷出てこない…晴れを祈願して太陽の踊りを踊るしか…!
ほんとに晴れた!!
ァォィョッュは晴れ女かも!
だとしたら嵐のときしか出てこない大巨人は絶望的かも、って思ったけど、何度かの失敗の末、無事晴れ女に打ち勝って嵐が吹き荒れてくれました。

これで七不思議コンプできたので、報酬の「おどろきとまどう」のしぐさを手に入れました。
他の写真は以下から。日記には書いてないけど七不思議2周目もいくつか撮ったよ。
写真置き場「2025/06/19」
急ですが、ユーザーページの新規登録&パスワード変更画面のパスワードフォームに簡易的ですがパスワード強度チェックを付けました。
ないよりましレベルの簡易的なものなので、このチェックに頼るよりはパスワードマネージャーとかでパスワードを作ることをお勧めします。
実装は、ある程度AIに頼りながら書きました。
ただこれ、自分で書くよりAIに書かすより、誰かが作ったライブラリを探したほうが良かったかもなと思ってます。
人が気軽にAIに頼む程度の要求仕様じゃAIも気軽で雑な実装しか書かないし、それが正しい保証もない。
ライブラリなら、しっかり作り込まれたものであればという前提は必要だけど、仕様は練り込まれ、テストも入念に行われて、サンプルも充実し、使いやすく整備されているはずです。
と考えると、AIを使うのは直接コーディングさせるよりも、便利なライブラリを探させるのに使ったほうがいいのかも。
別に実装は進んでないです。
さっきあんなこと言ったけど、こっちのプロジェクトはむしろ直接コーディングさせるほうでAI活用したいんで、AIの都合に合わせた構成にしたいなーとか考えています。
例えば今GitHubではAmazon Q Developerを入れていますが、こいつはIssueを割り当ててやると、作業用ブランチを作って作業して、元のブランチへプルリクエストを出します。
だったら元のブランチになる候補は数を絞ったほうがいいなということで、フェーズごとのブランチを廃止して、小さな機能ごとでも開発が終わった分はmasterブランチに統合していくことにしました。
Phase2 by mifumi323 · Pull Request #6 · mifumi323/funyan
ということで、このプルリクエストです。
この日記を書くタイミングでプルリク出したので、AIのレビュー待ちでマージは保留しています。
課題立て。
今後どんなテストするにせよステージファイル開けないと始まらないですからね。
一応NuGetパッケージはあるみたいだけど、外部依存を持ちたくないとか、yaneSDK特有の癖とかあるかもしれないとかで、自前で実装したほうがよさそうかと思っています。
課題にも書いてるけど、例えばこことかを参考に。
LZSS – 株式会社イーブ
荒れ放題のみんなのタグ、いろいろ解決すべき課題はあるけど、やっぱり基本は投票の力で正常化したいので、どれに優先的に投票すべきかを判断しやすくなるようにソート機能を用意しました。
今のところ標準の並びの延長線上の順序しか提供できていないので効果は微妙かもしれませんが、これを基礎にしてもっといい感じの順序を提供できたらいいですね。
来週の放送情報。
再放送なのです。
今日の開発。
画像周りを扱いやすくしてます。
みんなのタグの一致度順ソート開発中。
通常のタグ検索の「#○○」と、それに対応するストリクトクエリの場合だけ、一致度順ソートになります。
システム自体はできたけど、パフォーマンスとか細かい確認を済ませてからリリースしようと思います。
細かいコミットが多いのでまとめて。
今回でNullable対応が完了。
真面目に非null保証するより、真っ当に使っていたら仕様前に必ず初期化するはずなのでnullチェック不要とした部分もそれなりにありますね。
で、作業していたら新たな課題も見えてくるわけで…
TravisCIも悪くないけどやっぱりGitHubで完結させたいよねってやつ。
プラットフォームごとの実装が必須なやつですが、未実装の場合には例外、つまり実行時エラーが起きます。
あらかじめわかっていないと、実際に動かすまで問題が発覚しないということです。
これをビルド時に強制したい、という課題です。
ボス倒し終わって残るは報告だけの状態だったので、終わらせました。
物語の性質上、報告だけだとあとがきを呼んだようなプレイ感。
とりあえず続きに着手。
久々すぎていろいろ動かなくなってたんで、実作業としてはこれだけ。

ドラクエ10では歴史的な経緯でアイテムの名前が変わったりしているので、それに対応する対応です。
データ入れるところまでは実装してすでにリリース済みですが、実際にリダイレクトする処理はまだです。
kじゃなくてnのほうね。
kのほうで以前にFPSアップのアイディアについて話したわけですが、実際にアップしてみたら処理落ちしたなんてことになったら嫌なので、一応の完成形が見えているnのほうでFPSの限界を実験してみたいなと。
ずいぶん前に開発が止まったのでうろ覚えですが、確か今はnullable関連の実質無意味な警告と戦っている途中だったんですよね。
これを手っ取り早く動作できるようにして時間計測してみたいと考えています。
うーん、本当にやるんかなぁ…。
管理画面側なので実際に触っているユーザーには影響ないんですが、辞書管理の応答削除機能をいまさら作りました。
UIだけあって何も機能してなかったのが何年も放置されていたんですよね。
うちのサイトで実際に稼働しているほうだけです。
配布用の方は修正する予定はありません、面倒なので。
同じく数年放置案件。
ちょっとだけnullable関連の修正を行いました。

(ァォィョッュ)ヴェリナードの配信クエストを最後までクリアしました。
オーディス王子が王様を目指すやつです。
メインストーリーの方でメルー公が息子を助けるのに執着した理由がわかるんですよね。
オーディスの方はというと、「結局君に頼りっぱなしだったな」と、嘘偽りのない本当のことを言っていました。
もうちょっと自分で頑張ってくれ!
Flaky Testとの戦い - Cybozu Inside Out | サイボウズエンジニアのブログ
Flaky Testという言葉を知ったので。
ソフトウェアの開発に関する用語で、同じ条件のはずなのに成功したり失敗したりと不安定なテストです。
これがあると、不安定だからテスト失敗しているのか、プログラムがまずいから失敗しているのかがわからず、テストが信用できなくなってしまうのです。
要因としては、テスト機材のスペックとか、時間や時期によるものとか、乱数が関わるものとか、通信関係とか、いろいろあるようですね。
うちのサイトのテストでも、そういう不安定なテストがあります。
不安定要因自体も、通信関係を中心に、何が起きるのか確認したい部分があるので、完全になくすことはできないんですが、せめて不安定要因を除いた部分と、不安定要素そのものになるべく切り分けてテストするようにしています。
ビルドエラー完全解消。
開発第二段階に入り、テストプロジェクト作成。
Travis CIでの自動テスト環境も整えました。
おおむね形式的なエラーは取れてきたけど、厄介なのが残っちまった…。
かなりエラーが減ってきた。
ぎゃああああああああ!!!! pic.twitter.com/9wePNtxbUL
— 📛松田美文 (@matsuda323) July 30, 2019
https://github.com/mifumi323/funyan/tree/phase0/Core
やみくもにやってたらわけわからなくなってきたので、いったん仕切り直すことにしました。
https://github.com/mifumi323/funyan/blob/master/readme.md
一度に多くのことをこなそうとすると行き詰まるので、いくつか段階を分けることにします。
ゲームの形になるのはかなり先になりそうですが、前のやり方よりは可能性がありそうです。
想像以上に雑なコードだなおい。
https://github.com/mifumi323/funyan
とりあえずリポジトリ作成。
オープンソースとマルチプラットフォームの2点のコンセプトは前回の移植プロジェクトから引き継いでいこう。
funyakの開発がちっとも進まないので、そのつなぎとしてふにゃさんの.NET移植計画「funyan」発動。
以前やろうとしていたプロジェクトもあるのですが、そっちは理念が先走り過ぎてfunyakでいいじゃんって状態になっていたので破棄。
nは.NETの意味と、ナンバリングタイトルの移植である意味を持たせています。
今回は、極力単なるベタ移植で行きます。