【ゲームエンジン】Unity初心者質問スレBuild1

[過去ﾛｸﾞ] 【ゲームエンジン】Unity初心者質問スレBuild1 (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

326(1): 2018/08/04(土)14:04 ID:qIP9aSz0(3/8) AAS
初心者に分かるように言ってんじゃん。
紙パンツスレ飽きちゃったんか？あっちで吠えてろよ

327: 2018/08/04(土)14:29 ID:jfygBgbK(2/2) AAS
おまえらの話は誰にも通じてないし役にもたってないぞ

328(2): 弟子 ◆rZPPjYuxmQ 2018/08/04(土)14:41 ID:+VI6JuUR(2/5) AAS
>>326
YAMLとは？
シリアライズとは？
ケバdeaugとは？

初心者なんでまったく訳わかんないですわ

329(2): 2018/08/04(土)14:43 ID:yHEIRFFR(1/2) AAS
>>324
それってシーンファイルに書いてある識別IDじゃない。んでシーンを保存するまで0だよ。保存する前のヒエラルキーはどう説明するのさ。

330(1): 2018/08/04(土)14:45 ID:yHEIRFFR(2/2) AAS
>>328
初心者スレで聞いてみれば。

331: 2018/08/04(土)14:50 ID:cpg8UDOV(1) AAS
>>328
知らなくても作れるけどな。

332(1): 2018/08/04(土)15:05 ID:qIP9aSz0(4/8) AAS
>>329
Editorがシーン用にDBを構築してるって事なんだよ。隠蔽って書いただろ。
シーンの中見たなら、ある程度シリアライズされてる内容見えただろ。でも全てじゃないのは分かったはずだ。

未保存がメモリで動く訳ないだろ。実行前に必ず保存されてるわ。
保存前のヒエラルキーは見た目だよ、ドラフト扱いな。
もう少しEditorとUnityEngineの違い分かった方がいいな。

333(1): THE・シンプル先生 2018/08/04(土)15:07 ID:KOItUBKr(1/2) AAS
>>312
自分で工夫する事で昔の「main()ループ」に近い物が作れる。

?：空のゲームオブジェクト(Empty)を適当な位置に作る。名前は仮に"GameMain"としておく。
?：次に適当な場所に"GameMain.cs"と仮の名前でC#スクリプトを作る。
?：?を?にアタッチ
?：?の中にprivate属性などGameObject型の動的配列の"元だけ"を宣言 → 例：GameObject[] Enemy;
?：?の"start()"などで実際に必要な数の配列を作成　→　例：Enemy = new GameObject[3];
?："GameObject.Find("※オブジェクト名").gameObjectを使い、先程作成した配列にシーン上のGameObjectを関連付けていく　→　例：GameObject[0] = GameObject.Find("Enemy0").gameObject;
?：後はGameObject[0]を使う

当然他のやり方も無数にある。

334(1): THE・ステップアップ先生 2018/08/04(土)15:19 ID:KOItUBKr(2/2) AAS
>>312
次の内容はおまけなので意味不明な場合は気にしなくていいよ。

ソース上でのオブジェクトの管理のしやすさはメモリー使用量に反比例する。
今までのやり方（main()ループのやり方）だと扱いたいオブジェクトを最初に配列に全て格納するのでそれだけ沢山メモリーを占有し続けることになる。
旧型のゲームを作る場合はこのやり方でも問題ないし今でもこっちの方が扱いやすい場面が多々ある。
とくに小規模ゲームの場合はこっちのやり方で全然いいと思う。

じゃあUnityがこの古き「main()ループ」のやり方になっていないのは何故かというと
中〜大規模のゲーム作成も想定して作られてるのもあると思う。
この規模になると次の事を実現しないといけない。
・必要な場面にだけメモリだけを使いこまめに確保と解放を繰り返す節約型モデル
・もともと非常に重い3D物理演算を実用レベルで運用する
・もともと複雑で重い3Dの当たり判定処理（コリジョン）をプログラマが手軽に扱えるようにする
これの実現でメモリー制約の厳しいスマホで苦労せずに3Dゲームを作れたり
MMOやオープンワールド系のゲームを作れるポテンシャルを実現している。

FCマリオやテトリス作るなら"main()ループ型"でいいけど、モンスターハンター作るなら"main()ループ型"では死ねるよという感じ。
実際に何かを作ってみると分かるが当たり判定（コリジョン）は"main()ループ型"で回して中でいちいち判定するより
オブジェクト1つ1つにC#スクリプト埋め込んで当たった時に勝手に「当たったよ！」とイベント通知してきてくれる方が100％楽。

余談だが、UnityやVisualStudioのようなGUIでモデルを配置できるエディッタ時代ではなく、コマンドプロンプト時代のCUI時代にソースで扱っていたクラスのカプセルの概念、あれをビジュアル的にも再現できている今のUnityのモデルだとも感じてる。
今のUnityのやり方が、昔に目指されていたオブジェクト指向プログラミングの1つの完成形・理想形なんじゃないかと思う。
アセットの概念なんかはまさにオブジェクト指向プログラミングのカプセル可の恩賜だと思うよ。

335(1): 弟子 ◆rZPPjYuxmQ 2018/08/04(土)16:23 ID:+VI6JuUR(3/5) AAS
>>330
それはどこですか？
誘導お願いします　
ここは、そういうスレなので教えてください

336(1): 2018/08/04(土)16:28 ID:qIP9aSz0(5/8) AAS
>>335
ほらよ、君にうってつけだ
2chｽﾚ:gamedev

337(1): 2018/08/04(土)17:03 ID:u4pCimN6(1) AAS
>>332
＞>>329
＞Editorがシーン用にDBを構築してるって事なんだよ。隠蔽って書いただろ。
＞シーンの中見たなら、ある程度シリアライズされてる内容見えただろ。でも全てじゃないのは分かったはずだ。

ヒエラルキーの表示じゃなくて、ヒエラルキーに表示されている、シーン上のオブジェクトの話をしてたつもりなんですけど。

＞未保存がメモリで動く訳ないだろ。実行前に必ず保存されてるわ。

未保存のときもlocal identfierfile 0のままシーンビューやヒエラルキービューで編集出来ますけど、そのオブジェクトはメモリ上じゃなくてどこで動いてるんですか？

338(1): 2018/08/04(土)17:27 ID:qIP9aSz0(6/8) AAS
>>337
シーン情報はシーンにある。プレファブ情報はプレファブファイルにある。
てか見たんだろ？ファイルにあるわ。

もちろん画面に表示したり、編集させるにはメモリを使ってる。だけど電源オフったら消える通りストックはされておらん。
編集はできとるが、これがそのまま再生実行時に使われると思ってるところがあんたが嵌ってるところだ。

新規作成したらEditor用のメモリに展開はされる。
だけど電源オフったら消える通りストックはされておらん。

未保存データは再生実行時には使われておらん。
再生実行時に保存データを使ってEditor用のメモリに一旦展開する。これがデシリアライズな。

分かった？

339(1): 2018/08/04(土)18:23 ID:bPWDdaDo(1) AAS
>>338
誰か再生実行時の話してましたっけ？プレハブを作る場面の話だったと思いますけど。
ヒエラル木とか言ってる人に合わせて、ヒエラルキー上にリストされているシーン上のオブジェクトの事を指して、またはオブジェクトの階層構造自体の事をヒエラルキーって言ってたのが悪かったかな。
ヒエラルキーのリストは確かにファイル。

んで、編集中にプレハブを作りました。そのプレハブをシーン上に配置しました。シーン上に配置した時点でオブジェクト化されたんじゃないかと思うのですが、このときはプレハブソースからのデシリアライズは起きないのですか？

340(2): 2018/08/04(土)18:30 ID:sBxajZWZ(1) AAS
playerキャラとかNPCキャラとか複数のオブジェクトで使い回すような自作関数ってそれぞれにアタッチしてるスクリプトに書く？それとも１つ関数をまとめたオブジェクトを作ってそこに書いておいてその都度それぞれが参照する感じのほうがいいですか？
例えばオブジェクトの現在の座標とか着地判定を取得する関数とか

341(1): 2018/08/04(土)19:26 ID:qIP9aSz0(7/8) AAS
>>339
インスタンス化とデシリアライズの話が出たから、そのタイミングである再生実行の話をしただけで、いきなり誰かしたかと言うのはおかしい話。

プレハブから配置したのは、あくまでEditor上でシーン情報を作っただけで、デシリアライズは再生の時に起きるっての分かる為なんだが

まあ、ちょっとデシリアライズを誤解してるってか、話がどんどん逸れそうだからな。行間読むわ

多分言いたいのは、プレハブをシーンに置いた時に、プレハブ情報からシーン情報が構築されないのか？って言いたいんだろう。
一旦Editorのメモリ上では構築される。
そんで、再生や保存で、その時に当然Dirtyな置かれたオブジェクトがファイルに保存される。
再生の初期にシーンファイルを読み込んで、デシリアライズしてメモリ展開する。
オブジェクト化は再生の初期やInstantiateの時に起こる。これをインスタンス化と呼ぶ。

じゃあ、エディタで見えてるのは何なの？って言うと、編集のためにファイルをエディタ用のメモリに展開してるだけ。

最初にプレハブを置く＝テンプレートからのエディタ用メモリへのコピー
保存＝シーン情報の構築
ヒエラルキー＝再生時のメモリ構築用データ
と思えば良い。

まだダメかな？いい加減疲れてきたぞ。をい

342: 2018/08/04(土)19:33 ID:qIP9aSz0(8/8) AAS
>>340
人それぞれかな。
俺の場合は、それぞれにアタッチしてる。だが種類は極小でなるべく余計な物はアタッチしないって方針
一個だけアタッチするなら、代表するオブジェクトに持たせたり、シングルトン使ってそいつにコンポーネント生やしたりもする。
シングルスレッドならUnirx辺りを使ってアタッチしないで生やしたりもできる。
それぞれ一長一短だから全部やってみるとええ。

343: 2018/08/04(土)20:34 ID:Ter6X2ca(1) AAS
>>340
良いか悪いか。
仕様に基づいて、一番最適な設計を行って実装するのがプログラマだから、察するに現時点の貴方のレベルからすると、342さんも言ってるように、とにかく実装経験を積むことが近道になると思う。

344(1): 2018/08/04(土)20:47 ID:s81iLtQ9(1) AAS
>>341
でもさ、公式のマニュアルに
外部ﾘﾝｸ[html]:docs.unity3d.com
単に、プレハブアセットをプロジェクトビューからシーンビューにドラッグするだけで、プレハブのインスタンスを作成します。
プレハブのインスタンスとして作成されたオブジェクトは、ヒエラルキービューで青色の文字として表示されます（通常のオブジェクトは黒の文字で表示されます）。

て書いてあるのよ。
プレハブはシアライズされたファイルで、そのシリアライズされたファイルからインスタンスを作成するんだからデシアライズじゃないの？Unityではデシアライズとよばないの？

345: 弟子 ◆rZPPjYuxmQ 2018/08/04(土)23:08 ID:+VI6JuUR(4/5) AAS
>>336
君はスレタイ読めないのかな？

346(1): 弟子 ◆rZPPjYuxmQ 2018/08/04(土)23:10 ID:+VI6JuUR(5/5) AAS
>>344
呼び方とかどうでもいいのよ、動けば
議論したいなら他行くか、自分でスレ建ててそっちでやってね

347(1): 2018/08/05(日)00:07 ID:iaL/bkNc(1) AAS
弟子realize
↑
低能特有の神経質な悪臭が半端ないな
なんなんだこのゴミ

348(1): 弟子 ◆rZPPjYuxmQ 2018/08/05(日)00:15 ID:9xb2C49y(1/4) AAS
>>347
そのゴミが建てたスレに来て何言ってんの

349(1): 312 2018/08/05(日)01:31 ID:CyFJgm7j(1/2) AAS
>>334
とても勉強になる回答内容に感激しました。
私はその昔ながらのmain()ループのやり方で生きて来たクチなので
Unityのマニュアルやチュートリアルに目を通し(熟読はしていませんが、
非常に困惑しているところだったんです。
ステップアップ先生の話を聞いた限り、仮にUnityでFCマリオを制作するとしても、
昔ながらのmain()ループのやり方をUnityで実行するより、
本来はUnityモデルを覚えて作った方が"ラク"だよ、ということですよね？
例えば当たり判定〜のくだりは確かにそっちの方が確実にラクなのが理解できますし。
それとも「いや、FCマリオくらいのゲームしか作る気ないなら、
この先Unityを覚えて制作せずとも、>>333のUnityの中で擬似main()ループで作る方が断然ラクだよ」とかですか？

というのもmain()ループのやり方が染み付いてしまっている私自体、
ゲームの処理には中心となるがループを置いて、
そこからすべての流れを構想してしまうオツムなんです。
Unityモデルは全オブジェクトが個々で処理され、バラバラに存在している感じ？というか
各オブジェクトや処理に非常にふあふあしていると感じました。
もちろん自分のUnity理解度がまだ足りないせいなのは重々承知してますが
アセットやツールで解決するそれぞれの処理がブラックボックスすぎて、
初心者としてはそれらの応用が難しい。
アニメーション描画も、正直配列に各画像を入れ込んでフレームで回す方がラクなのに、
AnimationEventを使ってメモリを動かしてイベントの制作をしなければならない？のも余計ややこしく感じます。
結局、ソースだけで解決できないエンジンなので例えFCマリオであっても
Unityを覚えないと作れないことにちょっと面食らっています。
それらもステップアップ先生のおっしゃる通り
3Dや中〜大規模のゲーム作成も想定されたUnityだからこその仕様なのだと理解しましたが
どうなんでしょうか、私が2Dオンリーのゲーム制作目的であっても
Unityモデルで制作方法を覚えた方があとあと必ずラクになりますか？
変な相談ですみません。

350: まあ、人それぞれやな先生 2018/08/05(日)02:07 ID:bE8Y0pws(1) AAS
まあ、人それぞれやな

351: 2018/08/05(日)03:32 ID:IZ2haYgx(1) AAS
自分のやり方でやってみれば
unityでも十分できると思うよ
一元管理のほうがコード書きやすいし
チュートリアルみたいなコードは手練れてないと無理じゃね

352(1): THE・ステップアップ先生 2018/08/05(日)04:35 ID:PSh59YKG(1) AAS
>>349
mainループ式は、シングルスレッドとかシングルタスク的な動きを連想させるけど
Unity式は、マルチスレッドとかマルチタスクとか非同期的みたいな動きだから慣れていないと取っつきにくいだろうね。
どちらかというと、Webのサーバークライアントプログラムの扱いに似てるかもね。
これは慣れだよ。
最初は四苦八苦かもしれないけど
旧式でもゲームを作れる技量があるのなら、触っている内に必ず非同期的な作りにも慣れる。
慣れるとメリットの多さに気づける。

Unity式のやり方を覚えた方が絶対に得だよ。
作れる物の幅も広がるしステップアップに繋がる。
そしてソースが非常に簡略化する時が多い。
例えば動きを実現するのにmainループ型では30行必要だった処理が1行で済むなんてこともあるよ。

最初から全てをUnity式のやり方にする必要はなくて
慣れてるmainループ式で作り、Ｕｎｉｔｙ式にしたほうが便利そうな部分だけそっちにする感じでいいんじゃないかな？
実際のゲーム作りも、ほとんどが「main()ループ式　＋　Unity式のハイブリット型」になると思う。
main()ループ式だけとか、Ｕｎｉｔｙ式だけという作りにはならないと思うよ。
他の人はどうなのかは知らないけど自分の場合は必ずゲーム全体を管理するmainループ的なスクリプトが存在するよ。

mainループはゲーム全体の状態をコントロール（ゲーム中なのか？ゲームオーバーなのか？などの状態）したり、
ラジコンを動かすプロポ代わりとなり、各GameObjectに実装した関数へ「待機」とか「アクションＡの動きを実行せよ」とか指示をだして操作してるようなイメージ。
各GameObjectには渡された引数で色々な動作をするように記述したC#スクリプトをアタッチさせておき、指示を受けて動くロボット的なイメージ。

人によっては"GameMain"に相当する部分を"GameMgr（ゲームマネージャー）"みたいな名称にしてるかもね。

353: 2018/08/05(日)07:32 ID:7w+AZmvn(1) AAS
>>346
俺には初心者がそれなりにマニュアル読みつつ、独自解釈のエラそうな知ったかを追い出そうとしてるように見えるけど？

354: 2018/08/05(日)09:16 ID:1CW9jcvb(1/3) AAS
さすがお盆休みだなぁ。

355(1): 2018/08/05(日)09:22 ID:1CW9jcvb(2/3) AAS
>>348
初心者スレなんていう公共的なスレタイ付けといて言うセリフじゃないぞ。個人的なスレにしたいならもっとスレタイ考えろ。
初心者スレはお前が立てなくてももっと普通の奴が立てるからでしゃばんな。

上下前次 1-新書関写板覧索設栞歴

あと 647 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ

ぬこの手ぬこTOP 0.017s