ゲームプログラミング

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

概観[編集]

この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で魅力的に提供される、イラストや音楽が好きという場合もあります。

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

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

…というのは、ゲームというのは総合的な分野ですから、イラストや音楽はその要素として確実にありますが、それ以外、プログラミングやシナリオなど、様々な創作や創造が必要で、全ての作業量はかなり多いものになるでしょう。

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

ゲーム作り始めの時点では、これらの判断は明確でなくても勉強目的でも構いませんが、しかその内「自分は本当にゲームを作りたいのか? Yes or no?」という疑問への答えが必要になるときがくるかもしれません。

試しにゲームを作ってみて、もし自分の本当の目的がゲームでないと分かったなら、それ以外の活動に移るのも、取る道の選択肢でしょう。

給料は安い

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

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

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

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

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

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

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

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

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

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

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

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

さて、読者がゲーム制作を職業として目指すのかどうかはともかく、とりあえず、ゲーム業界の状況を知っておくのが有用でしょう。

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

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

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

漫画家大塚志郎のアドバイス

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

一人でイラスト作画や作曲をしながらゲーム制作をするのはある意味マルチタレントだとも言えますが、現実にその創作をしている人たちは、かなり年長のこの分野の熟練者が多いようです。若い19歳ぐらいの頃に、それらマルチジャンルを両立するのは、一般にかなり困難なことだと思われます。

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

大塚は、漫画家の人生のうちで、これからデビューを目指している新人に近い境遇にあるのは、ヒット後の漫画家の生活状況ではなく、まだ無名・マイナーな時代の態度・生活だ、と描いています。成功後の熟練した漫画家より、若いデビュー直後の作家をお手本にするのがいいだろう、という主張ですよね。

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


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

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

PlayStation2あたりまでの時代は、経済評論誌の未来予想でも、「もしかしたら今後、家庭用の据え置きゲーム機がパソコンの代替品として、家庭のリビング家電の標準品になるかもしれない」という予想があった。ゲーム産業がそのような牽引役として、経済界から期待されていました。ソニーが国産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]

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

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

ポリコレ規制

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

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

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

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

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

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

プロトタイプ[編集]

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

ですからむしろ、商業的なゲーム制作では、イラストは簡略なものを使ったうえで、プログラム中心の試作品(プロトタイプ)をいくつか作り、その中でゲームとしての面白さがあるものを、取捨選択したうえで商品化を考え、その後イラストや楽曲を詰めて完成度を高めていく、と、いう制作過程を取るようです。

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

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

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

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

ミドルウェアによっては使用料が発生するので、その点を事前に調べておく[22]

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

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

商標権等

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

意匠権とは、建物や工業製品の外観に関する権利なので、ゲーム制作ではあまり気にする必要はないようです[24]

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

特許権や実用新案権とは、大まかに言えば、技術的な発明に関する権利です。商標が登録されているかどうかは、特許庁の『特許情報プラットフォーム』というwebサイト[25]で確認できます。

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

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

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

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

二次利用を許可されてない著作物は素材として使えません。

そして見落としがちなのが、フォントの著作権です[24]。フォントにも著作権があります。

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


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

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

そこでゲーム会社側では原則、

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

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

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

ここで前編集者は娯楽産業の世界には厄介な消費者がいると言及しているけど、この前編集者自身がこのWikibooks で異常なまでに厄介な参加者なんだが、そろそろ人のふり見て自分を返り見るべきだと思うな。

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

そして前編集者はアイデアに関して権利をどうこう言う人間を無知だと書いているけど、自分は至上の賢人だと思ってるようだね。

そしてこの人物は他者を愚弄する時は必ず自分の意見ではなく、権威ある人がそう書いたから、出典だからと宣う。

出典は岡田斗司夫氏の著作『東大オタク学講座』や『マジメな話』だそうだ。

まあ岡田氏ならかなり過激なことを書くのは事実だろうが,この前編集者S はその悪徳をさらに10倍に高めてこのWikibooks に記述する地獄のように厄介で無知で馬鹿な人間だ。

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

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

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

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

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

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

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

勉強に関しては、汚くてもいいからまず工夫して作ってみると、何を勉強すればいいかが見えてきます。

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

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

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

参考文献のその章では、シナリオライター志望者に向けて語られていますが、プログラマーを目指すならどうすればいいでしょうかね。

プログラマー志望なら、サンプルゲーム、サンプルプログラムを作ってしまうのがいいかもしれません。

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

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

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

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

ゲーム業界人広井王子は書籍のインタビューで、自分の社長としての人材評価は「0点」から始まる「加点法」だと語っていたようです。

『ゲームデザイン プロフェッショナル』著者も、文脈は違いますが「加点方式で物事を考える」と述べています[31]

正直インチキなゲーム業界人の点数勘定などには全く興味ないが、そんな話とは全く別に、ゲーム制作の上で、実際に動く簡単なプロトタイプを作ってみることは間違いなく有意義な事でしょう。

アイデアはアイデアとして、思考や思想の展開としてありますが、それを具体的な形にしてみることは非常に楽しくエキサイティングで、意味ある活動ですよね。

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

アルファ版[編集]

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

アルファ版でもそのゲームが本当に面白いかどうか検証がなされます。サウンドやビジュアルは商品に近いほぼ完成化された形で取り込みます。

アルファ版の使用の結果、プロジェクト中止の決定がなされる場合もあります[19]

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

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

基本的に

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

の流れですね。

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

数学は後回し[編集]

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

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

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

C言語を使ったゲームは、予備知識はそれほど多くないので、あまり難しいことは考えず、まず実際にプログラムを書いて作ってしまう事優先にするのが正解なようです。

市販のC言語入門書で、配列や関数などの一般的な機能を一通り習得したら、あとはVisual C++ で映像出力とキーボ-ド入力のみを、1~2週間ほど勉強、そしてVisual Studioを起動してゲームを作り始める。

うまくいけば数か月以内に、パソコン用の非ネット通信のゲームを作ることができるでしょう。

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

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

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

さて、ゲームを作る時は、アイデアを頭の中だけに置いておくのではなく、文章に書きだしてみましょう。

そして、壮大な長大なアイデアではなく、1週間~1ヶ月ていどで成果の確認できそうなアイデアだけを書いてみましょう。

次にそのアイデアを、実際に動作するプログラム、ソフトウェア(つまりプロトタイプ)にするために、具体的などんな機能を持ったプログラム(簡単なものでよい)を制作しなければいけないか、自分のやるべきことのリストを、箇条書きで作ります。[34]

IT界ではこういうリストを「ToDoリスト」(読み: トゥードゥーリスト)とか「タスクリスト」といいます。このページではむしろ日本語で、「作業リスト」と呼んでみましょう。

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

*「戦闘システムを作る。」

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

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

という風に、作業項目を細かく分割していきます。

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

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

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

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

プログラミングする前に作業リストを眺めて、そして上の項目から実際に作業を開始しましょう。

そして一つの項目を完成させましょう。

そして作業項目がひとつ終わったら、「【完了!】」等、そういう情報を、項目の前または後ろにつけます。備忘のための記録ですね。

たとえば、

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

こうします。

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

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

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

と、必要に応じて項目を追加します。

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

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

の様に完了した項目を後回しにしたり、或いは

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

のように、(現在→)、を追加するのも良いでしょう。

つまり作業の記述をそのままに、どこまで進展しているかが分かる等に書き足していくわけですね。

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

ゲーム性[編集]

「ゲーム性」という概念があって、これがあるからこそゲームは面白く、魅力的だと考えられています。

プレイステーション開発元のソニーもこれを重視していますし、一般的に多くのゲーム愛好者、関係者たちもその考えに同意するでしょう。

ではゲーム性とは何か?

ゲームのジャンルにもよりますが、「駆け引き」や「戦術」、これが「ゲーム性」だとよく言われます。

『ゲームプランとデザインの教科書』によると、ゲーム性とは、シューティングやアクションでは「対戦の駆け引き」、RPGでは「戦闘と物語の介入」、シミュレーションゲームなら「戦略性」だそうです[35]

ただし上述の書籍によると、1990年代は今よりもゲーム性とシステムが重視されていたとの説明があるので、裏を返せば2010年以降の現代では、ゲーム業界ではゲーム性の重視の比率は1990年代よりも減っているかもしれません[36]

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

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

メディアクリエイターの佐藤 雅彦氏(「だんご3兄弟」や「ピタゴラスイッチ」等を手掛けている)が、初めてかかわるコンピュータゲームで、ソニー・コンピュータ・エンターテインメントとの共同企画で、のちに「I.Q」(1997年にシリーズ第一弾を発売)と呼ばれるシリーズに携わった時、プロトタイプが全くゲーム性のないものになってしまい、それをプレイしたソニーの幹部陣の顔色が非常に曇ってしまったようです[38]

ここでの悪い反応、薄い反応の理由がわからなかった佐藤氏が、階段の踊り場でソニーの新人に尋ねてみると、「それが、あの、ゲーム性がないっていうか・・・」と言われたと出典の対談集に書かれています[38]

基本的に佐藤氏は、プロトタイプの企画を提案しただけですが、ソニーにはプロトタイプを作るための部署があるらしく、1~2ヶ月かけてそこでプロトタイプが作られたようです。

この問題の責任が誰にあるかは、大した重要な事ではありませんが、商業作品としてプロトタイプを作る以上は、どこかの段階でゲーム性を意識して、プログラムに盛り込む工夫が必要になるでしょう。

ゲームの見た目とは?[編集]

ふつうゲームのプレイヤーは、まず最初にそのゲームの「見た目」を判断し感受するでしょう。ですからその見た目のインパクト、興味を呼び起こす構成が必要になります。

例えばスーパーファミコンRPG『新桃太郎伝説』では、開発当初はドラゴンクエスト5 のようなマップ画面のトップビューUIでしたが、開発中にクォータービューの他社製RPGが発売されて高い評価を得たので、マップUIを(トップビューではなく)クォータービューに作り直したようです。このことは攻略本『新桃太郎伝説 究極本』に開発裏話として書かれています。

一方現在でもこの方向の試みは重要なようで、書籍『ゲームデザイン プロフェッショナル』の著者は、他企業の製品の画面と、自社の製品を目で見比べる分析方法で、自分たちの製品のUI の問題を見出しています[39]

割と素朴で単純で即物的な見た目、「かっこいい」とか、「ぱっと見派手」等の要素が非常に重要なようです[39]

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

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

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

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

ソース開示が嫌な場合は、開示義務のあるツールは使わないのが正解ですね。

ゲームに限らず、ソース開示を義務としている開発ツールは多くあるので、ライセンスには気を配る必要があります。

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

ですからゲーム開発において、ツールのライセンス条件の確認は、非常に重要です。

GPLライセンス違反

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

ですから、ソース公開したくないプログラムには、GPLソフトウェアは組み込めません。

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

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

特定のプログラム自体に、GPLソフトウェアのコードを取り込んだ時、ソースコード公開が必要になります。


BSDライセンス他

オープンソースの中には、どのような利用法であっても、利用者にソース公開を求めないライセンスもあります。BSDライセンスとMITライセンスはソース非公開で利用できます。

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

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


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

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

自作ソフトでソース開示

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

然しソースコードを開示していることが原因で、トラブルに巻き込まれる場合もあるかもしれません。自分の作ったゲームのコードが悪用され、トリッキーないたずらや嫌がらせ、誹謗中傷などを受ける可能性も全くないわけではありません。

そこでライセンスに、利用による損害に対する保証が無いことを明示するのは、ある程度有効でしょう。大抵の著名なフリーソフトウェアライセンスには、この条項があります。他者の悪意を完全に防ぎ失くすることは難しいのですが、ある程度の対策は見出されていますし、自身でも見出していく必要があるでしょう。


開発ツールを使用しないという事[編集]

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

大規模な作品の場合、Visual C++ などでコードを書いて開発することを推奨します。

機能制限[編集]

ゲーム開発ツールを使う場合、そのツールにもよりますが、「○○ができない」、つまり特定の目的を果たすための機能を持っていない場合があります。

Visual Basic や Visual C++ には普通にある関数でも、開発ツールには無い場合も多い。

また、もし、いったんはゲーム開発ツールを使って目的の機能を持ったシステムを作ったとして、さらなる機能をそのシステムに追加しようとするときに、大幅な作り直しが必要になる場合があります(拡張性の悪さ)。

システムがモジュール化されていても、そのモジュール部分では大きく改変する必要がある場合もあるでしょう。

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

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

移植性の悪さ[編集]

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

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

ゲーム開発ツールで作ったソースを、Visual C++のソースに置き換えるのは、簡単にはできないし、ほぼ全面的に新たに書くことになるでしょう。

イラストレーター、デザイナー[編集]

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

ゲーム界の場合デザイナーというのは、プランナーやディレクターのことであり、管理職的な設計者のことで、美術的なクリエイターではない。design という英語には、機械建築の設計という意味もあります。

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

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

…ところで前編集者はわざわざこの項目を作ったうえで、色々な場所での言葉の意味の違いを、クドクドと自分勝手な分かりづらい説明で長々述べた後、「混同しないように気をつけましょう。」なんて馬鹿馬鹿しい言葉で締めているんだけど、この人物の意図はどこにあるのだろう?

例えばデザイナーというのは一般的に、造形作品、図案、意匠を考案する人のことを言うのだから、ゲーム界の外の人間が多少その業界内での意味を取り違えても、それほど致命的なミスでもないし、罵倒、愚弄されるいわれもなければ、好き放題にその相手を罵倒、愚弄していいわけでもない。間違えて使っている人を見たら、その都度やんわりと教えてあげればいいだけじゃあない? だいたいその世界に現実に身を置いたら、そこでの言葉の意味、使い方なんて自然に覚えるものだし…。

それを得意げにこれが違うあれが間違いといちいち理屈書いて、いい気になって威張っているこの人物は何者なのだろう?

現編集者が思うには、この人物は、学問、知識、知恵、科学とは何かという事を、根源的に取り違えている、のだろう。

操作性[編集]

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

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

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

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

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

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

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

処理速度の問題[編集]

基本的にプログラミングでは、関数を使って、処理をコンパクトにまとめ、定数ではなく変数で柔軟性のある操作をすることが求められますが、ゲームの場合は、この構造のせいで処理速度が低下することがあります。

現在のCPUの性能、速さはかなり高くなってはいますが、プログラム処理は無限に煩雑化できますから、やはり高度な処理を短時間でなすことが求められます。特にゲームは、リアルタイムの反応のタイミングが非常に重要ですからね。数学の指数計算についての雑学で、「新聞紙を42回おりたたむと、月に届く距離になる」というものがあります。(新聞紙の厚さ)*2^42、ですね。もっとも新聞紙の物性から言って、ほぼ不可能な操作ですけど^^;;。コードの内容、組み合わせによっては、このように計算量が指数関数的に膨大になってしまい、処理速度が非常に遅くなってしまう場合があります。

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

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

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

ゲームプログラミングに要求されるコード特性は、科学計算ソフトウェアや金融プログラミングなどの手法とは異なります。情報工学・情報科学で適切とされる「構造化プログラミング」などの歴史的に発展してきたプログラミング・パラダイムの理念とは反するようなコード開発方針になる場合もあります。しかしゲームプログラミングに限らず、限定されたハードウェアで特定の結果を速く得るためには、様々なトリッキーな手管が必要になるでしょう。

ツクール等制作ツール

RPGツクールの制作元のカドカワ(アスキー社→エンターブレイン社→カドカワ(かつての「角川書店」) )では、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ライブラリによるコーディングは不要である(そもそもウディタにはコード入力の機は無く、マウス操作や、キーボード操作はキャラ名称や会話文などのテキスト文字や数値の入力のみ)。


乱数[編集]

文献『ゲームプランナー集中講座』にあるのですが、ゲームにおける乱数的な処理では、実は一見するとランダムのように見えていても、実際には演出や調整のためにアルゴリズムが介入している場合もあります。よくあるのは、たとえば、ゲーム中のクジなどで「外れ」が続くと、当たり確率が変動するアルゴリズムが組まれており、次第に次からは当たりやすくなる、のような介入です[41]

このような演出・調整などのためのアルゴリズム介入があるので、やたらと完全なランダム性などを追求するのも、考え物です。ゲームはシミュレータではありません[42]


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

しかし、無印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)といわれるスケジュール表から、 それをグラフ的に図示したガントチャートといわれる表を作って、その表を見て作業計画を判断する方法です [43]

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


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

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

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

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


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

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

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


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


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

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

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


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

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

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

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


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

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

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

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


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

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


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

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

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

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

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

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


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


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

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

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

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

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


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

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

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

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

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

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


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

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


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


  • 目標の提示

ゲーム中の目標の明確化は、シナリオの設計手法としてだけではなく、たとえば各ステージ目標の提示などは、プレイヤーをゲームに引きこむ手法にもなります。

というか、文献『ゲームプランナー入門』によると、もしゲームの目標や課題が満足に語られていないと、プレイヤーは最悪、「?」となり、コントローラーを置いてゲームを中断してしまいます。なので、設計の際、各ステージやエリアなどの冒頭で、そのステージの課題や目標などを明示する必要があります[56]

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


その他の開発順序[編集]

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

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

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色)を使えると言われている[58]。しかし実際には、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. ^ 12.0 12.1 吉冨賢介『ゲームプランナー入門』、P244
  13. ^ 青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.267
  14. ^ 青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.283
  15. ^ 吉冨賢介『ゲームプランナー入門』、P245
  16. ^ 16.0 16.1 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.139
  17. ^ 『ゲーム作りの発想法と企画書のつくりかた』、P.235
  18. ^ 18.0 18.1 吉冨賢介『ゲームプランナー入門』、P17
  19. ^ 19.0 19.1 吉冨賢介『ゲームプランナー入門』、P18
  20. ^ 20.0 20.1 蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P56
  21. ^ 蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P54
  22. ^ 蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P55
  23. ^ STUDIO SHIN『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日初版第2刷、P251の図
  24. ^ 24.0 24.1 24.2 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.135
  25. ^ 25.0 25.1 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.134
  26. ^ https://game.watch.impress.co.jp/docs/news/1078888.html 2020年11月25日に閲覧して確認
  27. ^ 27.0 27.1 27.2 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.350
  28. ^ 川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日 第1刷発行、P.38
  29. ^ 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.349
  30. ^ 『ゲーム作りの発想法と企画書のつくりかた、P.140
  31. ^ 『ゲームデザイン プロフェッショナル』、P224
  32. ^ 『ゲームデザインプロフェッショナル』、P170
  33. ^ 蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P88
  34. ^ https://www.youtube.com/watch?v=J5FCZG7dfEY 2020年3月17日に閲覧
  35. ^ 『ゲームプランとデザインの教科書』、P152
  36. ^ 『ゲームプランとデザインの教科書』、P302
  37. ^ 吉冨賢介『ゲームプランナー入門』、P36
  38. ^ 38.0 38.1 川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P.67
  39. ^ 39.0 39.1 『ゲームデザイン プロフェッショナル』、P199
  40. ^ 川上大典ほか『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.48
  41. ^ 『ゲームプランナー集中講座』、P232
  42. ^ 『ゲームプランナー集中講座』、P231
  43. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.65
  44. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.65
  45. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.65
  46. ^ 『【ゲームの企画書】『ペルソナ3』を築き上げたのは反骨心とリスペクトだった。赤い企画書のもとに集った“愚連隊”がシリーズを生まれ変わらせるまで【橋野桂インタビュー】』2019年10月30日 11:30 2020年12月1日に閲覧して確認.
  47. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日 第1版 第1刷、P.306
  48. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日 第1版 第1刷、P.184
  49. ^ 吉冨賢介『ゲームプランナー入門』、P17
  50. ^ 畑大典 ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P166
  51. ^ 川上大典 ほか著『ゲームプランとデザインの教科書』、秀和システム、、2018年11月1日 第1版 第1刷、P.253
  52. ^ 畑大典 ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日 第1版 第1刷発行、P166
  53. ^ 『ゲームの開発順序について解説します』 2020年8月30日
  54. ^ ntny著『ローポリスーパーテクニック』、ソフトバンククリエイティブ、2010年2月16日 初版 第5刷、P28
  55. ^ 『ゲームの開発順序について解説します』 2020年8月30日
  56. ^ 『ゲームプランナー入門』、P39
  57. ^ 『ゲームプランナー入門』、P54
  58. ^ [https://mynavi-creator.jp/blog/article/history-of-2dcg-designer 『2DCGデザイナーなら知っておきたい2DCGゲームの歴史』 2017/8/21 マイナビクリエイター編集部 ] 2021年12月30日に確認.

関連項目[編集]