Unityでゲームを開発するための20の悪いヒント







Gamedevは、特にチームに経験豊富なプログラマーと初心者の両方がいる場合、本当に魅力的な活動です。 UnrealやCryEngineなどのエンジンとは異なり、Unityのエントリしきい値はかなり低く、多くの場合、.NETのベテランと初心者はオフィス家具を使用した戦いで終わる関係を把握し始めます。



この記事では、あなたとあなたのチームがコードの書き方について最終的に同意するのに役立つヒントを集めようとしました。 それでは、行きましょう!



1. UnityScriptへの書き込み

プロジェクトの1つの言語は退屈です。 同僚の生活を多様化し、多言語であることを学ばせます。 C#はMicrosoftであり、一般に強力なタイピングはあなたのものではありません。



2. varを使用しないでください

Unity自体はこれを行うことを*禁止しており、一般にどのタイプの変数かは明確ではありません。 彼らがIntelliSenseのヒントについて教えてくれたら、目を転がしてください、Microsoftの脳! Notepad ++ではこれができません。



3.ミックススタイル

まあ、何? Unity自体は、C#スタイルガイドおよび財産上のイチジクキャメルケースに違反しています。 MonoDevelopを使用する場合、タブをスペースに、またはその逆に定期的に変更することを忘れないでください。 同時に、MonoDevelopでは「設定が完了しました」と全員に伝えます-このバグについては誰もが知っています!



4. XML Docコメントを書かない

彼らはファイルを詰まらせます、そして、あなたのコードは追加コメントなしで明確でなければなりません。 また、一般的に、Notepad ++はこのすべてをサポートしていません。 外部メソッドの署名を変更する場合は、XMLドキュメントを更新しないでください。オートドキュメントを読むのがもっと楽しくなります。



5.名前空間を使用しない

を使用して書くのはあまりにも退屈で、一般的に、それなしでできるのならなぜそうするのか。 すべてのスクリプトはScriptフォルダーに配置する必要があります。アルファベット順に検索する方が簡単です。



6.コンポーネントをリンクする

より多くの接続-より良い! 各コンポーネントは互いに他のコンポーネントを参照する必要がありますが、簡単です! キャラクターには、対戦相手、ドア、ゲームマネージャー、キャンバス上のキャンバスバー、ステージ上の他のオブジェクトへのリンクが必要です。 それ以外の場合、それをどのように使用するのですか?



7.参照を作成するとき、[SerializeField] private GameObject myGameObjectを使用して非表示にします。

そのため、参照はエディターでのみ編集でき、コードには反映されません。 コードで何かを変更する必要があることが判明した場合は、プライベートからパブリックに変更してください。



8.シングルトン以外のデザインパターンを使用しないでください

依存性注入またはその他のパタ​​ーンについて通知されたら、目を転がします。 どのようなnafigパターン、ここではエンタープライズではありません!



9. GameObject.SendMessage-驚くほど便利なツール。できるだけ頻繁に使用します

可能であれば、複数の行からメソッド名を収集します-メソッドがどこから来たのかを同僚が探すのがもっと楽しくなります!



10.可能な限りUnityEventを使用する

標準イベントは、特にインスペクターに表示されないため、吸盤向けです。 Unityは何の理由もなく独自のイベントを思いつきませんでした。



インスペクターを通してすべてを公開します。 コードをパーツに分割し、ボタンをクリックすると5つの異なるメソッドを設定します。このメソッドを呼び出すボタンを検索する方が楽しいでしょう。



11. AddListenerを介してイベントをサブスクライブする場合、RemoveListenerの登録を忘れる

借方記入し、コードが同時に数回機能する理由を探すことほど楽しいものはありません。 特に、これが常に発生しない場合。



12.すべてのコンポーネントをGameObjectsにキャッシュします

それらを使用しない場合でも、ボタンをクリックしたときに一度だけ使用する場合でも。 最適化をできるだけ早く開始する必要があります! 変換をキャッシュすることを忘れないでください。 変換が既にキャッシュされていると言う人は嘘つきです。



13.プロパティを使用しない

メソッド呼び出しのようにプロパティは遅く、フィールドへのアクセスははるかに高速です。 プロパティのすべての利点が発明されました。 誰かがプライベートセット、後方互換性、フィールドがプロパティに変更された場合にアセンブリを再コンパイルする必要性について話し始めると、それらを愚か者のように見ます。 とにかく、最後にフィールドをプロパティに変更したのはいつですか?



14. foreachを使用しないでください

まあ、彼らはこれについて複数回話しました。 Unity自体がforeachの使用を禁止しています。 同僚のコードでforeachを見つけたら、foreachに置き換えて、foreachがゴミを作成する方法に関する10分間の講義を読んで、フレームごとにリストを確認するベンチマークを示します。



15. Linqを使用しないでください

Linqは遅く、複雑で、一般的にはMicrosoftです。 10行の方がずっときれいです(foreachは使用しません-忘れましたか?)。 誰かがクエリ式を書くことを敢えてするなら、彼をバカと見なしてください-Mayeskyu ElはUnityと混同しています!



16.文字列を使用しないでください

文字列は、GCが収集するメモリの割り当てです。 char []を使用します-大学でリンクを渡したのは何の理由もありません。 ユニコードは必要ありません。余分なバイトを駆動するものは何もありませんが、ビットマップフォントはまだあります。



17.ジェネリックを使用しないでください

ジェネリックは遅くて困難であり、ジェネリック制約はさらに困難です。 どのようなナフィグ共分散と反分散ですか? Unityがあります。これはここにありません! 異なるタイプのクラスが必要な場合は、変数にクラス名を保存し、Type.GetType()を使用してクラス名を見つけます。



18.不必要にコルーチンを使用しないでください

非アクティブなオブジェクトでは機能せず、一般に追加の負荷が発生します。 ブール変数で状態を保持し、Updateでチェックします。すべてが1か所に収集されるため、これははるかに便利です。



19.エンジンの新しいバージョンが出たらすぐに、それを入れてProjectSettingsフォルダーにフィードします

同僚に最新のツールを維持する方法を学んでもらいましょう。 では、2日間で引き継ぐプロジェクトと、バグを含む新しいバージョンとは何でしょうか? Unityを正常にリリースできないことはあなたの問題ではありません! しかし、あなたがプレイしたい新しいパーティクルシステムがあります。



20.資産テキストのシリアル化を使用しない

彼女はエディターを遅くします。 バイナリのシリアル化ははるかに高速です。 マージについて誰かが言うとき、あなたの目を転がしてください-シーンを維持するために、彼は、ばか、何ですか? 制御する必要がある場合は、他の人の変更をロールバックするだけです。 他の人が触れないように、どのような資産に取り組んでいるかを言う必要がありました!



varおよびforeachについて
1. Bitbucketでは、 Unity リポジトリは、プルリクエストでvarまたはforeachを使用できないことを本当に示しています。 興味深いことに、同じ場所でm_k_プレフィックスなどを使用しないように書いています。ただし、C#スタイルガイドの標準に違反して、非常に多くの場所で使用しています。



この記事の一部は、使い慣れたプログラマーが提供する最適化と定期的な真珠に関するこの記事に触発されました。



ホリバーを配置しないために、foreachが実際にガベージを作成し、GCで収集する必要があることに同意することを提案します。 しかし、第一に、このルールは常に機能するわけではありません(foreachはコンパイラによって通常のforに拡張されることもあります)。第二に、各フレームで大きなリストをバイパスしなければ、99%のケースでこれは問題になりません。



PS良い週末、そして明けましておめでとうございます!



All Articles