ゲームプログラミング

概観編集

この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年以降、この考えは当てはまらなくなっています。

PlayStation1~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]

読書について

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

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

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

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

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

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

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


ゲーム、産業、コンピュータに関する多少の昔語り

ゲーム機が産業のけん引役かと語られた時期は、おおむね2000年以降~2010年あたりまで、です。

現・経済評論家の池田信夫(いけだ のぶお)は、1980年代の当時NHK記者だったのですが、彼は当時のIT業界やゲーム産業も取材しており、80年代当時は経済界などから未来技術として本命視されていたのは人工知能だったが、実際に流行した技術はゲーム産業だった、というような内容のことをブログで発信したことがあります[8]。なお、池田は、「大手コンピュータ・メーカーは、ゲームを無視した(*)。」と書くが、実際には90年代にもNECのPCエンジンや、富士通がスポンサーについたPCゲームソフト、ゲーム業界ではなくアニメ業界でも電機メーカーだが東芝のスポンサーしたOVAや大手ではないがパイオニア社のスポンサーしたOVAなど幾つかあるので、少し事実と違うように思う。

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

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

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

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

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

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

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

また、日本だけでなくマイクロソフトのXBOXなど、実際に欧米の企業もゲーム機に参入していた。このへんの雰囲気は、動画サイトでXBOXの開発談等、マイクロソフトの開発動画を見てみると、この企業もゲームが単に市場だけではなく技術としても意義がある、と、感じていた雰囲気がつかめると思います。

そして90年代の岡田が先ほどの著書で言うには、おおむね「よく人々はスーパーコンピュータなどの大型コンピュータに未来を夢見るけど、これからの技術はむしろ小型、短小な軽量端末の開発だ」といった内容(手元に書籍がないので言い回しは多少は違うかもしれません)。

しかしすじ肉しちゅ~はなぜこんなに岡田を誉めそやしたいのかね? 岡田のパシリ? 腰ぎんちゃく?

また評論家の阿部寛…じゃなかった、阿部弘樹^^;;;、によると、90年代の当時の少なくないゲーム消費者は汎用機(パソコン)を不信していました。汎用機から出るゲームはつまんないのばっか、と、と考えていた人が多かったようです。岡田も同様の認識であり、「ゲームに限らず汎用機で例外的に優れたソフトがあっても、需要があるなら専用機が開発されているはず」という認識であり「だからパソコンではなくゲーム機こそが未来技術だ」と、主張していました。しかしこいつら、理屈ばっかだね。典型的な頭でっかちの性格異常の愚か者。

とは言え実際、パソコンゲーム出身のゲームでも、「信長の野望」など人気作は、スーパーファミコンやプレステに移植されています。

ソニーからプレイステーション2が出たときは、当時のソニー経営者はDVDも見れる汎用機としてインタビューなどで宣伝したが、数日後に広報・宣伝がゲーム専用機として宣伝しなおした、と阿部寛…じゃなかった^^;;;(←しつこい^^;;)阿部弘樹が論じました。

だからゲーム機というのは、本来はデジタル家電の中枢端末を目指しているのだが、表向きはゲーム専用機だと言い張る、相変わらず金にしか興味のないインチキ大人の口先だけの茶番が続けられているわけです。

産業としてのゲームの重要性は、90年代ではあまり語られていなかった。経済評論誌で語られるようになったのは 2000年以降のようです。


ゲームプログラミングは面白い。しかし、そんな楽な事ではない。編集

ここでいう「プログラミング」とは、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年現在)。


プラットフォ-ム編集

ライセンス料

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

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

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

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

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

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

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

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

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

ポリコレ規制編集

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

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

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

ドラゴンクエストのファミコン時代、海外輸出の際、教会での描写を変更しなければいけなかったことがありました[要出典]。これは、岡田斗司夫氏の YouTube放送でも話題にされています[要出典]。教会の描写で、神父とシスターが同じ建物で仕事をしていた[要出典]。これが問題になったらしい[要出典]。カトリックでは妻帯禁止ですし、男女が同じ場で働く描写がよくないようです[要出典]

開発者たちは、「教会の描写はキリスト教ではなく、ゲーム世界独自の宗教」と主張して、難を逃れようとしましたが、しかし教会の裏にある墓地が十字架のマークだったので、「十字架はイエスの磔(はりつけ)の場でありキリスト教で重要な意味を持つ。十字架の墓標がキリスト教ではないという主張は欺瞞だ」と、輸出先国の協力者が指摘し、その言及は認められませんでした[要出典]

結局、日本の開発者たちは輸出にあたり、墓地か教会内の人物のどちらかを直したうえで海外での商品化を果たしたそうです[要出典]

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

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

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

共産党の機関紙『赤旗』がドラゴンクエストの職業について、「女性は回復職などの補助役割が多く、保守的な職業観、男女観ではないか?」と、指摘したことがあった(らしい)[要出典]

しかし、ドラゴンクエスト1~3の元ねたであるウィザードリィ・シリーズでは、僧侶(ウィザードリィでは「プリースト」)の職業は物理攻撃力・防御力もかなり高い前衛職です。

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

がウィザードリィでよくあるパーティ編成です。

プレイヤーによって、僧侶と盗賊の位置が入れ変わったり、ビショップと魔法使いの位置が入れ替わったりしますが、基本的に、僧侶は盗賊と同格の物理攻撃力・防御力です。

メイスやフレイルといった鈍器を振り回すのが、ウィザードリィの回復職のプリーストです。ドラクエもそれを踏襲しており、僧兵みたいに「鉄の槍」を振り回し、僧侶の物理攻撃力は魔法使いよりも高い。

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

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

プロトタイプ編集

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

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

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

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

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

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

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

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

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

商標権等

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アルファ版編集

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

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

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

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

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

基本的に

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

の流れ。

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

数学は後回し編集

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

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

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

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

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

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

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

作業リストを作る編集

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

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

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

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

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

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

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

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

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

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

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

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

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

作業リストの更新編集

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

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

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

たとえば、

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

こうします。

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

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

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

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

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

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

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

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

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

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

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

ゲーム性編集

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

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

ではゲーム性とは何か?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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++のソースに置き換えるのは簡単にはできない。ほぼ全面的に新たに書くことになるでしょう。

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

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

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

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

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

操作性編集

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

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

  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以外のジャンルを制作するのには、実質的には限界があり、さまざまな制約が生じます。

C++での具体的な手法

初期段階では関数や変数を活用してプログラミングし、処理速度を高める必要がある箇所にだけ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で入力していく方法。DirectX自体はWindowsAPIを利用している。

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

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

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

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

乱数編集

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

ゲームにおける乱数的な処理では、事実上ランダムな値にならず、演出や調整のためにアルゴリズムが介入している場合も多い。例えばゲーム中のくじで「外れ」続くと、当たり確率が変動し、次からは当たりやすくなるアルゴリズムなども良く使われる。[42]

ゲームは娯楽であり、実用目的のシミュレータではないし、アルゴリズム介入で、確率的にもいんちきが多いので、あまり厳密なランダム性が問題になることは少ないだろう[43]

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

無印C言語には標準的乱数関数 rand()があるが、これを乱数発生に使うことに批判的な意見もあるし、機能もやや不足していると見れる。

Windows64bit では int rand(void) の出力は 32bit 整数だろう。まず stand関数で初期化してから rand()を呼ぶごとに疑似乱数が帰ってくる。これの複数回の連なりが乱数列だね。帰ってくる値は0 以上 定数RAND_MAX の値以下。

例えばさいころの数値が欲しいなら、rand の返り値を6で割った後、余りに1足せば、とりあえずそれらしいものはできる。

RAND_MAXは rand()の属性として定数が与えられているだけだから(Windowsで0x7FFF)、この値の変更はできない。

まあこれでもそこそこいい加減な乱数として機能するだろうが、最近ではもう少し改良された、質の高い乱数関数もある。

また、改良された乱数関数は、乱数の範囲も指定できるから何かと使い勝手が良いし、バグを防ぐ効果もあるのだろう。

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

↑例えば上述のコードは前編集者が示したものだが、これは .NETプログラミングですね。.NET のSystem::Randomクラスを使っている。.NETのクラスは普通、C#かVisual Basic で利用するので、Visual C++で使えるようにするには結構面倒な手管がいるが、その辺は読者諸兄、ヘルプやネット情報を参照して、適宜辿り付いてほしい。

C++ の場合はむしろ、 #include <random> を宣言してそこで使える関数を使用するほうが簡単でしょうね。この場合でも、乱数としての精度も高いし、帰り値の範囲指定もできる。

画像のちらつき編集

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

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

これは、ダブルバッファ(「裏画面」と、良く言われる)という技術で、解決を図る。

Direct Xの用語では「スワップ チェーン」と呼んでいる。

.NET Framework開発環境の C++や C#でもダブルバッファの機能があると解説されている。いくつかのGUIオブジェクトのプロパティで、ダブルバッファの設定項目がある。

しかし前編集者が実験したところ、この機能を有効に使って確認することはできなかったとの指摘がある。ひょっとしたら何らかのマイクロソフトの解説に間違いがあって、工夫次第では利用できるかもしれないが、少なくとも今現在のこのページでは、その問題に関するリファレンスは提供できない。

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

前編集者は、.NET Framework のフォームデザイナでは、ちらつき自体は解決できそうだが、グローバル変数の共有が困難だったり、アプリ内から終了コマンドが使えない、などの難点があると指摘している。

ただ現編集者はこの2点に関しては、解決策はあると思うが、しかし特に調査はしない。

前編集者は、.NETプログラムでゲームを作る難点をいくつも上げているが、おそらくどれも、.NET の仕様や全貌に精通すれば解決できるように思えるが、そもそもその全貌がかなり広大なので、解決の道のりは長いだろう。

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

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

数値(HPなどの各種パラメータ現在値)や文字列(例えば、プレイヤーの作成したキャラクターの名前)や現在地やフラグ状況などなど、セーブの機能は欲しい。一番簡単な方法は、C言語の fopen 関数のテキストファイル書き込み機能で、テキストファイルとしてセーブすることだろう。

Windows API には CreateFile関数 があるが、テキストファイルでの素朴なセーブは一番簡単で単純なセーブ法だろう。そしてテキストファイルを読み込んでプログラムに各種変数を配置して、ロードとする。

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

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

バイナリファイルでもデータとしてのファイルと、OS が機械語または何らかの仮想的な機械語として扱う実行ファイルがある。それらのバイナリは種類に応じて多くは冒頭にファイル識別子の情報があるだろうし、OS や アプリケーション側で工夫を凝らして、特定の条件を満たす場合しか動作しないようにしているだろう。そしてバイナリファイルを扱うときは、セキュリティの安全性も考慮するだろう。

基本的にプログラム側は何でもありだが、識別子の判別その他、ある程度様々な考慮をしないと、困った事態が起こり、プログラマーが責任を問われることも起こるかもしれない。

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

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

データ内容を秘匿したければ、バイナリ化だけではなく、暗号化も必要になるかもしれない。

機能の整備編集

セーブ&ロード機能の実装時には、まずセーブ機能から作るのがやりやすいという。

しかし最終的には関係関数の整備は、ロード機能が基盤となるだろう。

データや変数を、一定のスタイルでセーブして、一方で正しいスタイルでロードする、この機能が必要なわけですよね。

シリアライズされたデータを、型を決めたうえで配置しなければいけないから、ロードのプログラムの方が複雑に、面倒になる。

結局データのシリアライズは、ロード機能が基盤となり、その機能の作りやすさが、セーブ機能の作りやすさも支配するようだ。

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

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

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

スケジュール管理編集

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 目標

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

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

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

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

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

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

基本的にはチュートリアルの細部は後回しにしたい。と、いうのはゲーム本体の仕様変更が、製作過程で頻繁に起こるので、チュートリアルもそれに合わせて後回しにせざるを得ない。

最初の段階でチュートリアルを作りこんでも、仕様変更になれば、その記述自体が不適になる。

当初のチュートリアルイベントがそもそも必要かどうか。説明書、マニュアルに任せてもいいですよね。

基本的にゲーム本体の仕様がかなり変更を含み場当たり的なので、チュートリアルは後回し、早くともゲームα版の時期になるでしょう。

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

ゲーム制作の時は、自分が昔プレイして楽しかったゲームを思い浮かべるし、参考にもしますよね。

ただ、コンピューターゲームは明らかに、周辺技術が時間とともに、かなりの速度で発達、変遷していきますし、過去のゲームを参考にすると言っても、精神面、思想面での参考で、技術面ではやはり、最新の情報技術を取り入れたいと、誰もが思うでしょう。

前編集者は得意げに、古典技芸の世界では、『師を見るな、 師が見ているものを見よ』と、いう言葉があると宣っていますが、そもそもこの国のゲーム業界では、基本的に金と目先の安易な欲望と私欲しか顧みられないし、そこを支配する知性と教養は、善意や誠意や真理とはかけ離れた、歪んだ論理と無駄に衒学的な詳細しか持たないし、権力をもって威張っている連中は、善性や美などとはかけ離れた安易な偏向した物理主義的な議論に明け暮れている連中なので、師などと呼べる人物に出会うことさえ、至難な事でしょう。

スプライト編集

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

一画面中に表示できる限界は、だいたい、マリオが一画面中に数十人ぶんです。

このように、ビデオゲームで小さなキャラクタを、高速表示する仕組みを、「スプライト」と呼んでいました。マリオのキャラクター表示は小単位のスプライトを複数合成していたようです。

このキャラクター数の制限が、当時はゲームの設計にも大きな影響を及ぼしていたわけですね。

例えばシューティングゲームで、100体の敵機を表示することはできない。

しかしそれなりの工夫はあった。表示のタイミングを変えることで、なんとなく、多量のスプライトがあるように見せることはできた。

つまり、

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

して、切り替える、うまく、素早くとか?

上手にプログラムを作ればそこそこ上手くいったようですね。それでも、キャラクターが多いと、一瞬、消えたりしている。

ファミコン上における実際の技術限界の正確な数値は、別の資料を参照していただくとして、あまりあてにならない数字として例えば、横1列上には 8体目までしか表示できなかったようです。マリオは一人で2*2=チップ使っていた。だから横一列では 4体までしか表示できませんね。

例えばシューティングでは、敵機の他に、弾丸などもスプライトでしょう。

マリオが4チップなように、巨大ボスなんかチップ数をかなり使っているでしょうね。

そしてチップ数が多いから、速度が遅くなるのでしょうか、何か我々の昔のゲームをプレイした記憶では、巨大ボスの動きは緩慢でしたよね。

しかしやや脱線しますが、巨大なキャラクターは何となく動きが遅いという我々の固定観念がある一方で、レスラーやヘビー級ボクサーはかなり動きが速い。相手の体が大きい上動きが早ければ、もう勝てないね。座して死を待つしかないか^^;;;。

画面描き換えと背景編集

ファミコンのマリオの横スクロールでは、例えば地上ステージの空は、青一色で描き換えを行わない。低地の地面の障害物周辺だけを動かしていたようですね。動かす部分はプログラムでの描き換えが必要だし、動かない部分は背景として、描き換える必要がない。

書き換える必要のない背景表示は当然プログラムの負荷も少ないですよね。

ですから昔のレトロゲームの雰囲気や映像、仕様は、当時の技術の制限、影響を受けた上でその形態になっていたという事で、今は技術が発達したので、様々な斬新な映像表現や、演出を駆使できる。

一方で最新の技術を駆使したうえで、過去のレトロな雰囲気を再現、表現するという道もあるでしょうね。

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

昔のブラウン管テレビのドットは、にじみが大きい。これはテレビ画面の性質なので、ゲームでも映画でもバラエティでもドキュメンタリーでも、解像度画面としてのにじみは同じように大きい。今の液晶画面が完全ににじみがないかどうかは怪しいが、ブラウン管よりは少ない。

そのため、当時の画像データをそのまま現在のパソコンで表示しても、にじみによるアナログ感がなくなり、荒い画像に見える。当時のゲーム攻略本にあるような写真画像は、同じデータではあるのだが、現在では上手に再現できない。

解像度だけではなく色についても、にじみの色の重なりで、昔の映像の方が豊かな色に見え、現在では雰囲気の再現はうまくできない。

昔のゲームはアナログ技術だからこその、独特の雰囲気を表現していた。

ですから昔のゲームのレトロな雰囲気は、データとしての昔の仕様をそのまま使っても再現できず、むしろ昔の画像写真の資料を見ながら、現在の技術、現在の機材によってその雰囲気を再現することを目指すことになります。現在では様々な画像フィルターも作れますから、そういうものの利用も有効でしょう。あるいは過去のデータ、仕様をそのまま使うなら、それは新たな画像世界になるかもしれません。

過去の低解像度画像を使ったゲームは、レトロではなくむしろ新ジャンルだという指摘があります。

90年代のカラー携帯ゲーム機の画像データをそのまま使って現在の液晶画面に表示すると、当時のディスプレイは走査線が太いので、画面として縦横比が変わってしまう。縦横比を補正すると走査線部分の黒線や余白が入り、それをドットで埋めて補正すると、画面のギザギザが目立ってしまうようです。

つまりディスプレイの性質が90年代と2020年代とで違うので、レトロ画面の再現はかなり困難、最初から目指さない方がいいだろうという意見もあります。

パソコン市場では、1999年ごろからノートパソコンが普及し、液晶ディスプレイも安価で出回ってきた。そこでにじみの少ないくっきりした映像が主流になってきますね。

基本的にディスプレイはブラウン管→液晶と変わり、解像度は大きくなる一方です。

プレイステーション2あたりからは家庭用ディプレイの切り替えが起こり、もはやブラウン管でのプレイ自体がなくなる。 アナログ放送は2010年ぐらいまで続いたでしょうか。しかし家庭ではゲームをするにしても、普通に放送を見るにしても、DVDを見るにしても、ブラウン管から液晶や、プラズマというのもありました、画面の解像度自体も高くなっていく。

そして画像のドットはにじみの少ないくっきりしたものへ変わっていきます。最近はパソコン画面でも、TVでもドットの縦横は等しい正方形ですが、ブラウン管はそうではなかった。

だから、当時はドットで絵を描く時も、長方形ドットです。

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

昔は、というか実はいまでも、CGや画像の縦横比が正確ではない映像を見る事はありますよね。

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

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

論理的には25色だが、ブラウン管のドットの滲みやテレビのアナログな仕様から、結局はなかなか豊かな映像が当時も見れたと言っていいのではないだろうか。

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

ドット絵

ファミコンのギザギザのキャラクターの絵は、よく、ドット絵と言われますよね。

ただ、プレイステーション以降、ゲーム機が進化しても、コンピュータの画像はドットのラスターグラフィックだから、ドット単位で絵を描くことは多い。

特に小さい絵、キャラクターやアイコンはドット単位でデザインすることがあります。

しかし言葉の使い方では、ドット絵と言えば昔の、ファミコンキャラクター風のギザギザの解像度の低い絵を指すことが多いでしょう。

現在のドットエディタで絵を描く場合でも、解像度の低い絵が多いですね。ラスターグラフィックも結局ドット単位で解像度が高く、色数が多いだけですが、点密度が高い、アンチエイリアスを駆使した絵は、もはや、ドットというよりはアナログの手描きの絵と言いたくなる。

前編集者はこのドット絵という言葉にこだわって、なんかグダグダ理屈書いていたけど、現編集者にとって何がしたいのか、何を言いたいのかただただ謎ですね。

とにかくドット絵にレトロな意味を持たせても全然問題ないと思うけど…。

子供時代の思い出は大事だぜ^^。

1990年代後半に、岡田斗司夫氏の対談でこういうものがあったそうです。出典はおそらく『マジメな話』。

「アニメの黄金期っていつだろう?」

「70年代かな~。」

「いや、80年代だろう。」

「そうかな~。」

「むしろ…」

「むしろ?」

「…12歳だね^^」

12歳万歳!(^^)/


テレビとディスプレイの焼き付き編集

ゲームというのは色数も少ないし、静止画も多い。

ファミコン時代から、同じ色長時間の表示は、ディスプレイの焼き付きを起こすので、常にそれなりの工夫がされていたかもしれませんね。

静止画を避ける、時々背景を変える、背景色を光のエネルギーを持たない黒にするとか…

パソコンでは昔からその工夫がありましたね。スクリーンセイバーという機能もある。

とにかく一つのドットに同じ色が長時間表示されると…ちょっと危ない。

焼き付きの問題は昔も今もありますよ。昔のブラウン管は焼き付かないという主張が時々あるようですが、事実ではないでしょう。

現代のテレビ受像機には、焼きつき防止のために「ピクセルシフト」という機能がある。これは画面上の映像の表示位置をタイミングごとに微妙にずらす機能です。こういう機能がすでに搭載されているので、ゲームソフト側で焼き付き防止を必要以上に考慮しなくてもいいらしい。液晶モニターは、焼きつきが起きにくいという。ただし有機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. ^ https://ikedanobuo.livedoor.biz/archives/51292691.html 2007年02月23日22:03 2022年11月23日に確認.
  9. ^ 『ゲームプランとデザインの教科書』、P.107
  10. ^ 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.120
  11. ^ 『ゲームプランナーの新しい教科書』、P20
  12. ^ 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.121
  13. ^ 13.0 13.1 吉冨賢介『ゲームプランナー入門』、P244
  14. ^ 青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.267
  15. ^ 青島矢一ほか『メイド・イン・ジャパンは終わるのか』、東洋経済、2010年8月12日発行、P.283
  16. ^ 吉冨賢介『ゲームプランナー入門』、P245
  17. ^ 17.0 17.1 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.139
  18. ^ 『ゲーム作りの発想法と企画書のつくりかた』、P.235
  19. ^ 19.0 19.1 吉冨賢介『ゲームプランナー入門』、P17
  20. ^ 20.0 20.1 吉冨賢介『ゲームプランナー入門』、P18
  21. ^ 21.0 21.1 蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P56
  22. ^ 蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P54
  23. ^ 蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P55
  24. ^ STUDIO SHIN『ゲームプランナーの新しい教科書』、翔泳社、2018年3月10日初版第2刷、P251の図
  25. ^ 25.0 25.1 25.2 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.135
  26. ^ 26.0 26.1 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.134
  27. ^ https://game.watch.impress.co.jp/docs/news/1078888.html 2020年11月25日に閲覧して確認
  28. ^ 28.0 28.1 28.2 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.350
  29. ^ 川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P.38
  30. ^ 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.349
  31. ^ 『ゲーム作りの発想法と企画書のつくりかた』、P.140
  32. ^ 『ゲームデザイン プロフェッショナル』、P224
  33. ^ 『ゲームデザイン プロフェッショナル』、P170
  34. ^ 蛭田健司『ゲームクリエイターの仕事 イマドキのゲーム制作現場を大解剖』、翔泳社、2016年4月14日初版第1刷発行、P88
  35. ^ https://www.youtube.com/watch?v=J5FCZG7dfEY 2020年3月17日に閲覧
  36. ^ 『ゲームプランとデザインの教科書』、P152
  37. ^ 『ゲームプランとデザインの教科書』、P302
  38. ^ 吉冨賢介『ゲームプランナー入門』、P36
  39. ^ 39.0 39.1 川村元気『理系に学ぶ』、ダイヤモンド社、2016年4月21日第1刷発行、P.67
  40. ^ 40.0 40.1 『ゲームデザイン プロフェッショナル』、P199
  41. ^ 川上大典ほか『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.48
  42. ^ 『ゲームプランナー集中講座』、P232
  43. ^ 『ゲームプランナー集中講座』、P231
  44. ^ 44.0 44.1 44.2 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.65
  45. ^ [1]2020年12月1日に閲覧して確認.
  46. ^ 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.306
  47. ^ 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.184
  48. ^ 吉冨賢介『ゲームプランナー入門』、P17
  49. ^ 49.0 49.1 畑大典ほか著『ゲーム作りの発想法と企画書の作り方』、総合科学出版、2020年11月19日第1版第1刷発行、P166
  50. ^ 川上大典ほか著『ゲームプランとデザインの教科書』、秀和システム、2018年11月1日第1版第1刷、P.253
  51. ^ 51.0 51.1 [2] 2020年8月30日
  52. ^ ntny著『ローポリスーパーテクニック』、ソフトバンククリエイティブ、2010年2月16日初版第5刷、P28
  53. ^ 『ゲームプランナー入門』、P39
  54. ^ 『ゲームプランナー入門』、P54
  55. ^ [3] 2021年12月30日に確認.

関連項目編集