ゲーム製作日誌 プログラム編 No.2 「ゲームライブラリの概要」

1、ゲームライブラリって必要か?

 今回は、ゲームに共通なゲームライブラリの自作に手をつけましょう。
 ゲームライブラリとは、プレイヤーのキーボード・マウスの入力の確認や、画面への描画、音楽の再生を簡単にやってくれるプログラムのことです。
 前回紹介した、DirectXというAPIだけでも一応ゲームを作ってもいけるのですが、はっきりいって面倒くさいです。毎回同じような長いコードを書く必要が出てきます。
 たとえば、「文字を表示したい」とします。もしゲームライブラリがないと、文字を表示するだけでもたくさんのコードを書なくてはなりません。
 ゲームライブラリをつくったらどうでしょう、ただライブラリに「文字を表示しろ!」と一言命令するだけで後はそのとおりに実現してくれます。そんな便利なゲームライブラリを今から作ろうとしています。
no2-1


2、じゃあ何が必要?

 
ゲームライブラリを作り始める前に、どんな機能が必要か考えましょう。それは、便利な機能はいっぱいあったほうに越したことはありません。
 まずは、プレイヤのキーボード・マウス入力を感知する機能は必要です。それがないと、タイトル選択も次にいくこともできません。
 画面描画に関する機能ももちろん必要です。画像・文字表示は必要として、3Dモデルの描画機能もあったらゲームの幅も広がりそうです。(ちなみに、今回開発中のゲームでも3Dダンジョン使ったシーンを入れる予定です)
 また、音楽再生機能もあったほうがいいです。BGMがないとゲーム中さびしいし、SEがないとゲームで何が起こったかわかりにくくなります。

 以上をまとめて、下のような機能をゲームライブラリに組み込んでいくことにしましょう。

 □基本描画機能
  ・画像描画
   読み込んだ画像を画面に表示する機能です
  ・文字描画
   文字列を画面に表示する機能です
  ・テクスチャストッカ
   ファイルから読み込んだ画像を貯めておく機能で、同じファイルを二重に読み込むことを回避できます
  ・グリフストッカ
   一度表示した文字象形を貯めておく機能です

 □3D描画機能
  ・モデル描画
   3Dモデルを描画する機能です
  ・モデルストッカ
   ファイルから読み込んだモデルを貯めておく機能です
  ・スキニング
   3Dモデルの動き表現に必要な機能です
  ・IK
   3Dモデルの動きを作る際に便利な機能です
  ・衝突判定
   3D空間内で物が接触しているか判定する機能です

 □入力機能
  ・キーボード
   キーボードの入力を感知する機能
  ・マウス
   マウスの入力を感知する機能

 □サウンド機能
  ・Waveフォーマット再生
  ・OggVoribisフォーマット再生
   音楽の再生を担当する機能


 次回以降では、これらの機能の実装を始めていきます。上の内容の詳細な説明も、そのときにしていきます。
 

最果てロマノーヴァ

製作中のRPGのタイトルが決定しました。「最果てロマノーヴァ」です。
体験版の公開までもう少しという感じです。

今回はゲームのシステムについて少し詳しく説明をします。

このゲームは大きく分けて二つのパートにわかれています。
一つは拠点を起点にして様々な行動を行うADVパート、もう一つはダンジョンの探索及び戦闘を行う疾風怒濤パートです。

ADVパートでは、舞台となる街「デルベルバトン」の「ミュルスの店」を拠点として様々な場所(大通り、町外れ、国立図書館など)をうろついたり、発見したダンジョンの探索に向かったり、クエストの受注及び遂行ができます。
・うろつきを行った場合、発生したイベントと選んだ選択肢によってクエストが追加されたり、仲間が増えたりします。
・ダンジョンの探索に向かうにはダンジョンが発見済みであることと距離に応じた日数が必要です。
・クエストは繰り返し受注できる単純な(特定のアイテムを五個集めろなど)汎用クエストと、専用のマップ、ストーリー等が用意された独自クエストがあります。

疾風怒濤パートでは3Dマップを三人称視点で探索し、アイテムの入手、あるいはクエストのクリアを目指します。ランダムエンカウント方式を採用しています。
戦闘はオーソドックスなコマンド選択式ですが、攻撃の順番が武器の種類によってある程度固定できたりするので、戦略性が高い……かもしれません。アクティブ なターン制になっており、キャラクターのとった行動により次に行動するまでの時間が変わり(ディレイ)、またキャラクターの行動と行動の間には自由にアイ テムが使用できます。

両者に共通する点として、時間の経過が挙げられます。ADVパートでは基本的に一回うろつくごとに一日、疾風怒濤パートでは一度キャンプを張る(回復する)ごとに一日が経過します。ゲーム内の日数には制限があり、一定の日数が経過するとゲームは「一段落」します。


今回はこのあたりにしておきます。がんばってます。

ゲーム製作日誌 プログラム編 No.1 「はじめに」

 はじめまして、ゲーム制作でプログラミングを担当するさそうです。

 今回からゲーム制作日誌と称して、ゲームプログラミングについての記事を書いていきたいと思います。ゲームを作る際に必要だった知識や考えたことなど、自分自身が今回はじめてゲームプログラミングをして経験したことを元にまとめていきます。私は、プログラミングが趣味なだけの実力しかないため今後書く記事には間違いや遠回りな実装等問題点があるかもしれません。そこはあたたかい目で見守っていただき、あくまでゲーム制作の参考にしていただければ幸いです。

 長い前置きはさておき、さっそく第1記を始めていきます。

1、言語の選択

 ゲームのプログラミングをする際には、まずプログラムを記述するプログラミング言語を選択する必要があります。言語を選ぶ条件としていくつかあると思います。
  1. 画面への描画、音楽の再現、キーボード・マウスからの入力に対応できるか

  2. ある程度の実行スピードが確保できるか

  3. 自分にあっている言語か
 基本的にゲームはプレイヤーの入力を受け、それに対して画面表示や音楽で反応するプログラムです。それらができないとゲームとしての形も保てないため「1」の条件は満たすべきです。
 「2」の条件については、実現したい内容にもよると思います。しかし、コードが完成した後に言語の実行速度の遅さのためにカックカクのゲームになってしまった・・・、なんて事態は想像したくもありません。
 「3」の条件は主に自分自身のモチベーションにかかわります。ゲームが完成するまで付き合う言語は、自分と気が合うものを選びたいです。

 以上の条件は、私自身が言語を選んだときの主な理由でもあります。今回のゲーム制作では、C#を用いることに決めました。そのため以降の内容はC#を前提とした話に傾いていくかもしれません。(また前置きを仕掛けてしまった・・・)


2、必要なライブラリの決定

 「」でも若干ふれましたが、ゲームプログラムには「プレイヤーからの入力」と「それに対する反応」が必要です。具体的にいうと、キーボード・マウス・ゲームパッドからの入力感知、ディスプレイへの描画機能、音楽の再生機能のことです。これらの機能は、そのままのプログラミング言語側では通常利用できないのでライブラリを介して機能を利用する必要があります。
 そのライブラリには多くの種類がありますが、現在主に使われているらしいものの中で2通りに分けられます。
  • DirectX系
    Microsoft社が開発した描画・入力・音楽に一括に対応するAPI群をDirectXといいます。
    このDirectXの売りは、異常なまでに高速な描画速度とバージョン更新の速さだと思います。
    欠点としては、基本的にWindows上でしか利用することが挙げられます。
    主にゲーム開発に使われているそうでPCゲームの多くやXboxゲームでも利用されています。

    派生ライブラリ例:
    DXライブラリ、Managed DirectX(注)、SlimDX、SharpDX
  • OpenGL系
    もともとはSGI社が開発していたシステムを移植してできた描画APIのことです。
    このOpenGLのすごいところは、様々なOS上で動作することです。DirectXのような、Windowsだけというような制限はありません。
    もともと、ゲーム用途として開発されたわけではないので高速な描画よりも正確な描画を目指しているようです。
    C#でも利用することができ、派生ライブラリ例としては、数々のものがあります
no1-1


 今回のゲーム制作では、DirectX系の「SharpDX」を用いることにしました。
 DXライブラリ等のモデル、文字描画、音楽再生を全部やってくれるようなライブラリを使えば、プログラミングを楽になると思いますが今回はゲームプログラングの基本から学習したかったため、便利機能のほんとどない純粋なDirectXに近い「SharpDX」を選びました。
 以前、おなじく純粋でしかもMicrosoft社謹製の「Managed DirectX」を使ってみたことがありますが、作成中に不具合が多くあり「これじゃ使えないじゃないか!」ということで方向転換を余儀なくされました。このライブラリの開発は終了しており、修正される見込みもないので皆さんも使うのは控えたほうがいいかもしれません。
 また、「SlimDX」という「SharpDX」に非常に似たライブラリも存在するのですが、そちらはプログラムを実行するために必要な依存プログラムがいくつか必要で、また「SharpDX」のほうが高速だという噂があります。


3、まずは何から手を付けるか

 もう何度も書きましたが、基本的にゲームはプレイヤーの入力を受け、それに対して画面表示や音楽で反応するプログラムです。つまり、プログラムを3つの部門に分けることができます。
  1. プレイヤーの入力を受け取る部門

  2. 入力に対する反応を考える部門

  3. 反応を画面表示や音楽で再現する部門
 例えば、3D空間を自由に歩き回れるゲームを想像してみましょう。ゲームパッドのスティックを倒せばその方向にプレイヤーのモデルが動く様子が画面に表示されるます。これを、上の3つの部門の担当にそれぞれ仕事を割り振って動作を考えると次のようになります。

  • プログラムが、部門「1」にゲームパッドのスティックが倒されているか聞く
  • 倒されているとわかったら、プログラムは部門「2」に何が起こるのか考えさせる。(この場合はプレイヤーの移動が結果になる)
  • プログラムは、部門「2」が考えた結果(プレイヤーの移動)を部門「3」に依頼して再現させる
no1-2


 いろいろなゲームの場面を思い出してもこの3つの手順に当てはめることができるはずです。つまり、この3つ部門が完成してしまえば、ゲームは完成です。
 さらに気づくことは、部門「1」と部門「3」のやってくれることはゲームが変わっても変わらないということです。プレイヤーがキーボードやマウスを押しているか確認する方法はどんなゲームでも同じでよいし、音楽の再生の仕方もしかり、画面表示もモデル・文字・絵の描画と細かく分ければ基本的にすることは変わりません。
 この部門「1」と部門「3」はどんなゲームでも変わらないということは、一度作ってしまえば他のゲームにも再利用できるということです。

 そこで、ゲーム制作の手始めとして、「入力を調べる機能」「画面に描画する機能」「音楽を再生する機能」を作ることにしましょう。
 次回からはそれら機能の実装を目指していきます。

4、まとめ

 今回の内容をまとめてみました。
  • ゲームプログラミングと自分にあった言語を選ぶ

  • 言語単体では、入力・描画・音楽を扱えないためライブラリを見つける

  • 入力・描画・音楽に関するプログラムの内容は全てのゲームで共通なため、一度作れば2つめ3つめを作るときに楽になる

 今回の内容は、「ゲームを作る」というよりもどちらかというと考えることしかしてなかったため、抽象的な記事で楽しくない記事になってしましました。次回以降は、もっとゲームを作ってることが実感できるような記事になるといいなと思います。

 とにかくがんばります。

twitterはこちら
ニコ生放送します
ギャラリー
  • ウマモサク
  • ウマモサク
  • ウマモサク
  • 3/17 制作記録
  • 3/17 制作記録
  • C91告知
  • C91告知
  • C91告知
  • C91告知
アクセスカウンター
  • 今日:
  • 昨日:
  • 累計:

  • ライブドアブログ