横スクロール型ゲーム/コメント2

最終的なビジョンが見えてるので、参加しようかなと。いままで長続きしなかったから短期決戦かな？
でもステージなんて作らなくていいような？画像は後ですよね？ -- Charlotte 2006-01-23 (月) 17:16:41
なにやらよいアイデアですね。１ステージ１人で作って、あとから合体させて個人では難しいボリュームの作品に…。ってイメージでいいのかな？足を引っ張る不安もないのに加えて、モジュールや音や画像の素材、ストーリーやキャラクター設定などなどが共有できるから１人でやるより効率的っぽいですね。 -- GENKI? 2006-01-23 (月) 22:14:44
タイトルを変更しました。 -- パタパタ大王 2006-01-23 (月) 23:35:02
Charlotteさん、参加ありがとう！！　GENKIさんも参加ということでＯＫですか？ -- パタパタ大王 2006-01-23 (月) 23:36:32
画像は後からでもいいかもしれませんね。１ステージ１人で作ってあとから合体させるイメージでＯＫです。パタパタ大王のアイディアをちょっとまとめてみたいと思います。 -- パタパタ大王 2006-01-23 (月) 23:39:50
正直どうしようか迷ったままでの書き込みだったんですが…背中を押されてしまった。　どこまで出来るか分かりませんが…とりあえず参加してみます！ -- GENKI? 2006-01-24 (火) 20:06:51
GENKIさん、参加ありがとう！！ -- パタパタ大王 2006-01-24 (火) 22:13:13
「アイデア」を整理しやすいように部類分けしました。設定を中心に適当に書き込んでみましたが…恥ずかしいのでアイデア追記お願いします。 -- GENKI? 2006-01-25 (水) 00:25:48
整理どうもありがとうございます。把握しやすくなりましたね。ところで「横スクロール型シューティングゲームを作ろう」ってありますがマリオはファイアボールを投げるからシューティングということですか？飛行機で弾を発射するようなシューティングのイメージではないですよね？もちろん後からみんなで決めることですが今は基本は踏んで敵を倒すような感じでイメージしています。一応確認のために＾＾； -- パタパタ大王 2006-01-25 (水) 01:09:06
間違えましたorz　どうにも、マリオタイプ＝シューティングと思い込んでいたくせがぬけずに、アクションとしりつつ間違えてしまいました。調べたのになぁ…。(*-_-* -- GENKI? 2006-01-25 (水) 21:15:45
あまりよくは考えてないけど、メインルーチンの中に新規命令を入れるだけで敵キャラクターがプレイヤーを攻撃したり倒れたりとかの判定と処理が出来たらいいな。どこまでマクロを組めるかということかな。これから頑張って探してきたおすすめBGMをアップしておきます。そういえばそのことで思い浮かんだのがフォルダの階層構造のことです。何時かは決めた方が良さそうです。 -- パタパタ大王 2006-01-28 (土) 22:43:39
うーん活気がない。(^ ^;　逃げ出したくなるほどに淋しいですね。 -- GENKI? 2006-01-29 (日) 18:31:11
簡単で拡張しやすいシステムにして魅力的なものになると参加したい人も出てくるでしょう。まずはみんなが簡単に拡張するための基礎ですね。 -- パタパタ大王 2006-01-30 (月) 00:03:05
そういえばパタパタ大王さんのプログラミング経験は？ -- GENKI? 2006-01-30 (月) 20:48:28
HSPしかプログラミングしたことはありませんが、もう４年くらい経ってすっかり初心者は卒業という感じです。一緒に頑張りましょう！！ -- パタパタ大王 2006-01-30 (月) 23:42:24
たたき台（？）スクリプト作成ご苦労様です。片手でデバッグプレイできない…。(^ ^;　　（修正して検証中…） -- GENKI? 2006-02-01 (水) 23:26:25
ここの企画でやっているゲームのジャンルは、アクションゲームの中でも、「ジャンプアクションゲーム」と呼ばれるジャンルのようです。 -- GENKI? 2006-02-03 (金) 00:33:45
私の古PCではあのスクリプトでも重い(泣)・・・。遠景ありズーム画面だと概算10fps程度しか出ない・・・
```
repeat 2; 1 or 3 or 4 ...
    gosub *control
    m_atari vx, vy
    await 16
loop
...
;await 20
```
- naznyark? 2006-02-03 (金) 01:15:35
- 軽くする方法ですが、雲や山だけの遠景を用意してそれぞれをサイズは違いますがマップチップと同じに扱うと良さそうですね。後、ウィンドウがまたがるズーム機能は確かに結構重いと思います。検索するキャラクター素材がRPGツクール用のものがほとんどで16*16はまずないですし、「チップのサイズ32*32ピクセル、１画面のマップチップ数16*14で、画面サイズ512*448ピクセル」の規格にした方が良いかなぁ。そしてマップチップの表示部分も画面に映る部分だけマップチップを当てはめるようにすると軽くなりますね。しかし、簡単に拡張できるためにまずはわかりやすさを優先したいと思います。 -- パタパタ大王 2006-02-03 (金) 07:35:00
  - 雲や山はマップチップというよりも今のPCのようにスプライトのように扱うのかなと思います。 -- GENKI? 2006-02-04 (土) 02:18:42
- 重いならDirectX系のPlug-in使ったほうがいいんでしょうか？ハードウェアで処理させればそれなりに早くなるんじゃないかと思いますが。またプラグインだとスプライトや当たり判定などの命令もあるのでプログラムもしやすくなると思うので導入も検討したほうがいいかもしれませんね。(DirectX使わないほうがある意味作りやすいともいえなくもないんですが…。) -- GENKI? 2006-02-04 (土) 02:18:42
- マップチップはウィンドウ外を描画しないようにすれば多少軽くなるかな。やり方はRPGのマップ描画処理と同じように考えればいいと思います。この処理今はないほうが分かりやすいのでいいのですが、今後マップが大きくなった場合はこれが必須機能になります。 -- GENKI? 2006-02-04 (土) 02:18:59
え～遅くなりましたが、開発に参加できそうです。 -- Charlotte 2006-02-03 (金) 01:58:11
これから３人で開発するので（もちろんまだメンバー募集中）連携がとても大切ですね。現在はGENKIさんがデバッグしてくれているところで、わたくしは音楽とジャンプ効果音と画面下に落ちた場合ステージの始めに戻す処理を加えているところです。GENKIさんのデバッグが終わった段階でさらにどうするかをみんなで決めましょう。こういう基礎が終わったら後は簡単で楽しい創作の段階です。用意されたものを並び替える簡単な作り方から、HSP使用者ならではの、自分で新たに部品をスクリプトで用意して作ることもできます。 -- パタパタ大王 2006-02-03 (金) 08:04:36
あら、私待ちですか。　ちょっとやってみましたが、あの微妙に１ドットずれるのはなんでしょうね？なんだかよく分からないので[小ワザ/アクション/基本動作]の方でも対処しみました。参考にどうぞ。 -- GENKI? 2006-02-04 (土) 02:00:03
HSP3のデバッグしてもらった参考スクリプトはまだ１ドットずれていますね。小ワザの方のスクリプトを参考のために今から見てきます。それとプラグインですがサウンドでは使うと思いますがそれ以外は使わないことにします。その方が作りやすいと思います。上のコメントでも少し書きましたが、手に入りやすいキャラクター画像の素材がRPGツクール用で、16*16はめったにないので「チップのサイズ32*32ピクセル、１画面のマップチップ数16*14で、画面サイズ512*448ピクセル」の規格に決めました。 -- パタパタ大王 2006-02-04 (土) 10:08:46
小ワザの方のスクリプトでは上手く出来ていたのでそれをHSP3.0に移植して、音楽とジャンプ効果音と画面下に落ちた場合ステージの始めに戻す処理を加えました。効果音は一度に複数出せるようにプラグインを使う予定です。 -- パタパタ大王 2006-02-04 (土) 13:30:15
キャラクターもMAPも32*32が普通なんですね。敵キャラで例外的に32*32サイズ以上のものを使うことありえますか？（そのときは画像自作になるかも知れないけど…。） -- GENKI? 2006-02-04 (土) 13:53:31
マリオの例で言うと、小さいマリオとクリボー等の小さい敵がマップチップと同じ幅と高さで16*16でした。ノコノコ等の普通のサイズの敵は16*24でした。普通のマリオは16*32で高さはちょうどマップチップふたつ分でした。このゲームのマップチップを32*32に決めましたから、さっきの例のサイズを全て２倍したのがそれぞれの基本になると思います。 -- パタパタ大王 2006-02-04 (土) 14:54:54
GENKIさんが当たり判定のサンプルスクリプトを作っていてマップチップよりキャラクターが大きいとあまり良く判定できないというのを見た頃から念のためにこちらでも当たり判定を作っていました。極端ではないなら色々なサイズと速度でも上手く判定してくれます。今の段階は対象が動かない場合の判定が出来ているところです。今から相手も速度を持っている場合のも作ろうと思います。出来たら敵キャラクターやギミック等に使おうと思っています。 -- パタパタ大王 2006-02-04 (土) 17:16:59
キャラクターどうしの当たり判定は衝突判定が参考になります。地面との当たり判定とは別に処理を行うわけです。画面に表示されるキャラクターは多くても２０も３０も出てこないと思うので、それほど処理が重くなることはないでしょう。 -- GENKI? 2006-02-04 (土) 20:07:58
マップチップサイズによるキャラクターのサイズ制限を外すのは結構簡単です。衝突判定用センサーを増やせばいいだけです。ブロックがセンサーとセンサーの間をすり抜けるのが問題なので、センサーとセンサーの間隔をマップチップサイズより小さくすればいいだけ、のはずです。ところで…衝突判定（当たり判定）は標準プラグインhspdxを使えば命令もあるし簡単なんですが…　　…まいっか。 -- GENKI? 2006-02-04 (土) 20:17:04
衝突判定のサンプルもここにあったんですね。知らなかったです。ところでマップチップに対しても座標で衝突判定が出来ますよね。変えたほうがわかりやすくなりますね。それとただ衝突しているかを調べるだけではなくてどこから衝突しているかも必要ですね。衝突して止まる場合や、敵キャラクターに上から衝突＝踏む場合等に。 -- パタパタ大王 2006-02-04 (土) 23:33:43
画面上に登場する全てのブロックとキャラクターで衝突しているかどうかのチェックをすると、結構な数になるのでさけていました。と考えていたのですが、でもよく考えたら自分の周辺にあるブロックとだけ衝突判定を行えばよかったんですね。orz　言われて気付いた。 -- GENKI? 2006-02-05 (日) 00:34:37
たたき台の段階でいうのは早計かもしれないが大丈夫ですか?
ああいう感じでプログラムを書いていくとプログラム苦手な人には手のつけようがなくて、苦手でない人には一から書きおろしたほうがやりやすいというものになりかねないような・・・ -- naznyark? 2006-02-05 (日) 01:23:39
マップチップも座標で当たり判定すると決まったことですし、一からわかりやすく書きたいと思います。わたくしパタパタ大王の基本的なスクリプトの組み方は、まず変数の宣言やバッファーの用意、そしてメインルーチンです。その中に速度操作、当たり判定、座標更新、描画、表示物、その他処理系のサブルーチンを入れようと思います。 -- パタパタ大王 2006-02-05 (日) 02:32:30
散逸構造論によると、エネルギーの流れが複雑になるとある時点でゆらぎが生じて、自己の系が破壊されるほどの変化を経過してやがて新たな系を再構築するのだそうです。 -- パタパタ大王 2006-02-06 (月) 00:38:52
素晴らしいです。この素晴らしさを一緒に確かめましょう。どんな速さでもどんな長さでも当たり判定が出来るようになりました。1*1の四角を1*1の四角に1ルーチンに400進む速さで進入させましたが見事に止まりました。数値が正確でもありました。しかし疑問が２つあります。わたくしの予想では四方に対して斜めに進入すると先に判定されるｘ軸方向に位置が加算されてしまうのですが、そうはならずに正確に判定していることと、判定ルーチンのループで右への衝突、左、下、上の順番で判定しているのですが、右へ衝突したらｘ軸に加算と速さを０にして、次の左等への判定にその０になった速さが利用されるのに正確に判定されていることです。素晴らしさと疑問を生んだ当たり判定が出来たようです。 -- パタパタ大王 2006-02-06 (月) 06:27:54
皆さんにも見てもらうためにアップします。そのしっかりした基礎の上にゲームを作りましょう。 -- パタパタ大王 2006-02-06 (月) 07:44:27
当たり判定を改良しました。処理部分で速度しか操作していません。わたくしにはもう理想形です。今度は本当に軽い解説と一緒にスクリプトのページに載せました。 -- パタパタ大王 2006-02-08 (水) 06:32:13
遂に気付いてしまった・・・、疑問が示す通りの結果に。最四方にそこに向かうような斜めで進入すると、最四方なので判定元と対象の位置の差の0がx軸方向の速度に先に代入されて一度速度が0に落ちます。横に何枚も同じ高さにマップチップを並べて横に移動しながらジャンプして着地するとたまになりました。後で直しておきます。 -- パタパタ大王 2006-02-08 (水) 11:42:38
問題の本質はそこではないです。
今回の用途なら実用になるかもしれませんが残念ながらパタパタ大王さんのあのスクリプトは
当たり判定処理としてはまだまだ不完全です。
*mainからawaitのあたりを次のように書き換えてしばらく見ていてください。
```
   x.0=200 : y.0=200
   x.1=350 : y.1=300
   x.3=0 : y.3=0
   x.4=0 : y.4=0
   maxvel.3=0
   maxvel.4=0
   frict.0=0
   mc=1
   ax.0=2 : ay.0=2
   vx.0=ax.0*mc : vy.0=ay.0*mc
*main
   if x.0<0 | x.0>512 | y.0<0 | y.0>512 {
       x.0=200 : y.0=200
       mc+
       vx.0=ax.0*mc
       vy.0=ay.0*mc
   }
   await 67
```
かなり本質的な部分で斜め方向からの処理が不完全です。
(当たり判定自体が行われない。接触した位置の判定がおかしい)
ただし速度が十分に小さければ問題は具現化しません。~ -- naznyark? 2006-02-09 (木) 02:04:47
見させてもらいました。斜めではなかったらちゃんとできていると思うので、大きく変わることはなさそうです。これからすることの項目に当たり判定をまた用意しておきます。気合を入れないと考えられなさそうです。今は他の項目を先にして全体の形を整えていきたいと思います。 -- パタパタ大王 2006-02-10 (金) 02:46:55
背景のグラデーションをプログラムで描いて、雲や山の背景をチップとして配置するととても軽くなりました。基礎フォルダとしてアップしました。 -- パタパタ大王 2006-02-10 (金) 11:50:14
どうも私は(パタパタ大王さんも(?))もっと根本的なところで勘違いをしていたようです。 (スクリプトのページに参考に載せたスクリプト)

当たり判定の接触判定自体は対象の物体の速度を考えないのが普通ですね。
基本的には
```
1  それぞれの物体の現在の速度での移動後の仮座標を算出
2  それぞれの仮座標同士で接触を調べる。(ここでは速度は関係ない)
3  接触していたら接触時の処理
```
で行えば良いはずです。
ただしこのやり方だと速度が判定対象の物体の大きさより大きいと正確に判定できませんがその場合は ( 速度 / n ) の仮速度を用意して判定を n 回にわけて行えばよいだけです。
(方法はともかく速度が判定対象の大きさより大きい場合は複数回の判定を行わないと正確な判定はできません)

ただしこのゲームの場合、速度が判定対象の物体の大きさはこえる状況は考えにくいので単純に仮座標同士での判定を行うだけでも良さそうです。
(その理由を説明するとまず、( 速度 = 内部処理一回に付き移動する距離 )、
そしてゲーム中で物体は ( 速度 * 内部処理フレーム数 ) 分の距離を一秒間に移動します。
またこのゲームの場合 ( 物体の基本(かつ最小)の大きさ = マップブロックの大きさ ) ですね。
つまり速度が判定対象の物体の大きさより大きい状態で移動する場合、最低でも
一秒で ( 1ブロックの大きさ * 50(or 60) ) もの距離を移動することになります。
1画面のブロックの数は横に16、1秒で3画面分も移動する速度の物体を出しては
このゲームのようなゲームの場合ゲームにならないでしょう。(実際は許容範囲ぎりぎりあたりの速度かな?)) -- naznyark? 2006-02-11 (土) 01:39:28
基本的な1,2,3の1で仮座標を出して2で仮座標同士で判定ですが、「現在の」を「当たり判定する前の」という意味で使って、仮座標は現在の位置に現在の速度を足したものだから、2の判定部分で速度は関係あると思います。ところでわたくしは考えることが好きで、自分が理解できていないことをもうすぐ理解できるようになるチャンスだと思っています。上手な方法を見たり教えてもらったりしてそれを採用したとしても、自分が作った当たり判定は完成させたいです＾＾ -- パタパタ大王（早起きバージョン） 2006-02-11 (土) 04:38:24
当たり判定のテーマで盛り上がってますね、頑張ってください。私は水をささないように他の方面やっときます。キャラクターアニメも効果音（プラグインあるし）もとりあえず（最適ではないかもしれませんが）何とかなりそうな感じですね。敵キャラの動きとかギミックは当たり判定が出来てからのほうがいいかな。あとは…タイトル画面とかステージ開始前の設定とか選択とかの画面か。適当でも出来そうな気もするけど…。(- -; -- GENKI? 2006-02-14 (火) 00:34:40
ところで肝心の「どんなジャンプアクションゲームにするか」が進んでいません。（原因の一端が自分の書き込みのような気もしますが…(-_-;;） -- GENKI? 2006-02-14 (火) 00:50:15
>パタパタ大王さん
言葉の解釈の問題もあるような気もしますがやはり接触判定部分には速度はいらないと思いますよ。
というか、移動後の仮座標という概念を導入するとパタパタ大王さんのスクリプトの接触判定部分からも速度が消えます。
当たり判定_r.hsp

それと基本的なところで勘違いしているようなので指摘しておきますと、座標 x 、大きさ(幅) w の矩形の右端の座標 xr は
```
xr = x + w - 1
```
です。 x=10 , w=8 の矩形の右端の座標 xr = 10 + 8 - 1 = 17
```
10　12　14　16　
□□□□□□□□
　11　13　15　17
```
となります。 -- naznyark? 2006-02-14 (火) 01:41:35
プチお久しぶり風のパタパタです。もうそろそろ何かアクションしておかないとフェードアウトしてしまうと思っていたらみなさんの更新があってので良かったです＾＾
周辺のことを少し試していましたが、敵キャラクターチップを多くすると敵どうしが頻繁に当たって壁をすり抜けてしまいました。naznyarkさんの「当たり判定_r.hsp」を移植して試したら今度は壁の最四方で跳ね上がってしまいました。上手く移植できていないのかも知れませんがちょっと不明。また後で色々試してみます。
右端の座標が左端と同じでも幅が1なんですね、気づかなかったです。
どんなジャンプアクションゲームにするかというのは特に設定のことですか？提案にある独自のシステムを作ることにわたくしも賛成です。何か大きな流れや始めと終わりを決めて、その途中はそれぞれの人が考えるという感じでしょうね。
このゲームで当たり判定はとても重要ですね。それを上手にしないと先に進まない感じだし、スクリプトの他のところにも大きく影響を与えている感じがします。
ここまでの履歴やこれからの構想をまとめてみようかな。 -- パタパタ大王 2006-02-14 (火) 23:27:06
敵同士は判定しなくていいと思いますよ。一般的なゲームでも敵どうし（味方同士）は当たり判定をとらないのが普通だと思います。当たり判定って処理はまともにやると重くなるものなのでできるだけ数は減らしたほうがいいです。…壁すり抜けの問題とは別の話ですね。 -- GENKI? 2006-02-14 (火) 23:55:34
敵チップも必要な部分で周りのマップチップと当たり判定するのでキャラクターチップとの判定も結局は含まれると思います。つまりチップは周りの他のチップと当たり判定するということですよね。だからキャラクターかマップか等の区別は必要ないかも知れないですね。ところで壁をすり抜けたのは当たり判定する順序が原因のようです。敵が敵に押されて壁にめり込んでもそのめり込んだ敵はもう壁とは当たり判定しないからそのままということだと思います。意外と簡単に作れると思ってたけど意外と面倒ですね＾＾；　今日はここのページを少し充実させて終わりにします。 -- パタパタ大王 2006-02-15 (水) 00:13:20
一回の移動で複数の相手と接触する可能性がある場合に正しい判定を行いたい場合は一回の処理では無理がありますね。
その場合の手法としては

1 分割式
( 速度 / n ) の仮速度を用意して判定を n 回にわけて行う。
特徴: やりやすい。平均的に遅い。それでも同時に複数と接触する場合は例外として処理をするか分割数を大きくするか無視するかを迫られる。

2 マルチフェイズ(?)式。
a 接触可能性判定フェイズ
b 接触処理フェイズ(優先度を判断して優先度の高い相手との当たり判定を処理する。)
c 全キャラの接触処理後、接触処理済の組み合わせを除いて処理後の数値で再度接触可能性判定を行う。
d c に戻る。(処理する必要がある組み合わせがなくなるまで繰り返す。)
特徴: まわりくどい。複雑な接触をしていると遅くなる。

といった方法などがありますね。
処理速度が欲しい場合にはマルチフェイズ式で (接触可能性判定)→(優先度の高い相手との接触処理のみを行う)→(判定終了)
で妥協するのが良いと思います。(妥協により生じた妙な結果もゲームの味のうちということで・・・)

ps.1 マップエディタのベータ版アップしました。mapeditor.hsp
ps.2 そろそろ古いコメントを別ページに移したほうが良いのでは?
ps.3 あの当たり判定スクリプトは判定時に何らかの事情で自キャラが他のキャラと重なっていると豪快にはじかれ(?)ます。それかな? -- naznyark? 2006-02-15 (水) 02:22:02
./スクリプト?にスクリプトの追加と更新しました。 -- naznyark? 2006-02-16 (木) 01:39:04
基礎フォルダを更新しました。ですが、これから色々と手を加えるところがあるスクリプトです。特に当たり判定のことでは、naznyarkさんのものをちゃんと移植できていないかも知れないし（とりあえず変数を配列にした程度）、優先度や順番を考えた判定も必要だと思います。そして、サブページのみなさんのスクリプトを取り入れられています。GENKIさんのアニメーションの部分やnaznyarkさんの当たり判定とマップ読み込み等です。これからもよろしくお願いします！！ -- パタパタ大王 2006-02-16 (木) 14:30:16
naznyarkさんはどちらか分からなかったのでとりあえずその他ということにしておきました。私だけ敬称つけなくても3付きでごめんなさい･･･|_;) -- kz3 2006-02-16 (木) 15:22:47
ケーズィースリーさんって読んでたんですが、3はサンって読むんですね。 -- パタパタ大王 2006-02-16 (木) 17:03:57

かずさんです。みなさんからはかずさんさんって呼ばれます。(笑 -- kz3 2006-02-16 (木) 17:17:08

 #deffunc Collision
        if (x+Width_x < px) { hyouji = "判定なし"
        } else:if (px+Width_px < x)  { hyouji = "判定なし"
        } else:if (y+Width_y   < py) { hyouji = "判定なし"
        } else:if (py+Width_py < y)  { hyouji = "判定なし"
        } else {
                 hyouji = "判定あり"
        }
 return

ソースまだ読んでないのですが、当たり判定を。 -- Charlotte 2006-02-17 (金) 00:30:14

ドレイクのコミュニティーモデルというのがあるそうです。山とその生態系を構成する動植物群の環境で既に協力なコミュニティーが作られていて、新しい動植物群は容易には入り込めない。１２５種類の新種を一つ一つコミュニティーに植える。するとコミュニティーにうまく入れるものもあれば、失敗するもの、最初はうまく入れても途中で脱落するものといろいろあった。そして１５種類の動植物からなるコミュニティーが出来上がった。しかし、この最終的に残った１５種類だけを取り出して、一種類ずつ、まっさらな環境に移植しようとしても、どの種から始めても、どんな組み合わせでも、このコミュニティーは再現できなかった。つまり途中で脱落していった種が無いと今のバランスは保たれていなかった。（引用＆編集：引用元 http://kamakura.ryoma.co.jp/~aoki/paradigm/Complexity.htm） -- パタパタ大王 2006-02-17 (金) 11:40:03
画像変わりましたね。なぜ縦長？ -- GENKI? 2006-02-17 (金) 22:22:22
普通のマリオがブロック２つ分のサイズだったから合わせました。いいバランスだと思います。 -- パタパタ大王 2006-02-17 (金) 23:57:55
そういうことでしたか。でも、ブロックとの大きさのバランスはいいんですが、画像が縦長になっちゃっててキャラクター自身のバランスが悪くなっちゃってますよ。ブロック高さにあわせるなら横にも２倍に（縦横比を維持）したほうがいいです。当たり判定の大きさと画像の大きさを一致させる必要はないのだから画像に変に変更加えなくても…。 -- GENKI? 2006-02-18 (土) 00:19:24
参考用に基礎フォルダの当たり判定部分を改造したものをアップしました。&ref(): File not found: "基礎スクリプト_atari_r.hsp" at page "横スクロール型ゲーム/コメント2/スクリプト";
主に地形チップとの当たり判定処理部分をいじっています。

p.s. 基礎フォルダの書庫とフォルダ名にはいつのバージョンかわかるように日付をつけておいたほうが良いと思います。
( 基礎フォルダ20060218 とか。基礎スクリプトに対する追加や部分改造のスクリプトの場合、どのバージョンの基礎スクリプトに対するものかをはっきりさせておいたほうが良いでしょう。) -- naznyark? 2006-02-18 (土) 01:59:52
GENKIさんが言うようにバッファから画像を取る大きさと当たり判定の大きさを分けたほうが良いですね。そのスクリプトを組むのが面倒そうだったのでとりあえず32*64の大きさになるようにしたのでした＾＾；（わたくしには見栄えも気にならなかったですし。） -- パタパタ大王 2006-02-18 (土) 12:05:25
naznyarkさんの当たり判定ですが、壁に接している場合にまだ進もうとすると地面にめり込みますよね？一応確認のため。キャラクターチップをたくさん出しても軽かったです。 -- パタパタ大王 2006-02-18 (土) 12:25:04
描画部分でちょっとだけずらすだけなのでやってみればそれほど難しいものでもないですよ。簡単なサンプルがありますんで参考にでもどうぞ。 -- GENKI? 2006-02-18 (土) 13:06:40
>地面にめり込む
その通りです。あのスクリプトではそれで正常な動作です。
解決策としては
方法 1 : 2 パスマルチフェイズ式
a 横方向と縦方向のどちらを優先して処理するかを判定。
b 優先すべき方向の接触可能性判定と接触処理を行う。
c 処理後の数値でもう片方の接触可能性判定と接触処理を行う。
方法 2 : (今回の状況の場合)縦方向の速度(重力の影響)の発生処理を変更。
a 物理処理の前にキャラの現在の状況(足元の状態)を調べる。
b 足元に床がないときのみ重力による速度を発生させる。
という方法などはどうでしょうか。 -- naznyark? 2006-02-19 (日) 01:50:04
あ、コメントがデフォルトで開いた状態になってる。こんな機能あったんですねー。毎回展開しなくていいので便利です。 -- GENKI? 2006-02-20 (月) 21:49:08
プログラマーは絵や音の作成者の意志を出来るかぎりの形で尊重しなきゃ。それが出来るのもプログラマーなのだから。また、尊重しないとゆーことは、結果的に「一番良い状態を損なう」っていう意味でもあるので…要注意。 -- GENKI? 2006-02-20 (月) 22:39:38
ある程度構想を立ててから取り組まないと応用が利かなくなるけど、ある程度作って分かることがあるという感じ。これから確かめたいことや作りたいものの一覧をメモの項目に書きます。 -- パタパタ大王 2006-02-22 (月) 12:14:27
基礎フォルダをアップしました。良い感じです。いよいよステージエディタを作らないと上手く進まないくらいの段階になってきました。naznyarkさんのマップエディタのスクリプトを応用したいけどほとんど理解できないです＾＾；今週は自分の中で開発の勢いが先週より上がった気がします。時間があった先週の日曜日は開発する気が一杯あったのに構想を考えるのにすごく時間が掛かっただけでした。今週は構想をスクリプトに変える週かな。 -- パタパタ大王 2006-02-22 (水) 14:59:53
今日はステージデータの整理をしました。描画も見えない部分はしないようにしました。 -- パタパタ大王 2006-02-24 (金) 00:10:21
マリオがファンタジーキャラになっただけで敵とかシステムはマリオのままなんですか？ -- 2006-02-26 (日) 16:37:32
そこを自由に変えられるのが良いところです（全体の統一感は必要だとは思いますが）。わたくしはまずはマリオを作ってノウハウみたいなのを得てから変えたい部分は変えるという感じで進めています。 -- パタパタ大王 2006-02-26 (日) 16:53:32
GENKIさんcsvありがとう。基礎フォルダに取り入れたいと思います。
ところで*chipdataとしているようにcsvで示しているのは地面やブロックのチップ以外にもキャラクターや背景のチップもあるので、マップと言うよりステージかチップと言った方が良いと思います。 -- パタパタ大王 2006-02-26 (日) 18:08:50
ページが更新できるようになったのでこのページの整理をしました。 -- パタパタ大王 2006-02-27 (月) 00:14:53
パタパタ大王さん、コメント書くのに"[["パタパタ大王"]]"そんなに気になる？ -- RSSリーダー? 2006-03-04 (土) 13:54:25
黄色に黒っていうのが好きじゃないです。ここはさらに進んで自分用のデザインをしてしまいます。
ステージエディタですが、一応作れるという段階に今日しようと思います。快適にとか簡単に作れるというわけではあまりないです。－－； -- パタパタ大王 2006-03-04 (土) 15:57:20
基礎フォルダをアップしておきます。予定通り一応作れるという段階です＾＾；　説明がないとわからないと思うし、スクリプトもぐちゃぐちゃだし、これからの修正点もたくさんあります。ちょっとは開発が進んでいるという確認程度でお願いします。 -- パタパタ大王 2006-03-04 (土) 23:48:43
みなさん、プチお久しぶりです＾＾
ステージエディタの改良をしました。より快適になったと思います。説明書も一応書いておきました。まだ直した方が良いところもあるけど、細かいことを沢山すると時間がかかりそうなので今日は一先ずこれでＵＰです。
後ひとつシャーロットさんに確認したいのですが、基礎フォルダに入れたステージデータにマリオからサンプリングしたステージが入っています。これって大丈夫でしょうか？ -- パタパタ大王 2006-03-12 (日) 17:45:37
20060222を元に当たり判定をいじったものアップしました。&ref(): File not found: "基礎スクリプト_r4.hsp" at page "横スクロール型ゲーム/スクリプト";
20060222のフォルダに入れてそのまま実行してください。
当たり判定部分動作のために当たり判定部分以外も少し変えてます。コード整理してないけれど。
基本動作としてはほぼ完成形になっているのでは？ -- naznyark? 2006-03-13 (月) 00:16:10
みなさん素晴らしいですね。私はエディタ部分を作ってGENKIさんはステージ・チップファイル部分を作ってnaznyarkさんは当たり判定部分を作りましたね。来週の土日はこちらでそれらを組み合わせてＵＰしようと思います。いい感じですね。 -- パタパタ大王 2006-03-13 (月) 01:35:48
naznyarkさんの新しい当たり判定ですが、色々良くなっていましたね。それを組み込もうとしていた時にわかったことですが（20060222版）、すごく離れたキャラクターが地面と一緒に下にずれていました。そしてそのキャラクターをプレイヤーから押していると何時の間にかソフトが止まっていました。もちろん時間がある時で良いので直してくれると嬉しいです。
私は20060312版とGENKIさんが作ってくれたモジュールを組み合わせておこうと思います。その他にも時間があれば細かいこともしたいです。 -- パタパタ大王 2006-03-15 (水) 21:18:28
不具合修正?と少し改良したものアップしました。&ref(): File not found: "基礎スクリプト_r4b.hsp" at page "横スクロール型ゲーム/スクリプト";
上のコメントと同じ条件で不具合が解消したかどうか報告お願いします。 -- naznyark? 2006-03-16 (木) 03:14:59
基礎フォルダ20060319をアップしました。
まずnaznyarkさんの当たり判定のことからですが、前の不具合はちゃんと直っていました。ありがとうございます。そして新しい基礎スクリプト（基礎スクリプト2.hsp）に組み込んだのですがチップNoがプレイヤーより後のチップとはくっつく感じで変になってしまいます。基礎スクリプト2.hspでstage21.csvをプレイして最初の硬ブロックに左から乗るのと右から乗るのとで試してください。それで確認できると思います。ちゃんと組み込めてないかも知れないです。こちらが把握している変更点は、重力が常にかかるようになっていたこととconのことと*syoriです。
次にGENKIさんのステージデータのことですが、数時間かけて新しい基礎スクリプトに組み込みました（チップIDを新規登録すること以外）が、結果からまず言うと20060312版から使っていたGENKIさんのモジュール（案１みたいなもの）をこれからも使うことにしました。せっかく作ってくれていたのでかなり考えた結果ですがごめんなさい。案２の良さはチップ情報定義Fileを変えるだけで全てのステージのチップもそれに対応して変わるということだと思います。しかしひとつの要素が違っただけで新たにチップ情報定義Fileに登録することになりますが、モジュール側でそれをする部分が十分でなかったりややこしいと感じました。そしてひとつの要素が違っただけで登録されるチップが多くなっていくと結局は案１に近い状態になると思いました。案１の良さはわかりやすさで、私はそれを選びました。20060312版からのものを使いますが作ってくれていた案２からも良いところを取り入れられたと思います。
20060312版からの主な更新点ですが、フォルダに入っている基礎スクリプト.hspはエディット中少し高速になった（はず）こととチップのテンプレートが外部ファイルになったことと右クリックでの操作が増えたことです。基礎スクリプト2.hspはそれをnaznyarkさんの新しい当たり判定に合わせたものです。 -- パタパタ大王 2006-03-19 (日) 02:05:37
検討・意見ありがとうございます。案１作っといてよかった。分かりやすさも使いやすさの内ってことなんですかね…今後公開用にモジュール作るときの参考になります。案２の方はいつか自分で使うと思いますのでお気になさらず。 -- GENKI? 2006-03-19 (日) 12:53:04
基礎スクリプト2.hsp の改造版アップしました。基礎スクリプト2_r2.hsp
上記のくっつく問題の修正と速度アップの模索が主です。当たり判定以外に変えてある部分もちょっぴりありますが *atari の部分を元のスクリプトと差し替えるだけでも動くはずです。 -- naznyark? 2006-03-23 (木) 03:03:47
パタパタ大王さんに質問
キャラチップ素材は改変禁止のものなのですか? 透過色を置き換えて gmode 2 を使ったほうが gmode 4 より描画速度は速いのですが。 -- naznyark? 2006-03-24 (金) 02:54:20
加工ＯＫって書いてありました。gmode 2で試したらgmode 4よりすごく速いですね。chara.pngで0,0,0色が目に使われていたのでgmode 4にしていたのですが、差が大きかったので次からのアップで画像をgmode 2に合わせたいと思います。 -- パタパタ大王 2006-03-24 (金) 17:35:52
基礎フォルダ20060326をアップしました。zokuseiを少し見直しました。空中で空気抵抗がかからないようにしましたが操作しにくい感じがして微妙です。みなさんの意見を聞かせてください。 -- パタパタ大王 2006-03-26 (日) 17:54:33
20060326使ってみました。プレイモードの操作性については個人的には問題ないと思います。エディットモードは便利な機能が増えてますね。それでも付け加えるならば32ドットずつしか動けなくしたり、あるいは既定の升目にしか配置できない機能（切り替え式で）など（一般的に言うところのグリッド・スナップ機能のようなもの）があると配置が地面やブロックの配置が楽になると思うのですが…どんなスクリプトで出来るか想像できないのであんまり強くいえないのですが。(^_^;ここまで出来ればエディタはほぼ完成？ -- GENKI? 2006-03-27 (月) 22:59:02
切り替え式でグリッド・スナップ機能って良いですね。一応確認のために書いておきますが、シフトを押しながらチップをドラッグしたらそのチップの幅単位で移動するようになります。かなり前のバージョンからです＾＾
あとステージをもっと作りやすくするために接地みたいに他のチップに接して配置できるようにしたいです。 -- パタパタ大王 2006-03-28 (火) 00:34:07
またやっちまったよ…マニュアル書いてあるしorz　チップサイズ移動だと縦長のチップとかで若干問題ありか。しかし他のチップに接して配置する機能はよさそうな感じですね、チップサイズが32(規定値)の倍数以外でも対応できそうだし。 -- GENKI? 2006-03-28 (火) 01:53:45
うぅ最近口先ばかりになってきてしまってどうもいけない…_|￣|○ -- GENKI? 2006-03-28 (火) 01:55:17
やりすぎた・・・原型とどめていない・・・ -- naznyark? 2006-04-01 (土) 00:53:09
今週は時間があまり取れなかったので私の方ではバグ取りや作りかけのものが残ってしまうくらいで大きく進みませんでしたが、naznyarkさんが原形を留めない程に素晴らしく作ってくれていたので全体では大きく進みました。その新しい基礎フォルダをアップします。次の土日にまた作ります。それでは。 -- パタパタ大王 2006-04-03 (月) 02:05:32
あ、naznyarkさん！　基礎スクリプト_20060326_r1.hspっていうのがアップされていますね。それって原形を留めなかったファイルですか？今回の基礎フォルダのアップはそれをもとにしていたので・・・。 -- パタパタ大王 2006-04-03 (月) 02:08:57
しまった、naznyarkさんにまだ言わないといけないことがありました。当たり判定でPCよりチップNoが小さいチップに対してzokusei4と8が効きませんでした。なので接触判定1を少し変えましたが遅くなったしまったと思います。よろしくお願いします。 -- パタパタ大王 2006-04-03 (月) 02:15:32
今日は良く寝て、土曜日と日曜日で出来る所まで色々充実させよう。ではお休みなさい。 -- パタパタ大王 2006-04-08 (土) 02:17:23
微妙なタイミング? 20060403の改造版をアップしました。 -- naznyark? 2006-04-09 (日) 02:14:22
20060403の改造版から主に出来上がったものはスクロールバーくらいです。他のバグを取ろうとしても取れませんでした。また来週です。 -- パタパタ大王 2006-04-09 (日) 22:50:19
改造版アップ。アニメと摩擦まわりもいじったので古いステージデータは正常に動作しません。
このチップデータ形式ではチップの変身処理はやりにくいような気がする。チップタイプを使ったデータ形式の採用を再考すべきかも。 -- naznyark? 2006-04-14 (金) 03:08:53
おひさりぶりです。ここに来ていない間になにをやっていたかというと　…何もやってませんでした。_|￣|○　　充電休養中です。私生活でも妙にやる気が出なくなってきたもので…。（そんなに重いわけじゃないのでご安心を。^_^;）音沙汰なしで心配かけるのもなんなのでご連絡を…ってなんだかこのまま逃げ去っていく人の発言みたいだ。orz -- GENKI? 2006-04-15 (土) 00:52:23
充電完了しだい復活します。なるだけ早く。　さてお詫びといってはなんですが、私のサイトにこの企画への宣伝リンクはっと来ました。（というか今までがはり忘れてただけですが…。^_^;;）もう少しぐらい参加者増えるといいですね。 -- GENKI? 2006-04-15 (土) 00:59:05
GENKIさんへ：充電するなら完全に充電した方が良いと聞いたことがあります。焦らなくて大丈夫です＾＾　私はこれ関係に土日を当てているみたいに気軽でマイペースにしていきましょう＾＾
naznyarkさんへ：改造版アップありがとうございます。幅が出ましたね。約2000行になって、作り足すために把握するのが大変ですね。ところでデータ形式の再考ですけど、現在の形式は基本的で、私は色々しやすいと思っていますけど、どんな感じで変身処理がしにくいのでしょうか。解説お願いします。 -- パタパタ大王 2006-04-15 (土) 10:28:28
stage_x1.csvの一番右上のキャラクターGOODですねｗ -- パタパタ大王 2006-04-15 (土) 11:22:08
今週のアップは臨時で休みにします。なんかやる気が出ない・・・。ううん。 -- パタパタ大王 2006-04-16 (日) 18:36:51
まずここでいうチップの変身の意味ですがチップの基本的性質や表示画像の変更が行われるということを言っています。
方法1 すべてプログラム内で記述
チップ変数の種類を今のまま変えない場合の方法の一つです。
```
if status(cnt)= {
   if buf_num(cnt)= & buf_px(cnt)= & buf_py(cnt)= {
   ;if movetype(cnt)= | zokusei(cnt)= {
       buf_px(cnt)= : buf_py(cnt)= : acnt(cnt)=
       zokusei(cnt)= : movetype(cnt)=
   }
}
```
あまりに汎用性が無さ過ぎます。
(性質は同じで見た目が違うだけの複数のチップを同時に扱う場合、チップごとにプログラムを書かなければならない。)

また変身の場合に限らず上のように画像表示に関する変数を画像表示以外の判定などに使用すると画像ファイルの内容に対する自由度が低くなったり、使用する画像ファイルを変更しただけでプログラムの書き換えが必要になったりして不便なことになります。

方法2 変身後のデータをチップ変数として用意する。
チップ変数の種類が増えます。

if f_henshin(cnt)= {
    buf_px(cnt)=buf_px_c(cnt) : buf_py(cnt)=buf_py_c(cnt) : acnt(cnt)=acnt_c(cnt)
    zokusei(cnt)=zokusei_c(cnt) : movetype(cnt)=movetype_c(cnt)
}

意味の無い無駄な変数が多くなります。
(変身しないチップにとっては完全に無駄。複数の変身を可能にする場合はさらに変数が増える。)
それ以外は汎用性も拡張性もあり悪くはないです。

方法3 実際には変身させずに複数のチップを切り替える。
切り替え先チップのIDを用意して、チップの表示・当たり判定を切り替えます。

if f_henshin(cnt)= {
    zokusei(cnt)= : status(cnt)=
    zokusei(idhenshin(cnt))= : status(idhenshin(cnt))=
}

ステージ作成時に作成者からみてのチップの管理が大変になります。

方法1以外なら悪くは無いのですが、明らかな無駄が多いプログラムはそうでないプログラムと比べると問題は多くなりがちです。(必要な無駄か明らかな無駄かの見極めは難しいですが。)

どういうやり方をするかは個人的な好みの問題もでてきますが、データ構造の仕様などは必要最小限の基本的な状態から拡張を続けていくよりは早い段階の内に最終形を見据えた状態で作っておいたほうが結局後々楽ですです。
(メイン部分が本格的なチップイベント(アクション)実装段階に入り掛けている今が大規模な仕様変更ができる最後のタイミングと思っていたほうが良いです。) -- naznyark? 2006-04-17 (月) 00:20:32

こんばんは。それらを踏まえてチップの変身について考えたのですが、チップNoを指定して変身するのはどうでしょうか。位置と速度と表示の順番以外を指定したチップNoと同じにするということです。そのためにはステージのどこかに予め作っていないといけないので、変身専用のチップ、つまり指定されるだけのチップを例えば0,-900の位置に置いておいたら良いと思います。プログラムも
```
i=変身元チップNo : j=変身先チップNo
buf_px(i)=buf_px(j)...
```
とするだけだと思います。
データ構造の仕様ですが、最終形を良く見据えられないから、作って必要なものなどを確認していくと私は思ってたんですが、ここで改めて良く考えたほうが良いようですね。アクションについて今ちょっと考えてるのは、予めプログラムのアクションルーチンに番号を付けたアクション（イベントハンドラ付き）を色々用意しておくというものです。ステージエディタでそのアクションを文字列のチップ変数として指定します。例えばaction=0+2+3+9とすれば0番と2番と3番と9番のアクションが出来ます。また、アクションルーチンを外部のHSPスクリプトとしてインクルードしたり、他の誰かがアクションを付け足したりすることも考えています。どうでしょうか？ -- パタパタ大王 2006-04-17 (月) 01:56:45

> チップNoを指定して変身するのはどうでしょうか。
方法3 の変形といえますね。無理に大規模な仕様変更をする必要は無いのでその方法を基本にやりましょうか。

> 最終形を良く見据えられないから
今回の場合は参考にすべきモノが明確に存在するのですから、最低限それと同じ程度の物を作るにはどのような処理・変数が必要かを事前にある程度は研究・分析することはできたはずです。
(イベントや敵の動きはどのようなアクションの組み合わせでできているかを研究するのは今からでも遅くは無いですが。)

アクションの仕様については私もその方向でよいと思います。ただしアクション処理の追加は外部のスクリプトをインクルードするのではなく直接本体スクリプトを変更する方法のほうが良いと思います。
(最終的には実行ファイル + データファイル + データファイルの変更でカスタマイズの形を目指すべきで、基本スクリプトファイル + データファイル + 追加スクリプトファイルでカスタマイズという形を基本にするべきではないと思います。) -- naznyark? 2006-04-18 (火) 02:43:30
どうも、パタパタ大王です。
確かに本体のバージョンアップは新たにEXEを作ればいいのでnaznyarkさんのアドバイス通りにしようと思います。私は次の週は参考ゲームの研究・分析をメインでするという感じにします。それでは。 -- パタパタ大王 2006-04-18 (火) 06:42:13
表記ほうほうや管理方法、概念などは既存のものを参考にしたほうが速いかも。例えばhspdxのでスプライトやキャラクタなど。 -- GENKI? 2006-04-18 (火) 21:15:20
改造版アップ。チップ変数大幅変更(追加)。速度に関する数値は100倍したものを基本に。アクション処理の基本形。
今回も古いステージデータは使えなくなっています。
チップ変数はもう少し増やす必要があるような気もする。 -- naznyark? 2006-04-22 (土) 00:59:40
エディタでチップのイベント・アクションを作っているとＲＰＧツクールシリーズを思い出します。エディタが1024*768以上じゃないと快適に使えないくらいの画面の大きさになってしまいました。把握している問題点が色々ありますがとりあえず今日はこれでＵＰでお願いします。では。 -- パタパタ大王 2006-04-23 (日) 14:34:21
改造版アップ。アクション条件とアクションはほぼ全部変更。簡易アクションエディタ作成(コピー&ペーストでステージデータを直接書き換えてください)。
> エディタが1024*768以上じゃないと快適に使えないくらいの画面の大きさになってしまいました。
エディットモードのインターフェイスデザインを変えたほうが良さそうですね。-- naznyark? 2006-04-26 (水) 02:01:37
基礎フォルダをアップしました。素材を新たに加えて、それを使ったステージを作ったという感じです。
因みにスクリプトの解説のページは私以外の人が書いてももちろんOKです。 -- パタパタ大王 2006-04-30 (日) 21:34:40
インターフェイスを整理したら勢いが出るかな・・・と思って整理中。 -- パタパタ大王 2006-05-14 (日) 19:48:42
スクリプトをちょっとだけ整理。途中のところがあるけどまた次にします。 -- パタパタ大王 2006-05-15 (月) 00:47:54
少しだけ改造版。プレイ時のチップの順序変更をしないように。status、atrb1フラグの意味少し変更。画像の読み込み処理変更(大きい画像は私のPCではうまく動かなかった) -- naznyark? 2006-05-20 (土) 01:36:58
基礎フォルダをアップしました。次はイベントを簡単に作れるようにインターフェイスを整えたりしたいと思います。 -- パタパタ大王 2006-05-21 (日) 18:12:43
と言いながらダイレクトサウンドを付けただけのをアップ－－； -- パタパタ大王 2006-05-28 (日) 21:19:46
改造版、というよりテスト版をアップ。データ仕様を内部・ファイル内容ともに大幅変更。それに伴いファイル読み込みなどの関連個所を変更。エディットモード周りの修正は未着手(動きません。というかモードに入れないようにしてます)。起動->プレイ開始のあたりまでをなんとなく仮実装。 -- naznyark? 2006-06-05 (月) 00:48:52
それと当初からの予定ではあったようだけど今の段階での外部プラグインの導入は個人的には反対。外部プラグイン非使用のものをベースとして完成させてからの話だと思う。 -- naznyark? 2006-06-05 (月) 00:58:13
テスト版の新版アップ。ステージデータコンバータ付属(一部のデータは変換後のファイルを直接修正する必要があります。)。描画フレームモード追加。一部アクション追加(でも将来また大幅な変更があるかも・・・)。ステージイベント扱いの処理追加。 -- naznyark? 2006-06-10 (土) 02:11:09
こんばんは＆おはようございます。パタパタ大王です。
新しいマップはチップの間隔も良いし、敵が縮んだりコインが出たりして良い感じですね。エディットモードが出来なかったのですが、どうやって新しいマップを作ったのでしょうか？
ところで私はイベント関係のスクリプトがほとんど把握できていません。ちょっと試してみても上手くいかないし、あの長いスクリプトを全部読んで理解するのも難しいです。私からは手が付けられないです。その他にも16進数の設定が慣れないです＾＾；　エディットモードでは16進数がインプットで使えないのに16進数で指定しなきゃいけないから大変だったように感じていましたが、何か上手な方法があるのでしょうか？
次の段階はイベントを作りやすくすることだと思っているのですが、手が付けられないので結局はタイトルとか音関係とかを作ったということなんです＾＾；今思い付くのはアクションエディタ.hspをエディットモードに付けることなんですが、アクションエディタって実はcsvファイルをテキストで編集しなきゃだめですよね。それじゃあエディットモードの意味がないし・・・って困っている感じです￣＿￣；
イベント関係のスクリプトを簡単に説明してくれると助かります。それと今後の目標はどうすれば良いと思います？ -- パタパタ大王 2006-06-10 (土) 04:23:39
> どうやって新しいマップを作ったのでしょうか？
前のバージョンのエディットモードで作成したデータをコンバータで変換(そのために作成したコンバータ(笑))。変換後のファイルを直接修正、変更。今のテスト版のデータフォーマットならチップタイプデータ部を中心に修正すれば良いのでたいした手間にはならないと思います。

> エディットモードでは16進数がインプットで使えないのに16進数で指定しなきゃいけないから大変だったように感じていましたが、何か上手な方法があるのでしょうか？
16進数指定する必要があるのは基本的にその中の各ビットをフラグとして使っているもの。設定する人にとっては各フラグの意味と状態こそが重要であるのに複数のフラグをまとめた数値を単位として設定させようとしているからわかりにくくやりにくいものになっている。
という点を踏まえての方法の一例。edittest.hsp(イメージであって中の処理は未実装)。
設定する人にとって意味のある要素を単位として設定すればやりやすくなるはずです(上記の例では接触判定グループと属性は変数の値全体を設定するのではなく、変数を2進数にした場合の各ビットをそれぞれフラグとして設定しようとしています)。 -- naznyark? 2006-06-12 (月) 00:13:33

> イベント関係のスクリプトを簡単に説明してくれると助かります。
どこからどこまで説明すればよいのか・・・
- 用語定義
  ここでいうイベントとは基本的にはマップイベントやゲームイベントとでもいうべきもので、ゲーム全体の進行に影響を与える出来事のことをいいます(点数が増えるとか(これはイベント扱いするべきかは微妙)、プレイヤーキャラがやられるとか、エリアを移動するとか、ステージをクリアするとか・・・)。
- 処理の流れ
  イベントはイベント発生条件が満たされると発生します(敵を倒す、プレイヤーキャラが敵と接触する・・・)。ただしイベント発生と同時にイベント処理がなされるのではなく、イベント発生時には要処理イベントリストにイベント情報を登録するだけです。実際のイベント処理は一連のチップアクションなどが終了した後でまとめて行います。これはイベントの種類ごとに優先度を設定して、より優先度の高いモノから処理するためです(未実装)。
- 最新テスト版(20060523_ex_r6)で実装しているイベントの説明１(エイリアス生成)
  現スクリプトでは処理高速化のために地形ブロックチップの大半はチップアクション処理(発動判定・実アクション処理)を行わないようになっています。しかしプレイヤーキャラに突き上げられた地形ブロックチップは弾んで戻る(あるいは壊れる、アイテムを出すなど・・・)というチップアクションを行う必要があります。
  (なおここでいうチップアクション処理を行わないというのはマップスタート時に生成されるリスト情報に基づくもののことであり、マッププレイ中には変更されることはありません。)
  こうした矛盾を解決するために用意されているのがイベントチップです。チップアクション処理を行うチップの中にはマップスタート時には特定のチップタイプを持たず非存在ステータス状態のチップが複数用意されています。これらがイベントチップであり必要に応じて各種のチップタイプに変化しタイプに応じたアクションを行います。
  エイリアス(分身)生成は指定したチップのパラメータをイベントチップにコピーすることによりイベントチップを元チップのエイリアスにします(基本的にはその際に元チップを非存在状態にしてイベントチップの非存在状態を解除します)。エイリアスチップは元チップとパラメータ的には同じですが、元チップがチップアクション処理を行わない地形ブロックチップであったとしてもチップアクション処理を行うのが大きな特徴です。
  こうした処理により地形ブロックチップ(のエイリアス)にチップアクションをさせることが可能になります。エイリアス生成はそうしたことを主目的に用意されたイベントです。
- 最新テスト版(20060523_ex_r6)で実装しているイベントの説明２(イベントチップ発生)
  上記のエイリアス生成と似たようなものです。ただしエイリアス生成が既にマップ内に存在しているチップのパラメータをコピーして新しいチップを発生させるのに対して、こちらあらかじめ用意(設定)してあるデータをチップのパラメータにして新しいチップを発生させます。

-- naznyark? 2006-06-12 (月) 00:13:33

って、アップ漏れしてるじゃないか・・・( <-バカ )。書庫差し替え。ステージデータコンバータ単体でも置いておきます。 -- naznyark? 2006-06-13 (火) 01:18:50
改造版アップ。マップイベント要素のいくつかを暫定ながら追加。細かい所をいくつか修正変更。 -- naznyark? 2006-06-17 (土) 01:28:35
改造版アップ。本体の変更はほとんどなし。ゲームデータファイル仕様書をまとも(?)なものにした。 -- naznyark? 2006-06-24 (土) 00:49:51
自分でもアクションゲーム作りたかったので参加したいです。 -- アキス 2007-03-08 (木) 21:20:03
提案?：やっぱりDirectXを使った方がスムーズに出来たりするのでは？ -- アキス 2007-03-08 (木) 21:21:09
日付等を見てわかるとおり、現在は進行が停止しています。この企画に参加するには、この企画を再活性化させる必要がありそうです…。 -- GENKI? 2007-03-08 (木) 22:22:25
そうですか・・・・どうにかして再建しないと・・・ -- アキス 2007-03-10 (土) 14:49:35
でも・・・見た感じ難しそうですね・・・アイデアの面で活躍をさせて頂きます。 -- アキス 2007-03-10 (土) 14:51:30
いまさらですが言っておくと最新版はトップページにあるものではなく横スクロール型ゲーム/スクリプトページにある ex_r11 のほうです。-- 2007-03-15 (木) 01:51:34
面白そうなので、参加させてください。ステージの制作などの仕事をやりたいです。 -- リョウ? 2008-04-06 (日) 13:18:19
やってみたかったのに -- ゆゆ? 2008-10-01 (水) 17:01:42
基礎フォルダ20060528の中の基礎スクリプト.hspを実行してみたらエラーが出るのですがこれはどういうことでしょう…… -- みちと? 2009-04-13 (月) 01:22:03
終わってるみたいですね・・・ -- 2009-06-08 (月) 14:25:24
わかんない。 -- nisihata? 2010-04-12 (月) 13:18:51
"nisihata"さん？ -- nono? 2010-06-17 (木) 14:12:40
nonoさん、ここは終わってるんですか？ -- nisihata? 2010-06-17 (木) 14:13:17
前のコメントが6月って・・・でも参加させてください。 -- a-okada? 2010-12-16 (木) 17:58:52
アクションゲームを作ってるんですけどマップの作成が分かりません。ここのWikiのマップ作成ソフトもわからなくて・・・ -- （・∀・）ｲｲ!? 2011-02-20 (日) 18:37:06

横スクロール型ゲーム/コメント2

OFFICIAL/関連

TUTORIAL

TOPICS

ETC

EDIT

REFERENCE

LOG

お知らせ

HSP Web-Ring

最新の40件