ナニコレ珍百景⓷ - TejimaTuyoshi/returnread GitHub Wiki

Unity > C# > ThirdParty・OSS

細かく絞ってる方が信用性が高い。が、使えるところが決まっている。

継承もっと使おう問題。

継承は、「updateは、継承先に入る」ことになる。

そのため、継承元でupdate内に書いていても継承先には届かない。

protectedにすることで、先に届くようになる。

ちなみに、その場合先のupdateに「privete new」にしてあげよう。「updateは普通にはないぞ」というwarningがなくなる。

制作時に、「オート操作」の物がある場合はboolでの制御が必須になるため管理が一つ分多くなる。

また、「オート」と「マニュアル」の二つが必要になるため、挙動としては「二倍」になる事を理解していてほしい。(オート時の移動変更条件と考えるとそれ以上かも...)

「マニュアル操作」時には『オート解除時にマニュアル操作が可能』になるようにトリガーを作成する必要がある。

継承時には「全体」->「カテゴリ(キャラクターやアイテムなど)」->「特定のオブジェクト」のように細分化する必要がある。(その方が作成しやすい。)

ただし、特定のオブジェクトを作成するにおいて「カテゴリからくる継承」については「オーバーライド」する必要がある。

(virtual)->(override)という順序なので注意。

作成時"<color=#ffffff>のようにするとカラーが変わる"

特定のオブジェクトに当たった際に「反射」するのは「そのまま継承」すると危険かもしれない。

崖時に反転する=>トリガー(コライダー)かライン(Ray Cast)で判定するが、基本はトリガーの方が良い。

継承中、「継承元含め今作成しているコードが250行超えたら怪しい」と思うこと。

死亡時の作成時、タグないしレイヤーを作成したうえで条件に沿ったうえでそれぞれの実装を行うが、

「一部分のみ」の当たり判定においてタグを使用すると、どうしても増えてしまうのでその一部分が大部分の方のタグを取得する方が良い。

その為には、その場所特有のスクリプトを作成する必要がある。

そこで「生死判定」を持っておく必要があり、動くか否かの継承がここで行われるだろう。

なお、死亡する際の判定はキャラ自体が持っているので死亡時の判定は必要なく、死亡した「後」の話が基本になるだろう。

ちなみにカメラ外に出た瞬間に「消す」か「死亡させる(set active = false)」させる必要がある。

作成する際あらかじめカメラってすっごい面倒なコードになるから気を付けようね。

Invisible系となっている。が、操作ががっつり難しいものばかりなのでどうしようね。

if(変数 != null) {}ならいるかどうかが分かるので、消すことが出来ない特殊なエラーはこれで...(良い子はマネしないでね)

ちなみにいない場合はnull判定なので基本はnullpointerexceptionとなるが、一部例外として別のエラーが発生する場合がある。

(例:探索時、オブジェクトが発見できない位置まで行ってしまった...)=>MissingComponentExecptionの場合もある。

エラーって英語の勉強になるからいいよネ。ありがたい。ただしぬるぽ。テメェはだめだ...!

あ、そうそう作成時にrandomを無理に活用すると上限突破サバイバーして15万とか飛ぶのでマジ怖い。

理由が未だに分かってないのでどうしたもんか...

getする際、継承元であっても継承先の情報が持ってこれるのでok

sealed => これより先継承不可になる。その代わり挙動が軽くなる。

warning が別で出るけど無視でよろしく。

playerが志望する判定は、攻撃するように少し先に着けることが大事。

...実は、敵とぶつかった時でアウトなのはラグが発生してめり込む危険性があるのでおすすめできない。

というかダメ出しされます。

死亡時の判定として「死んでいるか否か」を判定しなければ死亡後も倒せるキラーマシーンが発生する。

get { return 変数;}で外側で死亡しているかを検知可能

変数A => 変数B

Aの中身はBである。

istrigger = false => トリガー判定は勘弁。という場合はこれ。

マルチ機能作成=>実際は半年がかかるため結構リスクがかかる。(サーバー量が高い。)

技術検定=>photon(Pun),モノビットなど

「V」に関するものがモノビットが多い。

サーバーを作成する上で「対応する人数(処理)と期間(時間)」が変化する場合ばあるため十分見極めてから作成しよう。

Fusion=>マルチ化する際のファイル(Photon)

ただし、「仮置き」用のサーバーなのでphoton側から「消してくれ」という指示が入る時もある。

サーバー主導型=>MMOなどの同期が必要ななる。

クライアント主導=>ロジックの結果のみをやり取りする。

サーバー側の方がチート系に対応しやすいが、結果そこまでテスト用に欲することはないのでクライアント側の方が

軽さ的に上である。

同じサーバー上で作成を行う場合、IDを入力しなければ作成状況が同期されず、衝突する可能性がある。

ID入力後は自動である程度入るようにはなっている。

サーバーなのでシャットダウンが発生するものの、これは「サーバー上での動きの保存」が勝手に行われているため初期化するため。

ID,chat,version(数字が無い場合=0),region(サーバーの環境,jpやenなど),port(0=使わない,本来はNG)などが一緒でないと一緒にならない。

サーバーである以上、それぞれのオブジェクトを「ネット上に載せる」必要があり、一部辛い部分がある。

room => staticのようにその中のサーバーでの情報は残っている状態。

それぞれに対応する「アイデンティティ」というコンポーネントを付ける必要があり、はっきり言って「プレハブ」にする必要がある。

ネットで作成する上で、「sceneを保存して確定化させる」必要がある。

送る情報を限定するためにnetwork[transform]のように名前が変わっているのが分かりやすい。と思う。

送る情報が無い場合、warningとして出力される(ゲーム自体が止まるようなエラーではない。)

これを使う場合、対象になるコードの継承元のmonobehaviourではなく、similationbehaviourに変える必要がある。

Unityにあるrandomを使うと一緒になる確率が高いので、InitState(DateTime.UtcNow.Millisecond)で不確定にさらにする。

正直つなげるところが多いので結構めんどくさかったりする。