[過去ログ] 【3Dゲームエンジン】Unity質問スレッド29 [無断転載禁止]©2ch.net (1002レス)
1-

このスレッドは過去ログ倉庫に格納されています。
次スレ検索 歴削→次スレ 栞削→次スレ 過去ログメニュー
403: 2017/06/17(土)10:41 ID:UGLU7o9s(1) AAS
同種のアタッチ先が違うオブジェクトを複数用意する必要があるならインスペクタで柔軟に変えられるようにしておく
複数のシーンで同じオブジェクトを使用したり、途中で生成したりするならFind
実装方法による
404: 2017/06/17(土)11:14 ID:KBN1S3O5(1) AAS
ガイジかな? アスペかな?
405: 2017/06/17(土)11:47 ID:PcOOd2P9(1) AAS
>>398
サンクス、参考になった
oftypeがここまでとはw
406: 2017/06/17(土)17:44 ID:/Jex4D7T(1) AAS
初めて作ったのはどんな作品ですか?
Unityユーザーはコレの前にも色々経験あるのかな
407: 2017/06/17(土)18:20 ID:mnU4IsFY(1) AAS
Unity軽く触ってみたけど簡単に作れます!みたいな触れ込みだけど
結構ガッツリプログラム書かないと駄目じゃない?これ

チュートリアルの玉ころがしは簡単だけど
ローグライク2Dのチュートリアルとかは結構難しいよね
408: 2017/06/17(土)18:33 ID:YFMwAjJR(1) AAS
相対的な簡単さを絶対的な簡単さと偽ってるだけだからまだ良心的
409: 2017/06/17(土)18:58 ID:nFYpcEEx(1) AAS
ある程度以上の規模のゲーム作るのがそもそも難しい作業だから
410: 2017/06/17(土)20:07 ID:ZFFYbfbw(4/5) AAS
実際自分で作り始めると毎日やることなすことつまづくと思う
411: 2017/06/17(土)20:45 ID:pRk3a5a+(1) AAS
作るの好きだけどストアに掲載するのが面倒
かといって外注する程気合い入れてないし
412: 2017/06/17(土)22:47 ID:ILKQLYKC(1) AAS
アセットをかえば簡単だと思います
413: 2017/06/17(土)23:09 ID:89HwilAC(2/3) AAS
>>401
アセット使わない派

>>402
・ご指摘の通り実装の手軽さの問題もある
・最適化を犠牲にし視認性を重視することもある(メンテナンスの利便性)
・スマホ向けにメモリー節約重視で選択を変える時もある
 (変数に格納しっぱなしの方が嫌な場面もある)

414: 2017/06/17(土)23:27 ID:ZFFYbfbw(5/5) AAS
聞くだけむだだったなw
415
(1): 2017/06/17(土)23:35 ID:89HwilAC(3/3) AAS
そうかい?
・Awakeになんでもかんでもぶち込むとアプリ起動しなくケースがある
・根本的にアプリの起動が重くなる
・スマホのライフサイクルを知っているならば都度確保の方が安全な事が多い
・GCとの兼ね合い
他、きりがないほどある

作る物にもよるし何を重視するかにもよる
だからケースバイケースなわけ

無駄に感じるなら最初から質問しないでね
416: 2017/06/17(土)23:48 ID:8FuMlYpm(1) AAS
きりがないほど何にも対応出来ない素人は書き込まないで下さい
417: 402 2017/06/17(土)23:53 ID:pfeoMtxp(2/2) AAS
俺はわかりやすかったですthx
418
(1): 2017/06/18(日)00:00 ID:q1X0lAjX(1/5) AAS
ケースバイケースは地雷ワードだな
100%適用できるルールではなくても"基本的に"と譲歩つけた上で何か解を与えたほうがいいんだろね
みんな問いよりも解法ばかりを求める時代だから
419: 2017/06/18(日)02:10 ID:sTZlcSJA(1) AAS
実行効率、つまりパフォーマンスはどのくらい低下するのかの話じゃなくて?
420: 2017/06/18(日)07:56 ID:X5Sl8Nuy(1/5) AAS
>>415
答えになって無くて笑ってしまったw
421: 2017/06/18(日)08:45 ID:WNEWBLm8(1/4) AAS
>>395の時点でお察し
422: 2017/06/18(日)08:51 ID:3wXsUBad(1/4) AAS
バーカ
423: 2017/06/18(日)09:43 ID:5tDWnbC/(1) AAS
持ち上げてから梯子外されるガイジ
424
(3): 2017/06/18(日)10:23 ID:XAVbtWpl(1/3) AAS
>>418
ケースバイケース君と俺は別人だが俺が書いた>>379から派生してグダッてるみたいなので基本方針を示しておく

1. Findは基本的に使用禁止
文字列引数による検索は実行時エラーの温床となるので避けるべき、インスペクタ上でオブジェクトの名前を変えられただけでコケるとか怖すぎる
またヒエラルキーツリーを全部舐める様な処理を多用するのはパフォーマンス的にも好ましくない

2.インスペクタ上で参照がセットされていることを前提にした構造は可能な限り避ける
シーンファイルを誤って変更された時に、インスペクタ上で探して修正するのは面倒。特にシーン内のオブジェクトが複雑に絡み合った参照関係を持つなどは論外
もしどうしてもこれが避けられない場合はオブジェクトをプレハブ化してプレハブ内での参照に限定することで問題のスコープを小さく保つ

上記ルールに沿って作れないならそれは設計が悪いので設計を見直す、疎結合を徹底するべし
必要ならCamera.mainなどの様なstatic経由での参照の受け渡しや、シングルトンなマネージャークラスの導入を検討する
※多用は厳禁、後者はScript Execution Orderを正しく設定すること

ヒエラルキーツリーやインスペクタでの変更に弱いコードはメンテナンス性が低く、こうした変更による問題が発生した場合の問題箇所の検出が非常に困難になるので避ける様にするといい
425: 2017/06/18(日)10:39 ID:3wXsUBad(2/4) AAS
じゃあゲーム上のオブジェクト参照どうすんのよ
426
(3): 2017/06/18(日)11:22 ID:YW1VLQdX(1/2) AAS
これ間違ってるね

>1. Findは基本的に使用禁止

名前で判断するのが一番メンテナンスしやすいので普通によく使われる
バグってもそれを上回る使い安さ。だから使用禁止にしてる企業なんかない
むしろ命名規則の徹底の方が大切。名前書き間違えるとか池沼に弄らせない限り起きません。
池沼はゲーム作っちゃダメ。以上、終わり
427: 2017/06/18(日)11:24 ID:/3Y06ViO(1) AAS
>>424
低能自慢して何が楽しいの?

アセットおじさんとは違う嫌がらせかね
428: 2017/06/18(日)11:51 ID:XAVbtWpl(2/3) AAS
>>426
たとえば…
GameObject.Find("MainCamera");
Camera.main
他所から変更されるリスクはどちらも大差ないが、優先されるべきは圧倒的に後者だ

コード補完が効くのはどっちだ?
コンパイル時点で間違いが検出出来るのは?
処理速度はどっちが早い?
アセットとして切り出した時などに名前を変更されるリスクは本当にないのか?
命名規則に従ってないオブジェクトの存在をどうやって見つける?

運用対処なんてバグの温床以外の何物でもない
429: 2017/06/18(日)12:19 ID:YW1VLQdX(2/2) AAS
さぁ?w
現実は君の考えてる妄想とは違うってこったろうね
430: 2017/06/18(日)12:23 ID:3wXsUBad(3/4) AAS
得意げに長文書いててワロタ
ゲーム会社で働いてから書き込もうな知ったかエンジニア君
431: 2017/06/18(日)12:57 ID:d8uwf8Mk(1/2) AAS
運用カバー無しとかキリがないと思うんだけど
432
(1): 2017/06/18(日)13:09 ID:q1X0lAjX(2/5) AAS
>>424
おお、何となく書いたレスに真面目な長文回答つけてくれてわざわざスマンね

俺は内容に関してはほぼ同意
Findに限らず、SendMessageやStopCoroutineみたいな文字列指定はクソだからね
ただ正し過ぎるというか、1,2を両方課すのは求道的すぎて利便性が損なわれてる気もする

1に比べたら、インスペクタ参照についてはもっと緩くてもいいんじゃね
1-
あと 570 レスあります
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ

ぬこの手 ぬこTOP 0.015s