ゲームプログラミング

ゲーム > ゲームプログラミング
工学 > 情報技術 > プログラミング > ゲームプログラミング

概観

このWiki参考書では、コンピュータを用いたw:ゲームのプログラミングを扱います。つまり、いわゆる「テレビゲーム」や、コンピュータゲームに関する記述についてです。

ここでは家庭用のパーソナルコンピュータで扱える範囲の事柄、それらのゲームソフトをつくるためのプログラミングについて議論します。必要に応じて家庭用ゲーム機の話題にも触れますが、あくまで派生的なものです。本書はプログラミングの教材であるので、大多数の読者が最初にプログラミングで触れるであろうパーソナルコンピュータでのプログラミングを、特にことわらないかぎりは想定しています。

用語に関して、コンピューターゲームの世界独自なものもあるでしょうから、適宜『ゲームプログラミング/コンピュータゲームの種類』などを参照してください。

本書の目的

本書はゲームクリエイターではなく、たまたま何らかの理由でゲームを作っているプログラマーのために、プログラミングによってゲームを作るための技術の参考資料として執筆されています。したがって、取り上げる話題はゲームとは関係の少ない一般IT企業での仕事のしかたについての記述もあれば、製造業系の組込ソフトなど、かなりIT系やテクノロジー系の話題に片寄っています。たとえゲーム会社を退職しても、他の一般IT企業に転職してもプログラマーとして応用できることなども目指して本書は書かれています。本書で紹介するクリエイター論やデザイン論は、派生的なものにすぎません。

本書を扱う上での注意点

特にことわりのないかぎり、本書ではC言語でのプログラミングによってゲームを作りたい読書を念頭に説明しています。そのため、現実的には本書で紹介する手法よりもRPGツクールといったゲーム開発ツールの使用を使ったほうが早い状況も存在することを留意してください。

その他、本書について

本書「ゲームプログラミング」は「プログラミング」の一部として運用されており、具体的なゲームづくりへの応用の指南を目的に執筆されました。各プログラミング言語の詳細な情報については、『C言語』や『Java』やなどの教科書のほうが（実際に動作するコードの量が）充実しています。また、Visual C++ での画面出力については『Windows API』に入門的な説明があります。

本書『ゲームプログラミング』は現状、プログラマー目的以外には対応できないかもしれません。もしプログラマー目的以外の無料のwiki教科書が欲しい方は、現状では、自分で本wikiに加筆するか、あるいは本書『ゲームプログラミング』とは別に新規Wiki執筆を検討していただきたい。

ゲームプログラミング/心構え

ゲーム制作に関する留意点

IT的な留意点

プログラミングなしでも同人ゲームを作れる

自分でゲームを作る際、必ずしも、C言語などプログラム言語で記述する必要はありません。プログラミングをせずにほぼマウス操作と会話メッセージなどの文章のキーボード入力だけで、ゲーム開発をできるようにするソフトウェアが有料無料問わず発表されています。

たとえば、RPGを作りたいなら、日本で発表されているソフトでは、『w:RPGツクール』(有料)や『w:WOLF RPGエディター』(無料)などのように、RPG製作に特化された開発ソフトがあり、大幅に開発の手間を減らせます。アクションゲームを作りたいなら、『w:アクションゲームツクール』(有料)があります。（かつて『w: 2D格闘ツクール2nd.』というのがありましたが、しかし現在ではサポート切れのため、今現在の市販の十字キーコントローラーが初期設定では動かない、一部のボタンしか使えないなど問題点があります。）また、ノベルゲームを作りたいなら、フリーソフトの『w:吉里吉里Z』などがあります。吉里吉里Zはソースコードが公開されており、オープンソースになっています。

上記のようなゲームを制作するためのツールを本書ではまとめて「ゲーム開発ツール」または「ゲーム開発ソフト」と呼ぶことにします。このようなツールを「ゲームエンジン」と呼ぶ場合もありますが、開発ツール以外のゲーム用ランタイムのことも「ゲームエンジン」と表記する場合があります。

C言語などによるプログラムは、上記のゲーム開発ツールを使わない場合の選択肢になるでしょう。既存のゲーム開発ツールの仕様に不満を感じる場合に、「じゃあ自分でプログラムして作ろう」となり、プログラミングが必要になるわけです。また、上記の開発ツールはほとんどがWindows用のソフトです。MacやLinuxでは動きません。MacやLinuxで動作するゲームを作りたい場合にも選択肢の一つとして挙がります。

既存のゲーム開発ソフトを使わずにプログラムを組んでゲームを自作する場合、必ずしも既存のツールのような、ゲーム作品と開発ツールが分離された仕組みを再現する必要はありません。一般的に初心者が、ゲーム開発ツールを作ることはほぼ不可能です。初心者は開発ツールを作ることは考えず、1本でもゲーム自体を完成させてみましょう。開発ツールを自作したいのなら、まず先にゲーム1本を完成させたあとに、あとから開発ツールとゲーム作品の分離などに取り掛かるのが推奨です。

その他気をつけたほうが良い点などは/ゲーム開発ツールを参照してください。

商業ゲームの開発言語

基本的に、現代の商業ゲームは、C言語で開発をする。ただし、ファミコンの古いゲームは、アセンブラで開発されていた。ファミリーコンピューターからスーパーファミコンに至るまで、OSは搭載されていない^[1]。

ではいつからC言語がゲーム開発に使われるようになったかというと、商学の学説では、プレイステーション（※ おそらくプレステ1？）の頃からだろう、と考えられている^[1]。ただしこの時代でも、処理速度の高速化のためにアセンブラにアクセスする開発チームも少なくなかった^[1]。また、プレイステーションのOSは独自仕様である^[1]。

カプコン（ゲーム会社のひとつ）など一部の企業は、OSによる開発ではなく、移植性を高めるために自社製の内製フレームワークを用いて開発する。カプコンの場合、2010年頃は「MTフレームワーク」という自社製フレームワークを用いて開発を行っていた^[1]。なお2020年代の現在、カプコンでは後継の別フレームワーク（カプコン内製）を使っている^[2]。

ゲーム用のメーカー独自プログラミング言語について

ゲーム開発ソフトには、ゲーム開発用の独自のプログラミング言語を持っている場合があります。このような機能の実現方法は、原理的には、ファイル入出力の関数を使い、テキストファイルの文字列を読み取って、文ごとにプログラム動作を設定・実行している、と、考えられます。インタプリタは、このような方法で作られています。

ゲーム製作ソフトでの独自のプログラミング言語はたいてい、コンパイル作業を必要としないので、おそらくインタプリタ方式でしょう。

基本的にWindowsの場合、実行ファイルに変換するには、Visual Studio というマイクロソフト社の配布している開発環境が必要です。

Visual Studio が開発環境を提供していない独自言語は、たいてい、インタプリタ方式となると思われます。

コンパイラ方式に比べて、インタプリタは処理速度が不利なので、適用できるジャンルや用途が限られます。たとえば3Dアクションゲームには、インタプリタ方式は不向きでしょう。

これらの独自言語を使うにしても、自分自身で独自言語を作りたいと思うとしても、この教本ではまず、既存のプログラミング言語を使ってゲーム制作を開始することを推奨します。

ゲームのプログラム言語の歴史

ゲームを書くために利用される言語は多岐にわたっています。歴史的にはゲーム業界でも、C言語や、特に計算機のスピードが重要になる場面ではアセンブラを利用してプログラミングを行うことが普通に行われていました。そのため、ゲームプログラミングは通常のプログラミングと違った技能が必要であるように思われていました。

現在では計算機がある程度速くなったことや、ゲームプログラムの開発を複数人で行うことでテクニカルなプログラミングが避けられるようになったことにより、ゲームプログラミングは他の一般のプログラミングと同じような課題だと見なされています。

しかし、特にアクションゲームなどのリアルタイムでの画面書き換えが必要なゲームで、プログラムのスピードが重視されることは変わっていません。また、コンピュータの性能があがるにつれ、それらの性能を全て引き出すように表現手段が変化してきたため（3D、ポリゴンなどを参照）、状況によっては複雑で特殊なプログラミングが必要になることもあります。

初心者が使えるプログラミング言語

ゲーム開発において、一般にゲームショップなどで流通している商業ゲーム作品において、現在よく利用されているプログラミング言語として、C言語、C++、Javaがあげられます。

Windowsの3DエンジンのDirectXは、主にC++を想定しています。なので負荷の高いアクションゲームを作りたい場合、Visual C++での開発が安全でしょう。

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

さいきんゲームエンジンとして有名なUnityは、言語としてはC#の文法を採用しています。

携帯電話向けのゲームではJavaが利用されましたが、これは携帯電話を提供する各社がJavaをアプリケーションの言語として選んだことによります（iアプリ、EZアプリ、S!アプリなどを参照）。現在でもAndroidなどのスマートフォン向けでは、Javaが使われています。

市販の書籍では、Pythonによるゲーム開発を紹介した出版物もあります。ただし Python は原理的にインタプリタ方式であるために処理速度がC++に劣り、アクションゲームなど負荷の高いゲームを作る事を目指している場合は、将来的にはPythonからC++への変更が必要になるかもしれません。

ゲームに適さない（だろう）言語

Flash関係

webブラウザ上で動くゲームのことを一般に「ブラウザゲーム」と言いますが、かつてはその多くでFlashが用いられていました。しかし、現在ではセキュリティの問題からAdobe社のサポートが終了しており、すでにほぼ廃止されているといっていいでしょう。

JavaScript

JavaScript はクロスプラットフォームですが、セキュリティ上の理由などからファイル出入力といったいくつかの機能がwebブラウザ上では使えないようになっており、セーブ・ロードといった多くの機能が標準では実装不可能となっています。そのためJavaScriptだけでゲームを作るのは、初歩的なゲームを出ない限り困難となっています。セーブの実装には、JavaScript国際規格にはない非標準仕様を使いこなすレベルの技術力を要し、そのようなゲームを作る場合はJavaScriptでの開発は選択肢にないと思われます。

ただし、オンラインゲームでは、サーバー側でPHPやサーバサイドJavaScriptなどの別プログラムが走っていると思われます。

ブラウザゲームの初歩的な原理

商品として流通するようなゲームや、高度な機能を持つブラウザゲームを作ることはとても難しく、このページでは手に負えません。そこでこのページでは初心者が練習用につくるゲームを例に記述します。

webブラウザだけで動くのがブラウザゲームです。ブラウザゲームを作るのに使う言語の第一選択肢はJavaScriptです。サーバー側の処理が必要ならPHP,Python,Perl,Javaなどの言語の出番でしょう。「ネットワークゲーム」は「ブラウザゲーム」とは意味が違います。「ブラウザゲーム」は、パソコンにwebブラウザさえあれば、ネットワークに接続していなくてもゲームプレイできて、最後、クリアまでプレイできる作品もあります。しかしネットゲームは、ネットワークに接続しないと、ゲームを開始することさえ不可能です。つまり、サーバの提供するゲームが「ネットワークゲーム」「ネトゲ」です。

もしPHPやPerlなどでゲームを作る場合、普通はネットゲームになる筈なので、作者がサーバを構築して提供する必要がありますし、プレイヤーにはゲーム中にサーバに接続する環境が必要になります。提供者は、サーバを用意したり、保守管理する必要があります。サーバーがダウンしてしまうと、プレイヤーがゲームをできなくなります。「PHP ゲーム」などの単語でネット検索したり、あるいは書店でプログラム言語の書籍や解説サイトを見ると、ときどきPHP・Perlなどの言語でゲーム開発しているものもありますが、一般的なダウンロード型のゲームとは違う筈なので、気をつけてください。

ソケット通信、ほか

コンピュータプログラムからインターネットに通信するには、いくつかの方法がある。例えば、C言語の場合はOSの提供するソケット通信といわれる機能を使う方法、JavaScriptにあるHTTP通信の機能を使う方法、などがあるだろう。ただし、JavaScriptでゲームを制作するのは、セキュリティ上の制約などからセーブロードが標準的方法では困難など、とても制作が難しい。よって本セクションでは、C言語にソケット通信を組み込むことの概要を説明する。

ゲーム制作初心者がソケット通信までする必要はないが、将来的には知る必要があるかもしれない。

本wikiではWindowsの場合については教科書『WinSock』、macやLinux / Unix や BSD の場合は教科書『Unixソケットプログラミング』で説明している。

Windowsとそれ以外のOSとで、ソケット通信の仕様が微妙に異なる。ソケット通信では文字コードの問題がある。手元のパソコンの文字コード設定は、通信相手方の端末には反映されない。Windowsの日本語版では、伝統的に Shift-JIS といわれる文字コードが使われてきたが、海外のWindows端末は日本の文字コードにあわせてくれないし、macやLinuxやBSDも同様に日本には合わせてくれない。簡単な対処法として、ゲーム中では日本語を送受信しない、つまり半角の英数字と記号だけを送受信する、という道はある。会員登録などのためにどうしても氏名や住所などの日本語を使う必要がある場合、PHP・Pythonなどサーバ言語に対応した「フレームワーク」があり、そのフレームワークが最初から日本語に対応、もしくは設定を少しいじるだけで日本語対応するので、それを利用すれば効率的かもしれない。ゲームとは別途、サーバー側にフレームワークをインストールして、会員登録時にサーバー側でそれを使うようにすればいいだろう。しかしゲーム内では日本語の扱いは非常に難しい、限定されるという事になるだろう。

C言語のプログラムにサーバサイドの言語・システムを組み込むのは難しいから、ネットゲームではどこかでソケット通信に頼ることになるだろう。市販の本を探しても、そもそもソケット通信の書籍自体がめったに見当たらないし（ほんの少しだけ出版されている）、もし見つけても全く文字コードの問題の解決方法は紹介されていない（2021年現在）。

プラットフォ－ム

ライセンス料

一般にプレイステーションや任天堂のゲームを開発するには専用の機材が必要であり、そのため、ソニーや任天堂とライセンス契約しなければいけない^[3]。その契約に際して、ライセンス費用またはライセンス料金と呼ばれるものを、ゲーム機開発会社の任天堂、ソニーに支払う必要があります。現在でもソニーや任天堂のゲーム機用のソフト開発・販売には、ライセンス料が必要です。少なくともPS4やニンテンドースイッチのパッケージソフト開発には、「ライセンス費」が必要^[4]。

なお、書籍『ゲームプランナーの新しい教科書』によると任天堂やソニーのようにゲーム機を作っている会社のことをハードメーカーと言います。つまり、ゲーム機のハードメーカーにライセンス料を支払うという仕組みになっています^[5]。

また、スマートフォン向けアプリは、プラットフォーム使用料が掛かります。書籍『ゲームプランとデザインの教科書』によると AppleStore, GooglePlayともに売上げの30%とのこと^[6]。その他のプラットフォームも、大体同じとのことです（参考文献の著作の時点では）。Google やAppleのようにプラットフォームを提供している企業のことをプラットフォーマーと言います^[7]。

昔からゲーム機のライセンス料は有料で高額であり、ソニーや任天堂の収益源のひとつになっている^[8]。一方、パソコンゲームにはライセンス料が無いのが普通です^[9]。なお、ハードメーカーでなければプラットフォーマーでもないゲーム会社のうち、製造から販売までを手がける会社のことをパブリッシャーといい、たとえばカプコンやコナミやセガやスクウェア・エニックスやバンダイナムコなどがパブリッシャーです^[7]。

実は、必ずしもパブリッシャーが開発を手がけるとは限らず、スマホ向けアプリなどではディベロッパーといわれる開発専門の会社に委託している場合もあります^[10]。

ポリコレ規制

Apple社のAppStore向けのスマートフォンアプリでは、ストア公開前にAppleによる審査があり^[11]、審査は欧米基準です。GooglePlayStoreでは公開前の審査はありませんが、公開開始後に審査が行われるのでそれに違反していると配信停止になります^[11]。そのため、海外プラットフォームで販売・配布したい場合「ポリティカル・コレクトネス」（政治的な正しさ）といわれる、海外の公序良俗の基準に配慮する必要があります^[12]。

ドラゴンクエストのファミコン時代、海外輸出の際、教会での描写を変更しなければいけなかったことがありました^[要出典]。これは、岡田斗司夫氏の YouTube放送でも話題にされています^[要出典]。教会の描写で、神父とシスターが同じ建物で仕事をしていた^[要出典]。これが問題になったらしい^[要出典]。カトリックでは妻帯禁止ですし、男女が同じ場で働く描写がよくないようです^[要出典]。開発者たちは、「教会の描写はキリスト教ではなく、ゲーム世界独自の宗教」と主張して、難を逃れようとしましたが、しかし教会の裏にある墓地が十字架のマークだったので、「十字架はイエスの磔（はりつけ）の場でありキリスト教で重要な意味を持つ。十字架の墓標がキリスト教ではないという主張は欺瞞だ」と、輸出先国の協力者が指摘し、その言及は認められませんでした^[要出典]。結局、日本の開発者たちは輸出にあたり、墓地か教会内の人物のどちらかを直したうえで海外での商品化を果たしたそうです^[要出典]。

また、十字架に関してですが、赤十字のマークは国際常識・国際条約として赤十字社以外は使用できないことになっています^[要出典]。ゲームではないのですが、赤十字によく似たマークをデザインしたグッズの回収騒ぎなども実際に発生しています^[要出典]。

また、ドラゴンクエスト世界観の漫画作品、「ダイの大冒険」の電子書籍版と2022年版アニメーションで、六芒星（ろくぼうせい）の魔方陣で魔物を召喚使用、とする描写が修正されています。直接的な理由は公表されていませんが、六芒星はイスラエルの国旗にも描かれ、伝統的にユダヤ人を表す記号とみられている、だから、という理由が、Webではよく指摘されています。

欧米の判断基準が、アジア諸国やアフリカの生活習俗に合致しない場合も多いのですが、欧米のIT大企業はその欧米基準での規制が政治的に正しいと考えているでしょう。「日本では少し考え方が違う」と言っても、通用せず規制される場合も多い。

共産党の機関紙『赤旗』がドラゴンクエストの職業について、「女性は回復職などの補助役割が多く、保守的な職業観、男女観ではないか?」と、指摘したことがあったらしい^[要出典]。しかし、ドラゴンクエスト1~3の元ねたであるウィザードリィ・シリーズでは、僧侶（ウィザードリィでは「プリースト」）の職業は物理攻撃力・防御力もかなり高い前衛職です。

戦士・サムライ・僧侶（ここまで３名が前衛）　　盗賊・ビショップ・魔法使い（うしろ３名が後衛）

がウィザードリィでよくあるパーティ編成です。プレイヤーによって、僧侶と盗賊の位置が入れ変わったり、ビショップと魔法使いの位置が入れ替わったりしますが、基本的に、僧侶は盗賊と同格の物理攻撃力・防御力です。メイスやフレイルといった鈍器を振り回すのが、ウィザードリィの回復職のプリーストです。ドラクエもそれを踏襲しており、僧兵みたいに「鉄の槍」を振り回し、僧侶の物理攻撃力は魔法使いよりも高い。

ゲームだけでなくテレビアニメでも、漫画ワンピースの海外アニメ版では、主人公側の若者がタバコを吸っているシーンをアメ玉に作画を変えられたり、ドラゴンボールに出てくるミスターポポという肌の真っ黒なキャラクターの肌を青く書き換えたり、色々な例があります。

ポリコレとは関係ない事例ですが、TVアニメーションのポケットモンスターで主人公のサトシ達がお握りを食べているシーンで、アメリカ版ではドーナツになっていたことがあります。これは、国による食文化の違いを示していますよね。

プロトタイプ

ゲームでは、曲や絵が良くてもゲームとしては今ひとつ面白くない、という事は起こり得ますよね。

書籍『ゲームプランナー入門』（吉冨賢介著）によると、商業的なゲーム制作ではイラストや楽曲は簡略なものを使ったうえで、プログラム中心の試作品をいくつか作り、その中でゲームとしての面白さがあるものを取捨選択したうえで完成度を高めていく、という制作過程を取るようです。この試作品をプロトタイプと呼びます。プロトタイプの段階では、プログラマーと、企画の意図を考慮するためプランナーも関わります。^[13]

イラストレーターは、プロトタイプの前段階あたりでイメージイラストを提供し、スタッフ間の共有イメージを作ります^[14]。そしてプロトタイプ進行中は、グラフィック案の提案をしていきます^[15]。サウンドも同様、プロトタイプでは、曲調を固めていく段階です^[15]。

※時々あるトラブルとして、マイナーな同人ゲームや零細メーカーのゲームで、背景イラストや脇役キャラクターなど目立たない部分で他社のイラストが使われていることがあるようです。おそらく試作用に流用したイラストが、そのまま製品に混入したのでしょう。こういうトラブルがあるので、他社イラストの使用は試作であっても避けるべきです。

実装検証

プログラマーは、そのゲームでコアになるプログラムやシステム、ミドルウェアについて、プロトタイプ段階で実装検証を済ませておく必要があります。プロトタイプより前の原案の段階では、利用するミドルウェアの洗い出しをして、出来る範囲での基礎実験をしておきます^[16]。ミドルウェアによっては使用料が発生するので、その点を事前に調べておく必要があるそうです^[17]。

例えば、任天堂『ゼルダの伝説ブレスオブザワイルド』ではプロトタイプの段階ではイラストを組み込まずに（イラストは、代わりに大きなドットの塊などで代用する）作られていた事がゲーム業界見本市イベント CEDEC 2017 で公開されていました^[18]。（おそらく音楽もプロトタイプでは組み込まないのだろう。）

プロトタイプのうち、画面だけなど張りぼての物を「モックアップ」といいます。一方である程度遊べる状態まで作っているものを、「プレアブル」といいます^[19]。

ゲームデザイン本ではよく「プロトタイプ」という表現が用いられるので、本ページではこの言葉を使うことにします。

商標権等

知的財産権には著作権・商標権・意匠権などがありますが、商標権は特に強い権利であり、気を配る必要があります。意匠権とは、建物や工業製品の外観に関する権利なので、ゲーム制作ではあまり気にする必要はないようです^[20]。

「特許権・実用新案権」と「商標権」は、事業者によって国に登録されている権利で、かなり強力な権利なので、気をつける必要があります。特許権や実用新案権とは、大まかに言えば、技術的な発明に関する権利です。商標が登録されているかどうかは、特許庁の『特許情報プラットフォーム』というwebサイト^[21]で確認できます。

商標をトリッキーな意図で登録する人も多く、自社でビジネス展開をする気がなかったり、他社の商品などでまだ登録されていない物を申請したり、そういうやや不正な登録申請でも認可されてしまう場合も多いです。

また、商標は業種のジャンルごとに分かれているので、たとえば携帯電話のジャンルが新たに追加された時代に、過去のゲームの商標を登録した人がいました。そのため携帯ゲームを出せなかったり、商標を買い戻したり、取り戻すための裁判をするのに時間とお金がかかってしまったり、様々な問題が発生します。^[21]

著作権は、登録の必要がなく、著作をした時点で発生する権利です。

『ゲームプランとデザインの教科書』によると、こういう事柄にまだ慣れていない人によくあることなのですが、他人の個人サイトやSNSで公開されていた絵や曲などを、許可なく勝手に使う事例があるようです^[20]。二次利用を許可されてない著作物は素材として使えません。そして見落としがちなのが、フォントの著作権です^[20]。フォントにも著作権があります。フリー素材と書かれていても、商用販売が禁止されている配布形態のものもありますので、気をつけましょう。

アイデアの権利。アイデアとは盗まれるのか、盗むのか?

商業ゲーム作家たちの、2022/1時点でのSNS発言によると、業界全体でみられることですが、会社外部の人がアイデアを一方的に投稿してきて、会社で作った作品にそのアイデアと類似点があったら、アイデア使用料を要求してくる、そのような問題に悩まされているようです。そこでゲーム会社側では原則、

送られてきたハガキやメールは、まずクリエイター以外の事務系の人間が読む。

もしハガキなどにアイデアがあった場合、そのハガキを処分。

などの方策を取ると言われています。また、偶然や何らかの理由でアイデアが一致してしまった場合に備えてのリスク回避として、事前に会社のウェブサイトなどで「弊社にアイデアが送られてきた場合、そのアイデアは弊社のものになります」のような宣言をしている会社も多くあると言われています。

法学的には、著作権法はアイデアを保護しません（『アイデア・表現の二分論』と言います）。

プロトタイプの段階では、画像や音楽は発注せず、骨組み的なプログラムだけで、そのゲームのアイデアが「はたして本当に面白いか？」を、実際に社内の関係者にプレイさせてみて確認します。

ちなみにプロトタイプに関しては『高等学校情報/その他の技術的な話題#プロトタイプ開発』の記述も参考になる。

ここでいう「プロトタイプ」（試作品）とは、コンピュータプログラムのゲームとして動作するのが前提です。映画製作でいう絵コンテ試写のように、ゲームの試作では、なるべく早期に第三者が試作ゲームを遊べるように作っていく必要があります。

プロトタイプという言葉を使用すること自体が妥当かどうか。まず、書籍『ゲームプランとデザインの教科書』で使われている^[22]。書籍 Game Programming Patterns でも用いられている。

ニコニコ動画の経営者、川上量生が使っています^[23]。川上は角川書店も買収したので、おそらくそこ（カドカワ・RPGツクール販売元）でも使っているでしょう。

ゲームのプロトタイプの基本姿勢は、「汚く作って、やりなおす」です^[22]。もちろん最低限のプログラムの知識、勉強は必要ですが、あまり知識収集や理解充実を気にするより、実際に作ってみることを優先したほうがいいようです。チーム制作をしている場合はプロタイプは赤ん坊であり、そのチームで育てていこう、我々の子供だという意識で接しているようです^[22]。

まず工夫して作ってみると、今後自分が何を勉強すればいいかも見えてきます。

英語では「quick and dirty prototype」という言葉があります^[24]。

書籍『ゲーム作りの発想法と企画書のつくりかた』によると、シナリオライター志望者が企画書やシナリオ案をメーカーに送りつけても、あまり効果的ではないようです。

それよりゲーム形式でシナリオを書いてしまうのがいいようで、「CHR:ヒロインA(私服)、表示」のような文章を織り交ぜて構成していくのが推奨^[25]。

参考文献のその章では、シナリオライター志望者に向けて語られていますが、プログラマー志望なら、サンプルゲーム、サンプルプログラムを作ってしまうのがいいかもしれません。

1990年代、週刊少年マガジンに不定期掲載していた読みきり漫画『ゲームクリエイター列伝』では、カプコン社のゲーム『バイオハザード』を扱った『バイオハザードを創った男達』の際、制作過程でゲームデザイナーが大幅な作り直しを判断して進行させた、という描写があります。（ただしWikiboooks一編集者の記憶、詳細はあいまい）。

のちの、ゲーム評論家の阿部広樹の評によると、むしろそれは劇的な大きな決断ではなく、ゲームデザイナーの日常の普通の仕事ではないか、と語られています。

どんな肩書の人間だろうと、すでに決まって進行していた方針をひっくり返すのは、かなりのストレスのある判断で指摘になりますが、一般に漫画や映画、あるいはNHKの仕事に関するドキュメンタリーでもそうですが、職業や職業者の物語では、過剰に対象を美化し、劇的な演出によって関係者を称賛し、英雄視する傾向があるように思います。

アイデアはアイデアで価値がある。でも、せっかくなら、それを試作して、形にしてみよう。

ゲーム業界人広井王子は書籍のインタビューで、自分の社長としての人材評価は「0点」から始まる「加点法」だと語っていたようです。『ゲームデザインプロフェッショナル』著者も、文脈は違いますが「加点方式で物事を考える」と述べています^[26]。

正直インチキなゲーム業界人の点数勘定などには全く興味ないが、そんな話とは全く別に、ゲーム制作の上で、実際に動く簡単なプロトタイプを作ってみることは間違いなく有意義な事でしょう。アイデアはアイデアとして、思考や思想の展開としてありますが、それを具体的な形にしてみることは非常に楽しくエキサイティングで、意味ある活動ですよね。

仕様書や設定資料を超えて、誰もが遊べる試作品は、意味のある企画行為でしょう。前編集者は、時間軸・動きの制作意図の明確化、という言葉を使っています。もちろん短くまとめること自体もなかなか難しいのですが、工夫を凝らして、ゲームプログラムを完成させることが重要な経験であり、思考の具体化でもあると思います。

アルファ版

アルファ版はプロトタイプとは違うもので、その後段階で、ゲームの全体像が分かる一部分を、商品に準じた形で作ることです^[13]。

厳密な定義は会社によって意味が多少違いますが、とりあえず最初からエンディングまでほぼ完成状態をひととおり遊べる制作物を指します^[27]。細かいバグ修正はこれらの段階では後回しにします。

アルファ版でもそのゲームが本当に面白いかどうか検証がなされます。サウンドやビジュアルは商品に近いほぼ完成化された形で取り込みます。アルファ版の使用の結果、プロジェクト中止の決定がなされる場合もあります^[14]。

基本的に

プロトタイプ→アルファ版→ベータ版→調整→デバッグ

の流れ。

プロトタイプ制作に必要な予備知識

数学は後回し

ゲーム制作の作り始めにおいて、必要な数学や物理の予備知識は、それほど多くありません。参考文献によれば、数学や物理の習熟にこだわって多くの時間と精力を費やして勉強するよりは、3Dの勉強などで必要を感じたら、そのつどその分野の数学や物理を学ぶのが効率的だと述べており、また可能なら実際にプログラミングでその理論を試してみると具体的に理解をしやすいと述べています^[28]。

C言語の予備知識は入門書1冊+αで十分

C言語を使ったゲームは、予備知識はそれほど多くないので、あまり難しいことは考えず、まず実際にプログラムを書いて作ってしまう事優先にするのが正解なようです。市販のC言語入門書で、配列や関数などの一般的な機能を一通り習得したら、あとはVisual C++ で映像出力とキーボ－ド入力のみを、1～2週間ほど勉強、そしてVisual Studioを起動してゲームを作り始める。うまくいけば数か月以内に、パソコン用の非ネット通信のゲームを作ることができるでしょう。

ただ、ゲームプログラミングを試みる人は、必ずしもゲーム制作のみが絶対的な唯一の目標ではない可能性もあるので、それぞれの立場に応じて、座学を取り入れてみるのもいいと思います。

作業リストを作る

作業リストの制作開始の方法

ゲームを作る時は、アイデアを頭の中だけに置いておくのではなく、文章に書き出すと効率的なことが多いです。

まず、壮大な長大なアイデアではなく、1週間～1ヶ月程度で成果の確認できそうなアイデアだけを書いてみましょう。次にそのアイデアを実際に動作するプログラム、プロトタイプ相当のソフトウェアにするために、具体的などんな機能を持ったプログラムを制作しなければいけないかを、簡単なものでよいのでやるべきことのリストを箇条書きで作ります。^[29]IT界ではこういうリストを「ToDoリスト」や「タスクリスト」といいます。このページではむしろ日本語で、「作業リスト」と呼んでみましょう。

さて、このリストを作るときは、作業項目は具体的かつ直接的に解決可能で単純な目標に分割します。ですから例えば RPG の戦闘システムを作るときは、

*戦闘システムを作る。

と、あいまいに総体的に書くのではなく、具体的に、

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

という風に、作業項目を細かく分割していきます。こうすることで、作業がひとつずつ比較的に簡単な要素に分解され、実際に着手する際に楽になります。また、バージョン管理ソフトを使って管理している場合、上記のような作業リストの分解をしておけば、各バージョンの概要を書く際に作業リストの項目が転用できるので一石二鳥です。

予定日は書かないほうがいいと思われます。スケジュールを管理したい場合は、別にファイルを作るといいです。

最後に書き出した項目を優先順位で並べたら、最初の作業リストは完成です。

作業リストの更新

プログラミングする前に作業リストを眺めて、そして上の項目から実際に作業を開始しましょう。ある作業項目を終わらせたら、その項目の周辺に特定の印をつけます。例えば、上記の作業リストの作業項目をいくつか終わらせたとすると、以下のようになります。

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

以前の記述を残したまま、その作業が終了したことを示しておくわけですね。

また、追加の作業が必要になったら必要に応じて項目を追加します。例えば「ダメージ計算システムを作るために、ランダム計算が必要になり、自分がそのプログラム言語でのランダム計算に詳しくない」という状況ならば、以下のように優先度に応じた位置に作業項目を追加します。

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

作業管理は人それぞれです。例えば、前編集者は「完了した項目を後述する」「現在着手しているタスクにも印をつける」といった手法を提案していました。

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

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

プロトタイプ制作における創作面の検討事項

ゲーム性

ゲーム性とはなんでしょう。「ゲーム性」という概念があって、これがあるからこそゲームは面白く、魅力的だと考えられています。プレイステーション開発元のソニーもこれを重視していますし、一般的に多くのゲーム愛好者、関係者たちもその考えに同意するでしょう。ゲームのジャンルにもよりますが、「駆け引き」や「戦術」、これが「ゲーム性」だとよく言われます。

『ゲームプランとデザインの教科書』によると、ゲーム性とは、シューティングやアクションでは「対戦の駆け引き」、RPGでは「戦闘と物語の介入」、シミュレーションゲームなら「戦略性」だそうです^[30]。ただし上述の書籍によると、1990年代は今よりもゲーム性とシステムが重視されていたとの説明があるので、裏を返せば2010年以降の現代では、ゲーム業界ではゲーム性の重視の比率は1990年代よりも減っているかもしれません^[31]。

『ゲームプランナー入門』（吉冨賢介著）では、ゲーム性とは「課題や挑戦の仕組み」であると結論づけています^[32]。そして、この達成感こそが「ゲームならではの面白さ」だと述べています。

アクションパズルゲーム「I.Q」

メディアクリエイターの佐藤雅彦氏（「だんご3兄弟」や「ピタゴラスイッチ」等を手掛けている）が、初めてかかわるコンピュータゲームで、ソニー・コンピュータ・エンターテインメントとの共同企画で、のちに「I.Q」（1997年にシリーズ第一弾を発売）と呼ばれるシリーズに携わった時、プロトタイプが全くゲーム性のないものになってしまい、それをプレイしたソニーの幹部陣の顔色が非常に曇ってしまったようです^[33]。ここでの悪い反応、薄い反応の理由がわからなかった佐藤氏が、階段の踊り場でソニーの新人に尋ねてみると、「それが、あの、ゲーム性がないっていうか・・・」と言われたと出典の対談集に書かれています^[33]。

基本的に佐藤氏は、プロトタイプの企画を提案しただけですが、ソニーにはプロトタイプを作るための部署があるらしく、1～2ヶ月かけてそこでプロトタイプが作られたようです。この問題の責任が誰にあるかは、大した重要な事ではありませんが、商業作品としてプロトタイプを作る以上は、どこかの段階でゲーム性を意識して、プログラムに盛り込む工夫が必要になるでしょう。

ゲームの見た目とは？

ふつうゲームのプレイヤーは、まず最初にそのゲームの「見た目」を判断し感受するでしょう。ですからその見た目のインパクト、興味を呼び起こす構成が必要になります。例えばスーパーファミコンRPG『新桃太郎伝説』では、開発当初はドラゴンクエスト5 のようなマップ画面のトップビューUIでしたが、開発中にクォータービューの他社製RPGが発売されて高い評価を得たので、マップUIを（トップビューではなく）クォータービューに作り直したようです。このことは攻略本『新桃太郎伝説究極本』に開発裏話として書かれています。

一方、現在でもこの方向の試みは重要なようで、書籍『ゲームデザインプロフェッショナル』の著者は、他企業の製品の画面と、自社の製品を目で見比べる分析方法で、自分たちの製品のUI の問題を見出しています^[34]。割と素朴で単純で即物的な見た目、「かっこいい」とか、「ぱっと見派手」等の要素が非常に重要なようです^[34]。

商業としてゲームを作る以上は、ペイしなければ企業も事業の継続も維持できませんから、考慮せざるを得ない問題ではあります。

イラストレーター・デザイナー

ゲーム制作、業界において、イラストや音楽を作る部署、人物は、まとめて、"アーティスト"と呼んでいるようです。

ゲーム界の場合「デザイナー」というのは、プランナーやディレクターのことであり、管理職的な設計者のことで、美術的なクリエイターではない場合がある。美術的なクリエイターも同音異義語でデザイナーと呼ぶ場合もあるが、本wikiでは区別のためアーティストという言葉を用いる。

映像関係、画像系のアーティストはグラフィッカーと呼ばれることもあります。ムービー担当者、特にゲーム界では3D-CGの制作者をアニメーターと呼ぶことが多いようです。アニメーション業界では主に、手描きの原画、動画マンをアニメーターと呼びますが、最近は3D-CGアニメーション映画も多いので、すこし状況が変わっているかもしれません。

ゲーム業界とアニメーション業界、各会社企業、過去と現在で、「原画」「仕上げ」「絵コンテ」等、一般的な作業に関する言葉が、それぞれの状況で微妙に違った意味で使われることも多いので、それそれ自分の所属する状況に適した言葉の使い方を考える必要もあるでしょう。

操作性

操作性について、親指と人差し指だけでボタンプッシュなどの操作ができるように作成するのが基本です。中指、小指、薬指はコントローラのホールドに使うぐらいです。人間工学的に、小指や薬指は力が弱いので、微妙な操作には向かないことが知られています^[35]。

一般的にゲームプログラミングでは、

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

入力と出力、この2点が機能として必要になります。

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

パソコンゲームでは、プレイヤーからの入力には通常、キーボードかマウスを利用します。他にジョイスティックやゲームパッドが利用される場合もあります。家庭用ゲーム機ではコントローラが利用されることが多いのですが、ニンテンドーDSやWii Uではタッチパネル、Wiiでは複数の入力機器が提供されることが発表されています。各種入力機器をプログラムから扱う手法自体は、普遍性があり、入力機器ごとに大きく変化しない、と、考えられています。デバイスドライバ、高等学校情報Bには、プログラムから周辺機器を扱う方法について多少の記述があります。

画面表示のうち、3Dの表現は割合難しく、ある程度の数学（高校、あるいは場合によってはそれ以上）の理解が必要でしょう。2Dに関してはプログラムの面では、さほど難しい部分はありません。

処理速度の問題

基本的にプログラミングでは、関数を使い処理をコンパクトにまとめ、定数ではなく変数で柔軟性のある操作をすることが求められますが、ゲームの場合はこの構造が原因で処理速度が低下することがあります。現在のCPUの性能、速さはかなり良くなってはいますが、プログラム処理は無限に煩雑化できますから、やはり高度な処理を短時間でなすことが求められます。特にゲームは、リアルタイムの反応のタイミングが非常に重要ですからね。数学の指数計算についての雑学で、「新聞紙を42回おりたたむと、月に届く距離になる」というものがあります。コードの内容によっては、このように計算量が指数関数的に膨大になってしまい、処理速度が非常に遅くなってしまう場合があります。ですが、このセクションで後述するように、関数を用いる場合の解決策があるので、プログラミングの初期のほうは、とりあえずバグを未然防止するために関数を活用するべきでしょう。

1980年代頃のファミコンなど古い時代のゲームでは、ストレージ容量（ハードディスク容量のこと）が、ボトルネックでした。「容量不足でイベントをいくつか削りました」と、当時のRPGなどのゲーム作家が述べるのは、ストレージ容量の不足のことでしょう。ただ当時のファミコンはROMカセットでハードディスクは無いので、まさにストレージ容量という言葉が適切でしょう。しかし2010年以降の現代では、ボトルネックになっている要因は、ストレージ容量不足よりも処理速度です。

ゲームプログラミングに要求されるコード特性は、科学計算ソフトウェアや金融プログラミングなどの手法とは異なります。情報工学・情報科学で適切とされる「構造化プログラミング」などの歴史的に発展してきたプログラミング・パラダイムの理念とは反するようなコード開発方針になる場合もあります。

ツクールなど制作ツール

RPGツクールの現制作元のカドカワでは、PRGツクールでのアクションゲーム開発は推奨していません。アクションゲームの場合は同社の「アクションゲームツクール」で制作するよう、薦めています。アクションゲームとターン制RPG では要求される特性が大きく異なり、なかにはほぼ対立しているような性質もあります。

ツクールやウディタでも、万能にあらゆることがスタマイズできるわけではなく、その制作ツールの特性に依存しますし、基本的に主に処理速度の低下しない部分について、ユーザが創作できるようになっているでしょう。多くのRPG制作ツールはマップ操作や戦闘画面の基本システムのルーチンそのものは、初学者にはあまりカスタマイズできません（カスタマイズにはかなり高度な技術が必要でしょう）。画像や音楽は挿入できますが、例えば戦闘プログラムなら、「コマンド」の命令文など一部の派生的な部分だけが独自に作れる程度。ですから、ツクールでどうしてもアクションRPGを作りたい場合、基本システムの改造はかなり困難だろうし、別途、アクションRPGのような動作をするマップイベントを作成する・・・ぐらいでしょうか。

ゲーム開発ツールは便利なものですが、万能ではありません。適材適所で正しく使いましょう。

C++での具体的な手法

初期段階では関数や変数を活用してプログラミングし、処理速度を高める必要がある箇所にだけdefineマクロ等を用い別の方法に置き換える。C++ならinline関数という機能もあります。

通常の関数で記述していったソースコードを、あとから一括変換などでdefineマクロやinline関数などに置き換えることは比較的に容易です。また、関数を経由しているので、マクロを使った場合でも比較的にバグが混入しづらくなっているかもしれません。（defineなどの前処理指令マクロは、用いるとバグを発見しづらいので、なるべくマクロの利用を避けるべきなのが、ゲームプログラミングに限らないプログラミングの定石です。）

一方、全く関数を使ってないコードを、あとからdefineマクロなどに手作業で置き換えるのは、なかなか面倒です。最終的には一括変換で置き換えることが出来ますから、途中の段階では、処理速度を気にせず関数を使うのがいいでしょう。

なお、defineマクロは、値の置換以外には用いないのが、プログラミングの定石です。このため、たとえば黒色RGB値の10,10,10といった配列にdefineマクロを使うべきかどうか悩みますが、とりあえずなるべく値周辺にだけdefineマクロを適用するようにするようにするのが良いでしょう。いっぽう、一般の命令文をdefineマクロで置き換えるのは、避けるべきでしょう。

ターン制RPGやシミュレーションゲーム、アドベンチャーゲームなど、アクション性のないゲームでは処理に時間が掛かってもかまわないため、どんどん関数に置き換えていっても良いかもしれません。一方、アクションゲームなどでキャラクター操作中のコードのように頻繁に使って、しかもそのゲームの中心的なコードなら、そこは最終的には関数にしないほうが良いかもしれません。このように、ゲームのジャンルによって処理速度に対する必要な水準が異なりますので、プログラミング時における関数などの利用の方針も異なります。

以上のように、何でも関数にすることは避けるべきです。関数は処理速度の問題がありますので、必要性のある部分だけ関数にするべき。関数を使わなくても、for文やif文などのブロックの構成を適切に組み合わせることで、コード中のmain関数以降の部分でコード共通化できることは色々とあります。「共通性のあるコードだから」といって、大して長いわけでもないコードを関数に置き換える事は、速度維持には寄与せず、ゲーム制作のプログラミングとしては、悪手となるでしょう。

2Dの画面出力

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

未分類

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

Visual Studio付属のフォームデザイナ（VSの用意するGUI自動作成ソフト）によるGUIオブジェクト作成では、RPG用には使いづらい。いや、ひょっとしたら上手に使う方法はあるのかもしれないが、様々な理由で難易度は高い。

そこでまず、Visual C++で、フォームデザイナをなるべく使わずに文字や映像を出力する方法を考える。選択肢は、幾つかある。

1. フォームデザイナを1つも使わない方式

Windows APIで入力していく方法。(Wikibooksに『Windows API』の入門書があります。)
DirectXで入力していく方法。DirectX自体はWindowsAPIを利用している。

2. 1つだけフォームデザイナのパネルを使う方式

フォームデザイナで「パネル」という画像表示機能のコンポーネントを一つ用意して、そのパネルで表示する画像をゲーム内のストーリーなどに応じて切り替えるだけで、すべての画像表示を行う。

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

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

乱数

そもそも乱数とは何かという問題があるが、それは高度な数学的な議論になるだろうから、我々はその問題には深入りできない。

ゲームにおける乱数的な処理では、事実上ランダムな値にならず、演出や調整のためにアルゴリズムが介入している場合も多い。例えばゲーム中のくじで「外れ」続くと、当たり確率が変動し、次からは当たりやすくなるアルゴリズムなども良く使われる。^[36]。ゲームは娯楽であり、実用目的のシミュレータではないし、アルゴリズム介入で、確率的にもいんちきが多いので、あまり厳密なランダム性が問題になることは少ないだろう^[37]。

例えば、サイコロというのは典型的な乱数器だし、ゲームにもよく使う物だろう。

ゲーム「桃太郎伝説」シリーズの開発者のさくまあきら氏、ハドソン社が、参考として他社RPGであるドラゴンクエストの乱数を真似しようとして分析したところ、初期ドラクエが戦闘ダメージのゆらぎについて高度な計算を使って実装していると思った部分が、実際には簡単な疑似関数だった（伝聞としてそう聞いた）、という開発談もあります^[38]。

無印C言語には標準的乱数関数 rand()があるが、これを乱数発生に使うことに批判的な意見もあるし、機能もやや不足していると見れる。Windows64bit では int rand(void) の出力は 32bit 整数だろう。まず、stand関数で初期化してから rand()を呼ぶごとに疑似乱数が帰ってくる。これの複数回の連なりが乱数列だね。帰ってくる値は0 以上定数RAND_MAX の値以下。例えばさいころの数値が欲しいなら、rand の返り値を6で割った後、余りに1足せば、とりあえずそれらしいものはできる。RAND_MAXは rand()の属性として定数が与えられているだけだから(Windowsで0x7FFF)、この値の変更はできない。

まあこれでもそこそこいい加減な乱数として機能するだろうが、最近ではもう少し改良された、質の高い乱数関数もある。また、改良された乱数関数は、乱数の範囲も指定できるから何かと使い勝手が良いし、バグを防ぐ効果もあるのだろう。

	Random^ saikoro1=gcnew Random();// Random^ でRandomクラスの変数を作っている。gcnewはインスタンスをつくるための演算子。
	int detame; detame=saikoro1->Next(1, 7);// Next メソッドで「〇〇以上△△未満」の乱数を指定できる。「->」はメンバーアクセス演算子。
	MessageBox::Show("目"+detame.ToString()+"が出ました。");

↑例えば上述のコードは前編集者が示したものだが、これは .NETプログラミングですね。.NET のSystem::Randomクラスを使っている。.NETのクラスは普通、C#かVisual Basic で利用するので、Visual C++で使えるようにするには結構面倒な手管がいるが、その辺は読者諸兄、ヘルプやネット情報を参照して、適宜辿り付いてほしい。C++ の場合はむしろ、 #include <random> を宣言してそこで使える関数を使用するほうが簡単でしょうね。この場合でも、乱数としての精度も高いし、帰り値の範囲指定もできる。

画像のちらつき

画像が頻繁に変化するアプリでは、画面がチラつく事がある。画面のチラつきは、ゲームのように画像を凝視するアプリではかなり利便性を損なう。キャラクターが1歩移動するだけで、画面全体がちらついたりする場合もあり、かなりプレイヤーの不満になる。

これを、ダブルバッファ（裏画面とも言う）という技術で解決を図る。Direct Xの用語では「スワップチェーン」と呼んでいる。.NET Framework開発環境の C++や C#でもダブルバッファの機能があると解説されている。いくつかのGUIオブジェクトのプロパティで、ダブルバッファの設定項目がある。しかし前編集者が実験したところ、この機能を有効に使って確認することはできなかったとの指摘がある。ひょっとしたら何らかのマイクロソフトの解説に間違いがあって、工夫次第では利用できるかもしれないが、少なくとも今現在のこのページでは、その問題に関するリファレンスは提供できない。

そこでやはり、以前の項目と同様、Win32 API または DirextX の利用をこのページでは考えたい。

前編集者は、.NET Framework のフォームデザイナでは、ちらつき自体は解決できそうだが、グローバル変数の共有が困難だったり、アプリ内から終了コマンドが使えない、などの難点があると指摘している。ただ現編集者はこの2点に関しては、解決策はあると思うが、しかし特に調査はしない。前編集者は、.NETプログラムでゲームを作る難点をいくつも上げているが、おそらくどれも、.NET の仕様や全貌に精通すれば解決できるように思えるが、そもそもその全貌がかなり広大なので、解決の道のりは長いだろう。

セーブ・ロード・データベース

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

HPや主人公の名前、現在地、フラグ状況などなど、ゲームには数値や文字列を保存するセーブ機能は欲しくなる。一番簡単で単純な方法は、C言語の fopen 関数、Windows API の CreateFile関数など、テキストファイル書き込み機能で、テキストファイルとしてセーブすることだろう。そして、テキストファイルを読み込んでプログラムに各種変数を配置して、ロードとする。

書き込みとしては、一番単純なC言語記法では、fprintf ですかね。C++としての書き込みをしてもいいし、読み込むのも、一番基本的な方法で。基本Cだとしたら fscanf で、この関数でテキストの数値も変数として読み込めるはずです。場合によっては atoi関数で文字列→数値の変換をすることもあります。

基本的にデータファイルは、OS もアプリケーションも、テキストファイルとバイナリファイルの２分類で考えるでしょう。実際にはテキストファイルもバイナリの集まりですが、慣用的、伝統的にテキストファイルだけ特別視することが多い。

バイナリファイルでもデータとしてのファイルと、OS が機械語または何らかの仮想的な機械語として扱う実行ファイルがある。それらのバイナリは種類に応じて多くは冒頭にファイル識別子の情報があるだろうし、OS やアプリケーション側で工夫を凝らして、特定の条件を満たす場合しか動作しないようにしているだろう。そしてバイナリファイルを扱うときは、セキュリティの安全性も考慮するだろう。基本的にプログラム側は何でもありだが、識別子の判別その他、ある程度様々な考慮をしないと、困った事態が起こり、プログラマーが責任を問われることも起こるかもしれない。

市販のパソコン用ゲームや同人ゲームでは、テキストファイルではなくバイナリでデータ保存するゲームの方が圧倒的に多いだろう。その方がそれっぽくかっこがつくし、何よりデータの改変行為がしにくくなる。ゲーム開発ツール側自体もそうなっている場合が多い。RPGツクールもウディタも、セーブデータの形式はバイナリ。

テキストデータは基本エディタで開けるが、バイナリデータも内容によっては結構ぐちゃぐちゃの状態で開ける。バイナリデータはバイナリエディタで開ける。バイナリエディタのリードオンリーモードやバイナリビューアみたいなものがあれば、データを壊さないで結構安全にデータ調査できる。データ内容を秘匿したければ、バイナリ化だけではなく、暗号化も必要になるかもしれない。

セーブ&ロード機能の実装時には、まずセーブ機能から作るのがやりやすいという。しかし最終的には関係関数の整備は、ロード機能が基盤となるだろう。データや変数を、一定のスタイルでセーブして、一方で正しいスタイルでロードする、この機能が必要なわけですよね。シリアライズされたデータを、型を決めたうえで配置しなければいけないから、ロードのプログラムの方が複雑に、面倒になる。結局データのシリアライズは、ロード機能が基盤となり、その機能の作りやすさが、セーブ機能の作りやすさも支配するようだ。

ゲーム中の特殊イベント

ゲームプログラミング/特殊イベント

RPGやシミュレーションゲームで、1回しか起きない特殊イベントを作りたい場合もありますね。例えば日本の中世の戦国シミュレーションゲームで、「桶狭間の戦い」が3回も起きたら困りますよね。まあ起きるなら起きてもいいけどね^^。信長君には敦盛を3回舞ってもらいましょう^^。

さて、リンク先ではその話題についての叩き台、「こうプログラミングしたら、いいんじゃない？」、という事を説明しています。

スケジュール管理

個人でゲームを作る時にはあまり考慮しなくていいのですが、シビアな仕事の世界では、スケジュール管理表が良く使われます。

「作業責任分担表」（TRM:Task Responcibility Matrix）といわれるスケジュール表から、それをグラフ的に図示したガントチャートといわれる表を作って、その表を見て作業計画を判断する^[39]。

仕事	担当	状態	開始	終了予定	終了日
仕事1	田中	済	2021/10/03	2021/10/10	2021/10/10
仕事2	田中	仕掛	2021/10/11	2021/10/13
仕事3	鈴木	済	2021/10/05	2021/10/08	2021/10/08
仕事4	山田	未着手	2021/10/13	2021/10/17

ガントチャートでは普通、横軸に日程をとります。

商業ゲーム界でもガントチャートの横軸は日程です^[39]。

ガントチャートとして図示することで、ボトルネック、リスク要素、直感的にスケジュールの詳細や全体像が理解しやすくなります^[39]。

スケジュール管理のための、現実的、習慣的な工夫ですね。

このTRMとガントチャートは、IT業界だけでなく建築工事でも使われ、これを利用したボトルネックの洗い出しも、建築学の教科書に記述があります。

住宅の新築やリフォームをする時、建築業者がこの表を提示して、見せてくれることもあるでしょう。

業界人ではなくとも、こういう慣習を知っておくと、得るものがありますよね。

ストーリー制作、そして順序

ゲーム界、特に商業ゲーム界では、ストーリーもゲームも全体から作っていくようです。アトラス社（ペルソナシリーズ、女神転生シリーズ、などを手掛ける）では、「ゲーム全体に血を回すのが先」、という言葉が良く言われていました^[40]。

プレーヤーが見たいのは、物語の細部ではなく、ゲーム全体のストーリーやテンポ、総合像である、とは限らないのだが、しかし物語を含む創作物では、全体を見て重視し、そこから作っていくのはある意味王道、常套手段ではあります。

ちなみにやや雑談的ですが、日本の週刊漫画は、その週その週での勢いや読者の興味の引き付けも大事なので、全体がないのに、その場その場で場当たり的に作られた事も多かったようです。

現編集者が聞いたことのある話では、週刊少年ジャンプで連載していた本宮ひろ志氏が、不良少年物の漫画で、敵の不良少年グループと1対1000の喧嘩になり、さあいよいよ対決場に着いて勝負だってところで以下次号にし、そして実は本宮氏はその続きを全く考えていなくて、考えてみたけどどう考えてもどう描いていいかわからない^^;;;、そこで仕方ないのでイライラして近所の酒場に飲みに行き、そしてイライラしたままそこの常連達とあり得ない大ゲンカして^^;;、そのままボロボロになって家に帰って、2時間で次の号の漫画を描き終えた、と、本宮氏自身がメディアで語っていたのを聞いたことがあります。

さて、コンピューターゲームである以上、ゲームのストーリーはシステムと連携、調和したものになるでしょう。

そこで、ゲーム作家として、システムを先に決めた後ストーリー、そういう方法論の作者も多いようです^[41]。

とにかく商業ゲーム界では常識的に、全体像から攻めていく。

例えばドラマ脚本では、「ハコ書き」という方法がある。全体像に当たる「大ハコ」を記述してから、「大ハコ」→「中ハコ」→「小ハコ」と記述していく^[42]。

しかし、本当にすべてのゲーム制作は全体から作る必要があるのか、という疑問はありますが、その方法論に従うとすると、

エンディングを大まかに先に作る
機能の実験を簡易でいいので事前にしておく（※プロトタイプの項目を参照）
使用頻度の高い部分から作る

などの工夫を凝らして、常識的な方法を遂行していくことになるでしょう。

或いは、アルファ版（α版）を中盤から作り始めるとか…^[43]。α版の製作目的の一つとして、そのゲームが本当に面白いかの検証がある。面白くないと判断したら、制作中止もある。最初からではなく中盤から作ると、ゲームの全体像が見えるので、検証、判断がしやすい。

つまり全体から攻めて、細部やゲームが作られていくわけですから、必ずしも冒頭部から作り始める必要はないわけです。

エンディングやラスボス戦闘を早めに作る場合

ゲーム作者にもよりますが、商業ゲームシナリオでは、エンディングを早い時期に作る人も多い^[44]。

システム面についても、先にゲーム全体のクリア条件を決めてから、あとから各ステージの条件を決めていくことが多いようです^[45]。

エンディングの仮の、おおざっぱなシナリオ、そしてキャラクターの性格付けを先に決めておくと、ゲームの方向性と主人公達が目指すもの、ゲームの全世界像が作者やスタッフに明快になっていきます^[44]。

基本的に商業ゲーム界では、全体→部分と細部、の構成を進めていきます。

ゲームは必ず最後にラスボスと戦う訳では無いでしょうが、その戦いはゲーム中で最も高負荷になるでしょうし、全てのシステムが集積する場面でもあるので、エンディングを先に作ると、ゲームの最大負荷の検証ができます^[46]。

3Dゲームでは、RPGなら戦闘シーン、アクションゲームならアクションシーンが、一般的に最も高負荷^[47]。

負荷が高くて処理が落ちないかどうかも、この方法で確認できます。

常識的、教条的物語手法、そして金と権威を持っている人間の言を神のように崇めるとしたら、たいていの物語は最後の最後が一番の見せ場になると考えられるでしょう。ストーリーを削る必要があるとすれば、最後以外の部分、という事になります^[46]。

つまりラスボス戦は削らない。後の部分は削る可能性あり。だから最後を先に作っておけば（作れる範囲で）、もし制作過程で不測の事態が起こっても、重要部分はできているので、早く、上手にリリースできる。

イラスト制作でも順番を考え直すと打開できる場合あり。

イラスト雑誌『コミッカーズ』（1995年季刊夏号）（唯登詩樹表紙）での藤島康介のインタビュー

藤島（談）:よく若い漫画家さんから相談で、「先生みたいに女性の長い髪を書くとき、毛先を書くのが難しいです。根元は書けるのに」との相談を受けるのですが、僕（藤島）は髪を描くときは毛先から始めて根元に向かって描いてます。

つまりイラスト初心者は、根元から髪の毛を描きたくなるのですが、ここで長い髪の毛を描く場合はむしろ毛先を先に書いて位置決めして、長い毛を描くと割とうまく描ける。

きれいな女性の髪の毛は、毛先の奇麗さが大事ですからね。

ストーリーを作る時に全体を考えたうえで、必ずしも最初から書くことにこだわらない方がいいように、絵を描く時にも同じ発想が有効になる。例えば機械製図でも、正確に奇麗に書くためあるいは実際の製作のため?、位置決めの優先指示の記法がある。

目標

世の中では目的や目標を明確化せよ、と主張する人は結構多い。現編集者は懐疑的。むしろ他人を自分の都合いいように動かしたいから、その方向を明示したいのだろう。それより、我々の本当の目的と目標は何か、歩みを止めてちょっと考えてみろよ、と、言いたい。

しかし結局世の人たちは目標をはっきり、言語化したがる。ゲームでもそれをすると、プレイヤーがゲームに引き込まれる、と言うが、実際にはそれはゲーム業界のカモになっている、インチキゲーマーだけだろう。

とにかくカモたちは目的を欲しがる。目標や課題がゲーム中で明確になっていないと、疑問だらけになり、ゲームをやめて、業界にお金を落としてくれない。そこで設計の際、各ステージやエリアなどの冒頭で、そのステージの課題や目標などを明示する必要があるという^[48]。

ファミコンなどの古いアクションゲームではゲーム本編では目標は語られていませんが、しかし説明書などではきちんとそれが語られており、実際にスーパーマリオブラザーズの第1作目の説明書では、目的はクッパを倒してピーチ姫を救出することだと語られています^[49]。

チュートリアル・製作順序

RPGやシミュレーションゲームの序盤は、操作説明のためのチュートリアルイベントになることも多いのですが、ここにも製作順序のポイントは指摘できますね。

例えば製作過程において仕様変更は頻繁に発生するので、基本的にはチュートリアルの細部は後回しになることが多いです。最初の段階でチュートリアルを作りこんでも、仕様変更になればその記述自体が不適になる。そもそもの話、チュートリアルイベントが必要かどうか、説明書に任せてもよいのではないかを考えても良いかもしれません。基本的にゲーム本体の仕様がかなり変更を含み場当たり的なので、チュートリアルは後回し、早くともゲームα版の時期になるでしょう。

昔のコンピューターゲームと技術の発達・変遷

ゲームプログラミング/レトロゲームに分離しました。

脚注

^ ^1.0 ^1.1 ^1.2 ^1.3 ^1.4 引用エラー: 無効な <ref> タグです。「m289」という名前の注釈に対するテキストが指定されていません
^ 2022.11.04 の記事※ネット検索の邪魔に無らないよう当wikiではリンク先タイトルを省略させていただく
^ 『ゲームプランとデザインの教科書』、P.107
^ 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.120
^ 『ゲームプランナーの新しい教科書』、P20
^ 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.121
^ ^7.0 ^7.1 吉冨賢介『ゲームプランナー入門』、P244
^ 青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.267
^ 青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.283
^ 吉冨賢介『ゲームプランナー入門』、P245
^ ^11.0 ^11.1 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.139
^ 『ゲーム作りの発想法と企画書のつくりかた』、P.235
^ ^13.0 ^13.1 吉冨賢介『ゲームプランナー入門』、P17
^ ^14.0 ^14.1 吉冨賢介『ゲームプランナー入門』、P18
^ ^15.0 ^15.1 蛭田健司『ゲームクリエイターの仕事イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P56
^ 蛭田健司『ゲームクリエイターの仕事イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P54
^ 蛭田健司『ゲームクリエイターの仕事イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P55
^ https://game.watch.impress.co.jp/docs/news/1078888.html 2020年11月25日に閲覧して確認
^ STUDIO SHIN『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日初版第2刷、P251の図
^ ^20.0 ^20.1 ^20.2 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.135
^ ^21.0 ^21.1 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.134
^ ^22.0 ^22.1 ^22.2 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.350
^ 川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P.38
^ 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.349
^ 『ゲーム作りの発想法と企画書のつくりかた』、P.140
^ 『ゲームデザインプロフェッショナル』、P224
^ 『ゲームデザインプロフェッショナル』、P170
^ 蛭田健司『ゲームクリエイターの仕事イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P88
^ https://www.youtube.com/watch?v=J5FCZG7dfEY 2020年3月17日に閲覧
^ 『ゲームプランとデザインの教科書』、P152
^ 『ゲームプランとデザインの教科書』、P302
^ 吉冨賢介『ゲームプランナー入門』、P36
^ ^33.0 ^33.1 川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P.67
^ ^34.0 ^34.1 『ゲームデザインプロフェッショナル』、P199
^ 川上大典ほか『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.48
^ 『ゲームプランナー集中講座』、P232
^ 『ゲームプランナー集中講座』、P231
^ [1] 2022年3月19日に確認.
^ ^39.0 ^39.1 ^39.2 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.65
^ [2]2020年12月1日に閲覧して確認.
^ 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.306
^ 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.184
^ 吉冨賢介『ゲームプランナー入門』、P17
^ ^44.0 ^44.1 畑大典ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P166
^ 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.253
^ ^46.0 ^46.1 [3] 2020年8月30日
^ ntny著『ローポリスーパーテクニック』、ソフトバンククリエイティブ、2010年2月16日初版第5刷、P28
^ 『ゲームプランナー入門』、P39
^ 『ゲームプランナー入門』、P54

概観