メモ帳 - TejimaTuyoshi/returnread GitHub Wiki
マテリアルは、シェーダーとテクスチャから成るアセット
Albedo - 反射光比 色と透明度を設定する
Metallic/Smoothness - 表面がどれくらい金属的/滑らかであるかを設定する
Rendering Mode
Opaque - 不透明/光沢なし
Transparent - 透明度設定可
Fade - オブジェクトが反射していても透明度を設定できる
Cutout - 透明と不透明のみで、半透明がないモード
LateUpdate = Updateの後に行われる。=>アニメーションにうってつけ。
アニメーションが「不自然」にならないように調整する。
アニメーションの不自然さを無くすための「ブレンド」の大きさは違う。
なので、Any State の場合は「全てのブレンドの位置などが一緒になる」。
攻撃時、モーションの時だけコライダーを展開している。(アニメーションによる設定)
? = nullの時は実行しない(C++のときやった”Null実行演算子”)
Animation内にある[Animation Event]を使用することで、コード内のメソッドを起こすことが可能。
ただし、Updateのような「同じ名前のメソッド」だった場合、他のくっついているコンポーネントのメソッドも呼ばれてしまう。
ReadOnly = Eventをくっつけられない。
FBXにアニメ―ションが入っているので、「アニメーション」をコピーしよう。
ナビゲーションメッシュ＝通れるor通れないの情報
ナビメッシュエージェント＝コンポーネント
ScreenpointToRay=マウスでクリックした場所に「Ray」を飛ばす
全く同じ座標にオブジェクトが複数あると、ポリゴンがちらつく
＝少しオブジェクトを「引かせる」ことで衝突およびちらつきを回避する。
「計算して」道を進んでいくので、ゴール系はNG
ルートモーション＝ モデル(キャラクター)を動かす動きを指示させる。
ルートモーションで使用すると、アニメーションとの連動が可能。(というか基本がそう。)
ただし、コライダーを動かすことはできないので使用しない方が得策。
FBX ＝ アニメーションがいっぱい。 => materialなんかも入ってる。ただし、mayaとかの絵のソフトでないと作成、編集できない。
IK ＝ 「手から」AIが計算してその場所に動かせるようにする。(逆運動)
LookAtWeight＝どれほど見るか。LookAtPosition＝何を見るか。
ただし、アニメーションでIKをONにするためには、「アニメーターのレイヤーを「IKに☑」にする」こと。
アニメーションを使用する際、「スーパーデフォルメキャラ(2~3頭身)」の方が楽。
しかし、ちゃんとしたキャラの頭身で作ると、周りの企業にいい意味で「目を付けられる」。
Base Layer = 全身。
別のレイヤーを作って入れると、「パーツごとに再生が可能」に。
この際、「マスク」にその部分を入れることで、BaseLayerを動かすことが可能に。
マスクはIKも設定が可能。
deltatimeを使用することにより、「〇秒に一回行う処理を行うことが可能」(その中に初期化を入れることが前提)と作ることが可能。
transform.TransformDirection = カメラを基準に移動
Kit tool = 必要最低限必要なものが用意される
ゲームを作るうえで、「作りやすくする」ためにこれは必要になる。
FingdAsset => アセット内にあるオブジェクトを見つけて、その動作を行うことが可能に。
ただし、話を聞かずにシーンを使って「上書き」されることがあるので
「Kit Tool」から作らせるようにする必要がある。
Receiver = 操作した際に送られる(受け手)側の方。
プロは「後々拡張可能のように、あらかじめ元のスクリプトを作成してそれを継承する」ように立てる。
「Collision Detection」パラメーターは、非常に簡単に一言で言うと「当たり判定の精度」の設定。
この設定を変えることで、高速で動くオブジェクトの動きを予測させて、すり抜けを防止することができる。
高速で動くオブジェクトについては「Continues Dynamic」の設定に変更をする。
this・・・スクリプトを指す
this.gameObject・・・ゲームオブジェクトを指す
重いのでFindは毎フレーム使用しちゃダメ
Transform.Find = 自身のすべての子オブジェクトの中から指定した名前のオブジェクトを探しだして取得する関数
大きな違いは「非アクティブオブジェクトも取得できる」「全検索ではない」
戻り値はTransform型だが、取得したtransform後ろに「.gameobject」とつけるだけで簡単にGameObjectを取得することが可能。
Spriteは型にすることが可能。
そろっている可能性がある場合の判定は、基本for文がある。(総当たり)
判定には(すべて見る方法)と(置いた場所を記録する方法)がある。
全て見る方法=>その方向にあるcellのスプライト(Material)がそのスプライトであるかを確認する。
「セルの中身を見るわけではなく、配列を見る」こと。
泥臭くてもやりましょう。
配列の方が早いです。わざわざゲームオブジェクトを見るより断然マシなので、
配列に慣れましょう。
boolは偉大。if文に使うので、基本的には使っていこう。不等号ばかりで使い方忘れるなよ?。
set{} //値の代入
get{} //外部に値を返す
これUnityでも使用する。
AIを実装するときは、「プレイヤーと同じ挙動をするようにする。」
Ramdomで置く。とかだと、AIというよりCPUの方が近い(どちらもAIではあるが、無駄な挙動を含むのでCPU)
ロジックより、関数を考えてからやる人もいる。(この挙動すれば使えるよネというのを考えたりする。)
まあ初心者はramdomすることが多い。
ただし無限に回り続ける物や、計算が混じってでかすぎる数字が出たりするので注意するべし。
手番をAIと切り替える際はAIから先に書いて、自分の処理を書く方が見やすい。
ちなみに自分の処理を省いて作成するとAI同士の戦いになる。いい研究になるネ。
velocity = 上書きを行うので危険。基本的にRigidbodyは当たり判定の時に行いたいが、velocityの計算を毎フレームずつ変化させる方法がある。
当たり判定のif文を書く際、「Tag」ではなく「GameObjectのname」で引っ張ってくることがある。これは場合によっては元の方のnameが変更されてしまう危険性があるので注意。
当たり判定やカメラ自体はUnityだけでなく、別のエンジンでも仕様は変わらないのでしっかり覚えよう。
プレハブから生成する場合、Cloneとついているが、基本的には邪魔になるのであんまり付かないようにしよう。
ground上に置かれているものからprefabを変更することが可能になるらしい。[Override]
Singleton = 〇〇マネージャー ではない。
シングルトン自体は一つしか存在しないが、他のところはみんなこちらに入り込む(参照など)ことができる。
Monovihavir = StartやUpdateを使うものが基本なので、マネージャーには使わない。
というか、シングルトンとMonovihavirを二つとも使うのはお勧めしない。
Monovihavirが誤作動や過稼働を起こすため、あんまりSingletonでそんなことをしてほしくない。
Singletonはprivateで呼ぶようにしないと、嘘の呼び出しとなってしまう。
計算を行う(別機能)場合は、スクリプトを別の物で作成しておいた方が良い。
当たり判定は「Collider」ではなく、自分で範囲を決めた上で作る方法がある。
この場合、計算が複雑になりやすく「自分自身」も判定に入っているので
ターゲットのみ発動するようにしないといけない。
ただし、「プレハブ」に対して「ヒエラルキー」のオブジェクトを直接(ステータスに)入れることはできないので、
「プレハブ」のものは「スクリプト内」のループ(for等)で判断できるようにしよう。
多分、あらかじめオブジェクトの情報を獲得できると良し。
情報を取る際には、「情報の幅」には注意が必要。
取ってきた情報の幅が大きすぎるとスクリプト内の動作の「バグ」または「不具合」が発生する恐れがある。
ちなみにFindで一発だが、[SerializeField]は先ほど言った通りステータスに入れることはできないので忘れないようにしよう。
破壊する=>UnrealにはあるがUnityにはない。
破壊する=自由切断(Mesh破壊)で可能。
カオスデストラクション=>Unrealにて破壊するコード。
実際に破壊されるような演出に近いものなので、「演出」ではない。
Mesh Cutsというのがあるのでそれを活用するとなお良い。
一気に破壊されるというよりは、切れてから保存されて物理演算が働いて吹っ飛ぶ形になっている。
マップ生成はパーリンノイズを使用している。
実際はUnityが作成したものをマップ生成に使用している。
キーバインドは=>InputSystemのInputActionRebindingExtensions.RebindingOperationを使用した上で編集している。
Aimアシストを「パワー」で調整する。
インプットシステムには「入力元」を判断する機能があるので「ImputSystem」のみで作成自体は可能。
視点によってマップの生成する範囲を決めることが可能に。
UIについてはカメラのある方法を向きながら、敵の上にあるように見えるようにすることが可能。
CRIWAREとは 音や映像を「かるく」「きれいに」「つかいやすく」する3つのミドルウェアの総称。
Unityなどに落とし込む際は、専用のPragアプリ(システム)があるのでそちらで編集およびアウトプットを行いますが、
「パッケージ」型で作られ、「custom Pacage」を使用することが可能。
距離減衰の効果を得ることが可能のため、使ってみると良い。
スキルを「ゲーム外」で保存、作成することが可能にしていた。
パラメータのリセットをする必要が出てきている。
一つのシーンから動かすのが少しキツイ構造に...
ロジックを変更=>スクリプタブオブジェクトの簡略化に成功。
インスタンスを経由してスキル(パラメータ)を管理することが可能に。
被った際にレベルが上がるようにしているため、専用の変数の確認が入っている。
vコンテナ(VContainer) = Unity(ゲームエンジン)上で動作する高速なDIフレームワーク
フレームワークをいじることは基本的にはしないが、Unity自体がまぁまぁ遅いので使用するときには順番通りにやろう。
今年はあまり流行っていない...。
Shaderは基本的にC++に「近い」のでちょっとだけやると良い。
独立したスクリプト=>そのスクリプトだけで終わる。
共依存の場合、片方に依存をしているために、
片方がエラーを起こす危険性がある。
なお、継承は片側ならokである。
共依存にしてしまうと、片側が別のスクリプトからの継承が起こる場合、もともとあった変数が書き換えられる可能性があるので注意。
ImageやTextにある「Raycast Target」は、Imageの当たり判定であるため、チェックは怠らずに
再帰から抜け出す方法を書かないとループしてしまう。
再帰呼び出しから抜けるコードを書かないと落ちる。(再帰し続けるため。)
デバッグに有効であった際、下から順番に「どの順番で呼ばれているか。」を確認することが可能。
このような呼び出し履歴を「スタックトレース」という。
デバッグ以外では、「.NET」で確認可能。
Debug.Log(Environment.StackTrace);と書いて確認することも可能。
ちなみにコードが長ければ長いほど、トラックも長くなる。
環境によってスタックサイズが異なるが、「限り」は必ずある。そういった場合LOGなんかをずっと管理することは不可能になる(容量が足りなくなる。)
一つでずっとループしていると気づきやすいが、別の関数が絡んでいるとどこでループが発生している(原因含めて)のかが分かりずらいので注意。
まぁエンジンもコンソールもエラーが出てくれるが、ちゃんと見ようね。
ただ、コンソール上ではUnityなどのエンジンよりも動くのでそこまで気にすることはない。
ちなみにエンジンの方が少ない理由は、コンソールは「空」の状態から始められるのに対し、
エンジンでは「start」という関数を読むという「stack」が消費されているため使用できる量が少なくなる。
用は「ショート回路(ループして終わらないような)コードを書かない」こと。
基本は関数は一度使われた場合、消滅するはずが「stack」に記録されているので呼び戻すことが可能。
StackOverflowException が発生する。=> Unity で一度この状態になると Unity エディター自体が不安定になるので再起動推奨。
Unityでは物理判定の処理を、デフォルトでは0.02秒毎に処理します
シーンの読み込みは大分重いのでシーン自体はできるだけ少ない方が良い。
[Multiline]を使うことで、二行以上のテキストボックスをinspectorに作ることが可能。(Textは元からテキストボックスが作成されているので不要)
Unityでは、インタフェースはGetComponentで拾ってくることができる。
インターフェース。使ってみるのもアリ。というか使えぐらいの押しっぷり。
UnityのSerializeFieldはinterfaceやvirtual classをうまく処理できない。=>Serialize Referenceならできる。
「比較的最近入った実装で、Interface等で拡張した派生クラスをデータとして設定可能にし、その変数をシリアライズ可能にする仕組み。」
ちなみに、元々あるわけじゃない。誰かが作ったものなので注意。
また、使うには以下の条件が必要。
⓵SerializeReferencとSubclassSelectorは両方指定が必要
⓶PropertyDrawerやほかのエディタ拡張と競合することがあります。
⓷複雑なクラスを指定する際、条件次第でデータが消えるなどバグることがある。
企業に入るとColliderを使うケースが少ない。
Rigidbody以外は球かRayを使用、その他は計算を個々で書くなど。
分からない=まずコピペ。=>勉強・研究=>分解して修正。
三角形の当たり判定の計算時、鋭角の部分に侵入する場合はもう一つの辺の方が近いために反対側の辺に移動する(貫通する)ケースがある。
Googleのスプレットシートを使用したキャラクターデータを使用することが可能で、「ネットワーク」を通過している。
情報を取るうえで、「プランナー」がスプレットシートを使用したデータ管理を行う上で「ネットワーク」を介在して情報管理することがあるため、
実際には「Unity」においておくのもいいが、「ネットワーク」によるスプレットシートの使用はアリ。
数字としてだけでなく、文字(Text)として情報を残しておくことも可能。
CinemaScene = カメラの動く「範囲(角度)」を決めることが可能。
オブジェクトをUIに乗せることが可能。
Unityでのセーブデータ=>IDでの記録はおすすめはできない。(JSONの方が良い。)
オクルージョンカリング = 見えていないオブジェクトを「描画しない」。
ミニマップ = 別のカメラを作成。レイヤー変更して写すものを調整。
タイヤにTrailRendererを設置。=>タイヤ痕になる。
Rayで向かう方向を表示、「近い場所」ではなく「最新の場所」にすることで、進行する道筋に戻ることが可能。(最新の場所を保存する必要アリ)
マップ生成時、「エリア」「道」「壁」「カメラ」を意識して作成する必要がある。(この後に特殊ゾーンを作成？)
Unity内では、Scriptの継承に「MonoBehaviour」がなければUnity内でアタッチすることは不可能。(言語としては正しい)
Unity内では最近は、
**「複数クラスがある場合、外のScript名とクラス名が同じで継承もされている状態でなければならない。」**だけで、
一つの場合は継承さえ守られていれば名前は縛られないらしい。
「MonoBehaviour」がなくても「実行」する方法がある。
[RuntimeInitializeOnLoadMethod]があることで、実行してくれる物がある。
これは「ゲーム全体」のリセットに向いているため、個々のオブジェクトには向かない。
最悪、アタッチされていない状態でも動く。結構厄介じゃない?でも「マネージャー系」向き。
なお、「どのタイミングで発動するか」を指定できるらしいがDebug.logぐらいじゃないとエラーを出す。
どっちにせよゲーム実行内で行うようにしよう。
Splash => 再生される前 Scene=> 実行されてから。beforeとafterの二種類あるので、しっかり確認しよう。
継承アリと継承ナシ(MonoBehaviour)の混合は危険。混ぜるな!
最初っからあるクラスは最初に残しておくこと。
というか、基本は一クラスにつき一クラスの方が安全。(人による)
class中身=>メンバなのだが、これにも若干の縛りがある。
メンバには「11つ」ある。
・定数
constで使用可能。「コンパイル時に定義される」もの。 宣言された値の別名。 定数を定義する際、「定数式」が必要。ただし、 null以外の型でなければならない。(コンパイル時に確定できないと使用不可能) 別の変数に計算式として入れる場合、 「定数同士」で「コンパイル時」に解決される問題なので、 「実行時」には起こらない。なので、一回ずつ作り変える必要がある。 なお、代表的な定数として「円周率(Mathf.PI)」や「自然対数の低(Mathf.E)」等がある。 基本的には「マジックナンバー」を使用せずに変数で使用する「変化しない」数字の場合はこれでよい。
・フィールド
型と変数定義が基本 voidなんかの「関数」が分かりやすい。 Unityなんかではゲームオブジェクトのnew系を行うことは少ないが、 生成系に関わっている。 そのデータに基づいた型を取得することが可能。 複数のデータを一つのデータにしてまとめる役割が基本。 この覚え方。あんまりよろしくないが。 ただの変数のみで「型が一切設定されていない変数を使用しても意味がない。 オブジェクトが二つある場合、それぞれが設定されて それぞれが「情報」を持っている。のでデータが二個分あることになる。 データ管理を一番する場所なので、 計算を謝らないようにしよう。 代入方法によって、「数値が同じ」場合と、「異なる状態」にすることが可能。 ただ代入すると「値型」だが、stractを使用すると「参照」になる。 (代数的要素)にのみ使用。vectorなど。 publicで「組み込み型」の場合、[SerializeField]と同じになる。 フィールドは基本「public」にすることは基本無い。(カプセル化)大事。 継承していない通常のクラスの場合。 それをフィールドに使用できるが、そのままではパラメータには表示されない。 [Serializable]をpublicでないクラスの上に使用すれば表示する事が可能。 構造化としての始まりである。(正確に言うともうちょっと分化するが...) 他にも「変更されない変数(オブジェクト必須)」として「readonly」がある。 constとの違い=>実行時に型を自己解釈して使用することが可能。 わざわざコンパイルする必要が無い。 オブジェクトに作用するので、Randamを使用すると一個づつ変化していることが可能。 ただし、書き換え不可能なので実行してから変更するのは不可能。
・コンストラクタ
必ずクラス名と同じでなければ使用不可能。ただし、戻り値が不要。 オブジェクトが自身を初期化をするための物。 インスタンス生成時に自動的に記述した処理が実行されるメソッド。 関数とかではないので、「書き方」によるものといった考え方の方が楽ではある。 Unityでは使用する事はあまりない。 なんだったら「使うな!」とまで言われている。 一応使えるには使えるが、危険。 理由として、 「シリアライズ化されるタイミングでコンストラクタが実行される」 「シーンやプレハブを開いたときにシリアライズ化されている」 という理由。 簡単に言えば、実行時にずっと実行され続けて通常処理とコンストラクタに書いた処理が ぶつかり合うことがあるとのこと。上書きもされないので邪魔になる。 さらに言えばその状態でもし「生成」を書いていた場合、 生成された物が溜まりつづけてしまう危険性もある。 Unityでの「MonoBehaviour」では使用しない方が良い。
・ファイナライザ
コンストラクタの逆であるデストラクタと同じ(実際にはデストラクタはファイナライザを呼び出している)、 インスタンスが消える際に実行される。 startではすぐに実行されるが、updateではゲームが終わらない限りずっと実行される。 こちらは、C#ではどのタイミングでインスタンスの消去が行われているかが 不確実のため、必ず実行されるわけではない。(.NET Frameworkが管理している) そのため、最悪コンストラクタの処理がずっとし続ける危険性がある。
//ToStringのoverrideを行っているため、ログやテキストにオブジェクト関連の情報を流すことができる