ゲームのアルゴリズムを教えて管sai
>>64
普通の2次元配列を用意すると、任意の要素の周辺には8個の要素があるが、
そのうち2個削れば6個になる。
横並びのHEXの場合、削り方には
・右上と右下
・左上と左下
の2通りあるが、行の隅・奇で決めればよい。
但し、このアドレス計算のオーバーヘッドが無視できない場合、
>>65の言うようにリスト構造か、[6方位][各セル]分の配列を
あらかじめ作ってしまう方法も検討するとよい。
>65-66
d
話が前後するけど移動に関しては↓の「2.マップ移動システム」みたいな
話もある。構造が明快ではなくなるけどXY式より処理は少なくなる。
ttp://members.jcom.home.ne.jp/masimaro/cgi/index.html
横軸分引けば下移動、足せば上移動だから、アクションでも使えるん
じゃないかな? 斜めになっている地面、斜めになっている天井とプレイヤーとの当り判定ってどーゆーふうにしたらいいんですかね?
地面は何とかなりそうなんですが天井の方がよくわかりません。 某板よりコピペ
多数のオブジェクトの衝突判定を並列化する方法
移動後の座標をボクセルに振り分ける。
1つのボクセル内に存在するキャラを総当たりで衝突判定。
処理の順序としては、移動、振り分け、衝突判定、衝突処理。
これで処理を並列化できる。
もう少し詳しく言えば、衝突判定をしやすくするために、
ボクセルに振り分ける時点で座標値などをボクセルごとの一時バッファに複製しておく。
これにより巨大なバッファをLSにロードする必要がなくなる。
衝突の連鎖については次フレームに回す。それで結果的には再帰処理になる。
普通は移動後に振り分けるというより
ボクセル内のオブジェクトを管理するバッファを常設しておいて
移動でボクセル外に出たときだけバッファの更新をするでしょ。
>>69
・坂を方程式で表す方法
例えば天井がy=-0.1*x+64の直線と考えれば、
atamay<=-0.1*atamax+64なら当たり。
地面をy=-0.1*x+480の直線と考えれば、
asiy>=-0.1*asix+480なら当たり。
atamax,atamayはキャラの頭の座標。asix,asiyはキャラの足の座標。
画面は640*480を想定。
・小さい矩形に分ける方法
天井も地面も小さい矩形がたくさん集まったものだと考え、それぞれの矩形と
の当たり判定を行う。壁(当たり判定がある地形)があるシューティングとかは
これでやってるはず。
これなら坂はまっすぐでなくてもかまわない。
・色で判定する方法
たとえば壁(当たり判定がある地形)は黄色で描くものと決める。atamax,atamay
の座標の色を読み黄色なら当たり。RGBのRが128以上なら壁とかでもいい
(言語による)。描画処理と当たり判定の順序に気をつける必要がある。地形
を描いて、キャラを描く前に当たり判定を行う。あるいは地形だけ仮想画面に
描くか。
・矩形との当たり判定
天井をたとえば10度傾いた矩形と考える。この矩形をAとする。Aの中心点
を中心として−10度回転させた矩形をBとする。同じように点(atamax,atamay)
を回転させた架空の点の座標を(kakuux,kakuuy)とする。
あとは普通に傾いてない矩形の当たり判定(Bと(kakuux,kakuuy)の当たり判定)
を行うだけ。足と地面も同様。サイン、コサイン、アークタンジェントが分かれば
できる。 ビリヤードの玉のように、円形のオブジェクトが
同じ円形のオブジェクトに当たって弾き飛ばすような
移動の仕方って、どうすればいいんでしょうか? >>75
衝突距離が出しやすいから矩形よりも簡単だったりする。
接線での水平成分、垂直成分それぞれの速度の変換を行う。高校数学(三角関数)と物理なんだが。
食い込んだ分の補正をするとなお良し。 角度を付けた移動ってどうやるんですか?45度だったら
x=x+45
y=y+45
でいいんですか? 高校の(今は中学か?)教科書嫁
というのはなんなのでヒントだけ
x = x + v * cos(angle)
y = y + v * sin(angle) せめて足すんぢゃなくてXょうゃ…
75は角度なんでそのまま使ったらヤバいょうな気がする;
角度たら360°ダロ?
75÷360ぽくね!?
少数点だし…ナンカ上手く曲がりソウぢゃん!?
こんな感じでゲームを創ってたアノ頃………
(涙)
>>79
#define RAD 3.14159/180
って定義しておいて、
x+=cos(45*RAD)*speed;
y-=sin(45*RAD)*speed;
でいけると思うよ。
質問させて下さい。
ユーザーに手書きで図形を書かせ、
それが丸なのか四角形なのか三角形なのかを判別したいのですが
どのようなアルゴリズムが考えられますでしょうか? ふたつかんがえた。もちろん使ったことはない。
・描画速度の変化をみる
(角を描くときに速度が落ちるので、2回落ち込むと三角形とか)
・描かれた線の接線のむきの分布みる
(三方向にピークが出ると三角形、とか)
・グリッドを作って通過するポイントで判定(文字認識?)
・マウスの移動方向をxyの変化量で8つに分ける(マウスジェスチャ?)
俺も作ろっと 縦スクロールシューティングゲームを作ってるんですが、
敵の出現のやり方がいまいち分かりません。
今までは、マップを描画したときに、
敵の情報があったら、同時に表示して、その敵の情報を削除
してました。
何か、いいアルゴリズムがありましたら、教えてください。 #define MAX_X 20
typedef struct _Map{
int ShowX;
int ShowY;
int Type;
int Hp;
int X;
int Y;
}_Map;
_Map Map[MAX_X][500];
void ShowEnemy(int ScY,MapChip Map)
{
for(i=0;i<MAX_X;i++)
{
if(ScrollY==Map[i][ScrollY/16].ShowY)
{
switch(Map[i][Scroll/16].EnemyNuber)
{
case 1:
CreateEnemy(i*16-ScrollX,0,1,3);
break;
case 2:
CreateEnemy(i*16-ScrollX,0,2,5);
break;
…
default:
break;
}
}
}
} ちなみに、CreateEnemyの引数は、X座標、Y座標、敵番号、耐久力だ。 >91
発生する時刻と座標のテーブル持ってればいいんじゃないの?
今、C言語でシューティングゲーム作ってるんですが、
連続した弾の出し方が分かりません。教えてください。
専門学校の先生には、配列を使えと言われたのですが、
よく分かりません。
今、作成している途中のソースコードを書きます。
void Shot(void)
{
for(i=0;i<100;i++)
{
if(Bullet[i].flag == 0 && Bullet[i].type == 0)
{
Bullet[i].flag = 1 ;
Bullet[i].x = (Jiki.x+Jiki.x+Jiki.width) / 2 ;
Bullet[i].y = Jiki.y ;
}
}
}
void KeyCheck(void)
{
if(GetAsyncKeyState(VK_SPACE)<0){ Shot(); }
} それだと一回ボタン押したら毎回100発の弾が重なって発射されるけど、それでいいの?
どうしたいの? >>97 さん
ある程度、間隔を置いて、発射させたいんですぅ。
毎回、100発の弾が重なるのは、耐え難い事実なんです。 大金を払い専門的な職業訓練を受けているはずの学生がこんなことすら自力で出来ない
「耐え難い事実」というならむしろこれw >>98
60フレーム/秒でKeyCheckは毎フレーム呼ばれるの? >>96
if文の中の最後にbreak;入れると幸せになれるぞ 適切なスレが見つからないのでここで質問させてください。
携帯電話アプリのシューティングを作っているのですが、
2D描画の処理を軽くする方法がわかりません。
個々のgifファイルを軽量化してみたりもしましたが、効果があるのかどうか分からないくらいです。
クリッピング領域を指定する方法もあるようですが、いまいちよく分かりません。
他に効果的な方法は無いものでしょうか。 >>102
画像の数を減らして、同じ画像を使いまわすとか、
1秒間あたりの描画回数(FPS)を減らすとか。
あとは、一画面に同時に出現するオブジェクトの数を減らすとか、
背景のスクロールをあきらめるとか、
あと、ベンチマークツールがあればそれを使って、
ボトルネックとなっている処理(メソッド/関数)を分析してみるとか。
>>102
プログラム実行中は結局ビットマップでメモリに保持させてるから効果がないと思うんだが…
予め画像のパレットを全て一緒の256色にしといてパレットを読み込ませないと。 >>103
ありがとうございます。
>同じ画像を使いまわす
試してみようと思います。
これは一箇所に画像を読み込んでおいて、
その画像を使うオブジェクトが描画のたびにそこを参照するようにする、
ということで良いんでしょうか?
他のは、ゲームのバランス調整と平行して考えてみます。
>>102
すいません。そういうことに理解が無いもので・・・。
>予め画像のパレットを全て一緒の256色にしといてパレットを読み込ませないと。
これは良く使われる手法なのでしょうか?
それともgifファイルの軽量化に意味を持たせるための方法なのでしょうか?
どういう風に実装すれば良いのかさっぱり分からないので、後者なら諦めます・・・。
ありがとうございました。 大きな矩形の布地から、サイズの違う小さな矩形の布地を切り取る時、
余りの布面積が一番少なくなるよう、切り取る(小さな矩形を並べる)
アルゴリズムについて書かれた書籍、HP等をご存知でしたら、
教えて下さい。
よろしくお願いします。
>>107
移動するなら移動先を書いてくれ。
実は調べたり考えたりしてたんだが最小公倍数の矩形で
バックトラックするという馬鹿な方法しか思いつかなかったんだ。 >>96
100個程度ならいいですけど配列でもいいかもしれないけど
双方向リストとかを使うようにしたほうがいいかも。c言語だし。
まあこの辺は後ほど。
でも配列を使えとかいう講師に双方向リストを実装して提出したら
うらまれそうw
unsigned int KeyShotFrmCnt = 0; //ショットキーのウェイト用カウンター
↑これはソースの頭のほうに書いてね。
void KeyCheck(void)
{
??if (KeyShotFrmCnt == 0)
??{
???if(GetAsyncKeyState(VK_SPACE)<0)
???{
????Shot();
????(KeyShotFrmCnt = 10;
???}
??} else {
???--KeyShotFrmCnt;
??}
} うは、コピーしたらなんか辺になったorz
void KeyCheck(void)
{
if (KeyShotFrmCnt == 0)
{
if(GetAsyncKeyState(VK_SPACE)<0)
{
Shot();
KeyShotFrmCnt = 10;
}
} else {
--KeyShotFrmCnt;
}
} 2chってスペース空けるの面倒だなw
AAエディタとかで整形してるのか? ↓ポーカーで、誰が有利かを調べるプログラム作りたいんたけど
http://www.pokernews.com/swf/odd_calc_full-v1.1.3.swf
いったいこれ、なにをどうやってこんなに高速に確率計算できるのか、まったくわからない
このプログラムは、近似値じゃなくて↓みたいなドローイングデッドもきっちり表示するし
http://shanbara.jp/gamble/data/zero.png
あらかじめ計算した結果をデータベースにでも叩き込んだのかと思ってるんだけど
それにしたって膨大すぎる 単純に全探索じゃなくて、なんか省略する方法があるんだろうが 誰かクイックソートが挿入法よりなぜ早いのか教えてくれ
クイックソートのほうがめんどくさそうなのに最速とか理解できん・・・ >>113
そのswfをローカルに落として実行してみたら
Odds calculator failed to get data from server.
ってエラーメッセージが出たから、
確立計算専用の外部プログラムを呼び出してるっぽい。 >>115
全部のソートにN*Nの時間がかかるとする。
これを、半分に分けてソートして、足し合わせるとすれば、かかる時間は
(N/2)*(N/2) + (N/2)*(N/2)
= N*N/4 + N*N/4
= N*N/2
N*N > N*N/2
・・・とおもったらクイックソートって2分割って訳じゃないのね?て事で、
分割を、(1/x),(1/y)とする。ただし(1/x)+(1/y) = 1
1 = 1*1 = (x+y)/xy = (xx + 2xy + yy)/xxyy
分割したものをソートして、足し合わせる時間は
(N/x)*(N/x) + (N/y)(N/y)
= N*N/x*x + N*N/y*y
= (yyNN + xxNN) / xxyy
= NN(xx + yy)/xxyy
(xx + yy)/xxyy = (xx + 2xy +yy)/xxyy - 2xy/xxyy = 1 - 2xy/xxyy
ゆえに、NN > NN(xx + yy)/xxyy
こんなんでどうだろうか。というか、この証明あってるんだろうか。 データ数によるんだよね。 少ないデータならどれでも変わらん シューティングゲーム作っているのですが、
私の数学力のなさか、敵の動きが、直線と円を描くものしか作れません
どうやったら、アーケードにあるような あたかも敵が思考を持っているような動きが
実現できるのでしょうか? >>119
敵の動きのカタログ的なものが欲しいなら……。
シューティングゲーム プログラミング ¥ 2,940 (税込)
松浦 健一郎 (著), 司 ゆき (著)
http://www.amazon.co.jp/dp/4797337214 そうではなく、どのようにして さまざまな動きを実現しているのか? その方法を知りたいわけです。
私の敵を動かす情報は 初速度、速度、角度、時間、加速度で管理しているので、直線と円のみになってしまうのです。
そこで、微妙に、プレイヤーのいる方向に向かってきたりする方法は、どのような情報で管理しているのかを
知りたいのです。
私の方法でも角度を細かく設定すれば、ある程度 色々な動きは実現できるのですが、
もっとスマートな方法はないかと思い質問したまでです。 う〜ん、ちょっと違って
人工知能で解決できるのではないかと思うのですが、
人工知能に関する知識がないので、作れないのですが、
オススメの入門書などないでしょうか? >>125
現在位置ベクトル
現在速度ベクトル
目標位置ベクトル
目標位置での速度ベクトル
この条件を満たす加速度ベクトルの時系列を求めればいいんだよね。
でもゲームだから時系列を事前に求める必要はなくて
毎フレームごとに計算するから状態マシンでいけるよ。
2Dシューティングなら普通そうだと思う。
本格的にやるなら確率過程勉強するとおもしろいよ。
実際の迎撃ミサイルがどのように制御されてるか理解できる。 敵の動きが実際にはどういうふうに実装されてるのかを知りたいなら、
>>120みたいな作り方の本が一番実践的だと思うけどなぁ。敵の動きのサンプルもあるだろうし。
STGは本格的に作ったことはないが、普通敵の動きに人工知能なんて使わないんじゃない?
俺だったら毎フレーム状態遷移を計算して、行動を決定するような実装にすると思う。
リアル迎撃ミサイルの精度で敵が弾を撃ってくるSTGとか、やってみたいがストレスがたまりそうだなw Cマガが廃刊になって以来、こういった系統の本で当たりだった試しがない
浅く、レベルも低く、よくこんな本だせたな という本だらけ
立ち読みできないから なおさらタチが悪い
まぁ、状態遷移図で検討します >>125
この手のアルゴリズムは、たぶん正解みたいなものはなくて、
プログラマーのセンスによるんだと思う。
ゲームプログラマーが技術力だけじゃなく、センスを活かせる局面なので、
いろいろ試して自分なりのノウハウを蓄積するのがいいと思う。
ちなみに、この手の処理は、パラメータによる差別化だけじゃなくて、
ちゃんとそれぞれの動きに対して別のコードを書いたほうがいいよ。 シューティングゲームを作っています。
2次元配列に初期化された敵のデータがあります。
int EnemyMap[25][300]=
{
{0,0,0,0,0, 0,0,0,0,0, 0,0,0,0,0, 0,0,0,0,0, 0,0,0,0,0},
{0,0,0,0,0, 0,0,0,0,0, 0,0,0,0,0, 0,0,0,0,0, 0,0,0,0,0},
{0,0,0,0,0, 0,1,0,1,0, 0,0,0,・・・
}}
0が無しで、0以上が敵在りで、敵の番号です。
このような場合の敵の出現方法を教えて下さい。
ちなみに縦スクロールSTGです。お願いします。 0が無しで、0より上が敵在りで、敵の番号です
の間違いでした。 テキトーに推測しながら……
時間経過をターンとする、
25マス(?)のデータが300ターンぶんあるのを表すのなら
int EnemyMap[300][25]
ではないか
gameturn を例えば10フレームごとに +1 し、
{
int i;
for(i=0;i<25;i++)
{
int enemyidx;
enemyidx = EnemyMap[gameturn][i];
if(enemyidx != 0) {addenemy(enemyidx, i);}
}
} >>130
int COLUMN = 25;
int ROW = 300;
int EnemyMap[COLUMN][ROW] = { {0,0,.....
int rowNOW = 0;
while(1)
{
/* 画面描画とか、敵機、自機の移動とか*/
//ここから敵の配置
for ( int x = 0; x < COLUMN; x++ ) {
敵を出現させる関数( EnemyMap[x][rowNow], x, 0 );
}
rowNOW++;
}
void 敵を出現させる関数( int enemyType, int x, int y )
{
switch ( enemyType ) {
case 1: { 敵1登場(x,y); break; }
case 2: { 敵2登場(x,y); break; }
case 3: { 敵3登場(x,y); break; }
case 4: { 敵4登場(x,y); break; }
case 5: { 敵5登場(x,y); break; }
...
}
}
うーん、我ながらほれぼれするなあ。 >>133に
case 0: { break; /* 敵は登場しない */ }
を追加(汗)
そのデータ構造の欠点は
・敵がいてもいなくても同じだけの容量が必要
・同じ時間に敵は1機しか出現できない
あ、ひょっとして勘違いでこの25っていうのは画面の幅のことなのか!?
25x300のマップを表現してるとか 敵が画面横や画面中央から出現するような処理はできないな。 for(i=0;i<25;i++)
{
if( ScrollY == (ScrollY / 32) * 32 )
{
Enemy_temp = StageMap2[i + ( ScrollY / 32 ) * 25 ];
if( Enemy_temp > 0)
{
ShowEnemy( i * 32 , -32 , Enemy_temp , 3 );
}
}
}
でいいんでないの? 俺だったらテキストデータで
E:idx:xpos:ypos:flag
みたいなのを一行づつ読むのを作る、というか実際そうした。
E:1:32:-16
E:1:32:-24
W:30
E:2:64:-16
だったら種類1の敵をx=32 y = -16 と y = -24 に出現さして、30フレーム待って、x=64に敵出現
ゼビウスみたいに背景と連動するにはまた違ったやり方がいいだろうけど 俺も絶対的な配置より、>>139みたいな相対的な配置のほうが好きだな。
後々編隊の出現時刻を変えるときとか、相対時間を調整するだけですむ。
enemy命令、wait命令とか。
作り方はシューティングゲームプログラミングって本に載ってる。
あまりきれいなコードじゃないから余裕があるなら自分で組みなおした方がいいと思うが。
ttp://www.borndigital.co.jp/book/program/4-86246-015-1/index.html
GPGを購入しようと思ってるのですが 1〜5まであって
最新の5を購入しようと思っています 無理して1〜4まで全部買う必要はありませんか? Xi[sai]DXの自動解答ツールでも作ってくれ。
総当り的に解答できるものなのか・・・ >>141
バカカシネヨってぐらい高いよなこのシリーズ まんまスペースハリアーみたいな疑似3Dシューティングゲームを作ってみようと思うのですが
あの手のゲームは絵や映像の技法で言うところの「一点透視法」な画面だと思うのですが
その考えで行くと自キャラが撃つ弾は全て画面中央の一点に向かってしまう事になってしまいます(リアルに考えるとそれで正しい)
スペハリや亜流はその辺をどうやってそれっぽくフェイクしているのでしょうか? やっぱそんなもんか、俺もGEM2までしかもっていない よくわからないけど、画面表示の向きと、画面上の自機の向きをバラバラに考えて、上下左右移動時は時機の向きがそれぞれの方向に慣性付きで移動するようにして、その方向に弾がでるようにすればいいんじゃない? >>147
まず、一点に集中しちゃうのは平行線だけだぜ
よしんば自機の弾が平行にしか撃てないとしても、集中するのは無限遠点だ
ゲーム時間中に到達するのかい ゲーム画面中の10km先と無限の先は何ドットずれるんだい? crysisの四脚の敵とか
モンハンのシェンガオレンみたいのってどうやって作るんでしょう?
アニメーションさせれば平の地面を歩く程度はできると思うんですが
凹凸の地面を歩かせたりするにはプログラムからボーンを調整したりするんでしょうか?
いや、モンハンは分かりやすいかな?程度で出しただけなんで。
IKでやるのは理解してるんですが、
ボーンと地面の判定→先端ボーンの位置を指定→IKで根元までって感じなのでしょうか?
・・・今思うとDirectXの話な気がしなくもない。 自分が理解できない事は全てDirectXが解決してくれる病ですね モンハン並みのものを作れないおまえら雑魚すぎるwww 地面の高さに、モデル空間の座標を合わせるだけだと思うが
それとも、実行時にモデルアニメの計算をするのか
そんな事しないだろう
広大なマップを動き回るシミュレーションみたいなのを考えてて
とりあえずA*というアルゴリズムで2048x2048のマップで
1ドット単位で移動可能としてやってみたら遅くてとても実用的じゃないと判明した
もっと早い方法はあのかな?
マップを小さくしろってのは無しでお願いしますよ
考えてるゲームがマップの広さを利用したものなんで GameProgrammingGemsあたりにあったような気もする。
俺は買ってないけど。高くて。 調べてたらいろいろやり方はあるみたいだ
ちょっといいアイデアを思いついたんで今実験中 あれからいろいろ実験して完全オリジナルのアルゴリズムを考えてやってみた
2048x2048の1ドット単位移動マップで端から端あたりまでの検索の1秒も掛からなくなった
A*を継承してるんで検索漏れはないはず
なにげにすごい発明をしたのかも >>160
オライリーのAIの本のページにサンプルコードがあったはず、探してみな >>160
みつけてきたぞ
O'Reilly Japan - 実例で学ぶゲームAIプログラミング
http://www.oreilly.co.jp/books/9784873113395/
これの関連ファイルにソースコードとサンプルの実行ファイル入ってる ドカポンなどの双六式のゲームで、「おまかせ」というモードがありますよね?
でた目の数で丁度いけるマスを自動検索してくれるというものなんですが、
あれのアルゴリズム分かる方いますか?言語はなんでもかまいませんので
教えていただけないでしょうか。 マップが分岐なし一方通行なら一次元配列で出目を足せばいい。
分岐がたくさんあるなら、マップを二次元配列にするとして、
「ゲーム シミュレーション 移動範囲」を検索し応用。 >>168
SRPGの移動範囲みたいなのはわかるんですが、双六だと途中の経路にループがあったり、
飛ばせるマスがあったりしてそこを含めて出目に丁度合うように移動可能か判定するには
どうすればいいか、そこが今ひとつわからないんです。 それは簡単。印をつけてループしなくさせればいい
たしか移動歩数的なものを記録すればよかったんじゃない いや、ループはさせないとダメでしょ。
桃太郎電鉄でもリニアカードや新幹線カードを使うとサイコロをたくさん振れて
ループも含めて目的の駅に入りやすくなる。
単純に隣接マスを走査していけばいいと思う。
再帰でやれば楽だろう。 とりあえずマップを二次元スクエアとして、シティブロック距離を測定、移動可能距離が足りなかった場合はそこで打切り、
これを基本にして虱潰しにやるというのが一番いいですかね?
あとは直前のマスには戻れない、飛ばせるマスや通過点は移動距離に足して計測、とか細かい点が多いものの
当時のスーファミでも出来るくらいだからどのみち計算量は大したことないんですが リブルラブルやギャルパニ3みたいに「プレイヤーが引いて囲んだ線の内側」って
どうやって判定すればいいんでそ? 「線のどちらが内側か」という問題なら符号付き面積を求める方法があります。
もしくは、「確実に外側である適当な点から最初に線を横切った先は内側」
という判定方法もあります。
2Dアクションゲーム何ですけども、
キャラに引っ張られる様にスクロールさせるにはどうすれば良いでしょう。
常にキャラが中央に来るのではなく、中央から一定距離離れた所からキャラを追う といった感じです。 スクロール境界線を越えた分だけスクロールさせればよいでしょう。 >>176
有難うございます。正にその通りでした。 スーパーマリオブラザーズの様なゲームの場合、
ブロック等を全てスプライトで処理するのは やはり無理がありますよね あまり今のPCのマシンパワーを舐めないほうがいい
表示範囲外のところは勝手に無視してくれたりするんで
最適化とか効率はモノが動いてからでも十分間に合う
まずは思いついた方法、いちばん簡単にコーディングできそうな方法でやってみるが吉 >>179
有難うございます。
とりあえず組んでみる事にしました。 スクロールゲームでの、オフセット方式で座標を更新するとして、
画面のオフセット位置の更新ってどのタイミングでやるべきなのでしょう。
位置はプレイヤーに追従させるとして、プレイヤーの処理後だと プレイヤーの処理中にオフセット位置を用いる処理があればズレてしまうし、
結局どのタイミングでも、完全な同期は無理なのでしょうか。 2Dの無限マップってどうやってデータ保存しとけばいいんだろう
2次元リストだとプラス方向にしか伸ばせないし 簡単にお金が稼げる方法興味ある人だけ見てください。
グーグル検索⇒『来島のモノノリウエ』
FNI7DS9IDU >>184
基本的には動的に生成(プロシージャル)
乱数はパーリンノイズ
変化があったとこだけ差分を記録
見てないところでマジレスする快感
なお正しい方法かは知らん(俺だったらそうするってだけ) せっかくなので補足。
パーリンノイズは、「改良パーリンノイズ」のほう。
改良は、各頂点座標をシードにしたハッシュ値を乱数替わりにするので、
時間的にもメモリ的にもほぼノーコストで、各頂点のベクトルを再現できる。
(各頂点のベクトルを、メモリ等に保存しておく必要がない)
なので、無限マップの任意の座標の地形を、いつでも同じ形に再現できる。 昔のドラクエなどにあるメッセージ表示ってどうやるのでしょうか?
一文字づつ文字が表示されるみたいな。 2Dシューティングのホーミング弾が作れません
外積計算して正負で軸があってるか判断、
それを弾の個数分やるって事であってるんでしょうか もう見てないだろうが、
ホーミング弾の進行方向から見て、目標物が右側にあるのか左側にあるのか調べる。
(弾の移動ベクトルのatan2と、弾から物への方向ベクトルのatan2との比較)
右側にあるなら、ホーミング弾の移動ベクトルを右回転、左なら左回転。
ただし、回転角度には上限を設けないと、カクッと動くことになるw
最近のコンピュータって速いから、こんなもんで十分じゃないかな。。。と妄想w みてます!ありがとうございます
今はホーミング弾の目標が軸の左にあるか右にあるかを外積の正負で判断し、
弾一つ一つをループさせてみています
衝突判定に使う4分木の様な、効率的なアルゴリズムがあったりするのでしょうか 見られてたw
ホーミング弾って、距離離れてても追尾するイメージあるから、
四分木みたいな領域分轄はできないんじゃないかなぁ
処理速度の最適化は、一番重い処理を見極めて、
そこを高速化するのが効果的と思うけど、
ホーミング弾って、回転行列を使うから、
ホーミング角度θに応じたsinθとcosθを、あらかじめ計算しておくって手はあるかも。
(ホーミング角度θは、固定値なはずなので) わざと0.5秒とか一定間隔をあけてホーミングしたほうが
動きがカクカクしないしゲーム難易度的にもいいと思うぞ
(右回転なら右回転を0.5秒続ける) public int Sayu(Pos arg)
{
var buf = arg.posF - posF;
return Lib.GetSeiFu((vecF.X * buf.Y) - (vecF.Y * buf.X));
}
これを貼れと言われた気が。