Unreal Engine Meetup in Osaka Vol.02ツイートまとめ

じろち (jirochi.sz) @jirochi_sz

Blueprintで重複サーチってやり方あるのかな？ CPD的なやつ、、、 #UEOsaka

M.K @ryutorion

#UEOsaka 処理を要約できる部分で関数化しよう 読みやすいブループリント やっぱり読みやすいコードの書き方ですね 新人研修とかで伝えたい内容

おかず @pafuhana1213

別イベントで実装してる処理に線を繋ぐ場合にも関数化を要検討 めちゃわかる…線が色んな処理の流れに分かれてると本当に読みづらい…。線が交差してたり、気持ち長くなったら整理してる #UEOsaka

暇人（ゲームプログラマー） @hima_zinn

プログラマーはみんな書き方を一回勉強したほうがいいと思ってる。 一回勉強しておくだけで、今後のプログラムの質が全然変わると思う。 リーダブルコード読もう。 #UEOsaka

M.K @ryutorion

#UEOsaka 名前は明確でシンプルに 色々な人がこれを言うのは，できていない人が多いからなんだよなぁ 検索や翻訳で出てきたのに飛びついて変なのになっている人もいるし OpenTobira とかやられると死ぬ

暇人（ゲームプログラマー） @hima_zinn

自分は略語ほとんど使わないですね。 名前結構長くなってしまったとしても、 『みんなコード補完でプログラム組んでるでしょ？』 って認識。 #UEOsaka

alwei @aizen76

関数名も変数名は明確な方がいいけど、全て説明しようとすると20文字以上になったりして、命名が難しいのが大変。 #UEOsaka

alwei @aizen76

関数名も変数名は明確な方がいいけど、全て説明しようとすると20文字以上になったりして、命名の難しいところ。 #UEOsaka

SEN-A @SEN_A0527

変数のルール等、僕はプログラマー出身じゃ無いからこの辺り疎いので助かる😅 #UEOsaka

暇人（ゲームプログラマー） @hima_zinn

もちろん、短く正確に伝わるならそれがベスト。 ただ、略語作って伝わらないくらいなら、略さず全部書いた方が良いって話です。 #UEOsaka

おかず @pafuhana1213

変数と関数の名前について 何を表してるか、何をするのかを一目で理解できるように 変に省略しないようにしたり、bool 型変数だと Is〜、Can〜、Has〜とつけてみたり。 最近はいい感じの名前が思いつかないときはChatGPTにいい感じに関数名考えてもらったりしてる！べんり！ #UEOsaka

暇人（ゲームプログラマー） @hima_zinn

命名思いつかなかったら codicオススメ。 codic.jp/engine やりたいこと書いたらこんな感じの名前どうですか？って提案してくれるやつ。 #UEOsaka

M.K @ryutorion

#UEOsaka 読みやすさには宗教的な部分が ってことわりが まぁ一神教にならなければ良いかなって 色々な宗教の良いとこどりしようぜ って思ってるので結構すぐに書き方変えます

おかず @pafuhana1213

マクロと関数について マクロは必ず出力を返すように。もしマクロ内でReturnまで辿り着かない処理がある場合、その後の処理が走らない場合がある ああ…これは怖い…マクロならではのトラブルだ… #UEOsaka

alwei @aizen76

マクロで分岐して出力ノードで返さないとその場で処理が止まってしまい、後続の処理が実行されない。マクロが単なるノード展開という点のコワイところ。 #UEOsaka

M.K @ryutorion

#UEOsaka 関数内部はシンプルに 意外と難しいのが，何を1つの処理と見なすか，と言うところ 座標移動の処理で，座標のx軸を変更するのも1つの処理じゃないか，と言い始めると困る 適度な粒度を知るにはやはり経験も大事

暇人（ゲームプログラマー） @hima_zinn

よくあるケースだけど 『Aの状態のときだけBの処理する』 って処理を作る事になったら一つの関数にまとめるんじゃなくて 『Aの状態かどうか』を返す関数と『Aの状態のときにBする』関数を分ける。 過去経験上、後々になって『Aの状態かどうか』だけの判定を使うケース結構多い。 #UEOsaka

おかず @pafuhana1213

関数内部はなるべくシンプルに。一つの関数につき5つ以内のノードだと内容が把握しやすい バランスが難しいところだ…関数に分けすぎると階層が深くなって追いづらくなるし… #UEOsaka

M.K @ryutorion

#UEOsaka 判定関数や取得関数では内部を変更しない constをつけて ホント副作用は危険

おかず @pafuhana1213

constはいいぞという話。Get関数内で変更処理をしたりなどのトラブルを回避できる ちょっと話が変わるけど、Riderくんはコードに対して、constにできるやん！しようや！とガンガンオススメしてくれるので好き #UEOsaka

M.K @ryutorion

#UEOsaka コメントも注意 ちゃんとコメントも保守しないと騙されるからね (最近騙された)

おかず @pafuhana1213

コメントについて 複雑な処理の要約したい場合に有用。コメントで括ってるだけでとまとまってる感があって精神の安定性が保たれるので好き #UEOsaka

alwei @aizen76

ノード配置の話のところまでいけなくて残念！公開スライド楽しみにしてます！ #UEOsaka

SEN-A @SEN_A0527

僕毎回ノード組む際に処理毎にコメント書いてるんだけど、そういうのって逆に関数とかにするべきなんだろうか #UEOsaka

M.K @ryutorion

#UEOsaka 最終的には面白いゲームを作るのが目的なのでコードをキレイにしたりすることを目的にしないこと そうなんですよ 目的と手段を取り違えてはいけない