プログラミング学習日記　2026/02/05　我慢できないので「（曖昧な麻雀知識で作る）ひら◯な麻雀」電子化を開始する

　Bubble Teaを使ってのRPGっぽいのを作るプロジェクト・・後はもうおデータを作っていくだけなので熱意がちょっとね・・

　ということで、気分転換で次のプロジェクトに進もう！

　とりあえず基本的なルールも知らないのでGeminiに質問してみる

　ふーむ

　すべて使い切って　と　1つ以上　ってことは・・単語の文字数は決まってないのか。感覚的に50音で手牌が14枚だと厳しいから・・まあ50音3セットくらい使うのかな？と思ってたけど、そもそも手牌を減らすデザインだった。でも物理的な制約がないんだったら、50音を4セット、手牌14枚、頭2文字、4文字は鳴きでのみ作成可能って方が良くないかな？まあ、元々のルールを知らんのですけど。

　単語の判定については腹案があるのだ

　配牌された時点でグルーピングし、グループが確定した時点でUIにある「登録」キーで単語登録、一旦グルーピングしたものを解散させる「解散」キーも用意しておく。そのうちに意味のある単語が揃って役が出来て上がった時点で「役名」を入力、その際に各単語（つまり辞書の辞書？）に「役」のタグを埋め込む・・ってのをコツコツ対人で1000勝負くらいやったらルールが自動生成されるんじゃないか？と

　ふーん・・5文字以上か・・。ま〜言葉を使う以上3文字とかに限定する必要は無いのだけど、それだと何でもありになりすぎるような？

　とりあえず考えてたのはここで言うフェーズ１の部分だけでした。十分に単語辞書が育ったら、たしかにサジェスト機能はありだな〜

　あ、APIを使えばそもそも単語は照会出来るかも知れないのですな？まあでも、辞書登録フェーズそのものが学習の一環なんで・・

　というわけで、何は無くとも構造体ということで・・こんな感じかな？というのを一応作ってKiroに添削してもらう。いきなり作ってもらってては学習にならんからね。でもAIのコーディング能力の進化（の記事）を見てるとホント自己満足でしかないけどね

　ということでKiroが考えてくれた修正案、具体的には

　こういう感じ。

・捨て牌って川って言うんだ・・この構造だとプレイヤーごとに川を管理するんじゃなくてカードゲームの墓場みたいなシステムだけど・・これだと川の状態を見て山に残ってる牌を読むとかってのが出来無さそうだが？誰かを狙って上がるあれ、ツモじゃなくてロンだったっけ？あれも個人で川を持つ方が簡単そうだが。

・WordDicは[]stringじゃなくてBoolを値に持つ辞書にするわけか・・なるほど。検索コストが下がるわけだな

・YakuDicは確かにスコアをもたせるとなるとこうなるか・・

・WordYakuDicは・・履歴？これも辞書にして呼び出して更新・・みたいにすればいいと思うけどどうなんだろうか

・Phaseは忘れてた。これをキーにしてBubble Teaで状態遷移をしないとな

・Tehaiの構造、なるほど分けないとね。とりあえずコードを書き始めないと良し悪しは分からんな〜

・Group構造体、これはUIで単語の並びになるように選ばないといけないけど、サジェスト機能を前提に考えるならばバラバラのデータも持っておかないと困るだろうし、Word構造体を作ってRuneで構成文字をデータとして持たせたものをBoolの代わりに入れるべきではないだろうか？

・IsNakiはなるほど！でも鳴くとどういうメリット・デメリットがあるのか知らんからなｗ。文字数が合わなくなったりしないんだろうか？マンガを見てると横に別で並べてるので、４文字でも１セット（３文字と一緒）として扱ってるとか？例えば４文字以上の単語は鳴きでしか作れないようにするとかどうだろうか？鳴きであれば無限に長い単語を作っても良いとか？