※本記事にはサンプルコードはありません
前回の（企画編）に続き、今回は準備編となります。
作るゲームの方向性が決まったので、早速準備をします。
１、Unityの最新状態をチェックする
まずはゲーム作りの母艦となるUnityが最新版かどうかをチェックします。
最近のUnityはミドルアップデートでもおいしい機能を追加してくれることが多いので、できれば新しくアプリを作り始める際には最新の状態で始めた方が良いかと思います。
２、素材を集める
スクリプトを自分で書くのは当たり前ですが、ゲームの素材は一人の力ではどうにもならないので素材集めをしなければなりません。
僕は土台がサウンドクリエイターなので、音素材は基本的に自前でどうにかなりますが、グラフィック関係の素材はかき集める必要があります。
そんなときに便利なのがUnityの公式素材配布サイトUnityアセットストアです。
アセットストアには、Unityが公式に用意している素材はもちろん、世界中のクリエイターがUnityですぐ使える様々な素材を無料、または有料で配布してくれています。
もちろん、ここで入手した素材はUnityのみで使うことが原則ですが、利用範囲については素材配布者のポリシーによってUnity以外でも使える場合があります。
僕がアセットストアで配布しているGameMusicPackシリーズも、利用者からの申請があればUnity以外での使用をOKとしています。
今回はなるべく無料で済ませたかったので、最終的に下記の素材を揃えました。
【アセットストアで入手した素材】
・バスケットコート以外の背景3D素材
・3Dキャラクター用のモーションデータ
・フォントデータ
【アセットストア以外の場所から入手した素材】
・ユニティちゃんモデルデータとそれに関するもの一式（ユニティちゃん公式サイト）
・バスケットコートのモデルデータ一式（モデルデータを配布してる別サイト）
・その他スプライトやテクスチャ素材（無料素材配布サイト）
もちろん、試行錯誤する過程で他にもいろんな素材を使ってみたりもしました。
３、ゲームループの全体図をザックリ考える
企画編で決めたフリースローゲームのゲームループを考えます。
最初からあまりガチガチに決めると後々の調整で融通が利かなくなる可能性があるので、ザックリとした全体図を考えます。
前回の（企画編）に続き、今回は準備編となります。
作るゲームの方向性が決まったので、早速準備をします。
１、Unityの最新状態をチェックする
まずはゲーム作りの母艦となるUnityが最新版かどうかをチェックします。
最近のUnityはミドルアップデートでもおいしい機能を追加してくれることが多いので、できれば新しくアプリを作り始める際には最新の状態で始めた方が良いかと思います。
２、素材を集める
スクリプトを自分で書くのは当たり前ですが、ゲームの素材は一人の力ではどうにもならないので素材集めをしなければなりません。
僕は土台がサウンドクリエイターなので、音素材は基本的に自前でどうにかなりますが、グラフィック関係の素材はかき集める必要があります。
そんなときに便利なのがUnityの公式素材配布サイトUnityアセットストアです。
アセットストアには、Unityが公式に用意している素材はもちろん、世界中のクリエイターがUnityですぐ使える様々な素材を無料、または有料で配布してくれています。
もちろん、ここで入手した素材はUnityのみで使うことが原則ですが、利用範囲については素材配布者のポリシーによってUnity以外でも使える場合があります。
僕がアセットストアで配布しているGameMusicPackシリーズも、利用者からの申請があればUnity以外での使用をOKとしています。
今回はなるべく無料で済ませたかったので、最終的に下記の素材を揃えました。
【アセットストアで入手した素材】
・バスケットコート以外の背景3D素材
・3Dキャラクター用のモーションデータ
・フォントデータ
【アセットストア以外の場所から入手した素材】
・ユニティちゃんモデルデータとそれに関するもの一式（ユニティちゃん公式サイト）
・バスケットコートのモデルデータ一式（モデルデータを配布してる別サイト）
・その他スプライトやテクスチャ素材（無料素材配布サイト）
もちろん、試行錯誤する過程で他にもいろんな素材を使ってみたりもしました。
３、ゲームループの全体図をザックリ考える
企画編で決めたフリースローゲームのゲームループを考えます。
最初からあまりガチガチに決めると後々の調整で融通が利かなくなる可能性があるので、ザックリとした全体図を考えます。
最近のゲーム会社にありがちなんですけど、いわゆるゲームの遷移図を最初から作り込むことは、僕はあまり良いことではないと思っています。
今回のような小規模ゲームならまだしも、それなりに大きくて複雑なゲームになってくると遷移図を書くのは相当な時間と労力がいります。
しかも、大抵はプログラムやサーバーの知識がないプランナーが書いています。
当然、その遷移図は不備だらけなのは確実です。
なので進め方としては、最初はとりあえず全体のザックリとした遷移図をコンパクトに作り、次にプログラマー等の組み立てに関わりそうな人を交えて細かいフェーズ毎に必要な情報を足して、大きな遷移図を完成させることが大事なんじゃないかと思います。
そうすることで、開発途中に軌道修正があったとしても、プログラマーも柔軟に対応ができるようになります。
一番最悪なのは、開発者の知らないところで企画や遷移が勝手に変わり、既成事実みたいな感じでメインプログラマーに要望が突きつけられることです。
そんなの聞いてねーよ！
っていう状況はホントに作らないほうがいいですし、そんな状況を作ってる原因が自分にあることをわかっていないプロデューサーやディレクターはマジで反省したほうが良いです。
（おっと、つい日常の怒りが......）
次回は「実装編」です
（何回かに分けるかも）