開発のために構造化した話
結論
制作するときの共通ルール、用途ごとのルール、キャラクターごとの設定、過去の制作記録を分けました。
次に作るときに、自分もAIも必要なところを見に行けるようにしたかったからです。
きっかけはゲームの画像だったのですが、気づいたら問題や物語、保存、レビューの手順まで整理することになりました。
画像を揃えたかっただけなのに、だいぶ話が大きくなった。。。。
ということで、順を追って書いていきます。
【そもそも何を作っているのか】
コードの知識を学ぶRPG「CodeChronicle」を趣味で作っています。
FF6とか、SFC時代のRPGのUIやUXが好きなので、そういう雰囲気のゲームにしたいです。
開発するのは、毎日1時間ごとに取る5分休憩の時間です。
OrcaでAIの担当を分けて、並列で作業することもあります。
ただ、担当が変わるたびに、前に何を決めたのか説明する必要があります。
前の画像ってどうやって作ったんだっけ？？
あのキャラクター、会話するときも同じ画像だったっけ？？
こういうことを、毎回会話の中から探すのは大変です。
次の5分で開発を始める自分にも、分かるようにしておきたい。
そんな話です。
【泉と扉、なんか違う、、、、】
最初は、泉と扉の画像が気になりました。
ほかの素材は細かく描き込まれているのに、そこだけ簡易的なSVGになっていました。
同じゲームに置いているのに、違う世界から来たように見える、、、、
謎の騎士も同じでした。
マップではPNGの騎士が表示されるのに、会話すると32×40の簡易SVGが表示される。
マップで見たあの騎士はどこへ？？
確認すると、マップと会話で別の描画経路が残っていました。
つまり、画像を一枚確認して終わりにはできない。
同じ騎士でも、どこに表示されるかまで確認しないといけないんですね。。。。
それと、PNGにすれば全部揃うという話でもありません。
描き込みや色、実際にゲーム内で表示したときの大きさまで、ほかの素材と合わせる必要がありました。
【状況整理】
画像を作ったときの指示は残っていました。
ただ、残り方が「主人公の歩行」「騎士の肖像」のように、作った対象ごとだったんです。
主人公を歩かせるために考えたことは、ほかの人物を歩かせるときにも使いたい。
騎士の会話画像を作るために考えたことも、ほかのキャラクターに使いたい。
でも、そのまま使うと主人公の髪色や騎士の兜までついてくる。
そこは引き継がなくていい。。。。
共通で使えるところと、そのキャラクターだけの特徴が混ざっていました。
だったら、「主人公の歩行」から「歩行」のルールを取り出せばよさそうです。
「騎士の会話画像」も「キャラクターの会話用画像」にする。
そこへ、今回作るキャラクターの特徴を足すことにしました。
【共通のところと、その子だけのところ】
今は、こんな組み合わせで制作の指示を作ります。
みんなで守る共通ルール
＋ 何に使うかのルール
＋ 今回作る対象の設定
＋ 今回変更したいこと
たとえば、騎士の会話用画像ならこうです。
共通ルールには、既存の素材と絵柄や描き込みを揃えること。
会話用画像のルールには、頭や肩を枠に収めることや、PCとスマホの会話画面で確認すること。
騎士の設定には、閉じた兜、顔を隠す黒いバイザー、紫のマントなど。
ほかのキャラクターを作るなら、この騎士の設定を差し替えます。
全員に兜をかぶせたいわけではないので。。。。
歩行も、方向を描き分けることや、足元を揃えることは共通にします。
主人公の青黒い髪や青い衣装は、主人公の設定に置きます。
ただ、主人公が4方向×3コマだからといって、四足の生き物や飛ぶ生き物にも同じ形を要求するのは違う気がします。
何でも同じにすればいいわけでもないんですね。
用途のルールは、会話用画像、マップ用画像、歩行、攻撃・戦闘表現、環境素材、状態差分、背景の7つに分けました。
【これ、画像以外にも必要では？？】
NPCを追加するなら、画像だけ作っても終わりません。
どこに置くのか、何を話すのか、いつ登場するのか。保存はどうするのか。
学習問題も、問題文だけではなく、採点や出題する場所、復習の記録まで関係します。
画像でやった整理を、アプリ全体でもやりたい。
ここからは、円卓レビューで壁打ちしました。
肯定派、中立派、否定派、ユーザー代弁者の4つの視点で考えてもらい、自分も一緒に検討します。
さらに、質問で前提を掘り下げるgrillingで、分類が足りているか、共通化したつもりになっていないかを詰めました。
その結果、制作の入口を9ジャンルに分けることにしました。
| ジャンル | たとえば |
|---|---|
| 世界・場所 | 地形、建物、町、出入口 |
| 人物・生物 | 主人公、NPC、敵 |
| 動き・演出 | 歩行、攻撃、回復 |
| 物語・進行 | 会話、イベント、クエスト |
| 教材・学習 | 問題、解説、復習 |
| ゲームルール | 戦闘、成長、装備、報酬 |
| 画面・表現・操作 | UI、文字、音、操作 |
| 状態・保存 | 進行状態、設定、セーブ |
| 制作・運用 | 担当、レビュー、検証、履歴 |
ここで、全部をフォルダの親子関係にするのはやめました。
たとえば「洞窟にある閉じた扉の画像」。
洞窟は場所、扉は対象、閉じているのは状態、画像は媒体です。
これを全部一列に並べようとすると、ほかの場所の扉と共通にしたいことが見えにくくなります。
大きな分類は一つにして、場所や用途、状態などは分けて考えることにしました。
【で、どこを見ればいいのか】
制作の入口はdocs/production/index.mdに置きました。
そこから、ジャンルごとの案内、用途のルール、人物の設定へ進めるようにしています。
ただ、文書を増やすと「同じことがあちこちに書いてある」問題も出てきます。
片方だけ直したら、どっちが正しいんだろう。。。。
なので、情報ごとに管理する場所を決めました。
作業の進め方はSkill。
ここでいうSkillは、AIへ繰り返し渡す作業手順や判断基準をまとめた文書です。
作るときのルールは共通仕様と用途別仕様。キャラクターの特徴は個別設定。
実際に動く値はコード。過去に何を作ったかは履歴。
たとえば、画像の切り出し座標をコードにも文書にも書いてしまうと、更新がずれます。
なので、文書にはコードの参照先を置いて、今の数値はコードを見に行きます。
問題作成には、もともとquestion-authorというSkillがあるので、採点や入力の公平さのルールはそちらを参照します。
整理するために、同じルールをもう一個作ってしまったら大変なので。
それと、過去の「主人公の歩行」という制作記録は、その名前のまま残しました。
当時、主人公のために作った事実まで変える必要はありません。
今後も使うルールを取り出すことと、過去の記録を書き換えることは別にしました。
【次のAIにも渡せるようにする】
AI向けにはproject-guideというSkillを入口にしました。
何を作るかを確認して、必要なルール、個別設定、実装する場所、確認方法へ進むための手順です。
画像を作るならgame-art、問題を作るならquestion-authorにつなぎます。
全部読んでね、だと読む量も増えてしまうので、その作業に必要なものを選びます。
並列で担当を分けるときも、触るファイルと参照するルールをセットで渡す形です。
レビューの手順もSkillにしました。
実装した担当とは別の2エージェントに、同じ版をそれぞれ確認してもらいます。
最初の結果が出たら、互いの指摘を確認してもらいます。
相手の指摘を支持するのか、反証できるのか、まだ未確認なのか。根拠も一緒に返してもらって、親の担当がまとめます。相互確認は最大2往復です。
自分で作って自分で見直すことと、別の担当が見ることは分けたかったためです。
今回の整理も、独立した2名で確認して、互いの指摘を検証しました。
ファイルの一覧は既存のdocs/architecture/file-inventory.jsonを使い、対象ファイル全体を9ジャンルに分類しています。
分類漏れや更新漏れ、制作案内とSkillのリンク切れは、スクリプトで確認するようにしました。
もちろん、これでゲームの見た目まで確認できるわけではないので、画像は実画面で、動作は関係するテストで確認します。
【全部共通化できた、ではない】
ここまで整理しましたが、設定を一つ書けば何でも追加できる状態になったわけではありません。
主人公の歩行や、騎士の表示には専用の実装が残っています。
音を追加するときの確認手順を置くことと、BGMを再生する機能を作ることも別です。
今回は、まず制作のルールを整理しました。
実行コード全体を組み替えるのは別の段階にして、ルールがあるだけなのか、設定で追加できるのか、専用実装なのか、未対応なのかも分けて書いています。
既存のID、画像の切り出し座標、採点、保存形式も、分類を揃えるためには変えません。
次に何か作るときは、入口から必要なルールと設定を辿って、どこに追加して何を確認するかを見に行けます。
こうやって、共通のところと個別のところを分けていくのは楽しいです。
ゲームを作りたいのに、作るための構造を考えるのも楽しい。。。。
CodeChronicleは、冒険しながらコードを学べるRPGに育てていきたいです。
その続きを作る次の自分とAIに、今回決めたことを渡せるようにしておきました。
リポジトリ：CodeChronicle