横スクロール型ゲーム/スクリプト

スクリプトのアップについて †

[編集]

長いスクリプトをアップする場合は、ファイルにしてアップするようにしてください。
長いスクリプトを表示させる場合はスクリプトを直接書き込むのではなく、ファイルをアップして次のように記述してください。

&ref(pic/hsp3.png);~
#region(スクリプト)
#code(スクリプト01.as)
#endregion

のように記述することで、ダウンロードもスクリプトの表示も同時に出来ます。

スクリプトを直接書き込むとTabがスペースに置き換わってしまったり、ページの編集がしにくくなったりなどの弊害が発生します。
直接実行できないものや短い説明用のサンプルなど以外はできるだけファイルを使ったほうがいいでしょう。

↑

要素別開発 †

[編集]

↑

キー入力・キー操作 †

[編集]

入力装置

キーボード：最低限対応する必要あり。
ゲームパッド：出来れば対応したほうがいい。
マウス：特殊な場合を除いて対応する必要はない。

stickでもボタン数は足りますが、getkeyの方が押しやすいキー選べるからgetkeyの方がいいんでしょうか。

↑

NPCの制御 †

[編集]

つまり敵キャラクターの移動方法についてです。

これは基本的なキャラクターの操作用命令をそろえてしまえば簡単かなと思います。PCを操作するときと同じように記述するだけなので。 - GENKI?

↑

当たり判定 †

[編集]

パタパタ大王さん作成の当たり判定のスクリプトです。

当たり判定

一行だとちょっと見にくいので…

変数の内容
x - 座標
vx - 速度
chipw - キャラクターXサイズ
con - 当たり判定の結果

当たり判定のメイン部分

 
-
-
-
-
|
|
|
|
-
-
|
!
!
!
!
!

;	右へ移動した場合の当たり判定
if x.0+vx.0+chipw.0 >= x(cnt+1)+vx(cnt+1) {
    if x.0+vx.0+chipw.0-vx.0+vx(cnt+1) <= x(cnt+1)+vx(cnt+1) {
        if y.0+vy.0+chiph.0 > y(cnt+1)+vy(cnt+1) {
            if y.0+vy.0 < y(cnt+1)+vy(cnt+1)+chiph(cnt+1) {
                x.0 += x(cnt+1)+vx(cnt+1)-(x.0+vx.0+chipw.0)
                x.0 += vx.0
                vx.0 = 0
                con(0) += (cnt+1)
                if flag&4 {
                } else {
                    flag+=4
                }
            }
        }
    }
}

軽い解説

当たり判定のルーチンについて経緯と解説を加えます。が、２つの疑問があると他のページで書いたわたくしが解説するということを改めて確認してください。教えることを通じてわたくしも教わりたいと思っています。
ループ中のひとつ目の行は右への判定で、４つの条件式とx軸方向の位置への加算とx軸方向の速度を0にすることとフラグ等のパラメータを出すようになっています。
右への判定が出来たら左への判定は左右の方向に関わる条件式のプレイヤーと対象の変数を交換したらできるし、上下は左右の判定でのxをyに、yをxに換えれば出来るので、右への判定だけを解説します。

右への判定の一行を３つに分けていますが、まずはスクリプトに載っているものを眺めてください。この一行目がx方向についての条件式で、二行目がy方向についての条件式、三行目が当たっている場合の処理です。

;                                                              :     幅      :
if x.0+vx.0+chipw.0 >= x(cnt+1)+vx(cnt+1) : if x.0+vx.0+chipw.0-vx.0+vx(cnt+1) <= x(cnt+1)+vx(cnt+1) : 
if y.0+vy.0+chiph.0 > y(cnt+1)+vy(cnt+1) : if y.0+vy.0 < y(cnt+1)+vy(cnt+1)+chiph(cnt+1) : 
x.0+= x(cnt+1)+vx(cnt+1)-(x.0+vx.0+chipw.0) : x.0+=vx.0 : vx.0=0 : con(0)+=(cnt+1) : if flag&4 : else : flag+=4

x.0　x.0+chipw.0 x(cnt+1) x(cnt+1)+chipw(cnt+1)
■□□□□■　　　　　■□□□□■
□□□□□□　　　　　□□□□□□
□□□□□□　―→　□□□□□□
□□□□□□　　　　　□□□□□□
□□□□□□　　　　　□□□□□□

速度vxを省いた上の一行目を示します。

if x.0+chipw.0 >= x(cnt+1) : if x.0+chipw.0 <= x(cnt+1) :

な、なんと、これではx.0+chipw.0とx(cnt+1)が同じ場合しか当たりと判定されません。ひとつ目の条件式はプレイヤーの右端が対象の左端を越えるということですね。しかしこれだけだと、対象の遥か右側にいても当たりと判定されてしまうので、幅を決めようということになります。それがふたつ目の条件式に加わるとこうなります。

if x.0+chipw.0 >= x(cnt+1) : if x.0+chipw.0 <= x(cnt+1)+幅 :

これなら幅より右側にいて当たりと判定されることはありません。そして幅を具体的にどういう値にするのかということに考えが移りますが、その前にここで速度vxをまた加えてみたいと思います。この速度vxが持つ意味は、メインルーチンで対象（敵・マップチップ）の速度操作、プレイヤーの速度操作、そしてその後に当たり判定がされて、速度を位置に加算するという関係上、位置と加算して次の新たな位置を示すものです。もし当たっている判定ならその速度vxを0にすることで次の新たな位置に移さないという処理がされているわけです。位置と速度は対にして考えて良いです。

if x.0+vx.0+chipw.0 >= x(cnt+1)+vx(cnt+1) : if x.0+vx.0+chipw.0 <= x(cnt+1)+vx(cnt+1)+幅 :

位置と速度を対にしました。そして幅ですね。因みにこの一行は完成形と幅以外同じです。
わたくしは始めは幅を対象のx方向の長さの半分にしていました。しかしそれでは速度が対象の長さを超えた場合、一度も当たり判定に引っかかりません。ここで段々分かってきます。幅は固定ではだめだと。そしてプレイヤーの速度を幅にすれば良いと辿り着きます。それなら光の速さで移動しても光と同じだけの幅で必ず当たり判定に引っかかります。この段階のスクリプトはこうです。

if x.0+vx.0+chipw.0 >= x(cnt+1)+vx(cnt+1) : if x.0+vx.0+chipw.0 <= x(cnt+1)+vx(cnt+1)+vx.0 :

その幅である+vx.0を左辺に移項させたのがこうです。

if x.0+vx.0+chipw.0 >= x(cnt+1)+vx(cnt+1) : if x.0+vx.0+chipw.0-vx.0 <= x(cnt+1)+vx(cnt+1) :

これで対象が止まっていればどんな速さでも長さでも判定できます。つまり動いている対象にはうまく判定できなかったということですｗ
しかし後はプレイヤーの速度を幅に取り入れたから対象の速度も取り入れたら良いだろうと思って-vx(cnt+1)を入れて失敗、+vx(cnt+1)を入れて成功しました＾＾；　それが完成形です。

x.0+= x(cnt+1)+vx(cnt+1)-(x.0+vx.0+chipw.0) : x.0+=vx.0 : vx.0=0 : con(0)+=(cnt+1) : if flag&4 : else : flag+=4

次に三行目ですが、プレイヤーの右端と対象の左端の、次の新たな位置同士の差をプレイヤーの位置に加算しています。これでプレイヤーの右端と対象の左端が接するはずです。
なぜ位置の操作が必要かというと、極端な例で、1*1の対象に1ルーチンに400進む速さで進入した場合、当たりと判定して速度vxを0にするだけだとプレイヤーと対象の位置の差は400より下に必ずなってしまうだけだからです。速度が0になってまたそこから加速していってまた当たって速度が0になって・・・を繰り返してちょうど位置の差が0になるか余りが出てしまうかです。
ところで、 : x.0+=vx.0 : vx.0=0ですが、よくわかっていません。前は : x.0+=vx.0 : vx.0=0はなかったのですが、例えば右にずっと移動して当たっていて対象と接する位置にずっとなっているのに速度は最大速度までずっと上がっているのはおかしいので : vx.0=0を付けたのですが、おかしくなりました。差を確認すると見慣れた数、つまりvx.0だったのでさらに位置に加算しました。それで上手くいきました・・・。＾＾；
未だに素晴らしさと疑問が残っていますね。以上軽く解説するはずの長い解説でした。

当たり判定改良版

*atari			;当たり判定
	flag=0 : dim con,4
	repeat num-1
		;                                                              :     幅      :
		if x.0+vx.0+chipw.0 >= x(cnt+1)+vx(cnt+1) : if x.0+vx.0+chipw.0-vx.0+vx(cnt+1) <= x(cnt+1)+vx(cnt+1) : if y.0+vy.0+chiph.0 > y(cnt+1)+vy(cnt+1) : if y.0+vy.0 < y(cnt+1)+vy(cnt+1)+chiph(cnt+1) : vx.0= x(cnt+1)+vx(cnt+1)-(x.0+vx.0+chipw.0)+vx.0 : con(0)+=(cnt+1) : if flag&4 : else : flag+=4
		if x.0+vx.0 <= x(cnt+1)+vx(cnt+1)+chipw(cnt+1) : if x.0+vx.0-vx.0+vx(cnt+1) >= x(cnt+1)+vx(cnt+1)+chipw(cnt+1) : if y.0+vy.0+chiph.0 > y(cnt+1)+vy(cnt+1) : if y.0+vy.0 < y(cnt+1)+vy(cnt+1)+chiph(cnt+1) : vx.0= x(cnt+1)+vx(cnt+1)+chipw(cnt+1)-(x.0+vx.0)+vx.0 : con(1)+=(cnt+1) : if flag&1 : else : flag+=1
		if y.0+vy.0+chiph.0 >= y(cnt+1)+vy(cnt+1) : if y.0+vy.0+chiph.0-vy.0+vy(cnt+1) <= y(cnt+1)+vy(cnt+1) : if x.0+vx.0+chipw.0 > x(cnt+1)+vx(cnt+1) : if x.0+vx.0 < x(cnt+1)+vx(cnt+1)+chipw(cnt+1) : vy.0= y(cnt+1)+vy(cnt+1)-(y.0+vy.0+chiph.0)+vy.0 : con(2)+=(cnt+1) : if flag&8 : else : flag+=8
		if y.0+vy.0 <= y(cnt+1)+vy(cnt+1)+chiph(cnt+1) : if y.0+vy.0-vy.0+vy(cnt+1) >= y(cnt+1)+vy(cnt+1)+chiph(cnt+1) : if x.0+vx.0+chipw.0 > x(cnt+1)+vx(cnt+1) : if x.0+vx.0 < x(cnt+1)+vx(cnt+1)+chipw(cnt+1) : vy.0= y(cnt+1)+vy(cnt+1)+chiph(cnt+1)-(y.0+vy.0)+vy.0 : con(3)+=(cnt+1) : if flag&2 : else : flag+=2
	loop
	return

変えたところは判定の後の処理部分。速度しか操作していません。わたくしにはもう理想形です。
当たりと判定されると、プレイヤーの次の右端の位置と対象の次の左端の位置の差が0になるように調整された長さを、
1ルーチンに進む長さ＝速度として改めて代入するけど、次のルーチンでは位置の差が0なので速度は0から変わらないという仕組みです。

↑

[参考]当たり判定その２ †

[編集]

矩形同士限定。
上のパタパタ大王さんのスクリプトをもとに判定部分を別の方法にしたもの。
(差し替え。一般的にはこんな感じで行うと思う。 --naznyark 2006-02-14 (火) 01:33:14)

当たり判定_r.hsp

↑

基礎フォルダ20060319用基礎スクリプト当たり判定改造版 †

[編集]

対応する基礎フォルダにいれて実行してください。 -- naznyark? 2006-03-23 (木) 02:54:44

基礎スクリプト2_r2.hsp

↑

描画 †

[編集]

キャラクターアニメーション
この項目なんにもないのでとりあえず、キャラクターのアニメーションのサンプルでもどうぞ。

スクリプト

mca001.as

;
;	アニメーションサンプル
;
;2006/02/09
 
 
screen 2
picload "chara00.bmp"    ;ファイルが必要です。
gsel 0, 1
chracnts = 1
chrPNum = 2    ;キャラクターの向き
mv = 5
 
 
gmode 2,32,32
*main
    redraw 0
        color 255,255,255 : boxf : color 0,0,0
 
        stick key, 15
        if key&1 : px-=mv : chrPNum = 3
        if key&4 : px+=mv : chrPNum = 1
        if key&2 : py-=mv : chrPNum = 0
        if key&8 : py+=mv : chrPNum = 2
        if key&128 : goto *owari
 
        pos px, py
 
        ;アニメーション用カウント
        chrcnt2++
        if chrcnt2>5 : chracnt+=chracnts : chrcnt2 = 0    ;６ループに１コマアニメーション
        if chracnt>2 : chracnt-=2 : chracnts =-1    ;アニメーションは0～2の3コマ。
        if chracnt<0 : chracnt+=2 : chracnts = 1
 
        ;アニメーション表示
        gcopy 2, chracnt*32, chrPNum*32
 
    redraw 1
    await 17
goto *main
 
 
*owari
end

実行には画像ファイルが必要です。&ref(): File not found: "chara00.bmp" at page "横スクロール型ゲーム";
基本方針は、他ウィンドウからのコピペ。後はこれを汎用化（モジュール化）すればokでしょうか？もっと早くなる方法ありますか？ - GENKI?

↑

背景描画 †

[編集]

背景を何層かに分けて奥行きを表現するとちょっと重くなるようです。
解決案

背景固定（地面とかと一緒に動く）にしてしまう。
DirectXを使用する。
その他　
参考資料：小ワザ/マップスクロール

↑

セレクト画面 †

[編集]

タイトル画面やゲーム開始前のセレクト画面（こんな呼び方であってるのかな？）について。

参考資料
アイテム選択欄 - 参考になりそうでならなさそう。(笑　- GENKI?

↑

マップロード †

[編集]

マップデータのフォーマットについては横スクロール型ゲーム/マップフォーマットで検討中です。 3/13現在は、データの読み込み＆保存モジュールのサンプルが出来ています。参考にどうぞ。 --GENKI?

↑

マップエディタ †

[編集]

HSP3 用(ベータ版)
わざわざ作らなくてもその辺にありますが・・・
横スクロール型ゲーム専用でなく汎用品です。

まだまだ機能は少ないですが、実用上の最低限(未満)の機能はあります。 --naznyark? 2006-02-15 (水) 02:16:05
マップデータ仕様を決定。ロード機能追加。 --naznyark? 2006-02-16 (木) 01:36:10

mapeditor.hsp

↑

その他 †

[編集]

他にも項目あったらどうぞ。

↑

プラグイン・モジュール †

[編集]

DirectSound?対応プラグイン
- 作者：うにたま
  HSP MULTIMEDIA (HMM.DLL)
  http://onionsoft.net/hsp/hsp2ex3.html
- 作者：MIA
  HSP DirectSoundExtension?
  http://mia.taillove.jp/

↑

参考資料 †

[編集]

ジャンプアクションゲームの参考になりそうな資料。
小ワザ/アクション/基本動作
 小ワザ/アクションゲーム/ジャンプアクションゲーム
 衝突判定

↑

コメント †

[編集]

同種機能のスクリプトは重複させないのがルールのようなので問題ありなら削除してください。
あと作りかけのものだけどこのあたりからがつらいので暫定公開。画面描画の参考にでもしてください。
2djumpact_p.hsp -- naznyark? 2006-02-08 (水) 01:42:53
マップエディターですが、77行目のWindowFromPoint? POINT0(0), POINT0(1)でエラーが出てしまいます。マップロードをわたくしの基礎スクリプトに取り込みました。 -- パタパタ大王 2006-02-16 (木) 10:41:17
原因判明。古いHSP3.0 に同梱の user32.as 内の記述ミス。
対応版をアップしておきましたが、本当なら本体を 3.0a に更新することを推奨したところです。
(あれ 3.0a って今は無いのか? 今ダウンロードできる 3.0 は 3.0a 相当のものなのかな?) -- naznyark? 2006-02-17 (金) 03:16:17
HSP3.0を改めてダウンロードしてマップエディターがちゃんと動作しました。いい感じでした。ところで構想なんですが、背景のグラデーションと得点等の表示以外は全てチップとして扱っていますからマップエディターから進んでステージエディターという感じを考えています。マップエディターならチップの要素の内、位置と幅と画像インデックスしか扱っていないと思いますが、ステージエディターではその他に重力を受けるかや移動方法などの要素も指定できるものです。問題はマップデータ改めステージデータの構造だと思うのですが、簡単に思い付くのは1行に1つのチップのデータを置くというものです。csv形式がいいかな。それなら簡単に要素の追加もできそうです。 -- パタパタ大王 2006-02-17 (金) 10:27:01
エディターの出力フォーマットですが、こんなのはどうでしょうか？ -- GENKI? 2006-02-26 (日) 18:26:59
横スクロール型ゲーム/パタパタラボで考えておきます。 -- パタパタ大王 2006-02-26 (日) 19:29:05
必要なパラメータをだいたい検討してもらえれば読み取り用モジュール作ってみます。あとからパラメータが少々増減しても大丈夫なようにはするつもりです。 -- GENKI? 2006-02-26 (日) 20:20:40
ありがとうございます。csvの一行目はステージ独自のパラメータを指定するのは良いですね。ステージ名やステージの幅や重力加速度やBGMのエイリアス名などを指定すると思います。チップの要素の内イベント・アクションだけは文字列として取る必要があると思います。あとからパラメータが少々増減しても大丈夫なようにするというのはどういう感じなのでしょうか。それが出来るならとても助かります。パラメータは横スクロール型ゲーム/パタパタラボの「別ファイルで初期化するチップデータ」として大体の感じをまとめています。 -- パタパタ大王 2006-02-26 (日) 21:23:36
とりあえず基礎フォルダ20060222.lzhではいったんprmに全パラメータを掘り込んだ後に各変数に振り分けていたので、そういう感じで使えるようにしようかなと構想中。つまり使うときは今までどおりprm変数から各変数に振り分けるだけ。…になるはず。まだできてません。 -- GENKI? 2006-02-26 (日) 23:36:58
基礎スクリプト2_r2.hsp使ってみました。妙に重いです。(オリジナル37fpsに対してr2は17fps。） -- GENKI? 2006-03-23 (木) 21:40:24
ところで、プレイモードの存在にさっき気が付きました。もっとちゃんと検証しとくんだった。 -- GENKI? 2006-03-23 (木) 21:43:24
遅いのはアップしたものが await 50 まわしの理論最大 20 FPS の仕様になっているからです。
(*main) の中の await 50 を await 16 にすれば理論最大 60 FPS のオリジナルと同仕様になります。
(それでもオリジナルよりは遅いと思いますが) -- naznyark? 2006-03-24 (金) 02:46:04
さっき私も基礎スクリプト2_r2.hspを使ってみました。await 20にしたらFPSは33で安定していました。オリジナルより速いし素晴らしいです。 -- パタパタ大王 2006-03-24 (金) 17:30:24
動作速くなりました。(^ ^;　当たり判定の修正がよく効いていますね。不動チップ重なり時の速度低下no回避確認しました。 -- GENKI? 2006-03-24 (金) 22:13:29
私がアップした古いバージョンの基礎フォルダ用のスクリプトを削除してページも整理しました。 -- naznyark? 2006-04-03 (月) 01:51:24
私がアップした古い添付ファイルを削除。 -- naznyark? 2006-06-10 (土) 02:09:40
当たり判定についてちょっと提案があります。
pgetなどであらかじめ二次元配列に、透明色部分は0それ以外1という風に形をインプットしておき、
1で出来た部分の端で判定を行う。
無理かもしれませんが -- アキス 2007-05-05 (土) 16:53:01
キャラクタごとの輪郭で判定するということですか?
このタイプのゲームではほとんど利点がないように思いますが。 -- naznyark? 2007-05-06 (日) 00:38:23
そうですよね・・・・、本当に頭が悪いものなので・・・ -- アキス 2007-05-11 (金) 17:10:33
あ、でも、丸いキャラとかいたら -- アキス 2007-05-15 (火) 19:29:40
Enter押しちゃったorz
（↓これが本物です。↓）
あ、でも、丸いキャラとかいたら角とかの空白に当たったときに判定されるのを阻止できますが・・・ -- アキス 2007-05-15 (火) 19:31:56
それと、この企画に参加したいです！ -- アキス 2007-05-15 (火) 19:32:46
今別のパソコンでやってるんですが。
あと、ところどころファイルが表示できなくなってますよ。 -- アキス 2007-05-15 (火) 19:34:33
参加は自由です。たぶん。ただ現在は中心になって動いていたパタパタ大王さんの姿が見えないので、企画を牽引する人がいない状態です。まあ、牽引役は誰がやってもいいと思います。 -- GENKI? 2007-05-15 (火) 22:11:34
それじゃぁ、naznyarkさんかGENKIさんか両方かですね。
僕には無理です -- アキス 2007-05-16 (水) 18:44:02
あと、当り判定とか仕様とか勉強するので、しばらく来ないかもしれません。 -- アキス 2007-05-16 (水) 18:44:47
もひとつ。
VisualStudio?買ってVC++やるので、しばらくきません。 -- アキス 2007-05-16 (水) 19:42:22
>それじゃぁ、naznyarkさんかGENKIさんか両方かですね。いえいえ今のところはアキスさんが有力候補者。理由…書き込みの日付と発言数。　あ、でもこれないなら無理か。 -- GENKI? 2007-05-16 (水) 23:24:30
といっても、毎日来るのですが。
しかし、当り判定が理解できません。なので、アイディア等 -- アキス 2007-05-18 (金) 16:16:26
となると、僕が牽引役！？ -- アキス 2007-05-18 (金) 16:17:18
となると、僕が牽引役！？ -- アキス 2007-05-18 (金) 17:09:01
あぎゃ！、二重送信だ！ -- アキス 2007-05-18 (金) 17:09:59
当たり判定は他のページにも解説あるからそっちを見るのもいいかも。こことかここですね。基本は似たようなもんだよ。 -- GENKI? 2007-05-19 (土) 15:01:29
わかりました。見て見ます。
それと、自作の当り判定を作ってみる予定なのですが、
公開するとしたら、どの項目がいいのでしょうか？ -- アキス 2007-05-19 (土) 20:53:35
汎用的なものなら衝突判定、ここの横スクロール型ゲームのサンプル郡に組み込める（組み込むために作った物）ならこのページの当たり判定がいいんじゃないでしょうか。 -- GENKI? 2007-05-19 (土) 21:24:43
一応、キャラクタの四隅で判定するやつを作ったのですが、出来ませんでした。
一応掲示してみます。なので意見お願いします。 -- アキス 2007-05-19 (土) 22:54:59
理解できていないことがあるのに完成形を目指したプログラムを書くのは無理があります。
まずは理解できていないことを理解するためのプログラムを書き、いろいろ試すのが良いと思います。
test1.hsp,test2.hsp
上のプログラムで使用している数値の意味がわかれば、提示したスクリプトでやろうとした当たり判定はどういう意味の処理をやっているのかがわかると思います。 -- naznyark? 2007-05-20 (日) 02:49:43
わかりました。公開一時停止させ、実用できるほどとなったら、また公開します。 -- アキス 2007-05-20 (日) 11:40:06
test1.hspの方は理解できました。test2.hspのほうも探ってみます。 -- アキス 2007-05-20 (日) 11:46:58
test2.hspの方は、
「右上に表示される数値は、各々の四隅で判定したマス目の位置wo -- アキス 2007-05-20 (日) 11:48:48
あ、失礼しました、誤送信してしまいました。 -- アキス 2007-05-20 (日) 11:49:17
test2.hspの方も大分理解できました。当り判定の方を再度読んでみます。 -- アキス 2007-05-20 (日) 11:50:16
当り判定_r.hspを読んでみましたが、いまだにわかりません。
なので、色々試行錯誤して、作ってみます。 -- アキス 2007-05-20 (日) 11:54:38
当たり判定_r.hsp は使用しているアルゴリズムが異なるので test1,test2 では参考になりませんよ・・・。 -- naznyark? 2007-05-21 (月) 00:37:10
あ、そうでしたか。じゃぁ・・・どれを・・・（お馬鹿な奴なので・・・） -- アキス 2007-05-21 (月) 13:41:09
当たり判定_r.hsp で使用しているアルゴリズムの説明対応する四辺が平行な矩形同士の交差判定 -- naznyark? 2007-05-22 (火) 01:52:36