表示調整
閉じる
挿絵表示切替ボタン
▼配色
▼行間
▼文字サイズ
▼メニューバー
×閉じる

ブックマークに追加しました

設定
設定を保存しました
エラーが発生しました
※文字以内
ブックマークを解除しました。

エラーが発生しました。

エラーの原因がわからない場合はヘルプセンターをご確認ください。

ブックマーク機能を使うにはログインしてください。

愚痴・お勉強の時間

今もか知らないけどゲーム制作の流れ

作者: まい

 お勉強の時間?です。


 今回は、買い切りゲームのお話。


 ネトゲとかオンライン主体のゲームには特に当てはまらない場所やむしろ完成後の管理運営が主体だと思うので、あまり当てにならないでしょうが、そこは目を瞑って下さいませ。


 なお開発者インタビューや生々しい自嘲ゲーム開発ゲームなんかによって得た知識です。

 開発現場に居た訳でも無いので、間違ってる事もあるかもしれません。


 そんな知ったかを自信満々に語る奴を、プロやもっと詳しく知る人が、知識不足っぷりをニヤニヤして眺めるのが楽しみ方が一番かもしれません。

 前書きを見てから本文を読んで下さい。




 はい、そんな訳で書いていきます。




 あなたはゲーム開発の流れをご存知でしょうか。


 ゲームのジャンルや要素を決めて、さあゲームを造ろう! でしょうか?


 実はゲーム会社運営ゲームではかなり簡略化されてますので、それらが全てと思ってしまうと恥をかきます。


 まあ個人制作ならほぼそんなゲーム達と変わりませんが、大きな会社となればそうは行きません。




0.提案会議


  開発チームで集まったり、複数チームをまたいで気の合う仲間内や各チームのトップなどで集まって、今度はあんなゲーム作りたいなぁと語り合い、次に作りたいゲームのイメージをなんとなく形にします。



1.提案書(仮称)


  こんなゲームが作りたい!


  そのイメージを文章やPVにまとめて、各開発チームの責任者と責任者達の上司が集まる会議へあげます。


  この時点ではゲームの内容は曖昧です。 あくまでもジャンルや方向性を決めるだけです。



2.企画書


  提案書が通った後に、ゲームの具体的な内容を書きます。


  ゲームのシナリオの大まかな流れ、ジャンルやゲームシステム、主要登場キャラクターとそれのセールスポイント。


  あと大雑把でもゲーム機やスマホアプリやPC等のどの機械で出したいかとか、開発期間は多分これくらいとか、開発にいくらかかりそうとか、開発に何人必要かとかを想定して書いておくのが大切だとか。


  そう言ったものをまとめて、企画会議に出して社内プレゼンします。


  どの人員が開発するか、つまり人事もここで決定する訳ですが、大体が企画書を書いたチームで開発します。



3.仕様書


  企画書を(もと)に、ゲーム内容を出来るだけ細かく書き、開発の工程を記すそうで。


  例えば、街のマップをイラストや図解にして、この家はどのマップのどこに繋がっているとかの詳細図も用意する。


  まさに仕様書。


  なお、更に技術的な資料も添えられる事があったり、別途資料として違う呼び方をされるものが必要な時があるらしい。



4.承認サイン


 社長なんかの、ゲーム開発にGOサインを出せる権利を持つ人の承認をもらいます。


 ここでGOサインを出す人が無茶振りしたりゴネる事があるらしいですが、その辺はパス。


 この時点でゲームの総合的な責任はサインした人にあるのですが、開発のチーフプロデューサーやチーフディレクターにも責任がよく飛びます。



5.開発開始(仮称)


  企画が通ってGOサインが出れば、開発が始まります。


  基本は仕様書にそった内容で開発します。


  この頃の開発者は新しいゲームを作るぞと、かなり意気込んで頑張る気MAXで進行します。



6.開発初期


  まず会議会議の連続です。


  シナリオや音楽やグラフィックやシステム、チーム内のあらゆる開発のリーダーと共通のイメージが持てるよう、とにかく話し合います。


  この時の下っ端は、のびのび開発します。 企画書と仕様書を見て、必要になりそうなデータをなんとなく自身の材料で作り始めます。


  システムに関してはそれぞれ……では済まないので、リーダーからの指示で開発するでしょうけど。


  それと暗雲が立ちこめます。


  ゲーム開発には金が不可欠であり、スポンサーが存在します。


  それだけでなく社内のエライ人も頭や口を出してくる事もあります。


  それらが早速◯◯してほしいと、気軽にゲームの内容に関わる注文を出してきます。


  なので早くも仕様書と違う工程が挟まり、仕様書を書き直す必要が出てきます。



7.α(アルファ)


  開発が進み、ゲーム開発の進捗(しんちょく)がα版と呼ばれる段階に入った頃です。


  このα版とは、各種開発が進み組み合わせてみて、なんとかゲームが動いているといった状態です。


  まだまだ完成に遠く、仮で入れたマップやキャラクターや音楽や(ユーザー)(インターフェース)動き(はしり)始めた状態です。


  途中でシステムエラーによって停止することはしょっちゅうですが、ゲーム全体の形が見えてきたような頃です。


  なお、この頃に新作ゲームとして開発中なのを発表する場合が多く、それを知った他企業や社内のおエライさんからアプローチが増え、さらに開発責任者が「思ってたのと違う」とか「もっと良くなるぞ!」とか言って仕様の追加や変更が相次ぎ作業が増える。


  この頃の下っ端開発者達のやる気の残りは30%以下じゃないですかね。



8.β(ベータ)


  α版よりだいぶ進み、完成が見えてくる頃です。


  まだまだエラーは出るが、だいたいは出来上がって、調整作業やゲームの安定化作業が増えてきます。


  この頃までに最初の頃の仕様書のまま開発を進められたゲームは、極めて(まれ)


  最初の企画書ではファンタジーARPGだったのが、この時点でSF世界ARPGにいつの間にかなっていたり、またはその逆になっていたりする事もあるとか。


  だが油断してはいけない。


  そこまで進んでいるからこそ、怖いものがある。


  それは開発責任者やその上司、最悪社長等の雲の上の人物から言われる「仕様変更」の言葉。


  具体的には「〇〇を△△にしたらもっと面白くなるんじゃないか?」「□□はだめだ、変えてくれ」「✕✕は他社がさっき発表したのと似てるから、パクりと思われたくないし変えよう」など。


  開発の苦労をまるで分かっていないような、外野からの声で居間まで重ねてきた苦労が蹴り壊されます。


  ここまで作っておいて変更があると、複雑になったシステムではバグが起きる可能性が極めて高くなる。


  なのでシステムの調整に時間をかなり取られてしまう。


  部分的なものならまだマシだ。


  最悪中の最悪は、最初から作り直しだ。


  面白いと思って作っていたのが、他社と作品がモロ被りしてしまっていた場合や、社会情勢や大事件の発生によってゲームの中身に似ている部分が有った際は回避のために作り直す時もあるらしい。

  そんな事が無くても、会社の経営陣の気まぐれで出した鶴の一声でアッサリ最初から……の事例も聞く。


  これらで進捗の大幅な後退が起きてしまった場合でも、開発期限や開発予算の変更が無く、(ひど)く追い込まれたゲーム開発風景があるらしい。


  そんな訳でこの頃の、下っ端の開発者のやる気は0……いや、マイナスになっている場合もあると聞きます。


  まあ絶望の話は終わりにして、この頃のデータを使い、体験版として配布される事もあるとか。


  ちなみに大昔のテレビゲームが大ブームだった頃はどんな出来のゲームでも販売すれ(だせ)ば売れる時代で、このβ版程度の完成度で発売に踏み切るゲーム会社があったとか。



9.デバッグ


  (バグ)を取り除くからデバッグ。


  ゲームで言うバグとは、ゲームを開発している側から見て、ゲーム自体が開発者が想定していない動きをする事です。


  なんかいつの間にか部屋の中にいて、ブンブン飛び回って作業の邪魔をする、とても厄介な存在な所がよく似てます。


  例えば、ゲーム上の壁にぶつかったらその壁より先へ行けない想定だったのに、壁にぶつからず壁を通り抜けて先へ進んでしまったりする事等。

  これは、壁抜けバグやすり抜けバグと呼ばれる一般的なバグのひとつ。


  あとはメッセージウインドウが消えなかったり、BGMが消えたり違うBGMが流れたり、キャラクターが謎の回転を始めたり。 様々なバグがある。


  その様々なバグを見つけて、バグが発生しないようプログラムを見直す作業。


  それをデバッグ作業と言います。


  昔はゲームの開発者達が自分達で行っていたそうですが、最近はゲームの大容量化に(ともな)う複雑化で、自分達でやっていたらいつまでも発売できなくなるほどなのでデバッグ作業を代行する会社へ依頼するのが主流だそうで。


  しかしバグはさっきも述べた通りある程度の分類がされていて、多くのバグを出してきた記録に照らし合わせると、バグが起きやすい場所を絞り込める。


  なので今のデバッグ作業は、その主要なバグが出やすい場所だけ確認して、あとは報告がありしだい修正します。


  で対応するのが常となった。


  幸い、昔みたいにオンライン非対応のゲーム機で、ゲームの進行に関わる致命的なバグがあったら、ゲームを取り扱う店で告知してもらって回収してもらって直して配り直してもらう。

  なんて大騒ぎしなくても、修正用データを各自でダウンロードしてもらうだけで良くなったため、開発の負担は減った。


  ……とは言えないのもまた本当。


  修正用データをダウンロードできるようにする前に、その修正したはずのデータで別のバグが出てないかの確認にデバッグする必要があるし、気軽にデータを修正できる環境になってしまったので、何度も何度も修正してデバッグを繰り返す。


  昔は発売したら大体終わり! だったのが、発売後にかかる責任や負担が増している。



10.マスターアップ


   完成の事です。


   あとはゲームディスクに焼いてもらうとか、ダウンロード可能な状態にするとかで終わりです。 が、それは開発の仕事ではないので、開発としてはお仕事終了です。


   なおとあるゲームではマスターアップしたのに、上役に見せたら修正を何度か指示されて、発売までにバージョンが上がっていた話があります。


   ですが今のゲームには関係ないですね。


   発売されてからが本番です。


   ゲームを買ってくれたユーザーからのバグ報告を受けて、怒涛(どとう)の修正作業が始まります。


   昔は発売されたら「お疲れ様! さあ打ち上げだ!」 なんて気楽なものでしたが、今のゲームは発売されてからも苦労が続きます。




 以上、雑なゲーム開発の流れです。


 実際の現場はもっと細かくアレコレやってると思いますが、業界ネタを扱うゲームなり外から見てるなり開発者のインタビューなり、情報を集めるとこんな感じだなと。


 オンライン主体のゲームだとリリース後に追加しまくる必要性から、開発の話や流れが更に変わるのでしょうが、買い切りのゲームだとこう。


 だと自分は思っとります。

評価をするにはログインしてください。
この作品をシェア
Twitter LINEで送る
ブックマークに追加
ブックマーク機能を使うにはログインしてください。
― 新着の感想 ―
[良い点] ゲーム作りとは開発と営業と金庫の殴り合い。なお開発の下っ端が一番ワリを食う模様。という悲哀、というか関係者のストレスの漏洩を感じる(涙) [気になる点] 口を出されず好きに作ったからと…
感想一覧
+注意+

特に記載なき場合、掲載されている作品はすべてフィクションであり実在の人物・団体等とは一切関係ありません。
特に記載なき場合、掲載されている作品の著作権は作者にあります(一部作品除く)。
作者以外の方による作品の引用を超える無断転載は禁止しており、行った場合、著作権法の違反となります。

この作品はリンクフリーです。ご自由にリンク(紹介)してください。
この作品はスマートフォン対応です。スマートフォンかパソコンかを自動で判別し、適切なページを表示します。

↑ページトップへ