top page



プロフィール

Yo./Namikaze Project

Namikaze Projectの萌え系プログラマ。ご意見などありましたら、記事にコメントあるいは、twitter(@yo_namikaze)、メール(yo@namikaze.org)にお願い致します。


開発環境など

C++, Blender, Unity, DirectX, Windows7

カレンダー

<   2015年1月   >
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

旧ブログへのリンク

Yo.'s Game Development Diary

購読(RSS)

Powered by Movable Type 5.2.9

2015年1月アーカイブ

[Idinaloq] 進捗 2015/01/25

| コメント(0) | トラックバック(0)

突然ですが、本日、モデリング&3Dムービー担当だったjpsさんから、うれしい情報がありました。ムービーの .lwo .lws、非圧縮のレンダリング済み .avi (640x480)が15年の時を経て発掘されました。これは...再レンダリングも可能ですね(にやり) 。一方、これはかれこれ1ヶ月前の情報ですが、小田せんせの2Dパートのオリジナルビットマップは失われていました(残念)

さて、本題。自機の移動を細かく実装していました。

通常、入力を得て、左右キー(PAD)ならばX座標を一定値変更、上下キーならばZ座標を一定値変更します。
サンプルプログラム等で、自機の速度の分、X座標、Z座標を変更するものをよく見かけます。(さらにフレームレートの考慮が無いものもあります) それらはそもそもサンプルなのでよいのですが、実際に遊んでみると、サンプルの実装では処理が不足していることに気づきます。
移動速度の設定が十分に遅い場合には問題は起きませんが、比較的速い速度を設定した場合、そのままでは敵の弾幕を回避するのが難しくなります。

自機の速度が例えば毎フレーム、比較的速い、ある一定量(ACC) 移動すると設定しているとします。フレームレートを考慮した移動量補正値をdeltaとします。イディナロークでは、60fpsを基準(delta = 1.f)として調整しています。移動、ビジュアルのタイミングなど、必ずこの delta を掛けてあげる必要がありますが、以降の話では省略して説明します。

先ほどのACCは、連続的に移動する場合には気になりませんが、旧イディナロークは、機体別に設定された固定的な移動量で移動しているので、敵の弾を避ける場合に、細かく避けることが出来ず、大雑把な回避しかできませんでした。今回は、ここを改善、パッド操作を細かく行うと細かく移動することを可能にして操作性を向上させようと思います。

実装方法は色々あるとは思いますが、自機の初期の移動量を細かい移動量に設定し、パッドを連続して押下するとぐっと移動量が増加(もたつきを感じない程度に増加)し、パッドを一瞬でも離すと移動量が初期値(細かい移動量)に戻るようにしました。押下が継続している間は移動量を増加させることで、押してから離した時間を移動量に還元できるようになり、細かい移動も、移動量を調整できるようになりました。これにより、細かいパッドさばきが可能になっていると思います。

また、クラスの整理は継続的に実施中です。今回は、入力を行うラッパクラスを作成しました。このクラスを使用すると、利用側がダウントリガで入力チェックすることを意識せず、こんな感じで、Unityぽく入力判定できるようになります。UnityのGetButtonDown等のパラメータは文字列ですけれどね。ちなみに何も考えずにキー入力にも対応。

if (g_Input.GetButton(kInputStateLeft) ==true) {
left = true;
}
else if (g_Input.GetButton(kInputStateRight) ==true) {
right = true;
}
if (g_Input.GetButton(kInputStateDown) ==true) {
dw = true;
}
else if (g_Input.GetButton(kInputStateUp) ==true) {
up = true;
}
if (g_Input.GetButtonDown(kInputState4) ==true) { // A
SetCameraMode(kiCameraModeNormal);
}
else if (g_Input.GetButtonDown(kInputState5) ==true) { // S
SetCameraMode(kiCameraModeSide);
}
else if (g_Input.GetButtonDown(kInputState6) ==true) { // D
SetCameraMode(kiCameraModeBack);
}

また、旧イディナロークは、斜め移動が高速になるようにしていますが、これは意図的にやっていました。 たしかレイストームも斜めが速かったと記憶しています。今回はあえて、上下左右斜め一定にしました。

以下は、前述の細かい移動を出来るようにしたムービーになります。

今回はこの辺で。

ではでは。



   

[Idinaloq] 進捗 2015/01/21

| コメント(0) | トラックバック(0)

自機の弾の実装など。

本題の前提となる話を。

今回も画像にて。加算ブレンディングをわかりやすくするために3面で。まだ今風の派手さは無いです。

ずっと後になると思いますが、旧版で実装できていなかった、自機や敵機のバーニア噴射をつけたりもする予定です。

20150121_1.png

誰もが最初に選ぶであろうセイレーンは、緑色の3方向弾が主兵装です。この弾は、発射後も、自機のX軸にあわせて弾が追従します。X軸追従タイプになっているので、重要な実装です。このような弾にする理由はですが、単に見た目の問題が1つと、横移動で自機が簡単に弾幕を作ることが出来てしまうのは問題なので、このような処置をしています。

一方、ウンディーネ(オレンジ色の機体)は火力最大の代わりに足を遅く設定していました。バランスをとるため、弾はX軸に追従しないようにしていたと思います。

さて、ここからが本題なのですが、この、「弾を自機のX軸に追従させる」をどのように実装するのか、というのが前回の悩みどころのポイントでした。オブジェクトの独立性を高めるにはどうすべきか、もう少し具体的に自分なりに考え方を書きます。

CGamePlayerBulletオブジェクトに対して、Notificationを行う、オブザーバークラス(言い方はさまざま。Notification CenterでもManagerクラスでも良いですが)を作成します。

CGamePlayerオブジェクトの変化をゲームオブザーバークラスにプレイヤー位置変更メッセージ(例えばkmsgNotificationPlayerPosChange)を通知(Notify)します。

オブザーバークラスは、管理下のオブジェクトに対し、Notififyメソッドを発行し、各オブジェクトは自オブジェクトが処理すべき通知に対する処理があればそれを行い、無ければ何も行いません。今回で言うと、通知を受け取ったCGamePlayerBulletクラスは、通知に従い、メッセージの詳細を見て、追従処理を行います。このメッセージの詳細は、CGamePlayerオブジェクトから通知された座標クラスオブジェクトです。

ゲームを管理するゲームオブザーバークラス(CGameObjectObserver)はゲームオブジェクト(基底クラス:CGameObject)全体のメッセージングを管理しているため、通知内容を判断し、Notify先のオブジェクトを変えても良いです。

このようにすれば、各オブジェクトはメッセージによって結合されているため、結合度が疎になります。

今の実装は、自機弾クラス(CGamePlayerBullet)に、参照オブジェクトのポインタを持たせて、勝手に座標を聞きまくりですw。旧版がこの方式で、そのほうが実装が直ぐに出来たので、今はそうなっていますが、この記事を書いていて、メッセージングを復活させようかと思いましたw

書き捨ててしまったので、svnのリポジトリに残っていません。こまめにお試しコードを入れては消しているので、gitとかにしたほうが良いんでしょうか。

今回はこの辺で。

ではでは。



   

[Idinaloq] 進捗 2015/01/19

| コメント(0) | トラックバック(0)

ステージ3の要塞部分の3D背景モデルの調整をしていました。一部の3D背景モデルは、モデル間の接続を良くする為に(恐らく)、接続部分が少し長めに出来ています。当時はこれでも問題にならなかったのですが(D3DRMの成せる技)、現在はそのまま表示させると、接続部分がチラチラしてしまいます。モデルを修正すれば良いのですが、ここは姑息にモデルを修正しないで解決。重なっている部分のポリゴンの上下関係をはっきりさせてやれば良いので、互い違いに、わからない程度にオブジェクトのy方向にサイズを微妙に変えます(おぃ)。元々y軸方向は見えて居ない部分があるので可能です。これで問題が出たら、今度こそはモデルを修正します。

内部処理では、クラス周りの整理を実施中。「Tell, Don't Ask」を積極的に実践するにあたり、メッセージングを管理するクラスを作って、オブジェクト間の独立性を高めよう...とか思っていたのですが、まずは自分の慣れた方法で組みやすく。手段が目的に変わってしまいそうだったので。その辺のプログラミングパラダイムについては、Scratchとかで実施ですね。(Scratchでほっぷぽっぷん(作りかけ)を参照)

自機の弾を加算ブレンディングにしてギラギラさせたり。この辺を効果的に見せるには、αチャネルを設定する必要がありますね。旧版には無かったものです。この辺は、最終的に見た目の調整を行う時にやろうと思います。

ところで、状態遷移にswitch~caseを多用しているのですが、関数が巨大化するので、どうしたものかなと思っていました。そこで、各状態の処理を基底クラスCGameTaskを継承してクラス化(例えば、CGameTaskLogo)、mapを使って、状態変数をキーにして各状態処理クラスを管理、各状態処理を実行する際には、findし、各クラスの特定のメソッド(例えばExec)をコールしてみました。動きはしますが、でも、これってmapじゃなくて配列でも良いですよねw mapにする利点は、状態数を気にする必要が無いということですが、状態が増えると、状態を追加する初期化関数が膨らむので、良し悪し。状態数は最終的には固定的になるはずなので、map化はやめました(←いまここ)。技術的には面白いですけれどね。今までは、1つのクラスの中に、状態別にメソッドを作っていたので、リッチC状態だったのですが、クラス化は行う方向で実装を進めています。

Unityで再開発しようとしていたものを、なぜWindowsネイティブに戻したのかという話。そしてなぜ今、C#を使わずに、C++なのか。Unityは、開発環境は素晴らしいですが、手間をかけずに、無料でオープニング、エンディングムービーの再生ができそうになかったことが大きいです。あと、起動時のUnityロゴ。ライセンスを購入すればよいのに、というのはナシで。15年前なら、きっとライセンスを購入していたと思いますが、今は、ライセンスを購入してバリバリ書くとなると、個人的にハードルが高そうだったのです。C++なのは、旧版のコードがC++であることに尽きます。結果的に殆ど再利用していなくて、フルスクラッチしているので、その選択が正しかったかどうかは怪しいですが、時既に遅し。マルチプラットフォームという選択肢を捨てたのは、自分がAndroid携帯やタブレットでゲームをしない事が挙げられます。いま携帯向けに作れば、多くの人の目に触れる機会が増えるとは思いますが、それを考える前に、まずはかなりのブランクがある自分のリハビリが先だろうと。Unity版とBlender Game Engine版を平行して書いていた位ですので、Windowsネイティブ環境で動かす事を最優先事項に置けば、そういう迷いは無くなるだろうw とまあ、色々思うところがあったのです。

これはおまけ。3面を横から見た画像です。

20150119_1.png

今回はこのへんで。

ではでは。



   

[Idinaloq] 進捗 2015/01/12

| コメント(0) | トラックバック(0)

細かい作業をしていました。CPUパワーを使いすぎているとノートン先生に叱られていました。どうも、FPS=60を上限にする処理を入れると、CPU負荷が上がりすぎるようです。以前の記事でも修正してあり、ループ中にProcessMessage的なものは入れていたんですけれどね...。調整をやめたら、CPU負荷がみるみる下がりました。うーん。懸念点があり、上限を固定する方向に倒したのですが、再度、調整しない方向に倒すことにします。

今回は、経験に基づく教訓など。
私が今も所属しているZOBplusで運営していた、今は無き草の根BBSのZOB Station BBSのボードproject.namikazeの、SIG(Special Interest Group)ともいいますが、そこでの開発の「ぬりぬりメルちゃん」(1995)、Artifex Associationでの開発の「ほっぷぽっぷん」(1997)の後、Namikaze Projectとして、新しいゲーム開発プロジェクトを考えていました。もともと「イディナローク」はproject.namikazeのRPG開発企画として会話を始めましたが、RPGを作るパワーが不足している事を認識し、企画は頓挫しました。紆余曲折あり、イディナロークは名前だけ残り、Namikaze Projectのタクティカル3Dシューティングゲームとして企画し、1997年4月には試作を開始していました。ほっぷぽっぷんのver.1.0が1997年9月だから、平行していたのですね。1997年4月の時点では、Direct3D(RM)を使ったフリーの3Dシューティングなどというものは発表されておらず、3Dの速度も満足なものではありませんでした。その後、かなり長い期間、裏でこそこそ作っていたのですが、1999/1月辺りから(多分)、作業は活発化。(記憶によれば)作品発表ペースの遅さに痺れを切らしたFerdiaがコミケ(C56)に向けた開発を提案、かくして、プロジェクトは加速。C56(夏コミ)では時間が不足していて2面までで、テクスチャ等もかなり適当な感じでしたが、C57(冬コミ)では、専任のモデラーの方の協力を得て、何とか最後まで作ることは出来ました。1999年12月時点でも、フリーの3Dシューティングは初だったのではと思っています。(よく調べてません。当時、プリレンダのものはよく見ました。) 今はフリーの作品でも同人のものでも、当たり前に3Dが使われていて、時代が進んだな、と感慨深いものがあります。低価格(あるいは無償)でも高機能のツールが広まった結果でもあると思います。

イディナロークVer.1.00(1.02)は、実は作りこみ出来ていない部分があります。本来、ラスボスの後に脱出シーンが入る予定でしたが、作りこみ出来ていません。予定ではエンディングは2パターンあり、CVは2パターン存在していますがゲーム中は再生されません。この力尽きている部分は、今回の再開発では是非実装したい部分です。力尽きているホーミングレーザーもw

参考までに、タクティカルステージ(獣神ローガスぽい)のを作りたかったという片鱗は当時のコードにも残っていますw 僚機システムも入れたかったのですが...

int C3DApp::TacticalStage(float tick) {
    return 0;
}

しかし、パワー不足のため、まずは完成させる事に主眼を置いたのでした。

さて、C57の後、サブウェポンの修正はしましたが、ビジュアル面も含め、敵の攻撃、ボスの攻撃など、作りこみ不足があるのは認識していましたが、追加する意欲が出ませんでした。シールドを使うと不利になる状況も作る必要があったと考えていますが、システムが先行して、こなれていない状態のまま残ってしまっています。

今考えると、燃え尽き症候群でしょうか。イディナロークは触りたく無い的な何かがあったと思います。しかし、主に海外からのメールでの質問への応対や、サポートは積極的に行っていました。
その後、萌える3Dキャラをぐりぐり動かして先に進む、3D視点のベルトアクションを作ろうと、2001年位から頑張っていたのですが、色々忙しくなり、パワーが削がれてしまったのが事実でした。

これは経験則ですが、一番拙かったのは、企画、シナリオ、イメージが先行したということですね(←頓挫するパターンにありがち)。イディナロークは、技術面から入った点が多く、結果的にビジュアルを後から強化していったので完成したのだと今でも考えています。仕事ではないため、シナリオ、リソース面から入るとうまく行かないというのが持論です。ストーリーやイメージなどは後付け上等ですw そもそも、自分は元々手が早い方ではなく、コツコツという事が苦手だと自己分析していますが、さらに、期間が長くなるとダメで、集中して一気に作り上げないと頓挫する傾向にありました。ある程度作ると「出来た感」が強くなることも問題でしたw。(これを読まれた方は、思い当たる節はありませんか?)

今回のイディナロークの再開発プロジェクト(最近流行りのリブートではない)は、過去の教訓を生かし、プログラムを主体に、リソースをなるべくいじらずに進めています。それから、モチベーションの保ち方として、ブログに少しづつ公開すること。「ほっぷぽっぷん」の頃は、ほぼ毎日、開発日誌をBBSに上げていました。イディナロークの後の企画「くるりんマーナ(仮)」は、コソコソ作って、あとでバーン的なものを追求してしまったので頓挫した感もあります。自分で自分をフォローする、ただしあまりキツくないメカニズムが必要だと思います。ただし、ガントチャートは引きたくないw 今回の開発では、ブログの更新がフォローアップのメカニズムとして機能しています。

ところで。今遊びたいゲームは...?と聞かれたら、こう答えます。

  • パースが付いたビジュアルのSF色の縦シュー(ロックオンレーザーじゃないやつw)
  • 萌える3Dキャラをぐりぐり動かして先に進む、3D視点のベルトアクション
  • 3D化された獣神ローガス >@c_mos (これは本気で欲しい。当然タクティカル要素あり)

タクティカル要素をシューティングに入れると、スターラスターとかスターイクシオン的になるかもしれませんが、いずれタクティカル面を入れた何かを作りたいですね。
3Dのベルトアクションは、「プリルラ」がイメージに近いですが、デュープリズムだったり、ナップルテールだったりします。最近、こういうゲームが無くて淋しい限りです。
遊びたいゲームは自分で作るしかないのですよね。

Ver.1.03では、Windows7で何も苦労せずに安定起動させること、その次に(1.04かもですが)、1.02で力尽きている部分を、力尽きずに作り上げたいと考えています。

今回はこの辺で。
ではでは。



   

[Idinaloq] 進捗 2015/01/02

| コメント(0) | トラックバック(0)

2015年最初の更新です。本年もよろしくお願い致します。

今回はBGMについてです。

旧版のBGMは、standard midiファイルで提供しており、ハードウェア音源(SC-88, SC-88Pro, SC-55 等)を持っている人と、ソフトウェア音源(GM準拠)で再生する人の聞こえ方が異なっていました。当時、ゲームをプレイする人はSC-55等はそれなりに持っていたと思っていますが、一般に普及しているとは言えない状況でした。それに、初出当時のソフトウェア音源はCPUパワーも食うし、お世辞にもよい音だったとは言えなかったと記憶しています。15年経過した現在、standard midiのファイルを聴くという一般ユーザもかなり減っていると思われること、音楽の聞こえ方を統一するという目的から、Timidi95を使用して.MID→.WAV変換したものを現時点では採用しています。

開発環境にはかろうじてUSB接続が可能なSC-8850(1999年発売)が稼動しているのですが、いかんせん、録音状況が悪いんですよ。SC-8850→アナログout→アナログin→USB→PC→USB→スピーカが無音時にノイズが乗っていたので切り分けを行いましたが、アナログin→USBが原因の1つで、USBスピーカも若干ノイズを乗せているっぽいことが分かっています。静かな曲の場合、耳の良い人にはわかってしまうかもしれないと考えた為、手間を考慮した上での妥協策です。ただしこれは本来想定していた再生環境(GM対応だがGS推奨、確認はSC-88Proで実施)では無いため、1.0.3の最終版では相談して変更するかもしれません。

ちなみに、イディナローク1.0.1、1.0.2、のメインパッケージのダウンロードの合計数は、vector集計だと約73万5千ダウンロード(驚き)、当時、雑誌のCD配布などもありましたので、拾った人はそれ以上ですね。この数になると、ダウンロードして実行できたどれだけの人が想定した環境で曲を聴くことが出来たのか、については正直疑問ではあります。殆どの人は、Microsoft GS Wavetable Synth(MSGS)だったりしたのでしょう。ここは1.0.3を開発する上での後ろ向きなポリシーが前提にありますが、作業量との相談になるとは思います。(Timidi95版も悪くは無いです。SC-8850と聞き比べるとかなり印象が違うんですよね...。しかし、SC-8850もSC-88proの音作りとは異なるはずなので、懸案事項にしておきます。)

なお、BGM等はogg化を実施しようとしています。.mp3はゲーム等では今後使えないと考えた方が良いフォーマットですので、現実的には .oggになると思います。で、ogg化するのはAudacity等で変換が楽々出来るので良いのですが、プログラム上でロード→再生→破棄をダイナミックに行おうとすると、ロードして再生可能になるまでの間があるため、サクサク感が失われ、良い感じになりません。.wav、.mp3ならば大丈夫なのですが。 間を無くすには、予めロードしておく必要があるので、メモリ消費量を気にする必要がでてきます。現時点ではCVも入れて100MBをちょっと超える程度です。おそらく全てプリロードして使うことになると思います。

音の話をしたので、ムービーについてもちょっと。ムービーは旧版のファイルをそのまま使おうとしています(ファイル形式は.mpgから .ogv に変更するかもですが)。しかしながら、op.mpgは、C57(古)にあわせて作成し、歌い手の方に十分な練習の時間を与える事ができずに、急いで録音したという(日程が原因で力尽きている)版であり、歌い手の方には非常に申し訳無いものになってしまっています。

名誉の為に、フルコーラス版との差を聞いて頂けると歴然だと思いますので、まだ聞いたことが無い方は、ぜひ、イディナローク - オープニングテーマ曲フルコーラスバージョンを聴いてください。可能ならば、フルコーラスバージョンからショートバージョンをリミックスして、音だけでも差し替えたいとは思いますが、まずは本編ですね。時間と余力があれば、次のステップとして考えましょうか。

実は、だいぶ前ですが、新曲を1曲もらってしまっていて、先に進むしかない状況ですw 旧版の曲を知っている人なら、おおっと思うような雰囲気になっています。

今日はこの辺で。

ではでは。



   

Yo Namikaze Channel

アフィリエイト

Twitter

最近のコメント