Unity初心者の俺が調べたことをメモするスレ (99ﾚｽ)
上下前次1-新
33: 名前は開発中のものです。 [sage] 2023/09/10(日) 22:01:57.78 ID:pyk4erDp(2/2) AAS
所持ちゃう、初心者
34(1): 29 [sage] 2023/09/11(月) 07:46:22.08 ID:2rYAG6dH(1) AAS
>>3131(1): 名前は開発中のものです。 [sage] 2023/09/10(日) 21:59:14.98 ID:u9L0A1tk(2/2) AAS
>>28
ECSは全然理解してないし有料アセットとの兼ね合いが悪い（自分で調整できない／作業量多すぎ）だから導入するつもりは現状ないかなあ
アセット開発者がDiscordで今からECS対応は難しいって言っているのも見かけたし
>>29
どういうコードがGCalloc発生するのか自分で見て覚えていきたいってのもあるし、しばらくは続けようかな
シューティングゲームって弾幕GameObjectのinitialize／Destroyやオブジェクトプール行き来のDisable/Enableで最適化が大変そうだなあ
差し支えなければ教えてほしいんだけど重い処理を行っている時ってフレーム毎にどのくらいGCalloc発生してますか？
>>30
?
今日はNPC（アセットのコンポーネント）のUpdate30個をOnUpdateに変えるお試し軽量化をしてみた
0.5msぐらいの改善が見られた 他にも自分のゲームに使用しない無駄な機能がついていたりするから削っていこう
アセットに更新があった時に面倒だが、勉強道具にしたり自分で色々と改造したりできるから完全なC#コードが提供されているものは便利（DLLで提供されているものがあるか知らんけど）
アセットとC#の話で一つ複雑だなと思うのは、AssemblyDefinitionによってアセンブリが定義・分割されているとアセット側からこちらの自作コードにそのままではアクセスできない点。コード弄り始めた頃は原因が分からなくて四苦八苦した。
自作コードにAssemblyDefinitionsを設定していない場合は自動的にAssembly-Csharpに配置されるが、このAssembly-Csharpと他アセンブリのアクセスは一方通行の関係にある。すなわち、Assembly-Csharpから他アセンブリにはアクセスできるが、他アセンブリからAssembly-Csharpにアクセスすることはできない。
なので自分のコードに弄ったアセット側からアクセスしたい場合は、自分のコードをアセンブリ定義・分割して参照設定を追加するか、自分のコードをアセット側のアセンブリ内に入れる必要がある。
まあむしろアセットでアセンブリ定義・分割されてない方が色々と問題らしいので自分の経験は初心者特有の躓きって感じだな
大量にオブジェクト扱う部分は全部Burst使ってるから重い部分ではGCAllocは発生してないし、まだ開発序盤で一時的にお試しで入れてるコードやシューティングと関係ないアセットなんかでGCAllocが出てるだけなので参考になりそうな数字は持ってないよ、申し訳ない
35: 名前は開発中のものです。 [sage] 2023/09/11(月) 21:22:14.79 ID:GchgKIS7(1/2) AAS
>>34
なるほどありがとう
自分のゲームはだいぶ時間かかりそうだからその間にECSやバーストコンパイラーの仕様や情報が充実するといいなあ
>>3232(1): 名前は開発中のものです。 [sage] 2023/09/10(日) 22:01:38.99 ID:pyk4erDp(1/2) AAS
ところでヌシはタイトルには初心者って書いてるけど
所持がガベージとか気にしないよね？
ナニモン？
Unity歴５ヵ月弱の初心者だよ
今日はあまり何もしなかった
自作インベントリの検索機能を少し弄ったけど何となく前の仕様の方が使い勝手が良かった気がして結局コードを元に戻した
検索機能を処理する複数のクラスが絡み合っているので（密結合とはこういう状態？）、今後の保守や改良に備えてコードを見直した方がいいかもしれないと思った
自作スクロールの描画処理については既に一部をインターフェースや抽象クラスにしてあるので、検索機能も（今のところ予定はないけど）インベントリ以外に流用することを考えると同じように改良したい
ただこの辺はコーディングや設計の思想について先に学ばないと結局グダりそうだね
36: 名前は開発中のものです。 [sage] 2023/09/11(月) 21:58:09.05 ID:dpI1L58C(1) AAS
歴5ヶ月でインタフェースや抽象クラスとか
Unityは浅いけどC#は長い？
37: 名前は開発中のものです。 [sage] 2023/09/11(月) 22:31:07.12 ID:GchgKIS7(2/2) AAS
Unity歴とC#歴は同じ
プログラミングはキッズの頃にキッズ向け言語とRPGツクールのRGSS(Ruby)を少しやった程度
ただRubyはもう全く覚えてない
38: 名前は開発中のものです。 [sage] 2023/09/12(火) 22:16:09.67 ID:Agu+xwh8(1) AAS
ジェネリックについての勉強を少し始めた
自作のスクロールを拡張する上で複数の型を扱うことになるかもしれないので、スクロールの抽象クラスに一部ジェネリックの抽象プロパティや抽象メソッドを実装して今後のコーディングを統一的にするのが目的
ジェネリックな関数には制約条件というものが付けられるそうなので、これでスクロールに渡すべき型に特定のインターフェースの実装を要求すればコーディングのミスも減りそう
逆に言うとこれも個人開発だとミスの防止という点以外の利点が分からん…もっと勉強が必要そうだ
39(1): 名前は開発中のものです。 [sage] 2023/09/12(火) 22:30:53.89 ID:DqJC+Tye(1) AAS
すごいなぁ
自分はUnity半年あたりはやっと3DでUnityちゃんが動いて喜んでたわ
それで満足してた（笑）
40(1): 名前は開発中のものです。 [] 2023/09/13(水) 08:16:34.64 ID:zrU2QrrP(1) AAS
俺も歴同じくらいでほぼほぼchatGPTに聞きながらやってるけど>>11(1): 名前は開発中のものです。 [sage] 2023/08/30(水) 21:52:43.22 ID:zQtYmNBI(1/3) AAS
ちなスペックは
コード作成は生成AI頼り・基礎的なコンポーネントの使い方すら理解してない・C#の経験皆無
こういうレベル
ほど理解せずに進めちゃってる
キャラクターをステートマシンで動かしてるんだけど、抽象クラスとジェネリック使う機会あってほー便利だなあって思った気がするな
41(1): 名前は開発中のものです。 [sage] 2023/09/13(水) 22:19:12.03 ID:b/7dbaPf(1/2) AAS
>>39
自分は2Dはスキップしてるからその分は早いかもしれないね
2Dの学習が必要かをUnity始める前に少し調べたけど、どちらかというと否定的な見解が多い印象で、UIの制作でどうせその辺やC#を扱う必要も出てくるだろうから最初から3Dで始めた
>>40
ChatGPT便利だよなあ 厳密には自分はBingの会話AI(GPT4.0をウェブ検索用にチューニングしたやつ)を使ってるけど（無料だから）
無料版の3.5も試したけどBingと比べて誤情報や変なコードの出現率が高いから断念した
ステートマシンって現在の状況をノードで繋いだステートを行き来して色々とするものだっけ？（無知）
UnityのAnimator（mecanim）がステートマシンらしいからいずれ覚える必要があるし、自分の作ってるUIも段々と状況設定がゴチャゴチャになってきたからそういうのを勉強して整理しなきゃなあ
42: 名前は開発中のものです。 [sage] 2023/09/13(水) 22:19:25.85 ID:b/7dbaPf(2/2) AAS
今日やった作業は主に二つ
?ディザ抜きを利用した障害物の透過
シェーダーアセットの基本機能を設定しただけ。キャラクターがワールド上の設置物の影に隠れて見えなくなってしまわないように、カメラ距離でディザリングを行うことで透けて見えるようにした。カスタムシェーダーにも対応してるアセットなので、勉強が進んだらキャラクターを隠しているか等の判定も加えてより高性能なものにしていきたい。
?UIを実装するクラスの整理
一昨日から引き続きUIのコードを整理した。アイテム欄クラスと検索欄クラスでそれぞれ大体同じ処理を実装しているので、既に継承させていた抽象クラス（基底クラス）を拡張して派生クラスで実装していたコードを半分ぐらい移植した。アイテム欄クラスと検索欄クラスでは扱うコレクションの型が違っていたので（アイテム欄クラスはアイテムのインスタンス、検索欄クラスはintを扱っていた）、この二つのクラスにコレクションを渡すインターフェースをジェネリックを使って<T>にすることで抽象クラス（基底クラス）で処理を統一できた。これを実現するためにジェネリックを調べていたようなものなのでひとまず満足。
ただ渡されたコレクションから描画すべき情報を取得する処理はまだ統一できていないので明日以降に挑戦してみる。
ところでUI（でも何でも）作り始める前にはちゃんと設計図を作成しないとダメだね
検索システムに「ミニメニューを開いて利用するから〜」というテキト−な理由でMiniMenuUIってクラス名つけたんだけど、ふとミニメニューにアイテム並び替え機能も欲しくなって「MiniMenuUI ＝ 検索システム」じゃなくなってしまったから、クラス名を付け直しになった
付け直し自体はVisualStudioのフォルダ全体置換機能を使ってすぐに終わったんだけど（異なるクラスでもフィールド名を統一しておいたのが功を奏した）、純粋に面倒だし変更し忘れが残っていたらどんなエラー吐くかも分からんし設計はちゃんとすべきだと思いました
43(1): 名前は開発中のものです。 [sage] 2023/09/13(水) 22:27:45.47 ID:HTnl4o+9(1) AAS
UIは何を使ってますん？
UnityUIやMeshプロは将来無くなるとかで
自分はUIToolkitを勉強してます
44(1): 名前は開発中のものです。 [] 2023/09/14(木) 06:44:41.69 ID:A6Ctx0a0(1) AAS
>>41
4.0も誤情報多いんで自分でも調べながらやってます
全く知らん分野に手を付けるとき基本的なアイデア提供してくれるのはありがたいっすね
unityのアニメーターみたいなビジュアルスクリプト？もあるしコードでのステートマシンもあります
移動ステートクラスみたいなのを作って、それを抽象クラスにして敵用移動ステートとプレイヤー移動ステートみたいに作ってましたね
でも冷静に考えると確かに抽象クラスじゃなくてまんま内容コピペして新しいクラス作ってもよくね？って思いましたね
コードの冗長性はなくて読みやすくはなるかもだけど…
45: 名前は開発中のものです。 [sage] 2023/09/14(木) 21:12:02.73 ID:BQP80pEG(1/3) AAS
>>43
普通のGUIだね
GUIは将来無くなる訳じゃないよレガシー行きはするかもしれないけど
UItoolKitにTMPが再整備されるまでまだ時間はかかるだろうしUItoolKitは学習コストに見合った性能や作りやすさはなさそうなんでしばらくはスルーするかな
>>44
対話式AIはあとコード丸投げして処理追わせたり注釈つけさせるのも便利だね
あと自分がちょっと慣れてきた分野で誤情報を見抜けると感動する（）
ビジュアルスクリプティングは有料アセットのもの？
今後のメンテも考えると共通事項はなるべく基底クラスにまとめておいた方がよいのかなとは思ってる
抽象クラスは今のところ個人開発だと「うっかりインスタンス化」「派生クラス毎に処理が大きく異なるメンバを実装強制して、うっかり実装し忘れ防止」の2つが主な利点なんだろうなあと考えている
単に共通事項まとめるだけから普通の基底クラスでもいいしね
46: 名前は開発中のものです。 [sage] 2023/09/14(木) 21:34:26.80 ID:BQP80pEG(2/3) AAS
今日の作業は相変わらずのUI実装クラスの整理
何かUnity Runtime Fee関係でだいぶキナ臭い動きが出てるから、当面は有料アセット購入はせずにUIとゲームシステム面の実装をするつもり
今後の同行次第で（有名なアセット撤退とか自分が覗いてる5ch外のコミュニティ閉鎖とか）ワンチャン3Dゲーからワールドマップのない2Dゲー（ゲームジャンル名が分からん）に目標変えて比較的短期でリリースして別エンジンに移行するかも
ただ仮に言語が変わっても設計を考えておくのは絶対に役立つと思うから、ゲームシステムはUnityで完成させたい
今日の作業で気になった点
①MonoBehaviourの必要性
UIにしろ何にせよ今のところ自分は大抵のクラスにMonoBehaviourを継承させてゲームオブジェクトにアタッチさせて使っているが、全部アタッチする必要性ってあるの？っていう単純な疑問が生じた
というのもMonoBehaviourを利用しないデザインが～みたいな話をしばしば耳にするので…
MonoBehaviourはAwakeやUpdateみたいなマジックメソッドを利用できるようになる利点はたしかにありがたいのだが、ゲームオブジェクトやクラスが増えてくると管理が面倒になってくるので、特定のゲームオブジェクトのライフサイクルと一蓮托生ではない・又は便宜的にゲームオブジェクトと一体になっていると分かりやすい（例えばキャラクターと所持アイテムみたいに）クラスのインスタンスはnewで作ったほうがいいんじゃないか？と感じたり
今後ゲームシステムを作っていく上では更にMonoBehaviourの機能を使わないクラスも増えてきそうなので、この機会に少し調べてみた方がいいかなと思った
47: 名前は開発中のものです。 [sage] 2023/09/14(木) 21:45:06.99 ID:BQP80pEG(3/3) AAS
②クラスのインスタンスのメモリ使用量
自作のアイテムクラス（のインスタンス）はint型フィールドを複数持っている
最大で1万個はアイテムを所持できる想定なので、メモリ圧迫やセーブデータの軽量化を考えるとまあなるべくインスタンスのサイズも小さくしておきたいとは考えている
そこで前にフィールドのint型（4バイト）をShort型（2バイト）に変えてみたのだが、プロファイラで雑に確認した限りではメモリ使用量に変化はなかった
数値の型のメモリは単純に半分になったのに変化しないのは何故だろう？と当時は思っていたが、どうもクラスのフィールドとして数値が入っているので、クラスのインスタンスをヒープメモリに配置する時に取りだしやすいよつにサイズが整理されてその際に単純計算したメモリ使用量と比べてサイズが拡張されるらしい
これかもしれない（ちゃんと調べてない）
48(1): 名前は開発中のものです。 [sage] 2023/09/14(木) 21:51:03.03 ID:t6pji0Zs(1) AAS
レガシー行きって何か怖いのよね（笑）
自分はUIToolkitにしてウェブみたいな作り出来るから画面サイズ気にしなくて楽になりました
メモリ関連はよーわからんけど宅さんあるときはdictionaryかなぁ
49: 名前は開発中のものです。 [sage] 2023/09/15(金) 21:07:15.26 ID:Fj2wueol(1/2) AAS
>>48
Dictionaryは個別の値へのアクセスは早いけど高性能な分メモリ使用量は多いよ
配列やリストはメモリ使用量は少なめでIndexでのアクセスは早いけど、個別の値の検索や削除が要素数に比例して遅くなるから多数のアイテムを管理するシステムには不向きな印象がある
明日は久しぶりにコレクションについてまとめてみるか
今日は抽象クラスの整理はひとまず終わったので次に作るUIの設計を考えた
クラス間の結合を弱めるにはインターフェースやZenject（外部ライブラリ）が有効だそうだが、導入には一手間かかりそうだなという印象
インターフェースはUnityの標準機能じゃインスペクターから設定できない（オーディンインスペクターという有料アセットや外部ライブラリを利用すれば一応可能）のが残念
それとインスペクターで参照を設定するのだと結局ゲームオブジェクト（MonoBehaviour）同士の結合は緩められてない気がする
「クラスAに機能を追加・修正・削除したから、クラスBの該当部分も直して～」っていう作業から抜けたいなあ
50: 名前は開発中のものです。 [sage] 2023/09/15(金) 21:24:06.03 ID:hZKK5Ca7(1) AAS
因みに今のパソコンでそのディクショナリのはやさとかメモリとかどれだけ影響あるのでしょうか？
最後の文章見ると個人開発じゃなくてグループ？
このメモは一体、、、
51: 名前は開発中のものです。 [sage] 2023/09/15(金) 21:52:15.68 ID:Fj2wueol(2/2) AAS
個人開発だよ
「直して〜」の「〜」は呼びかけじゃなくて以下ループとかそういうニュアンスのつもりだった
大量のデータを扱うコレクション（配列とかリストとかディクショナリ）の場合はどのコレクションを選択するかで処理速度は顕著な差が出るね
前に実験したことあるけど、1万個の所持アイテム用インスタンスを格納した?List<自作クラス>と?Dictionary<int,自作クラス>で一番最初に入手したアイテム（ListではIndex0、Dictionaryではint型キーを連番になるように制御して格納しているのでこれもキー0になる）を削除する処理を行った場合
?Listだと500msぐらいかかる一方で、?Dictionaryだと0.1msで終わる
これはListでは内部的には配列に特殊な処理を加えて自由に挿入・削除のできるコレクションに仕立てているから、削除関数であるRemoveAt()を実行すると削除した要素Indexの後ろに並んでいる要素たちを全部1つずつコピーして前に詰める作業が内部的に行われると全体の要素数が増えるにしたがってクッソ重くなる
一方でDictionaryは内部ではハッシュテーブルを利用していて、与えられたキーをハッシュに変換する作業がある代わりに基本的に要求された要素だけを参照しに行くから、全体の要素数が増えても処理速度に対して影響は出ない
メモリ使用量についてはモバイル端末想定じゃなきゃまあ誤差だとは思うけど可能な限りは軽くしたいね
52: 名前は開発中のものです。 [sage] 2023/09/16(土) 21:40:31.42 ID:OFNct1/O(1) AAS
コレクションについてまとめようと思ったけど別のことして忘れてた
とりあえず今日はメニュー画面の作成を進めた
今日から作成を始めたメインメニューはクラス間のシリアライズによる参照は使わずに、イベントとリスナー登録で情報のやり取りをしようと考えている
一般的にイベントでやり取りをする方法は、クラス間でお互いの内部実装に無関心で済むため（イベントの発火がされなければ待機しているだけで、引数を受け取ってどう使うかも自由）、疎結合に分類されるらしい
まあシリアライズの代わりにデリゲートへの関数のキャッシュとリスナーの登録をコードで行う必要があって、更に複数のリスナーが存在する場合は実行順序の制御も別所で必要になるので、インスペクターからシリアライズで参照設定をしてグチャっと処理コードを書いた方が短期的には楽に見えるのはナイショ
53: 名前は開発中のものです。 [sage] 2023/09/16(土) 22:33:48.81 ID:GeGtMKJg(1) AAS
やべぇー
なんか、高度すぎて
分からん
54: 名前は開発中のものです。 [sage] 2023/09/17(日) 22:58:20.80 ID:SjciO0EV(1/2) AAS
基本的に実装したい処理が思い浮かんだ時に必要そうな処理を基礎からその都度調べているだけよ
地道にUnityやっていけば必ず到達できるレベルでしかないからガンバレ
本日の作業もメニュー作り
静的イベントを利用してクラス間のやり取りをするうちに気になったのが、イベントとゲームオブジェクトのライフサイクルとの関係性
メインメニュー → 「装備」ボタンを押すと静的イベントを発火 → リッスンした装備メニューのマネージャークラスが装備メニューをSetActive といった流れを実装したかったが、テストプレイすると「装備」ボタンを押しても装備メニューが起動しない
原因は、装備メニューのマネージャークラスがアタッチされたゲームオブジェクトが無効化されていたためっぽい
無効化されたゲームオブジェクトの関数を外部からコールすることは可能だが、無効化中にはイベントのリスナーとしてコールバックを行うことはできないようだ
確かにゲームオブジェクトにアタッチされたクラスはUpdateなどのマジックメソッドが呼び出されないが、厳密にはこれらもランタイムから呼び出されている訳で、外部からコールされている状態に近いように思える
イベントのリスナーとしてのコールバックもEventHandler？が呼び出しているらしいので、「ゲームオブジェクト」のライフサイクルにはこれらの仕様を変更する（というか、制限された仕様のインスタンスをUnityが提供している？）ようだ
まあ面倒な理屈はともかく、イベントでやり取りするクラスは発火前にゲームオブジェクトを有効化しておくか、MonoBehaviourを利用しないクラスとして設計しましょう、というのが今日得た結論となる
55: 名前は開発中のものです。 [sage] 2023/09/17(日) 23:04:46.48 ID:aXQbPdAS(1) AAS
それセットアクティブじゃなくて
Enableでは？
56: 名前は開発中のものです。 [sage] 2023/09/17(日) 23:08:19.89 ID:SjciO0EV(2/2) AAS
いやイベントのリスナーになっているクラス（コンポーネント）がアタッチされているゲームオブジェクトが無効化されているとコールバックが行われないっぽのよね
コンポーネントじゃなくてゲームオブジェクトだからSetActiveの話
57(1): 名前は開発中のものです。 [] 2023/09/18(月) 12:08:45.30 ID:RKiVL9Tq(1) AAS
l_i_t_e(邪魔という方は左記をNGお願いします)
更にご家族に教えて加えて￥4000×人数をGETできます！
画像ﾘﾝｸ
上下前次1-新書関写板覧索設栞歴
あと 42 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.013s