概観編集

「ゲーム」とは編集

ゲームと一言でいっても、この教科書では、コンピュータを用いたゲームのプログラミングを扱います。

いわゆる「テレビゲーム」やコンピュータゲームについて述べます。

ここでは家庭用ゲーム機か、家庭用のコンピュータで扱える範囲の事柄をここでいうゲームとし、それらのゲームソフトをつくるためのプログラミングについて扱います。

解説にゲーム用語を使うので、もし用語の意味が分からなければ『ゲームプログラミング/コンピュータゲームの種類』などを参照してください。


そもそもプログラミングが必要か?編集

自分でゲームを作る際、必ずしも、C言語などプログラム言語で記述する必要はありません。

プログラミングをせずに、ほぼマウス操作と会話メッセージなどの文章のキーボード入力だけでゲーム開発をできるようにするソフトウェアが、有料または無料で発表されています。

たとえば、RPGを作りたいなら、日本で発表されているソフトでは、『w:RPGツクール』や『w:WOLF RPGエディター』などのように、RPG製作に特化された開発ソフトがあり、大幅に開発の手間を減らせます。なお、『RPGツクール』は有料製品です。『WOLF RPGエディター』は無料ソフトです。

アクションゲームを作りたいなら、『w: 2D格闘ツクール2nd.』や『w:アクションゲームツクール』などがあります。これらツクール製品は有料製品です。

また、ノベルゲームを作りたいなら、フリーソフトの『w:吉里吉里Z』などがあります。吉里吉里Zはソースコードが公開されており、オープンソースになっています。

なお、とりあえず「ゲーム開発ツール」と呼びましたが、じつは呼び方は特に決まってはいません。「ゲーム制作ツール」と呼んだりする場合もあります。ゲーム開発ツールのことを「ゲームエンジン」と言う場合もありますが、開発ツール以外のゲーム用ランタイムのことも「ゲームエンジン」といったりする場合があります。
本wikibooksでは、とりあえず、ツクールや吉里吉里シリーズやウディタ(WOLF RPGエディター)などの類のソフトの呼び方は、まとめて「ゲーム開発ツール」または「ゲーム開発ソフト」などと呼ぶことにします。


C言語などによるプログラムは、上記のゲーム開発ツールを使わない場合に、必要になる可能性があります。

既存のゲーム開発ツールの仕様に、あなたが不満を感じる場合に、「じゃあ自分でプログラムして作ろう」となり、プログラムが必要になるわけです。


なお、上記の開発ツールはほとんどがWindows用のソフトです。MacやLinuxでは動かない場合がほとんどです。なので、MacやLinuxでも動作するゲームを作りたい場合などに、プログラムが必要になる場合も多くあります。


既存のゲーム開発ソフトを使わずにプログラムを組んでゲームを自作する場合、必ずしも既存のゲーム開発ツールのような、ゲーム作品と開発ツールが分離された仕組みを再現する必要がありません。

というか、そもそも初心者には、ゲーム開発ツールを作るのは、ほぼ不可能です。なので初心者は開発ツールを作ることは考えずに、とにかくゲームを1本、とりあえず完成させるのが優先です。ゲーム1本を完成させたあとに、開発ツールとゲーム作品の分離などに取り掛かりましょう。


そもそもゲーム制作があなたの目的か?編集

このページを読んでる人は、おそらくゲームづくりをしようと考えているのでしょう。あるいは、このページを読んだせいでゲームづくりに関心を持ってしまうかもしれません。

ですが、ちょっとだけ待って考えてください。

あなたの作りたいモノは本当に ゲームそのもの でしょうか?

もしアナタが「自分はRPGがすき」だとしても、もしかしたら、よくRPGの題材になる西洋ファンタジーのストーリーの小説を作りたいだけかもしれません。

または、アナタはもしかしたらイラストを描きたいのかもしれません。音楽づくりをしたいのかもしれません。


なのに、もし、ゲームそのものを作るとなると、そのゲームの改良に、かなりの年月の自由時間が掛かります(たとえば、毎晩、帰宅してからゲーム開発に数時間ほど取り掛かるとか)。

そのため、小説の取材をしたりとか、イラスト創作の活動をしたりなどの時間が、かなり減ってしまいます。


また、ゲーム制作では、ゲーム性のためにリアリティを犠牲にしたりなど、ゲーム性のために小説やイラストには不向きな表現も必要になります。

たとえばRPGで、たった4人の主人公たちが、何百人もの敵キャラを倒したりとか、リアリティのやや乏しい表現なども、ゲームではよくあります。アクションゲームなどでも同様です。


あなたは、そこまでリアリティを犠牲にしてでもゲームを作りたいのですか?

あるいは、もしリアリティもあるシステムであってゲーム性も高く兼ね備えたゲームを作りたいとなると、本格シミュレーションなどのシステムのゲームになってしまうので、もはやRPGツクールやウディタなどの既存のゲーム開発ツールでは不十分で(または著しく非効率になるので)、Visula C++ などのプログラム言語を使って自分でソースコードを記述していく方式のゲーム制作になってしまうかもしれません。


他にもゲーム制作では、ゲームにあわないストーリーやイラスト構図などを削ることもあります。または、もしそれらのストーリーや構図を削らないなら、それでもゲームを面白くしたいなら、システムそのものを改修する手間が生じるかもしれません。もしそうすると、とたんにゲーム制作に要求されるスキルがあがります。


あるいは、けっして、そういう上述のような複雑・高度なジャンルでなくて、よくある展開でよくあるシステムでよくあるストーリーの既存ジャンルだとするならば、そもそもアナタが時間を注いでまでも作る必要があるのですか?

そういう「よくある展開」「よくあるシステム」のゲームは、すでに何作もネットで無料または低価格の作品が発表されています。


「単に作者オリジナルの初公開の曲があるだけのクソゲー」、「オリジナル初公開のイラストがあるだけのクソゲー」を制作したいですか?

曲や絵がよければ、面と向かって「クソゲー」とは言われないかもしれませんが、しかし内心、「システムやバランスがクソゲー」と思われています。曲や絵がいいのにプレイヤーから「このゲームの○○が面白い!」と具体的に言われないのは、つまり婉曲的に曲・絵いがいがクソゲー扱いされてるということです。反応が無いのは決して容認ではなく、「駄作なので『反応の価値なし』」と思われているのであり、いわゆる「サイレント・クレーム」(← ビジネス用語)です。

絵がよければゲーム公開サイトなどの紹介画面などで目立つので、とりあえず消費者・サイト訪問者に興味をもってダウンロードまたは購入までなら、多くの人に、してもらえます(広告写真と同様です。イラストには広告の役割もありますし、そもそもポスターの芸術史での歴史がそうです。いっぽう、音楽が良くても、なかなかダウンロードや購入に結びつかない)。

まだしも2001年ごろの日本での同人ゲーム黎明期やフリーゲーム黎明期などの時代なら、実験的な時代なので異分野交流も兼ねてイラストレーターや作曲家もゲーム制作するならともかく、2010年も過ぎた現代日本で、小説やイラストを書きたい人が、無理してゲームを作る必要はないのです。


ゲームは、けっしてver1.00を作って「終わり」ではなく、その後の、さまざまなアップデートが必要になる場合があります(バグ修正やバランス調整など)。バグ修正用に外注プログラマーや友人のプログラマーを雇えるならともかく、個人のゲーム製作では、そこまで雇うのは面倒です。たとえフリーゲームなどでバグ修正しない・バランス調整しないにしても、どの程度のバグをどういう理由で修正しないで放置するとか、そういうことをユーザーに説明するコミュニケーションの手間があるでしょう。


今のイラストレーター・作曲家では、たとえゲーム用に音楽やイラストを提供するなどの活動をしているクリエータでも、ゲームそのものは本人は作っていないクリエイターも今では多くいます。

また、過去すでに実験的にゲーム制作もしていたイラストレーターや作曲家などもいましたが、しかし今では多くのそれらのクリエイターは、すでにゲーム制作を卒業してゲーム制作中止してしまい、今では彼らの多くはイラスト創作や作曲の仕事に専念しています。

現在、フリーゲーム界隈や同人ゲーム界隈などで、ゲーム作家として残っている人の多くは、プログラマー系の人です(例外的にイラストレーター系のフリーゲーム作家の人も少数いるが、しかし絵描き系フリゲー作家は かなり少数です)。


また、現代ではイラスト投稿サイトや小説投稿サイトなど、専用のwebサイトがありますので、ゲーム以外の発表場所に困ることも少なく、それぞれのジャンルの発表はそちらを利用しましょう。

創作は、それぞれの分野は得意な人に任せたほうが無難です。モチはモチ屋です。


ゲーム制作に限らず、創作活動をする場合、けっして手段と目的とを、混同しないようにしましょう。


それでもゲームそのものを作りたいなら編集

開発ツールのライセンス条件編集

ゲーム開発ツールのなかには、そのツールで開発したゲームソフトに義務として「この開発ツールで開発したソフトウェアは、ソースコードを必ず公開しなければならない」などの条件をつけている場合があります。

もし作るゲームのソース開示をしたくない場合、けっして、開示義務のある開発ツールは使用しないようにしましょう。

ゲームにかぎらず、ソフト開発ツールとして使用した際などに、開発されたソース開示義務をさだめる開発ツールは多くありますので、ライセンスには気をつけましょう。


ライセンスによっては「有料ソフトの販売を禁止」とか「アダルト作品の開発は禁止」などの条件をつけている場合も、ありえます。

なので、あなたはゲーム開発前に、開発ツールがどのようなライセンス条件を指定しているか、かならず確認してから、ゲーム開発しましょう。


ソース開示すべきかどうか?

昨今では、リナックスなどのオープンソースの発展などの背景もあり、「自作ゲームのソースコードやソースファイルも開示しよう」と思うゲーム作者もいるかもしれません。

ですが、ちょっとだけ考え直してみてください。

大規模ITコミュニティや欧米大手IT企業などによる管理の充実しているリナックスなどと違い、小規模ゲーム界隈では、ユーザーの中には倫理観やリテラシーの低い人も含まれており、そのため、他人のゲームを利用して誹謗中傷などの表現を行う人もいるかもしれません。

他人のゲームのソースコードを使って、「なりすまし」のイタズラをする、迷惑な人もいるかもしれません。

このため、ゲーム作者である自分の知名度がある程度は高くなるまでは、ソース開示をしないほうが安全でしょう。

知名度の低い状態で「なりすまし」をされると、最悪の場合、作品の乗っ取りをされる可能性があります。


開発ツールの限界編集

下記の理由(機能制限および移植性の悪さ)の問題から、あまり大規模な作品は開発ツールでは作らないでおくのが安全です。

大規模な作品の場合、Visual C++ などでコードを書いて開発しましょう。

技術的な機能制限編集

ゲーム開発ツールを使う場合、そのツールにもよりますが、一般的に、技術的な理由で「○○ができない」という類の制限があります。

Visual Basic や visual C++ などには普通にある関数でも、開発ツールには無かったります。

また、もし、いったんはゲーム開発ツールを使って目的の機能を持ったシステムを作れても、さらなる機能をそのシステムに追加しようとするときに、けっこう作り直しの必要が多く生じたりします。(拡張性の悪さ)。追加したい その機能 に該当するデータベースなどのモジュールを呼び出しているソースファイルを、かなり作り直さなければならないような場合も、ありえます

もちろん、モジュール化されているので、作り直しの部分はそのモジュールだけで済みますが、しかし、そのモジュール部分は、かなり作り直す必要が生じたりします。


このような欠点のためゲーム開発ツールによるゲーム制作では、あまり大作を作ろうとしないほうが安全です。

開発ツールで作る作品は、比較的に小規模な作品に、とどめておきましょう。


そもそもWindowsの場合、本来なら Visual C++ などを使って、プログラム文法のいろいろな事に留意しながらプログラムを書くわけです。

開発ツールを使う場合、 Visual C++ のコードを書かずに、ほぼマウス操作だけでプログラムを作ろうとしているわけですから、何かしらの制限があります。


拡張性の悪さは、プログラム文法などの学習の負担を減らすためのトレード・オフのようなものだと思って、適材適所に用途に応じて開発ツールを選びましょう。


C言語などへの移植性の悪さ編集

また、もうひとつの問題点として、C言語への移植性の悪さがあります。

というか、そもそもソースコードが公開されていない開発ツールの場合、異なる開発環境にゲームのソースファイルを移植するのは、ほぼ絶望的です(仮に、開発ツールのランタイムを模倣できたとしても、著作権などの法的な懸念が生じかねません)。

ともかく、ゲーム開発ツールを使って作ったソースファイルを、もし「Visual C++ で書いたソースコードに移植しよう」とか思っても、まず無理です。


ゲームのプログラム言語編集

ゲームを書くために利用される言語は多岐にわたっています。歴史的にはC言語や、特に計算機のスピードが重要になる場面ではアセンブラを利用してプログラミングを行うことが普通に行われていました。現在では計算機がある程度速くなったことや、ゲームプログラムの開発を複数人で行うことでテクニカルなプログラミングが避けられるようになったことにより、ゲームプログラミングは普通のプログラミングに近いスキルとなっています。しかし、特にアクションゲームなどのリアルタイムでの画面書き換えが必要なゲームで、プログラムのスピードが重視されることは変わっていません。また、コンピュータの性能があがるにつれ、それらの性能を全て引き出すように表現手段が変化してきたため(3Dポリゴンなどを参照)、状況によっては複雑なプログラミングが必要になることもあります。

実際のゲームプログラミング編集

どのようなゲームを作るときでも、ゲームプログラミングでは、

  1. ゲームが提示する内容を表示することができる。
  2. プレイヤーからの入力を扱うことができる。

などの技術が必要になります。

プログラミング言語とプレイヤーからの入力については歴史的にもあまり変化がありません。プログラミング言語ではC言語C++などが用いられます。ただし、携帯電話向けのゲームではJavaが利用されましたが、これは携帯電話を提供する各社がJavaをアプリケーションの言語として選んだことによります(iアプリEZアプリS!アプリなどを参照)。

ただし、現在ではi-OSやAndroidなどのスマートフォンOSが普及したこともあり、Javaは使われない方針です。また、Javaのガベージコレクタの機能がゲームプログラミングには邪魔なので、Javaがゲームプログラマーに嫌われて避けられています。


パソコンゲームでは、プレイヤーからの入力にはコンピュータでは通常キーボードかマウスを利用します。他にジョイスティックゲームパッドが利用される場合もあります。家庭用ゲーム機ではコントローラが利用されることが多いのですが、ニンテンドーDSWii UなどではタッチパネルWiiでは複数の入力機器が提供されることが発表されています。幸いにもそれらをプログラムから扱う手法はそれほど入力機器ごとにそれほど大きく変化することはありません(プログラムから周辺機器を扱う方法については、デバイスドライバ高等学校情報Bなどを参照)。

残念なことに画面を表示することのうちで3Dの表現は割合難しく、ある程度の数学(少なくとも高校卒業レベルくらい)を理解する事が必要になります。2Dに関してはプログラムの面ではさほど難しい部分はありません。

プログラミング言語編集

ゲーム開発において、一般にゲームショップなどで流通している商業ゲーム作品において、現在よく利用されているプログラミング言語として、C言語C++Javaがあげられます。これらの言語の詳細については、対応する項を参照してください。ここでは主にC言語とC++を紹介します。

しかし、ネット上のフリーゲームでは、これ以外の言語が使われることも、よくあります。

例えば、JavaScriptが、webブラウザで動かせるゲームを作る際に、よく使われます。歴史的な経緯により、webブラウザ用のプロググラム言語では、画像の表示や音声や動画などの取り扱いが、なるべく初心者にも簡単なように設計されてきたので、ブラウザ上で動くゲームが発表されることも、しばしば、あります。なお、このようなwebブラウザ上で動くゲームのことを一般に「ブラウザゲーム」などと言います。


さて、ゲームプログラミングに限らず、プログラミングを行うには、プログラミング言語を習得する事が必要になります。情報科学や計算機科学などにプログラミングの理論もありますが、しかし、さいわいにも計算機科学などの専門知識について詳しく知らなくとも、プログラミングを行う事はある程度可能です。


入力編集

OSの種類によって、キーボード入力やマウス入力の受け付けのさいのプログラムの書き方は違う。

Windows API での具体的な手順は『ゲームプログラミング/入力』で説明する。


2Dの画面出力編集

画面出力の場合にも入力機器の場合と同じで、これらを操作する方法はOSごとに異なっています。先ほどあげたGTK+, Qt, SDLなどのライブラリはクロスプラットフォームの画面出力を提供しているため、これらを利用することで全てのプラットフォームで動くプログラムを作ることができます。

ブロックくずし
ゲームプログラミング/ブロック崩し』で説明。


サブページへのリンク集編集

ジャンル別のプログラミング手法編集

3Dグラフィック編集

RPG編集

非プログラミングのゲーム製作の関連作業編集

バランス調整編集

ゲームプログラミング/バランス調整』で説明する。

厳密にはプログラミングの話題ではないが、しかしゲーム製作で必要な知識なので、サブページで説明する。

ゲーム用の書類の書き方編集

説明書や仕様書(しようしょ)などの書き方については、『ゲームプログラミング/書類』で解説する。


未分類編集

Visual C++ でのプログラム文による文字画像の出力編集

Visual Studio付属のフォームデザイナ(VSの用意するGUI自動作成ソフト)によるGUIオブジェクト作成では、RPG用には使いづらい。

では、どうすれば、Visual C++で、なるべくフォームデザイナを使わずに、文字や映像を出力できるようになるのか?

方法は、なんとおりかある。

おおまかに、フォームデザイナをそもそも1つも使わない方式と、もうひとつは1つしかフォームデザイナのパネルを使わない方法、などがある。

  • Windows API で入力していく方法。(wikibooksに『Windows API』の入門書があります。 )これはフォームデザイナを使わない。
  • DirectXで入力していく方法。 WindowsAPIプログラミングが元になっているので、これもフォームデザイナを使わない
  • 1つだけフォームデザイナで「パネル」という画像表示機能のコンポーネントを用意して、そのパネルで表示する画像をゲーム内のストーリーなどに応じて切り替えるだけで、すべての画像表示を行う。


なお、フリーソフトでゲーム用ライブラリの『HSP』はWindows API を呼び出す仕組みになっています(なので、HSP関連のサイトを見ると、Win APIプログラミングの解説をしている場合もある)。

また、フリーソフトでゲーム用ライブラリの『DXライブラリ』は Direct X を呼び出す仕組みになっています。なお、ゲーム開発ツールのひとつであるウディタのソースコードは、DXライブラリとVisual C++ を使って書かれていると、作者が公表しています(ただしソースコードは非公開。ウディタは非オープンソース)。誤解の無いようにいうが、ウディタを用いたRPGのプログラミングにはDXライブラリによるコーディングは不要である(そもそもウディタにはコード入力の機は無く、マウス操作や、キーボード操作はキャラ名称や会話文などのテキスト文字や数値の入力のみ)。


乱数編集

ゲームを作ってると、サイコロのような乱数の機能も必要になる場合が多い。

しかし、無印C言語で用意されている、標準的な乱数関数 rand() が機能不足であり、いろいろと不便である。

rand 関数では、ランダムに 「34521」(例) とかの数が生成されるだけなので、「1以上から6以下の整数値が欲しい」などの指定すら、直接には出来ない。

rand関数で生成された乱数を、割り算(÷6)で割って、あまりは0以上5以下なので、サイコロにするには、余りに +1 すれば、rand関数でサイコロを作れる。

このように、rand関数の使いかたは間接的であり、いまいち使いづらい。

そこでIT業界では対策として、より直接的に乱数の範囲指定のできる等の新機能もある、さまざまな乱数関数が、のちの各種のプログラム言語で追加された。Visual C++ などに採用されている Random関数グループには、名前がrand関数と似ているが、しかし、この新しいRandom関数グループの中には「1以上から7未満の整数値がランダムに欲しい」のような指定が直接的に出来る「Next」命令がある。

Random関数のこの直接指定の機能により、バグの混入率が減る。


しかし、Visual C++ や Visual C# では、これらの命令を使うための予備的な宣言が必要であり、そっちの宣言の手間で、やや不便である。


でも、現実的に、Windows向けのゲームプログラムでは Visual C++ や Visual C# などを利用せざるを得ない。

Visual C++ にある高機能な乱数命令グループ Random や、そのRandomグループに属するNext命令などを使いたい場合、サイコロのプログラムをつくるだけですら、下記のような数行のコードが必要になる。

	Random^ saikoro1; // Random^ でRandom関数の使用を宣言しなければならない。
	saikoro1 = gcnew Random(); // ここでの gcnew は命令をつくるための演算子
	int detame; // 出た目
	detame = saikoro1->Next(1, 7); // Next 命令で「〇〇以上△△未満」の乱数を指定できる。「->」はアロー演算子というもの。
	MessageBox::Show("目" + detame.ToString() + "が出ました");


画像の ちらつき編集

画像がひんぱんに変化するアプリでは、画面が、ちらつく事がある。画面のちらつきは、ゲームのように、頻繁に画像が変わるアプリでは、かなり利便性を損なう。

キャラクターが1歩移動するだけで、画面全体がチラついたりする場合もあり、かなり、プレイヤーの不満になる。

これは、ダブルバッファという技術で、解決できる(日本のゲームプログラマーに「裏画面」と言われる技術を使えばいい)。


なお、Direct Xの用語では「スワップ チェーン」という。しかし、web検索で「スワップチェーン」としらべても、具体的なコードのある解説がほとんど出てこないし、何よりDirect Xでしか通用しない技術になってしまうので、あまり「スワップチェーン」には深入りしなくていい。

名目的には、.Net Framework開発環境のC++でもC#でもダブルバッファの機能はある事になっている。いくつかのGUIオブジェクトのプロパティで、ダブルバッファの設定項目がある。しかし、.Net Frameworkの不具合か設計ミスか何か知らないが、これら.Net Framework開発環境で、マイクロソフトの公式ヘルプどおりの方法(のはず)でダブルバッファをオンにしても、うまく動作しない(仮に間違った操作をしてたとしても、.Net Framework開発環境の公式ヘルプをきちんと整備してきてないマイクロソフト社が悪い)。

.Net Framework が頼りにならないので、残念ながら、Win32 API を使う必要がある。 Win32 APIは、古くからある開発環境のため、ネット上に情報が充実している。


フォームデザイナによる開発は、頼りにならない。

フォームデザイナで、ユーザーコントロールなどを使って、そこから画像書き込みをすれば、おそらくユーザーコントロールが裏画面として扱われるためか、ちらつき自体は解決できる場合があるが、しかしユーザーコントロールの使用上、グローバル変数の共有が困難だったり、アプリ内での終了コマンドが無いなどの欠点がある。特に、グローバル変数の共有が困難な点は、ゲーム性およびゲーム開発効率を致命的に損ない、使い物にならない。

また、困ったことに、GUIフォームの「パネル」オブジェクトに、ダブルバッファの機能が無い(もしくは不十分)。「パネル」なら、グローバル変数の共有は比較的に簡易だが、今度はダブルバッファの機能が不十分なのである。

一方、GUIフォームの「ピクチャーボックス」オブジェクトでは、関数ブロック内に書ける処理命令は、画像をクリックしたときの処理しか書けない。我々は、クリックしてない時にも画像(静止画だけでなく時には動画)を表示したいし、マウスクリック以外のキーボード操作にも画面を反応させたいのであるから、「ピクチャーボックス」は機能不足である。

結局、どのGUIオブジェクトでも、ゲームのような動画を描画できない。だから、Win32 API を使う必要がある。フォームデザイナは使えない。



ゲーム用の独自プログラミング言語編集

日本でネット上で流通しているゲーム開発ソフトには、ゲーム開発用に、独自のプログラミング言語を持っている場合があります。

このような機能の実現方法は、C言語で、ファイル入出力の関数を使い、テキストファイルの文字列を読み取って、文字ごとに条件分岐を設定する機能があるので、そのような機能を使って、独自の言語を作成することで、独自のプログラミング言語を作成することで可能なのです。

(たとえば、文字列 IF を読みとったら、あらかじめC言語プログラムで作成しておいた if文で書かれた関数を呼び出せば良い)。


なお、原理的には、 Java Script や Python などでも、文字読み取りの機能を使って、独自のプログラミング言語を作ることができます。


というか、そもそも、C言語以外のプログラム言語の、プログラム言語そのものの作成方法は、このようにして作成しています。

つまり、そもそも、C言語以外のコンパイラやインタプリタというのは、このような方法で作られています(なお、C言語そのもののコンパイラを作りたいなら、OS作成時にアセンブラ言語を使って、文字読み取りの関数を作って、C言語を作ればいい)。


さて、ときどき、ゲーム製作ソフトなどで、独自のプログラミング言語を使用している場合があります。たいてい、コンパイル作業を必要としないので、そのようなソフトは、インタプリタ方式でしょう。

そもそもWindowsの場合、実行ファイルに変換するには、Visual Studio というマイクロソフト社の配布しているソフトがないと、通常は、コードの実行ファイルへの変換は不可能です。

なので、必然的に、Visual Studio が開発環境を提供していない独自言語は、(その言語開発者が、よほど技術力が高度でないかぎり、)たいてい、その独自言語の実行方式はインタプリタ方式となります。

ゲームのデバッグ編集

総論編集

ゲームにかぎらず、一般にソフトウェアのバグを取り除く修正のことをデバッグといいます。

ゲームのデバッグのためには、まずバグを発見する必要があります。

しかし、すべての潜在的なバグを発見するのは、人員の限りや時間の限りがあり、ほぼ不可能です。

なので、まず製作者は、プレイヤーのよくやる行動をゲームプレイで再現してみて、そして遭遇したバグから直しましょう。


極端な例を挙げると、例えば、もし、普通のプレイヤ-のやらない行動をしてみてバグを見つけて直しても、 たとえば、RPGで、薬草の使用をキャンセルするのを20000回連続で続けると遭遇するバグがあったとして、もし製作者がそのバグを直しても一般プレイヤーは気づきません。

1960年代のような古いコンピュータのデバッグ方法と、現代のデバッグ方法は違います。

つまり、パソコン黎明期の科学計算のデバッグやファミコン黎明期(1980年代)のゲームのバグの探査方法と、現代の廉価or無料のパソコン用ゲームのバグの探査方法は、微妙に違います。

アセンブラなどをいじくる必要のあったテレビゲーム機の黎明期の時代のバグ発見の方法は、現代では、あまり向いていません。

現代のゲームでは、バグ修正は、ネットワーク通信ゲームなら、公開後にもネット経由でアップデート修正することもできます。

また、有料ゲームでも、販売前に体験版などを配布してプレイヤーにテストプレイしてもらう事で、プレイヤーの遭遇しやすそうなバグを探せます。


一方もしゲームでなく、たとえば自動車用の組み込みプログラムや、あるいは工作機械などの組み込みプログラム組み込みなどのバグ探索ならば、バグが人命の死につながりかねないので、たとえば、電源ケーブルや通信ケーブルなどの抜き差しをしたりとか不安定な状態にしてバグを探したりとか、温度をあげたり下げたりとかまでしたりとか、そういうハードウェアとの関連のありそうなバグも様々な方法で徹底的に探します。

しかし、現代のゲーム開発では、そこまでしてバグを探す必要は無いでしょう。

また、こういったハードウェア関連のバグは、OSメーカーやあるいは業務用の組み込み機器メーカーなどが探すべきバグです。 けっしてPC用ゲームメーカーの探すべきバグではないです。

新発売されたばかりの新ハード用の対応ゲームをハードメーカーやOSメーカーが制作しているならともかく、既存のパソコン用の無料ゲームや廉価ゲームなどでは、そこまでしてハード関連のバグを探す必要は無いでしょう。


優先順位づけ編集

ともかく、ゲーム産業にかぎらず一般のIT業界でも、発見されたバグは、修正の優先順位にもとづいて格付けをされます。

医学における、どの患者から先に治療すべきかという概念である「トリアージ」という医学用語になぞらえて、IT業界でもバグの修正対応の優先順位(priority)の格付けのことを外国でも「トリアージ」と言います。

このことは、ゲーム作家の側には「トリアージ」などの用語の暗記は不要ですが、どちらかというとプレイヤーのテスト協力者などに考え方を知ってもらう必要があるでしょう。

もし科学者が科学計算ソフトウェアで世界最先端の開発を目指すのなら、(予算が国から与えられる限り)好奇心や興味のおもむくままに研究して、「トリアージ」の概念を無視するのも可能かもしれません。しかし一般のIT産業やゲーム開発では、予算の制約が厳しく、人員や設備の制約も厳しく、そうはいかないので、「トリアージ」的な優先順位づけが必要になります。


すべての組み合わせの検証は無理編集

たとえばRPGなら、武器や防具といった装備の組み合わせは、

もし武器(剣や槍や斧や杖や弓など)が合計で100種類、
頭防具が合計で50種類(カブトや帽子)、
胴ヨロイや服が合計で50種類、

だとしたら、組み合わせは装備だけでも合計で 100×50×50 = 250000種類 (25万)にもなってします。

つまり、もしすべての組み合わせを検証しようとすると、作業が指数的に増えてしまいます。

しかし、こんなに多くの組み合わせを検証するのは個人では無理ですし、無駄です。


デバッグ検証はせいぜい、武器なら100種類の装備をすべて装備してみて、装備できるキャラクターが装備しても異常が無いかとか、戦闘で実際に攻撃を見て以上が無いかとか、そういうことを確認すればいいのです。

同様に、防具のデバッグ検証もそうです。

これなら、装備の検証作業は、100+50+50=200種類なので、大幅に作業が減ります。

つまり、足し算、加算的に検証すれば、十分です。


実際の市販のRPGなら、さらに装備の数が多くなるでしょう。

また、どのキャラクターが装備するかとか、どこのエリアで装備するかとか、いろいろな組み合わせが実際のプレイにはありますが、もちろん、そんな検証をすべてするのは無理で無駄です。


上記の例ではRPGの装備システムを例にとりましたが、別にRPGやシミュレーションゲームなどのパラメータの多いジャンルのゲームに限らず、 異なるジャンルのたとえばアクションゲームやアドベンチャーゲームなどのゲーム内の各種システムでも同様です。

なのでデバッグは、ゲーム内の各種のアイテムやコマンドなどのデバッグなら、せいぜい、とりあえず、そのアイテムやコマンドなどを選択したり実行しても異常が無いかを1回だけ試せばいいのです。

そもそも、ゲームのシステムは基本的に、プレイヤーごとに異なる多様なプレイスタイルに対応するために多くのアイテムやパラメータやイベントをゲーム内部に持っていて、そういった組み合わせの意外性などをシミュレートして楽しむものです。

なので、組み合わせは膨大になるのが普通なので、全組み合わせの掛け算的な回数の検証は無理です。


テレビゲーム黎明期の1980年代なら、装備アイテムの数などが少なかったので、もしかしたら組み合わせをすべて試すのも可能だったかもしれませんが、しかし現代では、アイテムの数などは膨大に増えており、もう無理です。


このため、現代の複雑化したゲームではver1.00以降の発表後にも、アップデート修正が必要になる可能性が高いです。なので、ver1.00の発表前に事前にアップデート版の配布が可能な環境を整えておきましょう。

さらに、もし有料ゲームのアップデート配布の場合なら、なるべく

有料版ソフトを買った人だけに、無償でアップデート適用ずみのフルパッケージ版を配布できるような環境

があるかを事前に環境準備しておく必要があります(「修正パッチだけ無料公開」とかではなく、すでに修正パッチを適用した状態でのフルパッケージ版という意味。消費者が有料で購入しているのだから、修正パッチ適用などの手間を掛けさせない。そもそも、修正パッチを適用するのにソースファイルが必要な場合が普通なので、普通はメーカー側で修正パッチを適用してから配布する)。


個人でそういう配布の環境を構築するのは困難なので、個人の場合には、ネット上のいくつかの企業がソフトウェア公開・販売環境を提供している企業がいくつかあるので、そのサービスを利用すると良いでしょう。

さらに、アップデート版のソフトウェア内部のシステムでは、過去バージョンの有料ゲームから、最新の修正後バージョンへのプレイデータの引継ぎをできるようにする必要があります(たとえばRPGの場合、プレイヤーにレベル1の序盤から再開させるワケにはいかない)。このデータ引継ぎの工夫は、ソフトウェア販売サービス提供の企業では無理なので。


もし、上述のようなアップデート配布が不可能な環境にあるのなら、そのゲームが個人製作のゲームの場合には、無料ゲームソフトにしておきましょう。

ゲームにかぎらず一般に有料ソフトを販売した場合には、開発元のメーカーは「保証期間」または「アフターサービス」のような社会的責任として、発売開始後から数年ていどは無償で不具合対応などのアップデートをすべきという社会的な責任があります。

食料品やティッシュペーパーのような消耗品でないかぎり、ソフトウェアにかぎらず一般の工業製品などでも企業は商品の有料での販売においては、発売開始後から数年は、「保証期間」などとして無償または低価格の不具合対応などの社会的責任が要求されます。

無料のソフトではそこまで保証する義務は無いですが、まあ実務の練習だと思って「保証期間」的なものも頭の片隅に意識しておいたほうが無難でしょう。



ソースファイルにモニター(監視)機能を入れる編集

もうひとつのバグ発見の方法として、

一般にゲーム開発では、作者用のソースファイルと、プレイヤー用のファイルを分けるので、

作者用のソースファイルにデバッグ用の機能をいくつか入れておく方法もあります。


ゲーム内のシステム内部の監視のためのデバッグ用メッセージ(「現在のパラメーター herosPower は 134 です。」のようなメッセージ)を表示するモニター的な機能は、こちらソースファイル側で行うとよいでしょう。

なぜなら、プレイヤーが細かいシステムメッセージを見ても退屈ですので。


まずテストプレイしよう

まず、バグ発見のためには、モニター機能プログラムを書くよりも先に、まず先に実際にゲームを起動してゲームをプレイしてみることです(いわゆる「テスト プレイ」)。テストプレイで挙動のオカシイ部分があったら、そこで、ソースコードで、挙動のおかしい箇所のプログラムの近辺で、変数の内容を表示する機能のあるモニタープログラムを自分で書きます。

ブレークポイントは後回し

なお、WindowsのVisual Studio には、ブレークポイントという、デバッグ用にコード中に強制停止するポイントを設定する機能があり目的の箇所でコードを停止させ、変数を表示させる機能がありますが、しかしこの機能(ブレークポイント)をいきなり使うのは、ゲーム製作では、あまりオススメできないです。

なぜなら、ゲームが止まってしまうので、実際のプレイ中でのパラメータの変化が不明です(ブレーク時点での変数の値しか、分かりません。)。


ブレークポイントを使う場合は、起動そのものの不可能なバグとか、ゲームが異常停止していまうようなバグの場合などの、テストプレイそのものが困難な重篤なバグの場合にだけにしましょう。

テストプレイが可能なていどのバグなら、なるべく実際にゲームをテストプレイして、モニタープログラムでバグの性質をさぐったほうが早いです。


モニタープログラムは最小限にするのがコツ

しかし、まだバグの見つかって無い段階で、モニタープログラムを入れるのは、オススメできません。

なぜなら、ソースファイルが見づらくなるからです。

バグが見つかってから、関連しそうな変数を表示するモニタープログラムを書きましょう。

モニタープログラムは最低限にするのがコツです。

そして、バグが修正し終わったら、そのモニタープログラムのコードは、量が多くなってきたら場合は、さっさとソースコードから該当する変数のモニタープログラムをコメントアウトするなどして、非表示にしてしまいましょう。

なんでもかんでもシステム内メッセージを画面に表示したとしても、メッセージを読みきれないので無理です。


また、あまり、ソースファイル独自の機能を追加しすぎると、一般にソースコードじたいが読みづらくなります。


デバッグルームなど編集

デバッグルームとは編集

ゲーム内でめったに起きないイベントなどのデバッグは、通常のプレイ方法では、めったに遭遇しないために発見が困難になります。

たとえば、ゲーム内でくじ引きがあり、1000分の1で大当たりが出るとしましょう。

通常のプレイでは、このくじ引きを1回だけしか出来ないとしましょう。


このようなイベントのデバッグ検証の場合、「大当たり」にバグがないかは、デバッグ用に、ゲーム作者だけ、くじびきを何百回も続けてチャレンジできるようにしたりとか、あるいは、ゲーム作者だけ、くじ引きの結果を操作できるようにして強制的に「大当たり」が出たりするようにするとか、

そういう作者だけの特殊システムが必要になります。一般プレイヤーには、デバッグルームには入れないように、対策する必要があります。


このような、デバッグ用の作者専用システムのことを、俗にゲーム業界では「デバッグルーム」とか「デバッグモード」とかいいます。

デバッグルームとは「デバッグの部屋」という意味です。作品によっては、実際にゲーム内に「デバッグルーム」というエリア、ステージを用意する場合もあります。

この機能を作者が使うことを「デバッグルームに入る」とか「デバッグモードをオン(ON)にする」いいます。

名前こそ「デバッグルーム」や「デバッグモード」などというものの、ぢかし、その場所ではバグそのものの退治・修正はしないですし、そもそも、ゲーム起動中にバグ修正は不可能です。

最終的にバグを修正するには、(ゲームをシャットダウンさせてから)ソースコードを開発ツールなどで直す必要があります。

「デバッグルーム」とは、単にゲーム内でバグ探しの作業をしやすいように、プレイヤーキャラクターを強化したり、あるいは敵を弱体化させるなどの環境を調整するだけなのが、デバッグルームです。


背景として、基本的にはプレイヤーキャラクターが強めのほうが、ゲーム内世界をいろいろと探検しやすいのでバグは発見しやすくなります。


なぜならゲームでは、たとえばRPGでゲーム終盤の強敵を倒したときに発生するバグなどは、主人公がゲーム序盤の弱いキャラクターの状態では無理です。一方、ゲーム序盤の弱い敵に主人公が負けるなら、単に油断したり無防備になればいいだけなので、主人公は強いままでもデバッグ可能です。

「大は小を兼ねる」といいますが、ゲーム内では強めのキャラは弱めのキャラを兼ねます。

しかし、その逆は困難です。


なので、たとえ、デバッグ用の機能の名前に「デバッグルーム」などの名前がついていなくても、もし裏技や隠しアイテムなどでプレイヤーを強化するものがあれば、実質的にデバッグモードでしょう。

また、ゲームクリア後に、初回プレイよりも強い状態でニューゲームを出来る機能があれば(いわゆる「強くてニューゲーム」)これも実質的にデバッグ機能して活用できます。ゲーム序盤~前半のイベントに潜むバグなどを探すには、「強くてニューゲーム」のような機能があれば便利でしょう。


プレイヤーによっては、「デバッグ」などのIT用語を嫌がる人もいるので、そういうのに気をつける必要もあります。

また、ゲームのジャンルによって、近未来SFファンタジーやSFアクションなどでは、ゲーム中のシナリオにもIT用語が出てくるので、そういうのと区別するために「裏技」などの言い換えをしたほうがいいかもしれません。


デバッグルームの建築編集

さて、デバッグルームを建築する際は、なるべく、既にそのゲーム内にあるシステムを流用します。なるべく、一般プレイヤーにも公開されている機能を組み合わせてルームを作る必要があります。そうしないと、デバッグルーム独自機能の検証の手間が増えてしまうので、かえって、メンドウになってしまいます。


デバッグルームの中では、普通のプレイヤーが操作できないものを操作できるようにします。たとえば、RPGなら、プレイヤーキャラのレベルをある程度の上昇させたり下げたりとか、主人公の入手している武器や防具ある程度の範囲でを操作したりとかの機能が必要です(けっして、完全に数値をピッタリ調整する必要はないです。最終目的はあくまでバグ発見です。けっして数値をピッタリと調整することは目的ではないです)。

RPGなら、たとえば、強めの武器や防具をいくつかデバッグルーム内においておいたりとか、あるいは、通常プレイでは商店では非売品の武器・防具をデバッグルーム内では有料(ゲーム内の通貨)だが販売しておくとかすれば、万が一、一般プレイヤーがデバッグルーム内に進入してしまっても安全です。

あるいは、デバッグルーム内に、経験値アップや、レベルアップなどのアイテムとかをいくつか置いておくと、レベル上げの手間が減ります。

このようにデバッグルーム内に強化システムを配置しておくと、ゲーム後半のイベントなどの検証も、ラクになります(キャラクターの育成などに掛かる時間などが短くなるので)。


くじ引きの「大当たり」などのイベントをデバッグ検証で容易にしたいなら、デバッグルーム内に、たとえば「幸運のお守り」のような感じのアイテムを置いておいて、それを装備すると、ゲーム内のくじ引きなどの大当たりの確率が100%になるとか50%になるとかの機能をつけておいて、そういうふうなアイテムを作っておけば、くじ引きなどの検証がラクになります。


さて、一般プレイヤーには、デバッグルームには入れないように、対策する必要があります。

作者のファイルにだけ、デバッグルームに入れるアイテム(「デバッグルームの鍵」など)とかを設置するとかして、実装します。一般プレイヤーに配布するゲームデータには、デバッグルームの鍵などを与えないようにします。デバッグルームの場所は、ゲーム内の中盤や後半に隠して立てておくと安全です。

あるいは隠すのではなく正式な公開機能として、ゲームクリアしたプレイヤーに、デバッグルームの一部を開放するなどする方法もあります。こうすると、あまり気にやまなくても済みます。

または、ゲーム開始のオープニング画面中に、画面には表示されてないが実はパスワード入力を受け付けしている状態を起動させておいて、パスワードが正しければデバッグモードがオンになった状態でゲームを開始できるようにするとか、そういう方法もあります。パスワードの受付をしているのを、プレイヤーには見せないようにします。


アクションゲームなど、あまりRPGのようなアイテム配布をしづらいようなシステムの場合は、この裏技のような方法のほうが便利でしょう。


裏技システムの場合、もし一般のプレイヤーがたまたまデバッグルーム用パスワードと同じキー配列を入力しないように、パスワードは十分に複雑にしておくとかの工夫が必要です。万が一、パスワードを運よく一般プレイヤーが知らずに偶然に入力してしまってゲームを開始した場合でも、プレイヤーがゲームプレイを楽しめるように、「これは裏技モードです」とかとでも冒頭で紹介しておいて、プレイヤーキャラクターの強さを(通常モードと比べて)やや強めに変更するくらいの設定にしときましょう。

1980年代のファミコンなどの市販ゲームで、こういう「裏技」(うらわざ)がよくあります。おそらく、そのソフト開発者がデバッグ用に残した機能だったのでしょう。


セーブとデータベース編集

セーブ機能とロード機能の作り方編集

もしゲームのためにセーブ機能が必要で、単に数値(HPなどの現在値など)や文字列(プレイヤーの作成したキャラの名前など)や現在地やフラグ状況などを保存したい場合なら、普通のC言語の fopen 関数のテキストファイル書き込み機能で、簡単にセーブ機能を実装できる。

Windows API の CreateFile 関数でなくとも、Windows ゲーム用のセーブファイルを作成できる。

標準C言語のfopen関数でも、Windows のGUIなゲーム用のセーブファイルを作成できる。


プログラム内容も、セーブで保存したい内容を、単にテキストファイル形式で書き込めばいいだけである。


ロードも、単に、書き込んだ内容を、fopenの読み込み機能でセーブデータをゲームに読み込んで、読み込み内容に従ってゲーム中の変数に適切な数値を代入させればいいだけである。


ただし、テキストファイルでセーブを書き込んだ場合、数値などは単なるテキスト文字として保存されるので、ロードの際にはC言語のatoi関数で数値に変換する必要がある。


なお、もし機械語でセーブファイルを作りたい場合は、既存のファイル形式(画像ファイル形式や音楽ファイル形式など)の機械語の形式に機械語ファイル識別子などが、かぶらないようにする必要があるので、作成の難度がやや高い(機械語のファイル冒頭には、ファイル識別子の情報がある)。

一応、もし既存のファイル形式に識別子が重なってもC言語プログラムで読取も書き込みもできるが、あまり推奨できる設計ではない。万が一、それが原因で不具合が起きてもプログラマーの自己責任である。


なお、市販のパソコン用ゲームや同人ゲームなどだと、テキストファイルでなく機械語で保存されているゲームも多い。ゲーム開発ツール側じたいが、そうなっている場合もある。たとえば、RPGツクールもウディタも、セーブデータの形式は機械語である。なぜ分かるかというと、ツクール製ゲームのセーブデータを、なんらかのLinuxデスクトップ上でセーブファイルをオープンすると、ファイル内容がいくつもテキスト文字として認識せずにエラー報告されるからである。ウディタの場合、そもそもLinux上ではテキストエディタではオープン不可能か、なんとか開けても、やはり中身がテキスト文字として認識されずにエラー報告されるからである。

テキストファイルによる保存は、日本のゲーム業界では あまり好まれていないようだ。


なお、暗号化について、たとい機械語でセーブ内容を書き込みをしてもバイナリエディタなどで読み込めば中身を読めてしまうので、ソースコードの内容を機密にしたい場合は暗号化が必要である。

特殊イベントのフラグの作り方編集

RPGなど、ゲーム中で一回しかおきない特殊なイベントとかを作りたい場合があるでしょう。RPG以外でも、シミュレーションゲームなどで特殊イベントを実装したいこともあります。たとえば、もし日本の中世の戦国時代シミュレーションゲームで「桶狭間の戦い」が3回も起きたりしたら困ります。

RPGの場合、1人しかいない中ボス敵(生物)を倒して殺すイベントは、1回しか起きなくては困ります。そして、たとえば中ボスを殺すと、大ボスの居城に行けるようになるストーリーだとしましょう。


どうやって、こういった特殊イベントを実装すればいいでしょうか?

とりあえず、C言語で手段を問わずに単にこれを実装するだけなら、プレイヤーが中ボスを殺したときに tyuubosDead=1 とかセットして書けばいいわけです(もし tyuubosuDead=0 なら、まだ中ボスを倒していないとする)。

こういうイベントの判定などの処理のために使う変数のことを、ゲーム業界用語で「フラグ」といいます。

あとはif文などで、フラグ変数をもとに、イベントの発生の有無を判定するシステムにすればいいだけです。


では、ツクールとかウディタとか、ああいうゲーム開発ツールでは、こういう特殊イベントのフラグ処理をどうやって実装しているのでしょうか?

ツクールなどの幾つかの開発ツールでは、「データベース」という項目があり、じつはこのデータベースを作者に使わせて、フラグ変数を代用させる仕組みです。

RPG開発ツールの「データベース」は、武器やモンスター名などのデータベースでもありますが、イベントフラグにも流用されます。

なお、RPGツクールやウディタなどでは、けっして、わざわざイベント専用の変数項目は用意されておらず、代わりにゲーム作者が自由に作成できる変数項目がいくつかあるので、それを組み合わせてゲーム作者が自分で作る必要があります(RPGツクールの場合、アイテム用データベースのなんらかの特殊アイテム所持数をイベントフラグとして流用するのが簡単でしょう。ウディタの場合、特に目的の定められていない「可変データベース」で目的の定まってない変数が作成できるので、それのいくつかをイベントフラグとして流用することになるでしょう)。

「戦闘中のボス敵のHPが半分以下なら、○○のイベントが起きる」などのイベントを実装したいゲーム作家さんもいるので、けっしてイベントフラグ専用の変数を、いちいちツクール開発企業(現在は角川書店、もともとはアスキー)は用意してくれません。

※ なお、こういった、Visual C++ などを用いないでゲーム開発ツールが変数を作る方法の実装手段は、一番簡単なのは配列を用いて実装する方法だろう。配列を流用しているだけなので、ゲーム開発ツールでは作成できる「変数」の要素数に限りがある。
また、ツクールやウディタでも、作成した変数にはid番号が1番(または0番)から順についており、このid番号を通じてイベントなどを制御する仕組みである。id番号が、配列の要素の番号であろう。


ゲーム中にイベントを挿入するさいに、データベース中の指定した項目の数値を参照して、その数値が「○○に等しいか?」「○○以上か?(以下か?)」などの条件判定をして、条件が真なら、真の場合の処理を実行するという、単純な仕組みです。

また、どのマップにも固定敵とのバトルにも、イベントを挿入できる仕組みになっていますので、作者は必要に応じて、どのマップでも固定敵バトルでもイベントを起こせるのです。


なお、もし読者のあなたが(RPGツクールやウディタみたいな)ゲーム開発ツールそのものを自作したいなら、RPGの戦闘システムやマップシステムに加え、こういったデータベースを流用したイベント管理フラグを実装すればいいわけです。

C言語でデータベース的なものを構築する方法なら、いわゆる「構造体の配列」または「配列の構造体」というもので簡単に実装できます(wikibooksでも『C言語/構造体・共用体』で解説しているでしょう)。構造体の配列は、情報系の専門学校や大学の情報系学科などでも普通に習う、ありふれた手法です。


なお、配列のほかにもデータベース的なものの構築方法はあり、テキストファイルなど外部ファイルに書き込みをして入出力する方法でも、データベースを構築できます。C言語のfopen関数で、簡単にファイルに読み書きできます。作成するテキストファイルを隠しファイルにしておけば、ユーザーが書き換えする心配も減らせますし、もし書き換えてしまってもユーザーの自己責任です。なお、Windowsでプログラミングで隠しファイルの作成などをするには、Windows APIの CreateFile関数で、ファイル属性の操作で FILE_ATTRIBUTE_HIDDEN を指定すれば、隠しファイルを作成したりできます。


さて、特に、CSV形式(シーエスブイけいしき)という書式のテキストファイルによるデータベースは、ゲーム業界にかぎらず、一般のIT業界でもよく使われる方法です。


配列だとデータ数が多い場合にメモリを圧迫する可能性があるので、もし自分でゲーム開発ツールを造る場合は、データ数がとても多い場合には外部ファイルに入出力するのも、ひとつの解決策です。

ただし、テキストファイル読み書きでデータベースを構築する方式の場合、マップ入場時など場所の切り替え時に、読み込み時間が少し掛かります。

また、テキストファイル読み込み形式のデータベースでも、読み込んだデータを処理するために配列や構造体をいくらか使用しますので、どちらにせよ知識として配列などの知識は必要です。

また、テキストファイルなど外部ファイルを読み書きする場合、データベースが外部出力されるのでユーザーがデータベースの中身を閲覧可能になりますので、機密性などは下がりますし、それでもデータベース内容を機密にしたい場合は暗号化などの手間が掛かります。

自分でゲーム開発ツールを造る場合は、作りたいゲームにあわせて、配列方式か外部ファイル読み書き方式か、データベースの方式を選びましょう。


どちらの方式にせよデータベースによるプログラミングは、まるで、昔のアセンブラによる変数の実装でメモリ番号の指定による実装を、代わりにC言語の配列の番号またはテキストファイルなどを用いて擬似的に実装したかのような方法です。なので、一応は、ツクールのような方法でも、利用できる変数の個数が足りるかぎり、ほぼ、どんなイベントでも作れます。


また、欠点として、まるで擬似アセンブラみたいな実装方法なので(より正確に言うなら、配列による擬似メモリマップか。メモリマップについては『オペレーティングシステム#メモリマップ』で解説)、当然ですがC言語のような構造化プログラミングの洗練された手による支援は、ゲーム開発ツールによる上述のようなデータベース駆動型のプログラミングでは、ほぼ見込めませんので、このためソースファイルの内容が、第三者や後日の自分が見て内容の分かりりづらい、いわゆる「スパゲティコード」のようなソースファイルが作られやすくなります。

ひとつの配列を、番号ごとにゲーム内の異なる様々なイベント処理のフラグとして流用するわけですから、「どの番号がどのイベントに割り当てしているか?」などを作者は把握しておかなければならず(いちおう、番号ごとに変数名をつければ暗記しなくてすむが)、管理がメンドウになります。

もし、データベースを使わずにC言語で直接にイベント処理を記述するなら、普通は異なるイベントには、異なる配列を宣言して作成するわけですので、番号の割り当ての把握は不要になります。


さて、原理的には、上述のようなデータベース駆動型プログラミングというか配列駆動型プログラミングを使えば ほぼ どんなイベント処理もできるのですが(アセンブラの「変数」の実装をC言語などで擬似的に再現したものなので)、しかしゲーム中の特殊イベント数が増えると(ボス敵の数が増えてきたり、依頼の数が増えてきたり、伝説のアイテムの数が増えてきたり)、登録する変数の数も増えてしまうので、管理が なかなかメンドウになってきます。

なので、もし幾つもの特殊イベントの発生順序が決まってる場合などは、データベースに「ストーリー進行度」とか「シナリオ進行度」みたいな名前のパラメータを1つ作って、「もしストーリー進行度が○○以上なら、このイベントが発生する」などの方法をとる場合もあります。

あるイベントをクリアすることで、ストーリー進行度が+1される、というような仕組みで、各ストーリーを順番に実行させる、・・・といった仕組みも、ゲーム開発で、よく聞きます。

また、ストーリーの分岐などをする場合は、シナリオ進行度をまるでBASICの行番号の分岐のように使って、選択肢などの結果に応じて(ラベル的に)ストーリー進行度をジャンプさせることで、分岐を実現したりもします。

ノベルスクリプトなどでは、こういった仕組みによるイベント実装も、多いかもしれません。


あるいは、上述の組み合わせ、つまりデータベース変数によるイベント判定と、ストーリー進行度によるイベント判定などの組み合わせなども、考えられます。

ゲーム作者は必要に応じて、適した方法を使いましょう。


フリーゲームや同人ゲームにかぎらず、大手ゲーム企業の開発する一般の商業ゲーム(テレビなどで宣伝されるゲーム作品)でも、イベント部分の記述は、エンジン部分を担当するC言語系統のゲームエンジンおよびそのエンジン用言語とは別のスクリプト言語(たとえばpythonやLuaなど)をもちいて(イベント部分のプログラムを)記述するのが普通だとされています[1]

なお、ゲームエンジンの多くはC言語系統のコーディング環境である。例として UnityはC#系統の環境だし、Unreal EngineはC++系統の環境である。


データベース分離の作業での方針編集

自作ゲームがある程度の完成度になるとデータベースを分離する作業に取り掛かることになる。

もし既にセーブ&ロードの機能が自作ゲームで実装してあれば、単に、そのセーブ&ロード機能を流用して、データベースの外部ファイルの入出力機能も作れてしまう。


この設計の場合にラクな手順としては、データベース分離の当初の段階では、けっしてデータベース編集ソフトとかを別系統では作ろうとせずに、まずは自作ゲームそのものにデータベースの入出力機能を組み込むことである。(イメージ的に言うと、ファミコンソフトの『w:ロードランナー』のステージ自作機能みたいに、自作ゲームに組み込むとラクである。)


まず外部ファイルに出力(エクスポート)

外部データベース入出力では、まず外部ファイル出力の機能のほうから作り始めたほうが、既存のコードが流用できるのでラクであろう。

自作ゲームがある程度はプレイ可能な状態なら、すでにコード内に配列や構造体などでコードがある段階なので、あとは、そのコードの配列変数などの内容の数値を、自分で決めた書式の順番どおりに外部ファイルにCSV形式などお望みの書式(自分で書式を決めていい)で出力すればいい。(CSV形式の読み込み方法のコードの作り方は『C言語/ファイル入出力』で説明してある。)

ついつい、外部ファイル取り込み(インポート)のほうから作りがちであるが(既存のゲーム製作ツールのユーザー視点だと、こうなりがっち)、しかし、外部ファイル出力(エクスポート)側から作ったほうがラクであろう。

セーブ&ロードの機能がすでにあるなら、エクスポート機能の製作では、そのセーブ機能のコードを流用すればいい。


外部ファイルからの読み込み(インポート)

そして次に外部ファイルを読み込めばいい。インポートでは、さきほどのエクスポートの作業を逆にして、ロード機能のコードを流用すれば、簡単にインポート機能を作れる。


さらにデータベース編集機能を作りたければ、上記のインポート&エクスポート機能に、エクスポートの際の書き換えの指示などを出せば済むだろう。


脚注編集

  1. ^ 『企画出身だからできる開発効率の推進〜バンダイナムコスタジオのテック職に聞く異色のクリエイターキャリア論 | インタビュー | CGWORLD.jp』 2020年1月17日に閲覧

関連項目編集