ゲームプログラミング

出典: フリー教科書『ウィキブックス(Wikibooks)』
ナビゲーションに移動 検索に移動

概観[編集]

「ゲーム」とは[編集]

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

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

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

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


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

自分でゲームを作る際、必ずしも、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 が開発環境を提供していない独自言語は、(その言語開発者が、よほど技術力が高度でないかぎり、)たいてい、その独自言語の実行方式はインタプリタ方式となります。


作業リストを作る[編集]

作業リストの制作開始の方法[編集]

ゲームを作る際、けっしてアタマの中であれこれとアイデアを考えるだけでなく、まずそのアイデアをテキストファイルなどに書き出しましょう。

このとき、とりあえず1週間~1ヶ月ていどで成果の確認できそうなアイデアだけにしましょう。


ついで、その数日で達成できそうなアイデアを、とりあえず実際に動作するプログラム・ソフトウェア(いわゆる試作品(プロトタイプ))にするために、何を自分が具体的にどんな機能をもったプログラム(簡単なプログラムでいい)を制作しないといけないかとか、

そういった、自分の「やるべきこと」のリスト(一覧表)を箇条書き(かじょうがき)で作りましょう[1]


IT業界で、こういうリストを「ToDoリスト」(読み: トゥードゥーリスト)とか「タスクリスト」いいます。(To do とは英語で「やるべき事」「やるつもりの事」のような意味)

わざわざ英語でいうのも面倒なので、私たちは日本語で「作業リスト」でもいいましょう。


さて、作業リスクを作るとき、作業項目は、具体的かつ単純な目標に分割します。

たとえば RPG の戦闘システムを作るとき、けっして

*「戦闘システムを作る。」(×、ダメな例)

と書くのではないです。

そうではなくて、たとえば下記のように具体的に

*戦闘画面のメッセージ表示欄および標準メッセージを作る。
*「闘う」コマンド選択欄を作る。(動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。)
*主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。
*主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。
*味方キャラが素早さ順に行動する処理を作る。

みたいに作業項目を細かく分割していきます。

こうすることで、作業がひとつずつ、比較的に簡単な作業に分解されていくので、ラクになります。



スケジュール帳ではないので、予定日とかは、ひとますは不要です。(たといスケジュール管理する場合でも、別のテキストファイルで行うべき。)

ネットの中にあるToDOリストの手本のなかには、予定日とかも書いたりするような細かいものもありかねませんが、しかしそういう細かい予定日とかは、とりあえずゲーム初心者には不要でしょう。

ともかく、作業リストのためにテキストに項目を書き出しをしたら、

次に、優先順位の順番どおりに、並び替えをしていきます。


こうして、とりあえずの最初の作業リストは完成です。


作業リストの更新[編集]

まず、プログラムをする前に、作業リストをながめて、そして作業リストの上のほうにある項目から、実際に作業を開始しましょう。


そして、とりあえず、どれかひとつの項目を、完了させましょう。


さて、作業項目がひとつ終わったら、その項目はけっして消さずに、「【完了!】」とか、なんとか、そういう情報を、項目の前または後ろにつけます。

たとえば

*【完了!】戦闘画面のメッセージ表示欄および標準メッセージを作る。
*【完了!】「闘う」コマンド選択欄を作る。(動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。)
*主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。
*主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。
*味方キャラが素早さ順に行動する処理を作る。

たとえ作業項目が終わっても、項目を消さずに、ゲーム完成までは作業項目の表示を残すのがポイントです。

のようになるワケです。

また、もし追加の作業が必要になったら、たとえばダメージ計算システムを作るために、ランダム計算が必要になって、自分がそのプログラム言語でのランダム計算に詳しくないなら、たとえば

*【完了!】戦闘画面のメッセージ表示欄および標準メッセージを作る。
*【完了!】「闘う」コマンド選択欄を作る。(動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。)
*Visual C++ でのランダム計算のとりあえず出来る方法について調べる。
*主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。
*主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。
*味方キャラが素早さ順に行動する処理を作る。


みたいに、項目を必要に応じて追加したりします。


さて、これからやる作業を検索しやすくするため、たとえば

やることリスト
*Visual C++ でのランダム計算のとりあえず出来る方法について調べる。
*主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。
*主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。
*味方キャラが素早さ順に行動する処理を作る。
 
完了した作業
*【完了!】戦闘画面のメッセージ表示欄および標準メッセージを作る。
*【完了!】「闘う」コマンド選択欄を作る。(動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。)


みたいに完了した項目を後回しにしたりとか、

あるいは

*【完了!】戦闘画面のメッセージ表示欄および標準メッセージを作る。
*【完了!】「闘う」コマンド選択欄を作る。(動作するコマンドはまだ「戦う」だけ。「逃げる」「魔法」などは音回し。)
*(いまココ→) Visual C++ でのランダム計算のとりあえず出来る方法について調べる。
*主人公1人用の「戦う」コマンド用のダメージ計算システムを作る。
*主人公以外の味方キャラのぶんの表示欄も戦闘画面に追加する。
*味方キャラが素早さ順に行動する処理を作る。

みたいに「(いまココ)」とか追加するとか、

人によってさまざまな方法の違いがあるでしょうが、どちらにせよ、たとい、ある項目が完了しても、その項目を消さないで残したままにしておいて「完了」とか追記するだけにしておくのがポイントです。


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

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

もしゲームのためにセーブ機能が必要で、単に数値(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 なら、まだ中ボスを倒していないとする)。

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

ある行動をまだしてない状態のとき、フラグをOFFだとします。フラグがOFFの状態を数値「0」とします。

したら、以降はそのフラグがONになります。ONの状態を数値「1」だとします。


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

原理的に、特殊イベントの処理はすべて、フラグ変数の読み書き処理で可能です。後述する様々な手法も、フラグ変数の読み書きを基礎にしています。


ON/OFF以外のフラグが必要な場合[編集]

たとえばゲーム中では、「ある用事を頼まれたけど、まだその用事を解決していない」のような場合もあります。

さて、ゲーム中で何かの用事や依頼のイベントを扱う場合、もしONかOFFかの2通りだけだと不都合です。なぜなら、

そもそも、その用事を依頼すら、されてない段階.
用事を依頼されたが、まだ解決していない段階.
用事を解決した段階.

という3段階の区別が必要なのに、ON/OFFの2通りだけでは区別できないからです。


必要に応じて、3段階のフラグも作りましょう。

とりあえず、

依頼されてない段階: 0
依頼されたが解決してない段階: 1
解決した段階: 2

とでも、数値の意味を設定しておけば大丈夫でしょう。



データベース的なイベント処理の方式[編集]

ツクールなど開発ツールを使う場合[編集]

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

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

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

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

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


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


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

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

Visual C++などで自作の場合[編集]

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

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


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


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


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

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

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

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

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


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


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

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

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

原理[編集]

RPGのような物語のフラグを作る場合[編集]

RPGのような物語のフラグを作る場合、原理的には、

「1番目のイベントをクリアしたら、2番目のイベントの発生条件フラグが1になり、よって2番目のイベントが始まる」
「2番目のイベントをクリアしたら、3番目のイベントの発生条件フラグが1になり、よって3番目のイベントが始まる」
「3番目のイベントをクリアしたら、4番目のイベントの発生条件フラグが1になり、よって4番目のイベントが始まる」
(以下略)

のように、連鎖的にどんどん、各イベントをクリアするたびに次のイベントが始まるようにすれば、ゲームクリアまでの物語のイベントを実装できます。


さて、原理的には、上述のような逐次的というか1個ずつ進んでいく方法でもゲーム全体の物語のイベント管理も可能ですが、物語が長くなってくると非効率になってきます。

物語の進行に関するイベントが数百個もある場合、いちいち管理するのが大変です。


このような膨大なフラグを管理する場合、どうするかというと、ストーリー全体像のフラグと、ストーリー各部のフラグとを用意します。


たとえば、そのゲームがたとえ「第1話」とか「第2話」とか「第10話」とか別れてなくても、仮に「ゲーム開始からここまでのイベントは第1話とする。」とか「ここからここまでは第2話とする。」みたいな感じで、脳内でストーリーの区切りのいいところで、ある程度おおまかに、それぞれのイベントが第何話に相当するかを分けます。

で、「第1話の内部のそれぞれのイベントフラグ」、「第2話の各部のそれぞれのイベントフラグ」、・・・というふうに、別々に作っていきます。


この「第◯◯話」のように、そのゲームのストーリー全体像を管理するフラグを用意します。

その後、各話数の個別のイベントを作っていきます。


こうすると、たとえば第2話の状況なら、すでに第1話のイベントはすべて終えているハズなので、いちいち第1話の個別のイベントのオン/オフを確認する手間が省けます。


なお説明の都合上、上記では第「2」話みたいに数値で説明しましたが、実際のゲームストーリー開発では個別エピソードの順序が変更する場合もあるので、あまり数値で管理するのではなく、『○○編』(~へん)みたいに各エピソードの題名みたいなのを暫定的につけて管理するほうが、たぶんラクでしょう。

つまり、物語を『○○編』とか『△△編』や『□□編』とかに何分割か、しておきあす。そのあとから、それらの各「編」の順序を、ゲームがもっとも面白くなるように並び替えていくのです。


イベント管理のフラグを作る場合も、たとえば「『○○編』をクリアしたら、次の編である『△△』編が起きる」みたいに編単位で管理していけば効率益でしょう。


ただし歴史シミュレーションは例外

ただし、上記のような方法でイベント管理を作れそうなのは、あくまでも物語の順序がほぼ一通りに決まっている場合です。具体的には、RPGやアドベンチャーゲームなどのジャンルです。

歴史シミュレーションゲームなどで、しかも史実どおりで無い展開も可能なゲームの場合、上記のような物語形式のフラグ管理は無理でしょう。

たとえば、日本の戦国時代シミュレーションゲームによる仮想戦記のシミュレーションで、たとえば「桶狭間の戦い」は(今川を先に信長が倒したので)起きないが、しかし「本能寺の変」が(明智光秀が生きてるので)起きる場合などの展開なども、ゲームによっては、ありえます。

こういう場合、面倒ですが、話数形式のフラグ管理が使えないので、イベント発生条件を1個ずつフラグ管理していく方法しか、ないでしょう。


イベントの終了と次イベントの引継ぎについて[編集]

あるイベントのクリアから、次のイベント開始までの発生の引継ぎをどうするかは難しそうです。もしかしたら作家によっても違うかもしれませんが、とりあえず、下記のような対策が考えられます。

方法1: 次回イベントのオープニングを終了フラグに流用[編集]

たとえば第2話のイベントを始めさせる場合を考えましょう。

さて、もし第1話を終わらせるなら、なんらかの方法で、確実に(第1話の終了直後に)第2話を直後に開始しなければなりません。

このような技法としては、いっそ、第1話の終了フラグがONになるタイミングを、第2話の開始時点にする手法もありえるでしょう。

この手法を使うと、確実に、ストーリー進行での次のエピソード開始への引渡しが可能です(というか、すでに引渡しが完了してから前のイベントを終了させる方式である)。

プレイヤー視点では表面的には、あるゲーム中のシーンが第2話の開始オープニングイベントの自動進行のように見えても、もしかしたら実はプログラム内部的には、そのシーンは第1話のエンディングイベントの自動進行として処理されているかもしれません。


方法2 :とりあえず問題解決までイベント終了させない[編集]

ところで、第1話のクリア条件を満たした場合に、もし即座に第1話を終了してしまうと、当然ですが第1話のエンディングを見られません。

たとえば、あるゲームの設定で、もしRPGで第1話の敵ボス犯罪者を倒すと、ボスが何かセリフを残して死んだり、ボスが誘拐犯なら誘拐された被害者を救出するイベントが自動進行で発生してから、第1話が終わって第2話が始まるとしましょう。


ボスを倒せば第1話のクリア条件が満たされますが、しかし、もしボスを倒した瞬間にフラグを第1話の終了に設定してしまうと、その時点でもう第1話のイベントの進行が止まるので、ボスの残すセリフが見られませんし、ボスに誘拐された被害者の救出イベントにも進行せずに、誘拐された被害者は被害を受けたままになってしまいます。


つまり、第1話のクリア条件のフラグ変数とは別に、第1話の終了条件の変数を用意する必要があります。

つまり、「クリア条件を満たしたが、まだエピソードを終了させてはいけない」みたいな場合もあるのです。


こういう場合、どう処理すればいいかと言うと、そのエピソードの作中のトラブルなどを確実に解決した段階まで、そのイベントフラグを終了されてはいけません。

上記のボスによる誘拐事件の場合、少なくとも、誘拐された被害者の救出が達成されるまでは、けっしてイベントフラグを終了に設定してはいけません。


「ストーリー進行度」[編集]

なお、一般にゲーム用語で『ストーリー進行度』や『シナリオ進行度』という表現で、そのゲーム全体のストーリーの進行の度合いを表現することが、ゲームファンにありますが、しかし実際のゲーム業界が果たして本当にそういう変数を用意してるかどうかは不明です(ゲーム会社がソースなど非公開のため)。

ただし、もし自作ゲームの完成度がすでに高くて、開発に余裕があるなら、さらに「ストーリー進行度」に対応する変数を用意しておくと、何かと今後の編集に便利です。

なぜなら、「もしストーリー進行度が○○以上なら、このイベントが発生する」などの方法を使えるようになるからです。


ただし、実際のゲームのストーリー開発では、ストーリー内の物語の順序を開発中に、なんども(順序の)変更することがあるので、あまり開発の最初から「ストーリー進行度」に基づく設計を行わないほうが安全だと思います。


もしストーリーの順序がもう確実に決定済みで、幾つもの特殊イベントの発生順序が決まってる場合などは、データベースに「ストーリー進行度」とか「シナリオ進行度」みたいな名前のパラメータを1つ作るのも、ひょっとしたら便利かもしれません。


なお、一般にストーリー進行度の変数を作る場合、 プログラム内部的には、

ゲーム開始時はストーリー進行度が0で、物語を進めるイベントを1個クリアすることでストーリー進行度が +10 される、・・・というような仕組みで、各ストーリーを順番に実行させる、・・・といった仕組みも、伝聞ですが、ときどき聞きます。(昔のBASICの行番号でも10間隔で行番号を書いている。)


なぜ進行度の数値にこう間隔をあけるとラクかというと、もしイベントを追加して、たとえばイベントA(進行度 10番 に対応)とイベントB(進行度 20番 に対応)のあいだに後からイベントCを追加したくなったとき、たとえばイベントCの進行度を「15」とかしておけば、ラクに数値管理できます。


その他[編集]

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

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

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

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

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


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


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

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

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

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

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


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

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


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

脚注[編集]

  1. ^ 挫折しやすいゲーム開発を完成まで継続する方法について話します。 - YouTube 2020年3月17日に閲覧
  2. ^ 『企画出身だからできる開発効率の推進〜バンダイナムコスタジオのテック職に聞く異色のクリエイターキャリア論 | インタビュー | CGWORLD.jp』 2020年1月17日に閲覧

関連項目[編集]