昔のゲームの想い出 [0035] 「Mr.Do！」 [ユニバーサル] [1982] [アーケード]
《ほとばしるダイヤの緊張感！》
Mr.Do！は自機であるピエロを操作して、画面上の地形を掘り進みながら、画面上にあるサクランボを全て取得する等してステージクリアを行う面クリア型のアクションゲームとなります。
このゲームの基本システムはディグダグに類似されているので(穴を掘る、岩(リンゴ)で敵を潰すというディグダグの2大フィーチャーを踏襲していたお陰で)、当時は周りでも「ディグダクの真似したゲーム」と言わていました。
私的には、どちらも20ステージは進めている位やりこんでいたので、このゲームが「ただのディグダグの真似」だけではないことがよく分るのですが、少しプレーしただけの人から見ると、ただのパクリとしか思えなくて当然かな…とも思います。
Mr.Do！は自機であるピエロを操作して、画面上の地形を掘り進みながら、画面上にあるサクランボを全て取得する等してステージクリアを行う面クリア型のアクションゲームとなります。
このゲームの基本システムはディグダグに類似されているので(穴を掘る、岩(リンゴ)で敵を潰すというディグダグの2大フィーチャーを踏襲していたお陰で)、当時は周りでも「ディグダクの真似したゲーム」と言わていました。
私的には、どちらも20ステージは進めている位やりこんでいたので、このゲームが「ただのディグダグの真似」だけではないことがよく分るのですが、少しプレーしただけの人から見ると、ただのパクリとしか思えなくて当然かな…とも思います。
XNAにおける3Dゲーム描画設計 (Visual C#+XNAプロジェクトにスプライト用ビットマップファイルを登録する)
3/23に引き続き、Texture2Dクラスにスプライト情報となるビットマップファイルを登録する手順を説明します。
XNAにおいて、スプライトとなるビットマップファイルはWindowsでは一般的な「.BMP／.JPG／.PNG」等が読み込むことができ、これらを登録することになります。
(他にも、Direct Drawなどでお馴染の.DDSや昔から存在する.TGAなどもあります)
このビットマップファイルの登録はモデルファイル同様、ソリューションエクスプローラーにアセットとして登録することができます。
サンプルソースでは"Sprite"というフォルダを作成し、この下にエネルギーメーターのビットマップ"EnergyGage.png"をアセット"EnergyGage"として登録しています。
[エネルギーメータのビットマップ]
[ソリューションエクスプローラーに登録]
スプライトのビットマップにおける留意点としては「マゼンダ色(R:255,G:0,B:255)が透過属性」として認識されます。これにより、スプライトの抜きの部分を実現することが可能となります(逆に言えば、マゼンダ色は使用できないということになります)。
これはXNAのデフォルトコンテンツライブラリの仕様のようです。(Windows上はWindows 3.1のVideo for Windows時代からクロマキー=マゼンダみたいな文化がありますね)
このため、JPEGのようなカラー情報が曖昧になるファイルフォーマットは抜きの処理を行うのは向いていないことになるので注意が必要となります。
このようにアセット名を登録することにより、Texture2Dクラスがこの名前でアクセスできるようになります。
アセット名を用いてのビットマップの読み込みはモデル同様、至極簡単で、
Texture2D = ContentManager.Load("アセット名");
というだけでTexture2Dにビットマップ情報が設定できます。
サンプルソースでは上述のコードをモデル情報の読み込みの時同様に、SpriteToolというクラスを作成しています。
XNAにおいて、スプライトとなるビットマップファイルはWindowsでは一般的な「.BMP／.JPG／.PNG」等が読み込むことができ、これらを登録することになります。
(他にも、Direct Drawなどでお馴染の.DDSや昔から存在する.TGAなどもあります)
このビットマップファイルの登録はモデルファイル同様、ソリューションエクスプローラーにアセットとして登録することができます。
サンプルソースでは"Sprite"というフォルダを作成し、この下にエネルギーメーターのビットマップ"EnergyGage.png"をアセット"EnergyGage"として登録しています。
[エネルギーメータのビットマップ]
[ソリューションエクスプローラーに登録]
スプライトのビットマップにおける留意点としては「マゼンダ色(R:255,G:0,B:255)が透過属性」として認識されます。これにより、スプライトの抜きの部分を実現することが可能となります(逆に言えば、マゼンダ色は使用できないということになります)。
これはXNAのデフォルトコンテンツライブラリの仕様のようです。(Windows上はWindows 3.1のVideo for Windows時代からクロマキー=マゼンダみたいな文化がありますね)
このため、JPEGのようなカラー情報が曖昧になるファイルフォーマットは抜きの処理を行うのは向いていないことになるので注意が必要となります。
このようにアセット名を登録することにより、Texture2Dクラスがこの名前でアクセスできるようになります。
アセット名を用いてのビットマップの読み込みはモデル同様、至極簡単で、
Texture2D = ContentManager.Load
というだけでTexture2Dにビットマップ情報が設定できます。
サンプルソースでは上述のコードをモデル情報の読み込みの時同様に、SpriteToolというクラスを作成しています。
Sample Action Gameの紹介 [ステージ1-2 (その2)]
今回は前回の続きとなるステージ1-2の紹介です。後半戦はこのゲーム上でかなり難易度の高いボス戦の紹介となります。
それではウォークスルーしていきたいと思います。
【地面の下】
ステージ1のスタート地点だった場所の下は空洞になっていました。
【宝箱出現方法の確認】
そういえば宝箱の出現方法を確認していませんでした。
なるほど、レッドドラゴンか…
【マグマの洞窟】
洞窟の奥に進むとポーションが置いてあります。このポーションはライフ枠が5つ分のライフが回復できるので、いままでのダメージをここで回復できます。
【マグマを通り抜ける…】
マグマの中を通り抜けます。
プログラム的にはソフトウェアで手前の背景の各セルを動的に変更しているのでアニメーションが行えるようになっています。
ファミリーコンピュータのハードウェアをソフトウェアで実現しているような感じです。
【レッドドラゴン戦】
「Sample Action Gameのバナー」
にもなっているレッドドラゴンとの対決です。(バナーでは自機の装備が違っていますが(^^ゞ)
レッドドラゴンは口から3種類のウィル・オ・ウィスプを吐きだし、且つしゃがんで足元から盾で防げないファイアボールを飛してきます。
足元の攻撃をジャンプで避けつつ、画面内を跳ねまわるウィル・オ・ウィスプの軌跡を読んでドラゴンを攻撃することになります。
このボスは本ゲーム中一番バランスの悪いボスとなっていて(ちょっと一般的な調整に失敗しています(^^;)、人によりかなり難しいと感じるボス戦となるでしょう。
攻略としては、
１．ライフを削りながら攻撃にのみ専念する。(ゴリ押し戦法)
２．ドラゴンの吐き出すウィル・オ・ウィスプを動きの遅いもののみを
残すように倒してから(ドラゴンの吐き出す数の限界が決まっています)、
ジックリと倒す。
この間、足元の攻撃は真上にジャンプで避けます。そしてその際、
真上にウィル・オ・ウィスプがいない所というのもポイントになります。
(正当攻略)
といったものが挙げられます。
ちなみに、ここで死んでも開始地点は城の上からではなく、洞窟の入口からとなります。
開始マップの位置もこのように…
洞窟から開始となります。
【レッドドラゴンを倒す】
レッドドラゴンを倒した直後に、地面から炎が吹き出すので、安全地帯を速攻で見付け出します。
【クリア洞窟】
レッドドラゴンを倒すと、洞窟が開きます。
しかし、ここの宝箱の出現方法が討伐だったので、どこかに宝があるハズです…
【来た道を戻る】
レッドドラゴンはマグマの管理を司っていたみたいで、マグマが引いています。
演出を少し凝ってみました。(^^)
【入口】
入口に浮遊する床が出て、地上に上がれるようになっています。
【宝箱】
今迄通っていたマグマの下に宝箱が！
宝箱の中には剣が入っています。効果は剣の攻撃力アップとなります。
これは一部の敵に有効になり、その効果は「10倍」となっています。(スゲー！ｗ)
それほど有効でない敵にもそれなりの攻撃力となっています。
【洞窟を抜けてクリア】
再び洞窟に戻り、レッドドラゴンを倒した洞窟を抜けます。
前回同様繰り返しますが、「ステージ1の出口も進めますが、本ゲームを楽しむならそこへは入ってはいけません。」
ここが正規ルートとなります。
【おまけ】
！？
◇ ◇ ◇
ここのボス戦は人により、非常に苦労すると思います。(某巨大掲示板でも不評な評価を頂いたことがあります)
正直将来調整しようか迷ったのですが、作者はドラゴンはそれなりに強くないといけないというイメージあったので、とりあえずこれ位の難易度でバランス調整を止めました。
何か良いボス戦等がありましたら受けつけますので、コメントでもしていただけると幸いです。m(_ _)m
(すぐに反映できるかはその時次第…といった感じではありますが…)
それではウォークスルーしていきたいと思います。
【地面の下】
ステージ1のスタート地点だった場所の下は空洞になっていました。
【宝箱出現方法の確認】
そういえば宝箱の出現方法を確認していませんでした。
なるほど、レッドドラゴンか…
【マグマの洞窟】
洞窟の奥に進むとポーションが置いてあります。このポーションはライフ枠が5つ分のライフが回復できるので、いままでのダメージをここで回復できます。
【マグマを通り抜ける…】
マグマの中を通り抜けます。
プログラム的にはソフトウェアで手前の背景の各セルを動的に変更しているのでアニメーションが行えるようになっています。
ファミリーコンピュータのハードウェアをソフトウェアで実現しているような感じです。
【レッドドラゴン戦】
「Sample Action Gameのバナー」
にもなっているレッドドラゴンとの対決です。(バナーでは自機の装備が違っていますが(^^ゞ)
レッドドラゴンは口から3種類のウィル・オ・ウィスプを吐きだし、且つしゃがんで足元から盾で防げないファイアボールを飛してきます。
足元の攻撃をジャンプで避けつつ、画面内を跳ねまわるウィル・オ・ウィスプの軌跡を読んでドラゴンを攻撃することになります。
このボスは本ゲーム中一番バランスの悪いボスとなっていて(ちょっと一般的な調整に失敗しています(^^;)、人によりかなり難しいと感じるボス戦となるでしょう。
攻略としては、
１．ライフを削りながら攻撃にのみ専念する。(ゴリ押し戦法)
２．ドラゴンの吐き出すウィル・オ・ウィスプを動きの遅いもののみを
残すように倒してから(ドラゴンの吐き出す数の限界が決まっています)、
ジックリと倒す。
この間、足元の攻撃は真上にジャンプで避けます。そしてその際、
真上にウィル・オ・ウィスプがいない所というのもポイントになります。
(正当攻略)
といったものが挙げられます。
ちなみに、ここで死んでも開始地点は城の上からではなく、洞窟の入口からとなります。
開始マップの位置もこのように…
洞窟から開始となります。
【レッドドラゴンを倒す】
レッドドラゴンを倒した直後に、地面から炎が吹き出すので、安全地帯を速攻で見付け出します。
【クリア洞窟】
レッドドラゴンを倒すと、洞窟が開きます。
しかし、ここの宝箱の出現方法が討伐だったので、どこかに宝があるハズです…
【来た道を戻る】
レッドドラゴンはマグマの管理を司っていたみたいで、マグマが引いています。
演出を少し凝ってみました。(^^)
【入口】
入口に浮遊する床が出て、地上に上がれるようになっています。
【宝箱】
今迄通っていたマグマの下に宝箱が！
宝箱の中には剣が入っています。効果は剣の攻撃力アップとなります。
これは一部の敵に有効になり、その効果は「10倍」となっています。(スゲー！ｗ)
それほど有効でない敵にもそれなりの攻撃力となっています。
【洞窟を抜けてクリア】
再び洞窟に戻り、レッドドラゴンを倒した洞窟を抜けます。
前回同様繰り返しますが、「ステージ1の出口も進めますが、本ゲームを楽しむならそこへは入ってはいけません。」
ここが正規ルートとなります。
【おまけ】
 |  |
！？
◇ ◇ ◇
ここのボス戦は人により、非常に苦労すると思います。(某巨大掲示板でも不評な評価を頂いたことがあります)
正直将来調整しようか迷ったのですが、作者はドラゴンはそれなりに強くないといけないというイメージあったので、とりあえずこれ位の難易度でバランス調整を止めました。
何か良いボス戦等がありましたら受けつけますので、コメントでもしていただけると幸いです。m(_ _)m
(すぐに反映できるかはその時次第…といった感じではありますが…)
昔のゲームの想い出 [0034] 「ザ・ブラックオニキス」 [BPS] [1984] [PC-8801]
《クラーケンがコワイっ！》
先日友人と「会社がメンタルヘルスケア専門医と契約して～」というような会話が出て、「精神病→ウツロになる→ウツロの街→ブラックオニキス」という連想ゲームのような流れで、このゲームの会話になりました(笑)
ザ・ブラックオニキスは、様々なPCプラットフォームでリリースされたRPGゲームで、最大5人のパーティを組みながら3Dダンジョンを移動するゲームとなります。
雰囲気やRPGの仕様は先発のウィザードリィに近いですが、全体的に色使いが青系で明るく、かつパーティが画面に表示されている等、非常にビジュアルに富んだ画面構成となっています。
私はこのゲームを近所の幼馴染宅のFM-7で見せてもらい、このゲームを知ることができました。当時の私はゲームセンターのゲームをメインでプレーしていたので、この手の「じっくり腰を据えてやるゲーム」の多大な設定にもの凄く敷居の高さを感じながら見ていました。
このゲームはかなり自由にダンジョンの移動ができ、且つパーティのメンバーを入れ変えることができる(またダンジョン内で出会った他のパーティも仲間にできます)ので、やりこみ要素が高く、友人は色々なパーティを作っていました。
そこで私も友人からセーブデータを作ってもらい、彼が習い事に行っている間にプレーさせてもらう…というスタイルでプレーさせてもらい、よく分らないまま街をウロつき、このゲームの有名な名所である「枯れ井戸」を見つけ、レベルが低いまま降りて行きました…
ここでは移動中敵に遭遇しないのか、どんどん降りれるので「なんだ？どんどん行けるなぁ～」と思っていたら、突然「クラーケン(緑のタコ)」が出現しました。
「おぉ！なんだコイツは！」と思いながらも戦闘をしたところ、「パーティが一瞬で全滅」させられて、あっけに取られていると丁度友人が帰宅してきて、「あー、コイツは当分戦っちゃダメだよ。」と言われ、「えぇぇ！」となった想い出があります。
そんな友人も結構レベルが高いのに、クラーケンに倒されていたのを目の当たりにし、私の中では「ブラックオニキス→クラーケン→最強の代名詞」のような連想が常にされるようになりました。
◇ ◇ ◇
この後に来るファミリーコンピュータ時代のお行儀の良いRPGでは、最初から(Lv.1から)、かなりの強敵(例えばドラゴンクエストでいう「あくまのきし」クラス)に会えるというシーケンスはなかなか無いですが、このゲームのようにいきなり後半で倒す予定となる強敵に出会えるのはなかなか良いフィーチャーと思います。
まずは、簡単に殺されて「いつか、倒してやるからなっ！」みたいな、ある意味「伏線を張っている」訳ですが、ちゃんと殺されるというリスクがあるのが、ストイックでいいかもしれません。
先日友人と「会社がメンタルヘルスケア専門医と契約して～」というような会話が出て、「精神病→ウツロになる→ウツロの街→ブラックオニキス」という連想ゲームのような流れで、このゲームの会話になりました(笑)
ザ・ブラックオニキスは、様々なPCプラットフォームでリリースされたRPGゲームで、最大5人のパーティを組みながら3Dダンジョンを移動するゲームとなります。
雰囲気やRPGの仕様は先発のウィザードリィに近いですが、全体的に色使いが青系で明るく、かつパーティが画面に表示されている等、非常にビジュアルに富んだ画面構成となっています。
私はこのゲームを近所の幼馴染宅のFM-7で見せてもらい、このゲームを知ることができました。当時の私はゲームセンターのゲームをメインでプレーしていたので、この手の「じっくり腰を据えてやるゲーム」の多大な設定にもの凄く敷居の高さを感じながら見ていました。
このゲームはかなり自由にダンジョンの移動ができ、且つパーティのメンバーを入れ変えることができる(またダンジョン内で出会った他のパーティも仲間にできます)ので、やりこみ要素が高く、友人は色々なパーティを作っていました。
そこで私も友人からセーブデータを作ってもらい、彼が習い事に行っている間にプレーさせてもらう…というスタイルでプレーさせてもらい、よく分らないまま街をウロつき、このゲームの有名な名所である「枯れ井戸」を見つけ、レベルが低いまま降りて行きました…
ここでは移動中敵に遭遇しないのか、どんどん降りれるので「なんだ？どんどん行けるなぁ～」と思っていたら、突然「クラーケン(緑のタコ)」が出現しました。
「おぉ！なんだコイツは！」と思いながらも戦闘をしたところ、「パーティが一瞬で全滅」させられて、あっけに取られていると丁度友人が帰宅してきて、「あー、コイツは当分戦っちゃダメだよ。」と言われ、「えぇぇ！」となった想い出があります。
そんな友人も結構レベルが高いのに、クラーケンに倒されていたのを目の当たりにし、私の中では「ブラックオニキス→クラーケン→最強の代名詞」のような連想が常にされるようになりました。
◇ ◇ ◇
この後に来るファミリーコンピュータ時代のお行儀の良いRPGでは、最初から(Lv.1から)、かなりの強敵(例えばドラゴンクエストでいう「あくまのきし」クラス)に会えるというシーケンスはなかなか無いですが、このゲームのようにいきなり後半で倒す予定となる強敵に出会えるのはなかなか良いフィーチャーと思います。
まずは、簡単に殺されて「いつか、倒してやるからなっ！」みたいな、ある意味「伏線を張っている」訳ですが、ちゃんと殺されるというリスクがあるのが、ストイックでいいかもしれません。
背景の情報管理について (モデルから座標情報の取得について)
※これは2007/4月の頃のお話です。
XNAで3Dのアクションゲームを作成するにあたり、背景のモデリングとその背景の座標情報をどのように設計するか検討しました。
基本的にキャラクターも背景も3Dのモデリングで作成する訳なので、ツールはMetasequoiaを使用しようと考えた訳なのですが、「背景の座標情報をどのようにして取得するのだろう？」と考えたところ、以下のアプローチが思い浮びました。
【モデルクラスの中を覗いて取得する】
まず普通に考えれば、XNAでモデルファイル(Xファイル)の情報が読み込め、これがModelクラスに格納され、これをforeachでメッシュ単位で描画まで行えているのだから、ここに座標情報が無いのはおかしいと思い、C#のコンパイラのメンバ表示で中をどんどん掘り下げていったところ、おおまかな階層でいうと、
Model.Meshes[配列].ModelMesh.VertexBuffer.GetData
というメソッドがあったので(ちなみにこれはジェネリクスで型定義がされていました)、「よし、これだっ！」という感じでDirect3Dで定義されているような型をXNA上で探し、これをジェネリクスタイプとして定義して呼び出したところ、エクセプションが走りました…(^^;
「あれれ？ "GetData"なのになんでだろ？ 型が不正なのかな？」と思い、エクセプションの内容を見ると「WriteOnly」…
「えぇ～？ 型が不正というよりも、"GetData"なのに"書き込み専用"って、何？？？」みたいな状況となりました。
とりあえず、モデルの頂点情報が取得できないのであれば、背景のヒット判定ができないので、次の手法を検討しました。
【コンテントパイプラインを実装して取得する】
上述の方法がシンプルとは思いましたが、よく分りませんがメソッドがWriteOnlyですし、当初のXNAアーキテクチャーではこの方法がセオリーっぽく感じたので、これを実装することに…
とりあえず新しいプロジェクトとして、背景用のコンテントパイプラインを作成して、現在のソリューションに追加しました。
…と簡単に言いましたが、コンテントパイプラインの実装には本当に骨が折れました。
まずなにより「情報が殆んどない！」という流れから始まり、全世界をネットでかけずり周りながら、以下の順番で障壁にブツかりまくりました。
(『趣味』にしてはかなりキツイ作業としかいいようがない位…)
１．エントリポイントの作り方
とりあえずプロジェクト名を"BGContent"とした、クラスライブラリとしてプロジェクトを作成し、現在のソリューションに加えました。
そして、ModelProcessorクラスから派生させたBackgroundModelProcessorというクラスを実装し始めました。
このクラスにエントリポイント(正確にはコールバック)となるProcessというメソッドをオーバーライドして、そのメソッドの最初に基底クラスのメソッドを呼び出してみて、既存のモデルがコンテントパイプラインとして機能するか実験してみました。
とりあえずまずは成功したっぽかったので、これを登録した背景となるモデルのプロパティの"Content Processor"に登録してみて、この背景のモデルが読み込まれるか実験してみました。
ちゃんとコンテントプロセッサができなければXファイルのコンパイルの時点でエラーとなります。(なりました(^^;)
ここでポイントなのは戻り値が普段扱わないModelContentクラスというのも驚きました。「なんだこのクラス、見たことない！」と、まるでレアアイテムのようなノリで調べても、ネットにも情報がない…という始末でした。
２．頂点情報の取得 …その前に
ModelContentというクラスが取得できたので、この中を例の如くコンパイラのメンバ表示で覗いてみると、MeshesやらBonesやらとお宝情報が見えてきたので、なんとかしてコイツの情報を取得したいと情報を求めてネット上でアメリカ辺りをウロついていたら、この情報を取得する方法について説明があるのを発見しました。
これを読むと「ん？ ContentTypeReader、ContentTypeWriterが必要…？」、よくよく考えると、コンテントパイプラインというのはモデル等のコンテンツ情報を読んで、Windowsや、Xbox 360のプラットフォームに合せて変換して出力する…という流れのためのものなので、リーダーやライターがあって当然…
ということで、これの実装を試みました。
とりあえず現状はWindowsのみで進める予定なので、エンディアンとか気にしないで、そのまま頂点、頂点インデックス、テクスチャーファイル名の情報を入出力することにしました。
この入出力の実装により、コンパイル時にコンテンツのコンパイル(変換)が行われ、実行ファイルと共に変換されたコンテンツが出力される寸法です。(多分…)
…が、しかし…
３．モデル情報を格納する型を決める
ここで情報のI/Oのために自前でフォーマットを用意するようで、頂点情報のバッファ、頂点インデックスバッファ、テクスチャーファイル名のバッファ(これは将来属性でもいいかな…と)を内包したクラスを作成し、これをReader, Writerのジェネリクスタイプにすることにしました。
また、Writerでは、このデータ型とReaderをランタイムタイプとして定義する必要があるようで、これをオーバーライドしました。
４．頂点情報の取得
これで、エントリポイントからようやく情報が取れるようになりました。
Processメソッドで基底メソッドをコールして情報を読み込み、ModelContentクラスを引数としたメソッドを作成し、この内容から頂点情報、インデックス情報、テクスチャー情報を取得して、自前のデータフォーマットであるModelVertexDataクラスに情報を設定できるようにしました。
５．モデルに格納
自前のフォーマットにデータを保存できたまでは良いのですが、この情報をどこに格納すればいいのだろう？とModelクラスを見ていたら、Tagというメンバ(object型)に任意のデータを設定できるみたいだったので、これを設定しました。
これにより、ContentManager.LoadにてModelクラスが取得でき、この中のTagにコンテントパイプラインで読みこんだ自前フォーマットが取得できるようになりました。
◇ ◇ ◇
とまぁ、モデルの頂点情報を取得するまでにかなりの四苦八苦を行いましたが、とりあえず背景のモデルの頂点が取得できたので、背景としての存在を設計できるようになりました。
XNA上でのここまでの作業を行う事と、C++でDirect3Dを用いて自前でシンプルに情報を取得する…という比較は価値観の違いで行えませんが、この時点で一般のアマグラマーの人にXNAを流行らせるにはかなりの苦労が必要なのかなぁ～という所感がありました。
(背景ヒットの無いシンプルなゲーム制作か、自然とオープンなライブラリが充実してくれば話は別ですが…)
また、後で分ったのですが、この読み込みはキャッシュされる(or 読み込みは一度だけ)の模様で、ContentManager.Loadされた後に取得できるModelクラスのTagをnull化してしまうと、二度目以降のロードではTagに情報が読み込まれないみたいです。(本ブログの時点の「XNA Game Studio Express 1.0 Refresh」でのお話です)
◇ ◇ ◇
【おわりに】
文頭に「※これは2007/4月の頃のお話です。」という注釈をしましたが、この後にXNAのバージョンが上り、VertexBuffer.GetDataメソッドがWriteOnlyではなくなりました。
しかし、コンテントパイプラインの勉強という意味では良かったので、モデル情報の細かいハンドリングもできそうですし、コレはコレで使って行こうと思いました。
ただし、モデルの中にも頂点情報があるのに、更に自前のフォーマットでその複製があるのがかなり痛いです…
将来はこの辺りをどうするかを検討していかなければなりせん(何年後になるのか、それともこのプログラミングが途中で終了するのか…)
そして、本来は「ゲームプログラミング [XNA]」のカテゴリに載せるべき内容ではありますが、正直キチンと説明できるレベルではなかったので、開発日記としたレベルで、このカテゴリーに書くことにしました。
XNAで3Dのアクションゲームを作成するにあたり、背景のモデリングとその背景の座標情報をどのように設計するか検討しました。
基本的にキャラクターも背景も3Dのモデリングで作成する訳なので、ツールはMetasequoiaを使用しようと考えた訳なのですが、「背景の座標情報をどのようにして取得するのだろう？」と考えたところ、以下のアプローチが思い浮びました。
【モデルクラスの中を覗いて取得する】
まず普通に考えれば、XNAでモデルファイル(Xファイル)の情報が読み込め、これがModelクラスに格納され、これをforeachでメッシュ単位で描画まで行えているのだから、ここに座標情報が無いのはおかしいと思い、C#のコンパイラのメンバ表示で中をどんどん掘り下げていったところ、おおまかな階層でいうと、
Model.Meshes[配列].ModelMesh.VertexBuffer.GetData
というメソッドがあったので(ちなみにこれはジェネリクスで型定義がされていました)、「よし、これだっ！」という感じでDirect3Dで定義されているような型をXNA上で探し、これをジェネリクスタイプとして定義して呼び出したところ、エクセプションが走りました…(^^;
「あれれ？ "GetData"なのになんでだろ？ 型が不正なのかな？」と思い、エクセプションの内容を見ると「WriteOnly」…
「えぇ～？ 型が不正というよりも、"GetData"なのに"書き込み専用"って、何？？？」みたいな状況となりました。
とりあえず、モデルの頂点情報が取得できないのであれば、背景のヒット判定ができないので、次の手法を検討しました。
【コンテントパイプラインを実装して取得する】
上述の方法がシンプルとは思いましたが、よく分りませんがメソッドがWriteOnlyですし、当初のXNAアーキテクチャーではこの方法がセオリーっぽく感じたので、これを実装することに…
とりあえず新しいプロジェクトとして、背景用のコンテントパイプラインを作成して、現在のソリューションに追加しました。
…と簡単に言いましたが、コンテントパイプラインの実装には本当に骨が折れました。
まずなにより「情報が殆んどない！」という流れから始まり、全世界をネットでかけずり周りながら、以下の順番で障壁にブツかりまくりました。
(『趣味』にしてはかなりキツイ作業としかいいようがない位…)
１．エントリポイントの作り方
とりあえずプロジェクト名を"BGContent"とした、クラスライブラリとしてプロジェクトを作成し、現在のソリューションに加えました。
そして、ModelProcessorクラスから派生させたBackgroundModelProcessorというクラスを実装し始めました。
このクラスにエントリポイント(正確にはコールバック)となるProcessというメソッドをオーバーライドして、そのメソッドの最初に基底クラスのメソッドを呼び出してみて、既存のモデルがコンテントパイプラインとして機能するか実験してみました。
| /// <summary>背景のモデル情報をスキャン用コンテントパイプライン</summary> [ContentProcessor(DisplayName = "Backgroung Processor")] public class BackgroundModelProcessor : ModelProcessor { /// <summary>コンテントパイプライン処理を行います</summary> /// <param name="input">ノード情報</param> /// <param name="context">プロセスコンテキスト</param> /// <returns>読み込みが完了してモデル</returns> public override ModelContent Process( NodeContent input, ContentProcessorContext context) { // 既存の仕組みでモデルを読み込みます ModelContent model = base.Process(input, context); // ここに情報読みこみメソッドを実装 return model; } } |
とりあえずまずは成功したっぽかったので、これを登録した背景となるモデルのプロパティの"Content Processor"に登録してみて、この背景のモデルが読み込まれるか実験してみました。
ちゃんとコンテントプロセッサができなければXファイルのコンパイルの時点でエラーとなります。(なりました(^^;)
ここでポイントなのは戻り値が普段扱わないModelContentクラスというのも驚きました。「なんだこのクラス、見たことない！」と、まるでレアアイテムのようなノリで調べても、ネットにも情報がない…という始末でした。
２．頂点情報の取得 …その前に
ModelContentというクラスが取得できたので、この中を例の如くコンパイラのメンバ表示で覗いてみると、MeshesやらBonesやらとお宝情報が見えてきたので、なんとかしてコイツの情報を取得したいと情報を求めてネット上でアメリカ辺りをウロついていたら、この情報を取得する方法について説明があるのを発見しました。
これを読むと「ん？ ContentTypeReader、ContentTypeWriterが必要…？」、よくよく考えると、コンテントパイプラインというのはモデル等のコンテンツ情報を読んで、Windowsや、Xbox 360のプラットフォームに合せて変換して出力する…という流れのためのものなので、リーダーやライターがあって当然…
ということで、これの実装を試みました。
とりあえず現状はWindowsのみで進める予定なので、エンディアンとか気にしないで、そのまま頂点、頂点インデックス、テクスチャーファイル名の情報を入出力することにしました。
この入出力の実装により、コンパイル時にコンテンツのコンパイル(変換)が行われ、実行ファイルと共に変換されたコンテンツが出力される寸法です。(多分…)
…が、しかし…
３．モデル情報を格納する型を決める
ここで情報のI/Oのために自前でフォーマットを用意するようで、頂点情報のバッファ、頂点インデックスバッファ、テクスチャーファイル名のバッファ(これは将来属性でもいいかな…と)を内包したクラスを作成し、これをReader, Writerのジェネリクスタイプにすることにしました。
また、Writerでは、このデータ型とReaderをランタイムタイプとして定義する必要があるようで、これをオーバーライドしました。
| /// <summary>頂点情報保持クラス</summary> public class ModelVertexData { // テクスチャ及び頂点情報 public VertexPositionNormalTexture[] m_Vertices; // インデックスバッファ情報 public int[] m_IndexBuffer; // テクスチャファイル名 public string[] m_TextureNames; /// <summary>コンストラクタ</summary> /// <param name="Vertices">頂点情報</param> /// <param name="IndexBuffer">インデックスバッファ</param> /// <param name="textureNames">ファイル名集合(3頂点数と同じ)</param> public ModelVertexData( VertexPositionNormalTexture[] Vertices, int[] IndexBuffer, string[] textureNames) { m_Vertices = Vertices; m_IndexBuffer = IndexBuffer; m_TextureNames = textureNames; } /// <summary>頂点を取得します</summary> /// <param name="index">取得する頂点インデックス</param> /// <param name="Vertics">取得する 3 頂点</param> public void GetVector( int index, ref VertexPositionNormalTexture[] Vertics) { Vertics[0] = m_Vertices[m_IndexBuffer[index]]; Vertics[1] = m_Vertices[m_IndexBuffer[index + 1]]; Vertics[2] = m_Vertices[m_IndexBuffer[index + 2]]; } } /// <summary>書き込み用コンテントタイプライタ</summary> [ContentTypeWriter] public class ModelVertexDataWriter : ContentTypeWriter<ModelVertexData> { /// <summary>書き込みメソッド</summary> /// <param name="output">ライター</param> /// <param name="value">頂点情報</param> protected override void Write( ContentWriter output, ModelVertexData value) { // メンバを書き出します output.Write((int)value.m_Vertices.Length); for (int i = 0; i < value.m_Vertices.Length; i++) { output.Write(value.m_Vertices[i].Position); output.Write(value.m_Vertices[i].Normal); output.Write(value.m_Vertices[i].TextureCoordinate); } output.Write(value.m_IndexBuffer.Length); for (int i = 0; i < value.m_IndexBuffer.Length; i++) { output.Write(value.m_IndexBuffer[i]); } output.Write(value.m_TextureNames.Length); for (int i = 0; i < value.m_TextureNames.Length; i++) { output.Write(value.m_TextureNames[i]); } } /// <summary>ランタイムタイプを取得します</summary> /// <param name="targetPlatform">未使用</param> /// <returns>ランタイムタイプ名</returns> public override string GetRuntimeType( TargetPlatform targetPlatform) { return typeof(ModelVertexData).AssemblyQualifiedName; } /// <summary>リーダーランタイム情報の取得を行います</summary> /// <param name="targetPlatform">未使用</param> /// <returns>ランタイム情報</returns> public override string GetRuntimeReader( TargetPlatform targetPlatform) { return "BGContent.ModelVertexDataReader, BGContent, Version=1.0.0.0, Culture=neutral"; } } |
４．頂点情報の取得
これで、エントリポイントからようやく情報が取れるようになりました。
Processメソッドで基底メソッドをコールして情報を読み込み、ModelContentクラスを引数としたメソッドを作成し、この内容から頂点情報、インデックス情報、テクスチャー情報を取得して、自前のデータフォーマットであるModelVertexDataクラスに情報を設定できるようにしました。
５．モデルに格納
自前のフォーマットにデータを保存できたまでは良いのですが、この情報をどこに格納すればいいのだろう？とModelクラスを見ていたら、Tagというメンバ(object型)に任意のデータを設定できるみたいだったので、これを設定しました。
これにより、ContentManager.Load
◇ ◇ ◇
とまぁ、モデルの頂点情報を取得するまでにかなりの四苦八苦を行いましたが、とりあえず背景のモデルの頂点が取得できたので、背景としての存在を設計できるようになりました。
XNA上でのここまでの作業を行う事と、C++でDirect3Dを用いて自前でシンプルに情報を取得する…という比較は価値観の違いで行えませんが、この時点で一般のアマグラマーの人にXNAを流行らせるにはかなりの苦労が必要なのかなぁ～という所感がありました。
(背景ヒットの無いシンプルなゲーム制作か、自然とオープンなライブラリが充実してくれば話は別ですが…)
また、後で分ったのですが、この読み込みはキャッシュされる(or 読み込みは一度だけ)の模様で、ContentManager.Load
◇ ◇ ◇
【おわりに】
文頭に「※これは2007/4月の頃のお話です。」という注釈をしましたが、この後にXNAのバージョンが上り、VertexBuffer.GetDataメソッドがWriteOnlyではなくなりました。
しかし、コンテントパイプラインの勉強という意味では良かったので、モデル情報の細かいハンドリングもできそうですし、コレはコレで使って行こうと思いました。
ただし、モデルの中にも頂点情報があるのに、更に自前のフォーマットでその複製があるのがかなり痛いです…
将来はこの辺りをどうするかを検討していかなければなりせん(何年後になるのか、それともこのプログラミングが途中で終了するのか…)
そして、本来は「ゲームプログラミング [XNA]」のカテゴリに載せるべき内容ではありますが、正直キチンと説明できるレベルではなかったので、開発日記としたレベルで、このカテゴリーに書くことにしました。
昔のゲームの想い出 [0033] 「妖怪道中記」 [ナムコ] [1987] [アーケード]
《超ド級難易度アクション！》
PCエンジンやファミリーコンピュータにも移植されている本ゲームは、プレイヤーの"たろすけ"を操り、5つの地獄ステージを巡り、最後に輪廻転生を果すといった内容です。
このゲームは1コインでクリアすることが困難極まりないゲームバランスとなっていて、雑誌ゲーメストなどで1コイン最高級エンディングの攻略記事などの特集も組まれた程のものでした。この攻略記事を見る前に、私は1コインで餓鬼界(下から二番目レベル)のエンディングが限界だったのですが、攻略記事を読んで「こりゃ、無理だ。」と諦めを決定した程です。
しかし、このゲーム(これはアーケードのみの話です)には、当時の私にとって物凄く魅力があり、クリアまで何万円とつぎ込んでしまったという経緯がありました。
ゲームセンターで、コイツにどんだけ金が吸い込まれてしまったか…
【背景のグラフィックが緻密】
この時期の2Dゲームのグラフィックは最高時期に達っしていて、背景にまるで使いまわしがありません。
これが「ちょっと、地獄巡りでもしてみるかな～」という気分にさせてくれます。全体的に時間制限のあるゲーム(永久パターン防止キャラがソレにあたります)なので、箱庭探索とまでは行かないのですが、3面程度までと決めてゲームをするのであれば、綺麗な要所の観光巡りとしてウロウロできます。
【魅せるキャラクター】
全5ステージに配置された敵キャラクターは数々の種類がいて、似たようなアルゴリズムではあるものの、「おっ、こんなキャラがココだけで出現するんだ。」みたいな感じで、存在感をかもしだしてくれます。
また、ボスであったり、通過ポイントの中ボスであったりする妖怪もかなりいい味出しており、ヒット&アウェイを楽しませてくれます。
日本の妖怪が出現するアーケードゲームは幾つかありますが、このゲームはトップレベルと思います。
【破壊のカタルシス】
たろすけの武器は気合い弾なのですが(ちなみにこれはお店で連射を購入できます)、これは溜め撃ちができ、貫通弾にもなります。そして、これで敵を粉砕すると非常に気持ちいいです。
この攻撃方法は、本ゲームの要となっているので、これを故意に使用できるようにと敵の出現場所がゲーム上うまく配置されています。
(まずプレー開始時にザコがゾロゾロ出てきたりするので、これを気合い弾で一蹴です)
これは中ボス戦でもうまく使用するような仕様になっており、敵弾が自機に来るタイミングと溜めのタイミングが非常にマッチしています。
…とまぁ、おおかたこのような理由で「もう一回… またもう一回…」とお金が飲みこまれていった感じです。(^^;
とにかく先の展開(やグラフィック)が気になってしまい、このゲームにのめりこんだという想い出があります。
◇ ◇ ◇
このゲームの高難易度の理由は「目の前に敵が急に出現する」、「ランダムに飛行タイプの敵が大量に出現する」、「永久パターン防止キャラがやたら出現する」といったものが挙げられ、特に永久パターン防止キャラの「地獄火(とか鬼火とか地獄輪とか呼ばれていますね)」というキャラクター出現の存在で、このキャラに瞬殺されるようになってきます。
このゲームは敵の出現場所や時間を覚えてくると、普通に配置されている妖怪ではあまりダメージを受けなくなり(ある程度受けてもお店でライフを回復しやすい)、そうなるとこの永久パターン防止キャラが生きてくるという感じとなります。
永久パターン防止キャラとは良く言ったもので、「触ると瀕死の状態」になり、且つ「非常に硬い」、「時間が経過すると出現数がどんどん増えてくる」…といったフィーチャーにより、ゲームとしてはプレー続行が不可能となってきます。
この流れはディップスイッチの難易度にも因るとは思いますが、順調に進んでいるとおおよそ3, 4面辺りで徐々にお目にかかるようになり、スクロールアウト(かなり大変)か、最大気合い弾数発でこれを破壊をして、逃げるようにプレーすることになります。
そして、ステージ4では各中ボスが持っている三種の神器が必要になるので、これと対峙している際等に出現されると、もう話にならないゲーム展開になったりします。
(ゲーメストでは、この三種の神器のフィーチャーをスキップする方法が掲載されていたりして驚いたものです)
私はいきつけのゲームセンターの難易度でこの地獄火の出現タイミングを測り、ステージ4のボス戦付近でこれが出ないようなルート検索を行い、ステージ4をクリアしていました。
しかし、最終ステージは「敵を一切殺生してはならないことが良いエンディングの条件」だったので、「地獄火を倒さないでルート確保のために一般妖怪(笑)を倒す」か、その逆かのトレードオフ状態でした…
私は後者の「地獄火をまとめて引き付けて倒して、できるだけ一般妖怪は倒さない」という選択でクリアをした感じでした。
特に一番最後の雲に乗りながら上を目指すという場所が最強(最凶)の鬼門で、地獄火をスクロールアウトしてはまた登る…という繰り返しで、なんとかクリアした感じでした。
しかし、それでも殆ど運でクリアするようなゲームバランスとなっており、当時は納得が行かなかったこともしばしば…という感じでした。
(ゲームセンターでも周囲のギャラリーが「こんなの無理だろ～」みたいな感じで漏らしていたのを聴き逃がしませんでした(^^;)
このように湯水の如くお金をつぎ込んだゲームですが、永久パターン防止キャラの出現バランスさえ良ければ洒落にならないほど楽しいゲームなのに～と思いつつ、「なんだかんだ言っても私の中では名作」という思い入れがあるゲームです。
最後に…
私は基本的に1度もコンティニューしないで1コインでエンディングを目指すゲーマーだったのですが、このゲームは全てのエンディング見たさにコンティニューを使用して全てのエンディングを見ました…
(コンティニューありきなバランスのせいか、コンティニューをするとかなり難易度が下っていた気がします)
PCエンジン版
3面の竜宮城のストリップショーはPAUSEが効かないので、
ビデオに撮って内容を確認した想い出が…(´д｀；ハアハア
PCエンジンやファミリーコンピュータにも移植されている本ゲームは、プレイヤーの"たろすけ"を操り、5つの地獄ステージを巡り、最後に輪廻転生を果すといった内容です。
このゲームは1コインでクリアすることが困難極まりないゲームバランスとなっていて、雑誌ゲーメストなどで1コイン最高級エンディングの攻略記事などの特集も組まれた程のものでした。この攻略記事を見る前に、私は1コインで餓鬼界(下から二番目レベル)のエンディングが限界だったのですが、攻略記事を読んで「こりゃ、無理だ。」と諦めを決定した程です。
しかし、このゲーム(これはアーケードのみの話です)には、当時の私にとって物凄く魅力があり、クリアまで何万円とつぎ込んでしまったという経緯がありました。
ゲームセンターで、コイツにどんだけ金が吸い込まれてしまったか…
【背景のグラフィックが緻密】
この時期の2Dゲームのグラフィックは最高時期に達っしていて、背景にまるで使いまわしがありません。
これが「ちょっと、地獄巡りでもしてみるかな～」という気分にさせてくれます。全体的に時間制限のあるゲーム(永久パターン防止キャラがソレにあたります)なので、箱庭探索とまでは行かないのですが、3面程度までと決めてゲームをするのであれば、綺麗な要所の観光巡りとしてウロウロできます。
【魅せるキャラクター】
全5ステージに配置された敵キャラクターは数々の種類がいて、似たようなアルゴリズムではあるものの、「おっ、こんなキャラがココだけで出現するんだ。」みたいな感じで、存在感をかもしだしてくれます。
また、ボスであったり、通過ポイントの中ボスであったりする妖怪もかなりいい味出しており、ヒット&アウェイを楽しませてくれます。
日本の妖怪が出現するアーケードゲームは幾つかありますが、このゲームはトップレベルと思います。
【破壊のカタルシス】
たろすけの武器は気合い弾なのですが(ちなみにこれはお店で連射を購入できます)、これは溜め撃ちができ、貫通弾にもなります。そして、これで敵を粉砕すると非常に気持ちいいです。
この攻撃方法は、本ゲームの要となっているので、これを故意に使用できるようにと敵の出現場所がゲーム上うまく配置されています。
(まずプレー開始時にザコがゾロゾロ出てきたりするので、これを気合い弾で一蹴です)
これは中ボス戦でもうまく使用するような仕様になっており、敵弾が自機に来るタイミングと溜めのタイミングが非常にマッチしています。
…とまぁ、おおかたこのような理由で「もう一回… またもう一回…」とお金が飲みこまれていった感じです。(^^;
とにかく先の展開(やグラフィック)が気になってしまい、このゲームにのめりこんだという想い出があります。
このゲームの高難易度の理由は「目の前に敵が急に出現する」、「ランダムに飛行タイプの敵が大量に出現する」、「永久パターン防止キャラがやたら出現する」といったものが挙げられ、特に永久パターン防止キャラの「地獄火(とか鬼火とか地獄輪とか呼ばれていますね)」というキャラクター出現の存在で、このキャラに瞬殺されるようになってきます。
このゲームは敵の出現場所や時間を覚えてくると、普通に配置されている妖怪ではあまりダメージを受けなくなり(ある程度受けてもお店でライフを回復しやすい)、そうなるとこの永久パターン防止キャラが生きてくるという感じとなります。
永久パターン防止キャラとは良く言ったもので、「触ると瀕死の状態」になり、且つ「非常に硬い」、「時間が経過すると出現数がどんどん増えてくる」…といったフィーチャーにより、ゲームとしてはプレー続行が不可能となってきます。
この流れはディップスイッチの難易度にも因るとは思いますが、順調に進んでいるとおおよそ3, 4面辺りで徐々にお目にかかるようになり、スクロールアウト(かなり大変)か、最大気合い弾数発でこれを破壊をして、逃げるようにプレーすることになります。
そして、ステージ4では各中ボスが持っている三種の神器が必要になるので、これと対峙している際等に出現されると、もう話にならないゲーム展開になったりします。
(ゲーメストでは、この三種の神器のフィーチャーをスキップする方法が掲載されていたりして驚いたものです)
私はいきつけのゲームセンターの難易度でこの地獄火の出現タイミングを測り、ステージ4のボス戦付近でこれが出ないようなルート検索を行い、ステージ4をクリアしていました。
しかし、最終ステージは「敵を一切殺生してはならないことが良いエンディングの条件」だったので、「地獄火を倒さないでルート確保のために一般妖怪(笑)を倒す」か、その逆かのトレードオフ状態でした…
私は後者の「地獄火をまとめて引き付けて倒して、できるだけ一般妖怪は倒さない」という選択でクリアをした感じでした。
特に一番最後の雲に乗りながら上を目指すという場所が最強(最凶)の鬼門で、地獄火をスクロールアウトしてはまた登る…という繰り返しで、なんとかクリアした感じでした。
しかし、それでも殆ど運でクリアするようなゲームバランスとなっており、当時は納得が行かなかったこともしばしば…という感じでした。
(ゲームセンターでも周囲のギャラリーが「こんなの無理だろ～」みたいな感じで漏らしていたのを聴き逃がしませんでした(^^;)
このように湯水の如くお金をつぎ込んだゲームですが、永久パターン防止キャラの出現バランスさえ良ければ洒落にならないほど楽しいゲームなのに～と思いつつ、「なんだかんだ言っても私の中では名作」という思い入れがあるゲームです。
最後に…
私は基本的に1度もコンティニューしないで1コインでエンディングを目指すゲーマーだったのですが、このゲームは全てのエンディング見たさにコンティニューを使用して全てのエンディングを見ました…
(コンティニューありきなバランスのせいか、コンティニューをするとかなり難易度が下っていた気がします)
PCエンジン版
3面の竜宮城のストリップショーはPAUSEが効かないので、
ビデオに撮って内容を確認した想い出が…(´д｀；ハアハア
Sample Action Gameの紹介 [ステージ1-2(その1)]
ゲームも後半戦になり、徐々に構成が長いケースが増えてきました。本ステージも大きく分けて2部構成のようになっているので、ステージ16-2同様に分けて紹介したいと思います。
それではウォークスルーしていきたいと思います。
【ステージ開始マップ】
かなり下まで降りたステージ16-2により、なにやらおかしな場所に…
あれ？ステージ名を見ても「The Beginning.」に…
【ステージ開始】
滑るように高速でステージがスクロールし、自機が表示された所は城の…外？
「封印を探してください」との事。
【高台から降りると…】
こ、ここはステージ1のクリアポイント…
倒したサイクロプスやベルを入手した宝箱がそのままとなっています。
ステージ1の紹介にて、このステージが重要と説明しましたがこういう意味でした。
ちなみに、ここで本ステージをクリアできますが、ゲームを楽しむならここへは入ってはいけません。
【ステージを逆に戻る】
当初、封印を破壊して進んできた足場を逆に戻ります…
【森の上には…】
当初とは違い、森の上が見えます。雲に乗って行きましょう。
【封印】
雲の上には金色の封印が4つ存在します。
ステージ的な配置としては上部の左・中央・右に3つ、下部の左に1つあります。
高速に飛行する赤コウモリは攻撃力、耐久力があるので盾で防ぐか、待ち伏せて倒しておきましょう。
【封印を破壊すると…】
なにやら地面の下へと…
【穴が！？】
ステージ1のスタート地点だった場所に穴が開きました。
◇ ◇ ◇
今回はここまでとします。
前半戦は些細なミス以外はさほど難しくないと思います。これは嵐の前の靜けさ…とでも解釈してください。
それではウォークスルーしていきたいと思います。
【ステージ開始マップ】
かなり下まで降りたステージ16-2により、なにやらおかしな場所に…
あれ？ステージ名を見ても「The Beginning.」に…
【ステージ開始】
滑るように高速でステージがスクロールし、自機が表示された所は城の…外？
「封印を探してください」との事。
【高台から降りると…】
こ、ここはステージ1のクリアポイント…
倒したサイクロプスやベルを入手した宝箱がそのままとなっています。
ステージ1の紹介にて、このステージが重要と説明しましたがこういう意味でした。
ちなみに、ここで本ステージをクリアできますが、ゲームを楽しむならここへは入ってはいけません。
【ステージを逆に戻る】
当初、封印を破壊して進んできた足場を逆に戻ります…
【森の上には…】
当初とは違い、森の上が見えます。雲に乗って行きましょう。
【封印】
 |  |
雲の上には金色の封印が4つ存在します。
ステージ的な配置としては上部の左・中央・右に3つ、下部の左に1つあります。
高速に飛行する赤コウモリは攻撃力、耐久力があるので盾で防ぐか、待ち伏せて倒しておきましょう。
【封印を破壊すると…】
なにやら地面の下へと…
【穴が！？】
ステージ1のスタート地点だった場所に穴が開きました。
◇ ◇ ◇
今回はここまでとします。
前半戦は些細なミス以外はさほど難しくないと思います。これは嵐の前の靜けさ…とでも解釈してください。
昔のゲームの想い出 [0032] 「レイドック」 [T&Eソフト] [1985] [MSX2]
《超美麗シューティング！》
レイドックは2人同時プレーでドッキングが行える、SFシューティングゲームです。攻撃方法はショットとサブウェポンで攻撃が行え、敵は飛行タイプと地上に砲台が配備されており、奇数ステージは空中(宇宙)戦、偶数ステージは地上(飛行)戦となり、ゲームとしてはとてもオーソドックスなタイプという感じです。
このゲームはゲーム自体の内容よりも、「魅せてあげよう、1ドットのエクスタシー」というキャッチコピーの通り、当時のMSXでは初(だったんですかねぇ？)の1ドット単位の滑らかスクロールというのが売りでした(他にも1ドット単位での衝突判定とかあったみたいですが、全然目視できませんでした…)。個人的にはスクロール自体はアーケードゲームで目が熟れていたので、それ程気にはなっていなかったのですが(「MSX2だと、縦には1ドット単位でスクロールができるのだな」という事は分りましたが)、サブタイトルで挙げたように、このゲームは「超美麗」という単語が似合う程、美しい背景が強烈な印象として残っており、ベーシックマガジンのようなPC雑誌にスクリーンショットとしてよく見掛けた、ステージ6の青色の要塞は、この時代のゲームの中ではトップレベルの美しさを持っていると思ったものです。
また、このゲームは宇宙空間に物寂しげBGMが凄くマッチしており、素晴しいSFの世界観を出していたという感も強く、今迄のアーケードゲームにはなかった雰囲気も持っていました。
このゲームはディスクドライブが必要なMSX2だったために、ディスクドライブを持っていなかった私は(私はアシュギーネの出ていた、A1mk2ユーザーでした(^^ゞ)、ディスクドライブを持っている幼馴染(この幼馴染みはゲーメストやファミコン通信のライターをやっていたバーチャファイターで有名な方です)の家に行き、このゲームをプレーさせてもらいました。また、タイトルCGの読み込み時に音声合成で喋るというのも画期的で、「おー！MSX2で音声合成かよ！」なんて感動したものです。
そして、当時周りにハードウェアやソフトウェアに強い人がいなくて話せませんでしたが、MSX2のスプライトはMSXのソレよりも多く発色ができるモードがあって、それにはスプライトを重ねる必要があったため、「おぉ！頑張って重ねている！？」と独りで興奮していたものです。
(その分、画面に出現するキャラクターは少なめだったのは見逃がしませんでしたが…)
◇ ◇ ◇
このように、当時は似たようなフィーチャーのシューティングゲームが色々と出ていた中、映像美だけでここまで勝負できるゲームというのは凄いと思ったものです。
ちなみに後続で何種類か出たレイドックは、MSXハードでのリリースとなり、グラフィックがデグレードされている物(曲は一緒)や、更にその後のMSX2後継機種でのリリースでは色々なアレンジが行われたり(個人的に絵も綺麗ではなくなったと感じています)と、これはこれでアリではあるのですが、綺麗で悲壮感のあった初代とは違っていたために、個人的には「う～ん、これは初代レイドックが一番良くできているかな…」という感じで、敬遠していました。
レイドックは2人同時プレーでドッキングが行える、SFシューティングゲームです。攻撃方法はショットとサブウェポンで攻撃が行え、敵は飛行タイプと地上に砲台が配備されており、奇数ステージは空中(宇宙)戦、偶数ステージは地上(飛行)戦となり、ゲームとしてはとてもオーソドックスなタイプという感じです。
このゲームはゲーム自体の内容よりも、「魅せてあげよう、1ドットのエクスタシー」というキャッチコピーの通り、当時のMSXでは初(だったんですかねぇ？)の1ドット単位の滑らかスクロールというのが売りでした(他にも1ドット単位での衝突判定とかあったみたいですが、全然目視できませんでした…)。個人的にはスクロール自体はアーケードゲームで目が熟れていたので、それ程気にはなっていなかったのですが(「MSX2だと、縦には1ドット単位でスクロールができるのだな」という事は分りましたが)、サブタイトルで挙げたように、このゲームは「超美麗」という単語が似合う程、美しい背景が強烈な印象として残っており、ベーシックマガジンのようなPC雑誌にスクリーンショットとしてよく見掛けた、ステージ6の青色の要塞は、この時代のゲームの中ではトップレベルの美しさを持っていると思ったものです。
また、このゲームは宇宙空間に物寂しげBGMが凄くマッチしており、素晴しいSFの世界観を出していたという感も強く、今迄のアーケードゲームにはなかった雰囲気も持っていました。
このゲームはディスクドライブが必要なMSX2だったために、ディスクドライブを持っていなかった私は(私はアシュギーネの出ていた、A1mk2ユーザーでした(^^ゞ)、ディスクドライブを持っている幼馴染(この幼馴染みはゲーメストやファミコン通信のライターをやっていたバーチャファイターで有名な方です)の家に行き、このゲームをプレーさせてもらいました。また、タイトルCGの読み込み時に音声合成で喋るというのも画期的で、「おー！MSX2で音声合成かよ！」なんて感動したものです。
そして、当時周りにハードウェアやソフトウェアに強い人がいなくて話せませんでしたが、MSX2のスプライトはMSXのソレよりも多く発色ができるモードがあって、それにはスプライトを重ねる必要があったため、「おぉ！頑張って重ねている！？」と独りで興奮していたものです。
(その分、画面に出現するキャラクターは少なめだったのは見逃がしませんでしたが…)
◇ ◇ ◇
このように、当時は似たようなフィーチャーのシューティングゲームが色々と出ていた中、映像美だけでここまで勝負できるゲームというのは凄いと思ったものです。
ちなみに後続で何種類か出たレイドックは、MSXハードでのリリースとなり、グラフィックがデグレードされている物(曲は一緒)や、更にその後のMSX2後継機種でのリリースでは色々なアレンジが行われたり(個人的に絵も綺麗ではなくなったと感じています)と、これはこれでアリではあるのですが、綺麗で悲壮感のあった初代とは違っていたために、個人的には「う～ん、これは初代レイドックが一番良くできているかな…」という感じで、敬遠していました。
XNAにおける3Dゲーム描画設計 (スプライト描画情報を持たせる)
前回まで3Dモデル情報の描画を行う説明をしてきましたが、今回から2D情報をスプライトとして描画する説明を行います。
3Dゲームにてスプライトの表現というと、奥行がないもの(常に手前に表示されるもの)ということで、ステータス情報や文字情報が主な表示情報となることが多いと思われます。ここでは従来のサンプルにコードを追記編集して、自機のエネルギーメーターの表示といったサンプルを挙げて説明して行こうと思います。
■サンプルソース (2008.03.23.zip)
Fig.実行画面
Fig.サンプルソースのデータ構成
◇ ◇ ◇
モデルキャラクタータスククラスを設計した際は、このクラス内にモデル情報を保持しましたが、今回はスプライト情報を持つクラスとして、スプライトキャラクタータスククラスを設計します(至極単純な発想ですね)。
サンプルソース上では「SpriteCharacterTask.cs」がその実装例として実装しています。
XNA上でスプライトを実現するには、Texture2Dクラスを用いれば容易に実現が行え、この情報に対して描画を行えば、画面にスプライト(ビットマップ)が描画できます。モデルキャラクタータスククラスの時同様、スプライトキャラクタータスククラスには、このTexture2Dクラスをメンバ(m_texture)として保持し、このスプライトを描画するための座標(m_drawRect)を内包しています。
ここで、スプライトとテクスチャーの用語が混合しているので、本ブログではどのように考えているかというと、
[スプライト]
昔ながらの2Dゲームにて表現される、平面のビットマップオブジェクト(物体としての定義が強いです)。
[テクスチャー]
3Dのモデルに貼り付けるビットマップデータ(要素としての定義が強いです)。
という感じで表現します。
XNA上のスプライト情報はTexture2Dというクラスの考え方を持っていても、描画の際にはSpriteBatchというクラスを用いた「スプライト」という用語を用います。
3Dモデル表示をメインとしたゲームを作成する場合、(設計次第ではありますが)スプライトの情報というのは、基本的にステータス情報の表示等が主で、ゲーム上の自機や弾等の衝突が行われるようなオブジェクトとしては実装されません。これは基本的にスプライトには奥行情報が無いためで、3次元キャラクターと2次元キャラクターでは同じ次元で存在させて衝突させることが、困難とされているためです。
(これを実現した場合、大抵3次元座標の方が2次元座標の情報に合せる表現が多々見受けられます。例としては3Dの表現をしている2Dタイプのシューティングゲームなどがその例となっています)
本サンプルの設計では、2Dはあくまでステータス情報のみという考えで設計しています。
次回からはこれを踏まえて、描画の設計について説明して行きたいと思います。
◇ ◇ ◇
ちなみに上述の例の逆応用で、2次元ビットマップを3次元空間で表現する方法があり、これは「ビルボード」と呼ばれる手法となります。古くからはFPSでDOOMが、RPGではゼノギアス等がこのような処理を行っているように見受けられます。ポリゴン描画のオーベーヘッドに比べ、高速で処理できますし、アニメ調のキャラクターを表現するゲーム設計には有効な手法と思います。
3Dゲームにてスプライトの表現というと、奥行がないもの(常に手前に表示されるもの)ということで、ステータス情報や文字情報が主な表示情報となることが多いと思われます。ここでは従来のサンプルにコードを追記編集して、自機のエネルギーメーターの表示といったサンプルを挙げて説明して行こうと思います。
■サンプルソース (2008.03.23.zip)
Fig.実行画面
Fig.サンプルソースのデータ構成
◇ ◇ ◇
モデルキャラクタータスククラスを設計した際は、このクラス内にモデル情報を保持しましたが、今回はスプライト情報を持つクラスとして、スプライトキャラクタータスククラスを設計します(至極単純な発想ですね)。
サンプルソース上では「SpriteCharacterTask.cs」がその実装例として実装しています。
XNA上でスプライトを実現するには、Texture2Dクラスを用いれば容易に実現が行え、この情報に対して描画を行えば、画面にスプライト(ビットマップ)が描画できます。モデルキャラクタータスククラスの時同様、スプライトキャラクタータスククラスには、このTexture2Dクラスをメンバ(m_texture)として保持し、このスプライトを描画するための座標(m_drawRect)を内包しています。
ここで、スプライトとテクスチャーの用語が混合しているので、本ブログではどのように考えているかというと、
[スプライト]
昔ながらの2Dゲームにて表現される、平面のビットマップオブジェクト(物体としての定義が強いです)。
[テクスチャー]
3Dのモデルに貼り付けるビットマップデータ(要素としての定義が強いです)。
という感じで表現します。
XNA上のスプライト情報はTexture2Dというクラスの考え方を持っていても、描画の際にはSpriteBatchというクラスを用いた「スプライト」という用語を用います。
3Dモデル表示をメインとしたゲームを作成する場合、(設計次第ではありますが)スプライトの情報というのは、基本的にステータス情報の表示等が主で、ゲーム上の自機や弾等の衝突が行われるようなオブジェクトとしては実装されません。これは基本的にスプライトには奥行情報が無いためで、3次元キャラクターと2次元キャラクターでは同じ次元で存在させて衝突させることが、困難とされているためです。
(これを実現した場合、大抵3次元座標の方が2次元座標の情報に合せる表現が多々見受けられます。例としては3Dの表現をしている2Dタイプのシューティングゲームなどがその例となっています)
本サンプルの設計では、2Dはあくまでステータス情報のみという考えで設計しています。
次回からはこれを踏まえて、描画の設計について説明して行きたいと思います。
◇ ◇ ◇
ちなみに上述の例の逆応用で、2次元ビットマップを3次元空間で表現する方法があり、これは「ビルボード」と呼ばれる手法となります。古くからはFPSでDOOMが、RPGではゼノギアス等がこのような処理を行っているように見受けられます。ポリゴン描画のオーベーヘッドに比べ、高速で処理できますし、アニメ調のキャラクターを表現するゲーム設計には有効な手法と思います。
Sample Action Gameの紹介 [ステージ16-2 (その2)]
今回は前回からの続きとなるステージ16-2の紹介です。後半戦はいままでクリアしたステージのお浚いのような構成になっています。
ここまで来れたのであれば、落ち着いてプレーすればそれほど大変ではないと思います。
それではウォークスルーしていきたいと思います。
【スイッチ その2】
前回の紹介したスイッチから更にスイッチのトラップとなります。
このスイッチはステージ8の攻略と同様に壁画の数字を点の方向に合せます。
注意点となりますが、ここではステージ8の時とは違い、スイッチの初期状態がどちらの方向にも傾いていないニュートラルとなっている上に、一度スイッチを切り替えたら「戻せない」という仕様となっています。
つまり、確実にスイッチを設定する必要があります。
【PAUSEをかけると…】
壁画の数字をスイッチにする際、PAUSEをかけてジックリ考えたいところですが、一度PAUSEをかけると画面にこのようなメッセージが…
そうです。ここではPAUSEが一度だけしか許されない仕様となっています。
【4つスイッチを設定】
正解だと正規ルート、不正解だと電撃ルートが開きます。
【出現する足場】
ステージ11の時のような出現する足場を4つ渡り、高速な足場を2つ渡って、左上のルートを通ります。
ここも時間にシビアなので、大きな失敗は許されません。
【サイクロプス】
2体のサイクロプスが出現します。
この時点でハイパーガントレットを入手していれば、サイクロプスの攻撃まで2回攻撃ができるので、テンポ良く片方のサイクロプスを撃破します。
モタモタしていると挟まれて攻撃を受けるので、気をつけましょう。
【クリアキーの出現】
2体のサイクロプスを倒すと、クリアキーが出現し、床が下に降ります。
壁画に左への矢印が…
ちなみに、このまま床に乗り続けていると、このようになります。
【宝箱】
宝箱の中には盾が入っています。効果は見て分るように、足元まで防御範囲が広がります。
これは宝箱の鍵(赤)を持っていた場合のケースで、もしも宝箱の鍵を持っていない場合はトラップが発動します。
宝箱の横のスイッチは、出口への床を起動できます。
【ステージクリア】
やっと出口の扉が見えました。
◇ ◇ ◇
とても長いステージ構成でしたが、これがステージ16-2となります。
大分下へ降りてきましたが、マップ上ではどのようになっているのか、こうご期待！？
それにしても、ステージの最初や途中途中に見えた、ネジのような背景は一体…？
ここまで来れたのであれば、落ち着いてプレーすればそれほど大変ではないと思います。
それではウォークスルーしていきたいと思います。
【スイッチ その2】
前回の紹介したスイッチから更にスイッチのトラップとなります。
このスイッチはステージ8の攻略と同様に壁画の数字を点の方向に合せます。
注意点となりますが、ここではステージ8の時とは違い、スイッチの初期状態がどちらの方向にも傾いていないニュートラルとなっている上に、一度スイッチを切り替えたら「戻せない」という仕様となっています。
つまり、確実にスイッチを設定する必要があります。
【PAUSEをかけると…】
壁画の数字をスイッチにする際、PAUSEをかけてジックリ考えたいところですが、一度PAUSEをかけると画面にこのようなメッセージが…
そうです。ここではPAUSEが一度だけしか許されない仕様となっています。
【4つスイッチを設定】
正解だと正規ルート、不正解だと電撃ルートが開きます。
【出現する足場】
ステージ11の時のような出現する足場を4つ渡り、高速な足場を2つ渡って、左上のルートを通ります。
ここも時間にシビアなので、大きな失敗は許されません。
【サイクロプス】
2体のサイクロプスが出現します。
この時点でハイパーガントレットを入手していれば、サイクロプスの攻撃まで2回攻撃ができるので、テンポ良く片方のサイクロプスを撃破します。
モタモタしていると挟まれて攻撃を受けるので、気をつけましょう。
【クリアキーの出現】
2体のサイクロプスを倒すと、クリアキーが出現し、床が下に降ります。
壁画に左への矢印が…
ちなみに、このまま床に乗り続けていると、このようになります。
【宝箱】
宝箱の中には盾が入っています。効果は見て分るように、足元まで防御範囲が広がります。
これは宝箱の鍵(赤)を持っていた場合のケースで、もしも宝箱の鍵を持っていない場合はトラップが発動します。
宝箱の横のスイッチは、出口への床を起動できます。
【ステージクリア】
やっと出口の扉が見えました。
◇ ◇ ◇
とても長いステージ構成でしたが、これがステージ16-2となります。
大分下へ降りてきましたが、マップ上ではどのようになっているのか、こうご期待！？
それにしても、ステージの最初や途中途中に見えた、ネジのような背景は一体…？
自機の移動コントロールについて
現在開発しているSample Action Game 3Dは、俗にいうTPS(Third Person Shooter)という表現になるのですが、この際、自機の移動コントロールをどのようにするか検討しました。
１．ラジコン方式
２．カメラ視点方式
ラジコン方式は「自機の向いている方向」に対してコントローラーの上下で自機の前進後退を行い、コントローラーの左右で自機の向いている方向を変える方式となります。昔からあるFPSの移動方式にもなっていて、TPSだと初代バイハザードやトゥームレイダーなどがこの方式を採用しています。
特徴としては自機の向いている方向を基準とするので、カメラアングルが変ってもコントロール方向が変化しません。また自機の向きを180度逆に向かせる事(急旋回)を場合により対応させる方法を必要とします。
(自機を左右に向かせる速度を上げれば不要ですが、これは調整のトレードオフとなります)
カメラ視点方式は自機の移動方向と向きを「カメラの向いている方向」に対して決定する方法で、カメラが見ている方向がコントローラーの上となり、自機がその方向に移動します。近年のTPSのゲームは、割とこの形式になっているように見受けられます。
特徴としてはカメラアングルに対して自機をコントロールするので、ゲームプレイヤーとしては直感的に移動が行えます。ただし、カメラは常に自機を追いかけるので、例えば左右に自機を移動させ続けるとカメラを中心に自機がグルグル周る事になります。
これはステージ内を左右に移動するの事とは意味合いが違うので、座標的には若干斜めに移動することを意味します。
また、ラジコン方式と違い、自機を180度逆に向かせることは比較的容易となり、例えば前を向いている(カメラと同じ方向を向いている)時に、コントローラーの下を押下すれば、一気に逆を向かせられるという仕様が実現できます。
(ただし、ゲームによっては一気に逆を向かせずに、n度程度の回転をかけて、数フレームで180度を達成させるインターフェースの仕様にするものもあります。この場合は自機の動作が滑らかになり、リアリティ感を得られたりできますが、代償として振り返るレスポンスが遅れるので、ゲームの内容によりけりという感じとなります)
◇ ◇ ◇
このような仕様がある中、Sample Action Game 3Dではカメラ視点方式を採用することにしました。
180度の旋回に関しては現在はダイレクトに反応するということで、入力された方向に即自機が向くようにしました。
将来は入力レベルにより、n度の旋回を実装するかもしれませんが、現在はあまり深く考えない本仕様で設計しています。
このように、自機のコントロール一つとっても、どのように実現すべきか検討するのは考えさせられるものです。
１．ラジコン方式
２．カメラ視点方式
ラジコン方式は「自機の向いている方向」に対してコントローラーの上下で自機の前進後退を行い、コントローラーの左右で自機の向いている方向を変える方式となります。昔からあるFPSの移動方式にもなっていて、TPSだと初代バイハザードやトゥームレイダーなどがこの方式を採用しています。
特徴としては自機の向いている方向を基準とするので、カメラアングルが変ってもコントロール方向が変化しません。また自機の向きを180度逆に向かせる事(急旋回)を場合により対応させる方法を必要とします。
(自機を左右に向かせる速度を上げれば不要ですが、これは調整のトレードオフとなります)
カメラ視点方式は自機の移動方向と向きを「カメラの向いている方向」に対して決定する方法で、カメラが見ている方向がコントローラーの上となり、自機がその方向に移動します。近年のTPSのゲームは、割とこの形式になっているように見受けられます。
特徴としてはカメラアングルに対して自機をコントロールするので、ゲームプレイヤーとしては直感的に移動が行えます。ただし、カメラは常に自機を追いかけるので、例えば左右に自機を移動させ続けるとカメラを中心に自機がグルグル周る事になります。
これはステージ内を左右に移動するの事とは意味合いが違うので、座標的には若干斜めに移動することを意味します。
また、ラジコン方式と違い、自機を180度逆に向かせることは比較的容易となり、例えば前を向いている(カメラと同じ方向を向いている)時に、コントローラーの下を押下すれば、一気に逆を向かせられるという仕様が実現できます。
(ただし、ゲームによっては一気に逆を向かせずに、n度程度の回転をかけて、数フレームで180度を達成させるインターフェースの仕様にするものもあります。この場合は自機の動作が滑らかになり、リアリティ感を得られたりできますが、代償として振り返るレスポンスが遅れるので、ゲームの内容によりけりという感じとなります)
◇ ◇ ◇
このような仕様がある中、Sample Action Game 3Dではカメラ視点方式を採用することにしました。
180度の旋回に関しては現在はダイレクトに反応するということで、入力された方向に即自機が向くようにしました。
将来は入力レベルにより、n度の旋回を実装するかもしれませんが、現在はあまり深く考えない本仕様で設計しています。
このように、自機のコントロール一つとっても、どのように実現すべきか検討するのは考えさせられるものです。
昔のゲームの想い出 [0031] 「ドラキュラハンター」 [テクノン工業] [1980] [アーケード]
《美女のウェストがっ！？》
ドラキュラハンターは、「ゲームセンターあらし」等でも有名な、牧師がドラキュラを十字架で倒すアクションシューティングゲームです。
私がこのゲームを見たのは、普段行ったことの無い「住宅街の中にあるゲームセンター(プレハブ式のゲームセンターだったのでゲーム小屋)」で、ここにはゲームが4, 5台置いてあるだけで、駄菓子も売っていないような所での発見でした。(プレハブで出来ていたので、床も木の板という作りでした)
この隠れ家的な小屋の存在は、あまりゲームをしたことが無いクラスメートとの会話の中で、「それらしいゲームなら、○○っていうゲーム屋で友人に連れられて見たことあるよ」という発言からの事で、私はこのゲームを一目見ようと、普段行かないような場所に勇んで足を運んだという経緯があります。
このゲームは漫画では有名な割には出荷台数が多くなかったのか、数々の大きなゲームセンターに遊びに行っていた私でも、このゲームを見かけたのは、この小屋のようなゲームセンターのみでした。
◇ ◇ ◇
さて、本ゲームの内容ですが、自機は牧師となって、ステージ内をウロウロしているドラキュラを武器である十字架(ブーメラン方式)で倒すというゲームです。ゲームセンターあらしでは表現されていないような説明をするとすれば、時代的にキャラクターは一色で、雰囲気的には「ワープ&ワープ」っぽい配色というと分りやすい気がします。
また画面上部にはコウモリがウロウロしており、自機とのX軸が合うと急降下爆撃のように降ってくるので、これがかなりの難易度となっています。(以前、紹介した「フリスキートム」のネズミの攻撃並という印象があります)
そして、このコウモリの攻撃により画面下部に十字架で守られている「美女」(とインストラクションカードに書いてあった)に攻撃をしてきます。
この十字架がスペースインベーダーのトーチカにような役割となっており、これがコウモリやドラキュラに破られて美女が襲われるとゲームオーバーとなります。この仕様はタンクバタリアンの旗のような仕様となっており、逆に上部にあるドラキュラの城の入口が開いた時に十字架を打ち込むと即ステージクリアとなります。(リリース時期がほぼ一緒なので、どちらが類似しているという訳でもない感じですが…)
当時私はこの「美女」の腰のクビレの動きが異様に目につき(これはエロいという意味ではないです)、息をしているアニメーションに対して何故だか妙に「生」を感じていました。そのためか、「十字架に守られいる中、ジッと横たわり、ヒッソリと息をしている…」というこの様が妙に「恐怖」を感じてしまい、私の中のドラキュラハンターは結構ホラーゲームの部類に入っています。(^^;
(このゲームを知っている知り合いがいないので、このような説明をするのは生れて初めてなのですが…)
◇ ◇ ◇
今ではかなりの希少ゲームとなっているこのゲームですが、ゲームの歴史上において、このゲームをリアルタイムでプレーできたのはとても運が良かったと思っています。
ドラキュラハンターは、「ゲームセンターあらし」等でも有名な、牧師がドラキュラを十字架で倒すアクションシューティングゲームです。
私がこのゲームを見たのは、普段行ったことの無い「住宅街の中にあるゲームセンター(プレハブ式のゲームセンターだったのでゲーム小屋)」で、ここにはゲームが4, 5台置いてあるだけで、駄菓子も売っていないような所での発見でした。(プレハブで出来ていたので、床も木の板という作りでした)
この隠れ家的な小屋の存在は、あまりゲームをしたことが無いクラスメートとの会話の中で、「それらしいゲームなら、○○っていうゲーム屋で友人に連れられて見たことあるよ」という発言からの事で、私はこのゲームを一目見ようと、普段行かないような場所に勇んで足を運んだという経緯があります。
このゲームは漫画では有名な割には出荷台数が多くなかったのか、数々の大きなゲームセンターに遊びに行っていた私でも、このゲームを見かけたのは、この小屋のようなゲームセンターのみでした。
さて、本ゲームの内容ですが、自機は牧師となって、ステージ内をウロウロしているドラキュラを武器である十字架(ブーメラン方式)で倒すというゲームです。ゲームセンターあらしでは表現されていないような説明をするとすれば、時代的にキャラクターは一色で、雰囲気的には「ワープ&ワープ」っぽい配色というと分りやすい気がします。
また画面上部にはコウモリがウロウロしており、自機とのX軸が合うと急降下爆撃のように降ってくるので、これがかなりの難易度となっています。(以前、紹介した「フリスキートム」のネズミの攻撃並という印象があります)
そして、このコウモリの攻撃により画面下部に十字架で守られている「美女」(とインストラクションカードに書いてあった)に攻撃をしてきます。
この十字架がスペースインベーダーのトーチカにような役割となっており、これがコウモリやドラキュラに破られて美女が襲われるとゲームオーバーとなります。この仕様はタンクバタリアンの旗のような仕様となっており、逆に上部にあるドラキュラの城の入口が開いた時に十字架を打ち込むと即ステージクリアとなります。(リリース時期がほぼ一緒なので、どちらが類似しているという訳でもない感じですが…)
当時私はこの「美女」の腰のクビレの動きが異様に目につき(これはエロいという意味ではないです)、息をしているアニメーションに対して何故だか妙に「生」を感じていました。そのためか、「十字架に守られいる中、ジッと横たわり、ヒッソリと息をしている…」というこの様が妙に「恐怖」を感じてしまい、私の中のドラキュラハンターは結構ホラーゲームの部類に入っています。(^^;
(このゲームを知っている知り合いがいないので、このような説明をするのは生れて初めてなのですが…)
今ではかなりの希少ゲームとなっているこのゲームですが、ゲームの歴史上において、このゲームをリアルタイムでプレーできたのはとても運が良かったと思っています。
Sample Action Gameの紹介 [ステージ16-2(その1)]
今回はステージ16-2の紹介です。このステージは前回のステージにて橋の下の扉を通った時のステージとなります。
このステージは本ゲームの中で一番ボリュームがあるステージとなっているので二回に分けて紹介したいと思います。
それではウォークスルーしていきたいと思います。
【ステージ開始マップ】
橋の下から内部に入りました。
【開始地点】
目の前に壁…？
とおもいきや、不思議な柱があります。この柱は通り抜けできます。
【足場が…】
更に先に進むと足場が崩れます。
【ポーション】
足場を降りずに、更に先に進むとポーションがあります。
前面からダメージを受けている場合は取りに行きましょう。
【天井から炎が…】
足場が崩れると天井からゆっくりと炎が降りてきます。
このステージは時間制限よりも、この炎から逃げる感じのステージとなります。
急いでステージを降りて行きましょう。
【第1のフロアー】
崩れた足場から最初に降り立ったフロアーには、3種類のスライムとウィザードがいます。
これらを倒すまで次のフロアーに進めません。
【第1のフロアーを攻略】
スライムとウィザードを倒すと、更に足場が崩れます。
【第2のフロアー】
第2のフロアーに降り立つと左から雷が飛んできます。
足場を上下に移動しながら左側に進んで行きます。
【ダークグリーンスライム】
ダークグリーンスライムが砲台のように配置されていました。
【第3フロアーへ】
一番左側に次のフロアーへの降り口があります。
【第3フロアー】
第3のフロアーに降り立つと、石像からファイアボールが発射されます。
このファイアボールを盾で受けるか、剣で切りつけると、メッセージが表示されます。
【第4フロアーへ】
ある程度ファイアボールを受けると、右側の床が崩れ降り口ができます。
【宝箱出現方法の確認】
これも簡単と思います。
…が、この鍵は何の鍵でしょう？
【第4フロアー】
第4フロアーは敵がいません。
最初に降り立った所の右側を見ると鍵があります。まだ取れません。
【スイッチ】
スイッチがあります。これらを切り替えます。
【鍵の入手】
鍵のある壁が開きました。
【鍵で壁を開ける】
鍵で壁を開きます。
何気ないフィーチャーですが、出口の扉以外でも鍵を使う処理となります。
ちなみに、先程入手した鍵(赤)ではこの壁は開きません。
このフロアーの時間は結構ギリギリなので、急いで攻略する必要があります。
◇ ◇ ◇
今回はここまでとします。
このステージは天井からの炎が迫ってくるので、ミスはできるだけしないように急いで攻略する必要があります。
このステージは本ゲームの中で一番ボリュームがあるステージとなっているので二回に分けて紹介したいと思います。
それではウォークスルーしていきたいと思います。
【ステージ開始マップ】
橋の下から内部に入りました。
【開始地点】
目の前に壁…？
とおもいきや、不思議な柱があります。この柱は通り抜けできます。
【足場が…】
更に先に進むと足場が崩れます。
【ポーション】
足場を降りずに、更に先に進むとポーションがあります。
前面からダメージを受けている場合は取りに行きましょう。
【天井から炎が…】
足場が崩れると天井からゆっくりと炎が降りてきます。
このステージは時間制限よりも、この炎から逃げる感じのステージとなります。
急いでステージを降りて行きましょう。
【第1のフロアー】
崩れた足場から最初に降り立ったフロアーには、3種類のスライムとウィザードがいます。
これらを倒すまで次のフロアーに進めません。
【第1のフロアーを攻略】
スライムとウィザードを倒すと、更に足場が崩れます。
【第2のフロアー】
第2のフロアーに降り立つと左から雷が飛んできます。
足場を上下に移動しながら左側に進んで行きます。
【ダークグリーンスライム】
ダークグリーンスライムが砲台のように配置されていました。
【第3フロアーへ】
一番左側に次のフロアーへの降り口があります。
【第3フロアー】
第3のフロアーに降り立つと、石像からファイアボールが発射されます。
このファイアボールを盾で受けるか、剣で切りつけると、メッセージが表示されます。
【第4フロアーへ】
ある程度ファイアボールを受けると、右側の床が崩れ降り口ができます。
【宝箱出現方法の確認】
これも簡単と思います。
…が、この鍵は何の鍵でしょう？
【第4フロアー】
第4フロアーは敵がいません。
最初に降り立った所の右側を見ると鍵があります。まだ取れません。
【スイッチ】
スイッチがあります。これらを切り替えます。
【鍵の入手】
鍵のある壁が開きました。
【鍵で壁を開ける】
鍵で壁を開きます。
何気ないフィーチャーですが、出口の扉以外でも鍵を使う処理となります。
ちなみに、先程入手した鍵(赤)ではこの壁は開きません。
このフロアーの時間は結構ギリギリなので、急いで攻略する必要があります。
◇ ◇ ◇
今回はここまでとします。
このステージは天井からの炎が迫ってくるので、ミスはできるだけしないように急いで攻略する必要があります。
昔のゲームの想い出 [0030] 「チェスターフィールド」 [ビック東海] [1987] [ファミリーコンピュータ]
《複雑怪奇ダンジョン！？》
先日、久々に会った同僚とファミレスで夕飯を食べていたら、「今度、静岡にあるビック東海という会社と～」というような会話が出て、「えっ？その会社って、昔、ゲーム作ってたよねぇ～」という事を話したら、「えぇっ？そうなんですか？」と言われてしまいました…(^^ゞ
「あまりゲームをやらない人から見れば、たしかにマイナーな会社だったかなぁ…」と思いながらも、よくよく考えるとアーケードでもコンシューマーでも結構リリースはしてたよなぁ～と思い出し、フツフツと「チェスターフィールド」の事を思い出しました…
ビック東海といえば、「『アイギーナの予言』は知っている」という人が割と多いのですが、私の場合はチェスターフィールドに少しトラウマがあって、こっちが強烈な想い出になっています。
チェスターフィールドは、地上とダンジョンを移動しながら、ダンジョンでアイテムを回収しつつ、ダンジョンや地上にいるボスを倒していくアクションロールプレイングゲームです。一見すると雰囲気がリンクの冒険やファザナドゥっぽくもあるのですが、動作はかなり違います。
私はこのゲームをいきつけのファミコンショップでやっていた、書き換え可能ROMレンタルというものを500円で書き換えてプレーしましたｗ
このゲームは画面が静止している際の自機の歩き方がカクカク(8ドット移動)と移動するのですが、地上のスクロールが行われると急に滑らかに歩くという、見たことない仕様で動いていたのがとても印象的で、当時は不思議でなりませんでした。
そして、プレーすること数分、最初の船の中にあるダンジョン(たかが船の中なのに…)で、凄い事に小一時間以上出られない…という事態に陥りました。
実はこのゲームのダンジョン(画面切り替え式)というのは、繋がりがワープのようになっていて、正規ルートを通らないとループしてしまう…という初っ端からやってくれた仕様でした。しかも、あまり変化がない画面構成のため、「ここは来たのかなぁ？」ということになってしまい、同じ所をグルグル回ってしまっていた…ということになりました。
あまりの理不尽さに、結局はファミコン必勝本か何かの雑誌に頼ってクリアーをすることになったのですが、「正直、絵は綺麗だけど、クリアーまでがあまりの苦痛でトラウマになった…」という想い出となっています。
(このため、「ビック東海 = チェスターフィールド」となってしまった訳です)
◇ ◇ ◇
前回の「サラダの国のトマト姫」もそうなのですが、ゲームプレーで色々と悔しい思いをして、それが痛烈に記憶に残ってしまった場合も、それなりの想い出になるものなんだよなぁ。とシミジミします。
先日、久々に会った同僚とファミレスで夕飯を食べていたら、「今度、静岡にあるビック東海という会社と～」というような会話が出て、「えっ？その会社って、昔、ゲーム作ってたよねぇ～」という事を話したら、「えぇっ？そうなんですか？」と言われてしまいました…(^^ゞ
「あまりゲームをやらない人から見れば、たしかにマイナーな会社だったかなぁ…」と思いながらも、よくよく考えるとアーケードでもコンシューマーでも結構リリースはしてたよなぁ～と思い出し、フツフツと「チェスターフィールド」の事を思い出しました…
ビック東海といえば、「『アイギーナの予言』は知っている」という人が割と多いのですが、私の場合はチェスターフィールドに少しトラウマがあって、こっちが強烈な想い出になっています。
チェスターフィールドは、地上とダンジョンを移動しながら、ダンジョンでアイテムを回収しつつ、ダンジョンや地上にいるボスを倒していくアクションロールプレイングゲームです。一見すると雰囲気がリンクの冒険やファザナドゥっぽくもあるのですが、動作はかなり違います。
私はこのゲームをいきつけのファミコンショップでやっていた、書き換え可能ROMレンタルというものを500円で書き換えてプレーしましたｗ
このゲームは画面が静止している際の自機の歩き方がカクカク(8ドット移動)と移動するのですが、地上のスクロールが行われると急に滑らかに歩くという、見たことない仕様で動いていたのがとても印象的で、当時は不思議でなりませんでした。
そして、プレーすること数分、最初の船の中にあるダンジョン(たかが船の中なのに…)で、凄い事に小一時間以上出られない…という事態に陥りました。
実はこのゲームのダンジョン(画面切り替え式)というのは、繋がりがワープのようになっていて、正規ルートを通らないとループしてしまう…という初っ端からやってくれた仕様でした。しかも、あまり変化がない画面構成のため、「ここは来たのかなぁ？」ということになってしまい、同じ所をグルグル回ってしまっていた…ということになりました。
あまりの理不尽さに、結局はファミコン必勝本か何かの雑誌に頼ってクリアーをすることになったのですが、「正直、絵は綺麗だけど、クリアーまでがあまりの苦痛でトラウマになった…」という想い出となっています。
(このため、「ビック東海 = チェスターフィールド」となってしまった訳です)
前回の「サラダの国のトマト姫」もそうなのですが、ゲームプレーで色々と悔しい思いをして、それが痛烈に記憶に残ってしまった場合も、それなりの想い出になるものなんだよなぁ。とシミジミします。
XNAにおける3Dゲーム描画設計 (モデル描画処理)
3/12に引き続き、モデルの描画処理の説明です。XNAにおけるモデル描画は「凝らないで描画するのであれば至極シンプル」に描画が行えます。
描画には前回説明した、視点行列、射影行列の情報を用いて、描画を行います。
「サンプルソース(2008.02.29.zip)」では、XNAのフレームワークにて作成されるSampleGame.Draw関数から、今回設計したDrawManagerクラスのDraw関数が呼び出される流れとなっており、この関数が描画の入口となっています。
SampleGame.Draw関数が呼び出されるタイミングはXNAの判断に委ねられており、特に指定しなければ16.6ms毎(内部ではTargetElapsedTime：{00:00:00.0166667}という設定)になっています。これは一般的なゲームの描画タイミングが1秒間に60フレーム更新となっているためです。
それではこの内部処理の説明をしてみたいと思います。
◇ ◇ ◇
【登録されているモデルキャラクタークラスの選別】
DrawManager.Draw関数では登録されているタスクを描画するためのループを行っており、その際描画対象がモデルキャラクタータスク(ModelCharacterTask)クラスのみ描画を行うように判定しています。対象となったタスクは、ここから更にDrawManager.DrawModel関数にモデル情報や表示座標を引き渡され、この中でモデルの描画を行います。
【モデル情報の描画】
DrawManager.DrawModel関数では引数に渡されたモデル情報や座標情報、回転情報、縮尺情報を用いて以下の手順で描画を行います。
(※この関数には半透明を表わす引数もとりあえず実装しています)
という流れとなります。
モデル情報の描画と言いつつも色々な用語が出てきたので、私なりの解釈で説明すると、以下のような感じでしょうか…
【ボーン】
モデル全体に存在する骨組となります。これはアニメーション情報に用いる情報となり、例えば人体のモデルを作成したとした場合、体に1本の軸(ボーン)が入っており、それを基準に5方向に頭、両腕、両足の各ボーンが設定され、それらが別々にアニメーションをする場合などに用いる…というイメージが大まかな掴みという感じでしょうか。
今回Metasequoiaでモデルを作成しているので、プラグイン等を用いない場合はXファイル上、ボーン情報は生成されていないのですが、XNAのファイル読み込みにてデフォルトで2つを与えられている感じです。
【メッシュ】
1モデル情報となります。モデル情報にはポリゴンという用語に代表される、頂点情報(Vertex)、頂点を3角形に構成した情報(Index)や、エフェクト情報が格納されています。
モデルには複数メッシュが格納されるイメージですが(例えば体、頭、腕、足、洋服等)、これは仕様なのか私には不明なのですが、Metasequoia(フリーウェア版)ではモデルをXファイルに出力すると、メッシュは1つのみとなる模様です。
【エフェクト】
ポリゴンの描画や、そのレンダリングの際に必要となる座標変換情報や効果(シェーディング)情報となります。このサンプルでは、メッシュ生成時にXNAが自動的に作成してくれるBasicEffectクラスがエフェクトとして生成されているので、これを用いて必要な情報を設定します。この情報を任意に変化させることで、ライティングやシェーディングの処理を自在に変化させることができます。描画の真髄はこのクラスにあるという感じです。
また、このエフェクトクラスは自前で作成することができ、そのクラスにHLSL(High Level Shader Language)という言語で記述した「エフェクトファイル」というものをXNAのプロジェクトに設定して、これをアセットとして読み込むことができ、PCに搭載されているグラフィックボードのシェーディング機能を使用する…といった事が可能となります。
【ワールド座標変換について】
40行, 50行にてeffect.Worldというエフェクトクラス内のメンバに座標変換を行っていますが、これはローカル座標系をワールド座標系に座標変換を行っています。
計算の細かい説明は詳しい説明のあるサイトにて調べてもらうとして、一般的にはこのような、「親ボーン×縮尺×回転」の行列をMatrix.CreateTranslationで平行移動させる…というのがお作法という感じです。
回転行列の掛け方が、Z→X→Yの順序とアルファベット的とは違うのですが、これはかけ算の順序で回転マトリックスが変化するので、表現をしたい様に掛け合わせるようになります。
(将来回転して飛んでいく弾等を検討したいので、とりあえずサンプルではこのように回すことにします)
◇ ◇ ◇
これで、ついにモデルの描画が行えました。
サンプルソースを見ると分かるとおり、「頂点同士の座標に線を引く、3頂点をポリゴンとして内部を塗る、光の加減で塗った面に明暗を付ける」などを今回のソースコード上では一切行っていません。
このように「かなり難かしいところはとりあえず隠蔽」が行え、「もしも深く操作したい場合は言語的な派生などを行い、拡張ができる」という設計が実現されている事は、XNAフレームワークの素晴らしさであると感じます。(とは行っても、○○○ツクール程、容易ではありませんが…)
描画には前回説明した、視点行列、射影行列の情報を用いて、描画を行います。
「サンプルソース(2008.02.29.zip)」では、XNAのフレームワークにて作成されるSampleGame.Draw関数から、今回設計したDrawManagerクラスのDraw関数が呼び出される流れとなっており、この関数が描画の入口となっています。
SampleGame.Draw関数が呼び出されるタイミングはXNAの判断に委ねられており、特に指定しなければ16.6ms毎(内部ではTargetElapsedTime：{00:00:00.0166667}という設定)になっています。これは一般的なゲームの描画タイミングが1秒間に60フレーム更新となっているためです。
それではこの内部処理の説明をしてみたいと思います。
◇ ◇ ◇
【登録されているモデルキャラクタークラスの選別】
DrawManager.Draw関数では登録されているタスクを描画するためのループを行っており、その際描画対象がモデルキャラクタータスク(ModelCharacterTask)クラスのみ描画を行うように判定しています。対象となったタスクは、ここから更にDrawManager.DrawModel関数にモデル情報や表示座標を引き渡され、この中でモデルの描画を行います。
【モデル情報の描画】
DrawManager.DrawModel関数では引数に渡されたモデル情報や座標情報、回転情報、縮尺情報を用いて以下の手順で描画を行います。
(※この関数には半透明を表わす引数もとりあえず実装しています)
| 1: /// <summary>モデルを描画します</summary> 2: /// <param name="model">モデル</param> 3: /// <param name="position">モデル中心座標</param> 4: /// <param name="rotate">回転情報</param> 5: /// <param name="scaleOn">スケールの可否(true:行う, false:行わない)</param> 6: /// <param name="scale">スケール情報</param> 7: /// <param name="alphaOn">透過をの可否(true:行う, false:行わない)</param> 8: /// <param name="alpha">透過情報</param> 9: /// <remarks> 10: /// 透過処理をかける場合は Z バッファ情報がおかしくなるので 11: /// 描画を行うオブジェクトの配列に任意でキューイングを行うようにしてください 12: /// </remarks> 13: public void DrawModel( 14: Model model, Vector3 position, Vector3 rotate, 15: bool scaleOn, Vector3 scale, 16: bool alphaOn, float alpha) 17: { 18: // ボーンの個数分変換行列を取得します 19: Matrix[] transforms = new Matrix[model.Bones.Count]; 20: model.CopyAbsoluteBoneTransformsTo(transforms); 21: 22: // モデルを描画する 23: foreach (ModelMesh mesh in model.Meshes) 24: { 25: //メッシュの各エフェクトを設定 26: foreach (BasicEffect effect in mesh.Effects) 27: { 28: // とりあえず現在はデフォルトのライト 29: effect.EnableDefaultLighting(); 30: 31: // ビュー 32: effect.View = m_camera; 33: // 射影 34: effect.Projection = m_projection; 35: // 伸縮が無い場合 36: // (マトリクスを掛けるオーバーヘッドがどれくらいか分らないのでとりあえず処理を分けます) 37: if (scaleOn == false) 38: { 39: // ワールド 40: effect.World = transforms[mesh.ParentBone.Index] * 41: Matrix.CreateRotationZ(rotate.Z) * 42: Matrix.CreateRotationX(rotate.X) * 43: Matrix.CreateRotationY(rotate.Y) * 44: Matrix.CreateTranslation(position); 45: } 46: // 伸縮がある場合 47: else 48: { 49: // ワールド 50: effect.World = transforms[mesh.ParentBone.Index] * 51: Matrix.CreateScale(scale) * 52: Matrix.CreateRotationZ(rotate.Z) * 53: Matrix.CreateRotationX(rotate.X) * 54: Matrix.CreateRotationY(rotate.Y) * 55: Matrix.CreateTranslation(position); 56: } 57: // 透過 58: if (alphaOn == true) 59: { 60: effect.Alpha = alpha; 61: } 62: else 63: { 64: effect.Alpha = 1; 65: } 66: } 67: mesh.Draw(); 68: } 69: } |
| １． | ボーンの個数分変換行列を用意。(19～20行) |
| ２． | モデル内のメッシュの個数分のループを行い、各メッシュを描画する。(23行) |
| ２－１． | メッシュ内のエフェクトの個数分のループを行い、メッシュ内の各エフェクトに対して設定を行う。(26行) |
| ２－２． | ターゲットとなるエフェクト情報に座標変換情報[視点行列]、[射影行列](この二つは前回説明したカメラ等の情報)を設定し、更に現在のモデルの座標情 報や回転情報、縮尺情報を掛け合せて[ワールド行列]を作成して、これをエフェクト情報に設定します。(透過情報もこの際、エフェクト情報に設定します) (29～65行) |
| ２－３． | メッシュを描画。(67行) |
| ３． | メッシュ情報を全て描画するまで「２．」を繰り返す。 |
という流れとなります。
モデル情報の描画と言いつつも色々な用語が出てきたので、私なりの解釈で説明すると、以下のような感じでしょうか…
【ボーン】
モデル全体に存在する骨組となります。これはアニメーション情報に用いる情報となり、例えば人体のモデルを作成したとした場合、体に1本の軸(ボーン)が入っており、それを基準に5方向に頭、両腕、両足の各ボーンが設定され、それらが別々にアニメーションをする場合などに用いる…というイメージが大まかな掴みという感じでしょうか。
今回Metasequoiaでモデルを作成しているので、プラグイン等を用いない場合はXファイル上、ボーン情報は生成されていないのですが、XNAのファイル読み込みにてデフォルトで2つを与えられている感じです。
【メッシュ】
1モデル情報となります。モデル情報にはポリゴンという用語に代表される、頂点情報(Vertex)、頂点を3角形に構成した情報(Index)や、エフェクト情報が格納されています。
モデルには複数メッシュが格納されるイメージですが(例えば体、頭、腕、足、洋服等)、これは仕様なのか私には不明なのですが、Metasequoia(フリーウェア版)ではモデルをXファイルに出力すると、メッシュは1つのみとなる模様です。
【エフェクト】
ポリゴンの描画や、そのレンダリングの際に必要となる座標変換情報や効果(シェーディング)情報となります。このサンプルでは、メッシュ生成時にXNAが自動的に作成してくれるBasicEffectクラスがエフェクトとして生成されているので、これを用いて必要な情報を設定します。この情報を任意に変化させることで、ライティングやシェーディングの処理を自在に変化させることができます。描画の真髄はこのクラスにあるという感じです。
また、このエフェクトクラスは自前で作成することができ、そのクラスにHLSL(High Level Shader Language)という言語で記述した「エフェクトファイル」というものをXNAのプロジェクトに設定して、これをアセットとして読み込むことができ、PCに搭載されているグラフィックボードのシェーディング機能を使用する…といった事が可能となります。
【ワールド座標変換について】
40行, 50行にてeffect.Worldというエフェクトクラス内のメンバに座標変換を行っていますが、これはローカル座標系をワールド座標系に座標変換を行っています。
計算の細かい説明は詳しい説明のあるサイトにて調べてもらうとして、一般的にはこのような、「親ボーン×縮尺×回転」の行列をMatrix.CreateTranslationで平行移動させる…というのがお作法という感じです。
回転行列の掛け方が、Z→X→Yの順序とアルファベット的とは違うのですが、これはかけ算の順序で回転マトリックスが変化するので、表現をしたい様に掛け合わせるようになります。
(将来回転して飛んでいく弾等を検討したいので、とりあえずサンプルではこのように回すことにします)
◇ ◇ ◇
これで、ついにモデルの描画が行えました。
サンプルソースを見ると分かるとおり、「頂点同士の座標に線を引く、3頂点をポリゴンとして内部を塗る、光の加減で塗った面に明暗を付ける」などを今回のソースコード上では一切行っていません。
このように「かなり難かしいところはとりあえず隠蔽」が行え、「もしも深く操作したい場合は言語的な派生などを行い、拡張ができる」という設計が実現されている事は、XNAフレームワークの素晴らしさであると感じます。(とは行っても、○○○ツクール程、容易ではありませんが…)
昔のゲームの想い出 [0029] 「サラダの国のトマト姫」 [ハドソン] [1984] [MB-S1]
《マツ マツ マツ マツ… …！？》
サラダの国のトマト姫は、ファミリーコンピュータにも移植された有名なアドベンチャーゲームです。
主人公であるキュウリ戦士を主観として、カボチャ大王からトマト姫を救出する、コマンド入力タイプのゲームとなります。
多数のPC版がリリースしている中、私は友人が持っていた日立製PCである、MB-S1でこのゲームをプレーしました。(割とマイナーなPCって感じですね(^^;)
そして後、FM-7上でもプレーした感じです。
「友人の家にお邪魔してプレーをさせてもらった」ということもあって、私の中では時間制限があった感が強く、ストーリーよりもクリアを重視した攻略をしていた想い出があります。このため私の中では、本ゲームはシナリオよりも、部分部分で目立ったグラフィックやフィーチャーが色濃く記憶に残り、あまりシナリオを覚えていません。「斜めの線を多様した遠近法で表現されているゲーム」という印象が強いです。
この時代のアドベンチャーゲームのコマンド入力は英単語入力方式か、カタカナ入力方式を取るケースが非常に多く(ファミリーコンピュータの場合はコマンド選択方式です)、どのようなコマンドが入力できるかは、マニュアルに記述されているケースと殆ど無いケースがあり、後者の場合はかなり直感的に入力を行わなければなりませんでした。本ゲームはある程度前者に近ったハズなのですが、それでも単語の入力が大変だった想い出があります。
英単語入力方式の場合などは大抵「動詞+主語(V+S)」でコマンドを入力していました(カタカナの場合は逆に「主語+動詞(S+V)」で入力できました)が、本ゲームではカタカナ入力ができたので「モモ タベル」のような、「英単語をあまり知らなくても、なんとかコマンドの入力」が行えました。しかしながら、それでも画面毎に「これ置けるのかなぁ～？」等と友人と四苦八苦しては、着々と近付く夕飯の時間(笑)にドキドキしながら、画面を攻略していったものです。(この流れを数日間繰り返しました。常に夕飯になったらBye-Byeでした)
そして数日後、このゲームの鬼門「ナスの番兵」の所に到着したのですが、現在インターネットで検索しても、やはりここがプレイ上のボトルネックとなった方が多いようで、私達もここの難関に見事ハマりました…(というかあんちょこ無しでアソコをクリアできる人の感性が凄いと思いますが…)
とにかく何がヒドイかと言うと、「マツ」というコマンドを入力しても画面には通常通り「マッテモ ムダ(←表現失念！)」のような、人にコマンド入力を諦めさせるようなメッセージが表示されるということで、これが何か違う反応でもしてくれれば、「おっ？もう一回やってみる？」みたいな流れになると思うのですが、このように「ある意味、プレイヤーを騙す」というような流れにしてくれたのは、今でもヒドイ仕様と思っています。
(しかもこの無味乾燥な入力を何回も行うと、この場所を突破できるなんて…)
結局この日は全く進捗がないまま、友人宅の夕飯の時間が来てしまい、諦めて自宅に帰宅したという悔しい思いをしました。
更に数日後、友人が雑誌か何かを見て調べてきて、「あそこは何回も『マツ』と入力すると、ナスが寝るんだよ！」と聴いて卒倒しました。
そしてその後、友人宅に行きプレーをすると… 「な、なんとナスが寝た！( °O °)」
もう…感動とかいうよりも、絶句に近かったのを覚えています。
この仕様が無ければ私の中ではかなり良作なアドベンチャーゲームになっているのですが、このせいで「佳作」というレッテルが私の中で生れてしまった「残念なゲーム…」ということになっています。
ただ、フォローという訳ではないのですが、トマト姫のスタイルがやけにエロいので、これはこれでアリとは思います。(とか言ってみたり(^^;)
サラダの国のトマト姫は、ファミリーコンピュータにも移植された有名なアドベンチャーゲームです。
主人公であるキュウリ戦士を主観として、カボチャ大王からトマト姫を救出する、コマンド入力タイプのゲームとなります。
多数のPC版がリリースしている中、私は友人が持っていた日立製PCである、MB-S1でこのゲームをプレーしました。(割とマイナーなPCって感じですね(^^;)
そして後、FM-7上でもプレーした感じです。
「友人の家にお邪魔してプレーをさせてもらった」ということもあって、私の中では時間制限があった感が強く、ストーリーよりもクリアを重視した攻略をしていた想い出があります。このため私の中では、本ゲームはシナリオよりも、部分部分で目立ったグラフィックやフィーチャーが色濃く記憶に残り、あまりシナリオを覚えていません。「斜めの線を多様した遠近法で表現されているゲーム」という印象が強いです。
この時代のアドベンチャーゲームのコマンド入力は英単語入力方式か、カタカナ入力方式を取るケースが非常に多く(ファミリーコンピュータの場合はコマンド選択方式です)、どのようなコマンドが入力できるかは、マニュアルに記述されているケースと殆ど無いケースがあり、後者の場合はかなり直感的に入力を行わなければなりませんでした。本ゲームはある程度前者に近ったハズなのですが、それでも単語の入力が大変だった想い出があります。
英単語入力方式の場合などは大抵「動詞+主語(V+S)」でコマンドを入力していました(カタカナの場合は逆に「主語+動詞(S+V)」で入力できました)が、本ゲームではカタカナ入力ができたので「モモ タベル」のような、「英単語をあまり知らなくても、なんとかコマンドの入力」が行えました。しかしながら、それでも画面毎に「これ置けるのかなぁ～？」等と友人と四苦八苦しては、着々と近付く夕飯の時間(笑)にドキドキしながら、画面を攻略していったものです。(この流れを数日間繰り返しました。常に夕飯になったらBye-Byeでした)
そして数日後、このゲームの鬼門「ナスの番兵」の所に到着したのですが、現在インターネットで検索しても、やはりここがプレイ上のボトルネックとなった方が多いようで、私達もここの難関に見事ハマりました…(というかあんちょこ無しでアソコをクリアできる人の感性が凄いと思いますが…)
とにかく何がヒドイかと言うと、「マツ」というコマンドを入力しても画面には通常通り「マッテモ ムダ(←表現失念！)」のような、人にコマンド入力を諦めさせるようなメッセージが表示されるということで、これが何か違う反応でもしてくれれば、「おっ？もう一回やってみる？」みたいな流れになると思うのですが、このように「ある意味、プレイヤーを騙す」というような流れにしてくれたのは、今でもヒドイ仕様と思っています。
(しかもこの無味乾燥な入力を何回も行うと、この場所を突破できるなんて…)
結局この日は全く進捗がないまま、友人宅の夕飯の時間が来てしまい、諦めて自宅に帰宅したという悔しい思いをしました。
更に数日後、友人が雑誌か何かを見て調べてきて、「あそこは何回も『マツ』と入力すると、ナスが寝るんだよ！」と聴いて卒倒しました。
そしてその後、友人宅に行きプレーをすると… 「な、なんとナスが寝た！( °O °)」
もう…感動とかいうよりも、絶句に近かったのを覚えています。
この仕様が無ければ私の中ではかなり良作なアドベンチャーゲームになっているのですが、このせいで「佳作」というレッテルが私の中で生れてしまった「残念なゲーム…」ということになっています。
ただ、フォローという訳ではないのですが、トマト姫のスタイルがやけにエロいので、これはこれでアリとは思います。(とか言ってみたり(^^;)
Sample Action Gameの紹介 [ステージ16]
今回はステージ16の紹介です。このステージは今迄のステージにて重要なアイテムを入手していた場合、本ゲームの大きな分岐点となるステージになります。
それではウォークスルーしていきたいと思います。
【ステージ開始マップ】
屋上が徐々に近づいてきました。
【スタート地点】
橋の上に来ました。
前面からそうなのですが、プログラム的なこだわりで背景が2重スクロールしています。また、月が常に画面に固定されています。
「何かワンポイントあるといいかな？」と思い、そう実装しました。
【ブルーナイト登場】
橋を進んでいると、上空からブルーナイトが出現します。
ブルーナイトは自機のように上下に攻撃をしてきて、且つ盾でこちらの攻撃を防いだりします。
また、ランダムのタイミングでジャンプをしてきます。
攻撃速度が速いので、かなりダメージを受けやすいのですが、うまく間合を取れば強敵ではありません。
尚、自機と同様に攻撃中は防御をしていないので、攻撃が行えます。
また、足元が留守になっているので、足元を攻撃する感じで戦うと良いでしょう。
【鍵の取得】
ブルーナイトを倒すと鍵が出現します。
【出口の扉】
アイテムが揃っている場合、扉を開けるといつもと違うメッセージが表示されます。
「スタート地点を調べろ」とのこと。
【メガネを覗く】
出口の扉が二つ映っています。そのうち上の方が禁止となっています。
【スタート地点】
スタート地点に戻ると、雲が現れます。
【ライフゲージの上限枠】
雲に乗って上まで行くとこれみよがしにライフゲージの上限枠のアイテムが浮いています。
現状では取れないので、左に進みましょう。
【ブルーナイト登場】
雲を移っていくと長い雲の上に来ます。そして、その先でブルーナイトが上空から出現します。
攻略法は先程倒したブルーナイトと同様なのですが、ステージが固定されるため間合が取り辛くなっています。
【新たな鍵】
ブルーナイトと倒すと、新たな鍵が出現します。それと同時にメッセージが表示されます。
「橋の下に新たなルートが出現」 こ、これは…
【宝箱】
宝箱ではないですが、ブルーナイトを倒すとライフゲージの上限枠が入手できます。
このハートは今迄と違い、ハートの周りに白い縁取りが付いています。
このハートはライフゲージの上限枠が2つ上ります。
【橋に戻る】
雲を降りると、橋が壊れています。
恐れずに飛び降りましょう。
【橋の下】
橋の下には雲があり、着地できます。左に進んで行きましょう。
2体のブルーナイトを相手していると体力がギリギリになっているかもしれません。
落下して体力を奪われないように慎重に移動しましょう。
【真の扉】
橋の下にステージクリアの扉がありました。
◇ ◇ ◇
本ステージクリアにて、ゲームの中盤が終了した感じとなり、このステージの分岐でゲームの展開が大きく変化します。
もしも上の扉を進んでもゲームの進行は普通に行えますが、本ゲームを堪能する場合は下の扉を選択するのが良いかと思います。
尚、上の扉を選択するとゲームがNGになるということではありません。
(ただし、今後のプレーによりエンディングがバッドエンディングに変化しやすくなる場合があります)
また、腕に自信がある方は、短時間で本ゲームをクリアするのに上の扉を選択するということもできます。
(ただし、かなり腕に自信がある方のみオススメします)
次回のステージ紹介は、下の扉を選択したルートの紹介を行います。
それではウォークスルーしていきたいと思います。
【ステージ開始マップ】
屋上が徐々に近づいてきました。
【スタート地点】
橋の上に来ました。
前面からそうなのですが、プログラム的なこだわりで背景が2重スクロールしています。また、月が常に画面に固定されています。
「何かワンポイントあるといいかな？」と思い、そう実装しました。
【ブルーナイト登場】
橋を進んでいると、上空からブルーナイトが出現します。
ブルーナイトは自機のように上下に攻撃をしてきて、且つ盾でこちらの攻撃を防いだりします。
また、ランダムのタイミングでジャンプをしてきます。
攻撃速度が速いので、かなりダメージを受けやすいのですが、うまく間合を取れば強敵ではありません。
尚、自機と同様に攻撃中は防御をしていないので、攻撃が行えます。
また、足元が留守になっているので、足元を攻撃する感じで戦うと良いでしょう。
【鍵の取得】
ブルーナイトを倒すと鍵が出現します。
【出口の扉】
アイテムが揃っている場合、扉を開けるといつもと違うメッセージが表示されます。
「スタート地点を調べろ」とのこと。
【メガネを覗く】
出口の扉が二つ映っています。そのうち上の方が禁止となっています。
【スタート地点】
スタート地点に戻ると、雲が現れます。
【ライフゲージの上限枠】
雲に乗って上まで行くとこれみよがしにライフゲージの上限枠のアイテムが浮いています。
現状では取れないので、左に進みましょう。
【ブルーナイト登場】
雲を移っていくと長い雲の上に来ます。そして、その先でブルーナイトが上空から出現します。
攻略法は先程倒したブルーナイトと同様なのですが、ステージが固定されるため間合が取り辛くなっています。
【新たな鍵】
ブルーナイトと倒すと、新たな鍵が出現します。それと同時にメッセージが表示されます。
「橋の下に新たなルートが出現」 こ、これは…
【宝箱】
宝箱ではないですが、ブルーナイトを倒すとライフゲージの上限枠が入手できます。
このハートは今迄と違い、ハートの周りに白い縁取りが付いています。
このハートはライフゲージの上限枠が2つ上ります。
【橋に戻る】
雲を降りると、橋が壊れています。
恐れずに飛び降りましょう。
【橋の下】
橋の下には雲があり、着地できます。左に進んで行きましょう。
2体のブルーナイトを相手していると体力がギリギリになっているかもしれません。
落下して体力を奪われないように慎重に移動しましょう。
【真の扉】
橋の下にステージクリアの扉がありました。
◇ ◇ ◇
本ステージクリアにて、ゲームの中盤が終了した感じとなり、このステージの分岐でゲームの展開が大きく変化します。
もしも上の扉を進んでもゲームの進行は普通に行えますが、本ゲームを堪能する場合は下の扉を選択するのが良いかと思います。
尚、上の扉を選択するとゲームがNGになるということではありません。
(ただし、今後のプレーによりエンディングがバッドエンディングに変化しやすくなる場合があります)
また、腕に自信がある方は、短時間で本ゲームをクリアするのに上の扉を選択するということもできます。
(ただし、かなり腕に自信がある方のみオススメします)
次回のステージ紹介は、下の扉を選択したルートの紹介を行います。
必要なツールの開発 (その2)
XNAにてプログラムを開発する際に複数人数で開発を行う場合、Visual C#の場合はMicrosoftのソフトウェアということもあり、Visual Source Safeを使うのが一般的ですが、今回の開発のように可能な限りフリーウェアで開発を行う場合はSubversionのようなフリーウェアのソース管理を用いるケースがあります。
この場合、ソースやリポジトリ情報をインターネット上のサーバーに置いておき、ネット環境さえあればどこからでもアクセスが行え、ソースの修正もどこからも可能となります。
このように便利なソース管理ソフトですが、ソースのバックアップを「このソフトの管理情報を除いて保管しておきたい…」となった場合、管理ソフト用のディレクトリがプロジェクト内のディレクトリ全てに作成され、それが深い階層の部分にも沢山できてしまう…ということになります。
(特にSubversionのようなソフトウェアの場合、更新履歴を保管するので、管理ディレクトリ内のサイズが膨大になります)
Subversionの場合は「svn export」でファイルを持ってくれば良いのですが、たまにリポジトリの管理情報ごと持ってこられて、「えぇ～。管理情報が各ディレクトリの下にできちゃってるよ～」となったりした事があります。
その場合はバッチファイルでこの情報等を削除したいのですが、以下の条件をSubversionのケースを例に取って考えてみると、バッチファイルで実現すると結構大変になります。
１．あるディレクトリ以下の階層下にある"*.svn"のディレクトリを削除する。
２．「１．」に該当したディレクトリの階層下のファイル、ディレクトリは"*.svn"に関係無く
全てのファイル、ディレクトリを削除する。
DELコマンドや、cygwin等を導入して、rmコマンドを導入しても、この表現を1行で行なえるようなバッチ(またはシェル)の記述は結構大変と思ったので(特に指定のディレクトリのワイルドカード以下を全てというのが)、「無ければ自分色で作る」といういつもの精神と、ついでにC#のお勉強という意味(←こっちの方が意味合いは強い)で、コマンドを作ってみました。
その名も、
「DelEx.exe」
とても安易なネーミングですｗ
使い方はDELコマンドに近い感じで作ってみました。
DelEx /?
にて使用法が表示されます。
使用例は以下のような感じでバッチコマンドに記述して、ファイルの削除を行います。
◇ ◇ ◇
本当はもっと良い削除方法があるとは思ったのですが、「プログラミング学習になるのなら、それもまた良し」ということと、サクッと作れるのであれば、「自作した方が楽しい」ということで作成しました。
ファイルの削除を行うAPIを実行するプログラミングというのは一歩間違えると悲惨なことになりかねないので、緊張感があってとても楽しいです(^^;
(UNIXで管理者権限のある人がパンチミスでルートディレクトリから再帰削除を実行するという、ありがちなミスを行ったというのは良く聴く話ですね)
とりあえずXFileTrimPath同様にソースは公開しますが、コンパイルは御自分でお願いするとともに、実行に関する責任は一切負わないものとさせていただきます。
【ソースファイル】
2008.03.14 DelEx.zip
この場合、ソースやリポジトリ情報をインターネット上のサーバーに置いておき、ネット環境さえあればどこからでもアクセスが行え、ソースの修正もどこからも可能となります。
このように便利なソース管理ソフトですが、ソースのバックアップを「このソフトの管理情報を除いて保管しておきたい…」となった場合、管理ソフト用のディレクトリがプロジェクト内のディレクトリ全てに作成され、それが深い階層の部分にも沢山できてしまう…ということになります。
(特にSubversionのようなソフトウェアの場合、更新履歴を保管するので、管理ディレクトリ内のサイズが膨大になります)
Subversionの場合は「svn export」でファイルを持ってくれば良いのですが、たまにリポジトリの管理情報ごと持ってこられて、「えぇ～。管理情報が各ディレクトリの下にできちゃってるよ～」となったりした事があります。
その場合はバッチファイルでこの情報等を削除したいのですが、以下の条件をSubversionのケースを例に取って考えてみると、バッチファイルで実現すると結構大変になります。
１．あるディレクトリ以下の階層下にある"*.svn"のディレクトリを削除する。
２．「１．」に該当したディレクトリの階層下のファイル、ディレクトリは"*.svn"に関係無く
全てのファイル、ディレクトリを削除する。
DELコマンドや、cygwin等を導入して、rmコマンドを導入しても、この表現を1行で行なえるようなバッチ(またはシェル)の記述は結構大変と思ったので(特に指定のディレクトリのワイルドカード以下を全てというのが)、「無ければ自分色で作る」といういつもの精神と、ついでにC#のお勉強という意味(←こっちの方が意味合いは強い)で、コマンドを作ってみました。
その名も、
「DelEx.exe」
とても安易なネーミングですｗ
使い方はDELコマンドに近い感じで作ってみました。
DelEx /?
にて使用法が表示されます。
| [DelEx] ファイルを削除します。 DelEx [/S] [/Q] [/F] [/L] ファイル名 /S 指定のファイルのパスから下の階層も検索対象とします。 /Q ファイルを削除するときにメッセージを表示しません。 /F エラーが発生しても無視して強制的に処理を行います。 /L 削除するファイル一覧を表示します。(削除は行いません) |
使用例は以下のような感じでバッチコマンドに記述して、ファイルの削除を行います。
| rem Gears下のSubversion情報を削除します DelEx.exe /S /Q Gears\*.svn |
◇ ◇ ◇
本当はもっと良い削除方法があるとは思ったのですが、「プログラミング学習になるのなら、それもまた良し」ということと、サクッと作れるのであれば、「自作した方が楽しい」ということで作成しました。
ファイルの削除を行うAPIを実行するプログラミングというのは一歩間違えると悲惨なことになりかねないので、緊張感があってとても楽しいです(^^;
(UNIXで管理者権限のある人がパンチミスでルートディレクトリから再帰削除を実行するという、ありがちなミスを行ったというのは良く聴く話ですね)
とりあえずXFileTrimPath同様にソースは公開しますが、コンパイルは御自分でお願いするとともに、実行に関する責任は一切負わないものとさせていただきます。
【ソースファイル】
2008.03.14 DelEx.zip
昔のゲームの想い出 [0028] 「バルトリック」 [ジャレコ] [1986] [アーケード]
《超難易度シューティング！》
バルトリックは、ショットとジャンプ使用してステージの最後にいるボスを倒す、面クリアタイプのシューティングゲームです。
ジャンプとあるように、自機は地面を移動する丸い戦車のような機体で、障害物となる壁の間を縫うように移動していきます。
スクロールは一方向のみで、自機の移動により上から下にスクロールします。
このゲームは洒落にならない程難易度が高いゲームで、私はゲームセンターで稼働している時は全4ステージ中、4ステージの中盤辺りでゲームオーバーになっていました。
このゲームは「覚えゲーというよりも運ゲーなのでは？」と思う程の難易度なので、当時は「今日はこのゲームにn百円使ったら止めよう」というような区切を自分に敷かないと、みるみるウチにお金が飲みこまれる感じでした。
また、当時の私のポリシーには「ゲームセンターのゲームはコンティニューをして先を見てはいけない。1コインクリアが硬派」のようなものがあり、このゲームにソレを適用すると、大抵4面辺りで、精も根も尽き果てる…という感じでした。
そして、最後には基板を購入して、かなりやりこんで、なんとかクリアをした…という程のシューティングゲームです。(現在はまたクリアができなくなった腕前です…)
しかし、この高難易度のゲームには基板を購入までさせる程の魅力があったのは事実で、私の中のフェイバリットシューティングゲーム(笑)の一つとなっています。
私的にこのゲームの魅力を考えると以下のようなものがあるようです。
[無機質と有機質的なステージ構成]
この頃のジャレコのシューティングゲームは、UPLがリリースしているゲームのような配色を持っており、アーガスに並んで本ゲームはメタリック感のあるキャラクタと有機的な背景(緑や乾燥した地面等)で表現をしています。今、見てもかなり綺麗と思います。
[派手なパワーアップ]
難易度が高いこのゲームですが、パワーアップはかなり派手になります。オプションとして自機に付けることができるポッドが2つあり、これからビームが発射されて3方向にレーザーが撃つことができ、且つこのレーザーが最高段階になると画面は自機のレーザーで一杯になります。
[滑らかなアニメーション]
スプライトキャラクターにはかなりの枚数を使用しており、自機や敵の弾、ホーミングミサイルのアニメーションパターンがものすごく滑らかです。
この時代、敵の弾のアニメーションは殆ど無いものが多い中、このゲームの敵弾はクルクルと3Dのように回り、且つ「影」がついています。
またホーミングミサイルから逃げ回っている時に、フラフラと付いてくるこの様のアニメーションは「まるで生きている」かのようでした。
[いい味だしている中ボス]
各ステージの中盤に中ボスが出てくるのですが、これらがいい味を出しています。とてもセンスがいいです。
正直、これらがステージラストのボスでも十分通用します。
と、高難易度の事を除けば、このゲームは2D表現の中、全てにおいて「質感」を持ち、プログラマーから見れば「丁寧、丁重に作られている」と思えます。
個人的にはこの質感の素晴らしさは「ブランド」をイメージさせてくれるゲームと感じ、比喩を用いれば、「2Dの動くフィギュアを持つ」とさえ思えます。
◇ ◇ ◇
このゲームの高難易度の原因は、「自機が遅い」ということが挙げられます。
後半のステージ、もしくはステージ進行をもたもたしていると、敵弾は速くなり、しかも永久パターン防止キャラとして、ホーミングミサイルを放つ敵が出現し、これの速度が自機の移動と同じかそれ以上となるという超難易度の展開となります。ホーミングミサイルが自機の移動と同じ速度で、しかも障害物を乗りこえる機能を持つので、自然と距離は縮み、上でも述べたように、ケツにピッタリと張りつき、逃げ回る展開となります。こうなると、もうジャンプをして軌道を変えるしか方法は無く、ジャンプが無ければ、ステージをそのまま逃げ続けながら進むしかありえない状況となり、後を振り向いて撃墜しようものなら、滑らかに後を向くアニメーションの最中に爆破されてしまいます。
このゲームは自機のスピード調整さえ良ければ、難易度が急激に下ったと思っています。
◇ ◇ ◇
と、このように超難易度でありながら魅力のあるバルトリックは後の弾幕ゲームとは違った難易度を持ち、「センスの良い」、「質感のある」、「丁寧な作り」から、ブランドとして持っていたいと思わせたくなるシューティングゲームなので、私の中では「それほど有名では無いけど、是非ともおさえておきたいシューティング」として思い入れがあります。
音源チップはコレです。
…20年振りに見て、「おぉ、コレだったのか～」という新しい発見。
当時は「FM音源だな」ということは分かっていましたが、あんまり気にしてなかったなぁ。
バルトリックは、ショットとジャンプ使用してステージの最後にいるボスを倒す、面クリアタイプのシューティングゲームです。
ジャンプとあるように、自機は地面を移動する丸い戦車のような機体で、障害物となる壁の間を縫うように移動していきます。
スクロールは一方向のみで、自機の移動により上から下にスクロールします。
このゲームは洒落にならない程難易度が高いゲームで、私はゲームセンターで稼働している時は全4ステージ中、4ステージの中盤辺りでゲームオーバーになっていました。
このゲームは「覚えゲーというよりも運ゲーなのでは？」と思う程の難易度なので、当時は「今日はこのゲームにn百円使ったら止めよう」というような区切を自分に敷かないと、みるみるウチにお金が飲みこまれる感じでした。
また、当時の私のポリシーには「ゲームセンターのゲームはコンティニューをして先を見てはいけない。1コインクリアが硬派」のようなものがあり、このゲームにソレを適用すると、大抵4面辺りで、精も根も尽き果てる…という感じでした。
そして、最後には基板を購入して、かなりやりこんで、なんとかクリアをした…という程のシューティングゲームです。(現在はまたクリアができなくなった腕前です…)
しかし、この高難易度のゲームには基板を購入までさせる程の魅力があったのは事実で、私の中のフェイバリットシューティングゲーム(笑)の一つとなっています。
私的にこのゲームの魅力を考えると以下のようなものがあるようです。
[無機質と有機質的なステージ構成]
この頃のジャレコのシューティングゲームは、UPLがリリースしているゲームのような配色を持っており、アーガスに並んで本ゲームはメタリック感のあるキャラクタと有機的な背景(緑や乾燥した地面等)で表現をしています。今、見てもかなり綺麗と思います。
[派手なパワーアップ]
難易度が高いこのゲームですが、パワーアップはかなり派手になります。オプションとして自機に付けることができるポッドが2つあり、これからビームが発射されて3方向にレーザーが撃つことができ、且つこのレーザーが最高段階になると画面は自機のレーザーで一杯になります。
[滑らかなアニメーション]
スプライトキャラクターにはかなりの枚数を使用しており、自機や敵の弾、ホーミングミサイルのアニメーションパターンがものすごく滑らかです。
この時代、敵の弾のアニメーションは殆ど無いものが多い中、このゲームの敵弾はクルクルと3Dのように回り、且つ「影」がついています。
またホーミングミサイルから逃げ回っている時に、フラフラと付いてくるこの様のアニメーションは「まるで生きている」かのようでした。
[いい味だしている中ボス]
各ステージの中盤に中ボスが出てくるのですが、これらがいい味を出しています。とてもセンスがいいです。
正直、これらがステージラストのボスでも十分通用します。
と、高難易度の事を除けば、このゲームは2D表現の中、全てにおいて「質感」を持ち、プログラマーから見れば「丁寧、丁重に作られている」と思えます。
個人的にはこの質感の素晴らしさは「ブランド」をイメージさせてくれるゲームと感じ、比喩を用いれば、「2Dの動くフィギュアを持つ」とさえ思えます。
◇ ◇ ◇
このゲームの高難易度の原因は、「自機が遅い」ということが挙げられます。
後半のステージ、もしくはステージ進行をもたもたしていると、敵弾は速くなり、しかも永久パターン防止キャラとして、ホーミングミサイルを放つ敵が出現し、これの速度が自機の移動と同じかそれ以上となるという超難易度の展開となります。ホーミングミサイルが自機の移動と同じ速度で、しかも障害物を乗りこえる機能を持つので、自然と距離は縮み、上でも述べたように、ケツにピッタリと張りつき、逃げ回る展開となります。こうなると、もうジャンプをして軌道を変えるしか方法は無く、ジャンプが無ければ、ステージをそのまま逃げ続けながら進むしかありえない状況となり、後を振り向いて撃墜しようものなら、滑らかに後を向くアニメーションの最中に爆破されてしまいます。
このゲームは自機のスピード調整さえ良ければ、難易度が急激に下ったと思っています。
◇ ◇ ◇
と、このように超難易度でありながら魅力のあるバルトリックは後の弾幕ゲームとは違った難易度を持ち、「センスの良い」、「質感のある」、「丁寧な作り」から、ブランドとして持っていたいと思わせたくなるシューティングゲームなので、私の中では「それほど有名では無いけど、是非ともおさえておきたいシューティング」として思い入れがあります。
音源チップはコレです。
…20年振りに見て、「おぉ、コレだったのか～」という新しい発見。
当時は「FM音源だな」ということは分かっていましたが、あんまり気にしてなかったなぁ。
XNAにおける3Dゲーム描画設計 (描画に対してまず最初に理解すること)
3/8にてモデル情報の設定が行われたので、次はいよいよ描画です。ちなみに、スプライト情報の方も今後検討したいと思います。
…と思ったのですが、画面にモデルを描画をするには先に知っておくことがありました…(^^;
さて、1/7にてXNAのフレームワークでは描画イベントはGame.Draw関数ということを説明しましたが、描画を行うためにはモデル情報の他に理解しておくこと、また検討することがあります。
【座標系について】
「サンプルソース(2008.02.29.zip)」では説明もなくモデルファイルのサンプルを挙げましたが、このモデルファイルはMetasequoiaにて作成しており、且つXファイル形式と出力する際、一般的に「右手座標系」と呼ばれている座標系にて保存しています。
この図ではMetasequoiaのXファイル形式に保存する際は、座標軸を「Direct3D」としています。これは右手座標系を表わします。
(ついでに保存サイズを1.0の等倍としています。こうしないと座標情報が縮小された位置の考えとなってしまうためです)
XNAの世界ではこの右手座標系をアーキテクチャとしているので、必ずこの座標系で処理を行う必要があります。
【座標変換情報】
描画を行うには3D空間の座標を2Dであるディスプレイの座標に変換を行う必要があり、この変換を行わないとモデルの情報を画面に出力できません。
座標変換を行うために必要な情報には「ワールド行列」「ビュー行列」「投影行列」というものが必要で、この○○行列という情報はXNAではMatrixクラスにて実現が行えるようになっています。
また、この座標変換情報以外にも、奥行のフェードアウト情報となる「フォグ情報」等もありますが、ここではシンプルに上述の内容のみを使って行きたいと思います。
(ここでは余談なのですが、XNAは殆んどDirect3Dのラッパーに近いので、レンダリングの追求を行えば、Level of Detailやスプライトの深度バッファ等の高次元の3D描画の情報等を操作することが可能のようです。私は使ったことありませんが…)
まずはこのような事項があることを理解しておきます。上述の詳細はインターネットでキーワード検索すると、幾らでも情報が入手できると思うので、XNAで描画を行うにはまずはこのことを理解しておけば良いかと思います。
◇ ◇ ◇
次に検討しておくことですが、3D空間の表現には奥行があったりするので、座標変換のために座標変換情報を最初に決めておく必要があります。
これら情報はゲーム実行中に任意に変更は可能ですが、まず最初にどのような空間にどのように表示するというのは必ず必要となるので、この座標変換について検討したいと思います。
「サンプルソース(2008.02.29.zip)」では、これら情報はDrawManagerクラスに格納されており、それぞれ「ワールド行列(m_world)」「ビュー行列(m_camera)」「投影行列(m_projection)」)となっています。(ビューがm_cameraなのは一般的にこのビューをカメラに準えているからです(^^;)
初期化タイミングはゲームのインスタンスが生成された直前に、Globalクラスの初期化時(Initialize関数内)にて、DrawManager.SetCoodinate関数を呼び出して、これら座標変換情報の設定を行なっています。
[視点行列]
Matrix.CreateLookAt関数にて、第1引数にてカメラを置く座標、第2引数にてカメラの見ている先の座標、第3引数は一般的な作法として設定しています。
カメラは中心から前方左上辺りに置き(座標:1000, 1000, 500)、オブジェクト(Player)の映っている所がカメラの先(座標:0, 0, 0)となっています。
[射影行列]
Matrix.CreatePerspectiveFieldOfView関数にて、第1引数にて視野角、第2引数にてアスペクト比、第3引数にてニアクリップ面の距離、第4引数にてファークリップ面の距離を設定しています。
視野角はカメラから見た画面の広がりとなり、角度が広がると画面に映すものが広がります。ここでは奥行を表すために45度にしています。
XNAでは角度を表す単位はラジアンとなります。XNAのMathHelper.ToRadians関数を用いると角度からラジアンに変換できます。オーバーヘッドはどの程度かは不明ですが…
アスペクト比は殆どお作法として設定しています。画面の幅÷高さが一般的と言われています。ここではSetCoodinate関数の引数で渡ってくる、ゲーム画面のサイズを基に演算しています。この情報はゲームのインスタンスが生成される際に取得が行えます。
ニアクリップ、ファークリップは奥行を表現する前後の領域となります。これは奥の描画をどこからどこまでにするかという情報です。奥行が必要であれば、ファークリップを大きな値にします。
[ワールド行列]
これについては次回の描画の際に説明します。
◇ ◇ ◇
今回はかなりの文章量となってしまいましたが、サンプルソースを基に、「まぁ、このようなことをしているんだな」程度に汲み取ってもらえればと思います。
ポイントは視点行列のカメラの座標のみといった所でしょうか…
次回はこれら座標変換情報を用いてモデルの描画(今度こそ画面に描画？)について説明したいと思います。
…と思ったのですが、画面にモデルを描画をするには先に知っておくことがありました…(^^;
さて、1/7にてXNAのフレームワークでは描画イベントはGame.Draw関数ということを説明しましたが、描画を行うためにはモデル情報の他に理解しておくこと、また検討することがあります。
【座標系について】
「サンプルソース(2008.02.29.zip)」では説明もなくモデルファイルのサンプルを挙げましたが、このモデルファイルはMetasequoiaにて作成しており、且つXファイル形式と出力する際、一般的に「右手座標系」と呼ばれている座標系にて保存しています。
この図ではMetasequoiaのXファイル形式に保存する際は、座標軸を「Direct3D」としています。これは右手座標系を表わします。
(ついでに保存サイズを1.0の等倍としています。こうしないと座標情報が縮小された位置の考えとなってしまうためです)
XNAの世界ではこの右手座標系をアーキテクチャとしているので、必ずこの座標系で処理を行う必要があります。
【座標変換情報】
描画を行うには3D空間の座標を2Dであるディスプレイの座標に変換を行う必要があり、この変換を行わないとモデルの情報を画面に出力できません。
座標変換を行うために必要な情報には「ワールド行列」「ビュー行列」「投影行列」というものが必要で、この○○行列という情報はXNAではMatrixクラスにて実現が行えるようになっています。
また、この座標変換情報以外にも、奥行のフェードアウト情報となる「フォグ情報」等もありますが、ここではシンプルに上述の内容のみを使って行きたいと思います。
(ここでは余談なのですが、XNAは殆んどDirect3Dのラッパーに近いので、レンダリングの追求を行えば、Level of Detailやスプライトの深度バッファ等の高次元の3D描画の情報等を操作することが可能のようです。私は使ったことありませんが…)
まずはこのような事項があることを理解しておきます。上述の詳細はインターネットでキーワード検索すると、幾らでも情報が入手できると思うので、XNAで描画を行うにはまずはこのことを理解しておけば良いかと思います。
◇ ◇ ◇
次に検討しておくことですが、3D空間の表現には奥行があったりするので、座標変換のために座標変換情報を最初に決めておく必要があります。
これら情報はゲーム実行中に任意に変更は可能ですが、まず最初にどのような空間にどのように表示するというのは必ず必要となるので、この座標変換について検討したいと思います。
「サンプルソース(2008.02.29.zip)」では、これら情報はDrawManagerクラスに格納されており、それぞれ「ワールド行列(m_world)」「ビュー行列(m_camera)」「投影行列(m_projection)」)となっています。(ビューがm_cameraなのは一般的にこのビューをカメラに準えているからです(^^;)
初期化タイミングはゲームのインスタンスが生成された直前に、Globalクラスの初期化時(Initialize関数内)にて、DrawManager.SetCoodinate関数を呼び出して、これら座標変換情報の設定を行なっています。
[視点行列]
Matrix.CreateLookAt関数にて、第1引数にてカメラを置く座標、第2引数にてカメラの見ている先の座標、第3引数は一般的な作法として設定しています。
カメラは中心から前方左上辺りに置き(座標:1000, 1000, 500)、オブジェクト(Player)の映っている所がカメラの先(座標:0, 0, 0)となっています。
[射影行列]
Matrix.CreatePerspectiveFieldOfView関数にて、第1引数にて視野角、第2引数にてアスペクト比、第3引数にてニアクリップ面の距離、第4引数にてファークリップ面の距離を設定しています。
視野角はカメラから見た画面の広がりとなり、角度が広がると画面に映すものが広がります。ここでは奥行を表すために45度にしています。
XNAでは角度を表す単位はラジアンとなります。XNAのMathHelper.ToRadians関数を用いると角度からラジアンに変換できます。オーバーヘッドはどの程度かは不明ですが…
アスペクト比は殆どお作法として設定しています。画面の幅÷高さが一般的と言われています。ここではSetCoodinate関数の引数で渡ってくる、ゲーム画面のサイズを基に演算しています。この情報はゲームのインスタンスが生成される際に取得が行えます。
ニアクリップ、ファークリップは奥行を表現する前後の領域となります。これは奥の描画をどこからどこまでにするかという情報です。奥行が必要であれば、ファークリップを大きな値にします。
[ワールド行列]
これについては次回の描画の際に説明します。
◇ ◇ ◇
今回はかなりの文章量となってしまいましたが、サンプルソースを基に、「まぁ、このようなことをしているんだな」程度に汲み取ってもらえればと思います。
ポイントは視点行列のカメラの座標のみといった所でしょうか…
次回はこれら座標変換情報を用いてモデルの描画(今度こそ画面に描画？)について説明したいと思います。
昔のゲームの想い出 [0027] 「セクターゾーン」 [日本物産] [1984] [アーケード]
《ペトラ人！》
セクターゾーンは強制的なスクロールの中、SFチックなバイクに乗りながら障害物を避け、仲間であるペトラ人を救出しながら、ステージを進めるシューティングゲームとなります。
このゲームは移植作である、ファミリーコンピュータ版の「セクロス」の方がかなり知られているようで、某巨大掲示板では少しエッチなキーワードとして良く見かけますｗ
私がこのゲームをゲームセンターで見かけたときは、「なんとも滑らかな奥行を表現しているゲームなんだろう」という印象でした。
手前の方は高速にスクロールし、奥の方は手前よりはゆっくりという遠近法に近い表現でスクロールをしていました。しかもこのゲームはスクリーンが縦だったので、この表現は更に効果的に見えたものです。
今考えるとただのラスタースクロールなのですが、このような横スクロールを行いながらの滑らかな遠近法というのは、このゲームと後発のマグマックス(こちらも日本物産)が走りだったような気がします(走りと言っても、この手のシューティングでここまで滑らかなのは他にあったかなぁ…とも思います)。
またこの時代のゲームのラスタースクロールは、ハードウェア的にスプライトとBGを分離して行っていることもあり、ラスタスクロールで自機が歪んだりしません。もしもプレイステーション等でこれを移植するとなると、ソフトウェアで行なわないとならない分、結構実現が大変のような気がします。
ファミリーコンピュータ版は「ゲーム性としての移植」は十分合格点とは思うのですが、「表現」という点は私的には不足しており、友人がコレを持ってきてプレーした時にはかなり違和感がありました。
１．外見のウリである、ラスタスクロールが行われない。
(ただの横スクロール)
２．発色数が少ない為に、ゲーム全体が軽く見える。
(自機やバイクに数色使用されており、このグラデーションがいい質感を出しています)
３．横に潰れて見える。
(家庭用テレビなので仕方がない)
これらはハードウェア的な問題で実現が苦しいのは分るのですが、コレら要素が欠けただけで「あー、やっぱりファミコンだなぁ～」という印象が強かったものです。
このように、移植に関してゲーム性は問題なく移植されているのに、大事な表現を落してしまうだけで、かなりの劣化を感じてしまうのは残念に感じてしまったものです。
しかし、難易度はファミリーコンピュータの方がうまく調整されていた気がします。特に目の前で破壊した敵の残骸で死ぬアーケード版に比べて(ある意味、最強の打ち返し)、ファミリーコンピュータの方は、このフィーチャーが無いので、プレーとしてはこちらの方がプレーしやすかった気がします。
個人的にはアーケードの方の難易度はバランスがちょっと…という感じで、正直「高速で動くバーニンラバー」をプレーしていた感じでした。
そして、サブタイトルにもあるペトラ人ですが、インストラクションカードに「ペトラ人」と書いてあって、友人と「なんだこのペトラ人ってｗ どっからついた名前なんだ？」と、ネーミングと名前の響きでなんか笑っていました。(いや、悪いという訳ではないんですが、なんか…(^^ゞ)
セクターゾーンは強制的なスクロールの中、SFチックなバイクに乗りながら障害物を避け、仲間であるペトラ人を救出しながら、ステージを進めるシューティングゲームとなります。
このゲームは移植作である、ファミリーコンピュータ版の「セクロス」の方がかなり知られているようで、某巨大掲示板では少しエッチなキーワードとして良く見かけますｗ
私がこのゲームをゲームセンターで見かけたときは、「なんとも滑らかな奥行を表現しているゲームなんだろう」という印象でした。
手前の方は高速にスクロールし、奥の方は手前よりはゆっくりという遠近法に近い表現でスクロールをしていました。しかもこのゲームはスクリーンが縦だったので、この表現は更に効果的に見えたものです。
今考えるとただのラスタースクロールなのですが、このような横スクロールを行いながらの滑らかな遠近法というのは、このゲームと後発のマグマックス(こちらも日本物産)が走りだったような気がします(走りと言っても、この手のシューティングでここまで滑らかなのは他にあったかなぁ…とも思います)。
またこの時代のゲームのラスタースクロールは、ハードウェア的にスプライトとBGを分離して行っていることもあり、ラスタスクロールで自機が歪んだりしません。もしもプレイステーション等でこれを移植するとなると、ソフトウェアで行なわないとならない分、結構実現が大変のような気がします。
ファミリーコンピュータ版は「ゲーム性としての移植」は十分合格点とは思うのですが、「表現」という点は私的には不足しており、友人がコレを持ってきてプレーした時にはかなり違和感がありました。
１．外見のウリである、ラスタスクロールが行われない。
(ただの横スクロール)
２．発色数が少ない為に、ゲーム全体が軽く見える。
(自機やバイクに数色使用されており、このグラデーションがいい質感を出しています)
３．横に潰れて見える。
(家庭用テレビなので仕方がない)
これらはハードウェア的な問題で実現が苦しいのは分るのですが、コレら要素が欠けただけで「あー、やっぱりファミコンだなぁ～」という印象が強かったものです。
このように、移植に関してゲーム性は問題なく移植されているのに、大事な表現を落してしまうだけで、かなりの劣化を感じてしまうのは残念に感じてしまったものです。
しかし、難易度はファミリーコンピュータの方がうまく調整されていた気がします。特に目の前で破壊した敵の残骸で死ぬアーケード版に比べて(ある意味、最強の打ち返し)、ファミリーコンピュータの方は、このフィーチャーが無いので、プレーとしてはこちらの方がプレーしやすかった気がします。
個人的にはアーケードの方の難易度はバランスがちょっと…という感じで、正直「高速で動くバーニンラバー」をプレーしていた感じでした。
そして、サブタイトルにもあるペトラ人ですが、インストラクションカードに「ペトラ人」と書いてあって、友人と「なんだこのペトラ人ってｗ どっからついた名前なんだ？」と、ネーミングと名前の響きでなんか笑っていました。(いや、悪いという訳ではないんですが、なんか…(^^ゞ)
Sample Action Gameの紹介 [ステージ15]
今回はステージ15の紹介です。このステージはジャンプアクションをメインとしたステージとなります。
それではウォークスルーしていきたいと思います。
【ステージ開始マップ】
城の外に出てきました。
【浮遊する床を移動】
このステージは城の吹き抜けを上って行くステージとなります。
最初は右から浮遊する床が来るので、これに乗って右側に行きます。
【2段目】
次は床が消滅する場所を渡って行きます。出現したらテンポ良く渡って行きましょう。
【3段目】
次も床が消滅する場所ですが、更にこの床は下に落ちて行きます。
そして、この段は斜め上のフロアに上る必要があるので、難易度も2段目より上っています。
この段は右下に6マス分のライフが回復するポーションが置いてあります。
これを取る場合は一旦消滅する床を左に戻る必要がありますが、焦らずに戻って行きましょう。
【4段目】
長い床の上に乗るとコウモリが出現します。
そして、コウモリを撃退すると上に上る床が出現します。コウモリは1撃で倒せる青と、3撃で倒せる赤が出現します。
出現する床は徐々に速度が上るので、タイミングを合せて上に上ってください。
【ローパー】
吹き抜けの屋上に来ると、床からローパーが出現します。ローパーはランダムに上と下にファイアボールを発射してくるので、それに合せて防御をします。
ある程度攻撃をしてきたら間があくので、それに合わせて攻撃を行います。
自機とローパーとの距離があまり開いていると、ローパーが地面に潜ってしまい、攻撃ができなくなるので、なるべくローパーとの距離を近づけて防御を行ってください。
【宝箱出現方法の確認】
至極簡単ですね。
【宝箱】
宝箱からはガントレットが出現します。
このアイテムを入手すると自機の攻撃スピードがアップします。
前面からそうなのですが、プログラム的なこだわりとして、装備により自機の外見が変化するようにしています。また残機表示のアイコンもこれに伴い変化するようになっています。
◇ ◇ ◇
徐々に自機の外見的な装備が揃ってきました。
アイテム入手枠の方も最初に入手したベルが枠から消える位、充実してきました。
それではウォークスルーしていきたいと思います。
【ステージ開始マップ】
城の外に出てきました。
【浮遊する床を移動】
このステージは城の吹き抜けを上って行くステージとなります。
最初は右から浮遊する床が来るので、これに乗って右側に行きます。
【2段目】
次は床が消滅する場所を渡って行きます。出現したらテンポ良く渡って行きましょう。
【3段目】
次も床が消滅する場所ですが、更にこの床は下に落ちて行きます。
そして、この段は斜め上のフロアに上る必要があるので、難易度も2段目より上っています。
この段は右下に6マス分のライフが回復するポーションが置いてあります。
これを取る場合は一旦消滅する床を左に戻る必要がありますが、焦らずに戻って行きましょう。
【4段目】
長い床の上に乗るとコウモリが出現します。
そして、コウモリを撃退すると上に上る床が出現します。コウモリは1撃で倒せる青と、3撃で倒せる赤が出現します。
出現する床は徐々に速度が上るので、タイミングを合せて上に上ってください。
【ローパー】
吹き抜けの屋上に来ると、床からローパーが出現します。ローパーはランダムに上と下にファイアボールを発射してくるので、それに合せて防御をします。
ある程度攻撃をしてきたら間があくので、それに合わせて攻撃を行います。
自機とローパーとの距離があまり開いていると、ローパーが地面に潜ってしまい、攻撃ができなくなるので、なるべくローパーとの距離を近づけて防御を行ってください。
【宝箱出現方法の確認】
至極簡単ですね。
【宝箱】
宝箱からはガントレットが出現します。
このアイテムを入手すると自機の攻撃スピードがアップします。
前面からそうなのですが、プログラム的なこだわりとして、装備により自機の外見が変化するようにしています。また残機表示のアイコンもこれに伴い変化するようになっています。
◇ ◇ ◇
徐々に自機の外見的な装備が揃ってきました。
アイテム入手枠の方も最初に入手したベルが枠から消える位、充実してきました。
昔のゲームの想い出 [0026] 「クレイジーバルーン」 [タイトー] [1980] [アーケード]
《顔がっ！》
クレイジーバルーンは、風船をスタート地点からゴールまで移動させる面クリタイプのゲームです。
ステージは針のようなもので構成されており、これに触れるとアウトといったシンプルなものとなります。
初めてこのゲームを見たのは、80年代に私が通っていたゲームセンターが開店した時で、誰もプレーしていなくて効果音だけが鳴っていた…という想い出があります。
しかしいざプレーしてみてもBGM は鳴らずにそのまま始まり、レバーもなく、4方向のボタンのみで移動するといった、シンプルな操作だったので、直感的にプレーが出きました。
一回の押下でホンの少しだけ進むので(画面はシンプルな8ドット矩形の針で構成されているので、当時のPCゲームみたいにキャラクターが8ドット単位で進むように見えるのですが、風船は滑らかに1ドット単位で進みます)、1面は少しづつ押しながら結構時間をかけながらも、とりあえずクリア…という感じで進めました。
そして2面に入り、更に難易度が高いステージになり、ここも慎重に操作…と思っていたら、針に触れたのか、イキナリ
「パシュ！」
と風船が割れ、かなり驚きました。(°д°)
このゲームはBGMも無い上に、割れ易い風船を慎重に動かすので、イキナリ割れるとかなり心臓に悪いゲームです。
昔、バラエティ番組で「イライラ棒」というのがありましたが、触れたらイカン！のノリはこっちの方が私的には元祖…という感じです。
そして、難易度の高くなってくるステージに対して更に慎重に進み始めた訳ですが、あんまりノンビリと移動していると画面の端に「少年の顔」が出現します。
これが出た瞬間「ん？」となったのですが、それと同時に思いっきり自機に向って息を吹き掛けて来ました。しかもこれがかなりの風圧で、殆ど制御不能な状態で針向っていき、「パシュ！」とアウトになりました…
そして風船が割れた瞬間に、この少年は「ゲラゲラ」と「かなり表情豊かな笑い」をしてきました。
このフィーチャーにあまりに驚き、家に帰ってからすぐに隣に住む幼馴染に会い、「クレイジーバルーンってゲームが凄い！ 急に顔が出てきて、凄い勢いで息を吹きかけてきて、風船が割れて、笑われた！」と、ゲームを知らない人が聴いたら、なにがなんだか分らないようなトークを必至に喋っていて、結局「何んだそりゃ？」と小馬鹿にされた想い出があります。
◇ ◇ ◇
このような至極シンプルなゲームでも、一つインパクトのあるフィーチャーがあると、ゲームの表現がものすごく良くなる(印象強くなる)事というのは、そのゲームのウリとなるのだと思いました。
クレイジーバルーンは、風船をスタート地点からゴールまで移動させる面クリタイプのゲームです。
ステージは針のようなもので構成されており、これに触れるとアウトといったシンプルなものとなります。
初めてこのゲームを見たのは、80年代に私が通っていたゲームセンターが開店した時で、誰もプレーしていなくて効果音だけが鳴っていた…という想い出があります。
しかしいざプレーしてみてもBGM は鳴らずにそのまま始まり、レバーもなく、4方向のボタンのみで移動するといった、シンプルな操作だったので、直感的にプレーが出きました。
一回の押下でホンの少しだけ進むので(画面はシンプルな8ドット矩形の針で構成されているので、当時のPCゲームみたいにキャラクターが8ドット単位で進むように見えるのですが、風船は滑らかに1ドット単位で進みます)、1面は少しづつ押しながら結構時間をかけながらも、とりあえずクリア…という感じで進めました。
そして2面に入り、更に難易度が高いステージになり、ここも慎重に操作…と思っていたら、針に触れたのか、イキナリ
「パシュ！」
と風船が割れ、かなり驚きました。(°д°)
このゲームはBGMも無い上に、割れ易い風船を慎重に動かすので、イキナリ割れるとかなり心臓に悪いゲームです。
昔、バラエティ番組で「イライラ棒」というのがありましたが、触れたらイカン！のノリはこっちの方が私的には元祖…という感じです。
そして、難易度の高くなってくるステージに対して更に慎重に進み始めた訳ですが、あんまりノンビリと移動していると画面の端に「少年の顔」が出現します。
これが出た瞬間「ん？」となったのですが、それと同時に思いっきり自機に向って息を吹き掛けて来ました。しかもこれがかなりの風圧で、殆ど制御不能な状態で針向っていき、「パシュ！」とアウトになりました…
そして風船が割れた瞬間に、この少年は「ゲラゲラ」と「かなり表情豊かな笑い」をしてきました。
このフィーチャーにあまりに驚き、家に帰ってからすぐに隣に住む幼馴染に会い、「クレイジーバルーンってゲームが凄い！ 急に顔が出てきて、凄い勢いで息を吹きかけてきて、風船が割れて、笑われた！」と、ゲームを知らない人が聴いたら、なにがなんだか分らないようなトークを必至に喋っていて、結局「何んだそりゃ？」と小馬鹿にされた想い出があります。
◇ ◇ ◇
このような至極シンプルなゲームでも、一つインパクトのあるフィーチャーがあると、ゲームの表現がものすごく良くなる(印象強くなる)事というのは、そのゲームのウリとなるのだと思いました。
XNAにおける3Dゲーム描画設計 (モデルファイルを読み込む)
3/4に引き続き、Modelクラスにモデル情報を読み込む処理を説明します。
前回はモデルファイルをVisual C#のソリューションエクスプローラに登録して、これにアセット名をつけるところまでを説明しました。
XNAではこの登録したモデルファイルをXNAのクラス、ContentManagerクラスを用いて読み込むことができます。
ContentManagerクラスはXNAのウィザードにてゲームのインスタンスクラス(Microsoft.Xna.Framework.Game)から派生したクラスのコンストラクト時に生成されます。
そして、このクラスのLoad関数を用いるとモデル情報が取得できるようになります。
Load関数の引数には登録したアセット名を指定し、戻り値としてモデル情報であるModelクラスを返します。
サンプルソース (2008.02.29.zip)では、ゲームのインスタンスクラスにあるContentManagerクラスに毎回アクセスするのではなく、このContentManagerクラスを内包したstaticクラス、ModelToolを用意して、これにLoadModel関数というのを実装しています。ModelToolクラスはプログラム開始時に初期化として、ContentManagerクラスを設定して、その後からプログラム内のツールとしてモデルの操作を提供するポリシーを持ちます。
(GlobalクラスのInitialize関数内で初期化を行っています)
そして、このツールクラスを用いた実現は、ModelCharacterTaskクラスから派生したPlayerTaskクラスがModelTool.Load関数を呼び出して、モデル情報の読み込みを行っています。
前回と今回の説明により、モデルの情報をプログラム上に読み込むことが出来ました。次回はモデルの描画について説明をしたいと思います。
前回はモデルファイルをVisual C#のソリューションエクスプローラに登録して、これにアセット名をつけるところまでを説明しました。
XNAではこの登録したモデルファイルをXNAのクラス、ContentManagerクラスを用いて読み込むことができます。
ContentManagerクラスはXNAのウィザードにてゲームのインスタンスクラス(Microsoft.Xna.Framework.Game)から派生したクラスのコンストラクト時に生成されます。
そして、このクラスのLoad関数を用いるとモデル情報が取得できるようになります。
Load関数の引数には登録したアセット名を指定し、戻り値としてモデル情報であるModelクラスを返します。
サンプルソース (2008.02.29.zip)では、ゲームのインスタンスクラスにあるContentManagerクラスに毎回アクセスするのではなく、このContentManagerクラスを内包したstaticクラス、ModelToolを用意して、これにLoadModel関数というのを実装しています。ModelToolクラスはプログラム開始時に初期化として、ContentManagerクラスを設定して、その後からプログラム内のツールとしてモデルの操作を提供するポリシーを持ちます。
(GlobalクラスのInitialize関数内で初期化を行っています)
そして、このツールクラスを用いた実現は、ModelCharacterTaskクラスから派生したPlayerTaskクラスがModelTool.Load関数を呼び出して、モデル情報の読み込みを行っています。
前回と今回の説明により、モデルの情報をプログラム上に読み込むことが出来ました。次回はモデルの描画について説明をしたいと思います。
昔のゲームの想い出 [0025] 「メトロイド」 [任天堂] [1986] [ファミリーコンピュータ]
《最高峰のスペースオペラ！》
メトロイドプライム3コラプションの日本版が発売されたということで、「週末にでも買ってこなきゃ」と思いつつ、今回の想い出はこのゲームにしたいと思います。ちなみに「スペースオペラ」という単語は、このゲームをゲーム雑誌が紹介していた文面に使っていて初めて知りました。(^^;
メトロイドプライム3コラプションの日本版が発売されたということで、「週末にでも買ってこなきゃ」と思いつつ、今回の想い出はこのゲームにしたいと思います。ちなみに「スペースオペラ」という単語は、このゲームをゲーム雑誌が紹介していた文面に使っていて初めて知りました。(^^;
Sample Action Gameの紹介 [ステージ14]
今回はステージ14の紹介です。このステージより中盤戦の後半辺りに入る感じとなります。
それではウォークスルーしていきたいと思います。
【ステージ開始マップ】
前のステージから少し上りました。
【顔の石像の攻撃】
このステージは今迄オブジェとして表示されていた、顔の石像からファイアボールが大量に発射されます。このファイアボールは盾で受けるか、剣で攻撃すると破壊できます。
フロアーの各段には三種類のスライムがウロついています。自機を追いかけてくるもの、気まぐれなものがいるので注意しましょう。
ここで始めて出現するスカイブルースライムはジャンプしてきます。
【宝箱出現方法の確認】
ジャンプしているスカイブルースライムと自機が映っています。
【宝箱】
宝箱からは黄金色のブーツが出現します。
このブーツを入手すると、以下のメッセージが表示されます。
こ、これは…
◇ ◇ ◇
このステージのアイテムの効果は、重要な効果となります。是非とも入手してください。
それではウォークスルーしていきたいと思います。
【ステージ開始マップ】
前のステージから少し上りました。
【顔の石像の攻撃】
このステージは今迄オブジェとして表示されていた、顔の石像からファイアボールが大量に発射されます。このファイアボールは盾で受けるか、剣で攻撃すると破壊できます。
フロアーの各段には三種類のスライムがウロついています。自機を追いかけてくるもの、気まぐれなものがいるので注意しましょう。
ここで始めて出現するスカイブルースライムはジャンプしてきます。
【宝箱出現方法の確認】
ジャンプしているスカイブルースライムと自機が映っています。
【宝箱】
宝箱からは黄金色のブーツが出現します。
このブーツを入手すると、以下のメッセージが表示されます。
こ、これは…
◇ ◇ ◇
このステージのアイテムの効果は、重要な効果となります。是非とも入手してください。
3Dアクションゲームにおける、ステージの空間構成とカメラワークについて
3Dタイプのアクションゲームを作り始めると、当然ながらカメラワークが必要になります。
現在はいい加減なカメラワークを実装してみて、どのように映るか確認したり、これを取り外してプレー感覚だけを調整してみたりと、色々と試行錯誤しているのですが、少くても一つだけ確実なのは、「フィールドが狭いとアクションゲームにはキツイ」ということです。
従来よりあるアクションゲームを一つとってみると分るのですが、自機と自機を追うカメラの間に壁や天井、場合により地面が入りこむと、画面は大抵以下のような処理となります。
(とりあえず自機とカメラの間に壁があったとします)
１．カメラがその壁よりも前に来る。
２．カメラが別の場所に移動する(壁を避ける)。これは横や上に移動する。
３．カメラはそのままの位置で、壁が半透明になり、透けて自機が見える。
大抵は柱などがこのような処理となります。
殆どのアクションゲームでは、大抵まず「１．」を実装し、ケースバイケースで「２．」や「３．」を実装する…ということが見受けられます。
この場合の「１．」は、「もっともと言えばもっとも」なのですが、この事を検討する際に以下の事象に遭遇します。
１．自機が壁に寄りすぎて、それによりカメラも壁の手前に補完され、自機にカメラが
寄ってしまい、画面が自機の背面のアップとなってしまい、ゲームプレー中に
何がなんだか分らなくなる。
(有名なゲームとしてはモンスターハンターがこのようになり、自機のアップが画面を
覆ってしまい、気がついたらプレイヤーがドラゴンに殺されている…ということが
あります)
２．「１．」の現象にて、自機の中にカメラが入りこんでしまい、自機の内部のモデルが
露呈してしまう。
(この例は何が良いかあまり思い浮びませんが、TOMB Raider 4等は記憶にあります。
顔の中の目玉とかが見えて不気味になります)
これらの事から、以下の空間構成や仕様を検討したいと考えています。(まだ未実装ですが…)
１．ステージは自機が動きまわりやすいように広くする。天井も高くする。
(カメラができるだけ寄らないように)
２－１．自機が壁に寄ってしまっても自機が壁に完全に寄れないようにする。
(自機とカメラの間合を持つ)
２－２．自機が壁に寄ってカメラが近づいた場合、自機を半透明、もしくは表示を
非表示にする。(自機の中身を映さない)
色々なゲームを見ると、どれも採用されている仕様ですが、これらを行わないとカメラが舞台の裏のハリボテならぬ、「見えてはいけない所を」映してしまったり、モデリングが壊れた自機を映しだすことになってしまいます。
とまぁ、簡単に理論を述べるのは簡単なのですが、これを実装するとなると結構厄介で、且つ理想的に表現できるかというとそうでもなく、これらはゲームの内容によりけりと言った感じになると思います。
現在はいい加減なカメラワークを実装してみて、どのように映るか確認したり、これを取り外してプレー感覚だけを調整してみたりと、色々と試行錯誤しているのですが、少くても一つだけ確実なのは、「フィールドが狭いとアクションゲームにはキツイ」ということです。
従来よりあるアクションゲームを一つとってみると分るのですが、自機と自機を追うカメラの間に壁や天井、場合により地面が入りこむと、画面は大抵以下のような処理となります。
(とりあえず自機とカメラの間に壁があったとします)
１．カメラがその壁よりも前に来る。
２．カメラが別の場所に移動する(壁を避ける)。これは横や上に移動する。
３．カメラはそのままの位置で、壁が半透明になり、透けて自機が見える。
大抵は柱などがこのような処理となります。
殆どのアクションゲームでは、大抵まず「１．」を実装し、ケースバイケースで「２．」や「３．」を実装する…ということが見受けられます。
この場合の「１．」は、「もっともと言えばもっとも」なのですが、この事を検討する際に以下の事象に遭遇します。
１．自機が壁に寄りすぎて、それによりカメラも壁の手前に補完され、自機にカメラが
寄ってしまい、画面が自機の背面のアップとなってしまい、ゲームプレー中に
何がなんだか分らなくなる。
(有名なゲームとしてはモンスターハンターがこのようになり、自機のアップが画面を
覆ってしまい、気がついたらプレイヤーがドラゴンに殺されている…ということが
あります)
２．「１．」の現象にて、自機の中にカメラが入りこんでしまい、自機の内部のモデルが
露呈してしまう。
(この例は何が良いかあまり思い浮びませんが、TOMB Raider 4等は記憶にあります。
顔の中の目玉とかが見えて不気味になります)
これらの事から、以下の空間構成や仕様を検討したいと考えています。(まだ未実装ですが…)
１．ステージは自機が動きまわりやすいように広くする。天井も高くする。
(カメラができるだけ寄らないように)
２－１．自機が壁に寄ってしまっても自機が壁に完全に寄れないようにする。
(自機とカメラの間合を持つ)
２－２．自機が壁に寄ってカメラが近づいた場合、自機を半透明、もしくは表示を
非表示にする。(自機の中身を映さない)
色々なゲームを見ると、どれも採用されている仕様ですが、これらを行わないとカメラが舞台の裏のハリボテならぬ、「見えてはいけない所を」映してしまったり、モデリングが壊れた自機を映しだすことになってしまいます。
とまぁ、簡単に理論を述べるのは簡単なのですが、これを実装するとなると結構厄介で、且つ理想的に表現できるかというとそうでもなく、これらはゲームの内容によりけりと言った感じになると思います。
 |  |  |
XNAにおける3Dゲーム描画設計 (Visual C#+XNAプロジェクトにモデルファイルを登録する)
2/29に引き続き、Modelクラスにモデル情報を登録する手順を説明します。
まずはモデルファイルを用意します。ここではXNAがサポートするXファイル(テキスト形式)を用意されたとして説明を進めていきます。
XファイルはMetasequoia等で作成することができます。
(2/29の説明で使用しているサンプルソース (2008.02.29.zip)では、"SampleGame\SampleGame\Model\Player.x"を例としています)
このモデルファイルを画面のソリューションエクスプローラーに登録します。モデルファイルはドラッグ&ドロップが可能で、任意の場所に登録が行えます。
注意としては、登録された後は、ソリューションエクスプローラー上でファイルに対して行う作業は、Windowsのエクスプローラーで行う作業と同等になるということです。
例えば、ファイル名の変更や登録の削除というのはファイルの変更であり、ファイルの削除を意味します。
以下の図(並びにサンプルソース)では、プロジェクトに"Model"というフォルダを作成し、この下に"Player.x"というモデルファイルを登録しました。
(赤い矩形の部分)
また、ソリューションエクスプローラーの下部に選択したファイルの情報が表示され、このモデルファイルを選択するとプロパティが表示されます。
モデルファイルの場合はこのモデルデータ(XNAでは「コンテンツ」といいます)に"アセット名"というものが設定され、プログラム内から参照する名前となります。
ドラッグ&ドロップにてモデルファイルを登録すると、拡張子が除かれたファイル名がアセット名になりす。
(青い矩形の部分)
プログラムからはモデルファイル名ではなく、アセット名を指定してモデルファイル情報を読み込みます。
プログラムからアセット名を参照する際はソリューションエクスプローラーのプロジェクトの位置がルートディレクトリとなり(この場合は"SampleGame")、その下にサブディレクトリがぶら下るというイメージとなります。
サンプルソースの例で見ると、"Player"のアセット名にアクセスするには"/Model/Player"というパス指定で指定することになります。
とりあえずまずはモデルの登録を行ってみました。
次はアセット名を用いてModelクラスにモデル情報を読み込むのですが、少し説明が長くなるので今回はここまでとします。
まずはモデルファイルを用意します。ここではXNAがサポートするXファイル(テキスト形式)を用意されたとして説明を進めていきます。
XファイルはMetasequoia等で作成することができます。
(2/29の説明で使用しているサンプルソース (2008.02.29.zip)では、"SampleGame\SampleGame\Model\Player.x"を例としています)
このモデルファイルを画面のソリューションエクスプローラーに登録します。モデルファイルはドラッグ&ドロップが可能で、任意の場所に登録が行えます。
注意としては、登録された後は、ソリューションエクスプローラー上でファイルに対して行う作業は、Windowsのエクスプローラーで行う作業と同等になるということです。
例えば、ファイル名の変更や登録の削除というのはファイルの変更であり、ファイルの削除を意味します。
以下の図(並びにサンプルソース)では、プロジェクトに"Model"というフォルダを作成し、この下に"Player.x"というモデルファイルを登録しました。
(赤い矩形の部分)
また、ソリューションエクスプローラーの下部に選択したファイルの情報が表示され、このモデルファイルを選択するとプロパティが表示されます。
モデルファイルの場合はこのモデルデータ(XNAでは「コンテンツ」といいます)に"アセット名"というものが設定され、プログラム内から参照する名前となります。
ドラッグ&ドロップにてモデルファイルを登録すると、拡張子が除かれたファイル名がアセット名になりす。
(青い矩形の部分)
プログラムからはモデルファイル名ではなく、アセット名を指定してモデルファイル情報を読み込みます。
プログラムからアセット名を参照する際はソリューションエクスプローラーのプロジェクトの位置がルートディレクトリとなり(この場合は"SampleGame")、その下にサブディレクトリがぶら下るというイメージとなります。
サンプルソースの例で見ると、"Player"のアセット名にアクセスするには"/Model/Player"というパス指定で指定することになります。
とりあえずまずはモデルの登録を行ってみました。
次はアセット名を用いてModelクラスにモデル情報を読み込むのですが、少し説明が長くなるので今回はここまでとします。
昔のゲームの想い出 [0024] 「ポケットザウルス 十王剣の謎」 [バンダイ] [1987] [ファミリーコンピュータ]
《トツゼンですが クイズの じかんです！》
最近、「悪魔城ドラキュラX クロニクル」のマリアのブーメラン鳩の攻撃を見ていたら、このゲームを思いだしました。
ポケットザウルス 十王剣の謎はプレイヤーである橋本名人(ハシモトザウルス)を操作して、現在・過去・未来を移動し、全ステージをクリアした後にサラマンダーを倒すといったアクションゲームとなります。
自機は連射可能なブーメランを使用して、敵を撃破します(少し違いますが、これが上述のマリアの攻撃っぽい感じです)。パワーアップするとブーメランの速度が上り、連射するとかなり軽快な攻撃になります(これが結構気持いいのです)。
私が初めてこのゲームを見たのは、いきつけのファミコンショップで後輩がこのゲームを「10分100円でプレー(昔はこういうファミコンショップが多かったですね)」していたところでした。
私の偏見では「この時代のバンダイのキャラクターゲームは、画面構成もゲームバランスも荒削りで正直名作が少ない…」となっているのですが、後輩がプレーしていたこのゲームを見ていたら、正直それがかなり払拭されました。例え画面構成がバンダイ特有の16x16のBGタイルパターンで構成でも…
このゲームの良いところは、
・ステージ構成が多彩(途中でシューティングとかもあります)
・フィーチャーが多彩
・ボス戦が個性的
といった事に加えて、更に上で述べたように自機の攻撃がかなりのカタルシスを持っているところが挙げられます。
正直ゲームバランスとかは、かなりいい加減と思うのですが、「なぜか、攻撃をしながら進んでいるだけで気持ちいい」のです。
シューティングゲームでコスりやピアノ撃ちで、驚異的な連射をしていると気持ちいいという感覚がありますが(私だけ？)、このポケットザウルスのブーメランがこれに近い感覚で、パワーアップした状態で敵に連続して打ち込んでいると撃破SE音も引き立って、かなりの気持ち良さがあります。
◇ ◇ ◇
そして、この日記のサブタイトルにもあるように、このゲームには子供向け(?)っぽい特殊なフィーチャーがあり、ステージを進んでいると、
「トツゼンですが クイズの じかんです！」
と本当に唐突に、しかもこのクイズというのは「そんなの普通分るか？」と思うようなものばかりが出題されます。しかし、ハズレても特にペナルティは無く、正解で得点が入るものなので、得点でライフが増えるこのゲームとしては、ついついこのクイズを解いてしまう感じでした。
しかし当時はこのフィーチャーを見て「開発の人はなんでこんなフィーチャーを用意したんだろ？子供向けなフィーチャーにしては、あんまり子供には分らないものが多いような…」という印象が強かったものです。
◇ ◇ ◇
結局、私は後輩のプレーに魅せられてしまい、その後日にこのゲームを購入することになりましたｗ
しかし、このゲームのタイトルでもある十王剣を使った攻略が分からず、結局は攻略本を買うことにまでなりました。
そこで最後の攻略法を見て「こ、こんなの分かるかー！しかもこの難易度でっ！」となり、本を手元に置きながらクリアをした…というなんか悔しい思いをした経験があります。
また、このゲームの妖界魔境ステージのある場所の画面切り替えにて、ゲームがハングアップするというバグがあり、当時これを発見した時は「凄くヒドイバグだなぁ～」と思っていたら、ファミリーコンピュータマガジンのウル技で披露されていて卒倒した事があります。
「深刻なバグ = 裏技」というコンバージョンがまかり通るということを認識させてもらった瞬間でした(^^;
最近、「悪魔城ドラキュラX クロニクル」のマリアのブーメラン鳩の攻撃を見ていたら、このゲームを思いだしました。
ポケットザウルス 十王剣の謎はプレイヤーである橋本名人(ハシモトザウルス)を操作して、現在・過去・未来を移動し、全ステージをクリアした後にサラマンダーを倒すといったアクションゲームとなります。
自機は連射可能なブーメランを使用して、敵を撃破します(少し違いますが、これが上述のマリアの攻撃っぽい感じです)。パワーアップするとブーメランの速度が上り、連射するとかなり軽快な攻撃になります(これが結構気持いいのです)。
私が初めてこのゲームを見たのは、いきつけのファミコンショップで後輩がこのゲームを「10分100円でプレー(昔はこういうファミコンショップが多かったですね)」していたところでした。
私の偏見では「この時代のバンダイのキャラクターゲームは、画面構成もゲームバランスも荒削りで正直名作が少ない…」となっているのですが、後輩がプレーしていたこのゲームを見ていたら、正直それがかなり払拭されました。例え画面構成がバンダイ特有の16x16のBGタイルパターンで構成でも…
このゲームの良いところは、
・ステージ構成が多彩(途中でシューティングとかもあります)
・フィーチャーが多彩
・ボス戦が個性的
といった事に加えて、更に上で述べたように自機の攻撃がかなりのカタルシスを持っているところが挙げられます。
正直ゲームバランスとかは、かなりいい加減と思うのですが、「なぜか、攻撃をしながら進んでいるだけで気持ちいい」のです。
シューティングゲームでコスりやピアノ撃ちで、驚異的な連射をしていると気持ちいいという感覚がありますが(私だけ？)、このポケットザウルスのブーメランがこれに近い感覚で、パワーアップした状態で敵に連続して打ち込んでいると撃破SE音も引き立って、かなりの気持ち良さがあります。
◇ ◇ ◇
そして、この日記のサブタイトルにもあるように、このゲームには子供向け(?)っぽい特殊なフィーチャーがあり、ステージを進んでいると、
「トツゼンですが クイズの じかんです！」
と本当に唐突に、しかもこのクイズというのは「そんなの普通分るか？」と思うようなものばかりが出題されます。しかし、ハズレても特にペナルティは無く、正解で得点が入るものなので、得点でライフが増えるこのゲームとしては、ついついこのクイズを解いてしまう感じでした。
しかし当時はこのフィーチャーを見て「開発の人はなんでこんなフィーチャーを用意したんだろ？子供向けなフィーチャーにしては、あんまり子供には分らないものが多いような…」という印象が強かったものです。
◇ ◇ ◇
結局、私は後輩のプレーに魅せられてしまい、その後日にこのゲームを購入することになりましたｗ
しかし、このゲームのタイトルでもある十王剣を使った攻略が分からず、結局は攻略本を買うことにまでなりました。
そこで最後の攻略法を見て「こ、こんなの分かるかー！しかもこの難易度でっ！」となり、本を手元に置きながらクリアをした…というなんか悔しい思いをした経験があります。
また、このゲームの妖界魔境ステージのある場所の画面切り替えにて、ゲームがハングアップするというバグがあり、当時これを発見した時は「凄くヒドイバグだなぁ～」と思っていたら、ファミリーコンピュータマガジンのウル技で披露されていて卒倒した事があります。
「深刻なバグ = 裏技」というコンバージョンがまかり通るということを認識させてもらった瞬間でした(^^;
Sample Action Gameの紹介 [ステージ13]
今回はステージ13の紹介です。このステージは中盤戦の中では高難易度となるステージとなり、瞬時の判断力を必要としますので、気合を入れてクリアする必要があります。
それではウォークスルーしていきたいと思います。
【ステージ開始マップ】
城の半分位の所まで来ました。
【ウィザード】
炎を操るウィザードが画面狭しと炎を地面から放出します。
炎は種火が付いて少ししたら一気に噴き上りますので、出現場所を確認したら、一気に安全となる場所に移動を行います。
この操作に瞬時の判断力が必要となります。
このステージは固定画面での戦闘となるので、画面の端にいるよりも画面中央を基準に左右に避けると比較的避け易いかもしれません。
(とはいっても炎の位置はランダムで攻撃をしてくるので、あくまで確率的な話ですが…)
ウィザードは浮いているので、真上にジャンプして攻撃します。横にジャンプして攻撃を行うと、炎を食らいやすいので、気をつけて攻撃してください。
ちなみに自機の横幅の当り判定は8ドットとなり、地面の灰色のブロックでいうとブロックの半分となるので、炎の合間を縫って避ける場合は参考に避けてください。
【宝箱出現方法の確認】
メガネを覗くと、凄い量の炎が見えます。炎に対して何かするということは想像できます。
何かをすると以下のようになってきます。以前のステージで炎に対して行ったことを思い出せば、出現は容易と思います。
しかし、敵の攻撃は容赦ないので、敵の撃破を優先すべきか悩むところです。
【宝箱】
宝箱からはライフゲージの上限枠が1つ上るアイテムが出現します。
もしも宝箱の出現をさせるのが大変の場合は、ステージクリアを優先するのも良いかもしれません。
【ウィザード撃破後…】
宝箱の上に雲(霧？)のようなものがかかっています。
自機をジャンプさせてもすり抜けてしまいますが、これは…
◇ ◇ ◇
最後に意味深なシーンがありますが、これは後に予想通り(?)の展開となりますので、まずはスルーしましょう。
それではウォークスルーしていきたいと思います。
【ステージ開始マップ】
城の半分位の所まで来ました。
【ウィザード】
炎を操るウィザードが画面狭しと炎を地面から放出します。
炎は種火が付いて少ししたら一気に噴き上りますので、出現場所を確認したら、一気に安全となる場所に移動を行います。
この操作に瞬時の判断力が必要となります。
このステージは固定画面での戦闘となるので、画面の端にいるよりも画面中央を基準に左右に避けると比較的避け易いかもしれません。
(とはいっても炎の位置はランダムで攻撃をしてくるので、あくまで確率的な話ですが…)
ウィザードは浮いているので、真上にジャンプして攻撃します。横にジャンプして攻撃を行うと、炎を食らいやすいので、気をつけて攻撃してください。
ちなみに自機の横幅の当り判定は8ドットとなり、地面の灰色のブロックでいうとブロックの半分となるので、炎の合間を縫って避ける場合は参考に避けてください。
【宝箱出現方法の確認】
メガネを覗くと、凄い量の炎が見えます。炎に対して何かするということは想像できます。
何かをすると以下のようになってきます。以前のステージで炎に対して行ったことを思い出せば、出現は容易と思います。
しかし、敵の攻撃は容赦ないので、敵の撃破を優先すべきか悩むところです。
【宝箱】
宝箱からはライフゲージの上限枠が1つ上るアイテムが出現します。
もしも宝箱の出現をさせるのが大変の場合は、ステージクリアを優先するのも良いかもしれません。
【ウィザード撃破後…】
宝箱の上に雲(霧？)のようなものがかかっています。
自機をジャンプさせてもすり抜けてしまいますが、これは…
◇ ◇ ◇
最後に意味深なシーンがありますが、これは後に予想通り(?)の展開となりますので、まずはスルーしましょう。
