俺に解るように説明する "Godot Engine 3.x" 入門+

ゲームエンジン Godot Engine に関すること。入門とか使い方とかチュートリアルとか、あれとかこれとか。日本語解説。

Godot 音シュー10「むずい・・・」

Good、Great、Excellent!!」みたいに判定しようと昨日1日あれこれ悩んだけど、結局難しいからやめた。「GoodとMiss」だけにする。細かく分けるのは時間があった時に再チャレンジするとしよう。で、2週間もすると何を試してヤになっちゃったのか忘れるので、ここにまとめておく。

f:id:ore2wakaru:20180618180835p:plain


考え方

まず、「Good、Great、Excellent!!」の判定は、キーを押した時「エリアの中心」と「ビートキューブの中心」の距離で判定しようと思った。距離が10cm未満なら「Excellent!!」、それ以上20cm未満なら「Great」、それ以上でエリアの判定範囲に入ってさえいれば「Good」みたいな感じだ。余裕で出来ると思った。

ビートキューブ(StaticMesh)がエリアに入ったらシグナルが出るようにはしてあるし、入った「StaticMesh」の中心位置をゲトして、エリアの中心との差を取るだけ。だが、これがなかなか・・・


typeof( AAA )

typeof( AAA ) は内蔵関数。カッコ内の変数の型を調べるもの。内蔵関数だからどこでも使える。

例えばエリアのシグナルbody_entered ( Object body )だったら、エリアに入った物体の情報はこの"body"に入るハズ。これは分かる。だがぱっと見"Object body"とあるように、明らかにObject型で入ると考えられる。

試す:

f:id:ore2wakaru:20180618131538p:plain

結果:

f:id:ore2wakaru:20180618131749p:plain

この"17"は、Godot API の@GlobalScopeを見る。ココ:@GlobalScope — Godot Engine latest documentation

f:id:ore2wakaru:20180618133502p:plain

Object型。


Object型 と Objectクラス で はまる

Object型ってなったら、Objectクラスで定義されてる変数・関数しか使えない? もしそうなら、エリアに入ってきた物体のグローバル位置なんか知ることは出来ない。そんな変数・関数はObjectクラスにないからな。と思ってしまったのが、今回の「はまり」ポイント。

f:id:ore2wakaru:20180618134202p:plain

結論から言うと、

Object型だからと言って、APIObjectクラスで定義されている変数・関数しか使えないわけでは無い事を知れ!

という事なんだ。ここ大事。


AAA.get_class()

AAA.get_class()ドット(".")の前の変数が何クラスかを調べるもの。Objectクラスで定義された関数。(この時は、Objectクラスのしか使えないと思ってたから、たまたま試しにコレ使ってみた感じ。)

f:id:ore2wakaru:20180618134941p:plain

試す:

f:id:ore2wakaru:20180618140214p:plain

結果:

f:id:ore2wakaru:20180618140227p:plain

"body"StaticBodyクラスとして入ってきていることが確認できた。光が見えた。StaticBodyクラスなら、Spatialクラスの変数・関数をいじれるから、位置情報(Translation)をゲットできる。ほほう、やったね。(今後も何かに迷ったら、これ使ってクラスを調べてみると道が開けるかも。)


クラスの確認

前(GDScriptの14)にもやったように、使える変数・関数はそこにたどり着くまでのクラスで定義されているものも、そのまま使える。これが多分「継承(Inherit)」っていうこと。

f:id:ore2wakaru:20180618142504p:plain

これだったら、

StaticBody = ( StaticBody + PhysicsBody + CollisionObject + Spatial + Node + Object )

こういうことな。

どんな変数・関数が利用できるか知っとく為に、めんどいがある程度APIを見て覚えてないとイケナイぜ。


位置情報も表示さす

試す:

f:id:ore2wakaru:20180618144005p:plain

結果:

f:id:ore2wakaru:20180618150259p:plain

あとはこれを変数に取って、キューブとエリアの差を取ればいいんだが。


Vsync "On" と _process(delta)

デフォではVsync"On"だ。[Project Settings] > [General]タブ > [Display] > [Window] からVsyncの設定が出来る。

f:id:ore2wakaru:20180618165128p:plain

これだと、FPSは使ってる液晶モニタのスペックで決まってしまうようだ。(60Hzなら、60FPS固定。ええパソコン持ってても60FPS固定。) だから、キー入力のタイミングがシビア(OKな受付回数が少ない)になる。エリアにキューブがいる時のエリアの中心位置を_process(delta)内から表示してみると、こう。

f:id:ore2wakaru:20180618170648p:plain

これで、「Good、Great、Excellent」なんかの3段階は分けられないよねーって感じだ。


Vsync "On" と _physics_process(delta)

普通に、_physics_process(delta)より_process(delta)の方がいっぱいアクセスするのかと勘違いしてたぜ。というわけで描画タイミングを使わないで、デフォ"60"の物理タイミングを"120"に変更して使ってみることに。

[Project Settings] > [General]タブ > [phisics] > [Common] > Phisics FPS”120”に。

f:id:ore2wakaru:20180618172806p:plain

これで、_process(delta)は60回/秒、_physics_process(delta)は120回/秒呼ばれることになる。物理の方が描画よりいっぱい呼ばれるようになった。(なんか一般的なのと話が違う感じがするけど、、、) で、こう。

f:id:ore2wakaru:20180618173517p:plain

いいじゃん。じゃ、"240"とかにすればもっとイイんじゃねと思ったけど、


Vsync "Off"

という選択肢もある。やってみたら、俺のしょぼいPCでもover 1700FPS。これが一番じゃんと思ったが、どうも「Area」の判定タイミングは物理プロセスで決まるらしい。なるほど。


おい

結局、Vsync "On / Off" 関係なく、物理プロセスを"100"くらいにして動かすのが無難かなーと思ったりもしたが、「GoodとMiss」の2判定にすれば"60"のままでいいじゃんと思ってしまった訳だ。おしまい。

あーだこーだやってみて、結局何も変えなくてイイヤとなった時の「なんだろう」感といったら、、、

おい、つまらん!