JP5393941B2 - ゲーム開発装置及びゲーム開発方法 - Google Patents

Description

本発明は、情報処理装置に組み込んで実行するゲームプログラムが容易に作成できるゲーム開発装置及びゲーム開発方法に関するものである。

従来のゲームプログラムの作成方法は、まずゲームシナリオを作成し、その後シナリオに従ってゲーム画面を一から作成し、作成したゲーム画面をゲームの進行に応じて結合させていた。
中には、特許文献１のように、バリエーションに富んだゲーム用プログラムを作成するために、互いに異なる複数の部分シナリオを用意しておき、これら部分シナリオから、疑似乱数によって略ランダムに選択された部分シナリオを、順次、第１段目から第４段目まで、繋ぎあわせることにより、単一のストーリイを構成するゲーム用プログラムの作成方法があった。

このようにして作成されたプログラムは、部分シナリオを多種多様に組み合わせることができ、バラエティに富んだゲームを楽しむことができるが、ゲームの作成方法としては従来と同様に全てを一から作り上げ、実際に実行する段階でゲームの実行手順を工夫したに過ぎないものであった。
ゲームプログラムを実際に開発する際には、各種リソースを素材とし、このリソースを結合させてプログラムを完成させている。リソースには、３Ｄオブジェクト、２Ｄイメージ、サウンド、スクリプト、シナリオ、文字列、挙動や配置等の数値データがあり、その種類や性質は多岐にわたる。また、リソースを生成する環境やツールもそれぞれ異なっている。

リソースは、ゲーム本編から使用できるように適切に配置される必要があり、リソース管理作業により個々のリソース毎に異なる管理作業を行っていた。
特開２００１−９６０６８

しかしながら、従来は、管理作業において、リソースごとに独自のコンバータや結合ツールを準備する必要があった。これは、従来のリソース管理に使用していたツール群が、ジャンルやプラットホームに依存する度合いが強いためであり、ゲーム機の仕様に密接に関わり、特有の実装が必要であり、ソフト作成ごとに（プロジェクトごとに）新たに準備しなければならなかった。即ち、ソフトの作成ごとに作り直している状態であり、ゲームソフトが完成すると管理ツールは破棄されており、再利用されていなかった。

更に、リソースと管理ツールが密接に一体化しているため、プログラムの一部変更や追加を行おうとした場合、例えばデザイナが３Ｄモデルを変更しようとする場合など、エキスポータで出力し、コンバータで加工し、プログラマに組み込んでもらい、実機で確認するという手順が必要であり、非常に面倒なものであった。

更に、ゲームプログラムの完成開発期間として許される期間は益々短期間化しており、効率的なプログラム開発が求められている。

本発明は上述した課題に鑑みてなされたもので、データとそのフォーマットを共に生成管理して、リソース管理の環境を再利用可能にすることにより、プログラムの作成途中での作成結果の確認を可能とすると共に、結果を見ながらの加工、開発サイクルの効率化、効果的な並行開発、技術の蓄積と再利用の推進、学習コストの低減、開発機器コストの低減、環境変化に対する柔軟さ、人員配置の最適化、移植性の向上、保守運用の容易さ等を実現することを目標とする。

係る目標を達成する一手段として例えば以下の構成を備える。
即ち、表示手段を備え、前記表示手段に表示画面を確認してゲームプログラムを開発するゲーム開発装置であって、ゲームを開発する際の各種の素材（リソース）を記憶するリソース記憶手段と、前記リソース記憶手段に記憶されている前記素材を利用してゲームを構成するための前記素材の取り込み方法を定義する素材定義手段と、前記素材定義手段により定義された定義情報に従って前記素材を取り込み管理する管理手段と、前記管理手段で管理される前記素材の加工方法を指示する加工指示手段と、前記加工指示手段で指示された加工方法に応じて前記素材の加工状態を前記表示手段に表示する表示制御手段とを備え、前記表示手段に素材加工状況を表示して前記素材の取り込み方法及び加工方法の指示を可能とすると共に前記管理手段が管理する前記素材の前記定義情報及び前記加工方法と素材データをゲームを実行するゲーム機の仕様に合わせて提供可能とすることを特徴とするゲーム開発装置とする。

そして例えば、更に、前記管理手段が管理する取り込まれた前記素材情報をゲームデータとして記憶するゲームデータ記憶手段と、前記管理手段よりの前記ゲームデータ記憶手段に記憶されている前記ゲームデータの加工方法及び定義を記憶するインターフェイス情報記憶手段とを備えることを特徴とする。

また例えば、前記素材は、ゲームを実行するゲーム機仕様に拘わらず共通の素材であり、前記取り込み方法及に加工方法も前記管理手段の管理仕様に応じたものであることを特徴とする。

または、ゲーム機で実行可能なゲームプログラムを開発するゲーム開発装置であって、ゲーム開発状況を表示可能な表示手段と、ゲーム実行手順を管理する管理手段と、ゲームシーンを構成する各種素材（リソース）を、前記管理手段に適応した取り込み方法で取り込むための取り込み定義情報を提供する取り込み定義手段と、前記取り込み定義手段の提供する取り込み定義情報に従って前記管理手段に取り込まれた素材情報の加工方法を定義する加工定義情報を提供する加工定義手段と、前記加工定義手段の提供する加工方法で加工された前記素材状態を表示するゲームシーン表示手段とを備え、前記加工定義手段による加工方法の定義を、前記ゲームシーン表示手段による表示結果を確認して提供可能であることを特徴とする。

そして例えば、前記管理手段は、前記素材を取り込みあるいは加工したゲームシーン毎の加工素材情報をゲームデータとして定義情報と共に出力するゲームデータ出力手段と、前記ゲームデータ出力手段で出力されるゲームデータをゲームを実行するゲーム機の仕様に合わせて管理するための管理方法を提供する管理方法提供手段とを含むことを特徴とする。

更にまた、ゲームを開発する際の各種の素材（リソース）を管理して前記素材の取り込み及び加工結果を表示可能なゲーム開発装置におけるゲーム開発方法であって、ゲームを開発する際の各種の素材（リソース）の取り込み方法を定義し、前記定義された定義情報に従って前記素材を取り込み管理すると共に、前記管理される前記素材の加工方法が指示されると当該指示に応じて前記素材の加工を行い、加工結果を表示し、前記表示される素材加工状況を確認して更に必要な前記素材の取り込み方法及び加工方法の指示を可能として前記管理する前記素材の前記定義情報及び前記加工方法と素材データをゲームを実行するゲーム機の仕様に合わせて提供可能とすることを特徴とするゲーム開発方法とする。

そして例えば、更に、前記取り込まれた前記素材情報をゲームデータとして管理すると共に、管理している前記ゲームデータを指示された加工方法及びデータ管理方法に従って更新し、ゲームを実行するゲーム機の仕様に合わせて提供可能とすることを特徴とする。

また例えば、前記素材は、ゲームを実行するゲーム機仕様に拘わらず共通の素材であり、前記取り込み方法及に加工方法も前記管理手段の管理仕様に応じたものであることを特徴とする。

または、ゲーム開発状況を表示可能な表示手段とゲーム実行手順を管理する管理手段とを備え、ゲーム機で実行可能なゲームプログラムを開発するゲーム開発装置におけるゲーム開発方法であって、ゲームシーンを構成する各種素材（リソース）を、前記管理手段に適応した取り込み方法で取り込むための取り込み定義情報を受け取る定義情報受け取りステップと、前記定義情報受け取りステップの提供する取り込み定義情報に従って前記管理手段に取り込まれた素材情報の加工方法を定義する加工定義情報を提供する加工定義ステップとを有し、前記加工定義ステップの提供する加工方法で加工された前記素材状態を前記表示手段に表示させ、前記加工定義ステップによる加工方法の定義を、前記ゲームシーン表示手段による表示結果を確認して提供可能であることを特徴とするゲーム開発方法とする。

そして例えば、前記管理手段は、前記素材を取り込みあるいは加工したゲームシーン毎の加工素材情報をゲームデータとして定義情報と共に出力すると共に、前記出力されるゲームデータをゲームを実行するゲーム機の仕様に合わせて管理するための管理方法を提供することを特徴とする。

本発明によれば、開発したゲームプログラムを実行するゲーム機の仕様にとらわれない、ゲームリソース（ゲーム素材）管理を行うことができ、既存のゲームプログラムの開発経験を有効に後のゲーム開発に反映させることが出来る。

また、開発途中であっても開発中のゲームのゲーム機におけるゲームシーンの表示状態などを目視確認することができ、不具合の解消やゲーム品質の向上なども開発時に確実に行うことができる。このように、ゲーム開発の習熟度を容易に向上させることができると共に、開発されたゲームの内容を容易に次のゲーム開発に反映させることができる。

以下、図面を参照して本発明に係る一実施の形態例を詳細に説明する。
〔第１の実施の形態例〕

以下、図１を参照して本発明に係る一発明の実施の形態例を説明する。図１は本発明に係る一発明の実施の形態例のゲームプログラム作成管理システムの構成を示すブロック図である。

図１において、１００は本発明の実施の形態例のゲームプログラム作成管理を行う情報処理装置、４００は処理結果やゲーム実行状態などを表示する表示部、５００は各種操作指示などを入力する操作部である。

操作部５００は、情報処理装置１００を操作するキーボード等を備えると共に、必要に応じて、ゲームを実行するゲーム実行用の操作キーを備えている。

情報処理装置１００は、ブートストラッププログラムや各種情報処理装置の動作に必要なパラメータなどを記憶するＲＯＭ１２０、一般的な処理情報や実行プログラム等を記憶可能なＲＡＭ１３０を備える。ＲＡＭ１３０は、ＩＣメモリに限られるものではなく、その他の磁気ディスクメモリ装置、磁気テープ装置等、種々のメモリで構成することができる。

また情報処理装置１００は、開発中のゲームプログラムを格納するゲームプログラム格納部１４０、ゲームプログラム格納部１４０に格納されているゲームプログラムをゲーム実機で実行させた場合と同様に実行させるゲームプログラム実行部１５０、各種情報処理を行うと共に情報処理装置全体の制御を司る制御部２００を備えている。

なお、ゲームプログラム実行部１５０に替えて、ゲーム機の実機を接続してゲームプログラムをダウンロードさせて実行させる場合には、ゲーム機にゲームプログラムとゲームデータが送られることになる。

ゲームプログラム格納部１４０には、ゲーム機で実際に実行されるものと同様のゲームが実行できるプログラムを格納する。ゲームプログラム実行部１５０は、ゲームプログラム格納部１４０に格納されているゲームプログラムを、情報処理装置１００で実行するためのエミュレータ機能を備えている。

制御部２００は、例えばＬＳＩ等で構成されているＭＰＵ２１０により具体的に各種の情報処理を行っている。制御部２００を利用してゲームプログラムを開発する際には、ゲームの進行を制御するプログラムが必要であるが、ゲームの場面場面では種々のイベントが発生し、周囲景色や背景なども変化させる必要がある。

このような場合に、各場面毎に一から全てを開発することは効率が悪いために予め用意した各種リソースを組み合わせたり適切に選択したりして場面設定・制御を行いゲームを組み立てることにより、容易に変化を付けることが出来る。

このため、ゲームのための素材として各種リソースを必要とする。本実施の形態例のリソースには、３Ｄオブジェクト、２Ｄイメージ、サウンド、スクリプト、シナリオ、文字列、挙動や配置の数値データ等の、ゲームに使用する材料すべてが含まれる。

本実施の形態例では、この各種リソースをゲームプログラムに依存しない汎用のものとして取り扱うことが出来るため、以前に開発したゲームプログラムのリソースをそのまま、あるいは一部加工して利用可能としている。

即ち、各種のリソースを管理するのに、従来の様なジャンルやプラットホームに依存させることなく、データとそのフォーマットを共に生成管理するゲームデータ管理部２２０を備えている。

このゲームデータ管理部２２０が管理するゲーム素材としてのリソースには、例えば、シナリオ情報２５０、スクリプト情報２６０、３Ｄモデル（３Ｄオブジェクト）情報２７０、サウンド（音響）情報２８０、パラメータ情報２９０等があり、そのほか、ゲームの必要に応じて他に２Ｄイメージ情報、文字列情報、挙動や配置などの数値情報などがある。

本実施の形態例では、ゲームデータ管理部２２０がこれらの各リソース情報を管理し、ゲーム本編から使用できるように適切に配置するべく、データとそのフォーマットを共に生成管理し、リソース利用の汎用性を担保している。

この結果、ゲーム開発に与える副次的な効果として、従来はゲームプログラムが完全に完成し、ゲーム実機に読み込ませて実行させなければその結果を確認できなかったものが、開発途中で適宜結果を確認（結果を目視確認）することが可能となる。また、加工、開発サイクルの効率化、効果的な複数プログラム、複数イベントの並行開発が実現する。

しかも、容易に技術の蓄積と再利用の推進、学習コストの低減、開発機器コストの低減、環境変化に対する柔軟さ、人員配置の最適化、移植性の向上、保守運用の容易さ、等特有の優れた作用効果を奏することが可能となった。

次にこのゲームデータ管理部２２０の機能を図２も参照して説明する。本実施の形態例のゲームデータ管理部２２０の主要部はゲーム素材（リソース）をビルトインする（組み込む）ゲームビルダー（ＧＢ）２２５であり、例えば搭載するコンピュータのＯＳがマイクロソフト社のウインドウズＯＳである場合には、ウインドウズＳＤＫ（登録商標）により作成されたプログラムで実現され、３Ｄ情報（３Ｄオブジェクト）の配置、そのパラメータの指定によって、位置情報や空間情報をリソースとして指定する。ライブラリ／ツールとして描画エンジン、コリジョン（あたり判定）ネットワーク、サウンド等のライブラリの利用を可能としている。

ゲームビルダー（ＧＢ）２２５は、上述したようにコンピュータ上で動作するソフトウェアであり、各リソースの管理ツールとして作用する。そして、例えばリソースを組み込んだゲームデータと同時にヘッダーファイルとソースファイルを出力する。ゲームプログラム実行部１５０は、これらを組み込むことで、ゲームデータを適切な形式で管理し、各ゲーム機で実行可能なプログラムの形式に変換して実行できるようになる。

ＧＢプラグイン２２１は、リソースをＧＢ２２５にインポートする（取り込む）為に必要な追加パーツであり、ＧＢ２２５と協調動作してリソースをＧＢ２２５に取り込む場合の橋渡しをすると共に、マップエディタ（レベルエディタ）機能とイベントエディタ機能を有している。

ゲームは、映画と同様に多くの画面を少しずつ変化させて構成されるものであり、この多くの画面の組み合わせで成り立っている。この画面画面の表現は、ゲームのプラットホーム（ゲーム機種別）に拘わらず共通である。

本実施の形態例ではこの点に着目し、ＧＢプラグイン２２１により各リソースを組み合わせて一つの画面を制作する。これをＧＢ２２５で取り込んで当該画面表現に必要な他のリソースを組み合わせて出力可能にしており、各プラットホーム仕様に拘わらず共通にリソースを結合・管理する機能を提供し、ゲームプログラムに影響されずに各ゲーム画面、イベントを開発可能とし、更に再利用可能とするもので、最終的に各プラットホーム（ゲーム機種）毎に個別仕様のゲームプログラムで制御する形態に変換することとしたのである。

この様に、各ゲームプログラムに変換した後であってもＧＢ２２５の管理下で各ゲームシーンが作成されており、他のプログラムの開発の際にそのまま再利用が可能となる。

それのみならず、プラットホーム（ゲーム機）が異なっても、ＧＢ２２５の上では差異がないため、他のゲーム機用に開発したプログラムのリソースであってもそのまま利用することが出来る。

そしてこれらのリソースを、ゲームプログラムが指定するプラットホーム（例えば、ＮＤＳ，ＰＳ２，ＡＭ等）、実行するゲームの種類（Game Ｇｅｎｒｅ）（例えば、ＲＰＧ，ＳＬＧ，ＡＣＴ，ＡＤＶ，ＳＴＧ等）により、それぞれ固有のリソース管理機能、プラグイン機能を備えさせる。

ＧＢユーザインタフェース２２６はゲーム管理部２２０の機能の一つとして存在し、取り込んだリソース群に対し、加工を加えるグラフィカルユーザーインターフェイス（GUI）であり、３Ｄ用、２Ｄ用等が存在する。

ゲームデータ２３０は、ＧＢ２２５から出力され、ゲーム本体で利用する為のデータである。本実施の形態例では、ＧＢユーザインタフェース２２６を使用して加工する対象のデータと、ゲーム本体で利用するデータは、全く同じものである。

ＧＢ２２５からは、ゲームデータ２３０とは別に、ゲームデータと共にＧＢインタフェースデータが出力される。このＧＢインタフェースデータは、何がどのように入っているのか、どういったものなのかを定義する情報（定義情報ファイル）であり、ゲーム本体（ゲームプログラム実行部１５０）に組み込むことで、ゲームデータに対する適切な管理操作手段を得ることができ、定義ファイルと同時に出力されたデータを適切な形式で管理できるようになる。

定義ファイルはXML等の記述言語もしくは、独自の形式でもたらされる単一ファイルで構成することが出来る。再コンパイルが必要ないのが利点であるが、解析ロジックをゲーム実行側に多めに持つ必要がある。

ＧＢ２２５によるゲームプログラムの作成例を図３のフローチャートを参照して説明する。

まずステップＳ１に示すように、ゲーム作成に伴って必要となる各種のリソースを準備する。なお、このリソースは、例えば２Ｄデータであればキャラクタの形態や道具類の形態、建物や植物の形態を形成するセル（これらの各パーツ）である。

そして、続くステップＳ３において準備されたリソースに対して適した取り込み手段をＧＢプラグイン２２１として用意する。

このＧＢプラグイン２２１は、例えば、２Ｄソースの取り込みの場合には、画面を形成する複数のチップ（セル）を予め用意しておいてこのチップを組み合わせて一つの画面を制作する場合、一つの画面を描画して形成し、その後この形成した波面を複数のチップ（セル）に分割して登録する等の制御を行う。

このようにしてＧＢプラグイン２２１でのリソースを取り込む処理途中の表示画面の例を図４に示す。図４はリソースが２Ｄセルで、この２Ｄセルを取り込みゲーム画面（背景画面）を制作する際の表示部の表示例を示している。

図の左側のリソースウインドウに画面を構成するためのセルが示されており、このセルを選択して右側のメインウインドウに表示されているゲーム画面を制作する。なお、右下にはルーペウインドウ（一部拡大画面）が、その上には参考画面が表示されている。

以下に具体的なプラグインの例を以下に示す。但し、以下の例はあくまで一例であり、他の種々のものに適用できることは明かである。

Ａ、衝突判定作成プラグイン
単一のプログラムとして作成され、プラグインとしてＧＢから利用される。背景など、３Ｄのオブジェクトをファイルとして読み込み、その形状情報から、再利用可能な衝突判定データを作成する。

作成された衝突判定データは、コリジョンプラグインで操作できる形式となる。作成された衝突判定データは、衝突判定ライブラリを通じて使用することが可能となる。なお、衝突判定ライブラリは、別途提供されている。

Ｂ、カメラパス生成プラグイン
空間内で、時間によってカメラを制御したい場合、位置や向きに加え、注視点や画角の制御、注視に関する制限を設定する必要がある。これらの設定を行う機能もプラグインとして実装される。設定されたデータは、リソースとして、ＧＢ上で他のリソースと同様に管理される。

続いてステップＳ５において、ステップＳ３においてＧＢプラグイン２２１を用意したリソースをＧＢ２２５に取り込む。そしてステップＳ７において、必要なリソースの全てがＧＢ２２５に取り込めたかを調べる。未だ取り込んでいないリソースがある場合にはステップＳ１に戻り次のリソースの取り込みを行う。

このようにして制作したゲーム画面にキャラクタや移動体を配置し、移動制御する場合のコリジョン（当たり判定）の判定のＧＢプラグイン２２１の例を図５に示す。

図５はコリジョンプラグインの具体例を示する画面であり、ゲーム画面におけるコリジョンパラメータの設定例が、中央背面のコリジョンパラメータ設定ウインドウにマクロ定義フラグを属性フラグとして指定している例を示している。なお、画面中央に移動体キャラクタが示されている。

指定は、例えばゲーム画面の頂点ポイント、低点ポイントを順次指定して座標をそれぞれ定義していくことになる。そして、ゲーム実行時には、例えば、指定されたポイントの座標を擬似的に連結してその間の座標を算出する。

ＧＢインタフェースの上記しているリソース毎の具体的なデータ構成例を表１に示す。

表１に示すデータ構造で（フォーマットで）ＧＢベースで操作可能としている。

一方、必要なリソースの取り込みが終了した場合にはステップＳ７よりステップＳ１０に進み、取り込んだリソースの利用方法の定義（管理定義の指定）を行う。これにより、表示部４００の表示画面を見ながら加工を行うことが可能となる。

このリソースの利用方法の定義の例を表２、表３に示す。表２にマップクラスの定義の例を、表３に配置物クラスの定義例を示す。

続くステップＳ１２で開発者はＧＢインタフェース２２６を介してリソースの加工方法を提供して表示部４００の表示画面を見ながら加工を行う。

ＧＢを利用してゲーム実機で完成したゲームを実行している場合と全く同じように表示画面に表示し、ゲーム進行が出来るため、更に高品質のゲーム画面にすべく細かな改良を行おうとした場合にも容易にこれを、複数の開発者が並行して行うことが出来る。ゲーム画面を編集中の画面表示例を図６に示す。図６はＧＢを利用してゲーム開発終盤の画面のマップ編集を行っているときの表示画面例を示す図である。

図６の左下がゲーム画面の表示例であり、画面に表示する画面マップ選択ウインドウを左上に、画面マップ選択ウインドウで選択されたマップのユーザ定義指定ウインドウを右上に、画面マップ選択ウインドウで選択された編集中のマップのマップクラスウインドウを右中段に、実際にマップの編集（マップ定義の編集）を行う編集ウインドウを右下に中で編集例を示している。

そして次のステップＳ１４で全てのリソースに対する加工が終了したか否かを調べる。加工すべきリソースが残っている場合にはステップＳ１０に戻り、次のリソースの利用方法の定義を行う。なお、このリソースの加工は、それぞれの開発者が並行して行うことが可能である。

ステップＳ１４で全てのリソースの加工が終了した場合にはステップＳ１４よりステップＳ１６に進み、加工したリソース群をゲームデータ２３０として出力する。また、同時にステップＳ１８で利用方法を定義ファイルとして出力する。

ゲーム機側（ゲームプログラム側）では、ステップＳ２０で定義ファイルを受け取る。これにより、ゲームデータの操作手段を獲得することになる。このため、続くステップＳ２２でゲームをリソース毎に実行させ、ゲーム実行状態を目視確認できる。

そしてステップＳ２２でのゲーム実行確認を行いながらステップＳ２４でゲームの完成状態を確認する。その結果、引き続きゲーム制作を続ける必要がある場合やリメイクを行う必要がある場合にはステップＳ１に戻り、再びゲーム制作を行う。

以上のＧＢシステムを使用することにより、例えば、あるタイトルのゲームを新しく開発する場合に、以前に良く似たジャンル（例えば３Ｄアクション）のゲームプログラムの開発経験のある場合には、この開発実績を有効利用することが可能でとなる。このために、以前のゲーム開発時のデータ定義を参考にして次にゲーム開発を行うことが出来る。

次に、以上に説明したＧＢを用いたプログラム開発環境での応用例を以下に示す。
（１）プロジェクト開始時の立ち上がりの早さ
例えば、当たり判定や敵配置等、そのまま使えるツールやプログラム群を検索し、同じようなものがあればそれを利用するようにする。

グラフィックソフトである場合には、マヤ（Maya）にするかソフトイメージ（SoftImage）にするか、ゲームの登場人員の決まっていない開発開始時点（未決定開発中時点）では決められないし、どちらがタイトルにふさわしいかの調査も必要である。

しかしながら、例えばグラフィックのリーダーについてはマヤ（Maya）を使用できるので、とりあえずマヤ（Maya）でいくことにする。その結果、マヤ用のＧＢプラグイン（すでに開発済みのもの）２２１を用いればよい。試しに仮制作したキャラクタは、ＧＢ２２５に取り込むことができる。

そして、プログラムを実行するゲーム機種別に応じて流用した定義にしたがって、ゲームデータと定義ファイルを出力してみる。プログラマは仮で昔作ったゲームプログラムに組み込んで試すこともできる。この場合には、ＧＢプラグインのリソースの定義などを変えるのみで、プログラム自体の変更は最小限でたり、ほとんど変更が必要ない場合も多い。

そして、マヤを用いて新しく作った３Ｄキャラクタが、ゲーム機（例えばPS2）実機上で動いている状態と同じ状態で表示出来ることが確認できた。

また、本実施の形態例のＧＢ２２５を利用して複数の開発者が並行してプログラムの開発を行う、並行開発も可能である。実際に開発した実例を以下に示す。
（２）ゲーム開発の終盤（並行開発の実例）
ゲーム開発の終盤では、細部の改良や不具合の修正を行う必要があるが、本実施の形態例ではこれをリソース毎に並行して行うことが出来る。

例えば、グラフィックデザイナーが、ゲーム画面を見ながらゲームのクオリティアップを行っている時に、並行してスクリプタが新しいステージを追加し、シナリオを作成したが、それぞれが全く問題なく開発できた。

更に、企画者は通しプレイをしながら、あらゆるバランス調整を行っている。また、サウンド担当者は効果音とＢＧＭを割り当て、聞きながら演出を工夫している。プログラマは新しい機能を追加し、そしてバグ取りに集中している。

本実施の形態例のＧＢでは、それぞれが、ゲームプログラムの異なる部分を開発・修正などしていることから、これらが全て並行して行われ、ボトルネックとなる人員が存在しない。よって、非常に効率の良いゲーム開発が可能となる。

（２）外国向けへの移植開発
開発したゲームの一部修正、例えばゲーム環境の変化（ローカライズ）を行うような場合においても、該当する部分のみを別途読み出して修正することが出来る。

即ち、ＧＢ環境下で作成された日本向けのゲームにおいては、例えばアメリカ合衆国では子供が実行できない場面（未成年者が行くことが出来ない酒場のシーンなど）などが多数含まれている場合が多い。このような場合には、北米版移植開発をする必要がある。このような場合であっても、ＧＢ２２５を利用すれば簡単に移植を行うことが出来る。

以下、移植開発作業を順に説明する。まず、ゲーム中の文字列表示を翻訳して移植する文字列翻訳作業を説明する。

本実施の形態例のＧＢ２２５は、リソース毎に特性、定義等を定めている。このため、文字列に関するリソースを変更すれば、ゲーム中の文字列表示のみが変更されることになる。

このため、まずはリソースのうち文字列に関するものを、全て翻訳し、加工する。単なる翻訳で済む場合（定義を変更する必要がない場合）には、プログラムを変更する必要はなく、そのままゲームプログラムを実行するのみで全ての部分で翻訳結果を目にすることができ、翻訳結果を目視確認できる。

定義の変更があればその定義にしたがった翻訳結果のはめ込み表示となる。例えば、従前にはなかった場面での文字列の表示などである。

この際において、ＧＢ２２５が直接加工するインターフェイスとして機能するので、外国語を理解できる担当者が、誤植の修正やニュアンスの加工作業を、ゲームを見ながら行うことが出来る。この際、プログラミングを行うような特別な技能は必要としない。この結果、特別のコンピュータに対する知識やプログラミング、システムプログラムなどの知識がなくとも、翻訳・移植作業が可能となり、真に外国語に有能な者による翻訳・移植作業が出来る。

また、レーティングの関係上、多少のシナリオ変更とモデルの変更が必要となった場合においても、本実施の形態例では、シナリオリソースと２Ｄ／３Ｄモデルリソースを別々に取り扱い、別々に修正することができる。

且つ、必要であれば定義そのものを変更することにより、あらゆるゲームシーンで、プログラムの加工を待たずして、リソース単位で独立に並行して、ゲームプログラムの実行時と同様の表示結果確認をしながら実機上と同様の、あるいは実機上での修正確認を取ることが出来る。

（３）人員配置の変更
あるプロジェクトが終了し、人員的に余裕が出来た様な場合、例えば、携帯電話端末向けのアドベンチャーゲームをＧＢ環境下で作成し、開発要員に余裕が出来たような場合に、他のプラットホーム（仕様の異なる他のゲーム機）上でレースゲームを作成しているプロジェクトが人員を必要としていても、従来であればプラットホームもジャンルも違う為、何の手助けも行えなかった。これは、環境習熟コストが高くつくというのが理由である。

しかしながら、どちらのプロジェクトもＧＢ環境下で開発を行っている場合には、人員は違和感無く他のプロジェクトの手伝いを行うことができる。

即ち、ＧＢ２２５を利用してゲーム開発を行うため、環境に対する習熟コストは必要が無く、新プロジェクトに特化した部分の習熟のみで合流が行える。また、見て加工することができるため、その習熟も比較的容易に行える。

本発明に係る一発明の実施の形態例のコンテンツ作成装置の構成を示すブロック図である。 図１に示すコンテンツ作成部の詳細構成を示すブロック図である。

本実施の形態例のコンテンツ作成処理を説明するためのフローチャートである。 本実施の形態例のＧＢプラグインを説明するための参考表示例を示す図である。

本実施の形態例のＧＢの利用例を説明するための参考表示例を示す図である。

本実施の形態例のＧＢを利用してゲーム開発終盤の画面のマップ編集を行っているときの表示画面例を示す図である。

符号の説明

１００ 情報処理装置
４００ 表示部
５００ 操作部
１２０ ＲＯＭ
１３０ ＲＡＭ
１４０ ゲームプログラム格納部
１５０ ゲームプログラム実行部
２００ 制御部
２１０ ＭＰＵ
２２０ ゲームデータ管理部
２２１ ＧＢプラグイン
２２５ ゲームビルダー（ＧＢ）
２２６ ＧＢユーザインタフェース
２３０ ゲームデータ
２５０ シナリオ情報
２６０ スクリプト情報
２７０ ３Ｄモデル（３Ｄオブジェクト）情報
２８０ サウンド（音響）情報
２９０ パラメータ情報
３１０、３３０ 商品掲載誌

Claims (8)

1. 表示手段を備え、前記表示手段の表示画面を確認してゲームプログラムを開発するゲーム開発装置であって、
   ゲームを開発する際の各種の素材（リソース）を記憶するリソース記憶手段と、
   前記リソース記憶手段に記憶されている前記素材を利用してゲームを構成するための前記素材の利用方法を定義する素材定義手段と、
   前記素材定義手段により定義された利用方法の定義情報に従って前記素材を取り込み管理する管理手段と、
   前記管理手段で管理される前記素材の加工を指示する加工指示手段と、
   前記加工指示手段で指示された前記素材の加工状態を前記表示手段に表示する表示制御手段とを備え、
   前記素材定義手段は、前記加工指示手段による加工の指示に応じて加工した素材の利用方法の定義情報を変更し、前記表示手段に素材加工状況を表示してゲームを実行するゲーム機で実行している場合と同じように表示可能とすることを特徴とするゲーム開発装置。
2. 更に、前記管理手段が管理する取り込まれた前記素材情報をゲームデータとして記憶するゲームデータ記憶手段と、前記管理手段よりの前記ゲームデータ記憶手段に記憶されている前記ゲームデータの利用方法の定義を記憶するインターフェイス情報記憶手段とを備えることを特徴とする請求項１記載のゲーム開発装置。
3. 前記素材は、ゲームを実行するゲーム機仕様に拘わらず共通の素材であり、シナリオ情報、スクリプト情報、３Ｄオブジェクト情報、音響情報、パラメータ情報、２Ｄイメージ情報、文字列情報、挙動や配置といった数値情報を含むことを特徴とする請求項１又は請求項２記載のゲーム開発装置。
4. ゲーム機で実行可能なゲームプログラムを開発するゲーム開発装置であって、
   ゲーム開発状況を表示可能な表示手段と、
   ゲーム実行手順を管理する管理手段と、
   ゲームシーンを構成する各種素材（リソース）を、前記管理手段に取り込んで利用するための前記素材の利用方法の定義情報を提供する取り込み定義手段と、
   前記取り込み定義手段の提供する前記素材の利用方法の定義情報に従って前記管理手段に取り込まれた素材情報の加工後に変更された利用方法の定義情報を提供する加工定義手段と、
   前記加工定義手段の提供する加工後に変更された利用方法の定義情報に基づき素材状態を表示するゲームシーン表示手段とを備え、
   前記加工定義手段による利用方法の定義に基づく、前記ゲームシーン表示手段による表示結果を確認してゲームを実行するゲーム機で実行している場合と同じように表示可能であることを特徴とするゲーム開発装置。
5. ゲーム開発状況を表示可能な表示手段とゲーム実行手順を管理する管理手段とを備え、ゲームを開発する際の各種の素材（リソース）を管理して前記素材の取り込み及び加工結果を表示し、ゲーム機で実行可能なゲームプログラムを開発するゲーム開発装置におけるゲーム開発方法であって、
   ゲームを開発する際の各種の素材（リソース）の利用方法を定義し、
   前記定義された利用方法の定義情報に従って前記素材を取り込み管理すると共に、
   前記管理される前記素材の加工が指示されると当該指示に応じて前記素材の加工を行い、加工結果を表示し、
   前記表示される素材加工状況を確認して更に必要な前記素材の利用方法及び加工の指示を可能として前記管理する前記素材の前記利用方法の定義情報と素材データをゲームを実行するゲーム機にゲームプログラムとともに提供可能とすることを特徴とするゲーム開発方法。
6. 前記素材は、ゲームを実行するゲーム機仕様に拘わらず共通の素材であり、シナリオ情報、スクリプト情報、３Ｄオブジェクト情報、音響情報、パラメータ情報、２Ｄイメージ情報、文字列情報、挙動や配置といった数値情報を含むことを特徴とする請求項５記載のゲーム開発方法。
7. ゲーム開発状況を表示可能な表示手段とゲーム実行手順を管理する管理手段とを備え、ゲーム機で実行可能なゲームプログラムを開発するゲーム開発装置におけるゲーム開発方法であって、
   ゲームシーンを構成する各種素材（リソース）を、前記管理手段に適応した利用方法で取り込むための利用方法の定義情報を受け取る定義情報受け取りステップと、
   前記定義情報受け取りステップの提供する利用方法の定義情報に従って前記管理手段に取り込まれた素材情報の加工を指示する加工定義情報を提供する加工定義ステップとを有し、
   前記加工定義ステップの提供する加工指示に対応して加工された素材状態を前記表示手段に表示させ、前記加工定義ステップによる加工指示に対応して利用方法の定義情報を更新して、前記ゲームシーン表示手段による表示結果を確認してゲームを実行するゲーム機で実行している場合と同じように表示可能であることを特徴とするゲーム開発方法。
8. 前記管理手段は、前記素材を取り込みあるいは加工したゲームシーン毎の加工素材情報をゲームデータとして利用方法の定義情報と共に出力すると共に、
   前記出力されるゲームデータをゲームを実行するゲーム機のゲームプログラムとともに管理することを特徴とする請求項７に記載のゲーム開発方法。

Images