日曜大工プログラマー向けの優れたゲーム設計プロセス


36

私はゲーム開発のかなり新しいです-Androidプラットフォームで、一人のゲーム開発を考えています。グラフィック、サウンド、音楽などのすべてを専門的に行うことはできないことは知っていますが、コーディングが終わったら後で心配することができると思います。

私の現在の障害は、ゲーム設計プロセスのセットアップです。A Theory of FunやBook of Lensesなどのゲームデザインに関する本や講義ノートをいくつか読みましたが、プロセスについてはまだわかりません。

もちろん、ゲームのアイデアを作成することは長期的には一種の独立したプロセスなので、この質問でゲームのアイデアをすでに持っていると思います。しかし、概念化のために、私は何ができますか?人々は通常、このためにデザイン文書とストーリーボードを作成すると思います。しかし、Androidプラットフォームの場合、設計ドキュメントが必要かどうかはわかりません-おそらく設計の要約で十分でしょう。その場合、ストーリーボード(またはゲーム画面の落書き)で十分です。ゲームデザインで他に何をする必要がありますか?

回答:


47

私はいくつかのモバイルゲームを作り、アップルのアプリストアで少しお金を稼ぎ、ほぼ独占的にこのプロセスを使い始めました。しかし、すべての開発プロセスが進むにつれて、しばらくして独自のものを開発します。

これは、チームメンバーの1人に送信したメールのコピーです。

  1. ゲームの簡単な説明を書きます
  2. 主なゲームプレイイベントを書き出す
  3. 紙にアイデアをプロトタイプし、それらが論理的に意味をなすかどうかを確認します。紙上のイベントを「プレイ」する
  4. 各イベントの基本的なユースケースを書く
  5. ゲームのアートワークの概念をいくつか描く
  6. 基本的なユースケースごとにユースケース図を作成する
  7. ユースケースを可能にするために必要なシステムの相互作用を詳しく説明します(ブラックマジックのように見える相互作用をスキップしないでください。「画面をクリックすると、ユニコーンが地形上に出現します。」ユニコーンをマウスの下の正確な地形の位置。)
  8. クラス図の作成を開始します(「GameCoordinator」などの神のクラスを避け、代わりに各論理オブジェクトのクラスを作成し、これらのクラス間の相互作用をできる限り分解します。これは苦痛なレッスンでした)
  9. 機能が制限されたゲームのプレイ可能なデモを作成する
  10. 数人の友達にプレイして壊してもらう
  11. 繰り返し...繰り返し...ゲームプレイイベントで繰り返します
  12. インターフェイスを引き出します。
  13. インターフェイスを機能させる
  14. すべてのモバイルアプリレビューWebサイトにレビューリクエストの送信を開始する
  15. インターフェイスを磨く
  16. あなただけではなく、多くのモバイルデバイスでそれを徹底的にテストしてください
  17. 悪いレビューで泣く
  18. 大きな問題を修正
  19. 良いレビューで笑顔
  20. ゲームを更新する

そうは言っても、最初のいくつかのゲームのラピッドプロトタイプを作成するまで、この種の計画をたぶん評価しないでしょう。Tetradが言ったように、この計画を使用するように言うことと、プロトタイプを作成して繰り返すことの間で私は破れています。あなたの最初のゲームのために、設計プロセスに行き詰まるのを避けましょう。設計プロセスを考え出すことは、プロセスが必要な理由を学ぶ際に得られる経験ほど重要ではありません。それでも、最初のゲームのプロセスがあればいいのに、お金を稼ぎ始めたらコードの大部分をリファクタリングしなければならず、いくつかのことを更新する必要があったからです。


1
正しいと思う場合は、回答として自由にマークしてください!私にとってはうまくいくものを思い付くために多くの痛みを伴う試みが必要でした。ちなみに、これはプログラミングに重く、多くのアートと音楽のステップをスキップしますが、それらは私のための反復と同時に動作します
ブランドン

私は両方の答えがとても好きです。しかし、この時点でゲームのステップ2、4、6を実行するとは思わない。ステップ8からは、設計よりも実装やその他のアクティビティが多くなります。これを答えとして受け入れる唯一の理由は、これがもう一方のスーパーセットのようだということです。あなたが提案したように、私は最初にTetradのアプローチから始め、それからあなたの答えに追加のステップが必要かどうかを見ます。
泰-宋新

2
@ポール良い計画。その一部は冗談を意図していますが、それでもあなたが経験することへのヒントを提供します。私があなただった場合、私はイベントをもっと調べます。「構造の作成、構造のアップグレード、構造の販売、ビルドのキャンセル、ユニットの移動、ユニットフォームの構造の構築」などのイベントがあるRTSを作成したいとします。コードに飛び込む前に助けてください。頑張って!それは常にあなたの最初のソロプロジェクトでの経験です。
ブランドン

30

個人的には、ラピッドプロトタイピングから始めます。

小規模なゲームの場合、設計ドキュメントは実際に問題全体について考えるように強制するのに適しています。すべてをプロトタイプにカプセル化できる場合、すべてを書き留める理由はありません。

ゲームのアイデアを頭に入れて、コアループを実装します。何かがそこにあるように思える場合は、それを繰り返します。何かおもしろいことがあるときは、その周りに退屈な部分(メニュー画面、オプションなど)を構築して出荷してください。


4
プログラミングを始める前に少なくともいくつかのメモを書きますが、完全なデザインドキュメントがプロトタイピングの邪魔になります。
12

3
それは直感的ですが、正式なプログラミングの背景から来ているので、コーディングする前に何かをする必要があるように感じます。このアプローチでは、設計の要約とTo Doリストで十分だと思います。ありがとう。
泰-宋新

1
設計概要とToDoリストは、「いくつかの注意事項」で私が念頭に置いていたものです。ToDoリストは流動的にしますが、開始するのに十分なタスクを書き留めてから開始してください。リストに項目を追加していきます。
冗談

@Paul正式なプログラミングのバックグラウンドから来ていると言うとき、UMLのような構造を考えていると思いますか?これらすべての図(私の謙虚な意見では)は、コードを説明することなく、他の人にあなたの作業を示す目的にのみ役立ちます。設計ドキュメントも同じ目的に役立つと思います。お金やその他の種類のサポートが必要な場合は、ゲームを誰かに見せるために使用できます。
TravisG

@heisheこの時点で他の人に自分の作品を見せる必要はないことを理解しています。後でゲームをレビューするために、私は自分自身の設計成果物に関心がありました。とにかく、私は得た答えに満足しています。
泰-宋新
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.