Gamemakin UE4スタイルガイド() {
そこそこ妥当なUnreal Engine 4 へのアプローチ
本ガイドは、 Airbnb Javascript スタイルガイド に多大な影響を受けています。
あなたのプロジェクトが本スタイルガイドに準じているか自動的にチェックする手段は、 the Unreal Engine marketplace で購入できます。 このプラグインのソースコードは最終的に無料になりますが、UE4をソースコードからビルドせずに使用したい場合は、マーケットプレイス版の使用をお勧めします。
Gamemakin LLCは、Discordの http://discord.gamemak.in にpublicチャンネルを持っており、スタイルガイドとLinterプラグインに関するあらゆる事について、議論したい場合は #linter チャンネルを利用してください。
本スタイルガイドの全てのセクションは、参照とリンクの利便性ために番号が振られています。 http://ue4.style の末尾にハッシュタグとセクション番号を付け足すだけで、特定のセクションに直接リンクができます
たとえば、このスタイルガイドの原則、第一節へのリンクを誰かに教えたい場合は、 http://ue4.style#0.1 という風に ＃0.1 を追加しましょう。
本githubリポジトリへのプルリクエストにはそぐいませんが、素晴らしいフォーク、または翻訳を行った場合は、以下にそのフォークまたは翻訳へのリンクを追加するプルリクエストの提出をお願いします。
- Korean Translation by ymkim50
- Russian Translation by CosmoMyzrailGorynych
- Japanese Translation by akenatsu
- Chinese Translation by Beijing Skylens Tech.
'map' という用語は、普通に人々が 'level' と呼んでいるものを一般に指し、どちらを使用しても同様の意味となります。この用語の歴史についてはこちらを参照してください。
命名法にはいくつかのバリエーションがあります。 以下に一般的記法を幾つか紹介します:
全単語の最初を大文字で、スペースは使わない。例：
DesertEagle,StyleGuide,ASeriesOfWords.最初の単語は小文字で、残りの単語の最初を大文字で。例：
desertEagle,styleGuide,aSeriesOfWords.各単語は任意で大文字または小文字始まり、全ての単語間はアンダースコアで区切る。例：
desert_Eagle,Style_Guide,a_Series_of_Words.
ほとんどのコンテキスト(文脈)において、 '変数' と 'プロパティ' は同じ意味で使われます。 ただし、両方が同一コンテキスト上で使用されている場合においてのみ、使用可能です：
通常、クラス内で定義された変数を指します。 たとえば、BP_Barrel ブループリントクラスに bExploded 変数がある場合、 bExploded は BP_Barrel クラスのプロパティと呼ばれます。
クラスのコンテキスト内で使用される場合は、前もって定義したデータにアクセスできることを示すためによく使用されます。
通常は、関数の引数または関数内のローカル変数などの、変数定義を指します。
クラスのコンテキスト内では、変数自身の定義とその変数が保持する何かについての議論を円滑にするために、よく使用されます。
これらの原則は idomatic.js style guide に即しています。
既にスタイルガイドを持っているチームまたはプロジェクトで作業する場合は、それを尊重する必要があります。既存のスタイルガイドとこのガイドとの間に不一致がある場合は、既存のスタイルガイドに従わなくてはなりません。
とはいえスタイルガイドは生きたドキュメントでなければなりません。すべての用途で変更にメリットがあると感じたら、既存のスタイルガイドに本ガイド同様の変更を加えるよう提案するべきです。
プロジェクト間を移動しても、スタイルや構造の再学習が発生しない方がよいです。 スタイルガイドに従うことで、不必要な推測や曖昧さがなくなります。
また、指示に従えばスタイルについて考える必要がないので、より生産的な創作と保守が可能です。 このスタイルガイドはベストプラクティスを念頭に置いて書かれています。つまり、このスタイルガイドに従えば、問題を追跡する労力を最小限に抑えることができるのです。
スタイルガイドに反していたりスタイルガイド無しで作業している人がいる場合は指導するようにしてください。
チーム内で作業したり、 Unreal Slackers などのコミュニティで議論するときは、一貫性があれば助けたり助けを求めたりがはるかに簡単になります。 誰も、他人のブループリントのスパゲッティを解くのを手伝ったり、理解できない名前のアセットを扱ったりはしたくないのです。
あなたが手伝っている人の作品が異なったスタイルガイドに即したものでも、それに一貫性があり真っ当なスタイルガイドならば、あなたはそれに適応できるはずです。 彼らがなんのスタイルガイドにも従っていない場合は、ここへ案内してください。
UE4チームに参加するとき、最初にすべき質問の1つは「あなたたちはスタイルガイドを持っていますか？」です。 答えがノーなら、彼らのチームとして作業する能力について疑問を持たなければなりません。
(( アセットの命名規則 ))
命名規則は、法律として扱うべきです。 命名規則に準拠したプロジェクトでは、アセットの管理、検索、解析、維持管理が非常に簡単です。
ほとんどのものに接頭辞(Prefix)が付いています。接頭辞は一般的にアセットタイプの略語で、その後にアンダースコアが続きます。
すべてのアセットに 基本アセット名 (Base Asset Name) が必要です。基本アセット名は、関連するアセットの論理的なグループを表します。この論理グループの一部であるアセットは、 Prefix_BaseAssetName_Variant_Suffix(接頭辞に基本アセット名を、接尾辞に違いを)の標準に従うべきです。
パターン Prefix_BaseAssetName_Variant_Suffix を念頭に置いて常識的に使えば、一般的に良いアセット名であることが十分に保証されます。各要素に関するいくつかの詳細なルールをここで見ましょう。
Prefixと Suffixは、以下の Asset Name Modifier テーブルを介して、アセットタイプによって決定されます。
BaseAssetNameは、このアセット群の文脈に関連した簡単で分かりやすい名前によって決定されるべきです。たとえば、Bobという名前のキャラクターがいた場合、Bobのすべてのアセットで BaseAssetName は Bob になります。
独特で特殊なアセットのバリエーションの場合、 Variant は、アセットの基本名のサブセットであるアセットの論理的なグループ分けを表す簡単で分かりやすい名前のいずれかです。例えば、Bobが複数のスキンを持っていた場合、これらのスキンは BaseAssetNameとして Bobを使用しますが、認識可能な Variantを含みます。 「Evil」スキンは Bob_Evil と呼ばれ、「Retro」スキンは Bob_Retro と呼ばれる。
ユニークではあるが一般的なアセットのバリエーションでは、 Variant は 01 から始まる2桁の数字です。例えば、岩石を作成する背景アーティストがいる場合、名前は Rock_01、 Rock_02、 Rock_03 などとなります。まれな例外を除いて、バリアントに3桁の数字は必要ありません。アセットが100以上ある場合は、異なるベース名で複数のバリアント名を使用して整理することを検討する必要があります。
アセットバリアントの作成方法に応じて、バリアント名を連結することができます。たとえば、Arch Vizプロジェクトのフロアリングアセットを作成する場合は、Flooring_Marble_01, Flooring_Maple_01, Flooring_Tile_Squares_01 などの連鎖バリアントを含むベース名 Flooring を使用する必要があります。
| Asset Type | Asset Name |
|---|---|
| Skeletal Mesh | SK_Bob |
| Material | M_Bob |
| Texture (Diffuse/Albedo) | T_Bob_D |
| Texture (Normal) | T_Bob_N |
| Texture (Evil Diffuse) | T_Bob_Evil_D |
| Asset Type | Asset Name |
|---|---|
| Static Mesh (01) | S_Rock_01 |
| Static Mesh (02) | S_Rock_02 |
| Static Mesh (03) | S_Rock_03 |
| Material | M_Rock |
| Material Instance (Snow) | MI_Rock_Snow |
アセットの名前を付けるときは、これらのテーブルを使用してアセットの 基本アセット名 で使用する接頭辞(Prefix)と接尾辞(Suffix)を決定します。
1.2.1 共通項目(Most Common)
1.2.2 アニメーション(Animations)
1.2.4 ブループリント(Blueprint)
1.2.5 マテリアル(Materials)
1.2.6 テクスチャ(Textures)
1.2.7 その他(Miscellaneous)
1.2.8 Paper 2D
1.2.9 物理(Physics)
1.2.10 サウンド(Sound)
1.2.11 UI(User Interface)
1.2.12 エフェクト(Effects)
| Asset Type | Prefix | Suffix | 注意(Notes) |
|---|---|---|---|
| Level / Map | Mapsフォルダ配下に置くべき. | ||
| Level (Persistent) | _P | ||
| Level (Audio) | _Audio | ||
| Level (Lighting) | _Lighting | ||
| Level (Geometry) | _Geo | ||
| Level (Gameplay) | _Gameplay | ||
| Blueprint | BP_ | ||
| Material | M_ | ||
| Static Mesh | S_ or SM_ | どちらか1つを選択。 S_ を優先 | |
| Skeletal Mesh | SK_ | ||
| Texture | T_ | _? | Textures を参照 |
| Particle System | PS_ | ||
| Widget Blueprint | WBP_ or WB_ | どちらか1つを選択。 WBP_ を優先 |
| Asset Type | Prefix | Suffix | 注意(Notes) |
|---|---|---|---|
| Aim Offset | AO_ | ||
| Aim Offset 1D | AO_ | ||
| Animation Blueprint | ABP_ | ||
| Animation Composite | AC_ | ||
| Animation Montage | AM_ | ||
| Animation Sequence | A_ or AS_ | どちらか1つを選択。 A_ を優先 | |
| Blend Space | BS_ | ||
| Blend Space 1D | BS_ | ||
| Level Sequence | LS_ | ||
| Morph Target | MT_ | ||
| Paper Flipbook | PFB_ | ||
| Rig | Rig_ | ||
| Skeletal Mesh | SK_ | ||
| Skeleton | SKEL_ |
| Asset Type | Prefix | Suffix | 注意(Notes) |
|---|---|---|---|
| AI Controller | AIC_ | ||
| Behavior Tree | BT_ | ||
| Blackboard | BB_ | ||
| Decorator | BTDecorator_ | ||
| Service | BTService_ | ||
| Task | BTTask_ |
| Asset Type | Prefix | Suffix | 注意(Notes) |
|---|---|---|---|
| Blueprint | BP_ | ||
| Blueprint Function Library | BPFL_ | ||
| Blueprint Interface | BPI_ | ||
| Blueprint Macro Library | BPML_ | 可能な限り、マクロライブラリは使わない。 | |
| Enumeration | E | アンダースコアを付けない。 | |
| Structure | F or S | アンダースコアを付けない。 | |
| Widget Blueprint | WBP_ or WB_ | どちらか1つを選択。 WBP_ を優先 |
| Asset Type | Prefix | Suffix | 注意(Notes) |
|---|---|---|---|
| Material | M_ | ||
| Material (Post Process) | PP_ | ||
| Material Function | MF_ | ||
| Material Instance | MI_ | ||
| Material Parameter Collection | MPC_ | ||
| Subsurface Profile | SP_ or SSP_ | どちらか1つを選択。 SP_ を優先 | |
| Physical Materials | PM_ |
| Asset Type | Prefix | Suffix | 注意(Notes) |
|---|---|---|---|
| Texture | T_ | ||
| Texture (Diffuse/Albedo/Base Color) | T_ | _D | |
| Texture (Normal) | T_ | _N | |
| Texture (Roughness) | T_ | _R | |
| Texture (Alpha/Opacity) | T_ | _A | |
| Texture (Ambient Occlusion) | T_ | _O or _AO | どちらか1つを選択。 _O を優先 |
| Texture (Bump) | T_ | _B | |
| Texture (Emissive) | T_ | _E | |
| Texture (Mask) | T_ | _M | |
| Texture (Specular) | T_ | _S | |
| Texture (Packed) | T_ | _* | 下記の注記 packing を参照 |
| Texture Cube | TC_ | ||
| Media Texture | MT_ | ||
| Render Target | RT_ or RTT_ | どちらか1つを選択。 RT_ を優先 | |
| Cube Render Target | RTC_ | ||
| Texture Light Profile | TLP |
<a name="anc-textures-packing"
テクスチャデータの複数のレイヤは1つのテクスチャにパックするのが一般的な方法です。 これの一例は、発光（エミッシブ）、粗さ（ラフネス）、環境遮蔽（アンビエントオクルージョン）をテクスチャの赤、緑、青のチャンネルとしてまとめたものです。 接尾辞を決定するには、上の指定された接尾辞の文字を単純に重ねます。 _ERO。
Diffuse/AlbedoのアルファチャンネルにAlpha/Opacityレイヤーを含めることは一般的に受け入れられています。これは一般的な方法なので、 接尾辞
_DにAを付加するかどうかは好きにしてください。
Diffuse/AlbedoのアルファチャンネルのAlpha/Opacityマスク以外の4チャンネルのデータをテクスチャ（RGBA）にパッキングするのはお勧めできません。
| Asset Type | Prefix | Suffix | 注意(Notes) |
|---|---|---|---|
| Animated Vector Field | VFA_ | ||
| Camera Anim | CA_ | ||
| Color Curve | Curve_ | _Color | |
| Curve Table | Curve_ | _Table | |
| Data Asset | *_ | 接頭辞はクラスに基づいている必要があります | |
| Data Table | DT_ | ||
| Float Curve | Curve_ | _Float | |
| Foliage Type | FT_ | ||
| Force Feedback Effect | FFE_ | ||
| Landscape Grass Type | LG_ | ||
| Landscape Layer | LL_ | ||
| Matinee Data | Matinee_ | ||
| Media Player | MP_ | ||
| Object Library | OL_ | ||
| Redirector | これらはできるだけ早く修正する必要があります | ||
| Sprite Sheet | SS_ | ||
| Static Vector Field | VF_ | ||
| Touch Interface Setup | TI_ | ||
| Vector Curve | Curve_ | _Vector |
| Asset Type | Prefix | Suffix | 注意(Notes) |
|---|---|---|---|
| Paper Flipbook | PFB_ | ||
| Sprite | SPR_ | ||
| Sprite Atlas Group | SPRG_ | ||
| Tile Map | TM_ | ||
| Tile Set | TS_ |
| Asset Type | Prefix | Suffix | 注意(Notes) |
|---|---|---|---|
| Physical Material | PM_ | ||
| Physical Asset | PHYS_ | ||
| Destructible Mesh | DM_ |
| Asset Type | Prefix | Suffix | 注意(Notes) |
|---|---|---|---|
| Dialogue Voice | DV_ | ||
| Dialogue Wave | DW_ | ||
| Media Sound Wave | MSW_ | ||
| Reverb Effect | Reverb_ | ||
| Sound Attenuation | ATT_ | ||
| Sound Class | 接頭辞/接尾辞を付けません。 SoundClassesフォルダ配下に置べき | ||
| Sound Concurrency | _SC | SoundClassの後に名前付けるべき | |
| Sound Cue | A_ | _Cue | |
| Sound Mix | Mix_ | ||
| Sound Wave | A_ |
| Asset Type | Prefix | Suffix | 注意(Notes) |
|---|---|---|---|
| Font | Font_ | ||
| Slate Brush | Brush_ | ||
| Slate Widget Style | Style_ | ||
| Widget Blueprint | WBP_ or WB_ | どちらか1つを選択。 WBP_ を優先 |
| Asset Type | Prefix | Suffix | 注意(Notes) |
|---|---|---|---|
| Particle System | PS_ | ||
| Material (Post Process) | PP_ |
アセット名と同様に重要なことに、プロジェクトのディレクトリ構造のスタイルも法律のように扱うべきです。 アセットの命名規則とコンテンツディレクトリ構造が両立し、いずれかの違反は不要な混乱の原因となります。
UE4プロジェクトのコンテンツをレイアウトする方法は複数あります。 このスタイルでは、アセットをグループ化する別の共通構造ではなく、特定のタイプのアセットを検索するために、コンテンツブラウザのフィルタリングと検索機能にもっと依存する構造を使用します。
上記の 命名規則 を使用している場合、フォルダに
Meshes,Textures, およびMaterialsなどの類似の型のアセットを格納することは、アセットの型がすでにソートされているため、 プレフィックスだけでなく、コンテンツブラウザでフィルタリングすることができます。
|-- Content
|-- GenericShooter
|-- Art
| |-- Industrial
| | |-- Ambient
| | |-- Machinery
| | |-- Pipes
| |-- Nature
| | |-- Ambient
| | |-- Foliage
| | |-- Rocks
| | |-- Trees
| |-- Office
|-- Characters
| |-- Bob
| |-- Common
| | |-- Animations
| | |-- Audio
| |-- Jack
| |-- Steve
| |-- Zoe
|-- Core
| |-- Characters
| |-- Engine
| |-- GameModes
| |-- Interactables
| |-- Pickups
| |-- Weapons
|-- Effects
| |-- Electrical
| |-- Fire
| |-- Weather
|-- Maps
| |-- Campaign1
| |-- Campaign2
|-- MaterialLibrary
| |-- Debug
| |-- Metal
| |-- Paint
| |-- Utility
| |-- Weathering
|-- Placeables
| |-- Pickups
|-- Weapons
|-- Common
|-- Pistols
| |-- DesertEagle
| |-- RocketPistol
|-- Rifles
この構造の理由は、以下のサブセクションに記載されています。
2.1 フォルダ名
2.2 トップレベルのフォルダ
2.3 Developers フォルダ
2.4 Maps フォルダ
2.5 Core フォルダ
2.7 Large Sets
2.8 Material Library
以下はコンテンツディレクトリ構造での、任意のフォルダへの共通な名前付けルールです。
2.1.1 常に PascalCase を使うこと * 
PascalCaseは、大文字で名前を始めることを意味し、スペースを使用する代わりに、すべての次の単語も大文字で始まります。 たとえば、DesertEagle, RocketPistol,および ASeriesOfWords などです。
記法を参照。
常に PascalCase を使うこと を再徹底したうえで、絶対にスペースを使わないでください。 スペースによって、さまざまな開発ツールやバッチ処理などで失敗する可能性があります。 理想的には、プロジェクトのルートには空白が含まれておらず、 C:\Users\My Name\My Documents\Unreal Projects の代わりに D:\Projectのような場所に置かれているのが理想的です。
あなたのゲームキャラクターの名前が「Zoë」の場合、そのフォルダ名は Zoeでなければなりません。 Unicodeは、解析ツールやUE4の一部ではパス(path)に含まれるのUnicode文字もサポートされないため スペース より悪くなることがあります。
これに関連して、プロジェクトに 不可解な問題 があり、コンピュータのユーザー名がUnicode文字（つまり、あなたの名前は Zoë）である場合や、 My Documentsフォルダ以下にUE4プロジェクトを置いている場合は、この問題を抱えています。 ただ単にUE4プロジェクトを D:\Project などに移動するだけで、これらの摩訶不思議な問題が解決するでしょう。
@, -, _, ,, *, と # のような a-z, A-Z, 及び 0-9 以外の文字を使うことによる、 他のプラットフォーム、ソース管理、および脆弱な解析ツールの問題を追跡することは困難です。
全てのプロジェクトに関するアセットは、プロジェクトと同名フォルダ以下に存在するべきです。 たとえば、プロジェクト名が「Generic Shooter」の場合、そのコンテンツの 全て は Content/GenericShooter 以下に存在する必要があります。
Developersフォルダは、プロジェクトが依存しているアセット用ではないため、プロジェクト固有のものではありません。 これに関する詳細は Developers フォルダ を参照してください。
このアプローチには複数の理由があります。
多くの場合、コードスタイルガイドでは、グローバル名前空間を汚染しない事と書かれています。このガイドも同じ原則に従います。 アセットがプロジェクトフォルダの外に存在することが許される場合、フォルダ内にないアセットがアセットを整理する必要がないという悪い行為を促すため、厳密な構造レイアウトを強制するのはずっと困難になります。
すべてのアセットは目的を持っている必要があります。そうでなければ、プロジェクトに属していません。 アセットが実験的なテストであり、プロジェクトで使用すべきでない場合は、 Developers フォルダに置く必要があります。
複数のプロジェクトに取り組んでいるときに、２つのプロジェクトに役立つものを作っていれば、プロジェクト間でそのアセットをコピーするのがチームにとって一般的です。このようなとき、コピーを実行する最も簡単な方法は、コンテンツブラウザの移行機能を使用することです。それは選択したアセットだけでなく、同時に依存関係にあるアセットもすべてコピーします。
これらの依存関係は容易に問題を発生させ得るものです。 2つのプロジェクトのアセットにトップレベルのフォルダがなく、同様の名前が付けられているか、すでに以前に移行されたアセットがある場合は、新しい移行によって既存のアセットの変更がうっかり消し去られる可能性があります。
これはEpicのMarketplaceスタッフが提出されたアセットに対して同じポリシーを強制する主要な理由にもなっています。
移行後にコンテンツブラウザの '参照の置き換え(Replace References)' ツールを使用すると、明らかにマージを保留していて、プロジェクトのトップレベルのフォルダに属していないアセットの明確さを向上させ、アセットの安全なマージが可能になります。ひとたびアセットがマージされ、完全に移行されると、コンテンツツリーに別のトップレベルのフォルダは存在しないはずです。この方法は、完全に安全な移行を行うことを 100％ 保証しています。
たとえば、あるプロジェクトに別のプロジェクトで使用したいマスターマテリアルを作成し、そのアセットを移行したとします。このアセットがトップレベルのフォルダにない場合、 Content/MaterialLibrary/M_Master のような名前を持つ可能性があります。ターゲットプロジェクトにまだマスタマテリアルがない場合、これは問題なく動作するはずです。
一方または両方のプロジェクトの作業が進行するにつれて、それぞれのマスターマテリアルは、正規の開発過程のせいで、特定のプロジェクトに合わせて変更される可能性があります。
たとえば、あるプロジェクトのアーティストが静的メッシュ用の汎用的なモジュラーセットを作成し、誰かがその静的メッシュのセットを2番目のプロジェクトに含める場合など、問題が発生します。アセットを作成したアーティストが、指示されているとおりに Content/MaterialLibrary/M_Master に基づいてマテリアルインスタンスを使用した場合、移行が実行されると、以前に移行された Content/MaterialLibrary/M_Master のアセットとぶつかる能性が高くなります。
この問題は、予測するのも説明するのも難しい場合があります。静的メッシュを移動する人は、プロジェクトのマスターマテリアルの開発に精通している人と同じ人ではないかもしれませんし、問題の静的メッシュがマスターマテリアルに依存しているマテリアルインスタンスに依存していることに気づいていないかもしれません。しかし、移行ツールでは、依存関係のチェーン全体が機能する必要があるため、これらのアセットを他のプロジェクトにコピーするときに Content/MaterialLibrary/M_Masterを強制的に取得し、既存のアセットを上書きします。
この時点で、いずれにせよ両方のプロジェクトのマスタマテリアルが互換性がない場合は、プロジェクトのマテリアルライブラリ全体や、すでに移行されている可能性のあるその他の依存関係を壊す可能性があります。これはアセットがトップレベルのフォルダに格納されていないためです。静的メッシュの単純な移行は、今や非常に危険な作業になっています。
移行時の衝突の削減 の拡張版では、チームメンバーがサンプルコンテンツ、テンプレートファイル、またはマーケットプレイスから購入したアセットを追加することを決定した場合、プロジェクトのトップレベルフォルダに一意の名前が付けられていれば、プロジェクトで新しいアセットと干渉し合わないことが保証されます。
マーケットプレイスのコンテンツが トップレベルのフォルダルール に完全に準拠していると思ってはいけません。トップレベルのフォルダに大半のコンテンツを持つアセットが多く存在しますが、もしかするとレベルファイルがグローバル Content フォルダを汚染するのと同様にEpicのサンプルコンテンツも変更されている可能性があります。
トップレベルのフォルダ を遵守する場合の最悪のマーケットプレイスの競合は、2つのマーケットプレイスアセットがともに同じEpicサンプルコンテンツを持つ場合に起こります。プロジェクトに移動したかもしれないサンプルコンテンツも含めて、すべてのアセットがプロジェクト固有のフォルダに含まれている場合、プロジェクトは決して壊れません。
プロジェクトをDLCにリリースする予定があるか、または複数のサブプロジェクトが関連付けられていて、他のプロジェクトは移行されるか、単にビルドがクックされていない場合、これらのプロジェクトに関連するアセットは、独自に別々のトップレベルコンテンツフォルダが必要です。これにより、メインプロジェクトのコンテンツとは独立してDLCをクックすることがはるかに簡単になります。サブプロジェクトを、最小限の労力でイン／アウトすることもできます。アセットのマテリアルを変更したり、パッチにおける振る舞いをオーバーライドする非常に特殊なアセットを追加する必要がある場合は、これらの変更をパッチフォルダに加えることは容易にできて、コアプロジェクトを壊すことなく安全に作業できます。
プロジェクトの開発中に、コアプロジェクトを危険にさらすことなく自由に実験できる「サンドボックス」のようなものをチームメンバーが持つことはよくあるです。この作業が進行中でも、これらのチームメンバがプロジェクトのソース管理サーバーにアセットを配置したいと思うかもしれません。すべてのチームがデベロッパーフォルダの使用を必要とするわけではありませんが、これを使用するチームはアセットをソース管理に提出する際に共通の問題に遭遇することがよくあります。
チームメンバーが、使用準備が整っていないアセットを誤って使用することは非常に簡単なのに、一旦そのアセットが削除されると問題が発生する可能性があります。たとえば、アーティストが静的メッシュの一連の処理を反復していて、サイジングとグリッドのスナッピングが修正され続けているとします。このアセットは信じられないほどの変更や削除を受ける可能性がありますが、それがメインプロジェクトフォルダにあれば、世界の建築家はそれと知らずにレベル全体でこのアセットを使用するかもしれません。これを解決するため、チーム全員で大量の再作業を行うことになります。
これら一連のアセットがDevelopersフォルダに配置されている場合、世界の建築家はそれらを使用する理由を決して持っていないはずですし、決して問題は起こりません。コンテンツブラウザには、デベロッパーフォルダを非表示にする特定の表示オプションがあります（デフォルトでは非表示になっています）ので、通常の使用状態で誤ってデベロッパーアセットを使用することはできません。
アセットを使用できるようになると、アーティストはアセットをプロジェクト固有のフォルダに移動し、リダイレクタを修正しなければなりません。これは実質、アセットを実験段階から製品段階に「昇格」させることです。
2.4 すべてのMap* ファイルは、Mapsフォルダに配置すること
Mapファイルは信じられないほど特殊で、特にサブレベルやストリーミングレベルで作業する場合は、プロジェクトごとに独自のマップ命名システムを使用するのが一般的です。特定のプロジェクトでどのようなマップ体系が整っていても、すべてのレベルは /Content/Project/Maps 以下に属している必要があります。
場所を説明することなしに特定の地図を開くように教えることができれば、大幅な時間の節約と一般的な「クオリティ・オブ・ライフ」の改善につながります。 Maps/Campaign1/や Maps/Arenasのように、レベルがMapsのサブフォルダ内にあるのは一般的ですが、ここで最も重要なのはすべてレベルが /Content/Project/Maps 内にあることです。
これにより、エンジニア向けのクック作業も簡単になります。ビルドプロセスのレベルを手入れすることは、そのために任意のフォルダを掘り下げなければならない場合、非常に不満がたまります。チームの地図がすべて1か所にある場合、誤ってビルド内の地図をクックしそこなうことはほとんどありません。また、QAプロセスだけでなくビルドスクリプトも簡単に作成できます。
プロジェクトの動作に不可欠なアセットには /Content/Project/Coreフォルダを使用してください。たとえば、 GameMode、 Character、 PlayerController、 GameState、 PlayerState、および関連するブループリントはここに属していなければなりません。
これは、他のチームメンバーにとって非常に明確な「これらに触れないでください」というメッセージになります。非エンジニアは Coreフォルダに入る理由はほとんどありません。優れたコード構造スタイルに従えば、デザイナーは、機能を公開する子クラスでゲームプレイを調整する必要があります。世界の建築家は、ベースクラスを潜在的に乱用するのでなく、指定されたフォルダでプレハブのブループリントを使用する必要があります。
たとえば、プロジェクトがレベルに配置できるピックアップを必要とする場合、ピックアップの基本動作を定義する基本ピックアップクラスが Core/Pickups に存在するはずです。 Health または Ammoなどの特定のピックアップは、/Content/Project/Placeables/Pickups/のようなフォルダに存在するはずです。ゲームデザイナーはこのフォルダ内のピックアップを定義し調整することができますが、プロジェクト全体のピックアップを意図せず破損する可能性があるため、Core/Pickups に触れてはいけません。
全てのアセットはアセットです。
すべてのアセット名は、そのアセットタイプを念頭に置いて命名されます。従って、これらのフォルダは冗長な情報しか提供しません。これらのフォルダの使用は、コンテンツブラウザが提供する堅牢で使いやすいフィルタリングシステムで簡単に置き換えることができます。
Environment/Rocks/ に静的メッシュだけを表示したいですか？静的メッシュフィルターをオンにするだけです。すべてのアセットの名前が正しく指定されている場合は、接頭辞に関係なくアルファベット順にソートされます。静的メッシュとスケルトンメッシュの両方を表示したいですか？両方のフィルターをオンにするだけです。これにより、コンテンツブラウザのツリービューで2つのフォルダを Control-Click する必要がなくなります。
これは、ほんの僅かな利点のためにアセットのフルパス名を無駄に延長することにもなります。静的メッシュの
S_接頭辞は2文字しかありませんが、Meshes/は7文字もあります。
これを守らないと、誰かが静的メッシュやテクスチャを Materialsフォルダに置いてしまうこともありえます。
これは、 2.6 に対してほとんど例外とみなすことができます。
膨大な量の関連ファイルを持つ特定のアセットタイプがあり、そのアセットタイプにおいて各アセットは独自の目的を持っています。最も一般的な2つは、アニメーションとオーディオのアセットです。 一つのフォルダ配下に属しているこれらのアセットが15以上あることが判明した場合、それらは一つのフォルダ直下に置く必要があります。
たとえば、複数のキャラクターを共有するアニメーションは、Characters/Common/Animations にあり、Locomotion や Cinematic などのサブフォルダを持つことがあります。
これはテクスチャやマテリアルなどのアセットには適用されません。 大量の岩石がある場合、
Rocksフォルダは大量のテクスチャを持つのが一般的ですが、これらのテクスチャは一般的には特定の岩石にしか関連しておらず、適切に名前を付ける必要があります。 これらのテクスチャが Material Library の一部であってもそれは変わりません。
プロジェクトでマスターマテリアル、レイヤードマテリアル、またはアセットのサブセットに属しない再利用可能なマテリアルやテクスチャを使用する場合、これらのアセットは Content/Project/MaterialLibrary に配置する必要があります。
このようにして、すべての「グローバル」マテリアルは生きるべき場所を持ち、簡単に見つけられます。
これにより、プロジェクト内で「材料インスタンスのみ使用」ポリシーを課すことも非常に容易になります。すべてのアーティストとアセットがマテリアルインスタンスを使用する必要がある場合は、存在するべき正規のアセットのみがこのフォルダ内にあります。
MaterialLibrary以外のフォルダ内のベースマテリアルを検索することで、これを簡単に確認できます。
MaterialLibrary は、純粋なマテリアルのみで構成される必要はありません。共有ユーティリティテクスチャ、マテリアル関数、およびその他この性質をもつものはここに、つまり意図した目的を負うフォルダ内に格納する必要があります。例えば、一般的なノイズテクスチャは MaterialLibrary/Utility に置かなければなりません。
テストやデバッグのためのマテリアルは MaterialLibrary/Debug の中になければなりません。これにより、出荷前にデバッグマテリアルをプロジェクトから簡単に取り除くことができ、参照エラーが表示されるかどうかで、プロダクトアセットがそれらを使用しているかどうかがはっきり明確になります。
このセクションでは、Blueprintクラスとその内部について説明します。 可能であれば、スタイルルールは Epic's Coding Standard に準拠しています。
覚えておいてください：Blueprintではどれだけ失敗しても問題ありません。 （KorkuVeren曰く）
3.1 コンパイル(Compiling)
3.2 変数(Variables)
3.3 関数(Functions)
3.4 グラフエディタ(Graphs)
すべてのブループリントは、警告及びエラー無しで、コンパイルする必要があります。放置しておくと非常に恐ろしい予期しない動作へと次々につながるので、ブループリントの警告とエラーを直ちに修正するべきです。
破損したブループリントをSVN/git等に(ソースのバージョン管理システム)にコミット しないでください。 それらをどうしてもSVN等に保存する必要がある場合は、代わりに延期してください。
壊れたブループリントは、壊れた参照、予期しない動作、料理の失敗、頻繁で不要な再コンパイルなど、別の方法で現れる問題を引き起こす可能性があります。 壊れたブループリントはあなたのゲーム全体を破壊する力を持っています。
(( ブループリントの変数を参照 ))
「変数」と「プロパティ」という言葉は、同じ意味で使用できます。
3.2.1 名前付け(Naming)
3.2.2 編集可能(Editable)
3.2.3 分類(Categories)
3.2.4 アクセス(Access)
3.2.5 高度(Advanced)
3.2.6 一時的(Transient)
3.2.7 保存(SaveGame)
3.2.8 設定(Config)
すべての非ブール変数名は、明確で明確で説明的な名詞でなければなりません。
すべての非ブール変数は PascalCase の形式でなければなりません。
ScoreKillsTargetPlayerRangeCrosshairColorAbilityID
すべてのブール値はPascalCaseで命名するべきですが、先頭に小文字の b を付けます。
例： Deadと Evil ではなく、 bDeadと bEvilを使用して下さい。
UE4 Blueprint editors は、変数の使いやすい表示に b を含めないことを知っています。
すべてのブール値は、一般的な情報を表すならば可能なときには叙述的な形容詞として命名されるべきである。 その変数を疑問として含む単語、例えば Isを含めないでください。 これは関数用に予約されています。
例： bIsDead と bIsHostile ではなく、 bDeadと bHostile を使用して下さい。
bRunningのような動詞を使わないようにしてください。 動詞は複雑な状態につながる傾向があります。
複合および/または従属状態を表すためにブール値を使用しないでください。 これにより、状態の追加と削除が複雑になり、もはや簡単には読み込めなくなります。 代わりに列挙を使用してください。
例：武器を定義するときに、武器を再装備したり装備することができない場合は、 bReloadingやbEquippingを使用しないでください。 EWeaponStateという名前の列挙体を定義し、代わりに WeaponStateという名前のこの型の変数を使用してください。 これにより、武器に新しい状態を追加することがはるかに容易になります。
例： bWalkingや bSprintingが必要な場合は bRunningを使わないでください。 これは、明確に定義された状態名を持つ列挙として定義する必要があります。
Blueprintのすべての変数への参照は常にそのコンテキストを持つので、すべての変数名はコンテキストと重複してはいけません。
BP_PlayerCharacterというBlueprintを考えてみましょう。
悪い場合
PlayerScorePlayerKillsMyTargetPlayerMyCharacterNameCharacterSkillsChosenCharacterSkin
これらの変数はすべて重複して名前が付けられています。 これらの変数を定義しているのは BP_PlayerCharacterなので、変数はその変数が属するBP_PlayerCharacterを表しています。
良い場合
ScoreKillsTargetPlayerNameSkillsSkin
((上記のように、BP_PlayerCharacterに属する変数であることを考慮して、シンプルに表すべきです))
Atomicまたはプリミティブ変数は、ブール値、整数、浮動小数点数、および列挙型など、最も単純な形式のデータを表す変数です。
ブループリントで作業する場合、StringやVectorはスタイルの観点からアトミック的であるとみなされますが、正確にはアトミックではありません。
Vectorは3つの浮動小数点で構成されますが、Vectorは回転子と同じように全体として操作することができます。
Text変数をアトミックなものと見なすのではなく、密かにローカライゼーション機能を隠していますか？文字列のアトミックタイプは
TextではなくStringです。
Atomic変数の型名はその名前に含まれるべきではありません。
例： ScoreFloat、 FloatKills、 DescriptionString ではなく Score、 Kills、 Description を使用します。
このルールの唯一の例外は、変数が変数の型を持たない名前を使うのが読みにくい場合に、変数が '数えられる何か' を表していることです。
例：フェンスジェネレータは、X個のポストを生成する必要があります。 Postsの Postsではなく NumPostsや PostsCountにXをストアすると、 Postという名前の変数型の配列として読み込まれる可能性があります。
非Atomicまたは複合変数は、データをアトミック変数の集合として表す変数です。 Textや Nameのような隠れた振る舞いを持つ構造体、クラス、インタフェース、プリミティブはすべてこのルールの対象となります。
アトミック変数型の配列は変数のリストですが、配列は変数型の '原子性(atomicness)' を変更しません。
これらの変数は、コンテキストを考慮しながら型名を含める必要があります。
クラスが複雑な変数のインスタンスを所有している場合、つまり BP_PlayerCharacterが BP_Hatを所有している場合は、名前を変更することなく変数型として格納する必要があります。
例： MyHat、 MyFlag、 PlayerAbility ではなく Hat、 Flag、 Ability を使用します。
複雑な変数が表す値をクラスが所有していない場合は、変数型とともに名詞を使用する必要があります。
例： BP_Turretが BP_PlayerCharacterを対象とする能力を持っているならば、 BP_Turretの文脈で TargetPlayerとしてその目標を保存する必要があります。それは所有していません。
配列は上記と同じ命名規則に従いますが、複数の名詞として命名する必要があります。
例： TargetList、 HatArray、 EnemyPlayerArray ではなく Target、 Hats、 EnemyPlayers を使用します。
ブループリントの動作を設定するために値を変更するのに安全なすべての変数は、編集可能 としてマークする必要があります。
逆に、変更が安全でない、または設計者に公開されるべきでないすべての変数は、エンジニアリング上の理由で、変数が Expose On Spawn としてマークされていない限り、編集可能とマークされてはなりません。
変数を 編集可能 として任意にマークしないでください。
編集可能とマークされた変数を含むすべての Editable変数は、 Expose On Spawnとしてマークすることができるので、この値の変更がブループリントの動作にどのように影響するかを説明する Tooltipフィールドに記述する必要があります。
すべての Editable変数は、その変数に設定されては ならない 値が存在する場合、スライダと値の範囲を使用する必要があります。
例：フェンスの支柱を生成するブループリントには、編集可能な変数 PostsCount があり、-1の値は意味をなさないでしょう。 範囲フィールドを使用して0を最小値としてマークします。
編集可能な変数が構築スクリプトで使用されている場合は、誤ってエディタをクラッシュさせる大きな値を割り当てることができないように、適切なスライダ範囲が定義されている必要があります。
値の範囲は、値の境界がわかっている場合にのみ定義する必要があります。 Slider Rangeは偶発的な多数の入力を防ぎますが、未定義のValue Rangeを使用するとスライダ範囲外の値を指定することができます。この値は「危険」とみなされますが有効です。
クラスに少数の変数のみがある場合、カテゴリは必須ではありません。
クラスに適度な量の変数（5〜10）がある場合、すべての Editable変数にはデフォルト以外のカテゴリが割り当てられます。 一般的なカテゴリは Configです。
クラスに多量の変数がある場合、すべての Editable変数は、 Configカテゴリを基本カテゴリとして使用してサブカテゴリに分類する必要があります。 編集不可能な変数は、その使用法を説明する記述的なカテゴリに分類されるべきです。
パイプ文字
|を使ってサブカテゴリを定義することができます。すなわちConfig | Animations
例：武器クラスの変数セットは、以下のように構成されています:
|-- Config
| |-- Animations
| |-- Effects
| |-- Audio
| |-- Recoil
| |-- Timings
|-- Animations
|-- State
|-- Visuals
C++では、変数にはアクセスレベルの概念があります。 Publicは、クラス外のコードが変数にアクセスできることを意味します。 Protectedは、クラスおよびすべての子クラスだけがこの変数に内部的にアクセスできることを意味します。 Privateはこのクラスのみを意味し、この変数には子クラスはアクセスできません。
ブループリントには現在、Protectedのアクセスの制御の概念が定義されていません。
編集可能 変数をPublic(公開)変数として扱います。 編集不可能な変数をProtected(保護)変数として扱います。
変数が定義されたクラス内でしかアクセスされず、子クラスではないことが分かっている場合を除き、変数をプライベートとしてマークしないでください。 変数が protectedとマークされるまで、子クラスの使用を制限したいことが絶対に分かっているときは、privateを確保してください。
変数を 編集可能 であるが、頻繁には値を変更しない場合は、それを Advanced Display をマークするべきです。 これにより、拡張表示矢印をクリックしない限り、変数が非表示になります。
Advanced Displayオプションを検索するには、詳細表示された変数として変数の詳細一覧に表示されます。
編集可能 でなく、初期値がゼロまたはヌルのすべての変数は、 Transient としてマークする必要があります。
一時変数とは、値を保存して読み込む必要がなく、ゼロまたはゼロの初期値を持つ変数です。 これは、実行時まで値がわからない他のオブジェクトやアクタへの参照に役立ちます。
これにより、変数は常にゼロまたはヌルとして初期化され、エディタがこれまでリファレンスを保存できなくなり、ブループリントクラスの保存と読み込みが高速化されます。
SaveGameから派生したクラスの中でのみ変数のSaveGameプロパティを使用してください。 このプロパティは、SaveGameクラスがこの値を保存する場合にのみ使用してください。
SaveGameとTransientをミックス しないでください。 これは意味をなさないです。
Config Variableフラグは使わないでください。 これにより、設計者は ブループリント の動作を制御することが難しくなります。 構成変数は、まれに変更された変数に対してのみC++で使用する必要があります。 それらを Advanced Advanced Display 変数と考えてください。
このセクションでは、関数、イベント、およびイベントディスパッチャの作成方法について説明します。特記事項がない限り、関数に適用されるものはすべてイベントにも適用されます。
関数、イベント、イベントディスパッチャーの命名は非常に重要です。名前だけを基に、機能についてある程度の予想がつくようになります。例えば：
- それは純粋関数か？
- それは状態情報を取得してるか？
- それはハンドラか？
- それはRPCか？
- その目的は何か？
関数の名前が適切であれば、こういった質問にすべて答えることができます。
すべての関数とイベントは、情報の取得、データの計算、または何かを爆発させるなど、何らかのアクションを実行します。したがって、すべての関数はすべて動詞で始まる必要があります。それらは現時点で可能な限り語られるべきです。それらはまた、関数等が何をしているかについていくつかのコンテキストを持つべきです。
OnRep 関数、イベントハンドラ、およびイベントディスパッチャは、このルールの例外です。
良い例：
Fire- Character/Weaponクラスの場合は良い例です、それの持っているコンテキストに即しています。Barrel/Grass/及び他のあいまいなクラスであれば悪い例です。Jump- Characterクラス中であればい例です、他の場合はコンテキストが必要です。ExplodeReceiveMessageSortPlayerArrayGetArmOffsetGetCoordinatesUpdateTransformsEnableBigHeadModeIsEnemy- "Is" は動詞
悪い例：
Dead- 死んでいる？これから死ぬのか？RockProcessData- あいまいで、これらの言葉は何も意味しません。PlayerState- 名詞はあいまいです。Color- コンテキストのない動詞、あいまいな名詞。
通知変数で複製されるすべての関数は、 OnRep_Variable の形式でなければなりません。これはBlueprintエディタによって強制されます。ただし、C++ の OnRep 関数を記述している場合、それをBlueprintsに公開する際にはこの規則に従ってください。
状態を変えず、どんなオブジェクトも更新せず、単に情報、状態、またはboolのyes/noを取得するための関数を書くときには質問形式にするべきです。同時に 動詞規則 にも従うべきです。
これは質問形式でなければ、その関数がアクションを実行し、そのアクションが成功したかどうかを返すと仮定してよいのと同様に非常に重要です。
良い例：
IsDeadIsOnFireIsAliveIsSpeakingIsHavingAnExistentialCrisisIsVisibleHasWeapon- "Has" は動詞WasCharging- "Was" は "be"の過去形 '前のフレーム' または '前の状態' を参照するとき "was" を使用.CanReload- "Can" は動詞
悪い例：
Fire- 燃えている？ 発砲するか？ 燃やすのか？OnFire- 発射のイベントディスパッチャと混同することがあります。Dead- 死んでいる？これから死ぬのか？Visibility- 視認出来る？ 可視化する？ 飛行条件の説明？
イベントハンドラや、イベントディスパッチなどの関数は、On で始まるべきで、続きは 動詞規則 に従ってください。 ただし、過去のことであることがうまく読み取れる場合は、動詞を末尾に移動した方がよいかもしれません。
単語 On の連結語句は、動詞規則に従うことが免除されます。
Handle を使用することは許されません。'Unreal' では Handle の代わりに On を使用しますが、他のフレームワークでは Onの代わりに Handle を使う方がよいかもしれません。
良い例：
OnDeath- ゲームの一般的な連結語句OnPickupOnReceiveMessageOnMessageRecievedOnTargetChangedOnClickOnLeave
悪い例：
OnDataOnTargetHandleMessageHandleDeath
RPCを作成する場合は、いつでも Server、 Client、または Multicastの接頭辞が付いていなければなりません。一切の例外なくです。
接頭辞の後に、関数命名に関する他のすべての規則に従ってください。
良い例：
ServerFireWeaponClientNotifyDeathMulticastSpawnTracerEffect
悪い例：
FireWeapon- 何らかの種類のRPCを示すものではありません。ServerClientBroadcast- 混乱します。AllNotifyDeath-Multicastを使用し、決してAllを使用しないでください。ClientWeapon- 動詞ではなく、あいまいです。
すべての関数にReturnノードは必要です。例外はありません。
Returnノードは、関数の実行が終了したことを明示します。Blueprintが Sequence、 ForLoopWithBreak、および逆向きのrerouteノードで満たされる世界では、可読性、メンテナンス、およびデバッグの容易さのために明示的な実行フローが重要です。
Blueprintコンパイラーは実行フローを追うことができ、Returnノードを使用すれば、ハンドルされないReturnまたは不良なフローがコードのブランチにあるかどうかを警告します。
プログラマがfor節を追加したり、forループが完了した後にロジックを追加してループの反復が早期に返ったりするような状況では、コードフローに偶発的なエラーが生じることがあります。 Blueprintコンパイラの警告は、これらの問題のすべてを直ちに警告します。
このセクションでは、すべてのBlueprintグラフに適用される事項について説明します。
ワイヤーの始点と終点が明確になるように配置しましょう。グラフを理解するためにわざわざ頭の中でワイヤーをほどく必要はありません。以下のセクションでは、スパゲティを減らすことに紙面の多くを割いています。
いつでもノードではなくワイヤーを整列させてください。ノードのサイズとピン位置を常に制御することはできませんが、ノードの位置を制御しすることとそれによりワイヤーを制御することはいつでもできます。真っ直ぐなワイヤーのラインは、フローをわかりやすくします。凸凹に波打つワイヤーのラインはひどくわかりにくいです。BPノードを選択してStraigten Connectionsコマンドを使用することにより、ワイヤを真っ直ぐにすることができます。Hotkey: Q
良い例：ノードの上部は、白い実行ワイヤーラインを真っ直ぐに維持するためにずらしてあります。
悪い例：ノードの上端が一直線に並んでいますが、白い実行ワイヤーラインが凸凹に波打っています。
許容可能な例：特定のノードは、アラインメントツールの使い方にかかわらずうまく機能しないかもしれません。このような状況では、ノードをより近くに持っていくことで、凸凹に波打つのを最小限に抑えてください。
直線状の白い実行ワイヤーを真っ直ぐにするか、なんらかのデータワイヤーを真っ直ぐにするかが選択肢として与えられたら、いつでも白い実行ワイヤーを真っ直ぐにするべきです。
Copyright (c) 2016 Gamemakin LLC
See LICENSE
このガイドをフォークし、チームのスタイルガイドに合わせてルールを変更することをお勧めします。 以下に、スタイルガイドのいくつかの修正案を挙げることができます。 これにより、マージの競合に対処することなく、スタイルガイドを定期的に更新することができます。