Unity初心者の俺が調べたことをメモするスレ (99ﾚｽ)
上下前次1-新
10: 名前は開発中のものです。 [sage] 2023/09/01(金) 18:06:12.03 ID:jPfSgGL6(1/2) AAS
>>9その都度調べてはいるけど結構忘れちゃうわ
自分のコードすら翌日見るとよく分からん
その３ ゲーム上のアイテムシステムの管理について
Unity特定の機能というよりどうやってこういう概念を実装したらいいのかな？って話
アイテムの入手と管理をどうやってゲームシステムとして実装するか
?ノベルゲー寄りの小規模なゲーム（アイテムは入手か未入手だけで特定の場面でしか利用しない。同じアイテムの複数個所持もない。）
正直一つずつbool値を設定して管理しても何とかなりそう。とは言っても場面毎に必要なアイテムを設定する際の利便性を考えると、スクリプタブルオブジェクト、Enumや通し番号あたりを割り振る必要性は結局あるかもしれない
?一般的なゲーム（それなりのアイテム数で複数個所持もある）
Dictionaryで、アイテム種類別管理データ（スクリプタブルオブジェクト、Enumや通し番号あたり）をキーに、値を所持数にして格納すると楽そう。
?ハクスラ要素のあるゲーム（同じアイテムでも性能が違っていたりする。Minecraftのエンチャントようなシステムもこのタイプ）
アイテム種類別管理データだけではなく、個別アイテムの管理データも必要になる。雑に調べた限りではこのパターンは意外とネットに情報がない。自分は購入したノーコード系アセットのサンプルゲームを見て、Dictionaryの値を個別アイテムインスタンスにする方法で実装できることを知った。
public class MyItem
{
private int itemNo; // アイテム種類別管理データに対応する enumでも何でもない
private int myAbility;// 個別データとか
}
こういうクラスを実装して、アイテム入手時にこのクラスのコンストラクターに個別情報を渡してインスタンス化して、そのままDictionaryに入れる。キーを0から始まる通し番号にでもしてキー自体を更に別のコレクションで管理すれば、疑似的なインデックスとして入手順にアイテムの個別インスタンスにアクセスすることも可能。(SortedDictionaryとどっちが早いかは未検証)
11: 名前は開発中のものです。 [sage] 2023/09/01(金) 18:09:01.68 ID:jPfSgGL6(2/2) AAS
コンストラクタに渡して〜って言ったけどコードにコンストラクタ含めてなかったわ
自分のプロジェクトではもうちゃんと実装しているからセーフ（適当）
12: 名前は開発中のものです。 [sage] 2023/09/02(土) 21:04:00.56 ID:zmatsJxn(1) AAS
その４をまとめられるほど学習が進まなかったわ
デザイン方向と機能案に時間を多く割いた結果、有名アセットとしてFinalIKを購入してデモを見て使い方をほんの少し覚えるだけで終わった
FinalIKそのものの話ではないけど、FinalIKは昔はアニメーション時にイベントを発生させる方法がSendMessageしか用意されていなかったっぽいのね（古いデモ動画見たらこれしかインスペクターに映ってなかった）
今はUnityEventにも対応しているので基本的にこっちを使うことになりそう
そもそもUnityにイベントを発生させる方法って何があるの？って再度調べてみると、現在ではUnityEventとC#Eventの二つが主流っぽい？
他にもSendMessageやBroadCastMessageというイベント発生機能も用意されているが、パフォーマンス面や管理のコストの問題を指摘する記事が多い印象（ゲームオブジェクト全体にイベントを送信してしまうため重い、関数を名前で指定するからゲームシステムを設計変更したりすると変更漏れとかが生じやすい？）
ちなみにEventSystemが入力情報を経てコールバックを発火するのに使うExecuteEventsもIEventSystemHandlerを実装するコンポーネントの関数をコールするものらしいので実はイベント発生に利用できるらしい（使う必要性があるかは知らない）
13: 名前は開発中のものです。 [sage] 2023/09/03(日) 22:10:58.50 ID:OCQOviyY(1/2) AAS
今日は独自のスクロールビューとスクロールバーをより汎用的に使えるようにコードの調整を始めた
今のコードではスクロール自体のクラスとスクロールにコンテンツを渡すクラスが密接に結びついているので、その繋がりを弱めていきたい
そこで方法を調べてみると、抽象クラスやインターフェースを利用する方法があるらしい
実は前にも抽象クラスとインターフェースについて購入したアセット素材を解読するために調べたことがあったが、正直その頃は「実装が持てない」以外のことがよく分からなかった
自分で抽象クラス・インターフェースを使ってみようと調べ直した結果、前よりは理解ができたので、ひとまずコードが少なくて調整が楽そうな独自スクロールバーにこの二つを実装してみて、ビューとバーの繋がりを弱めてみた
その４ 抽象クラスとインターフェースについて
抽象クラスもインターフェースも、これを継承したクラスに対して自身が要求する関数などメンバーを実装するように強制させる機能を有する。
他の類似点としては、両方ともインスタンスを生成することができない。抽象クラスはMonoBehaviourを継承していてもゲームオブジェクトにアタッチすることができない（エディタ上で警告文が出てアタッチ処理自体が行われない）。
逆にこの二つの違いは、
?抽象クラスは(C#では多重継承が不可能であるため)直接的には１個しか継承できないが、インターフェースは２個以上を継承することができる
?抽象クラスはフィールドを持つことができるが、インターフェースは持てない
?抽象クラスや実装のある（中身のある）関数等を持つができるため、普通の基底クラスとしても利用できる。インターフェースは持てないっぽい？（実はデフォルト実装という機能があるらしいが、C#の新しい機能だそうでUnityで対応しているかよく調べてない。しかも今のところあまり利用が推奨されないらしい）
?抽象クラスの抽象メソッドはアクセス修飾子はpublic又はprotectedでなければならない。protected（自身と派生クラスのみアクセス可能）が許されている点から抽象クラスはクラスの内部向けルールを定める性質が強い。一方でインターフェースのメンバーはpublicに限定される。インターフェースはInter + Faceの語源通りクラスの外部向けルールを定める性質が強い
14: 名前は開発中のものです。 [sage] 2023/09/03(日) 22:30:09.73 ID:OCQOviyY(2/2) AAS
今回は、インターフェースの「他のクラスのメンバーにアクセスしたいとき、そのクラスがインターフェースを実装していることさえ分かっていれば、クラス内の細かい実装を知る必要がない」という利点を体感することができた
他のクラスへの参照をインターフェースの型で取得することで、そのクラスがどんなクラスであってもそのインターフェースの実装たるメンバには確実にアクセスすることができるようになるのだ（もちろんメンバで滅茶苦茶な内容が実装されている可能性はある。ここはコードを書く人の良心任せ）
自分のプロジェクトでは独自のスクロールビューとスクロールバーを利用しているが、このうち「スクロールビューからスクロールバーに数値を渡す関数」をインターフェースの実装とすることで、スクロールバーは独自スクロールビューがどんなクラスでも数値を受け取れるようになった（今後用途に応じてスクロールビュークラスを拡張や派生させても、スクロールバークラスをその都度修正する必要がなくなった）
ちなみにスクロールビュークラス側には、今後の拡張に備えて抽象クラスを作成してその抽象クラス内でインターフェースを抽象メンバとして実装したのだが、この辺は自分でもどういう利点があるのかまだ理解しきれてないのでまた今度
15: 名前は開発中のものです。 [sage] 2023/09/04(月) 22:59:12.23 ID:8vO4bi2+(1) AAS
書こうと思ったけどTMP・文字列・GCの復習をしていたら時間がなくなったから今日は終わり！
16: 名前は開発中のものです。 [sage] 2023/09/04(月) 23:14:20.64 ID:DD6FCi8L(1) AAS
てかUnityというより
C#の仕様
17: 名前は開発中のものです。 [sage] 2023/09/05(火) 22:27:53.86 ID:1xAiAK3x(1) AAS
いまシステム面とUIを重点的に作ってるからどうしてもC#寄りになるね
その5はまとめられてないからUnityのマジックメソッドについて少し
StartやUpdateといったUnity独自の関数はランタイムによってゲーム実行時
（？）だったかに呼び出しリストが作成される
Unityの内部クラスが呼んでる訳ではないのでこれらのマジックメソッドはprivateでも呼び出しが行われる
逆にこれが原因なのか、通常の関数より呼び出しコストが高い
Update100個より1個のUpdateが100個の独自アプデ関数呼ぶ方がコール回数が1回多いはずなのに動作が軽いのは有名な話（らしい）
加えてawake OnEnable startの呼び出し順には多少注意が必要かもしれない
具体的にはStartよりOnEnableの方が早いので、Startで外部参照の設定するコードを書いてると先にOnEnableが呼ばれてヌルリファだったり意図しない挙動が起きがち
メニュー画面などのUI要素をGameObject.SetActiveで有効無効を切り替えてその際にOnEnable／OnDisableで初期化や再設定を行う設計を採っている時は扱いに注意（n敗）
ちなみにアセットのサンプル見てたら、OnEnableでコルーチン呼んで1f待機することで先に確実にStartを通す設計をしているものが見つかった
無理やりな気もするけどどうなんだろうね
18(2): 名前は開発中のものです。 [sage] 2023/09/05(火) 22:33:42.70 ID:Ts+LtVa/(1) AAS
UIやってるなら今ならちょうど
ユニティ・テクノロジーズ・ジャパンは、日本語の電子書籍『Unityにおけるユーザーインターフェースのデザインと実装』を無料で提供。専用ページから申し込めばダウンロードできるようになりました
てことで無料で見られるよ
Startを1frame待つのは理にかなってるんじゃないかな
Start関数は画面表示前の処理だし、1frameということは表示してからだから
確実だよね
19: 名前は開発中のものです。 [] 2023/09/05(火) 22:42:05.64 ID:JlRpf2nJ(1) AAS
>>18
マジか
良いこと聞いた
20: 名前は開発中のものです。 [sage] 2023/09/06(水) 22:29:47.35 ID:xeaBYfjk(1) AAS
>>18
情報サンクス
早速ダウンロードしてみたわ
UIToolKitはまだ全く手付かずだからどういうものか早く勉強しないとなあ
サンプルシーンで1f待ってるのはStartじゃなくてOnEnableね
そのサンプルはアイテム管理システムで、マネージャークラスがOnEnableでコルーチンで1f待機している間に、ゲーム開始後に道具メニューを開いた時に初めて生成されるアイテム表示用プレハブたちがStartで参照情報をマネージャーに渡してくる設計になっていた
マネージャーのOnEnableでプレハブの描画更新とイベントへのデリゲートの登録をやってるので、仮に1f待機がないとプレハブが生成される最初の1回目だけ参照情報をまだ受け取っておらずヌルリファが発生するからだと思われる
その５ 「抽象クラスの個人開発における利点がよく分からない」
まとめというより疑問に近い。
抽象クラスのメリットを調べると、大抵のサイトや記事では「抽象化によって複数人の開発で統一が取れたコードが作成できる」といった内容が挙げられている。では、個人開発における抽象クラスの利点は何なのだろうか。
結論から言うと調べても自分にはあまり理解できなかった。「無い」や「殆ど無い」としている記事も散見される。
というのも、単に複数のクラスで共通したルールを実装したいなら純粋に基底クラスを継承して利用すればだいたい足りる気がする。
たしかに抽象クラスで関数の名称やシグネチャなどを設定して派生クラスにそれに沿った実装を強制するのは、コードの統一性を確保する上では有用ではあるが、個人開発だとコードを弄るのは基本的に自分だけなので、自分で注意すればよくない？という気も
まあC#に限らずヒューマンエラーを防げます系機能は究極的には全部「自分で注意すりゃよくない？」になるし、もちろん自分にそんな神みたいなこと無理なんで…（OnEnableとStartで何回もエラー引き起こす程の低い注意力）
自分としては抽象クラスは「インスタンスは絶対これで生成しないけど共通・統一された処理を実装したい」ケースでお守り的に使っていこうかなと思った（適当）
21: 名前は開発中のものです。 [sage] 2023/09/07(木) 23:01:59.92 ID:zzCLMbJH(1) AAS
眠いから雑なぼやき
シングルトンを初めて自分のゲームに導入してみた。理由はどういうものか使ってみたかったから。
戦闘システム管理クラスをシングルトンにした。戦闘キャラクラスからたくさんアクセスする。
これが密結合か？
グローバル変数化を目的として作っちゃいけないという話は聞いたことあるけど、これもその一つかもしれない。
この辺のコード作成のパターンの理念について何も知らないからそろそろ勉強するときかなあ
22: 名前は開発中のものです。 [sage] 2023/09/08(金) 22:50:45.01 ID:whCfvpks(1) AAS
GCalloc（ヒープメモリアロケーション）にまとめたいけどまだ理解が足りていない
今日は有料アセットのGCalloc潰しを中心に作業をしたが、フィールドのList<構造体>をSortする箇所でアロケーションが発生する理由がイマイチよく分からなかった
引数としてデリゲートを渡すとアロケーションが発生するのはその都度コンパイラがnewしてしまうからで、「デリゲートの代わりにメンバを参照しないラムダ式を利用する」と初回のみのアロケーションで済むらしい
実際ラムダ式に変えたら毎フレームのGCallocが消えたのだが、「IComparerを実装したクラスのインスタンスを利用する」という方法もあると聞き、こちらも試してみたところGCallocは消えないどころか増えた
なんかボックス化というものが絡んでいるような気もするがよく分からないので今日はこれで終わり
23(1): 名前は開発中のものです。 [sage] 2023/09/09(土) 23:03:59.62 ID:DhDPacVH(1/2) AAS
GCalloc潰し二日目
昨日IComparerでGCallocが防止出来なかった理由については未だに分かっていない（というか殆ど調べていない）
「ラムダ式でメンバを参照する」コードを複数の有料アセットで見かける
GCalloc対策の話題でまず槍玉に上がる点だと思うのだが、あまり気にされていない・自分が気にしすぎなのだろうか？
24(1): 名前は開発中のものです。 [sage] 2023/09/09(土) 23:10:00.18 ID:O6P9FobY(1) AAS
えーと
研究者なら気にしてもいいかと
アプリ開発するなら今のハード考えると気にし過ぎじゃね
てか気にする必要ないでしょ
25: 名前は開発中のものです。 [sage] 2023/09/09(土) 23:34:12.06 ID:DhDPacVH(2/2) AAS
>>24
やっぱり気にし過ぎかなあ
特に今作っているゲームはPC向けだから尚更処理落ちやクラッシュはし辛いだろうし
一応自分でコード書く時はアロケーションは基本的に避けるようにしてるけど、有料アセットまで潰して回る必要はないか
26: 名前は開発中のものです。 [] 2023/09/09(土) 23:46:32.90 ID:tG9qh3d0(1) AAS
ガベージコレクションなんかC#の基本なんだから気にしなくていいだろ
そんなに嫌ならBurstCompilerでもJobSystemでもECSでも使えば良い
27(1): 名前は開発中のものです。 [sage] 2023/09/10(日) 00:04:42.69 ID:u9L0A1tk(1/2) AAS
結構規模の大きいものを作ってるから可能な限り潰しておきたい感はあるのよね
数時間のプレイに堪えられるような設計にしたい
28(1): 名前は開発中のものです。 [] 2023/09/10(日) 00:11:59.35 ID:nCKHuG8g(1) AAS
>>27
ECS,BurstCompiler使えよ
29(2): 名前は開発中のものです。 [sage] 2023/09/10(日) 09:03:38.32 ID:hFRQptHY(1) AAS
>>23
かける労力と得られるものが釣り合ってると思えるならそれぞれの判断でいいと思うけどね
今自分の作ってるやつはインクリメンタルGCついてても数分に一回3～7msくらいのGC Collectが発生してて
シューティングゲームなんでもう少しGCAlloc潰したほうがいいだろうなと思ってる
30(1): 名前は開発中のものです。 [sage] 2023/09/10(日) 15:42:12.07 ID:j4PqFMUR(1) AAS
あかん、行こう
31(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にアクセスすることはできない。
なので自分のコードに弄ったアセット側からアクセスしたい場合は、自分のコードをアセンブリ定義・分割して参照設定を追加するか、自分のコードをアセット側のアセンブリ内に入れる必要がある。
まあむしろアセットでアセンブリ定義・分割されてない方が色々と問題らしいので自分の経験は初心者特有の躓きって感じだな
32(1): 名前は開発中のものです。 [sage] 2023/09/10(日) 22:01:38.99 ID:pyk4erDp(1/2) AAS
ところでヌシはタイトルには初心者って書いてるけど
所持がガベージとか気にしないよね？
ナニモン？
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
>>31
大量にオブジェクト扱う部分は全部Burst使ってるから重い部分ではGCAllocは発生してないし、まだ開発序盤で一時的にお試しで入れてるコードやシューティングと関係ないアセットなんかでGCAllocが出てるだけなので参考になりそうな数字は持ってないよ、申し訳ない
上下前次1-新書関写板覧索設栞歴
あと 65 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.016s