スポンサーサイト

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

ゲーム制作状況 - 2013/11/30 -

今日の報告!

更新遅くなって済みません(_ _;)

ちょっと怒涛の如く不具合が発生したので、
対策を色々と練っていました。


今日は、その不具合と対処した方法を順に記載していきます。


■主人公がブロックの正反対に移動する
不具合その1。

ちょっと、動くブロックを実装してみたのですが、
動くブロックのX座標移動がマイナス、主人公の移動速度が0などの時に、
主人公がブロックの左側から右側に瞬間移動する現象が発生しました。

【参考画像】
Sample_20131130_1.jpg

さて、一体何が起こったのでしょう?


これは、めり込み解消の方法が誤っていました。

今まで下記の様にしていたのですが、
//右側へ移動していれば
if( ( *it )->MoveX > 0 ){
//衝突した物体の左側方向へ押し戻す
( *it )->m_PosX -= ( ( t_RightA - t_LeftB ) + 1 );
}else{
//左側へ移動していれば
//衝突した物体の右側方向へ押し戻す
( *it )->m_PosX += ( ( t_RightB - t_LeftA ) + 1 );
}

※(*it)がプレイヤー。 Aと付いている変数が主人公の矩形、
 Bと付いている変数が衝突した物体の矩形。

これ、主人公主体の判定方法だったのです。
つまり、主人公が移動して何かにぶつかるのではなく、
"何かが移動して来て"主人公にぶつかった場合
正常な判定が行われません。

今回の、ブロックのX軸方向移動がマイナス、主人公の移動速度0の場合、
elseの方の判定が行われて、右側に押し出される、という理屈。


なので、衝突する対象との相対的な重なる方向を算出し、
めり込み解消の為の押し出す方向を決める様にしました。

if( ( *it )->m_MoveX - ( *it2 )->m_MoveX > 0 ){
//衝突した物体の左側方向へ押し戻す
( *it )->m_PosX -= ( ( t_RightA - t_LeftB ) + 1 );
}else if( ( *it )->m_MoveX - ( *it2 )->m_MoveX < 0 ){
//衝突した物体の右側方向へ押し戻す
( *it )->m_PosX += ( ( t_RightB - t_LeftA ) + 1 );
}


今回の例に当てはめると、
0 - -2 = 2となり、正常に物体の左側に押し戻される様になります。

その他の色んなパターンでも検証しましたが、
正常に判定されることを確認しています。

~色んな接触パターン~
主人公  物体
0 +1  //物体が左側から接触
0 -1  //物体が右側から接触
+1 0  //主人公が左側から物体に接触 
+1 -1  //主人公が左側から物体に、物体が右側から主人公に接触 
+2 +1  //主人公が左側から物体に追い付いて接触
-1 0  //主人公が右側から、物体に接触
-1 +1  //主人公が右側から物体に、物体が左側から主人公に接触 
-2 -1  //主人公が右側から物体に追い付いて接触



■左方向の移動速度が、右方向の移動速度より速い
不具合その2。

ちょっとMoveの値を細分化して起こった現象なのですが、
大体、下記の様にしていました。

m_DetailMove += 200;
m_Move = ( m_DetailMove >> 10);



今まで、m_Moveに直接1や2を加算とかしていましたが、
それだと移動速度の微調整が効かないので、

m_DetailMoveの値を200とか500とかで増やし、
10ビット右へシフト演算(1024で割るのと同義)した結果を
m_Moveに代入
する様にしました。
(つまりm_DetailMoveが1024になった際に、m_Moveが1になる。)

そしたらなんと、
左方向の移動の方が若干早い、という状態になりました。
一体何故なのか。

…調べてみたら、下記の様になっていました。
(780 >> 10) = 0
(-780 >> 10) = -1


絶対値が1024以下の負(マイナス)の値の場合、
10ビットシフト演算だと0にならない模様。
これにより、移動速度1の誤差が発生していました。

仕方がないので、
素直に m_Move = m_DetailMove / 1024として対処。


■主人公が、移動する物体に乗っている時にジャンプすると、
ジャンプしたその場に取り残される

不具合その3。

…。

これ根本から実装を見直そうと
思ったので苦労した。


【参考画像】
Sample_20131130_2.jpg

上記の様に、X軸方向に10ドットぐらいの速さで移動していても、
ジャンプすると、真上に飛んで落下します。

現実世界でならあり得ない動きです。

例えるならば、スキーでジャンプ台からジャンプしたら、
スキー板だけが前方に発射され、
自分はジャンプ台の真上にジャンプ、落下する様なものです。

【参考画像】
Sample_20131130_3.jpg


…こんな動きはあり得ない。
うーん、うーん…


Sample_20131130_4.jpg


で、色々と悩んでいたんですが、
原因及び対処法がようやく分かりました。

原因は、接触した場合に、リフトの移動方向の差分を、主人公の座標に加算
という手法を取っていたからです。

if( 接触していれば ){
( *it )->m_PosX += ( *it2 )->m_MoveX;
}


これだと、リフトと接触しなくなった時点で、
主人公の座標修正処理が働きません。

だから真上に飛んだのです。
(主人公のm_MoveXは0の為。)


「じゃあ移動速度(m_MoveX)を代入すれば良いじゃん」という事で、
下記の様にしたのですが、別の問題が発生しました。

if( 接触していれば ){
( *it )->m_MoveX = ( *it2 )->m_MoveX;
}

今度は、リフトの上で主人公が身動きを取れなくなりました。

例:
リフトがX軸方向に2ドット、
主人公がリフトの上で、X軸方向に2ドット 動くとします。

すると、絶対座標としては、主人公はX軸方向に4ドット動かないといけません。
しかし、リフトの移動速度を代入している為、(2を代入)
左右移動が行えない状態になったのです。

なので、代入ではなく、
主人公の移動速度 + リフトの移動速度にする(加算する)必要があると思いました。

んで、「加算すれば、これで実装完了だ!」と思ったら、また別の問題が発生。


リフトに乗ると、
リフトの移動方向に主人公が発射される様になりました。

【参考画像】
Sample_20131130_5.jpg


同様に考えてみます。

例:
リフトがX軸方向に4ドット、
主人公がリフトの上で、X軸方向に2ドット 動くとする。

上記の場合、主人公の移動速度は下記の様になります。
2 + 4 = 6
6 + 4 = 10
10 + 4 = 14
 :


見ても分かりますが、速度がどんどん加算されていくので、
リフト以上の速さで右方向に移動
します。


もう対処不能なのではないかと思いましたが、何とか

摩擦で減衰した主人公の移動距離と
相対的な移動速度のズレを算出、
そのズレに(1 - 摩擦力)を乗算し、
その値を、主人公側の移動速度から引く


という方法で、実装完了しました。
けっこう疲れた…。

上記だけだと意味不明だと思うので解説をします。
まずリフトに乗った際、0.9の割合で移動速度が減少していくものとします。

■主人公の移動速度が5の場合。
5 → 4.5 → 4.05 → 3.645 …中略… 0

この場合、式は下記の様になります。
int t_DifX = ( ( *it )->m_MoveDetailX*m_Friction - ( *it2 )->m_MoveDetailX );
( *it )->m_MoveDetailX += - t_DifX*( 1- m_Friction );

分かり易いように、下記の様に書き直してみました。
int t_DifX = ( ( *it )->m_MoveDetailX*0.9 - ( *it2 )->m_MoveDetailX );
( *it )->m_MoveDetailX -= t_DifX*0.1;


で、次に、
リフトが右に10、
リフトに乗った主人公が右に5 移動するとします。

分かり易いように、1024倍せずに、
そのままの値で、小数点以下の値にして計算
してみます。

t_Dif = 5*0.9 - 10;   … -5.5
5 -= -5.5*0.1; … 5.55

t_Dif = 5.55*0.9 - 10;   … -5.005
5.55 -= -5.005*0.1; … 6.0505

t_Dif = 6.0505*0.9 - 10;   … -4.55455
6.0505 -= -4.55455*0.1; … 6.505955

t_Dif = 6.0505*0.9 - 10;   … -4.55455
6.0505 -= -4.55455*0.1; … 6.505955

長くなるので省略しますが、
主人公の移動速度が、最終的に
リフトの移動速度である10に収束
します。

あともう一つ、
移動速度5で、主人公が地面を歩いている状況でもシミュレートしてみます。

t_Dif = 5*0.9 - 0;   … 4.5
5 -= 4.5*0.1; … 4.55

t_Dif = 4.55*0.9 - 0;   … 4.095
4.55 -= 4.095*0.1; … 4.1405

t_Dif = 4.1405*0.9 - 0;   … 3.72645
4.1405 -= 3.72645*0.1; … 3.767855

t_Dif = 3.72645*0.9 - 0;   … 3.353805
3.72645 -= 3.353805*0.1; … 3.390645

こちらも見ていれば大体分かりますが、
主人公の移動速度は5 … 4 … 3と減少していき、
最終的に移動速度は0に収束します。

つまり、
リフトの上を歩いている場合は、歩くのを止めると、
リフトの移動速度に収束(リフトに乗っている状態)し、

地面を歩いている場合は、歩くのを止めると、
移動速度0に収束する(立ち止まる)のです…!!


この式を生み出すのに
時間がかかった。


全くもって手こずらされた。
実際の物理シミュレーションとは色々と違うとは思いますが、
これでひとまず良し、としましょう。

そもそもアクションゲームは、

何の支えも無く宙に浮いてるブロックとか、
下からジャンプしたらすり抜けられるけど、上から下にはすり抜けられない床とか、
ジャンプした後、更に滞空中にもう一度ジャンプとか、

実際の物理法則では、ありえない現象なんて
いっぱい起こっています。


正確な物理シミュレーションでなくとも、
ある一定の法則に基づき、アクションゲームの世界が構築されていれば
良いのではないかな
、と。


~今日のひとこと~

Twitterの方では既に紹介しましたが、こちらでも紹介。
「コンプレックス・エイジ」という作品が
大きな反響を受けている様です。

【参考画像】
Sample_20131130_6.jpg


"ゴスロリ"を着る事が趣味だった主人公が、
年を重ねるごとに趣味として続けられない事を悟り始める、と言った内容。
(永遠に"お姫様"では居られ…なかった。)


日頃、「終わり」というのは気にしないものですが、
目に見える形で「終わり」というものが訪れる瞬間があるという事を認識させられます。

特に"コスプレ"を趣味としている方には、
同様の心境になるかもしれない
ので、
現段階で一度見ておくと良いかもしれません。

ううむ…やだな…、終わりなんてやって来ないで欲し

【参考URL】コンプレックス・エイジ -第63回ちばてつや賞入選
スポンサーサイト

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

ジャンプ52号感想

●暗殺教室
犯人鷹岡説が当たった!!

また、
-------------------------------------------------
「防衛省の問題 = 鷹岡が防衛省の金品を奪った事」
奪った方法 = 戦闘機などの武器をマフィアとかに売り払う

-------------------------------------------------
という推測してたんですが、実際は機密費の奪取でした。
ちょっと外した。うーん悔しい。


とりあえず本編。

■鷹岡の様子について
鷹岡が結構おかしな状態になってますね。

で、このおかしな状態って以前も見た事があります。
野球の試合で、理事長が野球部員を洗脳した時です。

恐らく、理事長が鷹岡を洗脳したのではないかと。
(「休みの間に手を打つ」発言とも整合性が取れる。)


■クラスの生徒たちの活躍について
・人形を作る
・見張り2人を挑発して、誘導する
・スタンガンで見張りを気絶させる
・実弾でガストロに対抗
・ピアノを弾いて時間を稼ぐ
・某司会者の息子の気をひいて時間を稼ぐ
・100万の上着を着たマフィアをノックアウト
・ヤクザのバッジを見せて、ナンパ野郎を撃退
・握力の暗殺者を撃破
・座席移動で、ガストロを混乱させる
・監視カメラ等のシステムに侵入

思い返してみたら、
何気に万遍なく全員が活躍してるんですよね。
「この人 潜入する意味なかったじゃん」というのが無い。
良く考えられている…!

…で、今回、寺坂君活躍フラグが立った様な気がします。

また、どうすれば一番活躍出来るか?という事を考えると、
やはりワクチンの奪取になるでしょう。

この考察はまた下記で記載します。


■プラスチック爆弾について
烏間先生が「プラスチック爆弾を作った事がある」と言っていたのですが、
いつ作ったのでしょうか。
(何かの伏線かな?)

今の所、特殊部隊での訓練中に作った、と判断するのが妥当かなぁ
と思っています。
(そこまで重要な伏線ではない、と判断)


■予備のリモコン
---------------------------------------------------
もともとマッハ20の怪物を殺す準備で来てるんだ
リモコンだって超スピードで奪われないよう予備も作る

---------------------------------------------------
上記、鷹岡の発言なのですが、

…予備のリモコンも
全部マッハで取られるだけなのでは?

とか思った。

単純に考えて、ワクチンを取られたくないのであれば、
--------------------------------------------
・"ケースを開けた瞬間に爆発する"爆弾を設置
・その爆弾の解除方法は、鷹岡しか知らない

--------------------------------------------
という風にすれば良いと思います。
(それでも、マッハでケースを開けてワクチンを取られたら
  爆風が間に合わず、ワクチンだけ取られるかもしれない。)

まぁ、推測ですが、鷹岡は
"リモコン式の爆弾"しか作れないので、
(やむを得ず)リモコンを量産する事で対応
したのでしょう。多分。

念入りなので、もう一つぐらい奥の手がありそうな気がする。
奥歯にリモコンのスイッチを埋め込んで、
歯を噛み合わせれば爆破出来る
、とか。


■鷹岡との対決方法
さて、どう対処するべきか。

とりあえず、下記の様な展開は無いものとして考えてみます。
---------------------------------------------------------------
・ワクチンが不完全で、1,2週間で健康状態に戻る
・予備のワクチンが、別の場所に隠されていた
・ウイルス感染者から、ウイルスを採取、ワクチンを生成する事に成功
・"スモッグ"(暗殺者)を脅迫するなりして、ワクチンを作らせる

---------------------------------------------------------------
つまり、スーツケースに入ったワクチンを奪取できなければ
感染したクラスメイトは死ぬ
と仮定します。

まず、重要なのが、
鷹岡にリモコンのスイッチを押させない事。

この条件を満たす展開は下記の様になるでしょう。
-----------------------------------------------
【1】烏間先生が、鷹岡の手を撃つ
(もしくは、直接手でリモコンを叩き落とす等の行動を取る。)
【2】鷹岡自身が、「こちらの条件をのめ」と
   何らかの条件を出す。すぐに爆破はしない
【3】スーツケースを、鷹岡の至近距離に持って行く
  (爆破したら、あなたも死にますよ、という作戦)
【4】全速力で、全員で鷹岡を捉える
【5】烏間先生が、鷹岡のを撃つ

-----------------------------------------------
可能性としては、【1】か【2】かなと。


【3】について。
鷹岡は狂っているので、「爆破したらあなたも死ぬk(ドガァァ
という風に、脅し文句を言っている間に爆破される可能性があります。

また、鷹岡からしてみれば、
スーツケースを奪い、遠い場所へ放り投げて爆破させる事も可能なので、
脅しにもならない可能性大。

また、脅しで(狂っている)鷹岡がひるむとも思えないので、
この展開は無いかな、と。


【4】について。
これは烏間先生の作戦ですが、
床に大量の爆破リモコンが ばら撒かれた以上、
全員で取り押さえに行くのは、非常に危険な行為です。

また、漫画の展開的に、
↓これだと、非常に しょうもないご都合主義的な感じがするので、
この可能性も無いかな、と。

「全員で取り押さえに行ったけど、
爆破スイッチも押すことなく鷹岡を簀巻きに出来たぜ!」



【5】について。
一瞬ですべてを終わらせる最強の手段です。

ただ、これだと寺坂君も活躍出来ないし、
物語的にアッサリ終わり過ぎですし、ありえないと思います。


よって可能性として、下記の2つが残りました。
ここから更に絞り込んでみましょう。
----------------------------------------
【1】烏間先生が、鷹岡の手を撃つ
(もしくは、直接手でリモコンを叩き落とす等の行動を取る。)
【2】鷹岡自身が、「こちらの条件をのめ」と
   何らかの条件を出す。すぐに爆破はしない

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

【2】について。
鷹岡が出すとしたら、
どんな条件を出すかを考えてみる。
-----------------------
・渚君との再戦
・殺せんせーの引き渡し
・補習(クラスメイト全員と、一対一のバトルを要求)

-----------------------
…これぐらいしか無いかな。

対戦を要求するかな?と思ったのですが、
・リモコンを持ったまま戦う、
・リモコンを置いて、戦う

これ、どちらも違和感のある展開ですね。

ならば、「殺せんせーの引き渡し」か?と思うのですが、

今回の「補習をしてやろう」発言とかみ合ってない気がしますし、
そもそも懲らしめに来たのに、
鷹岡の要求に頭を下げるかの様な展開はどうなのと思いますし、

【2】の可能性も捨てる事にします。

よって、
---------------------------------------------------
【1】烏間先生が、鷹岡の手を撃つ
(もしくは、直接手でリモコンを叩き落とす等の行動を取る。)

---------------------------------------------------
これで行きます。


更に、過去の推測と現状の状況を組み合わせて
具体的な展開を予想します。

~現状の予想~
・渚君VS鷹岡になる
・その際、渚君がロヴロ先生直伝の"必殺技"を披露する
・寺坂君が、ワクチンを奪取する重要な役割を担う
・鷹岡は、リモコンだけでなく、
 体にスイッチを埋め込む等の、奥の手の起爆方法を用意している(?)

~現状の状況~
・ワクチンを奪取してしまえば、正直、
 鷹岡は一旦放置してホテルに帰っても良い


これらを纏めると、
鷹岡が、リモコン以外の別の方法で爆弾を爆発させ、
寺坂君がワクチンの奪取に成功し、
かつ渚君と鷹岡とのバトルになり(=烏間先生は行動不能)
渚君が鷹岡を倒す
 となります。

さて、状況的に妥当性があり、こんな展開は可能なのか。
可能です。


① 烏間先生が、鷹岡のリモコンを叩き落とす
② 更に、スイッチを押されない様に、
  烏間先生が、あらゆる体術を駆使して時間を稼ぐ
③ 寺坂君が急いでワクチンを取りに、スーツケースを開ける
④ 鷹岡が、奥歯に埋め込んでおいた
  奥の手の起爆スイッチを作動
⑤ ワクチンが粉々になり、寺坂君が瀕死の重傷を負う。
  しかし、寺坂君が少し早く取り出したワクチンは無事。
⑥ 烏間先生の意識が、鷹岡から離れる。(寺坂君に注意が行く)
⑦ その隙を見て、鷹岡が烏間先生に致命的な一撃を加える
⑧ 鷹岡が、クラスメイトをはねのけながら、ワクチンを奪い取る
⑨ 鷹岡が、渚君に対し一対一のバトルを要求
  (勝てたらワクチンを渡す、とか言う。もしくは、
   展開⑧の時点で、渚君以外戦闘不能になっていて、
   唯一残った渚君もやられそうになる)
⑩ 渚君が、必殺技を駆使し、鷹岡を倒す

これでどうよ!!

これだと寺坂君が爆破される事になりますが、
イトナ君の触手腹パンをこらえた実績があるので、
多分大丈夫なんじゃないでしょうか。(ちょっと適当)

また、これだと
「必殺技」が何なのかも予想しておかないといけないですね。


必殺技は恐らく、"人心掌握術"だと思う。
(渚君が、腕力やその他の技術を駆使した"技"を覚えるとは思えないし)

※例えば、
強力な武器を持った暗殺者Aと、丸腰の渚君が居るとします。
この時、人心を掌握し下記のどちらかが可能であれば、
--------------------------------------------------
・暗殺者Aが、「渚君は殺したくない」と思わせる
・暗殺者Aが、「渚君の命令なら何でも聞きたい」と思わせる

--------------------------------------------------
どんなに強力な武器を持っていようが、渚君が勝つのです。
(前者だと、攻撃をためらう暗殺者を、ロープで縛るなど。
 後者だと、その強力な武器で自ら命を絶て、と命令する、など。)

ロヴロ先生は、その必殺技である"人心掌握術"を、
弟子であるイリーナ先生に、ハニートラップという形で教えたんじゃないかな、と。


また、この"人心掌握術"ですが、
この漫画では、既に何回も駆使している人物が居ます。
理事長。

例:
・「頑張りなさい!」と乾いた声援で、
  渚君の精神を暗殺者からE組に戻す
・優しく諌め、濡れながらE組の生徒にハンカチを差し出す事で、
 E組以外の生徒に、尊敬の念を抱かせる
 また、「学校に居られなくなる所だったね、君が」と言い、
 E組の生徒自身には、理事長としての貫録を見せる


そういえば、前回の鷹岡の補習の時も、
言わば 鷹岡の人心掌握術 << 理事長の人心掌握術
だったんですよね。

・鷹岡の人心掌握術 … 言う事を聞かないと厳しく体罰。言う事を聞くと褒める。
            相手は、ちょっと褒めただけで涙を流すぐらいになる。

・理事長の人心掌握術 … 学園において全ての権限を持ち、またそれを他人にも知らしめる。
             凶悪な鷹岡も、理事長の権限で一発退場。

今回は、こうなるんじゃないかなと。
鷹岡の人心掌握術 << ロヴロ先生直伝:渚君の人心掌握術


じゃあ「人心掌握術」ってどうやるの?
という話になりますが…「涙を流す」とかかな…?
「涙は女の最大の武器」って聞いた事ありますし。

まぁ、渚君は女じゃないけど……見た目が(略

【余談】
女性の涙は、男性ホルモンを抑制する成分があるらしいです。
実際に、ある程度の影響を 他人に与えられる模様。
---------------------------------------------------
 [エルサレム 6日 ロイター] 
女性の涙には、男性ホルモンであるテストステロンを減らす成分が含まれているとの
研究結果を、イスラエルの研究チームが発表した。

ワイツマン科学研究所とウルフソン病院によるこの研究では、
女性に悲しい映画を見てもらい涙を採取。

男性被験者らの鼻の下にはり付けて影響を調べたところ、
心拍や呼吸の速度、唾液中のテストステロン濃度、脳のスキャンから、
性的興奮が抑えられることが分かった。

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

とりあえず、「ごく普通に、登校時の様に近づく」という手法は前回使ったので、
もう使えないと思います。

怯えて涙を流すという演技をして、鷹岡に悦に入らせる & 隙を突く
という感じになるんじゃないかな、と。


今回、丁度良く烏間先生も居るので、
もしかすると、渚君が鷹岡に勝利した際、
「確実に"暗殺者"としての才能が…開花している…!!」という感想を
烏間先生が述べる描写が入る
かな、とか思ってます。

※前回、渚君が鷹岡に勝利した際、「暗殺者としての才能を目覚めさせてしまっても良いのか…?」
と烏間先生は感じていました。
今回、勝利した場合は、それと比較した描写(才能が目覚めて来た)が入る…と思う。


【追記】
寺坂君が、今回感染発覚したのは何か意味があるのでしょうか。
----------------------------------------------------------
【1】鷹岡に感染させ、「ワクチンを破壊したらお前も死ぬ!」という展開にする為
【2】行動不能になっているみんなと対比させ、寺坂君には体力があるという事を示す
   また、クラスメイトに「申し訳ない」と思っている事を印象付ける為

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

【1】の可能性も無くはないが…どうなんだろう?
今回のウイルスは経口感染だった筈なので、
確実に感染させられるかは分からない所があると思うんですよね。

発病発覚までに大体半日ぐらいはかかりそうですし、
「これで、お前は感染したぞ!」と脅すことは出来ない様な気がする。

よって、ここは【2】と判断します…!
(というか、そうでないと上記の考察が全部無駄に(ry)

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

ゲーム制作状況 - 2013/11/24版 -

今日の報告!

とりあえず、前回

衝突判定⇒当たらなければ移動⇒衝突判定⇒当たらなければ移動 を
とりあえず移動⇒とりあえず移動⇒全部の衝突判定実施に変えたのですが、

その方法が纏まってきたので、その詳細を書いてみたいと思います。


まず、「移動」についてですが、
座標の変数の値を変えた際に、"差分"も任意の変数に保存します。

例えば下記の衝突判定用矩形の構造体があり、
座標が x = 50, y = 100だとします。

struct CollisionInfo {
int m_PosX, m_PosY;
int m_MoveX, m_MoveY;
};


SetPosX( m_CollisionHandle, 20 );
SetPosY( m_CollisionHandle, 120 );


で、上記の様に座標をセットした場合、
値はそれぞれ下記の様になっています。
m_PosX = 20
m_PosY = 120
m_MoveX = -30
m_MoveY = 20


何で差分も保存するのかというと、最後に衝突判定をまとめて行う以上、
「衝突している」という事だけを判定しても、
どの方向へ押し出して
めり込みを解消すれば良いのか分からない
からです。

例:
矩形Aと矩形Bが衝突しているとしています。

しかし、どう移動してきたかが分からないと、
矩形Aを上方向に押し出せば良いのか、下方向に押し出せば良いのか、
それとも右、または左方向に押し出せば良いのか全くわかりません。



また、最後に纏めて衝突判定を行うので、
全通りの組み合わせで衝突判定を行う必要があります。

全通りのオブジェクトの衝突を判定する方法についてですが、
これは簡単です。

A、B,C,Dの矩形が登録されている場合、

AB
AC
AD
BC
BD
CD

という風に先頭から順に、末尾までの矩形と順に判定を行っていきます。
これで全通りになります。

そして、Y軸方向の移動と、X軸方向の移動に分解して判別するようにしたので、
合計2回の全通り判定が行われます。

プログラムだと、大まかに下記の通り。
Listなので、イテレータを使用します。

//Y座標の衝突判定
for( it = t_CollisionManager.m_CollisionList.begin(); it != t_CollisionManager.m_CollisionList.end(); it++ )
{
std::list< std::tr1::shared_ptr< CollisionInfo > >::iterator it2;
it2 = it;
++it2;
//一番最後の要素の場合、イテレータを増やすとListの範囲外となる。
//よって、その際はループを抜ける

if( it2 == t_CollisionManager.m_CollisionList.end() ){
break;
}

if( ( *it )->m_MoveY == 0 && ( *it2 )->m_MoveY == 0 ){
//衝突判定を行う2つの矩形が、両方とも全く移動してなければ衝突はしない。
//なので、何もしない。

}else{
for( ; it2 != t_CollisionManager.m_CollisionList.end(); it2++ )
{
int t_RightA = ( *it )->m_PosX + ( *it )->m_Width - 1 - ( *it )->m_MoveX;
int t_LeftA = ( *it )->m_PosX - ( *it )->m_MoveX;
int t_TopA = ( *it )->m_PosY;
int t_BottomA = ( *it )->m_PosY + ( *it )->m_Height - 1;

int t_RightB = ( *it2 )->m_PosX + ( *it2 )->m_Width - 1 - ( *it2 )->m_MoveX;
int t_LeftB = ( *it2 )->m_PosX - ( *it2 )->m_MoveX;
int t_TopB = ( *it2 )->m_PosY;
int t_BottomB = ( *it2 )->m_PosY + ( *it2 )->m_Height - 1;

//2つの矩形が衝突していれば
if( ( t_RightA >= t_LeftB && t_LeftA <= t_RightB ) &&
( t_TopA <= t_BottomB && t_BottomA >= t_TopB ) ){
//省略
}
}
}
}


//X座標の衝突判定
for( it = t_CollisionManager.m_CollisionList.begin(); it != t_CollisionManager.m_CollisionList.end(); it++ )
{
std::list< std::tr1::shared_ptr< CollisionInfo > >::iterator it2;
it2 = it;
++it2;
//一番最後の要素の場合、イテレータを増やすとListの範囲外となる。
//よって、その際はループを抜ける

if( it2 == t_CollisionManager.m_CollisionList.end() ){
break;
}
if( ( *it )->m_MoveX == 0 && ( *it2 )->m_MoveX == 0 ){
//衝突判定を行う2つの矩形が、両方とも全く移動してなければ衝突はしない。
//なので、何もしない。

}else{
for( ; it2 != t_CollisionManager.m_CollisionList.end(); it2++ )
{
int t_RightA = ( *it )->m_PosX + ( *it )->m_Width - 1;
int t_LeftA = ( *it )->m_PosX;
int t_TopA = ( *it )->m_PosY;
int t_BottomA = ( *it )->m_PosY + ( *it )->m_Height - 1;

int t_RightB = ( *it2 )->m_PosX + ( *it2 )->m_Width - 1;
int t_LeftB = ( *it2 )->m_PosX;
int t_TopB = ( *it2 )->m_PosY;
int t_BottomB = ( *it2 )->m_PosY + ( *it2 )->m_Height - 1;

//2つの矩形が衝突していれば
if( ( t_RightA >= t_LeftB && t_LeftA <= t_RightB ) &&
( t_TopA <= t_BottomB && t_BottomA >= t_TopB ) ){
//省略
}
}
}
}



重要なのが、赤字の部分ですね。
"Y軸のみの移動"にする為に、X軸方向の座標は、
差分を引いて
います。

※X軸方向に30動いて、X座標が130、
 Y軸方向に10動いて、Y座標が110になった場合、下記の様になる。
 Y座標 … 110
 X座標 … 130 - 30  ( =100)



そして、現状の実行画面が下記の通り。
まだまだ質素な状態です。

【参考画像】
Sample_20131124_1.jpg
オレンジ … 主人公
茶色 … 床、およびブロック
水色 … 摩擦0の床 (滑ります)


次回は、下記の2点を実装予定です…!
・カメラワーク
・押すと動かせる物体





~今日のひとこと~
スーパーマリオという、
ほとんどの人が知っているアクションゲームがあると思います。

そのマリオなんですが、映画化された事があるらしいですね。
全然知らなかった…!

【参考画像】
Sample_20131124_2.jpg

アメリカで50億円の費用をかけて制作
日本とアメリカで公開されたそうです。

で、どちらの国でもヒットしなかった模様。
うーん面白いのかなぁ…?

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

ゲーム制作状況 - 2013/11/21版 -

今日の報告!

衝突判定の方法を変えてみました。
結構大きな改革かもしれない。


~今まで~
Sample_20131121_1.jpg

~変更後~
Sample_20131121_2.jpg


要は、衝突判定 ⇒ 当たっていなければ動かす ではなく、
とりあえず動かす ⇒ 
衝突判定専用のクラスが、座標修正を実施

という風にしてみたのです。


前々から思ってたんですが、

"主人公クラス"があるとして、
そのクラス内で左右移動、ジャンプなどを行うのは良いとしても、
「壁とぶつかっているから、めり込まない方向に移動しないと」とか、
「敵とぶつかったから、HPを減らさないと」とか、

そんな判定まで"主人公クラス"が
担うべきではない
と思うのです。
("敵Aクラス"、"敵Bクラス"があった場合も同様。)

なので、各Moverクラスは移動のみにしました。
これによって発生するメリットと言えば
-------------------------------------------------
・新しいMoverクラスを作る際、
 似たような衝突判定部分を記載する必要が無くなる。
・この敵に当たると燃える、凍り付く、感電するというような、
 衝突応答もそれ専用のクラスに任せられるので、
 各Moverクラスの複雑性が減る。
・衝突判定を行うクラスが一つのみになるので、
 衝突判定周りの不具合の原因の特定が容易

-------------------------------------------------
大体こんな感じでしょうか。

逆にデメリットと言えば、
-------------------------------------------------
・衝突判定専用クラスの複雑性が増す
・衝突判定専用クラスから、
 各Moverクラス等にアクセスする必要が出て来る

(メンバ変数の書き換えなどで)
-------------------------------------------------
各Moverクラスの内部で完結していた衝突判定処理を、
別の専用Moverクラスで行う様になったので当然ですね。
(各Moverクラスから内部変数の値を引っ張ってきて
衝突判定結果を、各Moverクラスの内部変数にセットしなおす必要がある。)

ソースコードだとこんな感じ。
変数を取得する関数を呼ぶ ⇒ 衝突判定 ⇒ 変数をセットする関数を呼ぶ
の手順になります。
//座標の値を引っ張ってくる
int t_PosY = t_DrawerManager.GetPosY( t_DrawerHandle );
//矩形の座標の値を引っ張ってくる
int t_CollisionPosY = t_CollisionManager.GetPosY( t_CollisionHandle );

if( //床と衝突していれば ){
//画像の座標を修正
t_DrawerManager.SetPosY( t_DrawerHandle, t_PosY )
//矩形の座標を修正
t_CollisionManager.SetPosY( t_CollisionHandle, t_CollisionPosY );
//落下時刻をリセット(メンバ変数のm_FallTimeをtimeGetTime関数で更新)
t_MoverManager.ResetFallTime( t_MoverHandle );
}


ここら辺の関数呼び出しがネックにならないかは、
ちょっと心配ではありますが、これで実装をしようと思います。



また、単純な主人公と動かないブロックとの衝突判定は実装できたので、
次は、動かせるブロックや、摩擦で移動速度が低下する処理などの実装を行います。

頑張るぞ…!


~今日のひとこと~
デバッグの仕事をしている自分から一言。

iPhoneやAndroidアプリのレビューについてですが、
サクラが居るんじゃないか?(自作自演で評価を高くする)
と、疑問を持った方がいたりするんじゃないかなと思います。

まぁ、これは普通にあります。


・レビューをお願いします!
 評価は★★★★☆以上でお願いします

とか、

・レビュー及びコメントの記載をお願いします!
「高評価のレビューする事を対価に、アプリ開発会社様より、
 キックバックを貰う件」
については記載しないで下さい


とか、なんか無茶苦茶な裏があったりとか。
(公に、「ツイートでつぶやいてくれた方の中から抽選でオリジナル●●が当たる!」みたいな
  キャンペーンをしている企業もあるので、レビューやツイートを対価とした商品配布等は
  今後 増えて来るかもしれない。)


更に、知り合いに聞く所によると、
アプリのレビュー評価を上げる
専門の企業もある
とか。
例:
★★★★☆ ハマるw
★★★★☆ おもしろい
★★★★★ 楽しい!
★★★★★ クセになる
★★★★☆ サイコー!
★★★★★ 自分の生活の一つです。
★★★★★ 面白いです!
(短文が多いイメージ。
 …かといって短文のレビュー = 業者ではないと思います。)



そんな企業あるの!?と思いましたが、
SEO対策の企業があるくらいだし、
レビュー評価アップの企業もあるんだろうなぁと納得しました。
(アプリのランキングもありますし、一種のSEO対策と言っていいのかも)

【余談】
また、アプリの売り上げを上げる為に
自爆営業(?)やってる所もあるらしい。

社員は全員、このアプリで10000円分のアイテム購入を行って下さい
みたいな。 (強制的に有料アイテム購入を促す。)


最近だと、年賀状を10000枚配れなければ自腹で買い取りなさい
という事をやらされてる、みたいな噂も聞きますし、
ソーシャルゲームでも、自爆営業をやっている所はあるのかもしれません。
(自分だったら…断る。給料から天引きされ始めたら、訴えるか、転職する。)

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

ジャンプ51号感想

●暗殺教室
ちょっと気になった事が。

今回ダミーの人形を作ったんですが、
この人形を作る為の道具って、いつ揃えたのでしょう?

必要な道具は下記の通り。
------------------------
・見張りの服
・カーテンの布
・モップ
・対先生用エアガン
・クツズミ

------------------------
ガストロさんが来た時点で、特に大きな移動はしてないので、
ガストロさんがステージに入ってくる前から、
ダミー人形に必要な道具一式を持ってた
事になります。

要は、見張り二人を倒して、ステージの座席に潜伏するまでの間に、
「暗殺者がもう一人居て、その相手は銃を使い、
 また耳が良くステージの座席に潜伏してる事も看破してくるから、
 ダミーの人形で気を引きつけて、その間に千葉君に狙撃させよう。
 だからダミーの人形用に、見張りの服を奪っておこう。」

これぐらいの予測をしてた事になります。
こんな予測出来るのだろうか?

それと、殺せんせーが色んな指示を出しましたが、
人形を作れという様な指示は出していません。


いつ、ここぞというタイミングで
「狙撃しなさい」という指示が出ると
判断できたのでしょう?


呼吸音が聞こえるぐらいなので、ガストロがステージに立った後に
「今のうちに人形を作りなさい」と指示出せたとは思えません。

出せたとすれば、
ガストロさんがステージにやってくる前でしょう。

しかし…必要になるかも分からない人形の
用意をする指示まで出すか?
と思うのです。

妥当性のある理由としては下記の2つでしょうか。
---------------------------------------------------------------
【1】何らかの手段で、ガストロ(銃使い)が来る事を想定できた
【2】人形はもともと、別の作戦で使う予定だった

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

【1】の場合は、"モバイル律"が監視カメラの映像を受信する事に成功。
銃をしゃぶっている変質者が居る事を確認。…かな。

【2】の場合は、見張りの人間2人が銃を持っていた事実から、
まだ銃を持っている見張り or 暗殺者が居るという事を推測
もし遭遇した場合に備えて、気を引きつける人形の準備をしていた。

…あ、あれこれ述べましたが
【2】だとすると妥当な判断だったのかもしれません。

まぁ…仮に【2】だったとしても、
・「無音で、座席背後で人形を作る」
・「最後にダミー人形を立たせる指示が来る」

上記2点の意思疎通を何故か行えた事の違和感は拭えないような気もする。


【予測まとめ】
・犯人は鷹岡
・鷹岡に指示を出したのは理事長
・資金の用意(ガストロさんを雇う金)も、理事長が絡んでいる
・その資金は、防衛省の予算を奪ったか、
 自衛隊の武器を他のマフィアなどに売りさばいて捻出
・ロヴロ先生の言っていた"死神"は別に居る
・最後は鷹岡VS渚君になり、ロヴロ先生直伝の"必殺技"が炸裂


※書いてて思ったんですが、
鷹岡が自衛隊の戦闘機などを誰かに売れば理事長の手回しが無くても
金は用意出来そうな気がした。

戦闘機は、1機だけで140億円もしたりするようです。

殺せんせーの暗殺成功報酬は100億なので、
ガストロの「政府より高い金を貰っている」発言とも整合性が取れます。


よって予想を少し変えます。


・鷹岡が、自衛隊の武器(戦闘機)などを売りさばいた。
・その金で暗殺者を雇った。
・烏間先生が「防衛省でも問題が起こっている」と言っていたのは、
 鷹岡が、勝手に武器を売りさばいた(武器が無くなった)件の事。



<追記予定!>

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

ゲーム制作状況 - 2013/11/16版 -

今日の報告!

とりあえず、Moverクラスを分割しました。


■今まで
・CMoverPlayer
⇒Move関数内で、落下処理、左右移動、ジャンプを行う

■現在
・CMoverPlayer
⇒Move関数内で、左右移動、ジャンプを行う

・CMoverGravity
⇒Move関数内で、落下処理を行う



アクションゲームには様々な物理法則に反するオブジェクトが出て来るので、
その為に重力を付け外し出来るようにしました。
(トゲトゲの物体が、落下せずに特定の軌道を巡回する、など。)

また、付け外し可能になると、オブジェクトを削除した際の、
当たり判定矩形、Mover、画像の各データ削除が面倒な事になるので、

~面倒な例~
この敵のオブジェクトは、CMoverEnemyと結び付けてたから、そのMoverを削除、
CMoverGravityとも結び付けてたから、このMoverも削除、
矩形は、1番と3番の矩形が割り当てられていたから、1番と3番の矩形を衝突判定リストから削除、
画像は、画像配列の添え字4番を使用してたから、4番を削除、NULLを突っ込んで…みたいな。


オブジェクトの構造体を作る事にしました。
これに矩形、画像、Moverの情報をひとまとめにします。

struct DrawerInfo {
std::vector< int > m_CollisionVec;
int m_DrawerHandle;
};

struct ObjectInfo {
std::vector< int > m_MoverVec;
std::vector< DrawerInfo > m_DrawerVec;
};


ポイントは、Collisionの情報がVector配列になっている事です。
つまり、ひとつの画像につき
複数の当たり判定領域を付ける
事が出来ます。


これメリットあるの?と思うかもしれませんが、
メリットは2つあります。
-----------------------------------------------------
【1】画像に合うあたり判定を構築できる
【2】異なる性質を持つ矩形を組み合わせて、
   オブジェクトの特徴を作る

-----------------------------------------------------
【1】は、例えば星形とか複雑な形の敵が居たとします。
それに対し、矩形(正方形とか長方形とか)1つで、
違和感のない当たり判定を作るのは難しい
です。

その場合は、矩形を複数作って
なるべく画像に合った衝突判定を実施させるのです。
Sample_20131116_1.jpg



【2】は、横からは倒せないが、上から乗ると倒せるみたいな敵の実装で使えます。
(マリオだと、クリボーとか)

Sample_20131116_2.jpg

※緑色の矩形に接触すると、敵がダメージ、
 赤色の矩形に接触すると、自分がダメージ、という風にする。


で、そのオブジェクトを管理するCObjectManagerクラスも作成。
-----------------------------------
t_ObjectManager.DeleteObject( 1 );
-----------------------------------
↑こういう風に削除関数を呼び出せば、
そのオブジェクトのMover、矩形、画像を解放してくれます。


まだ試行錯誤の段階なので、
完成したら、全体のシステムの仕組みを一枚絵で解説してみたいと思います。



あと、Twitter始めました。
とりあえず、背景、アイコン用の画像描いてみました。
Sample_20131116_3.jpg

【URL】conio - Twitter

小ネタやプログラム関連の事などを主に呟いていく予定!



~今日のひとこと~
最近はfacebookで出会い系詐欺などがあっているようだ。

手順は下記の通り。
【1】友達申請が来る(知らない女性。アイコンは女性の顔。)
【2】その友達申請を承諾する
【3】承諾すると、下記の様なメッセージが送られてくる

-----------------------------------------------------------
「友達になってくれてありがとうございます。
実は…間違えて友達申請をしてしまったんです。。

でも、この機会に●●さんと友達になりたいと思いました。
個人的な話もしたいので、このアドレスにメールを下さい×××」

-----------------------------------------------------------
【4】そのメールアドレスに、携帯のアドレスなどでメールを送信すると、
   携帯に大量のスパムメールが届く


要は、間違えて友達申請をしてしまったという設定で、
その人のメールアドレスを聞き出そう
とする手口の様です。

その人にもよりますが、
facebookには、プロフィールなんかで卒業大学、勤め先、友達、趣味など
より個人を特定できる情報満載
だったりするので、

まぁ、業者から見たら良いカモなんだろうなと思いました。


見分ける方法は、
・友達申請をしてきた女性に友達が居るか
(居ない、もしくは男性ばかりの場合は業者アカウント。)
・その女性に、facebookの記事投稿があるか
(全くない、もしくは更新されてなければ、業者アカウント。)
・女性のアイコン画像を、Googleにて画像検索をする
(別名の女性アカウント等が大量に出てくれば、画像を使いまわして
 名前、出身地などの設定を変えて詐欺行為を働いている。つまり業者アカウント。)

こんな感じらしい。

まぁ、一番手っ取り早い対策は、
知らない人からの友達申請は承認しないことでしょう。

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

ゲーム制作状況 - 2013/11/13版 -

今日の報告!

引き続きアクションゲームの根本システムを構築中。
(物理エンジンもどき)

なかなか参考になるサイトや
書籍が無くて困る。




とりあえず、
ローディング画面 → ゲーム画面と遷移する様にしました。

Sample_20131113_1.jpg


また、ジャンプと、左右移動を実装しました。

自分は加速度で動きを変えるシステムにしたので、
ジャンプの際は、m_MoveY = -30;みたいにすればOKです。



DWORD t_DifFallTime = t_TimeManager.GetNowTime() - m_FallTime;

if( t_InputManager.CheckInput( KEY_INPUT_Z ) == 1 ){
//ジャンプする際は、移動方向をマイナスにすればOK。
if( m_JampFlag == 0 ){
m_JampFlag = 1;
m_MoveY = -30;
}
}

//落下速度を徐々に上げていく。力技な実装。
if( t_DifFallTime < 200 ){
m_MoveY += 1;
}else if( t_DifFallTime < 400 ){
m_MoveY += 4;
}else if( t_DifFallTime < 600 ){
m_MoveY += 8;
}else if( t_DifFallTime < 800 ){
m_MoveY += 12;
}else{
m_MoveY += 14;
}

大体こんな感じです。
(省いていますが、地面に衝突した場合は、
 m_MoveY = 0; m_JampFlag = 0;としてます。)

複雑な物理の公式(計算)が無いのがミソです。


~開発中に気づいた問題点~
ブロックに衝突した場合、m_MoveY = 0;という風にしたのですが、

ジャンプして自分より高い位置にあるブロックにぶつかった場合、
なんかフワフワと落下して違和感のある動きになってしまいました。

【参考画像】
Sample_20131113_2.jpg

落下速度を0にしているので、当然と言えば当然なのですが、

動作としておかしいので、上方向に移動中に衝突した際は、
m_MoveYの値を反転させるという処理にして対応しました。
(m_MoveYが-10の場合、+10にする。)

※大体こんな感じ↓

//衝突を検知
if( CheckHit() == 1 ){
//上方向に移動の場合は、方向反転。
if( m_MoveY < 0 ){
m_MoveY = -m_MoveY;
}else if( m_MoveY > 0 ){
//落下している場合は、速度0にする。
m_MoveY = 0;
t_DifFallTime = t_TimeManager.GetNowTime();
}
}



とりあえず衝突応答システムなど、まだ調整の必要があるので、
構築出来次第、適宜 記事で紹介していきたいと思います。


■パッチを当てる事に関して
現在、自分でパッチを当てる実行ファイルを作ろうとか思っています。

先日紹介したフリーソフトWDiffについてですが、
商用のゲーム等のパッチ作成の際は、
WDiffの開発者に連絡を入れる旨が記載
されていたので、
もう自分で作ってみようかなぁと思った次第。
(連絡のやり取りでゴタゴタしたりしたら嫌だ。)

(予想ですが)原理的には、exeをバイナリとして読み取って、
一致しない部分を情報として持ち、その情報を用いて旧exeを書き換えれば良い

と推測しています。

■旧exe
123456789

■新exe
12345000006789

■差分
5:00000


大体こんな感じですね。
配列でいうと添え字5の部分から「00000」が新たに付け足されているので、
その情報を保持しておきます。

で、旧exeに対して、 12345 + 00000 + 6789みたいに
バイナリを繋ぎ合わせてやれば新exeに更新出来る
んじゃないかと。

まぁ、問題は一致する部分と一致しない部分の検出ですが、
これさえ出来れば、パッチを当てる実行ファイルは、自作できそうな気がする。


~今日のひとこと~
一万円札などに、
謎の外国人の名前のスタンプが押されている事があるらしい。

詳細は不明ですが、
海外の金融機関が日本円を取り扱う際に、
担当者の名前の入ったスタンプを押す
事がある模様。

【参考画像】
Sample_20131113_3.jpg

それが日本で出回ったりしてるそうだ。
なお、通貨変造などにはあたらず、普通に使用して問題ないとの事。

うーん、しかし自分は一度も見たこと無いぞ…?

【元記事】【画像】今までに見たことのない、謎の1万円札があるんだが… - 無題のドキュメント

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

ジャンプ50号感想

●暗殺教室
なんか、ボス = 鷹岡 が濃厚になってきたかもしれない。
最初は適当に予想してるだけだったんだけども。

とりあえず、本編を順に考察してみる。


・見張りの二人
見張りの人間が二人居たのですが、烏間先生は、
「こいつら…どこかで…」と言っています。

恐らく、鷹岡が"教育"していた防衛省(特殊部隊)の人間ではないかと思います。


・任務の変遷
当初は、殺せんせーを暗殺する任務だったようですが、
ボスは、明らかに中学生を苦しめる事に重点を置いています。

中学生に対する怨恨を持っている人物と言えば、
現状、鷹岡ぐらいしかいないかな、と。

また、中学生を苦しめるのが目的であれば、
"殺せんせーの暗殺"を名目に暗殺者を雇ったのは不自然
です。
(中学生を苦しめたいので、1週間程度のみ苦しむウイルスを
 ばらまいてくれとでもスモッグに頼めばよい。)

意向と計画が乖離しているので、
【1】誰かから殺せんせーの暗殺計画を依頼される
【2】私情で、計画よりも 中学生を苦しめる事に傾倒

この様な流れが妥当かと思います。
(自分は、この計画を依頼したのが理事長であると予想している。)


・ガストロの力量
ガストロは結構な暗殺者としての力量があると思います。

--------------------------------
……14 いや15匹か?
呼吸も若い ほとんどが十代半ば

--------------------------------
この発言から察するに、恐らく15人目は烏間先生です。
つまり、特殊部隊に居た人間の潜伏をも看破しているのです。

そして更に、人数だけでなく年齢まで判定。
それともう一つ。
----------------------------------
しかも今の発砲音は…
ボスの手下のM60を奪ったのか!!

----------------------------------
発砲音で銃のタイプまで分かっています。
相当耳が良いです。

この人エコーロケーションとか使えるんじゃないだろうか。
■エコーロケーション**********************
音の反響を受け止め、それによって周囲の状況を知ること。
反響定位とも言う。
**************************************




~ここからは伏線考察~
・ロヴロ先生直伝の"必殺技"
これ渚君に伝授された筈なんですけど、
詳細は明かされていなかった様な気がします。

鷹岡を 渚君が"必殺技"で倒す事になるかもしれない。

ワクチンを渡す気がなさそうなので、
鷹岡「あいつ(渚)と再戦させろ。そしたらワクチンはくれてやってもいい」
→渚君の必殺技炸裂し、鷹岡敗北。ワクチン奪取。

こんな感じになるかなーと。


・政府より高いカネもらっている
以前、ガストロが言っていたセリフ。

鷹岡がボスとした場合、プロの暗殺者を雇うためのカネを
鷹岡個人で用意したとは考えにくいです。

防衛庁でも何か問題が起きているみたいな事を
烏間先生が言っていた様な気がするので、
防衛の予算なんかを奪ったりしたんじゃないかと思う。

それでも鷹岡個人で動くのは厳しいような気がするので、
3人を雇うための資金調達には、理事長が絡んでいるような気がする。

(理事長は、殺先生の過去を知っていたりしますし、
シロやイトナ君みたいな触手の開発/ 研究をしている機関ともつながりがありそうなので、
裏で手を回すことは可能だと考える。)



考察纏め
・ボス = 鷹岡
・鷹岡に指示を出したのは理事長
・暗殺者の資金用意は理事長が絡んでいる
・最後は鷹岡VS渚君になり、必殺技が炸裂

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

ゲーム制作状況 - 2013/11/10版 -

今日の報告!

現在、アクションゲームの肝となる
衝突判定、衝突応答について考えています。

今回思ったのですが、
衝突判定は2段階必要なのではないか、という事。
-----------------------------------------------
第一段階: 衝突するオブジェクトを調べ、
        判定の順番を並べ替える

第二段階: 並べ替えられた順番で、衝突判定を実施

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

これだと良く分からないと思うので、
具体例を出してみます。

例えば、アイテムとブロックがあり、
その中間へ主人公が落下
するとします。

【参考画像】
Sample_20131110_1.jpg


そして、主人公の 移動終了予定の座標で、
アイテムとブロックの衝突判定をするとします。
下記の様な感じです↓

【参考画像】
Sample_20131110_2.jpg




…これで衝突判定が終わるのですが、
おかしな事が発生しているのがお分かりでしょうか…。

上記の手順をプレイヤー視点で見てみます。
プレイヤーからはこう見えます。

Sample_20131110_3.jpg

明らかに主人公と衝突していない
アイテムが消滅する
のです。

※余談
かつて「ニコゲー」というサイトがあったのですが、
そのサイトのアクションゲームでは、よくこの現象が見られたような気がする。
(主人公とぶつかっていないアイテムが消滅。)



なので、結論としては、
------------------------------------------
・めり込みを解除する衝突判定が先。
・接触したものが消滅する様な衝突判定は後。

------------------------------------------
このようになります。


今回の場合であれば、
-------------------------------------------------
【1】まず、衝突しそうなオブジェクトを全部探す。
   (今回はアイテムとブロック)
【2】探して見つかった際、オブジェクトの種類に応じて、
   衝突判定の優先順位を変更。
(アイテム→ブロックの順番から、
   ブロック→アイテムの順に入れ替えられる。)

【3】変更された順番で、衝突判定実施。
(めり込まない位置に主人公が移動させられた後、
アイテムとの衝突判定を実施。ぶつかってないので、何も起こらない。)

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

まだ、コーディングの途中ですが、
上記の様に、衝突判定の順番を入れ替える処理を入れた方が良い
という結論が出ました(_ _)

※問題が発生して修正が必要になった場合は、
また処理方法を考え直してみようと思います。




【今日のひとこと】
知人より、「ばり」と「ちかっぱ」の使い分けが分からないと言われました。
(おそらく博多弁。)

あ~~…確かに。
正直、あまり明確な使い分けは無いと思う。
どちらも、「とても」「すごく」という意味で使います。

例:
ちかっぱ疲れた。  ばり疲れた。
ちかっぱ美味い!  ばり美味い!
ちかっぱ人が多い。 ばり人が多い。
ちかっぱ凄かった。 ばり凄かった。 etc…。


あ、ただし、麺の固さに関してだけは、「ばり」のみ。
「ちかっぱ」、お前は駄目だ。

○ ばりかた
× ちかっぱかた


纏めると、
明確な使い分けは(おそらく)無い。
ただし、麺の固さに関しては「ばり」一択。

("バリカタ"という用語として定着してる感がありますが)

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

ゲーム制作状況 - 2013/11/07版 -

今日の報告!

色々と予定の変更があります。


■作業予定(11月)
・パズルゲームの修正
・アクションゲームの作成


■保留作業
・RPG制作
・アプリ制作
・フラッシュゲーム制作
・経営シミュレーションゲーム制作
・クライムゲーム / 恋愛?ゲーム制作 などなど


保留作業がいっぱいです。(やりたい事は色々とある。)

これを全部出来るとは思えないので、
現状、アクションゲーム制作一本に絞ろうと思います。
(予定が色々と変わって申し訳ございません…orz)


みかんこーぼー第一作目の「チルノのパーフェクトにほんご教室!」を超える内容の
アクションゲーム制作を実施します。


現在、物理演算について考え中。
単純に実装すると、
if( 右キーが押されていれば ){
x += 2;
}


こんな感じで、キーが押されていれば移動となるのですが、
摩擦とかも入れたい(氷の床、粘着質の床など)ので、
キーを押した際は、加速度を変える動作
にしてみました。

DWORD t_DifTime = t_TimeManager.GetNowTime() - m_StartTime;

if( t_InputManager.CheckInput( KEY_INPUT_RIGHT ) > 1 ){
//移動開始から20ミリ秒経過
if( t_DifTime > 20 ){
m_MoveX += 1;
m_StartTime = t_TimeManager.GetNowTime();
}
}else if( t_InputManager.CheckInput( KEY_INPUT_RIGHT ) == 1 ){
//移動開始時刻をセット
m_StartTime = t_TimeManager.GetNowTime();
}
//現在の座標を取得
int t_NowPosX = t_DrawerManager.GetPosX( m_TitleLogoHandle );

//現在の座標 + 移動速度を、現在の座標にする。
t_DrawerManager.SetPosX( m_TitleLogoHandle, t_NowPosX + m_MoveX );


大体こんな感じです。

例えば「→」キーを押し続けた際、20ミリ秒ごとに
移動速度が1,2,3,4,5…という風に増加し、(等加速度直線運動)
また、移動速度が5の時に「→」キーを離した際、
移動速度5でずっと右に動き続けます。


摩擦が発生しない限り止まりません。



あと、ついでに落下運動。
落下運動は下記の様に力技で実装しました。

DWORD t_DifFallTime = t_TimeManager.GetNowTime() - m_FallTime;
if( t_DifFallTime < 200 ){
m_MoveY += 1;
}else if( t_DifFallTime < 400 ){
m_MoveY += 4;
}else if( t_DifFallTime < 600 ){
m_MoveY += 8;
}else if( t_DifFallTime < 800 ){
m_MoveY += 12;
}else{
m_MoveY += 14;
}

//現在の座標を取得
int t_NowPosY = t_DrawerManager.GetPosY( m_TitleLogoHandle );

//現在の座標 + 移動速度を、現在の座標にする。

t_DrawerManager.SetPosY( m_TitleLogoHandle, t_NowPosY + m_MoveY );


徐々に落下速度が上がっているように見せるために、
落下開始からの経過時間で、
落下(Y座標の増加値)を変える
ようにしてます。
※無限に落下速度が速くなってもらっても困るので、
 「最大でもm_MoveYは30までしか上昇しない」、みたいな制限をかける予定。


今後また変更を入れるかもしれませんが、
とりあえず、上記の様な計算で行きたいと思います。


【今日のひとこと】
ナンバープレートには特殊なナンバーがあるみたいですね。

このまえ、下記の様なナンバーの車を見たのですが、
これは、領事館の車の様です。

領 - 1 2 3 4

そして厄介なことに、
このナンバーの車(領事館の車)には、日本の法律が適用されないらしく、
もしこの車と事故を起こしても、損害賠償などが払われない可能性があるとか。

※最近では、任意保険などに入らないと
 この領事館のナンバーは発行しない様にしている
みたいですが、
 いずれにせよ、このナンバーの車は近づかない方が良いかなと思います。

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

ジャンプ49号感想

●暗殺教室
ふと思ったのですが、
休みの期間の間に、E組に対して手を打つとか
理事長が言っていた様な気がする。


なので、下記の様な流れだったのかもしれない。
----------------------------------------------
【1】理事長が、鷹岡に「この任務が出来ればE組の教官に復帰させてやる」
   みたいな事を言う
【2】鷹岡が、暗殺者3人を雇って殺せんせー殺害(任務)を実施

(当初は、"通常状態の殺せんせー"に対して、
 生徒へのワクチンと引き換えに、殺害する予定だったのかもしれない。)
【3】現在に至る。
----------------------------------------------


纏めると、
・理事長が黒幕
・鷹岡が3人の暗殺者の雇い主(ボス)
・ロヴロ先生の言っていた「死神」は別に居る


こんな感じじゃないかなーと。


●トリコ
そういえば…ココさんどうなったの?
穴に落ちてずっと出てこないんだけど。


<追記予定!>

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

~ 東方2次創作 頂きものご紹介 ~

今までイベント参加する中で、
他のサークル様の作品を頂く機会があったのですが、
全く紹介出来ていなかったので、ここで紹介したいと思います…!

サークル名:月見醤油  様
作品名: 幻想郷情景 ~愛~
参考画像:
Extra_Fine_Arthicle2.jpg

Extra_Fine_Arthicle1.jpg

説明:
東方のオーケストラアレンジ。
全3Track収録。

感想:
いずれも素晴らしいアレンジです。
是非聞いて頂きたいです…!


サークル名:SPIERAL WIND
作品名:Wトリガーチルノ(Ver1.22)
参考画像:
Extra_Fine_Arthicle3.jpg
説明:
チルノが主人公のシューティングゲーム。
piro様が作成されたPVもあるので、こちらの動画もご紹介・・!

感想:
シューティング苦手な自分にとっては、難易度が高いです。。。
ですが、弾幕の種類が豊富で見ているだけでも楽しいです!(死にますが

あと、ホームページは下記になります(_ _)
【参考URL】SPIERAL WIND


サークル名:MORATORIUM
       深層記憶システム
作品名:PANDEMONIUM
参考画像:
Extra_Fine_Arthicle4.jpg
説明:
Track1 黒棺
    原曲:ほおずきみたいに紅い魂
    深層記憶システム

Track2 天真爛漫ガール
    原曲:妖魔夜行
    MORATORIUM

上記の様に、合同で作成された(おそらく)バンドアレンジCD。

感想:
聴いた感じですが、恐らく生音で録音されている…!(と思う)
ドラムとかベースとかが格好良いです…!

ただ、音量大きくしたら、音割れ(ノイズ?)が発生してしまいました。
うーむ。ノイズが憎い。収録(録音)による弊害であろうか。

また、パッケージ絵の方は三三(たこ部屋)様が担当されたとの事。

【ホームページ】MORATORIUM
【ホームページ】深層記憶システム
【pixiv】三三(さんぞう) - pixiv


サークル名:ひなあそび
作品名:ひな✿あそび
Extra_Fine_Arthicle5.jpg
説明:
下記のゲームが収録されております。

・Legend of Chiluno
・とってもシューティング
・愛媛みかん みかん収穫祭
・愛媛みかん体験盤

■Legend of Chiluno
Extra_Fine_Arthicle9.jpg


■とってもシューティング
Extra_Fine_Arthicle8.jpg


■愛媛みかん みかん収穫祭
Extra_Fine_Arthicle6.jpg

■愛媛みかん(体験版)
Extra_Fine_Arthicle7.jpg



感想:
雛乙巫祝(ひなおとふしゅく)様より頂きました。

余談ですが、複数あるPCが全部壊れたりバッテリー切れだった為、
最後に生き残った1台のPCで、頒布ゲームの生産を行っていらっしゃいました。


シューティングゲームは、すぐ死にました。
避けられません。。

それにしても、「愛媛みかん みかん収穫祭」は一体何なのでしょう。
明らかにみかんを収穫する状況ではないです。
まだクリアしてないのと、色々と謎(面白そう)なので、
ちょっとプレイしてみたいと思います。

【ホームページ】雛乙 巫祝 - Circle.ms


サークル名:こすぷれ喫茶娘々
作品名:ラバーストラップ(ミスティア)
Extra_Fine_Arthicle10.jpg
説明:
ラバーストラップです。

感想:
凄い、クオリティが高い。。。
こすぷれ喫茶娘々様のホームページを見るとお分かりいただけると思いますが、
かなりの大手サークル様でございます。

即売会中に、商品の見張りのご用命を頂きましたので、
少しの間だけ、3名体制で商品を見張らせて頂きました。(店番)
※何らかの手続きで、離席される必要があった模様。

【ホームページ】こすぷれ喫茶娘々 - ODN

============================
紹介は以上となります。
様々な制作をされている方が居て、とても素晴らしいと思うと共に、
自分も修行を積まなければならないと思いました。


頑張らなければ。
パッチファイルの作り方も把握したので、
アップデートとかサポートを行っていきます。

まだ至らない所だらけですが、
引き続き、ゲーム制作を精進して参りますので、よろしくお願い致します。

テーマ : 東方プロジェクト - ジャンル : ゲーム

パッチを当てて、自作ゲームのバージョンアップ版を作成する方法

実は今まで、パッチの当て方を知らなかったので、
調べてみました。
---------------------------------------------------
・パッチを当てる … 一旦完成したプログラムの一部を修正して、
             最新版のプログラムに更新する。

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


パッチの当てる事により、
-------------------------------------

■パッチなし
【1】自作ゲームVer1が完成しました。
【2】自作ゲームVer2が完成しました、お手数ですが、
   ReadMe.txtの1行目をダウンロードパスにしています。
   ダウンロードはこちらから⇒http://


■パッチあり
【1】自作ゲームVer1が完成しました。
【2】自作ゲームVer2が完成しました、
   自作ゲームVer1を購入して頂いた方は、
   こちらのVer2パッチ.exeを実行
してください。⇒http://

-------------------------------------
こんな感じで対応の違いが出て来るのです。

前者の力技でも対応できない事は無いのですが、
下記の様な問題が発生する可能性があります。
  ・適当にパスを入力したら、偶然一致してダウンロードできた
  ・どこからか、パス(ReadMe.txt)の内容が漏えいすえる。誰でもダウンロード可に。


パッチを当てる方に関しては、パッチをダウンロードしても、
書き換えるプログラム(自作ゲームVer1.exe)を持っていなければ意味をなさないので、
普通に公開しても問題ありません。
(…まぁ、この対応方法でも
 自作ゲームVer1.exeが違法コピーされてたらどうしようもないのですが)


~パッチの作り方~
パッチファイルの作成には、WDiffというフリーソフトで
行えるようです。

【参考URL】WDiffの詳細情報 - Vectorソフトを探す!

操作方法についてですが、
--------------------------------------------
【1】「差分作成元」をクリック、 古いVerのゲーム(.exe)を指定
【2】「差分作成先」をクリック、 最新Verのゲーム(.exe)を指定
【3】左上の方にある「D2」(厳密作成2)ボタンをクリック
【4】差分ファイルが作成された後は、「自己展開作成32bit」ボタンをクリック
【5】TEMPFILE.EXEが作成されれば完了!


※手順3の差分ファイルは削除しないとどんどん追記される様です。なので、
ゲームAの差分を作った後、全く別のゲームBの差分ファイルを作る場合は、
一度「TEMPFILE.WDF」を削除してから実施する事になると思います。
--------------------------------------------
このようになります。

基本的に、ファイルパスの指定とボタンクリックしかしないので
凄く便利で使いやすいです。


パッチの当て方は、完成した「TEMPFILE.EXE」を、
旧ゲーム(.exe)が入っているフォルダに移動させて実行
するだけです!


ただのフリーソフトの紹介になってしまいましたが、
パッチ作成は上記の様に行えるようです(_ _)

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

ゲーム制作状況 - 2013/11/03版 -

今日の報告!


破壊不能ブロックを実装しました!

【参考画像】
Sample_20131103_1.jpg

おじゃまブロックに、うっすらと青い「×」が入っているのが
破壊不能ブロックです。

その名の通り、破壊できません。
"なぞぷよ"で言う所の「鉄ぷよ」になります。

ついでに、上記の問題は(おそらく)難易度★★★★★。
※両端が破壊不能ブロックなので、
限られた領域で単語を消せるように積まなければならない、というコンセプトの問題です。


あと、細々した修正点を列挙します…!
--------------------------------------------------
・ストーリーモードでEXPを引き継ぐように修正
・とことんモードのBGM修正
・問題のクリア情報 保持機能 実装
・とことんモードで、スコアがおかしな値になる不具合修正
・大妖精の会話スクリプト追加
・コンティニュー画面実装
・謎解きモード73問目まで作成済み

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

【参考画像】
Sample_20131103_2.jpg
↑クリアした問題に「済」が付くようになりました


そして最後に。

名刺を作りました。

【参考画像】
Sample_20131103_4.jpg
※イラスト、および名刺は"乙谷"さんが作って下さいました。

イベントで、他のサークルの方々は名刺を作っていらっしゃるのに
自分たちは何もない
、という申し訳ない状態になったので、名刺を作る事にしました。


その内サークルのHPとかも作っていく予定…!


【今日のひとこと】
食べ物のラーメンについて。

"メン"は"麺"の事だと分かると思います。
では、"ラー"とは一体何なのか。

調べてみたら、"引き延ばす"という意味らしい。
つまり直訳すれば、引き延ばした麺である。
※ラーメン ⇒ 拉麺 ⇒ 拉(引き延ばす)麺


なら、"ラー油"は"引き延ばした油"なのか?
と思って調べてみたら、

こっちは、漢字で書くと"辣油"になるらしく、
"辣" = 熱を伴う辛さのこと。らしい。

なるほど。 

…日常的に使っているけども、
色々と由来が分からない単語って結構あるのかもしれない。

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



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