スポンサーサイト

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

ジャンプ48号感想

●暗殺教室
流石 殺せんせー拉致対策も万全でした。

しかし、あのまま助けが来なかったらどうなってた事やら。
あまり考えたくはないですな。


●ハイキュー
伊達工には伊達センパイとずんだ四天王が
いや、なんでもないです。ごめんなさい。

相手チームが一挙に公開されたようで、
これからもっと面白くなって行きそうです・・・!


●恋染紅葉
今回のエピソードはよかったです。

初めからこういうエピソードを
連発しておけばよかったのに。


今回の様な心理描写とかを常時やっておけば、
ニセコイくらいのポジションには行けたはず、と個人的に思う。

なぜ最初 「私をぎゅって抱きしめて!」とか言い始める、
妄想の様な展開をしてしまったのか。


●トリコ
鉄平さんは死んでいなかった。

んーとアレだ。
思わせぶりな引き(しかも、今後の展開に影響しない)は
あまりしない方が良いのではないかなと思う。

死んだ!? → 幻術だ → 死んだ!? → 幻術だ → ry
なんか上記のような不毛な描写のように思える。

やりすぎると、下記の様に
どちらに転んでも驚かなくなるという状態になりかねない。
-----------------------------------------------------------
本当に死んだ場合: え、今度は本当に死んでしまったの?
実は死んでいない場合: やっぱり死んでなかった。

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

本編について。
メルクさんの作った包丁デカ過ぎ。
絶対 切れ味に影響せんだろと思えるような装飾が一杯あるような気が。


●こち亀
ミニ四駆 懐かしいなぁ。

自分は実際のミニ四駆はあまりしなかったのですが、
ゲームのミニ四駆は良くやってました。

※これ↓



なんか、下記のループに嵌って詰んだ覚えがある。
結局クリアできなかった。

レースで勝てない → 賞金もらえない → 新しいパーツ買えない
→ やっぱりレース勝てない → モーターとかが劣化する → レースに勝てn(ry

リベンジしてみようかな。
ゲームとしても結構面白かった印象がありますし。
スポンサーサイト

テーマ : 週刊少年ジャンプ全般 - ジャンル : アニメ・コミック

ゲーム開発 現状報告 ~10/23~

ゲーム開発周りの現状報告です。
--------------------------------------
・描画機構 作成
・Xファイル読み込み機構 作成
・非同期読み込みクラス 作成
・インバースキネマティクスの学習

--------------------------------------
現在、上記の事をやっております。
開発の根底のシステム作りに終始している感じ。

とりあえず、描画機構は簡単に作り上げてみたので、
現状の描画システムの内部構造を書いてみます。
(まだまだ、やることが一杯あります。一つずつ片付けて行きたい)

■【現状の描画機構】
NowSystem.jpg

※面倒なので、参照数計測ポインタの表記は省略しました。
実際は std::tr1::shared_ptr<CDrawBase> みたいな感じになってます。

見たら分かりますが、主に下記の3種類の情報で管理してます。
------------------------------------------
・描画オブジェクト
・動作オブジェクト
・オブジェクト情報

------------------------------------------
で、どのマネージャーもlistとvectorをセットにしてます。

描画リスト(リストに登録されている順番に描画)は分かると思いますが、
セットになっているvectorの存在意義は?というと、
これ、各情報に直接アクセスさせる為に存在してます。

【例】
敵、主人公、背景など、たくさんの描画オブジェクトがある場合、
その中から敵を削除するとします。

この場合、下記のように検索してたら遅い(面倒くさい)と思い、
for( it = m_DrawList.begin(); it != m_DrawList.end(); it++)
{
//ユニークなIDを持たせておき、ユニークIDと一致するものを検索
if( (*it)->GetUniqID() == t_UniqID ){
    //一致すれば、描画の終了フラグをセット
(*it)->SetDrawState( DRAW_STATE_FINISH );
break;
}
}

以下の仕組みにしてみました。
------------------------------------------------------------
【1】描画リストへ描画オブジェクトを登録
【2】その際、登録したCDrawBaseクラスへのポインタを取得
【3】そのポインタをVectorに登録し、その添え字を描画ハンドルとして返す
【4】削除する際は、そのハンドルを削除関数に渡す

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

例えば、次のデータを登録した場合、
背景、(描画のみ)
敵A、(描画のみ)
敵B、(描画のみ)
敵C、(描画、移動)
主人公 (描画、移動)
システム的には下記の状態になります。

【参考画像】
NowSystem2.jpg


で、下記のような削除関数を用意しておき、

void CDrawManager::Delete( int t_DrawVecNum )
{
if( t_DrawVecNum >= 0 && (int)m_DrawVec.size() > t_DrawVecNum ){
if( m_DrawVec[t_DrawVecNum] != NULL ){
(*m_DrawVec[t_DrawVecNum])->SetDrawState( DRAW_STATE_FINISH );
}
}
}


で、適宜 削除したい場合は下記の様に関数を呼べば、
線形探索しか出来ないlistの要素を一発で消せるという寸法。

t_DrawMaager.Delete( 3 ); //背景を削除
t_MoverManager.Delete( 1 ); //敵Aの移動処理のみ削除

※上記の方法は、ポインタの先がlistの要素の為、問題がありません。
 vectorの場合は、push_backをすると、メモリの配置が変わる可能性があるので、
 その時点でm_DrawVecなどのポインタの配列はダングリングポインタと化します。
 
【駄目な例】
std::vector<CDrawBase> m_DrawVec;
std::vector<CDrawBase> m_pDrawVec //m_DrawVecの、任意要素へのポインタ



上記からも分かるように、
描画、移動、その他ステータスなど と、それだけの構造になってます。

"キャラクタークラス"とか"自機クラス"とかいうのは存在しません。


描画、移動(変数の書き換え)、そして変数(データ)さえあれば、
どんなゲームでも構成できるはずだ、という考えのもと、上記の描画機構を作りました。


ただ欠点としては、要素をバラバラにしているので、
それらを繋ぎ合わせる(各マネージャーに登録)するのが非常に面倒になることです。

ここらへんはFactoryクラスを作って対応しようと思います。
↓登録する部分のコード例
ObjectInfo t_ObjectInfo;

std::tr1::shared_ptr<CDrawBase> t_Draw( CDrawTexture() );
DrawInfo t_DrawInfo;

t_DrawInfo.m_PosX = GetValue();
t_DrawInfo.m_PosY = GetValue();
t_DrawInfo.m_DifX = GetValue();
t_DrawInfo.m_DifY = GetValue();
t_DrawInfo.m_RotaNum = GetValue();
t_DrawInfo.m_ExtendNum = GetFloatValue();
t_DrawInfo.m_TransNum = GetFloatValue();

if (t_Draw->Init( t_DrawInfo ) == INIT_OK ){
CDrawObjectManager& t_DrawManager = CDrawObjectManager::getInstance();
t_ObjectInfo.m_DrawVecNum = t_DrawManager.AddDrawObject( t_Draw );
}

std::tr1::shared_ptr<CMoverBase> t_Mover( CMoverPlayer() );
int t_Param[1024] = {0};
for(int i = 0, count = GetValue(); i < count; i++)
{
t_Param[i] = GetValue();
}
//Moverクラスは、いくつのパラメータが必要になるか分からないので、
//基底クラスで、int型へのポインタを受け取るInit関数を定義(純粋仮想関数)
//派生クラスで、任意のパラメータを、任意のメンバ変数に代入する仕組みにしている

if (t_Mover->Init( t_Param ) == INIT_OK ){
CMoverManager& t_MoverManager = CMoverManager::getInstance();
t_ObjectInfo.m_MoverVecNum = t_MoverManager.AddMoverObject( t_Mover );
}

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

ジャンプ47号感想

●タカマガハラ
最近の展開は面白いです。
エミシ君の能力は "音消し"ではなく、"他人を操る"であったか。

殴らないと操れないというのも、事前に伏線が張ってあって良かったです。
ただ変態が出てくるだけの展開だった初期とは大違いである。)


●トリコ
(確か)鉄平さんが死んだ・・・?
ハンターハンターのカイトを髣髴とさせる展開である。

唐突に死んだので、衝撃よりも困惑の方が強いかも。
(ハンターハンターの方は、事前に恐ろしい敵だという描写があったので、
   恐怖・絶望感が強かった。

マンサムさん結局出てこなかった。
もしかしたら、不意打ちを食らって倒れてたりするのかもしれん。


●リボーン
何かもう終わりそう?な感じである。
--------------------------
ツナが死ぬ気で○○ッ!?
--------------------------
何か上記の予告があったんですが、
告白とかプロポーズとかかな?と思った。


●ブリーチ
よく思い返してみた。

よく考えたら、更木剣八さんは、
偽者のユーハバッハさんに負けた
ことになるのか。

姿・能力を真似るロイドロイドには勝利して、
姿・記憶を真似るロイドロイドさんには敗北したことになる。

普通に考えて、前者の方が負ける可能性が高いような気がするのですが、
何故 後者に敗北してしまったのか。


●ニセコイ
よく分からんが、漫画の世界で演劇をやる事になった場合、
「ロミオとジュリエット」を行う可能性が高いような気がする。
(特に恋愛が関わってくる漫画)

現実の世界でも、「ロミオとジュリエット」ってやったりするのかな?とふと思った。
自分も演劇をやった事がありますが、「風の又三郎」でしたよ。


<追記予定!>

テーマ : 週刊少年ジャンプ全般 - ジャンル : アニメ・コミック

ジャンプ46号感想

●クロス・マネジ
おぉ良かった。
あの二人は主人公のフォローに回ってくれた。
まぁ、そもそもフォローするような事じゃない(非難されてる事自体がおかしい)のだけども。

あのメガネは、主人公と対比する為の
反面教師的な存在
なんじゃないかと思えてきた。


●タカマガハラ
敵は一人じゃない、というのが展開として面白かったです。

しかし、掲載位置が相変わらず低い。
連載自体が終わりそうなのは、エミシ君も想定外なのではなかろうか。


●トリコ
元気玉が出来たと思ったら、パックマンだったでござる。
なにこr(ry

これ必殺技としてどうなんだろう。


●暗殺教室
見るからにちょっかいを出してきそうな不良達が現れました。
京都ではこの不良たちが暗殺されるんですね。分かりまs(ry

京都では、不良たちに絡まれたり、
殺せんせーは一流スナイパーに狙われてたりして、色々と混乱しそうです。

しかし3年生で修学旅行とは。
自分の高校では2年生の時に修学旅行でした。
(3年は、もう最初から最後まで受験勉強みたいな感じだった)


●ブリーチ
総隊長がお亡くなりになりました。
でも、よく考えたら織姫さえ居れば全部元通りに出来るんですよね。
うん、大丈夫。織姫なら何とかしてくれる。(他人任せ)

で、ようやく一護があの牢屋みたいなのから脱出したっぽいですね。
しかし正直、色々と勝てる気がしない。

封印術を解くのに、これだけ時間がかかっていますし。
(あ、でもあの封印した奴は、封印する事に特化してた奴だっけか。
    他のユーハバッハさんとかの封印術なら、難なく解除できるのかもしれない。)
-----------------------------------------------
【1】一護が超進化を遂げる
【2】敵が、奪った卍解で自爆する
【3】何らかの手違いで、一護が、奪った卍解を更に奪う
   もしくは、奪った卍解の能力が一護に身につく。

(一護が残火の太刀を使えるようになったりとか)
-----------------------------------------------
展開の予想としては、【3】にしておこうかなと思う。
こっちの方が、やられた死神達の弔いになるかな、と。


●恋愛銀河区 石川荘
1P目を見て思ったこと。
フキダシ多っ!

なんか、いきなりライトノベル並の文章かつ文章量で、
読むのを躊躇
したくなった。 が、とりあえず読んだ。

全体的になんか見にくいなと思ったが、
ひとまず「アニメ声と喋り方が気に入らない」って言われた後、
ロボットが、フキダシプレート使って会話し始めたのには笑った。

・フキダシの量を減らす
・全てのコマにおいて、絵を読みやすくする

上記の改善があれば、更に良くなるんじゃないかと思った。
今後に期待してたりする。


●恋染紅葉
最近マクドナルドは、 (推論だが)セットメニューの売り上げを上げるために
カウンターのメニューすら撤去して うわ何をすやめ(ry

テーマ : 週刊少年ジャンプ全般 - ジャンル : アニメ・コミック

ジャンプ45号感想

●トリコ
四人の技をどう組み合わせるのかな?と思ってたら、
何か元気玉が出来たでござる。

「この料理うまそう・・・!」と強い食欲を抱くと、
周囲を破壊するエネルギー弾が生成されるとか、
どんな世界だ。 怖すぎるよ。

小松のフルコースを食う時とか、絶対フルコースが木っ端微塵になる。


●ニセコイ
最近は10年前の約束が、完全に放置されてるなぁと思った。
(そこら辺の謎の解明が進まなくても、面白いので問題ないのですが)

「鍵が直るまで、約束の相手が誰なのか?はお預け」 というのは、
今考えたら、納得のいくエンディングを考える時間を稼ぐ為の展開
ではないかと思った。

多分、今必死になって物語の展開とか考えてるんじゃないか、と勝手に邪推してみる。
もうこんな感じですよ。↓
----------------------------------------------------------------------------
鍵は直す・・・・・・!
直すが・・・
今回 まだ その時と場所の 指定まではしていない
そのことを どうか諸君らも 思い出していただきたい
つまり・・・・我々がその気になれば 鍵の受け渡しは
10年後 20年後ということも可能だろう・・・・・・・・・・ということ・・・・!
----------------------------------------------------------------------------

●クロス・マネジ
------------------------------------
女子部のマネジとか恥ずかしくねーの?
------------------------------------
このメガネは一体何なんだ。
何も恥ずかしくないだろうがぁぁあああァ!!
困ってる部活の助太刀に入ってるだけだろうがぁぁあああァ!!


ナンデ?ナンデミンナ櫻井をワラウ?櫻井ガナニカシタ?

将棋の盤上の駒をグシャグシャにしてヘラヘラ笑っている時から、
こやつの印象はあまりよろしくなかったが、
今回ので、印象が最悪となった。

こいつは友達じゃない。ただのチャラ男である。


●ブリーチ
総隊長の卍解が奪われるとか・・・(´・ω・`)

よく考えたら、卍解を奪う原理の解明が終わっていないのに、
「わしの卍解は奪えないのだろう」と勝手に判断したのは不味かったのでは。

一護はどうするんだか。
太陽を身に纏うが如し卍解とどうやって戦うんだ。

もう、総隊長の卍解を使おうとして、
「な、なぜだ・・・残火の太刀とは一体・・・うごごごご!」とか言いながら、
卍解が暴走して ユーハバッハさんは炎に飲まれちゃえばいいよ。


●リボーン
----------------------------------------
夜の炎のワープホールを連続で通過し
推進力を無限に加算することによって
高速となる!!

----------------------------------------
最終奥義が出ました。

技の原理は置いておくとして、
要は、物凄いスピードになった段階で
敵の頭上にワープ、体当たりを食らわせる
 という技のようですね。

これ、敵がよけたら自分が地面に激突するだけなんじゃ?

致死率100%っていうのは、(技が決まろうが、決まらなかろうが、)
自分が死ぬ確率100%という意味だったのかもしれない。

なんという捨て身の技だ・・・。大した奴 d(ry


●岸辺露伴は動かない
物語が展開してから、割と早く起承転結の"結"になってしまいましたが、
面白かったです。

荒木先生は、マナーとか、2進数とか、サブリミナル効果とか、
色んな要素を物語に組み込んでいるなぁと思います。
面白いです。

今回のマナーについて。
「正しい」か「正しくない」かのどちらかという事ですが、
中には「正しい」とされている事が本当に正しいのか疑問に思えるものもあったりします。
(もしくは間違っている)

『ライス(ご飯)は、ひっくり返したフォークの背に乗せて食べる』、とか。

まぁ、所詮は周囲に対して配慮する考え(知恵)ですからね。
地域や習慣によって、なんか色々と変わるような気がします。

山の神々が、意味の分からん動作を「これがマナー!これが正しい!」とか言い出したら、
お前がそう思うんならそうなんだろう・・・お前ん中ではな・・・。 とか言い返してやりたい。

あ、でもそんな事を言ったら殺されますね。
理不尽なり。

テーマ : 週刊少年ジャンプ全般 - ジャンル : アニメ・コミック

ローグライクゲームを作ってみよう!  その5 ~移動処理~

今回は、ローグライクゲームの
移動処理の部分を解説して行こうと思います。

※個人的な実装方法です。

■解説順
【1】単純な移動処理
【2】歩数の決定方法
【3】任意の歩数での移動処理



【1】単純な移動処理
とりあえず、色々と思うところがあって、
今回 移動方法をキーフレームアニメーションで実装しました。

※今までは下記のように、座標のインクリメント、デクリメントで対応していた。

switch(m_MoveType){
case MOVE_RIGHT: m_PosX += 1;break;
case MOVE_LEFT: m_PosX -= 1;break;
case MOVE_UP: m_PosY -= 1;break;
case MOVE_DOWN: m_PosY += 1;break;
default:break;
};

//マップチップが32の場合は、x,yがともに32で割り切れる座標かを確認
if((m_PosX % CHIP_LENGTH) == 0 && (m_PosY % CHIP_LENGTH) == 0){
m_MoveType = MOVE_NONE;
}

上記のようなやり方は単純ですが、
問題点がいくつかありました。
-------------------------------------------------------------
問題1:スピードの調整が面倒。
例えば、32ドットのマップチップの場合、
関数が32回実行された際に移動が終了します。

もうちょっと早い方が良いな、と思った場合は、
m_PosX += 2 とか、 m_PosX += 4 とか、 m_PosX += 8とか、
32で割り切れる値の範囲でしか変更が出来ません。
(移動終了判定にて、x,y座標が 割り切れるかどうかで確認している為)

問題2:異なる歩数の場合は?
主人公が1歩歩くたびに、敵が2歩動くとします。

単純に考えて、下記のように一回の処理で
敵の進む幅を2倍にしなければなりません。

主人公 ・・・ m_PosX += 1;m_PosX -= 1;など。
敵   ・・・ m_PosX += 2;m_PosX -= 2;など。

ここらへんはまだ良いのですが、
主人公が1歩歩くたびに、敵が3歩動くとします。

この場合、下記のようにすれば問題が無い様に思えますが、
これだと正常に動きません。

主人公 ・・・ m_PosX += 1;m_PosX -= 1;など。
敵   ・・・ m_PosX += 3;m_PosX -= 3;など。

歩数が32の倍数でなくなってしまってるからです。
(3,6,9,12,15,18,21,24,27,30,33・・・ となり、32を超える。
  マップチップのマス目ぴったりの場所を通り過ぎて行ってしまいます。)
-------------------------------------------------------------
・・・と、言う訳で、
異なる歩数で動く敵が居る仕様の場合、座標のインクリメント、デクリメントじゃ
面倒な事になりそうだと思い、今回やり方を変えたのです。

キーフレームアニメーションは時間で制御します。
式にするとこんな感じ。

現在の座標 = 初期座標 + 進み具合×(移動先の座標 - 初期座標);
※進み具合 ・・・ (現在の時刻 - 移動開始時刻) / 移動時間 で算出。


例えば、x座標 120の場所から220の場所まで 2秒(2000ミリ秒)で移動する場合、
下記のようになります。

double t_Rate = (timeGetTime() - m_StartTime) / 2000;
m_PosX = 120 + (t_Rate * (220 - 120));


//0秒経過
double t_Rate = (0) / 2000; //t_Rateは0.0
m_PosX = 120 + (t_Rate * (220 - 120)); //座標は120になる。
//1秒経過
double t_Rate = (1000) / 2000; //t_Rateは0.5
m_PosX = 120 + (t_Rate * (220 - 120)); //座標は170になる。
//2秒経過
double t_Rate = (2000) / 2000; //t_Rateは1.0
m_PosX = 120 + (t_Rate * (220 - 120)); //座標は220になる。

上記だと固定座標のアニメーションしかしないので、
下記のように、適宜 変数に座標などを保存しておけば、任意のアニメーションが行えます。
(斜め移動も可能)

const DWORD g_MoveTime = 2000;
//中略//
if(m_Move == MOVE_NONE){
if(Key[KEY_INPUT_RIGHT] == 1){
m_StartPosX = m_PosX;
m_NextPosX = m_StartPosX + 32;
m_StartTime = timeGetTime();
m_Move = MOVE_RIGHT;
}
}
//中略//

double t_Rate = (timeGetTime() - m_StartTime) / g_MoveTime;

//時間が経過しすぎている場合、
//アニメーションがちょうど終了する値に変更する。

if(t_Rate > 1.0){
t_Rate = 1.0;
}
m_PosX = m_StartPosX + (t_Rate * (m_NextPosX - m_StartPosX));

if(t_Rate == 1.0){
m_Move = MOVE_NONE;
}



【2】歩数の決定方法
次は歩数の出し方について。
端的に記載します。

<1> 移動するオブジェクトに、下記のパラメータを持たせる
int m_Speed; //速度
int m_SpeedCount; //歩数を決める際に利用するカウンタ
int m_StepNum; //歩数
<2> 主人公が移動した際、全ての移動するオブジェクトに、
   主人公のSpeedの値をSpeedCountに加算
する
<3> SpeedCount / Speed を、歩数とする (m_Stepに代入する)
<4> SpeedCount % Speed を、SpeedCountに代入する 

以上です。

よく分からないと思うので、実際にどうなるか記載してみます。

<1>初期状態
      主人公  敵A  敵B  敵C
Speed :   30   15   10   20
SpeedCount:   0    0    0    0
Step :   0    0    0    0

<2>主人公のSpeedを、全オブジェクトのSpeedCountに加算
      主人公  敵A  敵B  敵C
Speed :   30   15   10   20
SpeedCount:   30   30   30   30
Step :   0    0    0    0

<3>SpeedCount / Speedを、Stepに代入する
      主人公  敵A  敵B  敵C
Speed :   30   15   10   20
SpeedCount:   30   30   30   30
Step :   1    2    3    1

<4>SpeedCount % Speedを、SpeedCountに代入する
      主人公  敵A  敵B  敵C
Speed :   30   15   10   20
SpeedCount:   0    0    0   10
Step :   1    2    3    1

■2回目の移動■
<2>主人公のSpeedを、全オブジェクトのSpeedCountに加算
      主人公  敵A  敵B  敵C
Speed :   30   15   10   20
SpeedCount:   30   30   30   40
Step :   0    0    0    0

<3>SpeedCount / Speedを、Stepに代入する
      主人公  敵A  敵B  敵C
Speed :   30   15   10   20
SpeedCount:   30   30   30   40
Step :   1    2    3    2

お分かり頂けたでしょうか。

見ての通り、主人公は1歩、敵Aは2歩、敵Bは3歩 進む事がわかります。
また、中途半端なSpeedを持った 敵Cは、SpeedCountの状況に応じて
一歩進んだり二歩進んだりして、
歩数(移動速度)が調整されている
事が分かると思います。

※「歩数(移動速度)は固定にしたい!」という場合は、敵のSpeedを、
  主人公のSpeedCountの値で割り切れる値にしておけばOKです。


【3】任意の歩数での移動処理
ここちょっとややこしいので注意。

例えば3000ミリ秒で主人公が1歩動くとします。
この時、3歩動く敵は、下記のように処理を行います。
---------------------------------------
①1000ミリ秒で一歩動く
②次の移動先を決める
③1000ミリ秒で一歩動く (2000ミリ秒経過)
④次の移動先を決める
⑤1000ミリ秒で一歩動く (3000ミリ秒経過)

---------------------------------------
要は、主人公が移動先を決めて一歩移動している間に、
敵は細かく移動、移動先決定、移動、移動先決定を 歩数の数だけ行う
ことになるのです。

これを実装するコードは下記の通り。

//g_BaseMoveTimeは、主人公が一歩進む際にかかる時間
一歩あたりの移動時間 = g_BaseMoveTime / g_MoverInfo[1].m_Step;
double t_Rate = (double)(経過時間 - (現在の歩数 - 1)*(一歩あたりの移動時間)) / 一歩あたりの移動時間;

if(t_Rate == 1.0){
g_MoverInfo[1].m_MoveID = MOVE_NONE;
//現在の歩数を増やす
g_MoverInfo[1].m_NowStep += 1;

//現在の歩数 > 移動する歩数になったら、移動終了。変数を初期化
if(g_MoverInfo[1].m_NowStep > g_MoverInfo[1].m_Step){
g_MoverInfo[1].m_NowStep = 1;
}

}


単純に移動する場合は、t_Rateが1.0になれば終了なのですが、
歩数が一歩以上の場合は、複数回 移動処理が行われるので、
t_Rateが1.0になる度に、現在の歩数を1ずつ増やし、決められた移動する歩数を
超えれば終了
、というような処理が追加されております。

あと、t_Rateを算出する式もややこしいので、実際に数値を代入していって見ましょう。

//一歩目 途中
double t_Rate = (double)(500 - (1 - 1)*(1000)) / 1000; //t_Rateは0.5
//一歩目 終了
double t_Rate = (double)(1000 - (1 - 1)*(1000)) / 1000; //t_Rateは1.0

//二歩目 途中
double t_Rate = (double)(1500 - (2 - 1)*(1000)) / 1000; //t_Rateは0.5
//二歩目 終了
double t_Rate = (double)(2000 - (2 - 1)*(1000)) / 1000; //t_Rateは1.0

//三歩目 途中
double t_Rate = (double)(2500 - (3 - 1)*(1000)) / 1000; //t_Rateは0.5
//三歩目 終了
double t_Rate = (double)(3000 - (3 - 1)*(1000)) / 1000; //t_Rateは1.0

以上です。


【ソースコード】Rogue3.txt
【使用画像】
MapChip1.png
Human.png
※今回、上記の画像を使用しております。
 上記の画像もダウンロードするか、もしくは (64×32)が4×4の主人公の画像と、
 (32×32)が2×2のマップチップの画像を用意すれば動作すると思います。


※注意点※
【1】g_MoveBaseTimeは、歩数で割り切れる値にしてください。
(3歩動く敵が居る場合は、3000、6000など。
 例えば1000にしてしまうと、一歩あたり333.3333と、割り切れない時間で移動することになり、
 誤差が生まれ不具合が発生します。(断言。) )

デフォルトでは600にしてます。1,2,3,4,5,6などで割り切れる数なので、
1~6歩で動く敵は実装できます。(一度に6歩動くチートな敵なんて 普通は居ないでしょうが)

【2】この記事で解説していない部分があります
・画像の読み込み
・マップの定義、読み込み
・当たり判定
・アニメーション (人が歩いているように見せるための、画像切り替え)

今回内容を「移動」に絞ったので、上記の部分の解説は省略しています。
「意味分からん」みたいな所とかあったら突っ込みを入れていただければ解説/修正をします(_ _;)


【3】描画順の管理を行っていません。
今回 主人公 → 敵 の順で描画しています。
なので、敵が前面に来たら主人公は隠れます。

なので、画像が不自然に重なっても今回は無視してください。

【4】ソースコードがやや長い&最適な構造ではありません。
本当は分割コンパイルとかすべきなのですが、
ファイルを一つダウンロードしてコンパイルすればすぐ実行できる方が良いだろう、
と思い、意図的にクラス化などをしていない変数などがあります。

なので、アルゴリズムの部分だけに着目して、
他の変数の定義の部分は、自己流に改造するのが一番良い
と思います。


次回は・・・
根本の描画システムについて解説します。

※「クラスまみれのゲームプログラミング入門」みたいな感じ
【参考URL】クラスまみれのゲームプログラミング入門

描画システムの後は、
基本のステータスの実装と、敵との戦闘処理を作っていきます!

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

ジャンプ44号感想

●めだかボックス
言彦さんに破壊されたものは、2度と戻らないとの事。

しかし、1億回以上 敗北した安心院さんが特に傷を負っていなかった事からして、
抜け道はあるんだろうな、と思う。

例えば、"自分の分身を作り出せるスキル"で、無傷の状態の自分を新たに作り、
細胞を破壊された方の自分は消去する
、とか。

(破壊されたものを直すのではなく、「破壊されていない状態」を新たに創造する。)

で、そんなこんなで 王土さんが登場しました。
たまたま通りすがるなんて、
善吉の愚行権(デビルスタイル)は発動していないのだろうか?

そういえば、この人 黒神さんを洗脳して妻にしようとしてたっけ。
助けに来るキャラとしては適格なのかも。


●恋染紅葉
あれだ、以前も言ったとおり、ドロドロしたものを描写されても困る。
(ドロドロを乗り越えた上での、結果/成果が出る展開ならまぁ良いのですが)

そういえば、かつて、土曜だか日曜だかに
"明日のナージャ"とかいうアニメがあってたんですが、
ふと見てみると、いきなり
マリーとかいうキャラクターが
主人公の母親の形見のドレスを八つ裂きにして捨てるシーン
 が流れて
精神的苦痛を受けた事がある。

=閑話休題=

とりあえず、主人公が川に捨てられたキーホルダーを拾う → 小鳥さん改心
になるんだろうな、と。
(なんか「川に落ちた何かを探して見つける」展開って漫画でよく見かけるような気がする)

個人的に、テコ入れで
腐ったグループ内の関係や、それを取り巻く芸能界の掟みたいなのを破壊する展開
芸能界 制圧編 とかやってくれたら面白そうと思った。

(いかにテレビから干されずに、名を上げ、ファミリー(取り巻き)を構築し、
   大物芸能人を味方に付けたりしながら、知略を尽くして 芸能界の頂点に立つ!、みたいな。)


●トリコ
毎回言ってますが、マンサムさん どうしたの。

とりあえず、捕獲LV350くらいでも、4人の力を合わせれば勝てる!
みたいな展開になりそうですね。

しかし、どんな風に組み合わせるんだろうか?
特にココの毒はどう組み合わせたら良いのか分からん。


<追記予定!>

テーマ : 週刊少年ジャンプ全般 - ジャンル : アニメ・コミック



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