【軽量】godot engine【無料】 part4 (995ﾚｽ)
上下前次1-新
817: 08/20(水)11:26 ID:8BIAqddk(1/2) AAS
# connect() の Callable とは？
Godot 4.x から connect() の仕様が変わり、シグナル接続時に Callable クラスを使うようになりました。
記述例(4.x):
button.connect("pressed", Callable(self, "_on_button_pressed"))
Callable は「あるオブジェクトの特定のメソッドを呼び出すための参照」を表すクラスです。
記述例のように connect() によるシグナル接続時に Calalble コンストラクタの第一引数に実行したいメソッドを持つオブジェクト、第二引数に実行したいメソッドを記述します。
これらの引数はそれぞれ第一引数はオブジェクト参照、第二引数はそのオブジェクトが持つメソッド名(文字列)となります。
Godot 4.x では以下のような 3.x の (target, method_name) 形式は廃止され、第2引数に Callable を渡すことが必須になりました。
記述例(3.x) ※4.x 非対応:
button.connect("pressed", self, "_on_button_pressed")
また上記の記述例(4.x)は以下のショートハンドでも記述可能です。
記述例( 4.x ショートハンドver.)
button.pressed.connect(self._on_button_pressed)
これは内部的に Callable(self, "_on_button_pressed") を生成します。
Godot 公式もこの「Signal プロパティ経由」の記述方法を推奨しており、
シンプルかつ Callable を意識せずに利用できるため、実務でもこちらを使うのが一般的です。
818: 08/20(水)11:28 ID:8BIAqddk(2/2) AAS
# なぜ Callable を経由するのか？
簡潔にまとめると、以下のメリットがあります。
1. 安全性（未定義メソッドを is_valid() で事前検出可能）
2. IDE 補完・リファクタリング対応（文字列指定ではできなかった恩恵）
3. 統一性（シグナル以外でも「関数参照」として利用可能）
4. 柔軟性（ラムダでシンプルに書ける）
5. 将来性（Godot 4.x 以降の標準記法）
819: 08/21(木)07:12 ID:/HImpd/9(1/3) AAS
tonkusu
820: 08/21(木)10:04 ID:/HImpd/9(2/3) AAS
プログラミングっていきなり答え見たほうがいいのか？
821: 08/21(木)10:26 ID:OYDY07jx(1/8) AAS
見ないで答えるにはそれを知っていなければならないから最初は必ず見る
クイズだとしても知識を持っていなければ答えられない
パズルだとしてもルールを知らなければ考えられない
プログラムとはコンピュータとの対話言語を使った会話
言葉を覚えると言う意味では他言語とセオリーは変わらない
曖昧さが少ない分覚えやすいまである
822: 08/21(木)12:09 ID:Ajf2SJxV(1) AAS
最後はアルゴリズムだからなぁ
823: 08/21(木)12:24 ID:OYDY07jx(2/8) AAS
ゲームにおけるデータ処理なら必要なアルゴリズムは辞典読めば事足りると思う
ゲームに必要な物ならある程度はエンジンが機能を提供してくれる
他がやってない独創的な処理を実装したいなら頭悩ますしかないね
824: 08/21(木)13:27 ID:zThVp00O(1/3) AAS
実装したい機能について考え方さえわからない場合も多い
Godotではないが答えを見なければ今でも簡単な当たり判定すら実装できていなかっただろうと思う
825(2): 08/21(木)14:05 ID:/HImpd/9(3/3) AAS
キャラクターをスイッチしたいのだけども
アクティブキャラだけ操作権があって、別キャラと衝突したらそっちに操作権が移る
シグナルはキャラA,B共にarea2dを使っていてあらかじめ有効化している
シグナルのオンオフをいちいち切り替えるのは面倒そうなんで
a,b両方から衝突のシグナルが飛んでくるんで、フィルタリングしたい
フィルタリングの条件分岐に必要な要素って何があるかな？
現在操作キャラ(a)からのシグナルを無視して、それ以外(b)からのシグナルが来たら、bに切り替えるって流れかな
オンオフで対応したほうがシンプルでいいかな
こういう論理的思考が壊滅的に出来ないみたい
練習方法ない？
826: 08/21(木)14:59 ID:OYDY07jx(3/8) AAS
自分が理解できない物を論理的に考えるのは無理なのでまず自分が理解できる所まで単純化する
コンピュータを指示通りに動く人として捉える
相手に自分の考えを伝えるには相手が理解できる言葉を使う
相手がどこまで理解できているかを想像する
>>325の例題を要約すると以下の感じであってるかな？
「アクティブ時にのみ操作可能なキャタクターが複数存在する」
「操作キャラクターが操作可能キャラクターに衝突すると操作権が衝突した相手に移る」
相手が理解しやすい単純な説明を心がける
まず概要を伝えて会話する為の基礎を築く
シグナルとかArea2Dだとか複雑な話題はなくて良い
相手と共通認識ができたらより複雑な話題へ移る
こんな感じで物事を単純化してそこから徐々に複雑化していく
練習方法としては相手が知らない事を説明する事、仕様書を書いて読んで貰う事かな？
場を作るのが難しいけどディスカッションを多数こなすのが良いのではないかな
827: 08/21(木)15:00 ID:OYDY07jx(4/8) AAS
>>325でなくて>>825だったわ
828(2): 08/21(木)15:57 ID:OYDY07jx(5/8) AAS
必要なのかどうか判らんが>>825の制御方法を回答するなら以下かな
操作可能キャラクターに現在操作権があるかどうかを判定するアクティブフラグを持たせる
操作はフラグが有効な場合にのみ処理する
衝突シグナルの発呼はフラグが有効な場合にのみ処理する
衝突シグナル発呼後にフラグを無効にする
衝突シグナル着呼時にフラグを有効にする
829(2): 08/21(木)17:37 ID:zThVp00O(2/3) AA×
外部ﾘﾝｸ:pastebin.com
830: 08/21(木)18:26 ID:OYDY07jx(6/8) AAS
ゲームマネージャがアクティブなキャラクターを保持する方式だね
その方が今誰がアクティブなのかが即判るので良いかもね
一つ気になる点としてはAの処理とBの処理の処理順でAが先に処理される場合
キャラクターAがBに衝突した際にアクティブキャラクターをBに更新してしまうと
その後のB側の衝突処理でBは自分がアクティブキャラクターと認識してAに更新してしまうのではと思う
さてどうかな？
仕様を誰でも判りやすい言語化するのはAIとの対話にも役立つと思うよ
831: 08/21(木)18:35 ID:OYDY07jx(7/8) AAS
ちょっと訂正、後から文章足したからキャラクターAの登場がずれた
キャラクターAとBが存在する時にAとBの処理順がAが先に処理される場合
AがBに衝突した際にアクティブキャラクターをBに更新してしまうと
その後のB側の衝突処理でBは自分がアクティブキャラクターと認識してAに更新してしまうのではと思う
832: 08/21(木)19:10 ID:zThVp00O(3/3) AAS
おっしゃる通りキャラAからキャラBにタッチした時にB側の_on_area_enteredが実行されて再度キャラAに操作権が渡る可能性があるため(物理サーバーがシグナルを発火させる順番に依存するため100%ではない)
「アクティブ側だけが切替処理を実行」「同じ物理フレームでの多重切替を禁止」の処理を盛り込む必要ありです
流石です
833: 08/21(木)19:31 ID:OYDY07jx(8/8) AAS
AIが使えるとかなり捗るね
自分の上げた>>828方式だと発呼するのが一人だけなのが保証されているので複数による切り替えは発生しない
>>829方式の場合はもうひと工夫が必要
これもやり方は色々あるけど一つ方法を挙げておくと
即時にアクティブキャラクターを更新するのが問題の発生原因なので更新処理を遅延させる
call_deferredを使用すると現フレームと次フレームの間に処理が行われるのでこれを利用する
より具体的にはアクティブキャラクター更新処理を関数化してcall_deferredで呼ぶ
自分で使うならこう書くんだけど行儀が良くないコードなので実用するなら適宜直してね
(func():gm.active_char = other_char).call_deferred()
834: 08/22(金)12:59 ID:5H9qw/cT(1/2) AAS
ありがとう
じっくり読んで作るナリよ
やっぱりアクティブキャラだけシグナルを発する方式が安全なんすかね？
835: 08/22(金)13:20 ID:hykeI/+Z(1) AAS
今回上がった>>828,829どちらでも多重切り替えの対策をしていれば安全性は変わらない
作る人が作りやすい間違えにくい方式を選べば良い
現在のアクティブキャラを頻繁に知る必要があるなら>>829の方が良いと思う
>>828の場合は対象キャラクターの全件走査が必要になる
>>828のメリットはゲームマネージャ不要なので携わるクラスやファイルが少なくなる事かな
全件走査の件はグローバルクラス化して静的変数を持たせればゲームマネージャを用意せずとも同じ結果を得られる
やり方は色々存在する
尚現処理では2体以上のキャラクターと同時に衝突した場合の切り替え対象が不定となるので
優先順位が必要な場合は何らかの追加処理が必要
836: 08/22(金)19:05 ID:5H9qw/cT(2/2) AAS
ありがとう
勉強がてら、フィルタリングでやってみるか
837: 08/25(月)19:24 ID:pgacrMvG(1) AAS
パッパとRPG造りたいナリ
838: 08/26(火)07:36 ID:jvaDPhtX(1) AAS
そういうあなたにぴったりなゲームエンジンがカドカワさんからでてますよ・・・
839: 08/26(火)09:16 ID:QxOlVIen(1) AAS
あーいうの余計むずく感じるんで無理
840(1): 08/26(火)13:49 ID:WJT07pkb(1) AAS
じゃあ、おまえは何もできません、おまえ自身が無理だからです
出直してきてください
はい、次のワナビどうぞ
841: 生出白液 08/29(金)00:02 ID:511euTV9(1/2) AAS
extends CharacterBody2D
var gravity = 980
var jump_velocity = -600
var p = 2 # ジャンプ回数
@onready var sprite = get_node("rotation_fish") # 子ノード（回転魚など）
func _physics_process(delta):
velocity.y += gravity * delta
if is_on_floor():
p = 2
if Input.is_action_just_pressed("jump") and p > 0:
velocity.y = jump_velocity
p -= 1
if sprite:
sprite.call("receive_message", p) # 回転に通知
move_and_slide()
if is_on_wall():
get_parent().result = 1
get_parent()._result()
queue_free()
このコードに物体のｙ座標が８００を超えたら
get_parent().result = 1 get_parent()._result() queue_free()
と同じような実行をするコードを追加で作ってもらいたいです。親ノードは下のようです
extends Node2D
var result = 0 # 状態管理用
func _ready():
$Label.visible = false # 最初は非表示
func _result():
if result == 1:
$Label.text = "finish"
$Label.visible = true
else:
$Label.visible = false
842: 08/29(金)01:40 ID:VmXngAYr(1) AAS
>>840
お前Unity質問スレでもその先生ごっこやってたことあるだろ
滑ってんだよそのノリ
いちいちワナビ追っかけていって絡むのやめろ
843(1): 08/29(金)01:51 ID:NTpF3sfj(1) AAS
「子が移動後に壁にぶつかったら親に通知して消滅するコードに
子のy座標が800を超えたら1行目と同様の処理を追加したい」
"壁に接触している"事を判定しているのはif is_on_wall():の部分なのでここを変更する
"壁に接触している"または"y座標が800を超えている"とする
if is_on_wall() or position.y > 800.0:
こんなん？
844(2): 生出白液 08/29(金)21:55 ID:511euTV9(2/2) AAS
そのコードを加えてみましたが、Invalid assignment of property or key 'result' with value of type 'int' on a base object of type 'Window'.というエラーが出ました。このエラーの意味が全く分かりません教えてもらいたいです
845: 08/29(金)22:12 ID:US91n0Bz(1) AAS
煽りとか抜きにチャットAIに投げたほうが早いぞ
846: 08/29(金)22:48 ID:Zy5HkM5N(1/2) AAS
>>844
そのエラーはresultプロパティにアクセスしようとしたがプロパティが存在しないから発生している
>>843の修正を元には発生しない
想像に想像を重ねるとエラー文に出てくる"Window"はエラーを出したノードの親ノードを指している
if _on_wall():の次行のget_parent().result = 1が既出エラーを発生させる可能性がある
親ノードにぶら下がる子ノードだったならこのエラーにはならず親ノードの場合に発生する
修正以前にコードの親関係が正しくなくコードが機能する状態でないと思われる
修正前コードを動かすには孫ノードとコードが不足しているのでそれらの追加が必要
ノード構成は以下となるはず
Node2D (親コードextends Node2D配下のアタッチ先)
+CharacterBody2D (子コードextends CharacterBody2D配下のアタッチ先)
++CollisionShape2D
++Sprite2D (孫コードのアタッチ先※提示されていない)
自分もAIに聞いた方が応答速度が早くて良いと思うよ
上下前次1-新書関写板覧索設栞歴
あと 149 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ
ぬこの手 ぬこTOP 0.028s