top page



プロフィール

Yo./namikaze.org

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


開発環境など

C++, Blender, Unity, DirectX, Windows7

カレンダー

<   2016年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

Unityの最近のブログ記事

[Idinaloq] 進捗 2015/04/05

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

いつになく大量更新です。盛りだくさんなので、よろしくお願いします。

まず最初に、オリジナルサウンドトラック、ステージ2をYoutube、ニコニコ動画にアップしました。開発中のゲーム画像、設定画を入れてありますので、ぜひご覧下さい。一番下にリンクがあります。

次はゲーム画面を使ったスペースシューティング視点の画像ですね。今はまだ、この視点の使いどころを考えているところですが、ステージのスタートと、ボス戦闘開始前後で使えるかなと思っています。

カメラ切り替えをスムースに行うロジックは未実装なので、まだパチパチと切り替わるだけなのですが。

20150405_5.png

これは、お試しでNASA画像を使った背景を組み込み、板ポリだったデブリをグロー付きのテクスチャを追加してさらに加算半透明、自機にバーニア噴射の追加(仮)、ライティングの変更で、だんだんそれっぽく(当社比)なるのだけれど、今度は、テクスチャの解像度との差が浮き彫りに。一応元のテクスチャが512x512なので、ゲーム中の自機や敵はぎりぎり耐えられる解像感を持っていますが、ディティールはやや不足している感じではあります。でもまあ、十分使えます。だけれども、1面のハイパードライブ施設群、3面の戦艦群は、オブジェクト自体が大きく、カメラにアップで映るので、1/4の解像度だった当時は問題がなかったテクスチャマッピングの粗い部分が目だってしまっています。さて困ったな...。課題として覚えておきましょう。まずはゲーム部分の完成が大事です。

ゲーム部分の細かい作業とテストは続いています。なかなかゲーム中に敵を表示させて動かすところまで到達しません。表示して動かす事は容易なのですが、ヒットチェックが未実装なのと、爆発エフェクトも未実装なので、インフラが揃ったら着手します。まだもうちょっと先ですね。

今回、内部的に効いてきそうなテストを行いました。cygwin環境でLuaバインドのテストだったのですが、あっさり出来ました。Luaスクリプトを動かすこと自体は簡単なのですが、スクリプトに見せるC/C++側の関数の登録が面倒ですね。 一人で書いている分にはC/C++でガチガチに書けば良いので、利点を享受する前に面倒になるに違いないのですが、 敵のロジックをビルドせずにダイナミックに差し替えて動かせる仕組みを構築すると猛烈に使いやすくなりそうです。シーケンサでドラムパターンを作るみたいな感じで敵のアルゴリズムを書く感じ?に出来たり、敵のアルゴリズムだけに注力して、サクサク修正する、ということが可能になるので。さーて、どうしますかね。考えましょう。ちなみに、試せていないのですが、Unityに、Luaスクリプトで制御する「Unity Lua Interface Library」という無料のassetがあって、Luaが動くそうですよ。

さて、設定の解説にうつります。ストーリーの鍵を握る「伊勢崎さゆり」のシーン。左はデザイン画ですが、すでに右のような完成版の絵があるので、イメージが分かる感じでお見せしますね。

20150405_1.png

次はパイロット達の私服設定。新OPムービー向けの設定です(クリックで拡大できます)。

新OPムービーでは、彼女らのプライベートや、決意などが描かれます。さゆりは今回、黒髪タイツ娘だということが判明。

20150405_2.jpg

次は、アイリーンと(単なる(笑)オペレータの)小田朋美嬢。アイリーンは朋美よりも年上なのですが、ちょっとした裏のエピソードが。

20150405_3.png

せっかちで天然でちょっとお姉さんぶっている朋美が、

朋「おねえさんにまかせなさい!」

ア「うん、ありがとう。でも、えっと、たぶん私の方が年上...。」

朋「え?」

ア「うん」

朋「あわわわわ、わた、わた、ご、ごごごごご、ごめんなさい!!!」

という事があって大の仲良しになったのだとか。でもやっぱり時々お姉さんぶる朋美でした。

さて、イディナロークのゲーム中のボス戦闘前後の立ち絵(座ってるけどw)は、昔の256x256のbitmapを仮で2倍表示して512x512にしています。 これを通常の解像度で表示するとなると、元絵は少なくとも1024x1024以上のサイズで描く必要があります。絵描きさんは結構大変な事をしてるんですね。なぜこんな話をするかというと、その部分の画像を差し替える計画があります。その話をしましょう。

2000/01/14の開発日誌に記載があるのですが、エイリアの機体「フェニックス02 : コア思想攻宙要撃機 エイリア専用タイプ」の設定として、以下があります。

エイリアには自己増殖型コンピュータが搭載されているため、シンクロ機構を機体に搭載不要になっている。機体とエイリアの直結によりインタフェースの簡略化、伝達ロスをゼロにすることを可能にし、反応速度を
従来の2倍に跳ね上げさせた。シンクロインタフェースの排除によって軽量化した部分を機動性向上のためのブースター装備スペースへ転換、敵への高速接近、急激な離脱を主な任務とするようになった機体である。その任務、および高速性を重視した設計から、兵装は 20mm 2Way フォトンレーザーカノン(PLC)と貧弱だが、敵に一撃を与えるには十分の性能を持っている。

この設定にあわせて、エイリアの機体との接続についてデザインしようということになりました。設定途中のエイリアの機体とのダイレクト接続。今日の打ち合わせでデザインを担当している小田せんせから最初に出てきたのがこれ。

20150405_5.jpg

次に、おこがましくも(笑)修正を提案したのがこれ。どちらかというと、接続方法がメインだったのですが、話がエスカレートw

20150405_6.jpg

パイロットスーツのデザインでは、どこか妙にエロイ感じを出すことになりまして、少し照れくさい感じになると思います。それを汲み取って小田せんせが描いてくれたラフが、妙に恥ずかしそうに着ているさゆりの絵でして...。それはまだ見せられないので後日清書されたらアップする予定です。小田せんせの普段の絵を見ると誰もが納得する、「純粋でこれは絶対、普通にしている絵なのだけれどもどこか妙にエロイ感じ」がゲーム中だとなかなか伝わらないのがとても残念です。あ、念のため...対象年齢は全年齢です。

さて、イディナロークのサウンドトラックStage2をお楽しみください。Youtube、ニコニコ動画、両方にアップしていますよ!



最後に、namikaze.orgの大半のWebコンテンツをUTF-8に変換して、全てcharsetを入れました。これで文字化けが無くなって、色々な環境から問題なくアクセスできるようになったはずです。
古いページを修正するのは色々面倒ですね。

今回はこの辺で。

ではでは。



   

[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] 進捗 2014/12/15

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

3Dオブジェクトを管理するクラスを作り直し中です。もうしばらくかかりそうです。内部設計の変更なので、目に見えるような進捗になりませんが、これが終わらないと色々収拾がつかなくなるので、ここは落ち着いて進めたいと思います。

3Dといえば、旧イディナロークは、オイラー角でオブジェクトをコントロールしていて、しかもDirectX6のDirect3DRMにおんぶにだっこでした。なので、実のところあまり困った記憶が無かったのですが、時を経て改めて作ってみたところ、どうもうまく回転しないな、などと思っていたのでした。パイロット選択画面では、pitch-30度、yaw-80度、rollは少しづつ行います。回転する順序を変えて誤魔化して乗り切っていたのですがw、ローカル座標で任意軸回転させたほうが楽なので、素直にクオーターニオンを導入しました(←いまここ)。過去を振り返ると、イディナロークの様な、動きの少ないw 3Dオブジェクトを使用した2Dシューティングは、ダイナミックな動きが無かったおかげでオイラー角制御でもなんとかなってしまっていたのかなと思います。

ライブラリとかエンジンとかの話。3D描画エンジンであるD3DRMはとうの昔になく、そして後続のD3DXも無くなりましたね。Direct3D Retained Mode(D3DRM)がサポートされなくなった代わりにD3DXがリリースされた時、同じことになるような気はしていましたが、思いのほか長生きしましたね。DirectXの関数にせよ、ライブラリを生で使うのもライブラリに依存するのでマズい、と毎回思うので、今回はしっかりやろうと思います。まあ、ラッパ関数の作成と、ライブラリを作るだけなんですけれどね。これは、D3DRMに依存しすぎ、しかもD3DRMの関数がコードにガチガチに複雑に入り組んでいる為、D3DRMを模擬するライブラリを作るのもキツイ(RMを全部作ることになる)という状況を次に起こさないようにする為でもあります。同じような感覚を、実はUnityにも感じていたりします。ライブラリを使って楽をするならば、やはり、ソースコードがある方が安心できますが、エンジンのソースが無いので、最悪でも、C#やBooで書いて、Unityが無くなってもアプリケーション部分をある程度使いまわせるようなコードにする必要はありそうです。ソースがあるゲームエンジンとしては、Blender+Bullet+Ogre3D+Luaのgamekit(Ogrekit)は開発が明らかに止まっていますし、Blender Game Engineで作るには、広く頒布するには若干のハードルがあったりします。

とまあ、こういう話は楽しいのですが、今はWindowsプラットフォーム向けにWindows依存でガリガリ書いていきます。次回作る際に悩むことにしましょう。

今日はこの辺で。
ではでは。



   

[Idinaloq] 進捗 2014/12/02

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

今日は文字ばかりです。派手な進捗は無いですが、細かいコード修正をしています。15年前に作ったIdinaloqは、ソースを綺麗にする事を考えずに、勢いで作ってしまった感が多々ありまして。


例えばメニュー用のジョイスティック入力とか、元のコードはボタンを離したとかいうコードが隠蔽されておらずメインの処理にそのまま入っていて、うーむ(笑)という感じになりながら書き直しをしていました。まあ大した修正じゃないので、コードは掲載しません。Unityだと、Input.GetButtonDown("Fire1") とかやれば、そんなことは意識せず出来るので楽ですね。

ちょっと齧った程度のUnityですが、リソース管理など面倒な所のサポートが充実しているので楽ですよね。まあ、C++でやる時もその辺を作れば良い話ではありますが、統合環境なのが素晴らしいです。敷居が低いのは事実ですね。

Unityの開発からVC++での開発に戻ったのは、無料版ではUnityのロゴが出るのと、ムービー再生周り(アセットでアレコレすれば出来るっぽいですが)。その辺が諦められず、IdinaloqはUnityで作り始めたものを放置して、Windows向けにVC++で作る事にしました。昔はLightwave3D 6.xを購入するとか、ツール類にはバンバン投資していたのですけどねー。

いやしかし、最近は良い時代ですよね。Windowsのアプリケーションを作成できるフリーのツールがあり、さらに、使いこなせるかどうか無料版で試してみて、有料版に切り替えられる、といったパスがあるツールが存在するので。昔は、VC++も(古くはMSCから)有料で、布施的にバージョンアップが必要だったし(TPもDelphiもw)、まず投資があって、それから使いこなす必要があったので、ハードルが高すぎだったと思います。

で、Idinaloqですが、実はリソースを改変して楽しんでくれている海外の方も居られるので(ずいぶん古いですが)、データの暗号化、パックデータ化は行わないつもりです。決して手抜きでは無い(笑)。ですから昔同様、データ見放題です。再利用はダメですけどね。.mqo と .x が混在することになるかもですが。

うーん、Movable Typeで以下が仕込まれているのだけれど、記事を登録しても、「人気ブログランキング」にこのファイルを見に行ってもらえていない感じ。何故だろう...。

<link rel="alternate" type="application/atom+xml" title="Recent Entries" href="http://www.namikaze.org/moe_game_programming/atom.xml" />

今日はこの辺で。ではでは。

【追記:2014/12/03】 原因判明。「人気ブログランキング」がAtomに対応していなくて、RSS2.0じゃないとダメとのこと。で、対応出来たつもり。結果が確認できるのはまた明日かな。ココログからnamikaze.org上に移動した甲斐あって、こういうのにサクっと対応出来るのはうれしい所。pingも記事に連動して出せますしね。ほくほく。



   

[Unity] 覚書(MonoDevelop-Unity設定)

| コメント(0)

UnityとBooの組み合わせで、MonoDevelopを使っていて、ハマってしまったのでメモを書いておく。この辺をやらずにガリガリ書き始めて、いきなり躓いたので。

BooはPythonと同様にインデントが構文規則となっている為、空白とTABの混在がエラーを生み出すことになる。MonoDevelop-Unityを使う場合、以下の設定で混在を発見できる。

markersandrulers.png

このようにすることによって、以下のように見えない文字(空白、タブ、改行)が記号で表示される。しかし、気に入らないのが、MS Wordでもそうなのだが、空白を「ドット」で表現していること。改行コードが複数存在する状況では、改行を\nと表示するのはやむをえないだろうこと位はわかる。

昔のMono Develop-Unityでは何を表示するか選択出来たようだが、現時点で最新のUnity 4.5.5f1添付のものでは選択が出来ていない。(ドロップダウンにSelectはあるが、どこで選択するのか不明) よって、やむなく、Alwaysにしている。

秀丸エディタを使えば、空白は空白だし、TABはTABとして表現されるのだが。コード補完機能が使えなくなるのが痛い。

monodevelop_invisible_char_2.png

それから、BooはPythonに影響を受けたプログラミング言語であるので、インデントは4文字にしたい。ついでにインデント幅を4文字にすれば完璧。TABを空白にしてしまう設定をしても、どうも動作していないっぽい。

sourcecode_textfile.png

今日はこの辺で。



   

Yo Namikaze Channel

アフィリエイト

Twitter

最近のコメント