作ったものを紹介するだけなら、完成画面を一枚見せれば終わります。けれど、同じようなものを作りたい人に役立つ記事にするには、「なぜ始めたか」「どこで迷ったか」「何を分けて実装したか」「どう確認したか」まで残す必要があります。
今回は、好きなURLを一つ入れるだけで、そのサイトを元にしたキャラクターが生まれ、すぐ対戦できる遊びを作るために進めた作業を、履歴から三つ取り上げます。完成品の自慢ではなく、もう一度作るための設計図として書きます。
最初に決めたこと
目的は、好きなURLを一つ入れるだけで、そのサイトを元にしたキャラクターが生まれ、すぐ対戦できる遊びを作ることでした。
最初から全部を作るのではなく、利用者が最初に触る一点から始めます。画面、データ、演出、公開作業を同時に変えると、何が良くなり、何が壊れたか分からなくなるからです。そこで、この作業では一つの変更を小さくし、そのたびに実際の操作と数値の両方を確認しました。
また、ローカルで動いた状態と、公開URLで動いた状態は別物として記録します。ファイルが存在する、HTTP 200が返る、画面で最後まで操作できる。この三つは同じ証拠ではありません。
1. URLをキャラクターへ変換した
URLのhashから属性、能力、240体の見た目を決定し、同じURLなら同じ結果になる決定論を使った。
この変更で重視したのは、機能が存在することではなく、利用者が変化を画面上で確かめられることです。実装するときは、入力、内部状態、表示、保存または次の行動を分けて考えます。そうすると、不具合が起きたときも「操作が届いていない」「計算が違う」「表示だけ古い」を切り分けられます。
2. 戦闘を画面として見せた
各キャラクター3技、属性演出、HP、ダメージ、KO、勝者、挑戦状URLまでを一つの流れにした。
この変更で重視したのは、機能が存在することではなく、利用者が変化を画面上で確かめられることです。実装するときは、入力、内部状態、表示、保存または次の行動を分けて考えます。そうすると、不具合が起きたときも「操作が届いていない」「計算が違う」「表示だけ古い」を切り分けられます。
3. 取得失敗を遊びの停止にしなかった
外部サイトが取得を拒否した場合のフォールバックとCPU候補を用意し、SSRF対策を保った。
この変更で重視したのは、機能が存在することではなく、利用者が変化を画面上で確かめられることです。実装するときは、入力、内部状態、表示、保存または次の行動を分けて考えます。そうすると、不具合が起きたときも「操作が届いていない」「計算が違う」「表示だけ古い」を切り分けられます。
実際に触ると、どこが面白いのか
このツールの面白さは、説明を読んで理解するだけでなく、自分で触った結果がすぐ画面へ返ってくることです。好きなURLを一つ入れるだけで、そのサイトを元にしたキャラクターが生まれ、すぐ対戦できる遊びを作るという目的が、三つの変更を通して一つの体験になります。
作り方を読み進める前に、公開中の版を一度触ってみてください。入力前と結果後で、画面のどこが変わるかを見ると、後半の実装説明を具体的に想像できます。
うまくいかなかったところ
開発中に難しかったのは、画面だけを見て原因を決めないことでした。見た目がおかしくても、原因はデータ、入力、描画、キャッシュ、外部取得のどこかにあります。逆に、テストが通っていても、スマートフォンで押しにくい、画面外へはみ出す、結果が見えないなら完成ではありません。
今回の作業履歴で残っている確認済みの証拠は、240体×3技、PHP・JavaScript構文、専用テスト、PC・375px操作を作業履歴で確認。メニュー導線は公開済み。
一方、未確認も残しています。外部サイトの応答やOG画像は変化するため、現在の公開対戦結果は都度確認が必要。
未確認を隠さないのは、次に同じものを作る人が、完成済みの部分と自分で確かめる部分を区別できるようにするためです。
同じものを作るための順番
- URLをキャラクターへ変換したを、最小の動く状態で作る
- 戦闘を画面として見せたを、最小の動く状態で作る
- 取得失敗を遊びの停止にしなかったを、最小の動く状態で作る
- 入力から結果までを一度通して操作する
- PCと375px、必要なら320pxで画面外へのはみ出しを確認する
- JavaScript、PHP、データ契約のテストを実行する
- ローカル完了と公開完了を分けて記録する
最初の版では、設定画面や管理機能を増やしません。利用者が一回の操作で中心体験へ到達できることを優先します。中心体験が弱いまま周辺機能を足すと、説明文と保守対象だけが増えます。
実装ファイルも責務ごとに分けます。画面の骨組み、見た目、状態計算、入力、保存、外部取得を一つの大きなファイルへ集めない方が、変更範囲とテスト対象を固定できます。ただし、最初から抽象化しすぎず、二度目の同じ変更が現れたところで共通化します。
作る前に紙へ書いておく契約
同じものを作るなら、コードを書く前に五つだけ書きます。一つ目は、利用者が最初に行う操作です。二つ目は、その操作で内部状態がどう変わるかです。三つ目は、変化を画面のどこで確認できるかです。四つ目は、失敗した時にどこへ戻るかです。五つ目は、完了を証明する操作です。
たとえば「ボタンを押せる」は完了条件になりません。「ボタンを押すと対象が変化し、結果が表示され、再読み込み後も必要な状態だけが残る」までを一つの契約にします。外部データを使う場合は、取得成功だけでなく、拒否、空データ、遅延、不正な入力を契約へ加えます。ゲームなら、開始、通常操作、失敗、終了、再挑戦を同じ流れで確認します。
この契約を先に書くと、見た目の調整中にゲームルールを変えたり、データ修正中に共通メニューを巻き込んだりする範囲拡大を防げます。また、記事を書く時も、読者は何を入力し、プログラムは何を処理し、どの結果を見て次を判断するのかを順番に説明できます。
最小版から育てる方法
最初の一周は、仮のデータ一件でも構いません。入力から結果までが通る最小版を作ります。二周目でデータを増やし、三周目で失敗経路を入れ、四周目でPCとスマートフォンを比べます。見た目の演出は、中心操作が成立したあとに一つずつ加えます。
追加するたびに、前の中心操作をもう一度実行します。新しい演出が増えても、開始が遅くなったり、ボタンが画面外へ逃げたり、保存済みデータが読めなくなったら前進ではありません。変更前後を同じ操作で比較し、改善した点を一文で言えない変更は一度止めます。
データが三件以上ある時は、件数、重複、必須項目、画像の存在、URL、並び順をプログラムで検査します。一方、記事の意味、ゲームの面白さ、画像の主役は自動判定だけで決めません。機械が守る契約と、人間が選ぶ体験を分けることが大切です。
作業中の画面写真も、完成記念ではなく証拠として残します。開始前、中心操作の途中、結果の三場面があれば、読者は文章と画面を対応させられます。数値だけを掲載せず、その数値を出した入力と操作も一緒に書きます。
検証で見る場所
検証では、ボタンがあることではなく、ボタンの意味が正しいことを見ます。右を押したら本当に右へ進むか、保存後に同じ状態へ戻るか、結果をコピーできるか、最後まで進んだ時に止まるかを確認します。
スマートフォンでは、375pxと320pxの横幅、44px以上の操作領域、スクロール中の固定要素、画面回転、タップ後の状態を見ます。3DやCanvasをiframeで表示する場合は、外側のページと内側のアプリを分けて確認します。
公開時は対象ファイルだけを転送し、本番のSHA-256を照合します。その後、対象URLだけのキャッシュを更新し、公開HTMLが新しい資産を読んでいるか、PCとスマートフォンで主要操作が完走するかを確かめます。全サイトのキャッシュ削除や無関係なファイル更新は、対象を広げるので行いません。
この作業から得たこと
外部URLを使う遊びでは、成功時の派手さより、取得拒否・遅延・危険なアドレスをどう扱うかが土台になる。
道具を作るとき、完成画面だけを保存しても、次の人は同じ場所へたどり着けません。目的、最小の入口、三つの変更、失敗、検証、未確認を一緒に残すと、作業履歴が再利用できる設計書になります。
この記事は、公開時点のツールURL、画面、資産、未確認事項を確認したうえで掲載しています。SASIEでは本文の理解が変わる場面だけを選び、EYでは記事全体を一枚で伝える主役を決めます。画像を増やすこと自体を目的にはしません。
作り方を読んだあとにもう一度触ると、入力、状態変化、表示、検証のつながりが見えます。
