ゲームプログラミング

概観編集

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

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

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

本書の目的編集

この教科書『ゲームプログラミング』の目的は、題名にもあるとおり、プログラミングによってゲームを作るための技術の参考資料を目的としています。

ゲームクリエイターやゲームデザイナー(絵描きではなくゲームの設計者のこと)のためではなく、プログラマーのための教科書です。

したがって本書では、ゲームとは関係の少ない一般IT企業での仕事のしかたについての記述もあれば、製造業系の組込ソフトなどに関する概要的な記述もあります。

なぜなら本書はゲームクリエイターではなく、たまたま何らかの理由でゲームを作っているプログラマーのための教科書だからです。たとえゲーム会社を退職しても、他の一般IT企業に転職してもプログラマーとして応用できることなども目指して本書は書かれています。

従って、紹介する話題が、かなりIT系、テクノロジー系の話題に片寄っています。本書で紹介するクリエイター論やデザイン論は、派生的なものにすぎません。

本書を扱う上での注意点

特にことわりのないかぎり、本書ではC言語でのプログラミングによってゲームを作りたい読書を念頭に説明しています。

だから、ゲームの生産効率性を無視してでも、本来ならRPGツクールのような開発ツールを使ったほうが早いシンプルなゲームの場合ですら、本書ではC言語または他のプログラミング言語での開発にこだわった方法を説明している場合もあります。

その他、本書について

このページとそのサブページだけを見ていると本書は「ゲームクリエイトの教科書かな?」と捉えられるかもしれませんが、

しかしこのページとは別に本wikibooksには「プログラミング」というページがあり、そこではC言語やJavaなど代表的なプログラム言語のwiki教科書にリンクしています。ゲーム限定の話題ではないですが、プログラミングのコードについても、そちら『C言語』や『Java』やなどの教科書のほうが(実際に動作するコードの量が)充実しています。また、Visual C++ での画面出力については『Windows API』に入門的な説明があります。

本書『ゲームプログラミング』はそういったプログラミング教科書一覧の一部でもあります。C言語やWindows API の教科書では、これをどうやってゲームのプログラミングに応用すればいいか説明できないので(本wiki『C言語』はけっしてゲーム目的のページではないので)、ゲームの実際としてプログラミングの話題を切り離すために本書『ゲームプログラミング』は存在しています。

なので本書にゲームデザイン論やクリエイター論などの内容の充実は期待できません。

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

ゲームを作りたいな、よし、ゲームを作ろう。でも…編集

しかし自分の本当の目的ってゲーム作り?編集

「ゲームを作りたい」と思ったのなら、さっさとゲームを制作してみましょう。現代なら、ゲームの性能にこだわないなら、JavaScriptでもPythonでも何でも無料でとりあえずゲームを初心者でも簡単にプログラミングできる方法はありふれています。

しかし、ゲームをプレイするのが好きだからと言って、「ゲームを作る」までが本当に自分が好きかどうか、試しに少し作ってみたら、少しは考えてみる必要があります。

例として、RPGを例に考えてみます。読者の中には「私はRPGがすき」という人も多いでしょう。

RPG が好きという事はおそらく、よくRPGの題材になる西洋ファンタジーのストーリーや世界も好きという場合が多いでしょう。そして一方で現実のコンピューターRPGで魅力的に提供される、イラストや音楽が好きという可能性もあります。

実際のゲーム業界の人々も、ゲームを彩るイラストレーションや音楽がいかに重要な要素かを語っています[1]

さて、ここで問題なのですが、「ゲームを作りたい」と貴方が思っていたとして、あなたが本当に作りたいのはゲームなのか?あるいは本当はイラストが描きたかったり、音楽を作りたいのではないか?

…というのは、ゲームというのは総合的な分野ですから、イラストや音楽はその要素として確実にあり、そういった素材をもし自作するならプログラミング以外の創作が膨大にあるのです。イラスト・音楽などをフリー素材に頼るとしても、シナリオだけは自分で考えざるを得ません。

そしてゲーム、コンピューターゲームにはゲーム独自の世界観があって、現実や小説や映画とは違う、独特の法則に支配された世界を作る必要があります。ある意味リアリティを持たない、リアリティから外れた世界です。だから、小説のようなリアリティにこだわるなら、ゲームは不向きかもしれません。


とりあえずのゲーム作り始めの時点では、これらの判断は明確でなくても勉強目的でも構いませんが、しかその内「自分は本当にゲームを作りたいのか? はい/いいえ」といった疑問への解答が問われるでしょう。試しにゲーム作ってみて、もし自分の本当の目的がゲームでないと分かったなら、ゲーム以外の活動に移るのも一つの手です。


給料は安い

職業として、商売としてゲームを作る場合、ゲームプログラマーの給料は洋の東西を問わず、安い事が知られており、書籍などでも言及されています。たとえば『CAREER SKILLS ソフトウェア開発者の完全キャリアガイド』(ジョン・ソンメズ 著)という欧米人のプログラマーの書いた本には、アメリカのゲーム業界ですらハードワークの割に賃金が低い事が記載されており、もし給料の高い仕事につきたいならウォールストリート(※米国の金融ウォール街のこと)のための仕事をするべきだと書籍中で指摘しています。

日本でも同様にゲーム業界の報酬が低いことは知られており、多くのゲーム会社の伝記漫画でも、よく語られています。

アニメーション業界と比べたら、ゲーム業界のほうが報酬が高いことは事実かもしれませんが、これは実は恐ろしいことに、アニメーション業界の報酬が異常に低いだけで、アニメーション業界よりはましだけど、結局は…というのが現状でしょう。

同人ゲーム以外の発表の場編集

2001年ごろの日本はネットを活用した同人ゲーム黎明期、フリーゲーム黎明期で、実験的な時代でもあり、多くのイラスト愛好、創作者や音楽創作者がゲーム制作に手を染めていたようです。この頃、まだイラスト投稿サイトや小説投稿サイトといったものは無かったか、あったとしても小規模でマイナーなものでした。

しかし2010年のあたりから各種の投稿サイトが普及したことにより状況は変わり、むしろ現在では、小説やイラストを発表したい人はそのジャンルの投稿サイトに直接アクセスしたほうが早く、そのためゲームを通して発表するのは人によっては廻り道かもしれません。

なので、それをわかったうえで、それでもゲーム制作に身を投じるかを考えた上で、「よし、自分はゲーム制作をしよう」と思えるなら、ゲーム制作をするのが良いでしょう。

実際、今現在の作曲家やイラストレーターは、ゲームに関わったとしても、専門家として楽曲やイラストを提供するという立場に過ぎない場合もあり、自分自身が主体になってゲーム制作をする人はプロアマ問わず少数派のように見えます。

なお、同人ゲームの世界でも現在は(2021年頃に記述)、プログラマー系の作者が圧倒的に多い様です。

ただし、専門外の人だからこそ、メディアミックス的な意外な視点で新しいものが作れる可能性もあるかもしれません。ゲーム業界でも、コピーライター、作家の糸井重里がマザー2の企画にたずさわったりと、そういう例もあります。しかし、あくまで「可能性」であり、成功はけっして保証されてはいないので読者の自己責任でお願いします。

さて、今現在のゲーム専門学校のカリキュラムはプログラミングが主体のようです。CGの授業は、週に2時間程の様です。一方でゲームCG、或いは、一般CGに特化した学科もある様です。

ある編集者Aは、もしイラストを描きたいなら、イラストの世界でイラストを描くのが安全、と考えています。ゲームプログラミングについては、ゲームプログラムを書ける人は絵コンテも書けたりとか、基本的にある程度の作図的なイラストを書ける人が多いだろうから、別にプログラミングに専念しろとは思っていません。

さて、読者がゲーム制作を職業として目指すつもりかどうかは知りませんが、とりあえず、ゲーム業界の状況を知っておく必要があります。

結局商業界の状況が権威をもってその分野を支配しているのがこの社会の基本状況なので、趣味でも職業でも、業界周辺のことを知っておくのは得ることが多いでしょう。

文献『レベルデザイン徹底指南書』では、現実世界で自分が新しいスキルを1つ覚えたら、古いスキル1つはどれか忘れる必要があることを説いています[2]。著者は、最初はグラフィッカーでしたが、しかしプランナーに転職したので、グラフィック関係のスキルは仕事では「忘れて」しまったいう内容を述べています。ただし、比喩的に「忘れる」とは言ってますが、実際には忘れたわけではなく、仕事では時間の都合により両立できないので、グラフィック関係の技能は例えで「忘れる」と言っているだけであり、実際にはグラフィッカー時代に培った観察眼をプランナー時代の現在でも活用していると書籍中では述べられています。

このことは職業、あるいは技能とは一般的にそういうものだ、と、考えることができるでしょう。

漫画家のお手本

ただ同人ゲーム界では、ゲーム制作と、イラストまたは作曲などを一人で兼ねている作者もそこそこ居ます。ネットの世界には様々な簡単に利用できるフリー素材もありますので、イラスト作画や作曲をしなくてもゲームは制作できます。

さて、一人でイラスト作画や作曲をしているマルチタレントなゲーム作家に憧れるかもしれませんが、しかし少し考え直してください。その目標の人は、必ずしも若い19歳ぐらいの頃に、それらマルチジャンルを両立できていたとは限らない亊に、注目する必要があるからです。

漫画家の大塚志郎は、漫画家を漫画創作の手本にするならデビュー時代を手本にするのが良い、と言った内容の助言を、漫画家向けの技法の教育漫画で行っています。

大塚が言うには、漫画家の人生のうちで、これからデビューを目指している新人に近い境遇にあるのは、ヒット後の漫画家の生活状況ではなく、まだ無名・マイナーな時代の態度・生活だからです。そのほうが安全ではないか、という主張のようです。

では、ゲームの話題に戻りますが、それでもデビュー時代から複数ジャンルの同人活動を均等に兼業する意思が硬いなら、それはそれでひとつの考え方ですが、上述のリスクを知っておく必要があるでしょう。


ゲーム業界は産業のエンジン役?編集

かつてはゲーム産業が、日本のIT産業やデジタル家電産業の中心的・牽引(けんいん)役であった時代がありました。しかし、2010年以降、この考えは当てはまらなくなっています。

プレステ2あたりまでの時代は、経済評論誌の未来予想でも、「もしかしたら今後、家庭用の据え置きゲーム機がパソコンの代替品として、家庭のリビング家電の標準品になるかもしれない」という予想があった。ゲーム産業がそのような牽引役として、経済界から期待されていました。ソニーが国産CPUをプレステ2〜3に搭載したり、WindwosのマイクロソフトがXBOXでゲーム機に参入したり、そういう時代です。

しかし2020年代の今は違います。結局、2020年代のゲーム機に使われてる技術や部品は、パソコン用の部品や技術の流用、ゲーム機のCPUも、今やインテルなどのパソコン用CPUをゲーム機でも使っています。

もはや現代は、ゲーム業界は、産業のエンジンではないようです。

ですから今現在、新しい技術に興味ある人は、ゲームにこだわらず、直接的にその技術を勉強し改良したほうが近道です。

たとえば、インターネット技術を使って何か新しい事をしたいなら、ゲームを作るよりもwebアプリやサーバーwebサービスを作るべきだし、目的のネットワーク用ソフトウェアをそのまま制作したほうが早いし確実です。

古い経済知識の先入観にとらわれず、無理にゲーム制作にこだわらないほうが、自分自身の技能やキャリアも開けていくでしょう。

2010年に出版された商学書籍『メイド・イン・ジャパンは終わるのか』には、「しかしながら、ファミリーコンピュータで世界に攻勢をかけ、その後圧倒的な強さを誇っていた日本の家庭用ゲーム産業も、90年代末からはその競争力にかげりがみえはじめた。日本の国内市場は伸び悩み、成長率は鈍化傾向にある(図表7-3)。」とあります[3]

その「図表7-3」の統計値によると、

ファミコン発売の1993年には2268億円、
スーファミ発売の1990年には2430億円、
プレステ1発売の1994年には3882億円、
1995年には急成長して4769億円、
1997年には4795億円で、ほぼこの頃がピークであり、
2000年には3768億円にまで低下(プレステ2の発売年)、
2005年には3151億円まで低下(XBOXの発売年)、

である。(青島らが『レジャー白書』、『情報メディア白書』、『月刊トイジャーナル』、『CESAゲーム白書』などをもとに作成した図表の統計値です。)

また、2010年の時点の商学研究では、1997年を境に、ゲームソフト市場で競争する企業数が増加傾向から減少傾向に転じた[4]、とも言われています。

書籍『メイド・イン・ジャパンは終わるのか』にも、引用文「家庭用ゲームは日本がその本格的立ち上げを主導し」[5]と書かれているぐらいで、1990年代は日本のインパクトが強かったようです。

なお、携帯電話の分野で、日本は国際的な地位を喪失したのに対し、デジタルカメラとゲームは「現代」(参考文献の著作時2010年ごろ)でも日本が主要な地位にある[5]

ゲームが産業の牽引役だと語った人物

1998年頃、アニメ評論家の岡田斗司夫が、未来予想の一貫として、「これからゲーム機が、(パソコンではなく)家電の中枢になるだろう」というような内容の未来予想をしていました。たしか、岡田の著書『東大オタキングゼミ』(自由国民社、1998年)で、このような未来予想が読めます。岡田の東大での講義を加筆修正してまとめた書籍なので、実際の講義はその数年前に行われていたのだろうと思います。

岡田の東大での講義は東大生のその後の進路、官僚や大企業のビジネスマン達に大きな影響を与えただろうし、若手新進評論家として、この国の政治・経済人達も、その言論を参考にしただろう。

実際、2008年(リーマンショックあたり)くらいまでの日本の家電業界の投資は、ソニーがゲーム機のCPUを作ったりと、岡田の予想を参考にしているような面もありました。

ですが実際の2001年以降の家電業家の結果は予想とは少し外れました。まず

  • そもそも、冷蔵庫もエアコンも全然デジタル化(IoT化)されず、家電のほとんどが外部からのコンピュータ制御を必要としない現状。
  • 個々人が持ち歩いているデジタル家電は、携帯ゲーム機ではなくスマホになった。
  • パソコンは多くの家庭にいまだにインターネット用端末などとして残り続けている。

一方岡田は東大オタキングゼミで、98年当時の時点で任天堂が莫大な現金資産(たしか数千億円ほど)を持っていることに注目しています。

一般の大企業は、現金ではなく株券や不動産などの形で資産を蓄えています。しかし任天堂は、銀行口座の現金だけで数千億円という、非常に資金力の高い企業でした。今や日本を代表する世界的なゲーム大企業になっています。

また、日本だけでなくマイクロソフトのXBOXなど、実際に欧米の企業も昔はコンピュータゲームが産業の牽引役だと思って、先をこぞってゲーム機に参入していたわけでもあります。岡田の未来予想は、決して根拠の無いものではなかったのです。


読書について

ゲーム業界と関連のない文献も、この教科書では出典として書かれていますが、これはこの頁の主要執筆者Sが、多量の市販本を読む以外に知的活動の方法を知らないことと、自分自身の文章の権威と信頼性を、著名人の威を借りて確立したいからでしょう。

ゲーム業界を志望するなら、ゲーム業界人の書いた本は少なくとも何冊かは読んでおくといいでしょう。

ネット上では、業界人ではないのにもっともらしく書かれた文章も多いですし、おそらく本Wikiの執筆者にも本格的なゲーム業界関係者は一人もいないでしょう。

業界人達のSNS発言ではなく、現代では書籍があるので、実際に書籍を手に入れて読むのがいいでしょう。書店で販売される書籍というのは、けっして著者だけの意見でなく、編集者や校正者、周辺の職業人が査読をして、内容の信憑性を確認しています。

何十冊も本を読むよりはプログラミングを書く実践のほうが重要でしょう。

『ゲームデザイン プロフェッショナル』著者であるFGOクリエイターも、ゲーム開発の書籍は読んでおくべきだと忠告しています[6]。また、ゲームデザイン本で学んだ知識は、ゲーム業界以外でも仕事術として活用できます。たとえば上司への業務報告の報告・連絡・相談(ホウ・レン・ソウ)などの考え方は、ゲーム業界でなくても活用できます[7]

いっぽう、もし最新IT技術を勉強したいなら、読むべきは、ゲーム制作の解説本ではなく、そのIT技術の解説本など、そのものの書籍を読むほうが近道でしょう。


ゲームプログラミングは楽ではない編集

ここでいう「プログラミング」とは、C言語などのプログラム言語による開発のことです。RPGツクールなど開発ツールによるゲーム制作の話は原則していません(本書『ゲームプログラミング』はあくまでプログラミングのための教科書です)。

さて、よくネットや、あるいは日常でも(C言語などによる)「ゲームプログラミングは簡単だよ。イラストやシナリオのほうが難しい」などという人がいますが、この発言の心は、「俺はプログラミングもイラストもシナリオも出来る凄い男だぜ。しかもプログラミングなんて簡単だし、むしろクリエイティブなイラストやシナリオの方に精力を費やす偉い奴だぜ^^」という、世間に良くいる武勇伝、自慢を語りたがる、インチキ親父が吹かしているだけなので、あまり真面目に取り合わないのが正解だと思います。

まず第一に、不当にプログラミングの価値を貶めている言説です。

Visual C++またはVC# 、あるいは Direct Xなどを使ってプログラミングすることは、そんなに簡単なことではないでしょう。

ゲームプログラミングの入門書などには、初心者でも理解できそうな比較的簡単ないくつかのサンプルコードがありますが、それは初心者でも簡単に書けそうな技術だけを抜粋してるという、あくまで例外です。

RPGならたとえば、ドラクエ3のような戦争画面の行動順を処理するソート機能をつくるだけでも一苦労ですし、ほかにも道具・アイテムなどの自動整理機能をはじめとする標準機能を作るだけでも一苦労です。

決して上手い人のサンプルコードをコピーペーストをして終わりという訳にはいかず(そもそも現状そのようなサンプルコードがネットに無いですが)、もし仮にサンプルコードがネット上に公開されていても、自作品に組み込む際にさらにそれをデバッグ(決してテストプレイの意味ではなく、実際にコード修正が必要になります)しなければならず、プログラミング言語の理解が必要です。

ともかく、ゲームのプログラミングは決して楽ではないし、仮にもし楽だとしたら、じゃあゲーム会社のプログラマー職の人の仕事は何なんだ・・・という疑問につながりますよね(デマを言ってる人は、この疑問を脳内に都合よく無視しますが)。

ツクールやエディタのような制作ツールを使えば、C言語的なプログラミングは不要ですが、それはそのツクールなどのツールを開発している人達にプログラミングを肩代わりしてもらっているだけですので、決して「ゲームプログラミングが楽」ではないでしょう。楽だというなら、じゃあツクール開発元の角川書店およびその発注先ソフトメーカーのプログラミングが楽だとでも言うのか・・・(デマを言ってる人はこの疑問を無視します)。

そもそもコンピューターゲームというのはプログラミングがなければ成立しないのですから、そのプログラミングの価値を貶めて平気な人は、コンピューターゲームにかかわる資格はないでしょう。

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

IT的な留意点編集

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

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

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

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

アクションゲームを作りたいなら、『w:アクションゲームツクール』があります。これらツクール製品は有料製品です。(なお、かつて『w: 2D格闘ツクール2nd.』というのがありましたが、しかし現在ではサポート切れのため、現代の市販の十字キーコントローラーが初期設定では動かない、一部のボタンしか使えないなど問題点があります。)

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

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

C言語などによるプログラムは、上記のゲーム開発ツールを使わない場合の選択肢になるでしょう。

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

なお、上記の開発ツールはほとんどがWindows用のソフトです。MacやLinuxでは動きません。MacやLinuxで動作するゲームを作りたい場合は、別のソフトウエアを使う必要があります。

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

一般的に初心者が、ゲーム開発ツールを作ることはほぼ不可能です。初心者は開発ツールを作ることは考えずに、まず1本、とりあえずゲーム自体を完成させてみましょう。開発ツールを自作したいのなら、まず先にゲーム1本を完成させたあとに、あとから開発ツールとゲーム作品の分離などに取り掛かるのが推奨です。

商業ゲームの開発言語編集

基本的に、現代の商業ゲームは、C言語で開発をする。

ただし、ファミコンの古いゲームは、アセンブラで開発されていた。ファミリーコンピューターからスーパーファミコンに至るまで、OSは搭載されていない[4]

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

また、プレイステーションのOSは独自仕様である[4]

カプコンなど一部の企業は、OSによる開発ではなく、移植性を高めるために自社製の内製フレームワークを用いて開発する。カプコンの場合、2010年頃は「MTフレームワーク」という自社製フレームワークを用いて開発を行っていた[4]

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

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

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

基本的に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関係

例えば、かつて Adobe の Flash が、ブラウザで動かせるゲームを作る際に、よく使われていました。このようなwebブラウザ上で動くゲームのことを一般に、「ブラウザゲーム」と言います。ただし、現在ではFlashは廃止の方向です、すでにほぼ廃止されているといっていいでしょう。また、現状では、ローカルPC環境でのゲームをJavaScriptで作るのは、アマチュア段階では困難です。JavaScriptのアマチュアゲームと言う事例を聞きません。

JavaScript

なお、JavaScript はクロスプラットフォームですが、しかし、セキュリティ上の理由などから、いくつかの機能(たとえばファイル入出力)がwebブラウザ上では使えないようになっており、そのため、JavaScript だけでゲームを作るのは、初歩的なゲームを除くと、かなり困難です。(おそらく、オンラインゲームでは、サーバー側でPHPやサーバサイドJavaScriptなどの別プログラムが走っていると思われます。)

セーブ機能の必要なゲームを作る場合は、JavaScriptでの開発は選択肢にない(セーブの実装には、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年現在)。


プラットフォ-ム編集

ライセンス料

一般に、プレイステーションや任天堂のゲームを開発するには、専用の機材が必要であり、そのため、ソニーや任天堂とライセンス契約しなければいけない[8]

その契約に際して、ライセンス費用または料金と呼ばれるものを、ゲーム機開発会社の任天堂、ソニーに支払う必要があります。

現代でもソニーや任天堂のゲーム機用のソフト開発・販売には、ライセンス料が必要です。少なくともPS4やニンテンドースイッチのパッケージソフト開発には、「ライセンス費」が必要[9]

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

また、スマートフォン向けアプリは、プラットフォーム使用料が掛かります。 書籍『ゲームプランとデザインの教科書』によると AppleStore, GooglePlayともに売上げの30%とのこと[11]。その他のプラットフォームも、大体同じとのことです(参考文献の著作の時点では)。

Google やAppleのようにプラットフォームを提供している企業のことをプラットファーマーと言います[12]

昔からゲーム機のライセンス料は有料で高額であり、ソニーや任天堂の収益源のひとつになっている[13]。一方、パソコンゲームにはライセンス料が無いのが普通です[14]

なお、ハードメーカーでなければプラットファーマーでもないゲーム会社のうち、製造から販売までを手がける会社のことをパブリッシャーといい、たとえばカプコンやコナミやセガやスクウェア・エニックスやバンダイナムコなどがパブリッシャーです[15]

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


ポリコレ規制

Apple社のAppStore向けのスマートフォンアプリでは、アップロード後に、公開前にAppleによる審査があり[17]。、 審査は欧米基準です。

GooglePlayは、公開前の審査はないが公開開始後に海外基準で審査されるので、それに違反していると配信停止になります[17]

海外プラットフォームで販売・配布したい場合、「ポリティカル・コレクトネス」(政治的な正しさ)といわれる、海外の公序良俗の基準に配慮する必要があります[18]

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

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

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

プロトタイプ編集

ともかくゲームでは、曲や絵がよくても「なんかゲームとしてはイマイチ」という現象も起こりえます。(ゲーム企業では、この事態を防ぐために、ゲーム制作の初期段階ではイメージイラストなど簡略なイラストだけでプログラム中心のゲームの試作品(プロトタイプ)を幾つも作ったりして、その いくつもある試作品のグループの中から面白い作品だけを商品化の候補に選んで、さらにプログラムがある程度の完成度になってから、本格的に商品化を決めていって、そしてイラストや音楽などを本格的に作り込んでいく/発注していく等、という感じの製作手順になっています。)

書籍『ゲームプランナー入門』(吉冨賢介 著)によると、ゲーム業界では、企画書に書かれたゲームが本当に面白いかどうかを確認するために、「プロトタイプ」が作られます[19]。 プロトタイプの段階で制作に主に関わるのはプログラマーですが、企画の意図を説明するためにプランナーも関わります[20]

文献『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』によれば、イラストレーターは、プロトタイプの前段階あたりでイメージイラストなどを提供してスタッフ同士でイメージ共有させるのが仕事です[21]。一方、プロトタイプの段階では、イラストレーターの仕事は、グラフィック案の提案などに留めるようです[22]。サウンドも同様、プロトタイプの段階では、曲調を固めていく段階です[23]


※ ただし、時々よくあるトラブルとして、マイナーな同人ゲームや零細ゲームメーカーのゲームなどで、他社の商業イラストで背景イラストや脇役キャラクターなど目立たない部分のイラストが使われているトラブルがときどき報告されています。おそらく試作用に流用したイラストが、そのまま製品に混入したのでしょう。こういうトラブルがあるので、他社イラストの使用は試作であっても避けるべきです。
※ アニメ業界や映画業界とかの製作手順や試写会の手順とかとは、大幅にゲーム業界の制作手順は違います。
  • 実装検証

また、プログラマーの仕事として、文献『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』によれば、そのゲームのプログラム中でコアになるプログラムやシステムやミドルウェア類などは、プロトタイプ段階で実装検証を済ませておく必要があります。

プロトタイプより前の「原案」などの段階では、利用するミドルウェアの洗い出しをしたり、あるいは出来る範囲で基礎実験をしていきます[24]

なお、ミドルウェアによっては使用料が発生する場合もありますので、その点を事前に調べておく必要があります[25]


プロトタイプのうち、「画面だけ」とかのハリボテの状態のものを「モックアップ」とも言います[26]

一方、プロトタイプのうち、とりあえず遊べる状態にまで作ってあるもののことを「プレアブル」と言います[27]

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

知的財産権には著作権・商標権・意匠権などがありますが、商標権は特に強い権利であり、商標権には気をつける必要があります。

意匠権とは、建物や工業製品の概観に関する権利なので、ゲームビジネスではあまり気にする必要はないですト[28]

「特許権・実用新案権」と「商標権」は、事業者によって国に登録されている権利なので、かなり強力な権利であるので、気をつける必要があります。

特許権や実用新案権とは、大まかに言えば、技術的な発明に関する権利です。


商標が登録されているかどうかは、特許庁の『特許情報プラットフォーム』というwebサイト[29]で確認できます。

(「webサイト」と英数字まじりで書くと「ウェブサイト」とカタカナで書き直そうとするおかしな独自ルールを押し付けてくる人が世界には存在しますが、しかし参考文献『ゲームプランとデザインの教科書』には「webサイト」と表記されています。)

残念なことなのですが、世の中には、自社でビジネス展開をする気のない商標を登録する人や、あるいは他社の商品などでまだ登録されていないものを登録する人がいます。

そのような商標登録申請でも、登録が認可されてしまうのが現状です。


また、商標は業種のジャンルごとに分かれているので、たとえば携帯電話のジャンルが新たに追加された時代に、過去のゲームの商標を登録した人がいました[30]で確認できます。 。 このような商標申請でも登録できてしまうのです。

なので、携帯ゲームを出せなかったり、買い戻したり裁判をするのに時間がお金がかかってしまう場合もあります[31]で確認できます。


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

『ゲームプランとデザインの教科書によると、初心者によくある事例らしいのですが、他人の個人サイトやSNSで公開されていた絵や曲などを、許可なく勝手に使う事例があるらしいです[32]

二次利用を許可されてない著作物を素材として使うのは、やめましょう。

あと、見落としがちなのが、フォントの著作権です[33]。 フォントにも著作権があります。気をつけましょう。


フリー素材と書かれていても、商用販売が禁止されている配布形態のものもありますので、気をつけましょう。


アイデアの権利の問題

編集時の現状(2022年1月)では出典がSNSにおける商業ゲーム作家たちの発言なので当wikiでは出典を紹介できないのですが、

ゲーム業界が直面している問題の一つとして、外部の人がアイデアを一方的に押し付けてきて、作品に類似点があったら「アイデア使用料を払え」など金銭を要求してくる、まるで 押し売り のような厄介な人達に悩まされていると言われています。

こういった問題があるため、ゲーム会社では原則、

送られてきたハガキやメールは、まずクリエイター以外の事務系の人間が読む。
もしハガキなどにアイデアがあった場合、そのハガキを処分。

などの方策を取ると言われています。

また、偶然にアイデアが一致してしまった場合に備えてのリスク回避として、事前に会社のウェブサイトなどで「弊社にアイデアが送られてきた場合、そのアイデアは弊社のものになります」のような宣言をしている会社も多くあると言われています。(以上、作家のSNS発言やそれを紹介したサイトの取材などのまとめ.)

Linuxのようなオープンソースの界隈では考えられない事態ですが、しかし商業の世界というか娯楽の世界では、厄介な消費者がいるのです。おそらくゲーム産業に限らず、アニメ産業やマンガ産業あるいはその他の娯楽産業などでも同様の問題があるでしょう。

法学的には、そもそも著作権法はアイデアを保護しないのですが(『アイデア・表現の二分論』と言います)、しかしゲームファンやアニメファンやマンガファンの多くはそういう亊は理解していません。そもそも子供でも分かるようにゲームやアニメなどの多くは作られているので、残念ながらこの分野の消費者には法律知識が子供レベルのままの人も多いのが現状です。たとえばある作家の新作に、過去の別作家の作品とのアイデアの類似点が多ければ「パクリ」だ何だのとターゲット層は言います。

娯楽産業は基本、そういう無知な人達を相手に商売している業界です。

また、法律上は「著作権はアイデアを保護しない」といっても、しかし実際の裁判では業界の慣習が裁判官の心証形成に影響を与える事も多いので、無知なゲームファンの勘違いが裁判やその他の公的機関などに影響を与えてしまう可能性も考えられます。日本は民主主義である以上、無知な大衆の考えであっても司法や政治や行政にある程度は影響を与えてしまうのです。

だからもし読者がゲーム会社への就活などを考える場合も、こういった問題も考えて、厄介消費者かと誤解されないような方法によって就活しなければならないでしょう。就活するなら、けっしてアイデアやら仕様書やら企画書をゲーム会社に送りつけるのではなく、ゲーム会社の提供している正規の就活の手続きを利用して就活しなければならないでしょうか。


上述の「アニメ・マンガ・ゲーム産業の消費者層が馬鹿」論は、別に本wikiのオリジナルでもなければ偏見でもなく、もう1990年代あたりに散々、議論されたことです。疑うなら、たとえばアニメ評論家の岡田斗司夫の著作『東大オタク学講座』や『マジメな話』でも読んでください。

当時の岡田は、オタクには知性が子供レベルの馬鹿も多いということを認めたうえで、でもそういう馬鹿とも一緒に仲良くしてオタク産業を盛り上げていくべきだという持論でした。その後のアニメ産業やアニメ評論では岡田は尊敬されなくなりましたが、しかしオタク産業の宣伝は岡田の提唱のようにおおむね馬鹿をも包摂するように進み、そしてその結果が2010年以降の現代です。


商業ゲームでの実例として、任天堂『ゼルダの伝説 ブレス オブ ザ ワイルド』は、プロトタイプの段階ではイラストや音楽を組み込まずに(イラストは、代わりに大きなドットの塊などで代用する)作られている事がゲーム業界見本市イベント CEDEC 2017 で公開されています[34]

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

※ なお「プロトタイプ開発」という手法について、現代の日本では既に高校の段階で、高校教員に要求される程度の基礎知識になっており、たとえば『高等学校情報/その他の技術的な話題#プロトタイプ開発』などを参照せよ(高校教員向けの文科省の研修本にプロトタイプ開発の話題がある)。

ここでいう「プロトタイプ」(試作品)とは、まず当然にコンピュータプログラムのゲームとして動作するのが前提です。さらに、けっして字面「試作」どおりに単に「とりあえず作ってみる」だけではなくて、さらに、たとえば映画製作でいう絵コンテ試写のように、ゲームの試作では、なるべく早期にとりあえず第三者が試作ゲームを遊べるように試作品を作っていく必要があります。

書籍『ゲームプランとデザインの教科書』でも「プロトタイプ」という言葉は使われています[35]

また、少なくともニコニコ動画を経営では使われています。ニコニコ動画の経営者の川上量生が使っています[36]。これはつまり、川上が角川書店も買収したので、カドカワもそうであるという意味です。カドカワは現在、RPGツクールの販売元でもあります。 

そして、ゲームのプロトタイプの教訓としては、「汚く作って、やりなおせ」です[37]。学生などで「まず勉強してから」とか言う人は、いつまで経っても作り始めない、と書籍『ゲームプランとデザインの教科書』で言われています。チーム製作をしている場合でも「プロトタイプは赤ん坊」みたいなものなので、育てていこうという気持ちで見ていくものです[38]

けっして「先に勉強してから」ではなく、そうではなくて、先にとにかく汚くていいので作ってみると、「あとから何を勉強すればいいか」が的確に見つかっていくのです。

そういう手法を「クイック&ダーティ」[39]といいます。英語では「quick and dirty prototype」と言います[40]

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

それよりも効果的なのは、ゲーム形式でシナリオを書いてしまうことだと、書籍では述べられており、シナリオ中に「CHR:ヒロインA(私服)、表示」見たいな文章をシナリオ中に書いてしまうことだと、述べられています[41]

参考文献のその章では、シナリオライター志望者に向けて語られているので、プログラマー志望者については、特に語られていません。

まあ、常識的に考えて、プログラマー志望なら実際にゲームを作ってしまうのが早いと思います(参考文献の人がどう思っているのかは知りません)。なぜなら、そうすれば、シナリオのあるゲームをつくっている場合なら自然に「CHR:ヒロインA(私服)、表示」みたいな内容に該当することを考えることにもなりますので。


任天堂以外の参考例として、プロトタイプといえるかどうか分かりませんが、1990年代の古い参考例として、1990年代の漫画で『ゲームクリエイター列伝』という週刊少年マガジンに不定期掲載していた読みきり漫画があるのですが、wiki編集者の手元にそのマンガがないのでうろ覚えなので間違った説明をしてしまうかもしれませんが、この漫画でカプコン社のゲーム『バイオハザード』を扱った『バイオハザードを創った男達』の際、たしかその回の前半で、バイオハザードのゲームデザイナーが大幅な作り直しを指示したとあるのですが、しかしのちにゲーム評論家の阿部広樹の評によると、おおむね「あの漫画には、最初のほうの作り直しをさも大きな決断のように書いてあるけど、そういう指示はゲームデザイナーの普通の仕事だよ」みたいな内容のことを阿部は著書で言っていました。


試作しなければ0点

どんなに立派な企画があろうが、試作しなければアイデアの価値は0点でしょう。

世間の多くの人は、自分の価値を「100点中で自分は最初は50点」と思っていて、「成功すれば加点されていき、失敗すれば減点されていく」というような世界観で生きています。 しかし、少なくともゲーム業界は違い、「0点から始まるので、失敗を恐れて何もしなければ0点のまま」です。これは、文脈はやや違いますが、ゲーム会社で『サクラ大戦』シリーズなどで有名なプロデューサーおよびゲーム会社社長であった広井王子が、何かの書籍のインタビューで自分の社長としての人材評価は「0点」から始まる「加点法」で自分は人を評価していると答えていたことがあります。

広井氏はべつにゲーム業界志望者に向けて発言したわけではないので、プロトタイプを作れとは言ってません。しかし常識的に考えて、広井氏のような考えかたをするなら、ゲーム業界を目指す人ならばとりあえず手元のパソコンでさっさとプロトタイプを作るべきだという発想に至るでしょう。さて、書籍ではなくSNSなどでゲーム作家の発言を読んでも、「あれこれ理論を学ぶよりも前に、さっさと試作品を作るべきだ」と主張しているのが、多くのゲーム作家たちの意見です。実際のゲーム業界の先輩たちのアドバイスが、けっして「ゲームをプレイせよ」ではなく、「まずゲームを作れ」なのもポイントです。まあ、最低限「商業ゲームを最低1本はプレイしたことある」ぐらいのプレイは必要でしょうが。

さて、2010年以降の現代でも『ゲームデザイン プロフェッショナル』著者は、文脈は違いますが「加点方式で物事を考える」と述べています[42]。また、加点方式で考えることにより、利点として、高すぎる期待によって慎重のあまり行動が遅くなることを、加点方式なら未然防止できるので、開発スピードが早くなり効率的になります(『ゲームデザイン プロフェッショナル』、P224 をもとにwiki著者がそう解釈)。


まあ、果たして21世紀の現代の現実のゲームファンがそのような自分を「0点」としてとらえているかどうか疑わしいですが(ネットの自称ゲームファンたちの揚げ足取りをみると、彼ら自称ファンの価値観は疑わしい)、少なくともゲーム会社での制作の現場では「何もしなければ0点」でしょう。

人生が何点満点か分かりませんが、少なくとも試作などの行動を開始すれば、どんなに試作の結果が酷評であっても、作家としての加点はされていきます(行動内容が違法でない限りは)。

たとえ自作の評判が悪かったとしても、「こういう作品だと評判が悪い」(評判が正しいか否かは知らないが)といった知見が得られます。



単に「仕様書を書いてみた」、「設定資料を書いてみた」ではなく、実際にコンピュータプログラムとしてプログラムにしてみて、さらに、とりあえずは第三者が遊べるように、「試作」を目指しましょう[43]


もっとも「短くまとめる」というのも、ある程度の経験と能力が必要なことですので、無理して最短にまとめる必要も無いですが、ともかく、新人はとりあえずの完成品を1個作るのが、どの業界でも先決だろうと思われます。

アルファ版との違い編集

アルファ版とは、プロトタイプは違います。アルファ版とは、ゲームの全体像が分かる一部分を、「商品レベル」で作ることです[44]

プロトタイプと同じく、アルファ版でも、そのゲームが本当に面白いかどうかを確認します。商品に向けた検証なので、サウンドスタッフ[45]やビジュアルもアルファ版では商品レベル相当で組み込みます。

アルファ版での出来が悪かったら、最悪の場合、プロジェクト中止です[46]

ベータ版とは、会社によって意味が多少違いますが(たとえば『ゲームデザインプロフェッショナル』と『ゲームプランナ-入門』とで微妙に違う)、おおむね、とりあえずのゲーム最初からエンディングまでの完成間近をひととおり遊べる状態のことです[47]

細かいバグ修正はこれらの段階では後回しにします。

基本的に

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

の流れです。


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

数学は後回し編集

ゲーム制作の作り始めにおいて、数学や物理の予備知識は、それほど多くありません。

文献『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』によれば、やみくもに数学や物理を勉強するのではなく、3Dの勉強などで必要を感じたら、そのつど、その分野の数学や物理を学ぶのが効率的だと述べており、また可能なら実際にプログラミングでその理論を試してみると具体的に理解をしやすいと述べています[48]


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

C言語を使ったゲームは、予備知識はそれほど多くないので、さっさと作り始めるのが肝心です。

せいぜい市販のC言語入門書で「配列」や「関数」など、どこの入門書にもある基本的機能を一通り習得したら、あとは Visual C++ で映像出力とキーボ-ド入力さえを1~2週間ほど勉強したら、とりあえずもうVisual Studio を起動してゲームを作り始めることが可能です。面白い作品かどうかはともかく。

だから、その気になれば、とりあえず数ヶ月以内に、パソコン用の非ネット通信のゲームならば作ることはできます。だから、さっさとゲームを作り始めましょう。

それ以上の勉強は、趣味だとして自己責任でやるのは構いませんし、

十年後ぐらいの未来の投資だと思って勉強するの構いませんが、

しかし「もしゲーム制作の初期段階なのに、入門書レベル+α以上の知識が絶対に必要」だと思っているなら、

それはどこかの業者とかにダマされています。

作業リストを作る編集

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

ゲームを作る際、けっしてアタマの中であれこれとアイデアを考えるだけでなく、まずそのアイデアを文章に書き出しましょう。

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


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

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


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

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


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

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

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

と書くのではないです。

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

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

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

こうすることで、作業がひとつずつ比較的に簡単な作業に分解されていくので、ラクになります。(余談ですが、バージョン管理ソフトなどを使ってバージョン管理している場合にも、上記のような作業リストの分解をしておけば、各バージョンの概要を書く際にも作業リストの項目が転用できるので、一石二鳥です。)


スケジュール帳ではないので、予定日とかは、ひとますは不要です。(たといスケジュール管理する場合でも、他の場所に書くべき。)

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

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

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


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


作業リストの更新編集

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


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

さて、作業項目がひとつ終わったら、その項目はけっして消さずに、「【完了!】」とか、なんかそういう情報を、項目の前または後ろにつけます。 なぜなら、もし完了したことを忘れると、あとでまた調べなおしとかで困るので、完了の記録も残しておきます。

たとえば

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

のようになるワケです。

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

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

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

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


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

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


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

あるいは

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

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

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

プロトタイプ制作における創作面の大まかな検討事項編集

「ゲーム性」編集

ゲームには、「ゲーム性」というものが必要です。これはプレステの開発元のソニーですら、そう認識しています。「ゲーム性」が何かという定義は難しいのですが、ともかく昔から言われてます。ジャンルにもよりますが、「駆け引き」とか「戦術」とかが「ゲーム性」だとよく言われます。 『ゲームプランとデザインの教科書』によると、ゲーム性とは、シューティングやアクションでは「対戦の駆け引き」、RPGでは「戦闘と物語の介入」、シミュレーションゲームなら「戦略性」だそうです[50]

ただし『ゲームプランとデザインの教科書』によると、1990年代は今よりもゲーム性とシステムが重視されていたとの説明があるので、 裏を返せば2010年以降の現代では、ゲーム業界ではゲーム性の重視の比率は1990年代よりも減っているかもしれません[51]

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


ゲーム『I.Q』の事例

下記の話は映画監督の川村元気の対談集『理系に学ぶ』で読めるのですが、対談相手のアーティストで電通出身でテレビCM業界出身のアーティストである佐藤雅彦が、ソニー・コンピュータ・エンターテインメントとの共同企画で、のちに「I.Q」(1997年にシリーズ第一弾を発売)といわれるゲーム開発したときに、

当初はゲーム業界のことをまだよく知らない佐藤が、ゲーム性がほぼ皆無のゲームのプロトタイプを作ってしまい、 そのせいで、企画会議などではソニーの偉い人の顔がとても暗くなってしまったという失敗談があります[53]

なんでソニーの偉い人の顔が暗いのか分からなかった佐藤は、階段の踊り場でソニーの新人を問い詰めたら、「それが、あの、ゲーム性がないっていうか・・・」と言われたと対談集に書かれています[54]

正確には、佐藤本人はプロトタイプの企画を提案しただけであり、参考文献によるとソニー内には企画をもとにプロトタイプをつくる部署があるらしく、1~2ヶ月で作成されたそのプロトタイプをソニー上層部がプレイしたか見た結果、ソニーの偉い人の表情が暗くなったようです。佐藤がソニーに始めに企画を提案したとき、ソニー側から「その世界観だけなら、1、2ヶ月あれば再現できますよ」というので佐藤がお願いしたところ、上述のようなゲーム性のほぼゼロのプロトタイプが出来上がってしまったようです。

ちなみにこの佐藤氏、業績では、お菓子の湖池屋ポリンキーのCM 、ビールのモルツ、NHK Eテレ『ピタゴラスイッチ』、90年代の流行歌『だんご三兄弟』、など数々のヒット企画を手がけたベテランです。


創作面の留意点編集

プレイヤーはゲームを見た目で判断する編集

一般のプレイヤーはゲームを見た目で判断します。どんなに操作性がよくっても、まず分かってくれません。「プロトタイプでは見た目をみない」とか言っても、そんなのはゲーム業界内部にしか分かってもらえません。

たとえば実際、スーファミRPG『新桃太郎伝説』では、開発当初のドラクエ5的なマップ画面のドップビューのUIだったの、開発中にクォータービューの他社製RPGが出てヒットしたので、桃伝のマップUIを(トップビューではなく)クォータービューに作り直しています。 そう、攻略本『新桃太郎伝説 究極本』に開発裏話が乗っています。

21世紀の現代でも同様です。『ゲームデザイン プロフェッショナル』では、著書であるFGOクリエイター塩川氏は、ライバル企業の画面と自社製品とを実際に目で見比べる分析手法によって、自社製品のUIの問題点を見つけ出していっています[55]

しかも見た目が「かっこいい」かとか、「ぱっと見の派手さ」とか、そういう素人目でも一目瞭然で分かるところに、注力しなければなりません[56]

どんなに「私たちのゲームをよく見れば分かる」とか、「操作していけば分かる」とか作り手が思っていても、仮に実際に良く見れば技巧的な設計だったとしても、しかし見た目が「かっこいい」とかでなければ、プレイヤーがゲームのプレイ開始自体をしてくれないのです。

もしエンタメ系を仕事にするなら、こういう事にも気を配らなければならなくなります。


ゲーム開発ツールを使う場合編集

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

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

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

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

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

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


GPLライセンス違反事件

GPL(ジーピーエル)というライセンスがあって、Linuxなどのオープンソースで使われています。このGPLを組み込んだプログラムは、ソース公開しないといけなくなります。

なので、ソース公開したくないプログラムにGPLソフトウェアを組み込みのは、絶対にやめましょう。

過去、ゲーム業界でも、誤ってGPLライセンスのソフトウェアを組み込んでしまったために、呼出し元ソフトウェアでのソースコードの一部を公開する羽目になったゲーム会社もあります。2005年頃、『ToHeart2』という美少女ゲームが、xvidというGPLソフトを取り込んだ疑惑によって、GPL違反の疑いでソース公開になった過去があります。(w:ToHeart2#GPL違反とソース公開

GPLでも一応、たとえばLinuxサーバ上でソース非公開のアプリを動かすように、GPLのソフトウェアを非公開ソフトとは独立した状態で使うぶんには、ソース公開する必要はないとされています。(でないと、オンラインのプログラムやネットゲームなどは全てソース公開せざるを得なくなり、非合理な結果にある。)

ただし、GPLソフトウェアのコードを1行でも取り込むと、ライセンス違反によりソース公開を要求されてしまいます。


BSDライセンスなど

オープンソースの中には、どのような利用法であっても、利用者にソース公開を求めないライセンスもあります(つまり、ソース公開しなくていいライセンスである)。BSDライセンスというライセンスがそれで、ソース非公開で利用できます。またMITライセンスも同様に、ソース非公開で利用できます。

実際、ゲーム制作ツールの吉里吉里Zは、修正BSDライセンスで公開されています。

もしライセンスのことがよくわからない、またはゲーム制作にあまり本質的でないと思いライセンスの学習に時間をかけたくないなら、オープンソースのツールを使うなら、BSDライセンスを使うのが安全です。


なお、DXライブラリは、GPlでもなければBSDライセンスでもありません(DXライブラリ説明書「DxLib.txt」を読んでも、どこにも「GPL」とも「BSD」とも書いていません)。DXライブラリは単にソースコードが公開されていて、著作権者の「山田 巧」氏が著作権を保持しているオープンソースなライブラリです。

このように、ネット上でソース公開されているソフトウェアには、ライセンスの複雑な解釈を嫌ってか、「BSD」だの「MIT」だのすらライセンス条件を名乗らないオープンソースのソフトウェアもあります。


自作ソフトでソース開示すべきかどうか?

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

しかしユーザーの中には倫理観やリテラシーの低い人も含まれており、そのため、他人のゲームを利用して誹謗中傷などの表現を行う人もいるかもしれません。他人のゲームのソースコードを使って、「なりすまし」のイタズラをする、迷惑な人もいるかもしれません。

このため、ライセンスに、利用による損害に対する保証が無いこと、を明示しましょう。大抵の著名なフリーソフトウェアライセンスには、この条項がありますので、積極的に利用しましょう。これは、作品の乗っ取りに対する保護にもなります。


開発ツールの限界編集

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

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

技術的な機能制限編集

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

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

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

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

このような欠点のためゲーム開発ツールによるゲーム制作では、あまり大作を作ろうとしないほうが安全です。開発ツールで作る作品は、比較的に小規模な作品に、とどめておきましょう。

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

開発ツールを使う場合、 Visual C++ のコードを書かずに、ほぼマウス操作だけでプログラムを作ろうとしているわけですから、何かしらの制限があります。拡張性の悪さは、プログラム文法などの学習の負担を減らすためのトレード・オフのようなものだと思って、適材適所に用途に応じて開発ツールを選びましょう。

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

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

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

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

「デザイナー」とイラストレーターの違い編集

ゲームのイラストを作る部門や、音楽をつくる部門のことは、まとめて「アーティスト」とか呼びます。

けっしてゲーム用イラストレーターのことを「デザイナー」とは呼びません。なぜならゲーム業界の場合、もし「デザイナー」と言ったら、プランナーやディレクターなどのことであり、管理職的な設計者のことを言うからです。(そもそも設計を英語で design という。)

映像といっても、静止画のイラストレーター、ムービー担当者(アニメーターなどという)、3D-CGのCGデザイナーなど、さまざまな役職名がありますので、画像系のアーティストをまとめて「グラフィッカー」と言ったりもします。当然、音楽を制作する人は、グラフィッカーには含まれないです。

なお、ゲーム会社でアニメータといったも3D-CGの制作者のことだったりします。アニメ会社でいう「アニメータ」とは意味が違いますので、混同しないように。

なお、テレビアニメ業界とゲーム業界のイラスト分野とで、「原画」や「仕上げ」や「絵コンテ」など、共通の言葉が使われますが、しかし意味がアニメ業界とゲーム業界では若干違います。混同しないように気をつけましょう。

操作性編集

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


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

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

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

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

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

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

処理速度の問題編集

ゲームの場合、処理速後が必要です。なので最終的には、必ずしも関数や変数を多く使ってプログラミングするのが良いとは限りません。なぜなら関数や変数は、とても若干ですが必要な処理を増やしますので、処理速度が低下します。

いくらCPUが1秒間に数ギガHz(1秒あたり数十億回)の命令をするほど速いといっても、野放図に膨大な命令回数のプログラミングをしていては、そのうち処理速度が低下してしまいます。数学の中学高校レベルの指数計算についての雑学で「新聞紙を42回おりたたむと、月に届く距離になる」という雑学があります。コードの組み合わせによっては、新聞紙のおりたたみのように結果的に計算量が膨大に増大している場合もありえるので、そうならないように注意しながらプログラミングをしていく必要があります。

ですが、このセクションで後述するように、関数を用いる場合の解決策(※概要:あとでdefineやinlineに置き換え)があるので、プログラミングの初期のほうは、とりあえずバグを未然防止するために関数を活用するべきでしょう。


1980年代あたりのファミコンなど古い時代のゲームでは、ストレージ容量(ハードディスク容量のこと)が、ボトルネックでした。よく、ファミコン時代の商業ゲームの制作裏話でRPG「容量不足でイベントをいくつか削りました」などとゲーム作家が述べているのは、現代でいうストレージ容量の不足のことである。(なお当時はROMカセット。だからファミコンにハードディスクは無い。なので本文では「ストレージ容量」という言い方をした。)

しかし2010年以降の現代では、ボトルネックになっている要因は、ストレージ容量不足よりも処理速度です。


これはつまり、ゲームプログラミングに要求させるコード特性は、科学計算ソフトウェアやら金融プログラミングなどのプログラミング手法とは異なります。このためゲームプログラミングでは、大学などの一般の情報工学・情報科学の教科書的な「構造化プログラミング」など歴史的なプログラミング・パラダイムの理念には、一見すると(ゲームプログラミングは)反するようなコード開発方針になる場合もあります。


ツクールなど制作ツールとの処理速度の兼ね合い

実際、ゲーム制作ソフトのRPGツクールをつくっているカドカワ(アスキー社→エンターブレイン社→カドカワ(かつての「角川書店」) )は、PRGツクールでのアクションゲーム開発はまったく薦めていません。アクションゲームに関してはカドカワはPRGツクールとは別途、「アクションゲームツクール」を販売しており、ツクールでアクションゲームを作りたい場合には(RPGツクールではなく)アクションゲームツクールでのゲーム制作をするようにとカドカワは薦めています。

アクションゲーム と ターン制RPG では要求される特性が大きく異なり、なかには、ほぼ対立しているような特定もあります。

どうやらツクールやウディタでも、けっして何でもかんでもカスタマイズできるわけではなく、カスタマイズしても処理速度のあまり低下しないような箇所だけをカスタマイズできるような仕組みになっているようです。

だから、ツクールもウディタも、例えばマップ操作のルーチンや戦闘画面のルーチンなどといった基本システムのルーチンそのものは、あまりカスタマイズできません。カスタマイズできるのは、画像や音楽を除けば、あとは戦闘プログラムなら「コマンド」などの命令など一部の派生的な部分だけがカスタマイズできるようになっているのです。

だからツクールなどでどうしてもアクションRPGを作りたい場合、けっして基本システムの改造ではなく、別途、アクションRPGっぽい動作をするマップイベントを作成する・・・といった流れにでもなるでしょう。なのでツクールやウディタ以外でターン制RPG以外のジャンルを制作するのには、実質的には限界があり、さまざまな制約が生じます。


具体的な手法

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

通常の関数で記述していったソースコードを、あとから一括変換などでdefineマクロやinline関数などに置き換えることは比較的に容易です。

また、関数を経由しているので、マクロを使った場合でも比較的にバグが混入しづらくなっているかもしれません。(defineなどの前処理命令マクロは、用いるとバグを発見しづらいので、なるべくマクロの利用を避けるべきなのが、ゲームプログラミングに限らないプログラミングの定石です。)

一方、まったく関数を使ってないコードを、あとからdefineマクロなどに手作業で置き換えるのは、なかなか面倒です。

どうせ最終的に一括変換などで置き換えるのだったら、だったら途中経過の段階では、処理速度をあまり気にせずに関数を使うべきでしょう。

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


たとえば、処理に0.5秒ほどの時間の掛かってもかまわないような場所は、どんどん、関数に置き換えていっても良いかもしれません。

アクション性のないゲームなら、関数をぞんぶんに活用できます。

ターン制RPGやシミュレーションゲーム、アドベンチャーゲームなど、関数を活用しやすいでしょう。

逆に、アクションゲームなどでキャラ操作中のコードのように頻繁に使って、しかもそのゲームの中心的なコードなら、そこは最終的には関数に置き換えしないほうが良いかもしれません。

このように、ゲームのジャンルによって処理速度に対する必要な水準が異なりますので、よってプログラミング時における関数などの利用の方針も異なります。


また、なんでもかんでも関数にするのは避けるべきです。関数は処理速度の問題がありますので、必要性のある部分だけ関数にするべきでしょう。関数を使わなくても、for文やif文などのブロックの構成を適切に組み合わせることで、コード中のmain関数以降の部分でコード共通化できることは色々とあります。

「共通性のあるコードだから」と言って、大して長いわけでもないコードを関数に置き換えるのは、「処理速度の問題を分かってない」と思われても仕方無いでしょう。


2Dの画面出力編集

概要編集

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

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

目次編集

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

3Dグラフィック編集

RPG編集

アクション編集

※未作成

パズル編集

※未作成

シミュレーション編集

※未作成

ゲームのデバッグ編集

入力編集

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

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


ゲームエンジン ※未完成編集

  • ゲームプログラミング/Unity ※リンク先ページの編集者が現状ではUnityの著作・調査を放棄中なので、調べ物としては役立ちません(2021年12月19日に本文を記述)。

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

バランス調整編集

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

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

※ もしこのページがないと、プログラミングのページでゲームデザイン的なことを説明する羽目になるので、なるべく分離したい、という編集上の都合もある。

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

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

未分類編集

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

rand 関数そのものの、乱数としての精度そのものの問題というのがあり、科学技術計算では問題になるが、しかし入門的な試作ゲームを作る段階では不要なので、説明を省略する。


画像の ちらつき編集

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

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

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


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

DirectXのスワップチェーンとは、要するに、「DirectXでは自動的にダブルバッファリングを行えます」ということに過ぎない。なのでDirectXによる開発環境の場合、スワップチェーンを利用すれば、画面のチラツキもなくなる。

DXライブラリにも似た名前の似た機能があるが、やってることはスワップチェーンと同じなので、気にしなくていい。


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

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

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

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

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

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

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

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

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

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

つまり、Windows API の CreateFile 関数でなくとも、標準C言語の関数でも Windows ゲーム用のセーブファイルを作成できる。具体的には、標準C言語のfopen関数でも、Windows のGUIなゲーム用のセーブファイルを作成できる。

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

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


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


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

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


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

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


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


その後のセーブ・ロード機能の整備編集

セーブ&ロード機能の作成のプログラミングに挑むなら、セーブから作るほうが作りやすいだろう。

しかし、最終的にセーブ用関数とロード用関数の一部を統合する場合などは、ロード機能を基準に考えたほうが良いだろう。


この理由は、まず、セーブ機能とロード機能では当然、セーブファイルの読み方の書式を統一しなければならない。(でないと、ロードの前後で、ゲーム主人公の能力値や進行状況などが変わってしまい、セーブとしての機能を果たさない。)

なので、ともかくセーブとロードにおけるセーブファイルの書式を統一する必要がある。

ロードのほうが処理が複雑であり、プログラムが複雑になるので、ロード機能を作りやすい書式なら、セーブ機能も作りやすい。つまり、ロードの都合だけしか考えていない書式であっても、比較的ラクにセーブ機能のプログラムを書ける。

一方、セーブ用を基準にして考えたセーブファイル書式は、必ずしも、ロード機能のプログラムを作成しやすいとは限らない。


では、なぜロード機能のプログラムは、複雑になりやすいのか?

まず、セーブの場合、最終的に外部に出力されたデータには、データ型の差異(int型やchar型などの差異)は無く、すべてテキスト文字列として処理されているので、プログラムは比較的に単純である。

しかしロードのほうは、読み取った文字列がint型なのかそれともchar型なのかなどの解釈をプロプラムで指示しなければならないので、よってロードのプログラムはやや複雑になる。こうして、セーブ機能よりもロード機能のほうがプログラムが複雑になりやすいのである。

ゲーム中の特殊イベント編集

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

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

スケジュール管理の教養編集

 
ガントチャートの例:東海発電所の廃止解体工程

個人でのゲーム開発には全くの不要な知識ですが、スケジュール管理表といわれる技法がいくつかあります。

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

仕事 担当 状態 開始 終了予定 終了日
仕事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


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

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

ガントチャートとして図示することで、どこがボトルネックなどのリスク要因になりやすいのかが、一目瞭然です[60]

なので、それを見越して、スケジュール管理をします。


このTRMとガントチャートは、IT業界だけでなく建築工事でも使われるので、 社会人の知識のひとつとして知っておくと良いです。

ガントチャートによるボトルネックの洗い出しも、建築学の教科書でも良く教わる内容です。

よく住宅リフォーム工事などで、一般人でも建築業者の提示するガントチャートを見る機会があります。


新人の段階でそんなの書く機会はないかもしれませんが、しかし知っておくと上司からの命令が理解しやすいので、 知っておくと得でしょう。


ストーリー作成などの順序編集

ストーリー作りに限らず、ゲーム作りではゲーム全体を先に作るのが先決です。ニュアンスは違いますがアトラス社いわく(ゲーム開発では)、おおむね「ゲーム全体に全体に血を回すのが先」といった内容の格言があります[61]

プレイヤーが見たいのは、ゲーム全体のストーリーやテンポといったゲームの全体像です。細部は、あくまで補助的であり、そういった細部に対するプレイヤーの興味も、あくまでオマケの範囲でしかないのです。


さて、暗黙の前提として、ゲームのストーリーは、システムと連携・調和したものでなければなりません。

このため、ゲーム作家によっては、先にシステムを決めてから、あとからストーリーを作るような方法論を採用しているクリエイターもいます[62]

さて、ともかくゲームのストーリー作成は、なんらかの方法で、全体像を先にきめてから、あとから細部を作っていきます。

これを実現するための方法として、いくつかの方法があります。


ドラマの脚本などで使われる、「ハコ書き」という方法を使う人もいます。全体像に当たる「大ハコ」を記述してから、「大ハコ」→「中ハコ」→「小ハコ」と記述していく方法です[63]

そのほか、別の方法としては

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

のような方法もあるでしょう。


そのほか、書籍『ゲームプランナー入門』で紹介されている事例だと、アルファ版(α版)を中盤から作り始めています[64]。α版の製作目的の一つとして、そのゲームが本当に面白いかの検証や(駄目すぎたら製作中止)、改善するとしたらどこかの洗い出しが目的ですが、中盤だとそのゲームの全体像がわかりやすいので検証しやすいからのようです。

作品やジャンルや製作目的などによって、エンディングからか中盤からか、どこから作り始めるかは若干の違いはあるでしょうが、ともかく必ずしも冒頭部から作り始める必要がないということです。


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

まず、ゲーム用のストーリー(ゲームシナリオ)の作り方ですが、学校などでの作文の書き方の順序と、ゲームシナリオの書き方の順序は、違います。

作家にもよりますが、ゲームシナリオを作る場合、エンディングを早い時期に作る人もいます[65]

文献『ゲームプランとデザインの教科書』によると、シナリオでなくシステム面についても、先にゲーム全体のクリア条件を決めてから、あとから各ステージなどのクリア条件を決めていくことが多いようです[66]

では、シナリオの仮のエンディングについて考えていきましょう。このエンディングは、当面の仮のエンディングなので、あまり作りこむ必要がありませんが、しかしエンディングが必要です。

エンディングのシナリオと、キャラクターの性格づけの設定があることにより、そのゲームで何を主人公に目指させるべきなのかが、作者にハッキリとします[67]


ともかく、方法は作家ごとに色々と違いはありますが、そのゲームの全体像を何らかの方法で決めるのが先です。


また、ゲームでは最後のラスボス戦がそのゲーム中でもっとも高負荷だったり、全部のシステムが組み合わさってたりしますので、先にエンディングを作っておくことで、そのゲームで最大負荷の状態を検証する事が出来ます[68]

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

処理オチの確認とかも、この方法で確認できます。

また、ラスボス戦およびエンディングは、そのゲームの大きな見所のひとつであり、ほぼ最大の見所がラスボス戦およびその前後です。

いっぽう、中盤などは、比較的に重要性が下がります。


なので、スケジュール遅延や容量不足などで、ストーリーを短くしないといけなくなった時などは、ラスボス戦以外の場所を削ることになります[70]

よって、ラスボス戦などは削る可能性が少ないので、先にラスボス戦を作っておけば、たとえスケジュール遅延などをしても、先に見所を作ってあるので、早くリリースしやすくなります。

イラストなど異分野での類似事例

似たような、先に結末を決める事例は、イラスト技法にも存在します。

1995年ごろ、イラスト雑誌『コミッカーズ』(1995年 コミッカーズ季刊 夏号)に、当時の人気漫画家&イラストレーターの藤島康介がインタビューされたのですが(なお、その号の表紙は別の漫画家(唯 登詩樹))、

藤島はインタビューにて、おおむね内容『よく若い漫画家さんから相談で「先生みたいに女性の長い髪を書くとき、毛先を書くのが難しいです。根元は書けるのに」との相談を受けるのですが、 僕(藤島)は髪を描くときは毛先から始めて根元に向かって描いてます』みたいなインタビュー返事をしました。


こういうふうに、大切なのは頭の使いようです。要するに、ズレるのが怖い場所は、先に位置決めをすればいいのです。髪の房(フサ)の根元と毛先だったら、ごく一部の場所を除いて、読者の目線では毛先のほうが目立ちます。

だったら、作画の際の誤差は、読者には気づかれない根元の部分に押し付ければいいのです。


よくよく考えれば、イラストに限らず機械製図とかでも普通にそういう位置決めの優先指示の記法はあるのですが、 しかし世間の人は、なかなかそういう発想を異分野に応用できません。普通の人はついつい、実際の髪の伸びる順序どおりに根元から描いてしまいます。


その他の開発順序編集

チュートリアルの細部は後回し編集

※ 特に出典は無いですが、技術系の仕事では常識的な考え方です。

RPGやシミュレーションゲームなど、プレイヤー視点では、ゲームの始めのほうに操作説明などのチュートリアルのイベントがありますが、しかし、実はチュートリアルの細部は、作るのが後回しになる場合が多々あるかと思われます。

なぜなら、ゲームで仕様を変更するたび、チュートリアルも変更の必要が生じるからです。このため、チュートリアルのとりあえずの完成の時期は、けっこう後回しになります。

よほど仕様の単純なゲームなら別ですが、そうでない場合、あまり開発初期からチュートリアルの細部を作りこみすぎないようにするほうが安全でしょう。

そもそも、チュートリアルをゲーム本編に組み込み必要もありません。たとえば説明書などで、細かい説明を代用する事だって可能なわけです。

チュートリアル部分に深刻なバグが発生してないかとか、逆に本編ゲーム中にチュートリアルが異常起動しないかなどの確認のために、開発初期からチュートリアルを組み込んでも構いません。ですが、おそらく、最終的なチュートリアルの完成時期は、仕様やゲーム全体像が本当に完成・確定したあとの時期なので、ゲーム本編の完成間近の時期になるか、もしくは本編完成後になるでしょう。

古典ゲームと技術限界編集

ゲームを作る際、過去の名作ゲームを参考にしようと思うでしょうが、 しかし過去のゲームの設計は、当時の性能の限界に影響を受けているので、 果たして現代のコンピュータ性能の飛躍的に上昇した時代でも過去の設計をそのまま参考すべきかは、 やや検討の余地があるでしょう。

歌舞伎などの古典技芸の伝承の格言で『師を見るな、 師が見ているものを見よ』という教訓があると言われています。

このセクションでは、主に1980年代のファミコン時代のゲームを例に説明します。

スプライト編集

ファミコン時代の昔のゲーム機には、一画面に表示できるキャラチップ数(敵チップも含める)に上限がありました。

一画面中に表示できる限界は、だいたい、マリオが一画面中に数十人ぶんです。(実際の数値については、本ページでは触れない。説明の本質には関係ないので。)

ファミコンでは、このような仕組みを 「スプライト」と呼んでいました。(実はマリオ1体の表示の時点で既に、いくつかのスプライトの小単位を合成したものになっているのですが、説明やややこしくなるので、このページでは触れません。)

ともかく、実は昔のゲームのステージ設計は、スプライトの制限を前提にしたものになっています。

極端なハナシ、もしたとえばシュテイングゲームなどで、動く敵100体をボムで一瞬で倒せるようにしたゲームを設計しようとかファミコン時代に思っても、 ファミコンではすでに敵100体の表示の時点でグラフィック性能的に原理的に無理なのです。


どうしても敵100体を表示したい場合、表示のタイミングを変えます。

たとえば、

1タイミング目では0~10体目までのAグループを表示、
2タイミング目では11~20体目までのBグループを表示、

みたいにして、タイミングを変えることで、なんとか表示するのです。


このため、画面上に動くキャラクターが多いと、一瞬、ほかのキャラが消えるのは、裏側でこういうタイミング切り替えの処理が行われているからです。


説明の都合上、本ページではキリのいい「10体目」までと 上記の例では表現しましたが、実はファミコンの制限はもっときびしく、横1列上には8体目までしか表示できないと言われています。(しかもマリオ1体自体が、じつは2体×2体の計4体チップを使っているといわれる。なのでマリオ5体は同一ライン上には表示できない。)

なおシューテイングゲームの場合、敵チップだけでなく、敵味方の双方の弾丸もチップを利用しますので、実際の制限は上記の数値例よりも、もっと厳しいでしょう。


また、プレイヤー視点ではキャラクター1人にしか見えていなくても、背の高いキャラクターなどはキャラクター2体以上に相当するなど、注意しなければならないこともあります。

だからファミコン時代のアクションゲームで、巨大ボスのいるステージでは、ボス以外の敵が出現しないのは、おそらくですが、プレイヤー視点では1体のボスに見えても、内部プログラム的には敵チップを何体ぶんも利用しているのでしょう。

しかも巨大ボスは、ゆっくりとしか動きません。

おそらく、そのゆっくりとした時間内にVRAMを書き換え中だったのでしょう。

日本ではコトワザで「ウドの大木」みたいな言葉があるので、なんとなく巨大ボスがゆっくりと動いても不自然ではないかもしれませんが、よくよく考えたら現実世界の大男はけっこう動きが早いです。(レスラーやヘビー級ボクサーなどを考えれば分かるでしょう。)


書き換え速度と背景グラ編集

ファミコンのマリオでは、書き換えの手間を省くために、一説には、たとえばマリオ1の地上ステージの世界の空の青色は、実はほとんどの場合、マリオが横スクロールしても空の青色の部分は書き換えをしておらず、横スクロールする前の青色をそのまま使いまわしていると言われています。

なぜそれで効率化できるかというと、ステージ中の障害物はほとんどのステージの場合で、画面の比較的に低い位置に障害物があるので、その低地の障害物だけを書き換えすれば済むからです。

だからファミコン時代では、こういう理由から、ステージの背景グラフィックや、障害物配置なども決まっているでしょう。

だから果たして、現代でもそれを過去の名作のステージ構成を踏襲すべきかどうかは、分かりません。もちろん、仕組みを分かった上で真似るのなら、それは特に問題ないでしょう。


アナログテレビの にじみ編集

ブラウン管では、細かすぎるドットは表示が、にじみます。ゲームに限らず、テレビアニメや一般の実写番組などでも同様、にじみます。(どのように、にじむかは、専門的なので説明を省略する)


だから、ファミコン時代から、だいたいプレステ1時代のゲームのグラフィッカーは、このことまで意識してドットを描いているはずです。

ともかく、液晶テレビとブラウン管テレビでは、同じ画像データでも表示結果が変わります。

レトロゲームから勉強する際は、ファミコン〜プレステ1時代のレトロゲームでは、データ上の解像度よりも実際のディスプレイ上の映像は細かいことに気をつける必要があります。


たとえば滲み(にじみ)を意図的に利用することでテレビの解像度以上の表現をしていたりしていました。

また、ファミコンのドットは縦横の長さが縦方向と横方向とで長さが違うので、そこまで考慮して、グラフィッカーは絵を描いています。

また、ドットの図形的な細かさだけでなく、色についても、にじみによって、当時のゲーム機の色用のビット数の限界を超えた表示をファミコン時代から行っていました。

つまり、同じドットの黄色の単色でも、そのドットの幅が1ドットか2ドットかで、テレビ上で表示される色が違います。「色が違って見える気がする」ではなく、実際にブラウン管のディスプレイ上では色が違うのです。言い方を変えると、ブラウン管テレビでは元の画像データ通りには色は表示されていません。(さらに縦方向と横方向とで色のにじみ方が違うが、専門的すぎるので、説明は省略する。wiki書くために調べるほうも大変なので。)


なので、もし現代の人がファミコン当時のゲーム作品のグラフィックを参考にする際は、このことに気をつける必要があります。一番、手軽なのは、そもそもグラフィックの細部については参考にしないことです。

これはつまり、もし公式エミュレーターなどでファミコン時代の古いゲームを、現代の液晶ディスプレイ用のゲーム機でプレイしても、エミュレーター側で過去テレビのグラフィック特性の再現のための特別な工夫をしてないかぎりは、実はグラフィックの表示結果が当時のものとは異なるわけです。

一方、パソコン市場では、ノートパソコンの普及し始めた1999年頃には液晶ディスプレイのものが比較的に安価で出て来たので、この頃からパソコンゲーム市場では次第にブラウン管のにじみを考える必要が無くなったでしょう。


なお、アナログテレビはそもそもテレビ自体の解像度が低いので、プレステ2時代あたりからのゲームには合いません。だから、プレステ2時代あたりからは、あまりブラウン管の特性を考える必要はなくなります。

逆に言うと、あまり指摘されないことですが、プレステ2時代の当時の人が当時の最新ゲーム機をプレイするには、もし既存のアナログテレビを使い続けていた家庭は、テレビ受像機そのものを買い換える必要があったという亊です。

一応、家電量販店などでテレビ用のアナログ/デジタル信号の変換機などを購入してテレビに接続するなどして使えば、デジタルテレビ用のゲーム機もプレイ可能ですが。

だからアナログ放送自体は2010年くらいまで続いたとはいっても、あまり当時のゲーム機をアナログ用テレビでプレイしていたとは考えにくくはあります(プレイヤーの好みによる)。

アナログ停波以降の時代である2010年以降の現代では、もうテレビ番組の受像でもブラウン管は一切用いられていないので、もはや現代のコンテンツ制作では特に考える必要はありません。


ブラウン管自体のドットの縦横が違っている。

このため、ブラウン管を前提にしたゲーム機やパソコンはそれに対応するために画像データ側のドットの縦横比が違っている。

ゲーム機やパソコンの種類、さらにはアーケードゲームの基盤といったハードウェアの種類ごとに、コンピュータ側でのドットの縦横比の管理は違っている(らしい)。このため、移植のたびに、ドットは書き直しになったようだ。


古いゲームの制作では「ドット用紙」という方眼紙のような印刷書面がある(らしい)のだが、そのドット用紙の時点で1マスの縦横比が少しだけ違い、1マスが長方形である。1ドットだけでは長方形であるのに気付かないかもしれないが、しかし「ちりも積れば山になる」ように、何十や百ドットも積み重なれば、縦横の長さは大きく違ってくる。

現在のパソコン用のドットエディタ(という画像制作ツールがある)は1ドットが正方形であるが、しかしファミコン時代は1ドットが(ドット用紙の時点で)少しだけ長方形である。(なお、画像制作ツールそのものの作り方については、『ゲームプログラミング/画像ファイルの作成プログラム』で説明する。ゲーム制作では普通は必要ないが、知識として。)

ファミコンの色数制限は52色から4色×4パレット(1パレットあたり4色)を使えると言われている[71]。しかし実際には、4色のうち1色は透明色として利用される色であり、全パレット共通の色である(なので3×4=12色になることのいなる)。スプライトのパレットとは別に背景のパレットがあるので実際には、もっと16色以上の多くの色数が一画面内で使えるが、しかしその他のさまざまな制限があるので、合計で一画面内で25色が使えると言われる(12 × 2+1 = 25)。

しかし実際には、ブラウン管の滲み(にじみ)を利用しているので、当時のプレイヤーには1パレットだけで描かれた1キャラのキャラチップ内でも3色以上の多くの色が見えているだろうし、画面全体でも25色内にない色がプレイヤーの目には映っていることになるし、もしかしたら52色にない色がプレイヤーには見えているかもしれない。なお、スーパーファミコンの色数制限は32,768色から16色8パレットであると言われている。

レトロなゲーム機では、さらにメモリ容量やストレージ容量などの制限もあり、けっして仕様上の最大色数を気軽に利用できたわけではないだろう。こういう制限もあったからか、ネットではファミコンの色数が「4色」やら「8色」、スーパーファミコンの色数が「16色」や「256色」などとも言われることもある。

「ドット絵」とは

よく世間には、ファミコン時代のゲームの、ゲーム中での絵柄のことを「ドット絵」という人がいます。プレステ1やセガサターンのポリゴンによって、「ドット絵」が無くなったと思っている人もいます。

しかし現実には、プレステ以降でも、顔ウィンドウの顔グラフィクや、キャラチップなどのグラフィックでは、その制作時にドット単位のグラフィック指定は行われています。

たとえば装備品で武器の横に小さい剣の絵などのアイコン画像が書かれている作品などもありますが、こういったアイコン画像もドット単位の指定で描くでしょう。

こう指摘すると、「プレステ1以降のゲームは解像度が高い」とかよくわからない反論をする人がいますが、しかし「ドット」という工学用語のどこにも、「解像度が低い」とかの意味はありません。また、「ドット」というのをブラウン管ディスプレイの映像だと思ってる人もいます。

しかし、液晶ノートパソコンの普及した2001年以降の液晶モニターの時代ですら、 「液晶のドット欠け」などのように「ドット」という用語は使われます。

「ドット」というのは、けっしてゲーム用語ではなく、「液晶のドット欠け」のように電子工学などですでに意味が決まっているので、ゲームオタクの戯言(ざれごと)は「ドット」の意味には無関係です。

さて、プレステ1以降のゲームでもキャラチップなどでは、ドット単位の指定が行われるのでした。

それどころか、携帯ゲームソフトでは、ガラケーの時代から既にドット単位の指定は現役の手法であり、スマホゲーム時代の現代でも現役です。

だから「ドット絵には魅力がある」とかいって、ファミコン時代のゲームばかりあげる人は、こういう現役のドット絵作家の努力が目に入らない人ですので、なるべく信用しないほうが良いと思います。


また、画像編集のフリーソフトまたはシェアウェアで、現代でも「ドット エディタ」と呼ばれる種類の画像制作ソフトがあり、少なくとも2D同人ゲームの制作ではよく使われます。

ツクールやウディタのドット絵を作る場合でも、ドットエディタを使って作るわけです。

ゲームに興味なさそうな人が「ドット絵」をレトロゲームの絵という意味で使うのは仕方ないかもしれませんが、しかしゲーム通みたいな顔して「俺ってけっこうオタクなんだぜ」みたいなフリしてるのに、レトロ的な用法で「ドット」という言葉を使う人はアレです。

おそらく、本当はけっしてドット絵が好きなんじゃなくって、単に自分の子供時代の思い出が好きなだけだと思います。


ニュアンスは違いますが、アニメ評論でもそういう話があります。1990年代後半に岡田斗司夫と誰かの対談で(おそらく書籍『マジメな話』での対談)、

「アニメの黄金期はいつか?」というよくあるアニメオタク談義について、 対談相手が言うには、

よく「70年代だ」「いや80年代だ」とかで議論が始まるが「いや12歳だ」というオチが有名だと。


アナログテレビの焼きつきなど編集

あまりゲーム評論では指摘されないのですが、

このほか、ファミコン時代はテレビ受像機がアナログのブラウン管ディスプレイなので、 あまり長時間、同じ色をディスプレイ上の同じ位置に表示し付けていると焼きつきが起きる可能性があるので、

ステージごとにコンセプトになる背景色を変えたり、

あるいはステージの背景色を黒にしたステージを増やしたりとかの工夫も、必要だったかもしれません。


ゲームではないですがパソコンソフトなどの古いソフトは、こういったディスプレイの焼きつきの事を考えており、だからスクリーンセーバー機能の搭載など何らかの対策をしています。


ともかく、あまり、特定の色ばかり続けて使いすぎないようにする工夫が必要だったでしょう。

アナログテレビは西暦2010年のアナログ停波する時代まで使われていたので、焼きつき問題はファミコン以降のプレステ1~2時代のゲームにも関係するでしょう。


ネット上にはデマで「ブラウン管だと焼きつきが起きない」(×)というデマがあるが、しかし西暦2001年くらいの筐体パソコンのモニターはまだブラウン管が多かったし、その時代からすでに焼きつき防止のためにスクリーンセーバーがWindowsに搭載されていた。だからデマ「ブラウン管だと焼きつきが起きない」(×)にダマされないように。

なお、現代のテレビ受像機には、焼きつき防止のためにすでに「ピクセルシフト」という機能があって、 これは画面上の映像の表示位置をタイミングによって微妙にズラす機能です。こういう機能がすでに搭載されているので、わざわざゲームソフト側で実装する必要はない。そもそも液晶モニターは、焼きつきが起きにくい。ただし有機ELはどうだか、まだ新しい技術なので分からない。

脚注編集

  1. ^ 川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日 第1刷発行、P85
  2. ^ 大久保磨『レベルデザイン徹底指南書』、2016年12月14日 初版 第1刷発行、P81
  3. ^ 青島矢一 ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日 発行、P.263
  4. ^ 4.0 4.1 4.2 4.3 4.4 4.5 青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.289
  5. ^ 5.0 5.1 青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.91
  6. ^ 『ゲームデザイン プロフェッショナル』、P234
  7. ^ 『ゲームデザイン プロフェッショナル』、P332
  8. ^ 『ゲームプランとデザインの教科書』、P.107
  9. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.120
  10. ^ 『ゲームプランナーの新しい教科書』、P20
  11. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.121
  12. ^ 吉冨賢介『ゲームプランナー入門』、P244
  13. ^ 青島矢一 ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日 発行、P.267
  14. ^ 青島矢一 ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日 発行、P.283
  15. ^ 吉冨賢介『ゲームプランナー入門』、P244
  16. ^ 吉冨賢介『ゲームプランナー入門』、P245
  17. ^ 17.0 17.1 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.139
  18. ^ 『ゲーム作りの発想法と企画書のつくりかた』、P.235
  19. ^ 吉冨賢介『ゲームプランナー入門』、P17
  20. ^ 吉冨賢介『ゲームプランナー入門』、P17
  21. ^ 吉冨賢介『ゲームプランナー入門』、P18
  22. ^ 蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日 初版 第1刷 発行、P56
  23. ^ 蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日 初版 第1刷 発行、P56
  24. ^ 蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日 初版 第1刷 発行、P54
  25. ^ 蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日 初版 第1刷 発行、P55
  26. ^ STUDIO SHIN『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日 初版 第2刷 発行、P251 の図
  27. ^ STUDIO SHIN『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日 初版 第2刷 発行、P251 の図
  28. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日 第1版 第1刷、P.135
  29. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日 第1版 第1刷、P.134
  30. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日 第1版 第1刷、P.134
  31. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日 第1版 第1刷、P.134
  32. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日 第1版 第1刷、P.135
  33. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日 第1版 第1刷、P.135
  34. ^ 岩泉茂『【CEDEC2017】「ゼルダの伝説」作成を裏から支えたエンジニアたち』、サイト名: Impress Watch、2017年9月4日 07:00 2020年11月25日に閲覧して確認
  35. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.350
  36. ^ 川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日 第1刷発行、P.38
  37. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日 第1版 第1刷、P.350
  38. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.350
  39. ^ 『ゲームデザイン プロフェッショナル』、P219
  40. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.349
  41. ^ 『ゲーム作りの発想法と企画書のつくりかた、P.140
  42. ^ 『ゲームデザイン プロフェッショナル』、P224
  43. ^ Vコンテ {---}}という言葉がある通り、時間軸・動きの制作意図の明確化が映像作品の制作で屡々重要になります。
  44. ^ 吉冨賢介『ゲームプランナー入門』、P17
  45. ^ 吉冨賢介『ゲームプランナー入門』、P17、表の説明文
  46. ^ 吉冨賢介『ゲームプランナー入門』、P18
  47. ^ 『ゲームデザインプロフェッショナル』、P170
  48. ^ 蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日 初版 第1刷 発行、P88
  49. ^ 挫折しやすいゲーム開発を完成まで継続する方法について話します。 - YouTube 2020年3月17日に閲覧
  50. ^ 『ゲームプランとデザインの教科書』,P152
  51. ^ 『ゲームプランとデザインの教科書』,P302
  52. ^ 吉冨賢介『ゲームプランナー入門』、P36
  53. ^ 川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日 第1刷発行、P.67
  54. ^ 川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日 第1刷発行、P.67
  55. ^ 『ゲームデザイン プロフェッショナル』、P199
  56. ^ 『ゲームデザイン プロフェッショナル』、P199
  57. ^ 川上大典ほか『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.48
  58. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.65
  59. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.65
  60. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.65
  61. ^ 『【ゲームの企画書】『ペルソナ3』を築き上げたのは反骨心とリスペクトだった。赤い企画書のもとに集った“愚連隊”がシリーズを生まれ変わらせるまで【橋野桂インタビュー】』2019年10月30日 11:30 2020年12月1日に閲覧して確認.
  62. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.306
  63. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日 第1版 第1刷、P.184
  64. ^ 吉冨賢介『ゲームプランナー入門』、P17
  65. ^ 畑大典 ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P166
  66. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日 第1版 第1刷、P.253
  67. ^ 畑大典 ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P166
  68. ^ 『ゲームの開発順序について解説します』 2020年8月30日
  69. ^ ntny著『ローポリスーパーテクニック』、ソフトバンククリエイティブ、2010年2月16日 初版 第5刷、P28
  70. ^ 『ゲームの開発順序について解説します』 2020年8月30日
  71. ^ [https://mynavi-creator.jp/blog/article/history-of-2dcg-designer 『2DCGデザイナーなら知っておきたい2DCGゲームの歴史』 2017/8/21 マイナビクリエイター編集部 ] 2021年12月30日に確認.

関連項目編集