ゲームプログラミング

この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で魅力的に提供される、イラストや音楽が好きという場合もあります。
実際のゲーム業界の人々も、ゲームを彩るイラストレーションや音楽がいかに重要な要素かを語っています。
さて、ここで問題なのですが、「ゲームを作りたい」と貴方が思っていたとして、あなたが本当に作りたいのはゲームなのか?あるいは本当はイラストが描きたかったり、音楽を作りたいのではないか?
...というのは、ゲームというのは総合的な分野ですから、イラストや音楽はその要素として確実にありますが、それ以外、プログラミングやシナリオなど、様々な創作や創造が必要で、全ての作業量はかなり多いものになるでしょう。
そしてゲーム、コンピューターゲームにはゲーム独自の世界観があって、現実や小説や映画とは違う、独特の法則に支配された世界を作る必要があります。ある意味リアリティを持たない、リアリティから外れた世界です。だから、小説のようなリアリティにこだわるなら、ゲームは不向きかもしれません。
ゲーム作り始めの時点では、これらの判断は明確でなくても勉強目的でも構いませんが、しかその内「自分は本当にゲームを作りたいのか? Yes or no?」という疑問への答えが必要になるときがくるかもしれません。
試しにゲームを作ってみて、もし自分の本当の目的がゲームでないと分かったなら、それ以外の活動に移るのも、取る道の選択肢でしょう。
職業として、商売としてゲームを作る場合、ゲームプログラマーの給料は洋の東西を問わず、安い事が知られており、書籍などでも言及されています。たとえば『CAREER SKILLS ソフトウェア開発者の完全キャリアガイド』(ジョン・ソンメズ 著)という欧米人のプログラマーの書いた本には、アメリカのゲーム業界ですらハードワークの割に賃金が低い事が記載されており、もし給料の高い仕事につきたいならウォールストリート(※米国の金融ウォール街のこと)のための仕事をするべきだと書籍中で指摘しています。
日本でも同様にゲーム業界の報酬が低いことは知られており、多くのゲーム会社の伝記漫画でも、よく語られています。
アニメーション業界と比べたら、ゲーム業界のほうが報酬が高いことは事実かもしれませんが、これは実は恐ろしいことに、アニメーション業界の報酬が異常に低いだけで、アニメーション業界よりはましだけど、結局は...というのが現状でしょう。
2001年ごろの日本はネットを活用した同人ゲーム黎明期、フリーゲーム黎明期で、実験的な時代でもあり、多くのイラスト愛好、創作者や音楽創作者がゲーム制作に手を染めていたようです。この頃、まだイラスト投稿サイトや小説投稿サイトといったものは無かったか、あったとしても小規模でマイナーなものでした。
しかし2010年のあたりから各種の投稿サイトが普及したことにより状況は変わり、むしろ現在では、小説やイラストを発表したい人はそのジャンルの投稿サイトに直接アクセスしたほうが早く、そのためゲームを通して発表するのは人によっては廻り道かもしれません。
それをわかったうえで、それでもゲーム制作に身を投じるかを考えた上で、「よし、自分はゲーム制作をしよう」と思えるなら、ゲーム制作をするのが良いでしょう。
実際、今現在の作曲家やイラストレーターは、ゲームに関わったとしても、専門家として楽曲やイラストを提供するという立場に過ぎない場合もあり、自分自身が主体になってゲーム制作をする人は、プロアマ問わず少数派のように見えます。
同人ゲームの世界でも現在は(2021年頃に記述)、プログラマー系の作者が圧倒的に多い様です。
しかし、専門外の人だからこそ、メディアミックス的な意外な視点で新しいものが作れる可能性もあるかもしれません。コピーライター、作家の糸井重里が、マザー2の企画にたずさわった例もあります。しかし、あくまで「可能性」であり、成功はけっして保証されてはいないので、読者の自己責任でお願いします。
今現在のゲーム専門学校のカリキュラムはプログラミングが主体です。CGの授業は、週に2時間程の様。一方でゲームCG、或いは、一般CGに特化した学科もある様です。
あるWikibooks編集者Aは、もしイラストを描きたいなら、イラストの世界で描くのが安全、と考えています。ゲームプログラミングについては、プログラムを書ける人は絵コンテも描けそうだし、基本的にある程度の作図的なイラストを描ける人は多いだろうから、別にプログラミングに専念しろとは思っていません。
さて、読者がゲーム制作を職業として目指すのかどうかはともかく、とりあえず、ゲーム業界の状況を知っておくのが有用でしょう。
結局商業界の状況が権威をもってその分野を支配しているのがこの社会の基本なので、趣味でも職業でも、業界周辺のことを知っておくのは得ることが多いはずです。
文献『レベルデザイン徹底指南書』では、現実世界で自分が新しいスキルを1つ覚えたら、古いスキル1つはどれか忘れる必要があることを説いています。著者は、最初はグラフィッカーでしたが、しかしプランナーに転職したので、グラフィック関係の技能は仕事では「忘れて」しまった、という内容を述べています。ただし、比喩的に「忘れる」とは言っていますが、実際には忘却し無くなってしまったわけではなく、仕事では時間の都合により両立できないので、グラフィック関係の技能は例え話で「忘れた」、のであり、現実にはグラフィッカー時代に培った観察眼をプランナー時代の現在でも活用している、と、書籍中では述べられています。
このことは職業、あるいは技能とは一般的にそういうもの、と考えることができるでしょう。
ゲーム業界のプランナーに限らず、演劇の世界でも舞台監督の仕事がそんな感じであり、ついつい大道具とか小道具とかを舞台監督が手伝ってしまうと本来の管理業務に支障をきたすので監督は手伝わないように(監督は指示を出すのに徹さなければならない)、監督は自身を注意する必要があります。高校生向けの演劇部の本にそう書いてありました。こういう分担作業の出来ない人は高校教師以下なので、反省してください。
かつてはゲーム産業が、日本のIT産業やデジタル家電産業の中心的・牽引(けんいん)役であった時代がありました。しかし、2010年以降、この考えは当てはまらなくなっています。
PlayStation1~2あたりまでの時代には、経済評論誌の未来予想でも、「もしかしたら今後、家庭用の据え置きゲーム機がパソコンの代替品として、家庭のリビング家電の標準品になるかもしれない」という予想があった。ゲーム産業がそのような牽引役として、経済界から期待されていました。ソニーが国産CPUをプレステ2〜3に搭載したり、WindwosのマイクロソフトがXBOXでゲーム機に参入したり、そういう時代です。
しかし2020年代の今は違います。結局、2020年代のゲーム機に使われてる技術や部品は、パソコン用の部品や技術の流用、ゲーム機のCPUも、今やインテルなどのパソコン用CPUをゲーム機でも使っています。
もはや現代は、ゲーム業界は、産業のエンジンではないようです。
ですから今現在、新しい技術に興味ある人は、ゲームにこだわらず、直接的にその技術を勉強し改良したほうが近道です。
たとえば、インターネット技術を使って何か新しい事をしたいなら、ゲームを作るよりもwebアプリやサーバーwebサービスを作るべきだし、目的のネットワーク用ソフトウェアをそのまま制作したほうが早いし確実です。
古い経済知識の先入観にとらわれず、無理にゲーム制作にこだわらないほうが、自分自身の技能やキャリアも開けていくでしょう。
2010年に出版された商学書籍『メイド・イン・ジャパンは終わるのか』には、「しかしながら、ファミリーコンピュータで世界に攻勢をかけ、その後圧倒的な強さを誇っていた日本の家庭用ゲーム産業も、90年代末からはその競争力にかげりがみえはじめた。日本の国内市場は伸び悩み、成長率は鈍化傾向にある(図表7-3)。」とあります。
その「図表7-3」の統計値によると、
である。(青島らが『レジャー白書』、『情報メディア白書』、『月刊トイジャーナル』、『CESAゲーム白書』などをもとに作成した図表の統計値です。)
また、2010年の時点の商学研究では、1997年を境に、ゲームソフト市場で競争する企業数が増加傾向から減少傾向に転じた、とも言われています。
書籍『メイド・イン・ジャパンは終わるのか』にも、引用文「家庭用ゲームは日本がその本格的立ち上げを主導し」と書かれているぐらいで、1990年代は日本のインパクトが強かったようです。
なお、携帯電話の分野で、日本は国際的な地位を喪失したのに対し、デジタルカメラとゲームは「現代」(参考文献の著作時2010年ごろ)でも日本が主要な地位にある。

ここでいう「プログラミング」とは、C言語などのプログラム言語による開発のことです。RPGツクールなど開発ツールによるゲーム制作の話は原則していません(本書『ゲームプログラミング』はあくまでプログラミングのための教科書です)。
さて、よくネットや、あるいは日常でも(C言語などによる)「ゲームプログラミングは簡単だよ。イラストやシナリオのほうが難しい。」、などという人がいますが、この発言の心は、「俺はプログラミングもイラストもシナリオも出来る凄い男だぜ。しかもプログラミングなんて簡単だし、むしろクリエイティブなイラストやシナリオの方に精力を費やす偉い奴だぜ^^」という、世間に良くいる武勇伝、自慢を語りたがる、インチキ親父が吹かしているだけなので、あまり真面目に取り合わないのが正解だと思います。
まず第一に、不当にプログラミングの価値を貶めている言説ですよね。
Visual C++またはVC# 、あるいは Direct Xなどを使ってプログラミングすることは、そんなに簡単なことではないでしょう。
ゲームプログラミングの入門書などには、初心者でも理解できそうな比較的簡単ないくつかのサンプルコードがありますが、それは初心者でも簡単に書けそうな技術だけを抜粋してるという、あくまで例外です。
RPGならたとえば、ドラクエ3のような戦争画面の行動順を処理するソート機能をつくるだけでも一苦労ですし、ほかにも道具・アイテムなどの自動整理をはじめとする標準機能を作るだけでも一苦労です。
決して上手い人のサンプルコードをコピーアンドペーストをして終わりという訳にはいかず(そもそも現状そのようなサンプルコードがネット上に無いですが)、もし仮にサンプルコードがネットに公開されていても、自作品に組み込む際にさらにそれをデバッグ(決してテストプレイの意味ではなく、実際にコード修正が必要になります)しなければならず、プログラミング言語の理解が必要です。
ゲームのプログラミングは決して楽ではないし、仮にもし楽だとしたら、じゃあゲーム会社のプログラマー職の人の仕事は何なんだ・・・という疑問につながりますよね(デマを言ってる人は、この疑問を脳内に都合よく無視しますが)。
ツクールやエディタのような制作ツールを使えば、C言語的なプログラミングは不要ですが、それはそのツクールなどのツールを開発している人達にプログラミングを肩代わりしてもらっているだけなので、決して「ゲームプログラミングが楽」、ではないでしょう。楽だというなら、じゃあツクール開発元の角川書店およびその発注先ソフトメーカーのプログラミングが楽だとでも言うのか・・・(デマを言ってる人はこの疑問を無視します)。
そもそもコンピューターゲームというのはプログラミングがなければ成立しないのですから、そのプログラミングの価値を貶めて平気な人は、コンピューターゲームにかかわる資格はないでしょう。
自分でゲームを作る際、必ずしも、C言語などプログラム言語で記述する必要はありません。
プログラミングをせずに、ほぼマウス操作と会話メッセージなどの文章のキーボード入力だけでゲーム開発をできるようにするソフトウェアが、有料または無料で発表されています。
たとえば、RPGを作りたいなら、日本で発表されているソフトでは、『w:RPGツクール』や『w:WOLF RPGエディター』などのように、RPG製作に特化された開発ソフトがあり、大幅に開発の手間を減らせます。なお、『RPGツクール』は有料製品です。『WOLF RPGエディター』は無料ソフトです。
アクションゲームを作りたいなら、『w:アクションゲームツクール』があります。これらツクール製品は有料製品です。(なお、かつて『w: 2D格闘ツクール2nd.』というのがありましたが、しかし現在ではサポート切れのため、今現在の市販の十字キーコントローラーが初期設定では動かない、一部のボタンしか使えないなど問題点があります。)
また、ノベルゲームを作りたいなら、フリーソフトの『w:吉里吉里Z』などがあります。吉里吉里Zはソースコードが公開されており、オープンソースになっています。
C言語などによるプログラムは、上記のゲーム開発ツールを使わない場合の選択肢になるでしょう。
既存のゲーム開発ツールの仕様に不満を感じる場合に、「じゃあ自分でプログラムして作ろう」となり、プログラミングが必要になるわけです。
なお、上記の開発ツールはほとんどがWindows用のソフトです。MacやLinuxでは動きません。MacやLinuxで動作するゲームを作りたい場合は、別のソフトウエアを使う必要があります。
既存のゲーム開発ソフトを使わずにプログラムを組んでゲームを自作する場合、必ずしも既存のツールのような、ゲーム作品と開発ツールが分離された仕組みを再現する必要はありません。
一般的に初心者が、ゲーム開発ツールを作ることはほぼ不可能です。初心者は開発ツールを作ることは考えずに、まず1本、とりあえずゲーム自体を完成させてみましょう。開発ツールを自作したいのなら、まず先にゲーム1本を完成させたあとに、あとから開発ツールとゲーム作品の分離などに取り掛かるのが推奨です。
基本的に、現代の商業ゲームは、C言語で開発をする。
ただし、ファミコンの古いゲームは、アセンブラで開発されていた。ファミリーコンピューターからスーパーファミコンに至るまで、OSは搭載されていない。
ではいつからC言語がゲーム開発に使われるようになったかというと、商学の学説では、プレイステーション(※ おそらくプレステ1?)の頃からだろう、と考えられている。ただしこの時代でも、処理速度の高速化のためにアセンブラにアクセスする開発チームも少なくなかった。
また、プレイステーションのOSは独自仕様である。
カプコン(ゲーム会社のひとつ)など一部の企業は、OSによる開発ではなく、移植性を高めるために自社製の内製フレームワークを用いて開発する。カプコンの場合、2010年頃は「MTフレームワーク」という自社製フレームワークを用いて開発を行っていた。なお2020年代の現在、カプコンでは後継の別フレームワーク(カプコン内製)を使っている。
ゲームを書くために利用される言語は多岐にわたっています。歴史的にはゲーム業界でも、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++への変更が必要になるかもしれません。
例えば、かつて Adobe の Flash が、ブラウザで動かせるゲームを作る際に、よく使われていました。このようなwebブラウザ上で動くゲームのことを一般に、「ブラウザゲーム」と言います。ただし、現在ではFlashは廃止の方向です、すでにほぼ廃止されているといっていいでしょう。また、現状では、ローカルPC環境でのゲームをJavaScriptで作るのは、アマチュア段階では困難です。JavaScriptのアマチュアゲームと言う事例を聞きません。
なお、JavaScript はクロスプラットフォームですが、しかし、セキュリティ上の理由などから、いくつかの機能(たとえばファイル入出力)がwebブラウザ上では使えないようになっており(セーブ機能が標準では不可能)、そのためJavaScript だけでゲームを作るのは、初歩的なゲームを除くと、かなり困難です。(おそらく、オンラインゲームでは、サーバー側でPHPやサーバサイドJavaScriptなどの別プログラムが走っていると思われます。)
セーブ機能の必要なゲームを作る場合は、JavaScriptでの開発は選択肢にない(セーブの実装には、JavaScript国際規格にはない非標準仕様を使いこなす必要があり、かなりの技術力を要するでしょう)。
商品として流通するようなゲームや、高度な機能を持つブラウザゲームを作ることはとても難しく、このページでは手に負えません。そこで、このページでは、初心者が練習用につくるゲームを例に記述します。
webブラウザだけで動くのがブラウザゲームです。ブラウザゲームを作るのに使う言語の第一選択肢はJavaScriptです。サーバー側の処理が必要ならPHP,Python,Perl,Javaなどの言語の出番でしょう。
「ネットワークゲーム」は「ブラウザゲーム」とは意味が違います。
「ブラウザゲーム」は、パソコンにwebブラウザさえあれば、ネットワークに接続していなくてもゲームプレイできて、最後、クリアまでプレイできる作品もあります。
しかしネットゲームは、ネットワークに接続しないと、ゲームを開始することさえ不可能です。つまり、サーバの提供するゲームが「ネットワークゲーム」「ネトゲ」です。
もしPHPやPerlなどでゲームを作る場合、普通はネットゲームになる筈なので、作者がサーバを構築して提供する必要がありますし、プレイヤーにはゲーム中にサーバに接続する環境が必要になります。提供者は、サーバを用意したり、保守管理する必要があります。サーバーがダウンしてしまうと、プレイヤーがゲームをできなくなります。
「PHP ゲーム」などの単語でネット検索したり、あるいは書店でプログラム言語の書籍や解説サイトを見ると、ときどきPHP・Perlなどの言語でゲーム開発しているものもありますが、一般的なダウンロード型のゲームとは違う筈なので、気をつけてください。
一般に、プレイステーションや任天堂のゲームを開発するには、専用の機材が必要であり、そのため、ソニーや任天堂とライセンス契約しなければいけない。
その契約に際して、ライセンス費用またはライセンス料金と呼ばれるものを、ゲーム機開発会社の任天堂、ソニーに支払う必要があります。
現在でもソニーや任天堂のゲーム機用のソフト開発・販売には、ライセンス料が必要です。少なくともPS4やニンテンドースイッチのパッケージソフト開発には、「ライセンス費」が必要。
なお、書籍『ゲームプランナーの新しい教科書』によると任天堂やソニーのようにゲーム機を作っている会社のことをハードメーカーと言います。つまり、ゲーム機のハードメーカーにライセンス料を支払うという仕組みになっています。
また、スマートフォン向けアプリは、プラットフォーム使用料が掛かります。 書籍『ゲームプランとデザインの教科書』によると AppleStore, GooglePlayともに売上げの30%とのこと。その他のプラットフォームも、大体同じとのことです(参考文献の著作の時点では)。
Google やAppleのようにプラットフォームを提供している企業のことをプラットフォーマーと言います。
昔からゲーム機のライセンス料は有料で高額であり、ソニーや任天堂の収益源のひとつになっている。一方、パソコンゲームにはライセンス料が無いのが普通です。
なお、ハードメーカーでなければプラットフォーマーでもないゲーム会社のうち、製造から販売までを手がける会社のことをパブリッシャーといい、たとえばカプコンやコナミやセガやスクウェア・エニックスやバンダイナムコなどがパブリッシャーです。
実は、必ずしもパブリッシャーが開発を手がけるとは限らず、スマホ向けアプリなどではディベロッパーといわれる開発専門の会社に委託している場合もあります。
Apple社のAppStore向けのスマートフォンアプリでは、アップロード後に、公開前にAppleによる審査があり。、審査は欧米基準です。
GooglePlayは、公開前の審査はないが公開開始後に海外基準で審査されるので、それに違反していると配信停止になります。
海外プラットフォームで販売・配布したい場合、「ポリティカル・コレクトネス」(政治的な正しさ)といわれる、海外の公序良俗の基準に配慮する必要があります。
ドラゴンクエストのファミコン時代、海外輸出の際、教会での描写を変更しなければいけなかったことがありました。これは、岡田斗司夫氏の YouTube放送でも話題にされています。教会の描写で、神父とシスターが同じ建物で仕事をしていた。これが問題になったらしい。カトリックでは妻帯禁止ですし、男女が同じ場で働く描写がよくないようです。
開発者たちは、「教会の描写はキリスト教ではなく、ゲーム世界独自の宗教」と主張して、難を逃れようとしましたが、しかし教会の裏にある墓地が十字架のマークだったので、「十字架はイエスの磔(はりつけ)の場でありキリスト教で重要な意味を持つ。十字架の墓標がキリスト教ではないという主張は欺瞞だ」と、輸出先国の協力者が指摘し、その言及は認められませんでした。
結局、日本の開発者たちは輸出にあたり、墓地か教会内の人物のどちらかを直したうえで海外での商品化を果たしたそうです。
また、十字架に関してですが、赤十字のマークは国際常識・国際条約として赤十字社以外は使用できないことになっています。ゲームではないのですが、赤十字によく似たマークをデザインしたグッズの回収騒ぎなども実際に発生しています。
また、ドラゴンクエスト世界観の漫画作品、「ダイの大冒険」の電子書籍版と2022年版アニメーションで、六芒星(ろくぼうせい)の魔方陣で魔物を召喚使用、とする描写が修正されています。直接的な理由は公表されていませんが、六芒星はイスラエルの国旗にも描かれ、伝統的にユダヤ人を表す記号とみられている、だから、という理由が、Webではよく指摘されています。
欧米の判断基準が、アジア諸国やアフリカの生活習俗に合致しない場合も多いのですが、欧米のIT大企業はその欧米基準での規制が政治的に正しいと考えているでしょう。「日本では、少し考え方が違う」と言っても、通用せず規制される場合も多い。
共産党の機関紙『赤旗』がドラゴンクエストの職業について、「女性は回復職などの補助役割が多く、保守的な職業観、男女観ではないか?」と、指摘したことがあった(らしい)。
しかし、ドラゴンクエスト1~3の元ねたであるウィザードリィ・シリーズでは、僧侶(ウィザードリィでは「プリースト」)の職業は物理攻撃力・防御力もかなり高い前衛職です。
がウィザードリィでよくあるパーティ編成です。
プレイヤーによって、僧侶と盗賊の位置が入れ変わったり、ビショップと魔法使いの位置が入れ替わったりしますが、基本的に、僧侶は盗賊と同格の物理攻撃力・防御力です。
メイスやフレイルといった鈍器を振り回すのが、ウィザードリィの回復職のプリーストです。ドラクエもそれを踏襲しており、僧兵みたいに「鉄の槍」を振り回し、僧侶の物理攻撃力は魔法使いよりも高い。
ゲームだけでなくテレビアニメでも、漫画ワンピースの海外アニメ版では、主人公側の若者がタバコを吸っているシーンをアメ玉に作画を変えられたり、ドラゴンボールに出てくるミスターポポという肌の真っ黒なキャラクターの肌を青く書き換えたり、色々な例があります。
ポリコレとは関係ない事例ですが、TVアニメーションのポケットモンスターで主人公のサトシ達がお握りを食べているシーンで、アメリカ版ではドーナツになっていたことがあります。これは、国による食文化の違いを示していますよね。
ゲームでは、曲や絵が良くても、ゲームとしては今ひとつ面白くない、という事は起こり得ますよね。
ですからむしろ、商業的なゲーム制作では、イラストは簡略なものを使ったうえで、プログラム中心の試作品(プロトタイプ)をいくつか作り、その中でゲームとしての面白さがあるものを、取捨選択したうえで商品化を考え、その後イラストや楽曲を詰めて完成度を高めていく、と、いう制作過程を取るようです。
書籍『ゲームプランナー入門』(吉冨賢介 著)によると、商業ゲーム界では、企画書に書かれたゲームが本当に面白いかどうか確認するために、「プロトタイプ」が作られます。プロトタイプの段階では、プログラマーと、企画の意図を考慮するためプランナーも関わります。
イラストレーターは、プロトタイプの前段階あたりでイメージイラストを提供し、スタッフ間の共有イメージを作ります。そしてプロトタイプ進行中は、グラフィック案の提案をしていきます。サウンドも同様、プロトタイプでは、曲調を固めていく段階です。
プログラマーは、そのゲームでコアになるプログラムやシステムやミドルウェアについて、プロトタイプ段階で実装検証を済ませておく必要があります。プロトタイプより前の原案の段階では、利用するミドルウェアの洗い出しをして、出来る範囲での基礎実験をしておきます。
ミドルウェアによっては使用料が発生するので、その点を事前に調べておく。
プロトタイプのうち、張りぼての例えば画面だけの物等を、「モックアップ」といいます。一方である程度遊べる状態まで作っているものを、「プレアブル」といいます。
ゲームデザイン本ではよく「プロトタイプ」という表現が用いられるので、本ページではこの言葉を使うことにします。
任天堂『ゼルダの伝説 ブレス オブ ザ ワイルド』は、プロトタイプの段階ではイラストを組み込まずに(イラストは、代わりに大きなドットの塊などで代用する)作られている事がゲーム業界見本市イベント CEDEC 2017 で公開されています。(おそらく音楽もプロトタイプでは組み込まないのだろう。)
プロトタイプの段階では、画像や音楽は発注せず、骨組み的なプログラムだけで、そのゲームのアイデアが「はたして本当に面白いか?」を、実際に社内の関係者にプレイさせてみて確認します。
ちなみにプロトタイプに関しては『高等学校情報/その他の技術的な話題#プロトタイプ開発』の記述も参考になる。
ここでいう「プロトタイプ」(試作品)とは、コンピュータプログラムのゲームとして動作するのが前提です。映画製作でいう絵コンテ試写のように、ゲームの試作では、なるべく早期に第三者が試作ゲームを遊べるように作っていく必要があります。
プロトタイプという言葉を使用すること自体が妥当かどうか。まず、書籍『ゲームプランとデザインの教科書』で使われている。書籍 Game Programming Patterns でも用いられている。
ニコニコ動画の経営者、川上量生が使っています。川上は角川書店も買収したので、おそらくそこ(カドカワ・RPGツクール販売元)でも使っているでしょう。
ゲームのプロトタイプの基本姿勢は、「汚く作って、やりなおす」です。もちろん最低限のプログラムの知識、勉強は必要ですが、あまり知識収集や理解充実を気にするより、実際に作ってみることを優先したほうがいいようです。チーム制作をしている場合はプロタイプは赤ん坊であり、そのチームで育てていこう、我々の子供だという意識で接しているようです。
まず工夫して作ってみると、今後自分が何を勉強すればいいかも見えてきます。
英語では「quick and dirty prototype」という言葉があります。
書籍『ゲーム作りの発想法と企画書のつくりかた』によると、シナリオライター志望者が企画書やシナリオ案をメーカーに送りつけても、あまり効果的ではないようです。
それよりゲーム形式でシナリオを書いてしまうのがいいようで、「CHR:ヒロインA(私服)、表示」のような文章を織り交ぜて構成していくのが推奨。
参考文献のその章では、シナリオライター志望者に向けて語られていますが、プログラマー志望なら、サンプルゲーム、サンプルプログラムを作ってしまうのがいいかもしれません。
1990年代、週刊少年マガジンに不定期掲載していた読みきり漫画『ゲームクリエイター列伝』では、カプコン社のゲーム『バイオハザード』を扱った『バイオハザードを創った男達』の際、制作過程でゲームデザイナーが大幅な作り直しを判断して進行させた、という描写があります。(ただしWikiboooks一編集者の記憶、詳細はあいまい)。
のちの、ゲーム評論家の阿部広樹の評によると、むしろそれは劇的な大きな決断ではなく、ゲームデザイナーの日常の普通の仕事ではないか、と語られています。
どんな肩書の人間だろうと、すでに決まって進行していた方針をひっくり返すのは、かなりのストレスのある判断で指摘になりますが、一般に漫画や映画、あるいはNHKの仕事に関するドキュメンタリーでもそうですが、職業や職業者の物語では、過剰に対象を美化し、劇的な演出によって関係者を称賛し、英雄視する傾向があるように思います。
仕様書や設定資料を超えて、誰もが遊べる試作品は、意味のある企画行為でしょう。前編集者は、時間軸・動きの制作意図の明確化、という言葉を使っています。もちろん短くまとめること自体もなかなか難しいのですが、工夫を凝らして、ゲームプログラムを完成させることが重要な経験であり、思考の具体化でもあると思います。
アルファ版はプロトタイプとは違うもので、その後段階で、ゲームの全体像が分かる一部分を、商品に準じた形で作ることです。
アルファ版でもそのゲームが本当に面白いかどうか検証がなされます。サウンドやビジュアルは商品に近いほぼ完成化された形で取り込みます。
アルファ版の使用の結果、プロジェクト中止の決定がなされる場合もあります。
ベータ版とは、会社によって意味が多少違いますが(たとえば『ゲームデザインプロフェッショナル』と『ゲームプランナ-入門』とでも微妙に違う)、おおむね、とりあえずのゲーム、最初からエンディングまでのほぼ完成状態をひととおり遊べる制作物です。
細かいバグ修正はこれらの段階では後回しにします。
基本的に
の流れ。
ゲーム制作の作り始めにおいて、必要な数学や物理の予備知識は、それほど多くありません。
文献『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』によれば、数学や物理の習熟に拘って、それに多くの時間と精力を費やして勉強するよりは、3Dの勉強などで必要を感じたら、そのつど、その分野の数学や物理を学ぶのが効率的だと述べており、また可能なら実際にプログラミングでその理論を試してみると具体的に理解をしやすいと述べています。
C言語を使ったゲームは、予備知識はそれほど多くないので、あまり難しいことは考えず、まず実際にプログラムを書いて作ってしまう事優先にするのが正解なようです。
市販のC言語入門書で、配列や関数などの一般的な機能を一通り習得したら、あとはVisual C++ で映像出力とキーボ-ド入力のみを、1~2週間ほど勉強、そしてVisual Studioを起動してゲームを作り始める。
うまくいけば数か月以内に、パソコン用の非ネット通信のゲームを作ることができるでしょう。
ただ、ゲームプログラミングを試みる人は、必ずしもゲーム制作のみが絶対的な唯一の目標ではない可能性もあるので、それぞれの立場に応じて、座学を取り入れてみるのもいいと思います。
さて、ゲームを作る時は、アイデアを頭の中だけに置いておくのではなく、文章に書きだしてみましょう。
そして、壮大な長大なアイデアではなく、1週間~1ヶ月ていどで成果の確認できそうなアイデアだけを書いてみましょう。
次にそのアイデアを、実際に動作するプログラム、ソフトウェア(つまりプロトタイプ)にするために、具体的などんな機能を持ったプログラム(簡単なものでよい)を制作しなければいけないか、自分のやるべきことのリストを、箇条書きで作ります。
IT界ではこういうリストを「ToDoリスト」(読み: トゥードゥーリスト)とか「タスクリスト」といいます。このページではむしろ日本語で、「作業リスト」と呼んでみましょう。
さて、このリストを作るときは、作業項目は具体的かつ直接的に解決可能で単純な目標に分割します。ですから例えば RPG の戦闘システムを作るときは、
と、あいまいに総体的に書くのではなく、具体的に、
という風に、作業項目を細かく分割していきます。
こうすることで、作業がひとつずつ比較的に簡単な要素に分解されていくので、楽になります。また、バージョン管理ソフトを使って管理している場合も、上記のような作業リストの分解をしておけば、各バージョンの概要を書く際にも作業リストの項目が転用できるので、一石二鳥です。
予定日は書かないほうがいいと思われます。スケジュールを管理したい場合は、別にファイルを作るといいです。
そして書き出した項目を優先順位で並べたら、最初の作業リストは完成です。
プログラミングする前に作業リストを眺めて、そして上の項目から実際に作業を開始しましょう。
そして一つの項目を完成させましょう。
そして作業項目がひとつ終わったら、「【完了!】」等、そういう情報を項目の前または後ろにつけます。
たとえば、
こうします。
以前の記述を残したまま、その作業が終了したことを示しておくわけですね。
また、もし追加の作業が必要になったら、たとえばダメージ計算システムを作るために、ランダム計算が必要になって、自分がそのプログラム言語でのランダム計算に詳しくないなら、たとえば
と、必要に応じて項目を追加します。
さて、これから行う作業を検索しやすくするため、たとえば
の様に完了した項目を後回しにしたり、あるいは
のように、(現在→)、を追加するのも良いでしょう。
つまり作業の記述をそのままに、どこまで進展しているかが分かる様に書き足していくわけです。
「ゲーム性」という概念があって、これがあるからこそゲームは面白く、魅力的だと考えられています。
プレイステーション開発元のソニーもこれを重視していますし、一般的に多くのゲーム愛好者、関係者たちもその考えに同意するでしょう。
ではゲーム性とは何か?
ゲームのジャンルにもよりますが、「駆け引き」や「戦術」、これが「ゲーム性」だとよく言われます。
『ゲームプランとデザインの教科書』によると、ゲーム性とは、シューティングやアクションでは「対戦の駆け引き」、RPGでは「戦闘と物語の介入」、シミュレーションゲームなら「戦略性」だそうです。
ただし上述の書籍によると、1990年代は今よりもゲーム性とシステムが重視されていたとの説明があるので、裏を返せば2010年以降の現代では、ゲーム業界ではゲーム性の重視の比率は1990年代よりも減っているかもしれません。
『ゲームプランナー入門』(吉冨賢介 著)では、ゲーム性とは「課題や挑戦の仕組み」であると結論づけています。そして、この達成感こそが「ゲームならではの面白さ」だと述べています。
メディアクリエイターの佐藤 雅彦氏(「だんご3兄弟」や「ピタゴラスイッチ」等を手掛けている)が、初めてかかわるコンピュータゲームで、ソニー・コンピュータ・エンターテインメントとの共同企画で、のちに「I.Q」(1997年にシリーズ第一弾を発売)と呼ばれるシリーズに携わった時、プロトタイプが全くゲーム性のないものになってしまい、それをプレイしたソニーの幹部陣の顔色が非常に曇ってしまったようです。
ここでの悪い反応、薄い反応の理由がわからなかった佐藤氏が、階段の踊り場でソニーの新人に尋ねてみると、「それが、あの、ゲーム性がないっていうか・・・」と言われたと出典の対談集に書かれています。
基本的に佐藤氏は、プロトタイプの企画を提案しただけですが、ソニーにはプロトタイプを作るための部署があるらしく、1~2ヶ月かけてそこでプロトタイプが作られたようです。
この問題の責任が誰にあるかは、大した重要な事ではありませんが、商業作品としてプロトタイプを作る以上は、どこかの段階でゲーム性を意識して、プログラムに盛り込む工夫が必要になるでしょう。
ふつうゲームのプレイヤーは、まず最初にそのゲームの「見た目」を判断し感受するでしょう。ですからその見た目のインパクト、興味を呼び起こす構成が必要になります。
例えばスーパーファミコンRPG『新桃太郎伝説』では、開発当初はドラゴンクエスト5 のようなマップ画面のトップビューUIでしたが、開発中にクォータービューの他社製RPGが発売されて高い評価を得たので、マップUIを(トップビューではなく)クォータービューに作り直したようです。このことは攻略本『新桃太郎伝説 究極本』に開発裏話として書かれています。
一方現在でもこの方向の試みは重要なようで、書籍『ゲームデザイン プロフェッショナル』の著者は、他企業の製品の画面と、自社の製品を目で見比べる分析方法で、自分たちの製品のUI の問題を見出しています。
割と素朴で単純で即物的な見た目、「かっこいい」とか、「ぱっと見派手」等の要素が非常に重要なようです。
商業としてゲームを作る以上は、ペイしなければ企業も事業の継続も維持できませんから、考慮せざるを得ない問題ではあります。
ゲーム開発ツールのなかには、そのツールで開発したゲームソフトに義務として「この開発ツールで開発したソフトウェアは、ソースコードを必ず公開しなければならない」などの条件をつけている場合があり、このような条件を「開示義務」(かいじ ぎむ)または「ソース開示義務」などといいます。
ソース開示が嫌な場合は、開示義務のあるツールは使わないのが正解です。
ゲームに限らず、ソース開示を義務としている開発ツールは多くあるので、ライセンスには気を配る必要があります。
「有料ソフトの販売を禁止」とか「アダルト作品の開発は禁止」などの条件をつけている場合も、ありえます。
ですからゲーム開発において、ツールのライセンス条件の確認は、非常に重要です。
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++のソースに置き換えるのは簡単にはできない。ほぼ全面的に新たに書くことになるでしょう。
ゲーム制作、業界において、イラストや音楽を作る部署、人物は、まとめて、"アーティスト"と呼んでいるようです。
ゲーム界の場合「デザイナー」というのは、プランナーやディレクターのことであり、管理職的な設計者のことで、美術的なクリエイターではない場合がある。美術的なクリエイターも同音異義語でデザイナーと呼ぶ場合もあるが、本wikiでは区別のためアーティストという言葉を用いる。
映像関係、画像系のアーティストはグラフィッカーと呼ばれることもあります。ムービー担当者、特にゲーム界では3D-CGの制作者をアニメーターと呼ぶことが多いようです。アニメーション業界では主に、手描きの原画、動画マンをアニメーターと呼びますが、最近は3D-CGアニメーション映画も多いので、すこし状況が変わっているかもしれません。
ゲーム業界とアニメーション業界、各会社企業、過去と現在で、「原画」「仕上げ」「絵コンテ」等、一般的な作業に関する言葉が、それぞれの状況で微妙に違った意味で使われることも多いので、それそれ自分の所属する状況に適した言葉の使い方を考える必要もあるでしょう。
操作性について、親指と人差し指だけでボタンプッシュなどの操作ができるように作成するのが基本です。中指、小指、薬指はコントローラのホールドに使うぐらいです。人間工学的に、小指や薬指は力が弱いので、微妙な操作には向かないことが知られています。
一般的にゲームプログラミングでは、
入力と出力、この2点が機能として必要になります。
プログラミング言語とプレイヤーからの入力については歴史的にも、あまり変化がありません。言語では主にC言語、C++が用いられる。携帯電話向けのゲームではJavaが利用されましたが、これは携帯電話を提供する各社がJavaをアプリケーションの言語として選んだことによります(iアプリ、EZアプリ、S!アプリなどを参照)。現在でもAndroidなどのスマートフォン向けでは、Javaが使われています。
パソコンゲームでは、プレイヤーからの入力には通常、キーボードかマウスを利用します。他にジョイスティックやゲームパッドが利用される場合もあります。家庭用ゲーム機ではコントローラが利用されることが多いのですが、ニンテンドーDSやWii 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関数以降の部分でコード共通化できることは色々とあります。
「共通性のあるコードだから」といって、大して長いわけでもないコードを関数に置き換える事は、速度維持には寄与せず、ゲーム制作のプログラミングとしては、悪手となるでしょう。
画面出力の場合も入力機器の場合と同じで、これらを操作する方法はOSごとに異なっています。先ほどあげた GTK+, Qt, SDLなどのライブラリはクロスプラットフォームの画面出力を提供しているため、これらを利用することで全てのプラットフォームで動くプログラムを作ることができます。
※未作成
※未作成
※未作成
OSの種類によって、キーボード入力やマウス入力の受け付けのさいのプログラムの書き方は違う。
Windows API での具体的な手順は『ゲームプログラミング/入力』で説明する。
厳密にはプログラミングの話題ではないが、ゲーム製作では必要な知識なので、サブページで説明する。
説明書や仕様書(しようしょ)の書き方については、『ゲームプログラミング/書類』で解説する。
Visual Studio付属のフォームデザイナ(VSの用意するGUI自動作成ソフト)によるGUIオブジェクト作成では、RPG用には使いづらい。いや、ひょっとしたら上手に使う方法はあるのかもしれないが、様々な理由で難易度は高い。
そこでまず、Visual C++で、フォームデザイナをなるべく使わずに文字や映像を出力する方法を考える。
選択肢は、幾つかある。
1. フォームデザイナを1つも使わない方式
2. 1つだけフォームデザイナのパネルを使う方式
フリーソフトでゲーム用ライブラリの『HSP』はWindows API を呼び出す仕組みになっています(HSP関連のサイトを見ると、Win APIプログラミングの解説をしている場合もある)。
フリーソフトでゲーム用ライブラリの『DXライブラリ』は Direct X を呼び出す仕組みになっています。そして、ゲーム開発ツールのひとつであるウディタのソースコードは、DXライブラリとVisual C++ を使って書かれていると、作者が公表しています(ただしソースコードは非公開)。しかし、ウディタを用いたRPGプログラミングでは DXライブラリによるコーディングはしない。ウディタにはコード入力の機能は無く、マウス操作や、キーボード操作、キャラ名称や会話文などのテキスト文字や数値の入力のみに対応している。
そもそも乱数とは何かという問題があるが、それは高度な数学的な議論になるだろうから、我々はその問題には深入りできない。
ゲームにおける乱数的な処理では、事実上ランダムな値にならず、演出や調整のためにアルゴリズムが介入している場合も多い。例えばゲーム中のくじで「外れ」続くと、当たり確率が変動し、次からは当たりやすくなるアルゴリズムなども良く使われる。。
ゲームは娯楽であり、実用目的のシミュレータではないし、アルゴリズム介入で、確率的にもいんちきが多いので、あまり厳密なランダム性が問題になることは少ないだろう。
例えばさいころというのは典型的な乱数器だし、ゲームにもよく使う物だろう。
ゲーム「桃太郎伝説」シリーズの開発者のさくまあきら氏、ハドソン社が、参考として他社RPGであるドラゴンクエストの乱数を真似しようとして分析したところ、初期ドラクエが戦闘ダメージのゆらぎについて高度な計算を使って実装していると思った部分が、実際には簡単な疑似関数だった(伝聞としてそう聞いた)、という開発談もあります。
無印C言語には標準的乱数関数 rand()があるが、これを乱数発生に使うことに批判的な意見もあるし、機能もやや不足していると見れる。
Windows64bit では int rand(void) の出力は 32bit 整数だろう。まず stand関数で初期化してから rand()を呼ぶごとに疑似乱数が帰ってくる。これの複数回の連なりが乱数列だね。帰ってくる値は0 以上 定数RAND_MAX の値以下。
例えばさいころの数値が欲しいなら、rand の返り値を6で割った後、余りに1足せば、とりあえずそれらしいものはできる。
RAND_MAXは rand()の属性として定数が与えられているだけだから(Windowsで0x7FFF)、この値の変更はできない。
まあこれでもそこそこいい加減な乱数として機能するだろうが、最近ではもう少し改良された、質の高い乱数関数もある。
また、改良された乱数関数は、乱数の範囲も指定できるから何かと使い勝手が良いし、バグを防ぐ効果もあるのだろう。
↑例えば上述のコードは前編集者が示したものだが、これは .NETプログラミングですね。.NET のSystem::Randomクラスを使っている。.NETのクラスは普通、C#かVisual Basic で利用するので、Visual C++で使えるようにするには結構面倒な手管がいるが、その辺は読者諸兄、ヘルプやネット情報を参照して、適宜辿り付いてほしい。
C++ の場合はむしろ、 #include <random> を宣言してそこで使える関数を使用するほうが簡単でしょうね。この場合でも、乱数としての精度も高いし、帰り値の範囲指定もできる。
画像がひんぱんに変化するアプリでは、画面が、ちらつく事がある。画面のちらつきは、ゲームのように、画像を凝視するアプリでは、かなり利便性を損なう。
キャラクターが1歩移動するだけで、画面全体がちらついたりする場合もあり、かなり、プレイヤーの不満になる。
これは、ダブルバッファ(「裏画面」と、良く言われる)という技術で、解決を図る。
Direct Xの用語では「スワップ チェーン」と呼んでいる。
.NET Framework開発環境の C++や C#でもダブルバッファの機能があると解説されている。いくつかのGUIオブジェクトのプロパティで、ダブルバッファの設定項目がある。
しかし前編集者が実験したところ、この機能を有効に使って確認することはできなかったとの指摘がある。ひょっとしたら何らかのマイクロソフトの解説に間違いがあって、工夫次第では利用できるかもしれないが、少なくとも今現在のこのページでは、その問題に関するリファレンスは提供できない。
そこでやはり、以前の項目と同様、Win32 API または DirextX の利用をこのページでは考えたい。
前編集者は、.NET Framework のフォームデザイナでは、ちらつき自体は解決できそうだが、グローバル変数の共有が困難だったり、アプリ内から終了コマンドが使えない、などの難点があると指摘している。
ただ現編集者はこの2点に関しては、解決策はあると思うが、しかし特に調査はしない。
前編集者は、.NETプログラムでゲームを作る難点をいくつも上げているが、おそらくどれも、.NET の仕様や全貌に精通すれば解決できるように思えるが、そもそもその全貌がかなり広大なので、解決の道のりは長いだろう。
数値(HPなどの各種パラメータ現在値)や文字列(例えば、プレイヤーの作成したキャラクターの名前)や現在地やフラグ状況などなど、セーブの機能は欲しい。一番簡単な方法は、C言語の fopen 関数のテキストファイル書き込み機能で、テキストファイルとしてセーブすることだろう。
Windows API には CreateFile関数 があるが、テキストファイルでの素朴なセーブは一番簡単で単純なセーブ法だろう。そしてテキストファイルを読み込んでプログラムに各種変数を配置して、ロードとする。
書き込みとしては、一番単純なC言語記法では、fprintf ですかね。C++としての書き込みをしてもいいし、読み込むのも、一番基本的な方法で。基本Cだとしたら fscanf で、この関数でテキストの数値も変数として読み込めるはずです。場合によっては atoi関数 で文字列→数値の変換をすることもあります。
基本的にデータファイルは、OS もアプリケーションも、テキストファイルとバイナリファイルの2分類で考えるでしょう。実際にはテキストファイルもバイナリの集まりですが、慣用的、伝統的にテキストファイルだけ特別視することが多い。
バイナリファイルでもデータとしてのファイルと、OS が機械語または何らかの仮想的な機械語として扱う実行ファイルがある。それらのバイナリは種類に応じて多くは冒頭にファイル識別子の情報があるだろうし、OS や アプリケーション側で工夫を凝らして、特定の条件を満たす場合しか動作しないようにしているだろう。そしてバイナリファイルを扱うときは、セキュリティの安全性も考慮するだろう。
基本的にプログラム側は何でもありだが、識別子の判別その他、ある程度様々な考慮をしないと、困った事態が起こり、プログラマーが責任を問われることも起こるかもしれない。
市販のパソコン用ゲームや同人ゲームでは、テキストファイルではなくバイナリでデータ保存するゲームの方が圧倒的に多いだろう。その方がそれらしいしかっこがつく。ゲーム開発ツール側自体も、そうなっている場合が多い。RPGツクールもウディタも、セーブデータの形式はバイナリ。
テキストデータは基本エディタで開けるが、バイナリデータも内容によっては結構ぐちゃぐちゃの状態で開ける。バイナリデータはバイナリエディタで開ける。バイナリエディタのリードオンリーモードやバイナリビューアみたいなものがあれば、データを壊さないで結構安全にデータ調査できる。
データ内容を秘匿したければ、バイナリ化だけではなく、暗号化も必要になるかもしれない。
セーブ&ロード機能の実装時には、まずセーブ機能から作るのがやりやすいという。
しかし最終的には関係関数の整備は、ロード機能が基盤となるだろう。
データや変数を、一定のスタイルでセーブして、一方で正しいスタイルでロードする、この機能が必要なわけですよね。
シリアライズされたデータを、型を決めたうえで配置しなければいけないから、ロードのプログラムの方が複雑に、面倒になる。
結局データのシリアライズは、ロード機能が基盤となり、その機能の作りやすさが、セーブ機能の作りやすさも支配するようだ。
RPGやシミュレーションゲームで、1回しか起きない特殊イベントを作りたい場合もありますね。例えば日本の中世の戦国シミュレーションゲームで、「桶狭間の戦い」が3回も起きたら困りますよね。まあ起きるなら起きてもいいけどね^^。信長君には敦盛を3回舞ってもらいましょう^^。
さて、リンク先ではその話題についての叩き台、「こうプログラミングしたら、いいんじゃない?」、という事を説明しています。
個人でゲームを作る時にはあまり考慮しなくていいのですが、シビアな仕事の世界では、スケジュール管理表が良く使われます。
「作業責任分担表」(TRM:Task Responcibility Matrix)といわれるスケジュール表から、それをグラフ的に図示したガントチャートといわれる表を作って、その表を見て作業計画を判断する。
ガントチャートでは普通、横軸に日程をとります。
商業ゲーム界でもガントチャートの横軸は日程です。
ガントチャートとして図示することで、ボトルネック、リスク要素、直感的にスケジュールの詳細や全体像が理解しやすくなります。
スケジュール管理のための、現実的、習慣的な工夫ですね。
このTRMとガントチャートは、IT業界だけでなく建築工事でも使われ、これを利用したボトルネックの洗い出しも、建築学の教科書に記述があります。
住宅の新築やリフォームをする時、建築業者がこの表を提示して、見せてくれることもあるでしょう。
業界人ではなくとも、こういう慣習を知っておくと、得るものがありますよね。
ゲーム界、特に商業ゲーム界では、ストーリーもゲームも全体から作っていくようです。アトラス社(ペルソナシリーズ、女神転生シリーズ、などを手掛ける)では、「ゲーム全体に血を回すのが先」、という言葉が良く言われていました。
プレーヤーが見たいのは、物語の細部ではなく、ゲーム全体のストーリーやテンポ、総合像である、とは限らないのだが、しかし物語を含む創作物では、全体を見て重視し、そこから作っていくのはある意味王道、常套手段ではあります。
ちなみにやや雑談的ですが、日本の週刊漫画は、その週その週での勢いや読者の興味の引き付けも大事なので、全体がないのに、その場その場で場当たり的に作られた事も多かったようです。
現編集者が聞いたことのある話では、週刊少年ジャンプで連載していた本宮ひろ志氏が、不良少年物の漫画で、敵の不良少年グループと1対1000の喧嘩になり、さあいよいよ対決場に着いて勝負だってところで以下次号にし、そして実は本宮氏はその続きを全く考えていなくて、考えてみたけどどう考えてもどう描いていいかわからない^^;;;、そこで仕方ないのでイライラして近所の酒場に飲みに行き、そしてイライラしたままそこの常連達とあり得ない大ゲンカして^^;;、そのままボロボロになって家に帰って、2時間で次の号の漫画を描き終えた、と、本宮氏自身がメディアで語っていたのを聞いたことがあります。
さて、コンピューターゲームである以上、ゲームのストーリーはシステムと連携、調和したものになるでしょう。
そこで、ゲーム作家として、システムを先に決めた後ストーリー、そういう方法論の作者も多いようです。
とにかく商業ゲーム界では常識的に、全体像から攻めていく。
例えばドラマ脚本では、「ハコ書き」という方法がある。全体像に当たる「大ハコ」を記述してから、「大ハコ」→「中ハコ」→「小ハコ」と記述していく。
しかし、本当にすべてのゲーム制作は全体から作る必要があるのか、という疑問はありますが、その方法論に従うとすると、
などの工夫を凝らして、常識的な方法を遂行していくことになるでしょう。
或いは、アルファ版(α版)を中盤から作り始めるとか...。α版の製作目的の一つとして、そのゲームが本当に面白いかの検証がある。面白くないと判断したら、制作中止もある。最初からではなく中盤から作ると、ゲームの全体像が見えるので、検証、判断がしやすい。
つまり全体から攻めて、細部やゲームが作られていくわけですから、必ずしも冒頭部から作り始める必要はないわけです。
ゲーム作者にもよりますが、商業ゲームシナリオでは、エンディングを早い時期に作る人も多い。
システム面についても、先にゲーム全体のクリア条件を決めてから、あとから各ステージの条件を決めていくことが多いようです。
エンディングの仮の、おおざっぱなシナリオ、そしてキャラクターの性格付けを先に決めておくと、ゲームの方向性と主人公達が目指すもの、ゲームの全世界像が作者やスタッフに明快になっていきます。
基本的に商業ゲーム界では、全体→部分と細部、の構成を進めていきます。
ゲームは必ず最後にラスボスと戦う訳では無いでしょうが、その戦いはゲーム中で最も高負荷になるでしょうし、全てのシステムが集積する場面でもあるので、エンディングを先に作ると、ゲームの最大負荷の検証ができます。
3Dゲームでは、RPGなら戦闘シーン、アクションゲームならアクションシーンが、一般的に最も高負荷。
負荷が高くて処理が落ちないかどうかも、この方法で確認できます。
常識的、教条的物語手法、そして金と権威を持っている人間の言を神のように崇めるとしたら、たいていの物語は最後の最後が一番の見せ場になると考えられるでしょう。ストーリーを削る必要があるとすれば、最後以外の部分、という事になります。
つまりラスボス戦は削らない。後の部分は削る可能性あり。だから最後を先に作っておけば(作れる範囲で)、もし制作過程で不測の事態が起こっても、重要部分はできているので、早く、上手にリリースできる。
世の中では目的や目標を明確化せよ、と主張する人は結構多い。現編集者は懐疑的。むしろ他人を自分の都合いいように動かしたいから、その方向を明示したいのだろう。それより、我々の本当の目的と目標は何か、歩みを止めてちょっと考えてみろよ、と、言いたい。
しかし結局世の人たちは目標をはっきり、言語化したがる。ゲームでもそれをすると、プレイヤーがゲームに引き込まれる、と言うが、実際にはそれはゲーム業界のカモになっている、インチキゲーマーだけだろう。
とにかくカモたちは目的を欲しがる。目標や課題がゲーム中で明確になっていないと、疑問だらけになり、ゲームをやめて、業界にお金を落としてくれない。そこで設計の際、各ステージやエリアなどの冒頭で、そのステージの課題や目標などを明示する必要があるという。
ファミコンなどの古いアクションゲームではゲーム本編では目標は語られていませんが、しかし説明書などではきちんとそれが語られており、実際にスーパーマリオブラザーズの第1作目の説明書では、目的はクッパを倒してピーチ姫を救出することだと語られています。
RGBやシミュレーションゲームでは、初めの方は、操作説明のためのチュートリアルイベントになることも多いのですが、ここにも製作順序のポイントは指摘できますね。
基本的にはチュートリアルの細部は後回しにしたい。と、いうのはゲーム本体の仕様変更が、製作過程で頻繁に起こるので、チュートリアルもそれに合わせて後回しにせざるを得ない。
最初の段階でチュートリアルを作りこんでも、仕様変更になれば、その記述自体が不適になる。
当初のチュートリアルイベントがそもそも必要かどうか。説明書、マニュアルに任せてもいいですよね。
基本的にゲーム本体の仕様がかなり変更を含み場当たり的なので、チュートリアルは後回し、早くともゲームα版の時期になるでしょう。
ゲーム制作の時は、自分が昔プレイして楽しかったゲームを思い浮かべるし、参考にもしますよね。
ただ、コンピューターゲームは明らかに、周辺技術が時間とともに、かなりの速度で発達、変遷していきますし、過去のゲームを参考にすると言っても、精神面、思想面での参考で、技術面ではやはり、最新の情報技術を取り入れたいと、誰もが思うでしょう。
編集者Hの意見
別編集者 S の意見
(参考)松尾芭蕉が「古人の跡(あと)を求めず、古人の求めたるところを求めよ」と言ってるようです。『韻塞』(いんふたぎ)が出典らしいです。おそらく、古典芸能の格言の元ネタか、あるいはそれを受けての発言でしょう。どちらが先かは知りません。

ファミコン時代の昔のゲーム機には、一画面に表示できるキャラチップ数(敵チップも含める)に上限がありました。
一画面中に表示できる限界は、だいたい、マリオが一画面中に数十人ぶんです。
このように、ビデオゲームで小さなキャラクタを、高速表示する仕組みを、「スプライト」と呼んでいました。マリオのキャラクター表示は小単位のスプライトを複数合成していたようです。
このキャラクター数の制限が、当時はゲームの設計にも大きな影響を及ぼしていたわけですね。
例えばシューティングゲームで、100体の敵機を表示することはできない。
しかしそれなりの工夫はあった。表示のタイミングを変えることで、なんとなく、多量のスプライトがあるように見せることはできた。
つまり、
して、切り替える、うまく、素早くとか?
上手にプログラムを作ればそこそこ上手くいったようですね。それでも、キャラクターが多いと、一瞬、消えたりしている。
ファミコン上における実際の技術限界の正確な数値は、別の資料を参照していただくとして、あまりあてにならない数字として例えば、横1列上には 8体目までしか表示できなかったようです。マリオは一人で2*2=チップ使っていた。だから横一列では 4体までしか表示できませんね。
例えばシューティングでは、敵機の他に、弾丸などもスプライトでしょう。
マリオが4チップなように、巨大ボスなんかチップ数をかなり使っているでしょうね。
そしてチップ数が多いから、速度が遅くなるのでしょうか、何か我々の昔のゲームをプレイした記憶では、巨大ボスの動きは緩慢でしたよね。
しかしやや脱線しますが、巨大なキャラクターは何となく動きが遅いという我々の固定観念がある一方で、レスラーやヘビー級ボクサーはかなり動きが速い。相手の体が大きい上動きが早ければ、もう勝てないね。座して死を待つしかないか^^;;;。
ファミコンのマリオの横スクロールでは、例えば地上ステージの空は、青一色で描き換えを行わない。低地の地面の障害物周辺だけを動かしていたようですね。動かす部分はプログラムでの描き換えが必要だし、動かない部分は背景として、描き換える必要がない。
書き換える必要のない背景表示は当然プログラムの負荷も少ないですよね。
ですから昔のレトロゲームの雰囲気や映像、仕様は、当時の技術の制限、影響を受けた上でその形態になっていたという事で、今は技術が発達したので、様々な斬新な映像表現や、演出を駆使できる。
一方で最新の技術を駆使したうえで、過去のレトロな雰囲気を再現、表現するという道もあるでしょうね。
昔のブラウン管テレビのドットは、にじみが大きい。これはテレビ画面の性質なので、ゲームでも映画でもバラエティでもドキュメンタリーでも、解像度画面としてのにじみは同じように大きい。今の液晶画面が完全ににじみがないかどうかは怪しいが、ブラウン管よりは少ない。
そのため、当時の画像データをそのまま現在のパソコンで表示しても、にじみによるアナログ感がなくなり、荒い画像に見える。当時のゲーム攻略本にあるような写真画像は、同じデータではあるのだが、現在では上手に再現できない。
解像度だけではなく色についても、にじみの色の重なりで、昔の映像の方が豊かな色に見え、現在では雰囲気の再現はうまくできない。
昔のゲームはアナログ技術だからこその、独特の雰囲気を表現していた。
ですから昔のゲームのレトロな雰囲気は、データとしての昔の仕様をそのまま使っても再現できず、むしろ昔の画像写真の資料を見ながら、現在の技術、現在の機材によってその雰囲気を再現することを目指すことになります。現在では様々な画像フィルターも作れますから、そういうものの利用も有効でしょう。あるいは過去のデータ、仕様をそのまま使うなら、それは新たな画像世界になるかもしれません。
過去の低解像度画像を使ったゲームは、レトロではなくむしろ新ジャンルだという指摘があります。
90年代のカラー携帯ゲーム機の画像データをそのまま使って現在の液晶画面に表示すると、当時のディスプレイは走査線が太いので、画面として縦横比が変わってしまう。縦横比を補正すると走査線部分の黒線や余白が入り、それをドットで埋めて補正すると、画面のギザギザが目立ってしまうようです。
つまりディスプレイの性質が90年代と2020年代とで違うので、レトロ画面の再現はかなり困難、最初から目指さない方がいいだろうという意見もあります。
パソコン市場では、1999年ごろからノートパソコンが普及し、液晶ディスプレイも安価で出回ってきた。そこでにじみの少ないくっきりした映像が主流になってきますね。
基本的にディスプレイはブラウン管→液晶と変わり、解像度は大きくなる一方です。
プレイステーション2あたりからは家庭用ディプレイの切り替えが起こり、もはやブラウン管でのプレイ自体がなくなる。 アナログ放送は2010年ぐらいまで続いたでしょうか。しかし家庭ではゲームをするにしても、普通に放送を見るにしても、DVDを見るにしても、ブラウン管から液晶や、プラズマというのもありました、画面の解像度自体も高くなっていく。
そして画像のドットはにじみの少ないくっきりしたものへ変わっていきます。最近はパソコン画面でも、TVでもドットの縦横は等しい正方形ですが、ブラウン管はそうではなかった。
だから、当時はドットで絵を描く時も、長方形ドットです。
しかも、ゲーム機やパソコンの種類、さらにはアーケードゲームの基盤といったハードウェアの種類ごとに、コンピュータ側でのドットの縦横比の管理は違っている(らしい)。このため、移植のたびに、ドットは書き直しになったようだ。
昔は、というか実はいまでも、CGや画像の縦横比が正確ではない映像を見る事はありますよね。
現在のパソコン用のドットエディタ(ドット絵用の画像制作ツール)は1ドットが正方形だが、ファミコン時代は1ドットが(ドット用紙の時点で)少しだけ長方形。(なお、画像制作ツールの作り方については、『ゲームプログラミング/画像ファイルの作成プログラム』というコンテンツがこのサイトにある。)
ファミコンの色数制限は52色から4色×4パレット(1パレットあたり4色)を使えると言われている。しかし実際には、4色のうち1色は透明色として利用される色であり、全パレット共通の色になる(だから3×4=12色が使える)。 スプライトのパレットとは別に背景のパレットがあるので実際にはもっと多くの色数が一画面内で使えるが、しかしその他さまざまな制限があるので、合計で一画面内で25色が使えると言われる(12+13=25)。
論理的には25色だが、ブラウン管のドットの滲みやテレビのアナログな仕様から、結局はなかなか豊かな映像が当時も見れたと言っていいのではないだろうか。
しかしレトロなゲーム機では、さらにメモリ容量やストレージ容量などの制限もあり、仕様上の最大色数を気軽に利用できたわけではないかもしれない。こういう制限もあったからか、ネットではファミコンの色数が「4色」や「8色」、スーパーファミコンの色数が「16色」や「256色」、とも言われることがある。

外食チェーン店のマクドナルドが、子供をターゲットにした商売をしており、子どもの頃に気に入った味は、大人になっても食べ続けるという販売戦略です。例えば日本マクドナルドの創業者、藤田田(ふじた・でん)によると「人間は12歳までに食べてきたものを一生食べ続ける」と言っています。だから子どもの好きそうな味の料理を作ったり、あるいは子ども向けの定職に、子どもの好きそうなオモチャのオマケをつけたりします。
12歳と言い出した経営者は誰が最初なのか調べても良く分かりませんでしたが、そういう意味の話です。
ゲームというのは色数も少ないし、静止画も多い。
ファミコン時代から、同じ色長時間の表示は、ディスプレイの焼き付きを起こすので、常にそれなりの工夫がされていたかもしれませんね。
静止画を避ける、時々背景を変える、背景色を光のエネルギーを持たない黒にするとか...
パソコンでは昔からその工夫がありましたね。スクリーンセイバーという機能もある。
とにかく一つのドットに同じ色が長時間表示されると...ちょっと危ない。
焼き付きの問題は昔も今もありますよ。昔のブラウン管は焼き付かないという主張が時々あるようですが、事実ではないでしょう。
現代のテレビ受像機には、焼きつき防止のために「ピクセルシフト」という機能がある。これは画面上の映像の表示位置をタイミングごとに微妙にずらす機能です。こういう機能がすでに搭載されているので、ゲームソフト側で焼き付き防止を必要以上に考慮しなくてもいいらしい。液晶モニターは、焼きつきが起きにくいという。ただし有機ELはどうか。知りませんね。現編集者も前編集者も知らない^^;;;。