1. 入れたい機能を全部決める前に、プレイヤーがする動作一つと、そのあとの反応から選んでみよう。
2. 全体の設計はAstra、範囲が明確な小さな修正はLunaで試してみる予定だよ。
3. 変えるところと維持するところ、実行方法を伝えて確かめ、まだ作っていない機能や測っていない節約率は書かないよ。
AIもコーディングも初めてのスナックガールズが、実際に試して、つまずいたところを記録する開発日誌です。ゲーム制作の話は、今回が第1回。作りたいものはいっぱいあるけど、AIには何から頼めばいいんだろう?


入れたいものはいっぱい。どこから始める?
デジタルメディア研究部で、ゲームを作る話を切り出したよ。私が最初のアイデアを言い終わる前にキラリが手を挙げて、聞いていたネアも少し身を乗り出したの。ちょっと待って、一人ずつ! 始めようって言っただけで、こんなに話が出てくるとは思わなかった。

失敗しても、すぐもう一回できるといいな。惜しいところで終わると、またやりたくなるじゃん!

私は、自分で押しながらルールを覚えていくのも好きです。最初の説明が長すぎると、早く始めたくなりますし。
私は、押したらすぐ反応が返ってくるものを作ってみたい。でも、あれもこれも入れていたら、AIに最初のお願いを書く前に作るものが山積みになりそう。みんなのやりたいことは残しておいて、まず試す動作を一つ選んでみようと思う。どんなゲームを作るかは、話し合いながら決めていくよ。
Astraでゲーム制作に挑戦してみたい
今回、ゲーム制作に使ってみたいモデルはGPT-6 Astra。コードを書くところから、いくつもの機能をどうつなげるかまで、一人だと途方に暮れそうなところを一緒に考えてもらいたいんだ。
ここでいう「モデル」は、同じAIサービスの中で選べるAIの種類だと思えば大丈夫。OpenAIはAstraを、複雑な推論やコーディングなどに使うモデルとして紹介しているよ。それでゲームが勝手に完成するわけではないんだよね。私たちが欲しい操作やルールを説明して、できたものを自分で動かしてみる必要があるの。Astraの公式説明

じゃあ、「面白いゲーム作って」から書けばいいのかな?

どんな動作を楽しくしたいのか教えてください。自分で押して、確かめられるようにしましょう。
考えてみると、「面白く」だけじゃ足りないよね。どのボタンを押すのか、押したら何が変わるのかから説明しないと。最初は、プレイヤーがする動作を一つと、そのあとに起きることから決めてみようと思う。
ボタン一つ直すときも、ずっとAstraを使う?

ゲームは、一度頼んだら終わりとはいかなそう。文字の大きさを変えたり、ボタンを動かしたり、おかしな動作を直したりするからね。そのたびに、どのモデルを使うか考えてみようと思う。
全体の設計や原因を見つけにくい問題はAstraに、やることがはっきりした小さな修正はLunaに頼んでみる方法だよ。GPT-6 Lunaは、公式文書では範囲の明確な作業を効率よく処理するモデルとして紹介されているの。下の分け方は、その説明をもとに今回の制作で試してみたい作業の進め方だよ。Lunaの公式説明
| こんなお願いなら | 最初に試すモデル | 終わったあとに確認すること |
|---|---|---|
| いくつもの機能を、どんな順序と構造で作るか決める | Astra | 最初に試す範囲が大きすぎない? |
| 決めておいたボタンの文言・色・間隔を直す | Luna | ほかの画面や動作まで変わっていない? |
| エラーの場所と、求める動作が明確な小さな修正 | まずLunaで試す | 同じ操作をしたときにエラーが消えた? |
| 修正を繰り返す、またはいくつもの機能が一緒におかしくなる | Astraで原因を再検討 | 推測した原因を実際に確かめた? |

じゃあ、全部Lunaでやればいいんじゃない?

同じところを何度も直すと、もっとかかるかもしれません。直ったかどうかも見ないといけませんし。
そうだね。一回のお願いが安いことと、欲しい結果が出るまでにかかる量が少ないことは、違う場合もある。簡単そうなエラーでも、原因は複雑かもしれない。同じ修正が繰り返されるなら、同じお願いをそのまま送るより、うまくいかなかった方法と今の画面を整理して、もう一度考えてみようと思う。
トークンを節約するなら、説明を減らせばいい?
トークンは、AIが読み書きする情報を区切る小さな単位だよ。一文字や一単語と、ぴったり同じではないの。お願いの文章だけでなく、読み込んだファイル、会話の履歴、ツールの結果、答えも利用量に含まれるよ。
必要な条件まで省いて「いい感じにやって」と書くと、どんな結果が欲しいのか伝わりにくいよね。今変えるところと、そのままにするところをはっきり書いて、関係のない資料を減らす方向で試してみようと思う。公式の利用量ガイドでも、関連する資料に範囲を絞り、必要な出力だけを頼むように説明しているよ。Codexの利用量・料金ガイド
単価の安いモデルに変えても、トークン数そのものが必ず減るわけではないよ。今回は、どの作業にどのモデルを使ったか、何回直し直したか、実際の利用量はどうだったかも一緒に記録してみたい。まだ測っていない節約率は書かないよ。
モデルを変える前に、今どこまでできたか残そう
モデルを切り替えるときも、新しい会話に作業を移すときも、引き継ぐ相手が今の状態を把握できるようにしたい。特に新しい会話で、それまでの話を全部知っていると思い込むと、別々のものを作ってしまうかもしれないよね。
長い会話を丸ごと貼り付ける代わりに、実行方法、今できること、できないこと、触らないところ、次にすることを短く書いて、関係するファイルも一緒にリンクしておこうと思う。説明だけになって、実際のファイルが抜けないようにね。

下のゲームプロジェクトの開始画面だけを修正して。 現在の実行方法:[コマンドまたは実行の手順] 関連ファイル:[実際のファイルパス] 現在の見た目:[スクリーンショットまたは症状] 変えること:開始ボタンの文字を[希望する文言]に変えて、 小さな画面でも切れないようにして。 維持すること:ボタンを押したあとの動作とゲームのルールは変えないで。 関連するファイルから確認して、必要なところだけ修正して。 利用できる環境で実行し、ボタンのクリックと小さな画面を確認して。 直接確認できなかったことは、区別して教えて。 最後に、変更したファイル、確認結果、残っている問題を短くまとめて。
これは、特定のモデルにしか通じない呪文ではないよ。頼まれた側が、どこまで変えていいのか分かるように書くの。きちんと動いていた状態は戻せるように保存しておいて、一つずつ変えて確認すると比べやすいよ。
まず一つ、動かしてみよう!
「それはあとで…」と言いかけて、止まった。キラリはまだ話し終わっていないのに、私が先に遮っていたんだよね。最後まで聞いたら、また入れたいものができちゃった。このままだと、今日はおしゃべりだけで終わりそう。指を一本立てて、まずは一回押したら反応するものから作ってみようと提案したよ。

シロちゃん、初めて遊ぶ人がどこでつまずくかも、一緒に見ようよ。

いいですね。説明を読まなくても試せるか、気になります。
入れたいものは、まだいっぱいあるよ。押したとおりに反応するか、友達も遊んでみたいと思うか。小さく作って、自分たちで確かめるところから始めてみたい。実際に何を作って、どこでつまずいたかは、作る過程と一緒に開発日誌で紹介していくね。


コメント
0ログイン不要。投稿したブラウザから編集・削除できます。
すべてのコメント 0
한국어 · English · 日本語まだコメントはありません。最初のひとことをどうぞ。