スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

物理演算実装中・・・!

現在、物理演算の部分を実装中です!
(といっても、厳格に公式を当てはめた様な処理は行っていないのですが)


やっぱり実装が大変です。
簡易的な物理演算の仕組みは、以前作ったものがあるのですが、

それだと「氷の床」とかの"滑ってる"動作や、
空中で左右キーを押したときの動作が、不自然極まりないものになり、
今一から作り直している最中です。


■具体例 その1
if( //キーが押されていれば){
m_Speed += 4;
}


以前は上記の様にしていました。
摩擦の概念が無いので、例えば、
右キーを押せば通常の地面であろうと、氷の床であろうと即座に移動開始します。
(氷の床上だと、(滑るので)しばらくは移動開始しないのが適切。)


■具体例 その2
if( //通常の地面であれば ){
m_Speed *= 0.8;
}


自分のプログラムでは、右へ4進むとした場合、
何もしなければそのまま右へ4進み続けます。

なので、地面とのあたり判定があれば、
上記の様に4⇒3.2⇒2.56…という風に摩擦らしき力が働き、止まる様な
実装にしていたのですが、これだと
空中で左右キーを押した際に、物凄い勢いで移動開始します。

※地面に当たっている場合は、移動速度が0.8倍になるのですが、
 空中では0.8倍されないので、4⇒8⇒12と、移動速度がどんどん上がる状態になる。


空中の場合(衝突判定をして何も接触していない場合)は、
移動速度を0.4倍にするとかいう実装で多少見た目はマシになりましたが、
汚い実装方法だなと思い、作り直しています。


あと、オブジェクト作成を隠ぺいする様に変更中です。
今までは、プログラム側で下記を全部行っていました。
-----------------------------
・画像情報作成
・矩形情報作成
・移動クラス情報作成

-----------------------------

いろいろとかなり省略してますが大体こんな感じ。

t_DrawerInfo.m_PosX = 100;
t_DrawerInfo.m_PosY = 50;
t_DrawerInfo.m_Rota = 0;
t_DrawerInfo.m_Trans = 255;
t_DrawerInfo.m_Extend = 1000;
t_DrawerInfo.m_DrawFlag = DRAW_NOW;

int t_DrawerHandle = CreateDrawer( t_DrawerInfo );
if( t_DrawerHandle == -1 ){
return( -1 );
}

t_CollisionInfo.m_PosX = 0;
t_CollisionInfo.m_PosY = 0;
t_CollisionInfo.m_Width = 64;
t_CollisionInfo.m_Height = 64;

int t_CollisionHandle = CreateCollision( t_CollisionInfo );
if( t_CollisionHandle == -1 ){
return( -1 );
}

switch( t_MoverType ){
case MOVER_PLAYER:
t_pMover.reset( new CMoverPlayer() );
break;
default:
break;
}

if( t_pMover == NULL ){
return( -1 );
}
std::vector<int> t_Vec;
t_Vec.push_back( t_DrawerHandle );
t_Vec.push_back( t_CollisionHandle );

if( t_pMover.Init( t_Vec ) == -1 ){
return( -1 );
}

int t_MoverHandle = AddMover( t_pMover );
return( t_MoverHandle );


上記の様なコードを記載して、やっと主人公が誕生します。
長過ぎ。

敵とかいろんなキャラが登場するのに、
上記の様なものをいちいち書いてられるか!という訳で、
データ作成クラスを作り、そこに内部処理は全部任せます。

こんな感じで作成出来る様にする予定です!

//x = 100, y = 50に主人公1を作成
t_ObjectManager.Create( OBJECT_PLAYER1, 100, 50 );


このオブジェクト作成と、物理演算周りの修正が完了すれば、
後はステージ量産とか出来る
と思うので、頑張ります…!
7月中旬 完成目標…!

【追記】
そういえば、アクションゲームのカメラワークの実装方法の解説がまだだったような気がする。
これも後日記事として纏めようと思います。
スポンサーサイト

マップチップを動くキャラクターのアニメーション方法に関する考察

引き続き、ゲーム制作を続けていますが、
マップチップ上を動くキャラクターのアニメーションに関して
ふと、思った事があります。

今まで、マップチップ1つあたり:32ドットで、
キャラクターのアニメーション用の画像が4枚ある場合、


( 現在の座標 % 32 ) / (32 / 4)で画像を切り替えていたのですが、
これ、良くない方法なんじゃ?と思ったのです。
-----------------------------------------------------
※実際に当てはめて考えてみましょう。

主人公が(1,1)のマス目にいて、右へ1マス動くとします。
座標で考えると、(32,32)から、(64,32)へ動きます

( 32 % 32 ) / 8 = 0
( 40 % 32 ) / 8 = 1
( 48 % 32 ) / 8 = 2
( 56 % 32 ) / 8 = 3
( 64 % 32 ) / 8 = 0

この場合、上記のように
式の計算結果の値は0,1,2,3,0のように変化します。
これを画像切り替え番号として使用します。

【参考画像】
FieldChiruno.png


上記の画像を使用した場合、
こんな感じで歩いているように見えます。

分かりにくい計算式ですが、
要は、移動距離が32なんだから、それを4等分(8ドットずつ)にして、
その境界で4枚の画像を切り替えて表示させよう
、という事です。

【参考画像】
FieldChiruno2.jpg


で、コレで実装してたんですが、問題が発生しました。

移動速度を上げたら
意味が分からなくなる
のです。

上記の例で言えば、右へ1ドットずつ移動するから
画像の切り替えが視認できる
ものの、

移動速度が8ドットとかにすると、
点滅するが如く、一瞬で画像が0,1,2,3,0と切り替わるので、
何かガクガク動いているが、歩いている様に見えない
という状態になるのです。


で、出した結論が、
画像の切り替えは
移動中の座標で決めない

というもの。


時間を計っておき、どこを移動していようが、
時間に応じて画像を切り替えるのです。
画像0,1,2,3,0の切り替えを、200ミリ秒間隔で行う、という風に。

そしたら、移動速度を上げても
意外と自然に見えました。


よくよく思い返してみると、
市販のゲームとかでも、この時間によって画像を切り替える手法が使われていた
ような気がします。

(移動していない場合は、その場で足踏みしているように見える)

うーん、何故今まで気が付かなかったのか。

なので、座標による画像切り替えで歩いている(走っている)様に見えない!
と悩んでいる方は、一度

時間による画像切り替えの方法を試してみると
良いのではないかな
と思いました。
自分はこれで行きます。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

ゲーム制作状況 -2013/05/29 版

~もくじ~
【1】スクリプト制作について
【2】パズルゲームについて
【3】3Dゲームについて



【1】スクリプト制作について
とりあえず、ゲームを作成する為のスクリプトを作成するぞ!
という事で、簡易スクリプトを作ってみたのですが、

スクリプトを書くのがとても面倒くさいという状態に。
エディタでも無いと逆に作業効率が落ちてしまうレベル。
(今度、Luaを使ってみよう。)

ゲーム制作をする際、下記の4つがあれば良いのではないかと思った。
-----------------------------------------------------
・リソースを管理するクラス
・リソースを読み込むクラス
・外部ファイル化したリソース
・どのリソースを読み込むかを記載した外部テキストファイル

-----------------------------------------------------
(あまりスクリプトやらライブラリやら作ろうとして、
肝心のゲーム制作に着手できないというのは、なんとも本末転倒である。)

という訳で、しばらくゲーム制作中心に作業を進めていきます。
(その内、DXライブラリみたいな作業簡略化ツール的な何か
  を作れれば良いと思うのですが。)



【2】パズルゲームについて
5月の末日に公開予定です。

ただ、体験版の作成が終わっていないので、
1)体験版が完成すれば、それを公開
2)体験版が完成しなければ、去年9/9に配布したものを公開

という形にしたいと思います。

つまり、いずれにせよ5月中に公開は出来るという見込みです。

なお、体験版を公開した後ですが、

・COM対戦
・2人で対戦(非オンライン)
・2人で対戦(オンライン)
・使用キャラクター追加


上記の様な機能を追加の上、
追加したものを正式な製品版として頒布する予定です。


【3】3Dゲームについて
大⑨州東方祭8向けに、3Dゲーム作るぞー!との事だったのですが、
ちょっとイベントまでに、十分な内容のゲームを完成させられるか厳しいので、
ひとまず2Dのゲームを作っておいて、3Dのゲーム公開は次回
にしようかと思います。(うー残念である。)

よって、大⑨州東方祭8向けの別の何か(2Dのゲーム)を製作します。
(とりあえず、公開するものが無いとイベントに参加出来ないですし)

※参考情報↓

■「大⑨州東方祭8」
2013/09/22(日)北九州市・西日本総合展示場(新館)
http://dakimakura.sakura.ne.jp/daikyusyutohosai/

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

DirectSoundでストリーミング再生する方法(ソースコード付き)

DirectSound8で、ストリーミング再生を実装してみたので、
とりあえず、そのソースコードを公開してみます。

※クラス化はしてないので、普通にグローバル変数とか使ってます。

【ソースコード】DirectSoundSample.txt


■DirectSoundについて
DirectSoundって、音声を読み込む為の関数が無い、というのが厄介ですね。
自分でwavとかmp3とか、音声データのフォーマットを解析して読み込む部分を作らねばならない。

その為、DirectXでゲーム開発をする場合、
自分は無音のゲームを開発する感じになっていました。

今回、ある程度使い慣れているDirectSoundを使いましたが、
DirectSoundの後継と言われたりしているXAudio2を使ってみたいとか思ってます。


■ソースコードについて
とりあえず、行う手順は下記の通り。

【1】DirectSound8のデバイス作成
【2】音声データを解析してchar型の配列に格納
【3】音声データまたは、固定バッファのサイズでセカンダリバッファを作成
【4】セカンダリバッファに、イベント通知場所を設定
【5】_beginthreadex関数で、イベントを受け取った際に
   バッファを更新するスレッドを作成
【6】音声データをセカンダリバッファにコピー
【7】元の音声データ削除
【8】再生。
【9】再生中の音声データを停止、スレッドが終了するのを待つ
【10】スレッドのハンドルなどをCloseする


これだけの処理を実装するのは、正直、大変だと思う。

なぜなら、(個人的な想像であるが)
通常、ゲーム制作で_beginthreadex関数とか使わないからである。
※DirectSoundに加え、スレッド関する知識が必要になってくる

ともかく、何かおかしな動作があれば連絡ください。


■今後の予定について
今回作成するアクションゲームはDirectXで開発しようと思ってます。
(DXライブラリを使用しない)

なので、音声再生回り(DirectSound)やら、入力機器検出やら、
Xファイル読み込みやらを作っています。

パズルゲーム体験版は、5月に出すと決めて開発中。
頑張ります。

【参考画像】
Game1.jpg
タイトル画面です。下にVisualStdioのアイコンとかありますが気にしない。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

FlashBuilderで、iPhoneアプリを作成したぞ!

とりあえず、FlashBuilderでiPhoneアプリを作成
することが出来ました!

まぁ、本当にアプリ(ipaファイル)を作成しただけなので、
ゲームとしての体裁もなってない
のですが、

ひとまず実機での動作を確認出来ました!(`・ω・´)

【参考画像】
MyApp.jpg

(自分の端末にインストールして、アプリを実行してみた図)


さて、あとは中身を作りこんでStoreに公開するだけですよ…!

ディベロッパプログラムの購入や証明書の作成(pem形式からp12形式への変換とか)、
プロビジョニングプロファイルの作成 などの解説記事

内容をまとめて書きたいと思います!

もろもろお楽しみに\(`・ω・´)ノ +*

テーマ : ゲーム製作 関連 - ジャンル : ゲーム



上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。