HSPTV!掲示板

初めて書き込みさせて頂きます。玄冬と申します。

現在HSPを用いてSTGゲームを作成しております。
多数の敵を管理するのに配列は欠かせないものですが、データを管理するときに、一次元の配列を多数作って管理するか、2次元配列を1つ作って管理するかで悩んでいます。

例えば、複数の敵の,X座標,Y座標,HPを配列で管理する場合、
===1次元配列を多数作って管理===
dim teki_x(0) = x0
dim teki_y(0) = y0
dim teki_hp(0) = hp0
dim teki_x(1) = x1
dim teki_y(1) = y1
dim teki_hp(1) = hp1
…

===2次元配列1つで管理===
#enum x = 0
#enum y
#enum hp

teki(0,x) = x0
teki(0,y) = y0
teki(0,hp) = hp0
teki(1,x) = x1
teki(1,y) = y1
teki(1,hp) = hp1
…

質問としては
(1)上の2つには違いがあるのか?
(2)違いがあるのであれば、どこがどのように違うのか?(詳しく教えて下さい。)
(3)STGゲームの敵データの管理としてはどちらがふさわしいのか?

の3点が知りたい情報です。
御回答よろしくお願い致します。

あいまいな回答しかできませんが、
普通、そのような場合は多次元配列（後者）を使いますね。

ひとつの配列にまとめられているので、関連性がわかりやすいですし、

teki(3, HP)
3番の敵の、hp

のように意味が合理的です。

//ただ、多次元配列を使うと#enumがグローバルな関係で、インデックスの指定が長くなり、ゴチャゴチャしてしまうことがあります。
//特に、多次元配列を複数使う場合、起こりやすいです。（teki(0, TEKI_HP), tama(0, TAMA_HP), mikata(0, MIKATA_HP)など

>(1)上の2つには違いがあるのか?
>(2)違いがあるのであれば、どこがどのように違うのか?(詳しく教えて下さい。)
>(3)STGゲームの敵データの管理としてはどちらがふさわしいのか?
　多次元配列の長所
・覚える配列名が少なくてすむ
・セーブルーチンが楽

　多次元配列の短所
・次元数が大きいほど遅い
・高次要素の意味がわかりにくい

　どっちがよいかは好みの問題かもしれません。
私は、分解可能である限り分解します。
３Ｄ座標なんかは分解不可能です。

　dupで両方使えるようにすると、いいとこ取りできるかも。

>・覚える配列名が少なくてすむ
・覚える配列名が少なくてすむ（名前づけルールに悩んだり不統一になったりしにくい）

　結局、配列名が多くなることが苦になるかならないかで
好みが分かれそうですが、誰にでも限界はあるはずなので、
限界を超えると……。

　もしかして、構造体の要望が多いのはこの辺に理由がある？
しかし、それは名前づけルールで解決できるはず。
ピリオドや=>のかわりにアンダースコア（_）とか
キャメルケースとか使えばいいだけだから。

　構造体の定義が名前づけルールを視覚化するところに魅力があるのか？
しかし、これも名前づけルールを構造体の定義のように明文化すればいいだけのはず。

　構造体定義のように義務化されないとやる気にならない？

>多数の敵を管理するのに配列は欠かせないものですが、データを管理するときに、一次元の配列を多数作って管理するか、2次元配列を1つ作って管理するかで悩んでいます。
STGだったら、

dim teki(p1,p2)
p1 敵のインデックス(敵の数だけ増加)
p2 0(HP),1(敵のx座標),2(敵のy座標)

とかいうような2次元配列で管理したほうがいいと思います。
こうすれば、多数の敵にHPを付けやすいと思います。

> dim teki(p1,p2)
> p1 敵のインデックス(敵の数だけ増加)
> p2 0(HP),1(敵のx座標),2(敵のy座標)

例えばこういう記述が出来ます。

dim teki ,3,100		;パラメータの数、敵の数
teki(0,0) = 100, 10, 150	;敵0(HP=100,X=10,Y=10)
teki(0,1) = 100, 20, 150	;敵1
teki(0,2) = 100, 30, 150	;敵2
mes "HP:"+ teki(0,0)
mes "X=" + teki(1,0)
mes "Y=" + teki(2,0)

repeat 3
	dup a,teki(0,cnt)
	mes "敵(" + cnt + ")：HP="+a(0)+", (x,y)=("+a(1)+", "+ a(2)+")"
loop

dupを使うと記述がシンプルになっていい感じです。

皆様ご回答ありがとうございます。

やはり2次元配列管理がお勧めのようですね。大変参考になります。
ただ、何名かの方が仰られている命名や意味的なことに関して言えば、パラメータを名前にした配列を作るのも、パラメータをマクロで定義して添え字にするのも、意味性、命名の手間、などの観点ではあまり変わらないように思えてなりません。

>GENKIさま
なるほど!そのような代入形式がサポートされているのですか。他の方の仰る管理が楽と言う漠然とした表現では理解できなかったのですが、例を示して頂けて助かります。これは楽だ…
例でp2を敵の数、p1をパラメータにしているのは、この代入方式の仕様にあわせてでしょうか?
dupはANTARES様も仰っていますが使い勝手が良さそうでいい物を教えて頂けました。

>ANTARESさま
セーブルーチン！確かに変数一つセーブすればいいから楽になりますね。ボードゲーム系の盤面保存とかに良さそう…
…構造体ですか…確か"変数型混在の配列のようなもの"だったでしょうか?HSPではサポートされていないんですよね？HSPは始めたばかりでよくわかっていないんですが…

>tsukaさま
差し出がましいかもしれませんが、TEKI_HP、TAMA_HP、MIKATA_HPに分けず添え字を統一して#enum HP = 0 等とすればその問題は解決できるように思います。

もう少し構造的な違いについても知りたいです。
例えば長さがnの一次元配列を2つ作るのと、n*nの長さの二次元配列を作るのではメモリ容量や処理時間に差は出ますか?(nは適当な数)
dim A,n dim B,n <=> dim C, n, n

>例えば長さがnの一次元配列を2つ作るのと、n*nの長さの二次元配列を
>作るのではメモリ容量や処理時間に差は出ますか?(nは適当な数)
　メモリ容量は多少二次元配列が有利ですが、無視してもいいくらいの微量です。

　処理時間については言及済みですが、体感できるほどかどうかは
試してみないとわかりません。シューティングは最も高速性を要求される
ジャンルなので、体感できる可能性が高そうです。
てゆうか、HSPで作ろうとするのは無謀かも。

>dim A,n dim B,n <=> dim C, n, n
　勘違いしているようです。
dim A,n dim B,n <=> dim C, 2, n

ぬぁっ！！ホントだ！パラメータ2個しかないのにn*nの配列作る意味ないですね…

すばやいご回答ありがとうございます。
メモリ容量より処理速度が問題ですか…検討してみます。

皆様どうもありがとうございました。
まだまだ作業が進むにつれ疑問は湧いて来そうですが、これにて解決済みとさせて頂きます。
また何かありましたら、質問させて頂きます。その時はどうぞよろしくお願い致します。