GM：怪奇！collision_rectangleの謎！

どうも、Master.typeXです。
今回は進捗と同時に備忘録的なログにしようと思う。
というのも事の始まりはサキュバス・リリィの動作を
作っていた時だ。まずは動画を見ていただきたい。

効果音は付いてないがまあ、だいたい完成したところだ。
で、問題となったのが最初のリングレーザーだ。
今回、当たり判定にcollision_rectangleというものを使ったのだが
コレがいけなかった。

まず、collision_rectangleとはなんぞやと言われると
rectangleの名前の通り、指定した矩形の範囲内に
指定した対象オブジェクトが引っかかると
当たったかどうか、他にも対象オブジェクトの
変数などの情報なんかも取得できるというものだ。

一見すると便利そうだな？と思うだろう？
実は罠が潜んでいた。という事でこちらの図を見ていただきたい。

例として緑色の矩形が前述のcollision_rectangleで
赤い矢印の付いたのが攻撃範囲と思っていい。
上下に二個別れているが、枠を見ての通り
上下で一枚のスプライトである。
で、スプライトのCollisionMask設定は
「フレーム毎に正確」を選択している状態だ。
こうすることで赤の矢印部分だけが当たり判定になる。

言っておくと、矢印側の枠はあくまでも
見やすくするために用意したものなので
無いものと考えてくれ。

画像サイズ的にスレスレではあるが
まあでも当たらないだろうと思った。
しかしだ、現実は③の通り
命中してダメージイベントが発生する。

つまり、collision_rectangleは
対象オブジェクトのスプライト全体を参照する
ということがわかったのだ。困ったものだ。

対処法だがぶっちゃけた話
同じような大きさの矩形のスプライトを
用意して、collision_rectangleではなく
instance_placeで処理すればいい。
まあ、これはあくまでも自分の例ではあるがな。

ただ、同じような大きさのスプライトを
複数用意するのは手間だ。
しゃがみ状態はともかくとして
ほふくや変身で当たり判定が小さくなるので
そこまで面倒見なきゃならない。
ちなみに、mask_indexはアテにならないので
素直にsprite_indexで当たり判定を変えてやろう。

結論。
素直に当たり判定のスプライト描きましょう。
ということだ。

じゃあcollision_rectangleはどこで使うんだと言われると
俺も返答が困るので勘弁な！

それでは今回はこの辺で！
また次回！

GM：ステートマシン備忘録

どうもMaster.typeXです。

今回は趣向を変えて「ステートマシン」
という概念についてちょっと
忘れないように書いてみる。

ステートマシンとはなんぞや？

知らんがな。

それでいいのか第一声。
とりあえず今回の例として
この動画を見て欲しい。

プレイヤーキャラがいて、黄色いのがはしご、
緑のちっちゃいのがはしごの頂点である。

左右移動とはしごは
別々の処理を作らねばならぬのだが・・・

同じステップイベント内に書こうとすると
なかなか大変なことになる。
下手するとバグの温床にもなりかねない。

そこでステートマシンの出番である。

先程の2つの画像は同じステップイベント内で
書かれていたのだが、コレをクリエイトイベントに
書いておいて、実行させる方法がある。

//例 Createイベント内
statefree = function(){

//左右移動やはしご開始処理など

}

stateladder = function(){

//はしごの昇降などの処理

}

//初期ステートの設定
//ステップイベント内で state() と記述すれば
//stateに代入した処理を行ってくれる。
state = statefree;

こんな感じである。
実例がこちらなんだぜ。

自分でもよくわかっていないが
ステート名=function()で
一部の動作を切り分けておけば
バグの可能性も減るし、仮に起きてもどっちのイベントか
判別しやすくなる

・・・と、思うんだよな。

とにかく。
プレイヤーの動作はこうやって
切り分けて作ると管理も楽なので
GM使いは試してみてはいかがだろうか。

まあ、ぶっちゃけた話
下記動画を見たほうがわかりやすいんですけどね！！！
英語だけど。

https://www.youtube.com/watch?v=yfFzz9mZkU4&t=121s

ということで今回はこの辺で！
また次回！

突発事象：えらいこっちゃえらいこっちゃ【追記あり】

一大決心：カレーデュオロジーについて

どうも、Master.typeXです。
カレーデュオロジーの割にロゴがないな？

・・・そう、今回はデュオロジーについて
大事なお話があります。ハンケチ、用意しとけ。

えーと、結論から言うと
開発中止となりました。

理由という名の言い訳をいくつか述べると

1：モチベーションの低下
二年近く作っている割に見ての通り
成果が一向に出ないという体たらく。
このままグダグダ作るのは得策ではないと判断。

2：GameMakerStudio2の知識不足
というよりも新しい知識が増えて軽くパニクってる状態。
最近ステートマシンをようやく覚え始めた。

3：体調不良の悪化
このところホントひどいもんだからねぇ・・・
平日休日問わず辛いときは辛いのよ。

4：リアル事情が大きく変わるかもしれない
簡単に言うと通ってる事業所を変えるかも知んないというか、
もう今の事業所が3年目突入しちゃってるので
通所先を変えるか就職するかのどっちかだったんだけど
上記の通り体調不良が続いてるので就職は難しく
今現在の場所に通所するのも辛いので、変更を考えています。
それにより、生活リズムが若干変わるかもしれないので。

5：販売に対して強烈なプレッシャーを受けている
そもそも売れるかどうかわからんのに凹んでた。

以上、これらがデュオロジー開発中止の原因たちです。
大風呂敷広げておいて結局ダメだったとは何たることか。
本当にスタイリッシュ土下座するしかねぇ。

で、メインのプロジェクトがなくなって
どうするんだというと、そうでもなかったりします。

色々と考えて二作同時はやはり無理で
かつ、今ある素材だけでんなんとかなる
失われたカレーの開発のみを行うことにしました。
念の為デュオロジー版とデータは別にしています。
要するにまた作り直し

で、その失われたカレーは
Plusベースなのかというと、答えはノー。
ブラウザ版ベースで一部変更要素などを加えた感じになる予定です。
というか、今の状態でPlusベースで作るのは難しい！

そして、コレはどこ向けなのかはやっぱり未定。
Steam出せたらいいなとは思ってるけど・・・その辺はおいおいと。

他にも色々と訳合ってこうなったのですが
それに関してはマジで話せないです。
開発がちゃんと軌道に乗って
末期くらいになったらお話できるかなと。

とまあ、以上で一大決心と
再スタートのお話でした。

GMS2：技術的備忘録・物理エンジン編

どうも、Master.typeXです。
今回は技術的備忘録として
GMS2の物理エンジンについて書いてみようと思います。

とりあえずこちらをドウゾ。

前回記事に書いたプチプロジェクトのGMS2版です。
GMS2にも物理エンジンは搭載されていますが
まあ、これがけったいな仕様で困った。

ということで、書き連ねていきます。

物理ワールドの定義

コレは簡単。ルームエディタのプロパティから
「Room Physics」の「Enable Physics」にチェックを入れるだけ。
CF2.5で言うところの物理エンジンオブジェクトを置く感じです。
これで物理ワールドが定義されます。
Gravity xやGravity yはXとY方向の重力ってのは
見てのとおりわかりますが
Pixels To Metersはなんのこっちゃ知りません。マジで。

物理オブジェクトの定義

こちらも簡単。オブジェクトの
「Users Physics」にチェックを入れると
それだけで物理オブジェクトとなります。

が、こっからが問題である。

物理オブジェクトの仕様

物理ワールド内の物理オブジェクトは
特に設定もせずに衝突判定が勝手に働きます。
上記の動画もステップイベントには
衝突系のコード(place_meetingとか)は何一つ書いていません。

というか逆にplace_meetingとかは
物理オブジェクト内では殆ど意味を持ちません。
おそらくそれに関してはオブジェクトに設定できる
物理用の当たり判定(後述)が関係しているだろうと思いますが
よくわかってませんです。

ただし、別オブジェクトとの衝突イベントは
しっかり働くのでそこだけ注意です。

物理オブジェクトの設定

オブジェクト内の「Physics」から設定できます。
コレがまた色々いじったけどよくわからんが一応。

Density
日本語だと「密度」らしい。
この値が大きければ大きいほど物理的に軽くなる・・・っぽい？
ただ、コレが0だと重力の影響を受けなくなるので覚えておこう。

Restitution
日本語だと「反発」らしい。
この値が大きいとぶつかった時の跳ね具合が調節できる・・・っぽい？

Collision Group
衝突グループという項目だが
どうやら同じグループでないと衝突判定が行われない模様。
なんのこっちゃ。

Linear Damping
線形減衰という項目らしいがよくわからん。

Angela Damping
傾斜減衰という項目らしいがよくわからん。

Friction
日本語にすると「摩擦」らしい。
止まりやすさなんだろうけどようわからん。
・・・ようわからんだらけだなオイ。

Sensor
センサー、らしいがよくわからん。

Start Awake
覚醒状態でスタートという項目らしいがこれまたよくわからん。

Kinematic
キネマティックという項目だが
Unityでなんか同じような単語を見た気がするが
結局よくわからん。

Modify Collision Shape
これが物理オブジェクト固有の当たり判定。
Box(四角)、Circle(丸)、Convex Shape(凹凸)の三種類から
当たり判定を指定することができる。
上にアニメーションフレームが表示されているため
おそらくフレームごとに当たり判定を変える事が可能かと思われ。

その他注意事項

物理オブジェクトは通常の「speed」の影響は受けず
「phy_○○」系のパラメータを使う模様。
実際動画だと、オブジェクト生成時にランダムで
「phy_speed_x」を-2～2の値で変更して動作させてるので。

あたぁ知らん！！！
そんなんでいいのかクソ筆者

・・・冗談抜きでこんな情報を
垂れ流して大丈夫なのか不安ではある。
まあでも備忘録やから無問題無問題。(ぉぃ

正直、place_meetingが
ほぼ使えないというのは痛いが
まあ、けったいな仕様だなぁと。
※一応機能はするので全く使えないわけではない

これが役に立つかは知らないが・・・
いや、役に立たんやろな。うん。

とりあえず今回はここまでとします。
また次回。