ゲーム」とは編集ゲームと一言でいっても、この教科書では、コンピュータを用いたゲームのプログラミングを扱います。いわゆる「テレビゲーム」やコンピュータゲームについて述べます。ここでは家庭用ゲーム機か、家庭用のコンピュータで扱える範囲の事柄をここでいうゲームとし、それらのゲームソフトをつくるためのプログラミングについて扱います。解説にゲーム用語を使うので、もし用語の意味が分からなければ『ゲームプログラミング/コンピュータゲームの種類』などを参照してください。自分でゲームを作る際、必ずしも、C言語などプログラム言語で記述する必要はありません。プログラミングをせずに、ほぼマウス操作と会話メッセージなどの文章のキーボード入力だけでゲーム開発をできるようにするソフトウェアが、有料または無料で発表されています。RPGエディター』などのように、RPG製作に特化された開発ソフトがあり、大幅に開発の手間を減らせます。『RPGツクール』は有料製品です。RPGエディター』は無料ソフトです。2D格闘ツクール2nd.』や『w:アクションゲームツクール』などがあります。これらツクール製品は有料製品です。ノベルゲームを作りたいなら、フリーソフトの『w:吉里吉里Z』などがあります。吉里吉里Zはソースコードが公開されており、オープンソースになっています。「ゲーム開発ツール」と呼びましたが、じつは呼び方は特に決まってはいません。「ゲーム制作ツール」と呼んだりする場合もあります。ゲーム開発ツールのことを「ゲームエンジン」と言う場合もありますが、開発ツール以外のゲーム用ランタイムのことも「ゲームエンジン」といったりする場合があります。RPGエディター)などの類のソフトの呼び方は、まとめて「ゲーム開発ツール」または「ゲーム開発ソフト」などと呼ぶことにします。C言語などによるプログラムは、上記のゲーム開発ツールを使わない場合に、必要になる可能性があります。既存のゲーム開発ツールの仕様に、あなたが不満を感じる場合に、「じゃあ自分でプログラムして作ろう」となり、プログラムが必要になるわけです。上記の開発ツールはほとんどがWindows用のソフトです。MacやLinuxでは動かない場合がほとんどです。MacやLinuxでも動作するゲームを作りたい場合などに、プログラムが必要になる場合も多くあります。既存のゲーム開発ソフトを使わずにプログラムを組んでゲームを自作する場合、必ずしも既存のゲーム開発ツールのような、ゲーム作品と開発ツールが分離された仕組みを再現する必要がありません。いうか、そもそも初心者には、ゲーム開発ツールを作るのは、ほぼ不可能です。初心者は開発ツールを作ることは考えずに、とにかくゲームを1本、とりあえず完成させるのが優先です。ゲーム1本を完成させたあとに、開発ツールとゲーム作品の分離などに取り掛かりましょう。そもそもゲーム制作があなたの目的か?編集このページを読んでる人は、おそらくゲームづくりをしようと考えているのでしょう。このページを読んだせいでゲームづくりに関心を持ってしまうかもしれません。待って考えてください。?もしアナタが「自分はRPGがすき」だとしても、もしかしたら、よくRPGの題材になる西洋ファンタジーのストーリーの小説を作りたいだけかもしれません。アナタはもしかしたらイラストを描きたいのかもしれません。音楽づくりをしたいのかもしれません。ゲームそのものを作るとなると、そのゲームの改良に、かなりの年月の自由時間が掛かります(たとえば、毎晩、帰宅してからゲーム開発に数時間ほど取り掛かるとか)。そのため、小説の取材をしたりとか、イラスト創作の活動をしたりなどの時間が、かなり減ってしまいます。ゲーム制作では、ゲーム性のためにリアリティを犠牲にしたりなど、ゲーム性のために小説やイラストには不向きな表現も必要になります。RPGで、たった4人の主人公たちが、何百人もの敵キャラを倒したりとか、リアリティのやや乏しい表現なども、ゲームではよくあります。アクションゲームなどでも同様です。プログラム言語を使って自分でソースコードを記述していく方式のゲーム制作になってしまうかもしれません。他にもゲーム制作では、ゲームにあわないストーリーやイラスト構図などを削ることもあります。それらのストーリーや構図を削らないなら、それでもゲームを面白くしたいなら、システムそのものを改修する手間が生じるかもしれません。すると、とたんにゲーム制作に要求されるスキルがあがります。いう上述のような複雑・高度なジャンルでなくて、よくある展開でよくあるシステムでよくあるストーリーの既存ジャンルだとするならば、そもそもアナタが時間を注いでまでも作る必要があるのですか?そういう「よくある展開」「よくあるシステム」のゲームは、すでに何作もネットで無料または低価格の作品が発表されています。「単に作者オリジナルの初公開の曲があるだけのクソゲー」、「オリジナル初公開のイラストがあるだけのクソゲー」を制作したいですか?曲や絵がよければ、面と向かって「クソゲー」とは言われないかもしれませんが、しかし内心、「システムやバランスがクソゲー」と思われています。曲や絵がいいのにプレイヤーから「このゲームの○○が面白い!」と具体的に言われないのは、つまり婉曲的に曲・絵いがいがクソゲー扱いされてるということです。絵がよければゲーム公開サイトなどの紹介画面などで目立つので、とりあえず消費者・サイト訪問者に興味をもってダウンロードまたは購入までなら、多くの人に、してもらえます(広告写真と同様です。イラストには広告の役割もありますし、そもそもポスターの芸術史での歴史がそうです。音楽が良くても、なかなかダウンロードや購入に結びつかない)。2001年ごろの日本での同人ゲーム黎明期やフリーゲーム黎明期などの時代なら、実験的な時代なので異分野交流も兼ねてイラストレーターや作曲家もゲーム制作するならともかく、2010年も過ぎた現代日本で、小説やイラストを書きたい人が、無理してゲームを作る必要はないのです。ゲームは、けっしてver1.00を作って「終わり」ではなく、その後の、さまざまなアップデートが必要になる場合があります(バグ修正やバランス調整など)。バグ修正用に外注プログラマーや友人のプログラマーを雇えるならともかく、個人のゲーム製作では、そこまで雇うのは面倒です。フリーゲームなどでバグ修正しない・バランス調整しないにしても、どの程度のバグをどういう理由で修正しないで放置するとか、そういうことをユーザーに説明するコミュニケーションの手間があるでしょう。今のイラストレーター・作曲家では、たとえゲーム用に音楽やイラストを提供するなどの活動をしているクリエータでも、ゲームそのものは本人は作っていないクリエイターも今では多くいます。過去すでに実験的にゲーム制作もしていたイラストレーターや作曲家などもいましたが、しかし今では多くのそれらのクリエイターは、すでにゲーム制作を卒業してゲーム制作中止してしまい、今では彼らの多くはイラスト創作や作曲の仕事に専念しています。現代ではイラスト投稿サイトや小説投稿サイトなど、専用のwebサイトがありますので、ゲーム以外の発表場所に困ることも少なく、それぞれのジャンルの発表はそちらを利用しましょう。創作は、それぞれの分野は得意な人に任せたほうが無難です。ゲーム制作に限らず、創作活動をする場合、けっして手段と目的とを、混同しないようにしましょう。開発ツールのライセンス条件編集ゲーム開発ツールのなかには、そのツールで開発したゲームソフトに義務として「この開発ツールで開発したソフトウェアは、ソースコードを必ず公開しなければならない」などの条件をつけている場合があります。作るゲームのソース開示をしたくない場合、けっして、開示義務のある開発ツールは使用しないようにしましょう。ゲームにかぎらず、ソフト開発ツールとして使用した際などに、開発されたソース開示義務をさだめる開発ツールは多くありますので、ライセンスには気をつけましょう。ライセンスによっては「有料ソフトの販売を禁止」とか「アダルト作品の開発は禁止」などの条件をつけている場合も、ありえます。あなたはゲーム開発前に、開発ツールがどのようなライセンス条件を指定しているか、かならず確認してから、ゲーム開発しましょう。ソース開示すべきかどうか?昨今では、リナックスなどのオープンソースの発展などの背景もあり、「自作ゲームのソースコードやソースファイルも開示しよう」と思うゲーム作者もいるかもしれません。考え直してみてください。大規模ITコミュニティや欧米大手IT企業などによる管理の充実しているリナックスなどと違い、小規模ゲーム界隈では、ユーザーの中には倫理観やリテラシーの低い人も含まれており、そのため、他人のゲームを利用して誹謗中傷などの表現を行う人もいるかもしれません。他人のゲームのソースコードを使って、「なりすまし」のイタズラをする、迷惑な人もいるかもしれません。このため、ゲーム作者である自分の知名度がある程度は高くなるまでは、ソース開示をしないほうが安全でしょう。知名度の低い状態で「なりすまし」をされると、最悪の場合、作品の乗っ取りをされる可能性があります。下記の理由(機能制限および移植性の悪さ)の問題から、あまり大規模な作品は開発ツールでは作らないでおくのが安全です。コードを書いて開発しましょう。技術的な機能制限編集ゲーム開発ツールを使う場合、そのツールにもよりますが、一般的に、技術的な理由で「○○ができない」という類の制限があります。普通にある関数でも、開発ツールには無かったります。ゲーム開発ツールを使って目的の機能を持ったシステムを作れても、さらなる機能をそのシステムに追加しようとするときに、けっこう作り直しの必要が多く生じたりします。該当するデータベースなどのモジュールを呼び出しているソースファイルを、かなり作り直さなければならないような場合も、ありえますもちろん、モジュール化されているので、作り直しの部分はそのモジュールだけで済みますが、しかし、そのモジュール部分は、かなり作り直す必要が生じたりします。このような欠点のためゲーム開発ツールによるゲーム制作では、あまり大作を作ろうとしないほうが安全です。開発ツールで作る作品は、比較的に小規模な作品に、とどめておきましょう。使って、プログラム文法のいろいろな事に留意しながらプログラムを書くわけです。コードを書かずに、ほぼマウス操作だけでプログラムを作ろうとしているわけですから、何かしらの制限があります。拡張性の悪さは、プログラム文法などの学習の負担を減らすためのトレード・オフのようなものだと思って、適材適所に用途に応じて開発ツールを選びましょう。C言語などへの移植性の悪さ編集また、もうひとつの問題点として、C言語への移植性の悪さがあります。いうか、そもそもソースコードが公開されていない開発ツールの場合、異なる開発環境にゲームのソースファイルを移植するのは、ほぼ絶望的です(仮に、開発ツールのランタイムを模倣できたとしても、著作権などの法的な懸念が生じかねません)。書いたソースコードに移植しよう」とか思っても、まず無理です。ゲームのプログラム言語編集ゲームを書くために利用される言語は多岐にわたっています。歴史的にはC言語や、特に計算機のスピードが重要になる場面ではアセンブラを利用してプログラミングを行うことが普通に行われていました。現在では計算機がある程度速くなったことや、ゲームプログラムの開発を複数人で行うことでテクニカルなプログラミングが避けられるようになったことにより、ゲームプログラミングは普通のプログラミングに近いスキルとなっています。アクションゲームなどのリアルタイムでの画面書き換えが必要なゲームで、プログラムのスピードが重視されることは変わっていません。コンピュータの性能があがるにつれ、それらの性能を全て引き出すように表現手段が変化してきたため(3D、ポリゴンなどを参照)、状況によっては複雑なプログラミングが必要になることもあります。実際のゲームプログラミング編集どのようなゲームを作るときでも、ゲームプログラミングでは、ゲームが提示する内容を表示することができる。プレイヤーからの入力を扱うことができる。技術が必要になります。プログラミング言語とプレイヤーからの入力については歴史的にもあまり変化がありません。プログラミング言語ではC言語、C++などが用いられます。携帯電話向けのゲームではJavaが利用されましたが、これは携帯電話を提供する各社がJavaをアプリケーションの言語として選んだことによります(iアプリ、EZアプリ、S!アプリなどを参照)。現在ではi-OSやAndroidなどのスマートフォンOSが普及したこともあり、Javaは使われない方針です。Javaのガベージコレクタの機能がゲームプログラミングには邪魔なので、Javaがゲームプログラマーに嫌われて避けられています。パソコンゲームでは、プレイヤーからの入力にはコンピュータでは通常キーボードかマウスを利用します。他にジョイスティックやゲームパッドが利用される場合もあります。Uなどではタッチパネル、Wiiでは複数の入力機器が提供されることが発表されています。幸いにもそれらをプログラムから扱う手法はそれほど入力機器ごとにそれほど大きく変化することはありません(プログラムから周辺機器を扱う方法については、デバイスドライバ、高等学校情報Bなどを参照)。残念なことに画面を表示することのうちで3Dの表現は割合難しく、ある程度の数学(少なくとも高校卒業レベルくらい)を理解する事が必要になります。2Dに関してはプログラムの面ではさほど難しい部分はありません。プログラミング言語編集ゲーム開発において、一般にゲームショップなどで流通している商業ゲーム作品において、現在よく利用されているプログラミング言語として、C言語、C++、Javaがあげられます。これらの言語の詳細については、対応する項を参照してください。ここでは主にC言語とC++を紹介します。ネット上のフリーゲームでは、これ以外の言語が使われることも、よくあります。JavaScriptが、webブラウザで動かせるゲームを作る際に、よく使われます。歴史的な経緯により、webブラウザ用のプロググラム言語では、画像の表示や音声や動画などの取り扱いが、なるべく初心者にも簡単なように設計されてきたので、ブラウザ上で動くゲームが発表されることも、しばしば、あります。このようなwebブラウザ上で動くゲームのことを一般に「ブラウザゲーム」などと言います。ゲームプログラミングに限らず、プログラミングを行うには、プログラミング言語を習得する事が必要になります。情報科学や計算機科学などにプログラミングの理論もありますが、しかし、さいわいにも計算機科学などの専門知識について詳しく知らなくとも、プログラミングを行う事はある程度可能です。入力編集OSの種類によって、キーボード入力やマウス入力の受け付けのさいのプログラムの書き方は違う。具体的な手順は『ゲームプログラミング/入力』で説明する。場合にも入力機器の場合と同じで、これらを操作する方法はOSごとに異なっています。SDLなどのライブラリはクロスプラットフォームの画面出力を提供しているため、これらを利用することで全てのプラットフォームで動くプログラムを作ることができます。例ブロックくずし『ゲームプログラミング/ブロック崩し』で説明。『ゲームプログラミング/バランス調整』で説明する。厳密にはプログラミングの話題ではないが、しかしゲーム製作で必要な知識なので、サブページで説明する。説明書や仕様書(しようしょ)などの書き方については、『ゲームプログラミング/書類』で解説する。Studio付属のフォームデザイナ(VSの用意するGUI自動作成ソフト)によるGUIオブジェクト作成では、RPG用には使いづらい。C++で、なるべくフォームデザイナを使わずに、文字や映像を出力できるようになるのか?方法は、なんとおりかある。おおまかに、フォームデザイナをそもそも1つも使わない方式と、もうひとつは1つしかフォームデザイナのパネルを使わない方法、などがある。API』の入門書があります。)これはフォームデザイナを使わない。DirectXで入力していく方法。WindowsAPIプログラミングが元になっているので、これもフォームデザイナを使わない1つだけフォームデザイナで「パネル」という画像表示機能のコンポーネントを用意して、そのパネルで表示する画像をゲーム内のストーリーなどに応じて切り替えるだけで、すべての画像表示を行う。APIプログラミングの解説をしている場合もある)。呼び出す仕組みになっています。使って書かれていると、作者が公表しています(ただしソースコードは非公開。ウディタは非オープンソース)。誤解の無いようにいうが、ウディタを用いたRPGのプログラミングにはDXライブラリによるコーディングは不要である(そもそもウディタにはコード入力の機は無く、マウス操作や、キーボード操作はキャラ名称や会話文などのテキスト文字や数値の入力のみ)。乱数編集ゲームを作ってると、サイコロのような乱数の機能も必要になる場合が多い。機能不足であり、いろいろと不便である。数が生成されるだけなので、「1以上から6以下の整数値が欲しい」などの指定すら、直接には出来ない。すれば、rand関数でサイコロを作れる。このように、rand関数の使いかたは間接的であり、いまいち使いづらい。そこでIT業界では対策として、より直接的に乱数の範囲指定のできる等の新機能もある、さまざまな乱数関数が、のちの各種のプログラム言語で追加された。Random関数グループには、名前がrand関数と似ているが、しかし、この新しいRandom関数グループの中には「1以上から7未満の整数値がランダムに欲しい」のような指定が直接的に出来る「Next」命令がある。Random関数のこの直接指定の機能により、バグの混入率が減る。これらの命令を使うための予備的な宣言が必要であり、そっちの宣言の手間で、やや不便である。そのRandomグループに属するNext命令などを使いたい場合、サイコロのプログラムをつくるだけですら、下記のような数行のコードが必要になる。Random関数の使用を宣言しなければならない。「->」はアロー演算子というもの。画像がひんぱんに変化するアプリでは、画面が、ちらつく事がある。画面のちらつきは、ゲームのように、頻繁に画像が変わるアプリでは、かなり利便性を損なう。キャラクターが1歩移動するだけで、画面全体がチラついたりする場合もあり、かなり、プレイヤーの不満になる。これは、ダブルバッファという技術で、解決できる(日本のゲームプログラマーに「裏画面」と言われる技術を使えばいい)。Xでしか通用しない技術になってしまうので、あまり「スワップチェーン」には深入りしなくていい。Framework開発環境のC++でもC#でもダブルバッファの機能はある事になっている。いくつかのGUIオブジェクトのプロパティで、ダブルバッファの設定項目がある。Framework開発環境の公式ヘルプをきちんと整備してきてないマイクロソフト社が悪い)。APIは、古くからある開発環境のため、ネット上に情報が充実している。フォームデザイナによる開発は、頼りにならない。フォームデザイナで、ユーザーコントロールなどを使って、そこから画像書き込みをすれば、おそらくユーザーコントロールが裏画面として扱われるためか、ちらつき自体は解決できる場合があるが、しかしユーザーコントロールの使用上、グローバル変数の共有が困難だったり、アプリ内での終了コマンドが無いなどの欠点がある。グローバル変数の共有が困難な点は、ゲーム性およびゲーム開発効率を致命的に損ない、使い物にならない。困ったことに、GUIフォームの「パネル」オブジェクトに、ダブルバッファの機能が無い(もしくは不十分)。「パネル」なら、グローバル変数の共有は比較的に簡易だが、今度はダブルバッファの機能が不十分なのである。GUIフォームの「ピクチャーボックス」オブジェクトでは、関数ブロック内に書ける処理命令は、画像をクリックしたときの処理しか書けない。我々は、クリックしてない時にも画像(静止画だけでなく時には動画)を表示したいし、マウスクリック以外のキーボード操作にも画面を反応させたいのであるから、「ピクチャーボックス」は機能不足である。結局、どのGUIオブジェクトでも、ゲームのような動画を描画できない。フォームデザイナは使えない。日本でネット上で流通しているゲーム開発ソフトには、ゲーム開発用に、独自のプログラミング言語を持っている場合があります。このような機能の実現方法は、C言語で、ファイル入出力の関数を使い、テキストファイルの文字列を読み取って、文字ごとに条件分岐を設定する機能があるので、そのような機能を使って、独自の言語を作成することで、独自のプログラミング言語を作成することで可能なのです。if文で書かれた関数を呼び出せば良い)。文字読み取りの機能を使って、独自のプログラミング言語を作ることができます。いうか、そもそも、C言語以外のプログラム言語の、プログラム言語そのものの作成方法は、このようにして作成しています。そもそも、C言語以外のコンパイラやインタプリタというのは、このような方法で作られています(なお、C言語そのもののコンパイラを作りたいなら、OS作成時にアセンブラ言語を使って、文字読み取りの関数を作って、C言語を作ればいい)。ときどき、ゲーム製作ソフトなどで、独自のプログラミング言語を使用している場合があります。コンパイル作業を必要としないので、そのようなソフトは、インタプリタ方式でしょう。いうマイクロソフト社の配布しているソフトがないと、通常は、コードの実行ファイルへの変換は不可能です。開発環境を提供していない独自言語は、(その言語開発者が、よほど技術力が高度でないかぎり、)たいてい、その独自言語の実行方式はインタプリタ方式となります。総論編集ゲームにかぎらず、一般にソフトウェアのバグを取り除く修正のことをデバッグといいます。ゲームのデバッグのためには、まずバグを発見する必要があります。すべての潜在的なバグを発見するのは、人員の限りや時間の限りがあり、ほぼ不可能です。製作者は、プレイヤーのよくやる行動をゲームプレイで再現してみて、そして遭遇したバグから直しましょう。RPGで、薬草の使用をキャンセルするのを20000回連続で続けると遭遇するバグがあったとして、もし製作者がそのバグを直しても一般プレイヤーは気づきません。1960年代のような古いコンピュータのデバッグ方法と、現代のデバッグ方法は違います。パソコン黎明期の科学計算のデバッグやファミコン黎明期(1980年代)のゲームのバグの探査方法と、現代の廉価or無料のパソコン用ゲームのバグの探査方法は、微妙に違います。アセンブラなどをいじくる必要のあったテレビゲーム機の黎明期の時代のバグ発見の方法は、現代では、あまり向いていません。現代のゲームでは、バグ修正は、ネットワーク通信ゲームなら、公開後にもネット経由でアップデート修正することもできます。有料ゲームでも、販売前に体験版などを配布してプレイヤーにテストプレイしてもらう事で、プレイヤーの遭遇しやすそうなバグを探せます。ゲームでなく、たとえば自動車用の組み込みプログラムや、あるいは工作機械などの組み込みプログラム組み込みなどのバグ探索ならば、バグが人命の死につながりかねないので、たとえば、電源ケーブルや通信ケーブルなどの抜き差しをしたりとか不安定な状態にしてバグを探したりとか、温度をあげたり下げたりとかまでしたりとか、そういうハードウェアとの関連のありそうなバグも様々な方法で徹底的に探します。現代のゲーム開発では、そこまでしてバグを探す必要は無いでしょう。いったハードウェア関連のバグは、OSメーカーやあるいは業務用の組み込み機器メーカーなどが探すべきバグです。PC用ゲームメーカーの探すべきバグではないです。新発売されたばかりの新ハード用の対応ゲームをハードメーカーやOSメーカーが制作しているならともかく、既存のパソコン用の無料ゲームや廉価ゲームなどでは、そこまでしてハード関連のバグを探す必要は無いでしょう。優先順位づけ編集ともかく、ゲーム産業にかぎらず一般のIT業界でも、発見されたバグは、修正の優先順位にもとづいて格付けをされます。医学における、どの患者から先に治療すべきかという概念である「トリアージ」という医学用語になぞらえて、IT業界でもバグの修正対応の優先順位(priority)の格付けのことを外国でも「トリアージ」と言います。このことは、ゲーム作家の側には「トリアージ」などの用語の暗記は不要ですが、どちらかというとプレイヤーのテスト協力者などに考え方を知ってもらう必要があるでしょう。科学者が科学計算ソフトウェアで世界最先端の開発を目指すのなら、(予算が国から与えられる限り)好奇心や興味のおもむくままに研究して、「トリアージ」の概念を無視するのも可能かもしれません。一般のIT産業やゲーム開発では、予算の制約が厳しく、人員や設備の制約も厳しく、そうはいかないので、「トリアージ」的な優先順位づけが必要になります。(25万)にもなってします。すべての組み合わせを検証しようとすると、作業が指数的に増えてしまいます。こんなに多くの組み合わせを検証するのは個人では無理ですし、無駄です。デバッグ検証はせいぜい、武器なら100種類の装備をすべて装備してみて、装備できるキャラクターが装備しても異常が無いかとか、戦闘で実際に攻撃を見て以上が無いかとか、そういうことを確認すればいいのです。同様に、防具のデバッグ検証もそうです。これなら、装備の検証作業は、100+50+50=200種類なので、大幅に作業が減ります。足し算、加算的に検証すれば、十分です。実際の市販のRPGなら、さらに装備の数が多くなるでしょう。どのキャラクターが装備するかとか、どこのエリアで装備するかとか、いろいろな組み合わせが実際のプレイにはありますが、もちろん、そんな検証をすべてするのは無理で無駄です。異なるジャンルのたとえばアクションゲームやアドベンチャーゲームなどのゲーム内の各種システムでも同様です。デバッグは、ゲーム内の各種のアイテムやコマンドなどのデバッグなら、せいぜい、とりあえず、そのアイテムやコマンドなどを選択したり実行しても異常が無いかを1回だけ試せばいいのです。そもそも、ゲームのシステムは基本的に、プレイヤーごとに異なる多様なプレイスタイルに対応するために多くのアイテムやパラメータやイベントをゲーム内部に持っていて、そういった組み合わせの意外性などをシミュレートして楽しむものです。組み合わせは膨大になるのが普通なので、全組み合わせの掛け算的な回数の検証は無理です。テレビゲーム黎明期の1980年代なら、装備アイテムの数などが少なかったので、もしかしたら組み合わせをすべて試すのも可能だったかもしれませんが、しかし現代では、アイテムの数などは膨大に増えており、もう無理です。このため、現代の複雑化したゲームではver1.00以降の発表後にも、アップデート修正が必要になる可能性が高いです。ver1.00の発表前に事前にアップデート版の配布が可能な環境を整えておきましょう。有料ゲームのアップデート配布の場合なら、なるべく有料版ソフトを買った人だけに、無償でアップデート適用ずみのフルパッケージ版を配布できるような環境があるかを事前に環境準備しておく必要があります(「修正パッチだけ無料公開」とかではなく、すでに修正パッチを適用した状態でのフルパッケージ版という意味。消費者が有料で購入しているのだから、修正パッチ適用などの手間を掛けさせない。そもそも、修正パッチを適用するのにソースファイルが必要な場合が普通なので、普通はメーカー側で修正パッチを適用してから配布する)。個人でそういう配布の環境を構築するのは困難なので、個人の場合には、ネット上のいくつかの企業がソフトウェア公開・販売環境を提供している企業がいくつかあるので、そのサービスを利用すると良いでしょう。アップデート版のソフトウェア内部のシステムでは、過去バージョンの有料ゲームから、最新の修正後バージョンへのプレイデータの引継ぎをできるようにする必要があります(たとえばRPGの場合、プレイヤーにレベル1の序盤から再開させるワケにはいかない)。このデータ引継ぎの工夫は、ソフトウェア販売サービス提供の企業では無理なので。上述のようなアップデート配布が不可能な環境にあるのなら、そのゲームが個人製作のゲームの場合には、無料ゲームソフトにしておきましょう。ゲームにかぎらず一般に有料ソフトを販売した場合には、開発元のメーカーは「保証期間」または「アフターサービス」のような社会的責任として、発売開始後から数年ていどは無償で不具合対応などのアップデートをすべきという社会的な責任があります。食料品やティッシュペーパーのような消耗品でないかぎり、ソフトウェアにかぎらず一般の工業製品などでも企業は商品の有料での販売においては、発売開始後から数年は、「保証期間」などとして無償または低価格の不具合対応などの社会的責任が要求されます。無料のソフトではそこまで保証する義務は無いですが、まあ実務の練習だと思って「保証期間」的なものも頭の片隅に意識しておいたほうが無難でしょう。作者用のソースファイルにデバッグ用の機能をいくつか入れておく方法もあります。」のようなメッセージ)を表示するモニター的な機能は、こちらソースファイル側で行うとよいでしょう。プレイヤーが細かいシステムメッセージを見ても退屈ですので。テストプレイで挙動のオカシイ部分があったら、そこで、ソースコードで、挙動のおかしい箇所のプログラムの近辺で、変数の内容を表示する機能のあるモニタープログラムを自分で書きます。ブレークポイントという、デバッグ用にコード中に強制停止するポイントを設定する機能があり目的の箇所でコードを停止させ、変数を表示させる機能がありますが、しかしこの機能(ブレークポイント)をいきなり使うのは、ゲーム製作では、あまりオススメできないです。ゲームが止まってしまうので、実際のプレイ中でのパラメータの変化が不明です(ブレーク時点での変数の値しか、分かりません。ブレークポイントを使う場合は、起動そのものの不可能なバグとか、ゲームが異常停止していまうようなバグの場合などの、テストプレイそのものが困難な重篤なバグの場合にだけにしましょう。テストプレイが可能なていどのバグなら、なるべく実際にゲームをテストプレイして、モニタープログラムでバグの性質をさぐったほうが早いです。モニタープログラムは最小限にするのがコツしかし、まだバグの見つかって無い段階で、モニタープログラムを入れるのは、オススメできません。ソースファイルが見づらくなるからです。バグが見つかってから、関連しそうな変数を表示するモニタープログラムを書きましょう。モニタープログラムは最低限にするのがコツです。バグが修正し終わったら、そのモニタープログラムのコードは、量が多くなってきたら場合は、さっさとソースコードから該当する変数のモニタープログラムをコメントアウトするなどして、非表示にしてしまいましょう。なんでもかんでもシステム内メッセージを画面に表示したとしても、メッセージを読みきれないので無理です。ソースファイル独自の機能を追加しすぎると、一般にソースコードじたいが読みづらくなります。デバッグルームなど編集デバッグルームとは編集ゲーム内でめったに起きないイベントなどのデバッグは、通常のプレイ方法では、めったに遭遇しないために発見が困難になります。ゲーム内でくじ引きがあり、1000分の1で大当たりが出るとしましょう。通常のプレイでは、このくじ引きを1回だけしか出来ないとしましょう。このようなイベントのデバッグ検証の場合、「大当たり」にバグがないかは、デバッグ用に、ゲーム作者だけ、くじびきを何百回も続けてチャレンジできるようにしたりとか、あるいは、ゲーム作者だけ、くじ引きの結果を操作できるようにして強制的に「大当たり」が出たりするようにするとか、そういう作者だけの特殊システムが必要になります。一般プレイヤーには、デバッグルームには入れないように、対策する必要があります。このような、デバッグ用の作者専用システムのことを、俗にゲーム業界では「デバッグルーム」とか「デバッグモード」とかいいます。デバッグルームとは「デバッグの部屋」という意味です。作品によっては、実際にゲーム内に「デバッグルーム」というエリア、ステージを用意する場合もあります。この機能を作者が使うことを「デバッグルームに入る」とか「デバッグモードをオン(ON)にする」いいます。名前こそ「デバッグルーム」や「デバッグモード」などというものの、ぢかし、その場所ではバグそのものの退治・修正はしないですし、そもそも、ゲーム起動中にバグ修正は不可能です。最終的にバグを修正するには、(ゲームをシャットダウンさせてから)ソースコードを開発ツールなどで直す必要があります。「デバッグルーム」とは、単にゲーム内でバグ探しの作業をしやすいように、プレイヤーキャラクターを強化したり、あるいは敵を弱体化させるなどの環境を調整するだけなのが、デバッグルームです。背景として、基本的にはプレイヤーキャラクターが強めのほうが、ゲーム内世界をいろいろと探検しやすいのでバグは発見しやすくなります。ゲームでは、たとえばRPGでゲーム終盤の強敵を倒したときに発生するバグなどは、主人公がゲーム序盤の弱いキャラクターの状態では無理です。ゲーム序盤の弱い敵に主人公が負けるなら、単に油断したり無防備になればいいだけなので、主人公は強いままでもデバッグ可能です。「大は小を兼ねる」といいますが、ゲーム内では強めのキャラは弱めのキャラを兼ねます。デバッグ用の機能の名前に「デバッグルーム」などの名前がついていなくても、もし裏技や隠しアイテムなどでプレイヤーを強化するものがあれば、実質的にデバッグモードでしょう。ゲームクリア後に、初回プレイよりも強い状態でニューゲームを出来る機能があれば(いわゆる「強くてニューゲーム」)これも実質的にデバッグ機能して活用できます。ゲーム序盤~前半のイベントに潜むバグなどを探すには、「強くてニューゲーム」のような機能があれば便利でしょう。プレイヤーによっては、「デバッグ」などのIT用語を嫌がる人もいるので、そういうのに気をつける必要もあります。ゲームのジャンルによって、近未来SFファンタジーやSFアクションなどでは、ゲーム中のシナリオにもIT用語が出てくるので、そういうのと区別するために「裏技」などの言い換えをしたほうがいいかもしれません。デバッグルームの建築編集さて、デバッグルームを建築する際は、なるべく、既にそのゲーム内にあるシステムを流用します。一般プレイヤーにも公開されている機能を組み合わせてルームを作る必要があります。しないと、デバッグルーム独自機能の検証の手間が増えてしまうので、かえって、メンドウになってしまいます。デバッグルームの中では、普通のプレイヤーが操作できないものを操作できるようにします。RPGなら、プレイヤーキャラのレベルをある程度の上昇させたり下げたりとか、主人公の入手している武器や防具ある程度の範囲でを操作したりとかの機能が必要です(けっして、完全に数値をピッタリ調整する必要はないです。最終目的はあくまでバグ発見です。数値をピッタリと調整することは目的ではないです)。RPGなら、たとえば、強めの武器や防具をいくつかデバッグルーム内においておいたりとか、あるいは、通常プレイでは商店では非売品の武器・防具をデバッグルーム内では有料(ゲーム内の通貨)だが販売しておくとかすれば、万が一、一般プレイヤーがデバッグルーム内に進入してしまっても安全です。デバッグルーム内に、経験値アップや、レベルアップなどのアイテムとかをいくつか置いておくと、レベル上げの手間が減ります。このようにデバッグルーム内に強化システムを配置しておくと、ゲーム後半のイベントなどの検証も、ラクになります(キャラクターの育成などに掛かる時間などが短くなるので)。くじ引きの「大当たり」などのイベントをデバッグ検証で容易にしたいなら、デバッグルーム内に、たとえば「幸運のお守り」のような感じのアイテムを置いておいて、それを装備すると、ゲーム内のくじ引きなどの大当たりの確率が100%になるとか50%になるとかの機能をつけておいて、そういうふうなアイテムを作っておけば、くじ引きなどの検証がラクになります。一般プレイヤーには、デバッグルームには入れないように、対策する必要があります。作者のファイルにだけ、デバッグルームに入れるアイテム(「デバッグルームの鍵」など)とかを設置するとかして、実装します。一般プレイヤーに配布するゲームデータには、デバッグルームの鍵などを与えないようにします。デバッグルームの場所は、ゲーム内の中盤や後半に隠して立てておくと安全です。隠すのではなく正式な公開機能として、ゲームクリアしたプレイヤーに、デバッグルームの一部を開放するなどする方法もあります。すると、あまり気にやまなくても済みます。ゲーム開始のオープニング画面中に、画面には表示されてないが実はパスワード入力を受け付けしている状態を起動させておいて、パスワードが正しければデバッグモードがオンになった状態でゲームを開始できるようにするとか、そういう方法もあります。パスワードの受付をしているのを、プレイヤーには見せないようにします。アクションゲームなど、あまりRPGのようなアイテム配布をしづらいようなシステムの場合は、この裏技のような方法のほうが便利でしょう。裏技システムの場合、もし一般のプレイヤーがたまたまデバッグルーム用パスワードと同じキー配列を入力しないように、パスワードは十分に複雑にしておくとかの工夫が必要です。万が一、パスワードを運よく一般プレイヤーが知らずに偶然に入力してしまってゲームを開始した場合でも、プレイヤーがゲームプレイを楽しめるように、「これは裏技モードです」とかとでも冒頭で紹介しておいて、プレイヤーキャラクターの強さを(通常モードと比べて)やや強めに変更するくらいの設定にしときましょう。1980年代のファミコンなどの市販ゲームで、こういう「裏技」(うらわざ)がよくあります。そのソフト開発者がデバッグ用に残した機能だったのでしょう。関数のテキストファイル書き込み機能で、簡単にセーブ機能を実装できる。ゲーム用のセーブファイルを作成できる。GUIなゲーム用のセーブファイルを作成できる。プログラム内容も、セーブで保存したい内容を、単にテキストファイル形式で書き込めばいいだけである。ロードも、単に、書き込んだ内容を、fopenの読み込み機能でセーブデータをゲームに読み込んで、読み込み内容に従ってゲーム中の変数に適切な数値を代入させればいいだけである。テキストファイルでセーブを書き込んだ場合、数値などは単なるテキスト文字として保存されるので、ロードの際にはC言語のatoi関数で数値に変換する必要がある。機械語でセーブファイルを作りたい場合は、既存のファイル形式(画像ファイル形式や音楽ファイル形式など)の機械語の形式に機械語ファイル識別子などが、かぶらないようにする必要があるので、作成の難度がやや高い(機械語のファイル冒頭には、ファイル識別子の情報がある)。一応、もし既存のファイル形式に識別子が重なってもC言語プログラムで読取も書き込みもできるが、あまり推奨できる設計ではない。万が一、それが原因で不具合が起きてもプログラマーの自己責任である。市販のパソコン用ゲームや同人ゲームなどだと、テキストファイルでなく機械語で保存されているゲームも多い。ゲーム開発ツール側じたいが、そうなっている場合もある。RPGツクールもウディタも、セーブデータの形式は機械語である。分かるかというと、ツクール製ゲームのセーブデータを、なんらかのLinuxデスクトップ上でセーブファイルをオープンすると、ファイル内容がいくつもテキスト文字として認識せずにエラー報告されるからである。ウディタの場合、そもそもLinux上ではテキストエディタではオープン不可能か、なんとか開けても、やはり中身がテキスト文字として認識されずにエラー報告されるからである。好まれていないようだ。暗号化について、たとい機械語でセーブ内容を書き込みをしてもバイナリエディタなどで読み込めば中身を読めてしまうので、ソースコードの内容を機密にしたい場合は暗号化が必要である。特殊イベントのフラグの作り方編集RPGなど、ゲーム中で一回しかおきない特殊なイベントとかを作りたい場合があるでしょう。RPG以外でも、シミュレーションゲームなどで特殊イベントを実装したいこともあります。日本の中世の戦国時代シミュレーションゲームで「桶狭間の戦い」が3回も起きたりしたら困ります。RPGの場合、1人しかいない中ボス敵(生物)を倒して殺すイベントは、1回しか起きなくては困ります。中ボスを殺すと、大ボスの居城に行けるようになるストーリーだとしましょう。中ボスを倒していないとする)。いうイベントの判定などの処理のために使う変数のことを、ゲーム業界用語で「フラグ」といいます。あとはif文などで、フラグ変数をもとに、イベントの発生の有無を判定するシステムにすればいいだけです。ツクールとかウディタとか、ああいうゲーム開発ツールでは、こういう特殊イベントのフラグ処理をどうやって実装しているのでしょうか?ツクールなどの幾つかの開発ツールでは、「データベース」という項目があり、じつはこのデータベースを作者に使わせて、フラグ変数を代用させる仕組みです。RPG開発ツールの「データベース」は、武器やモンスター名などのデータベースでもありますが、イベントフラグにも流用されます。RPGツクールやウディタなどでは、けっして、わざわざイベント専用の変数項目は用意されておらず、代わりにゲーム作者が自由に作成できる変数項目がいくつかあるので、それを組み合わせてゲーム作者が自分で作る必要があります(RPGツクールの場合、アイテム用データベースのなんらかの特殊アイテム所持数をイベントフラグとして流用するのが簡単でしょう。ウディタの場合、特に目的の定められていない「可変データベース」で目的の定まってない変数が作成できるので、それのいくつかをイベントフラグとして流用することになるでしょう)。「戦闘中のボス敵のHPが半分以下なら、○○のイベントが起きる」などのイベントを実装したいゲーム作家さんもいるので、けっしてイベントフラグ専用の変数を、いちいちツクール開発企業(現在は角川書店、もともとはアスキー)は用意してくれません。用いないでゲーム開発ツールが変数を作る方法の実装手段は、一番簡単なのは配列を用いて実装する方法だろう。配列を流用しているだけなので、ゲーム開発ツールでは作成できる「変数」の要素数に限りがある。ツクールやウディタでも、作成した変数にはid番号が1番(または0番)から順についており、このid番号を通じてイベントなどを制御する仕組みである。id番号が、配列の要素の番号であろう。ゲーム中にイベントを挿入するさいに、データベース中の指定した項目の数値を参照して、その数値が「○○に等しいか?」「○○以上か?(以下か?)」などの条件判定をして、条件が真なら、真の場合の処理を実行するという、単純な仕組みです。どのマップにも固定敵とのバトルにも、イベントを挿入できる仕組みになっていますので、作者は必要に応じて、どのマップでも固定敵バトルでもイベントを起こせるのです。読者のあなたが(RPGツクールやウディタみたいな)ゲーム開発ツールそのものを自作したいなら、RPGの戦闘システムやマップシステムに加え、こういったデータベースを流用したイベント管理フラグを実装すればいいわけです。C言語でデータベース的なものを構築する方法なら、いわゆる「構造体の配列」または「配列の構造体」というもので簡単に実装できます(wikibooksでも『C言語/構造体・共用体』で解説しているでしょう)。構造体の配列は、情報系の専門学校や大学の情報系学科などでも普通に習う、ありふれた手法です。配列のほかにもデータベース的なものの構築方法はあり、テキストファイルなど外部ファイルに書き込みをして入出力する方法でも、データベースを構築できます。C言語のfopen関数で、簡単にファイルに読み書きできます。作成するテキストファイルを隠しファイルにしておけば、ユーザーが書き換えする心配も減らせますし、もし書き換えてしまってもユーザーの自己責任です。指定すれば、隠しファイルを作成したりできます。CSV形式(シーエスブイけいしき)という書式のテキストファイルによるデータベースは、ゲーム業界にかぎらず、一般のIT業界でもよく使われる方法です。配列だとデータ数が多い場合にメモリを圧迫する可能性があるので、もし自分でゲーム開発ツールを造る場合は、データ数がとても多い場合には外部ファイルに入出力するのも、ひとつの解決策です。テキストファイル読み書きでデータベースを構築する方式の場合、マップ入場時など場所の切り替え時に、読み込み時間が少し掛かります。テキストファイル読み込み形式のデータベースでも、読み込んだデータを処理するために配列や構造体をいくらか使用しますので、どちらにせよ知識として配列などの知識は必要です。テキストファイルなど外部ファイルを読み書きする場合、データベースが外部出力されるのでユーザーがデータベースの中身を閲覧可能になりますので、機密性などは下がりますし、それでもデータベース内容を機密にしたい場合は暗号化などの手間が掛かります。自分でゲーム開発ツールを造る場合は、作りたいゲームにあわせて、配列方式か外部ファイル読み書き方式か、データベースの方式を選びましょう。どちらの方式にせよデータベースによるプログラミングは、まるで、昔のアセンブラによる変数の実装でメモリ番号の指定による実装を、代わりにC言語の配列の番号またはテキストファイルなどを用いて擬似的に実装したかのような方法です。一応は、ツクールのような方法でも、利用できる変数の個数が足りるかぎり、ほぼ、どんなイベントでも作れます。欠点として、まるで擬似アセンブラみたいな実装方法なので(より正確に言うなら、配列による擬似メモリマップか。メモリマップについては『オペレーティングシステム#メモリマップ』で解説)、当然ですがC言語のような構造化プログラミングの洗練された手による支援は、ゲーム開発ツールによる上述のようなデータベース駆動型のプログラミングでは、ほぼ見込めませんので、このためソースファイルの内容が、第三者や後日の自分が見て内容の分かりりづらい、いわゆる「スパゲティコード」のようなソースファイルが作られやすくなります。ひとつの配列を、番号ごとにゲーム内の異なる様々なイベント処理のフラグとして流用するわけですから、「どの番号がどのイベントに割り当てしているか?」などを作者は把握しておかなければならず(いちおう、番号ごとに変数名をつければ暗記しなくてすむが)、管理がメンドウになります。データベースを使わずにC言語で直接にイベント処理を記述するなら、普通は異なるイベントには、異なる配列を宣言して作成するわけですので、番号の割り当ての把握は不要になります。メンドウになってきます。幾つもの特殊イベントの発生順序が決まってる場合などは、データベースに「ストーリー進行度」とか「シナリオ進行度」みたいな名前のパラメータを1つ作って、「もしストーリー進行度が○○以上なら、このイベントが発生する」などの方法をとる場合もあります。あるイベントをクリアすることで、ストーリー進行度が+1される、というような仕組みで、各ストーリーを順番に実行させる、・・・といった仕組みも、ゲーム開発で、よく聞きます。ストーリーの分岐などをする場合は、シナリオ進行度をまるでBASICの行番号の分岐のように使って、選択肢などの結果に応じて(ラベル的に)ストーリー進行度をジャンプさせることで、分岐を実現したりもします。ノベルスクリプトなどでは、こういった仕組みによるイベント実装も、多いかもしれません。上述の組み合わせ、つまりデータベース変数によるイベント判定と、ストーリー進行度によるイベント判定などの組み合わせなども、考えられます。ゲーム作者は必要に応じて、適した方法を使いましょう。フリーゲームや同人ゲームにかぎらず、大手ゲーム企業の開発する一般の商業ゲーム(テレビなどで宣伝されるゲーム作品)でも、イベント部分の記述は、エンジン部分を担当するC言語系統のゲームエンジンおよびそのエンジン用言語とは別のスクリプト言語(たとえばpythonやLuaなど)をもちいて(イベント部分のプログラムを)記述するのが普通だとされています[1]。ゲームエンジンの多くはC言語系統のコーディング環境である。EngineはC++系統の環境である。自作ゲームがある程度の完成度になるとデータベースを分離する作業に取り掛かることになる。セーブ&ロードの機能が自作ゲームで実装してあれば、単に、そのセーブ&ロード機能を流用して、データベースの外部ファイルの入出力機能も作れてしまう。この設計の場合にラクな手順としては、データベース分離の当初の段階では、けっしてデータベース編集ソフトとかを別系統では作ろうとせずに、まずは自作ゲームそのものにデータベースの入出力機能を組み込むことである。(イメージ的に言うと、ファミコンソフトの『w:ロードランナー』のステージ自作機能みたいに、自作ゲームに組み込むとラクである。)まず外部ファイルに出力(エクスポート)外部データベース入出力では、まず外部ファイル出力の機能のほうから作り始めたほうが、既存のコードが流用できるのでラクであろう。自作ゲームがある程度はプレイ可能な状態なら、すでにコード内に配列や構造体などでコードがある段階なので、あとは、そのコードの配列変数などの内容の数値を、自分で決めた書式の順番どおりに外部ファイルにCSV形式などお望みの書式(自分で書式を決めていい)で出力すればいい。(CSV形式の読み込み方法のコードの作り方は『C言語/ファイル入出力』で説明してある。)ついつい、外部ファイル取り込み(インポート)のほうから作りがちであるが(既存のゲーム製作ツールのユーザー視点だと、こうなりがっち)、しかし、外部ファイル出力(エクスポート)側から作ったほうがラクであろう。セーブ&ロードの機能がすでにあるなら、エクスポート機能の製作では、そのセーブ機能のコードを流用すればいい。外部ファイルからの読み込み(インポート)そして次に外部ファイルを読み込めばいい。インポートでは、さきほどのエクスポートの作業を逆にして、ロード機能のコードを流用すれば、簡単にインポート機能を作れる。データベース編集機能を作りたければ、上記のインポート&エクスポート機能に、エクスポートの際の書き換えの指示などを出せば済むだろう。3.0のもとで利用可能です。プライバシーデスクトップ。