No title

UE 基础gainian

必要的规范

以下规范仅作部分内容展示,随着文章推进逐步在后文补充,无法就此处进行展开.

命名规范:

1.U++根据继承的父类及使用的功能分类进行命名:

​ a.继承自UObject的请使用U开头

​ b.继承自SWidget的请使用S开头

​ c.继承自AAcotr的请使用A开头

​ d.接口的类前缀为I

​ e.模板的类前缀为T

​ f.枚举的前缀为E

​ g.布尔变量前缀为b

​ h.其他多数类均以F为前缀,如结构体

​ i.动态多播,动态单播请以F开头,单播和多播建议以F开头

​ j.Typedefs应以任何与其类型相符的字母为前缀:若为结构体的Typedefs,则使用F;若为 Uobject 的Typedefs,则使用U,以此类推。

​ k.特化的Typedef不再是模板,并应加上相应前缀,例如:typedef TArray FArrayOfMyTypes;

2.UHT需要正确的前缀,因此添加前缀很重要

3.类型和变量的命名为名词

4.方法名是动词,以描述方法的效果或被方法影响的返回值

5.所有返回布尔的函数应发起true/false的询问,如IsVisible()或ShouldClearBuffer()

6.U++建议使用大驼峰的命名方式,但是与C库和C++库等交互使用时,使用对应语言的写法亦可

7.蓝图命名规范,一般以BP_,WBP_,M_,ABP_等为前缀

8.C++对于供蓝图调用的方法一般可以使用K2_前缀开头,然后使用meta里面的Displayname来屏蔽K2_

生命周期

1.单例的UObject推荐使用Subsystem进行管理.不要再用老式C++的单例写法,比如什么饿汉式,懒汉式之类的,人都给我看麻了.

  1. 结构体推荐使用智能指针进行管理.没事没用new和delete这两个关键字,咱们不兴这个.当然你接第三库的话,当我没说.

注释格式

  1. 采用JavaDocs格式,多行或单行.以下给出函数,类,变量等参考.其实你可以应该看源码.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
  /**

\* Connect to iFlyTek SparkChat

*

\* @param WorldContextObject WolrdContext

*

\* @param InSparkChatAppID iFlyTek AppID

\* @param InSparkChatAPISecret iFlyTek APISecret

\* @param InSparkChatAPIKey iFlyTek APIKey

*

\* @param InXunFeiSparkChatReqInfo The important infomation about SparkChat settings.

*

*

\* @return UXGXunFeiSparkChatAsyncAction* Self object ptr

*/

UFUNCTION(BlueprintCallable, meta = (BlueprintInternalUseOnly = "true",

​ WorldContext = "WorldContextObject",

​ DisplayName = "XunFeiSparkChat",

​ Keywords = "XG XunFei Spark Chat Document"),

​ Category = "XGXunFeiLink|Spark|ChatDocument")

static UXGXunFeiSparkChatAsyncAction* XGXunFeiSparkChat(UObject* WorldContextObject,

​ FString InSparkChatAppID,

​ FString InSparkChatAPISecret,

​ FXGXunFeiSparkChatReqInfo InXunFeiSparkChatReqInfo);
  1. 你应当再每一个.h,.cpp,.cs文件第一行表明版权声明.如果是.h文件一定要包含”#pragma once”,避免多次包含编译.
1
2
3
4
5
// Copyright Epic Games, Inc. All Rights Reserved.



// Copyright 2023 Xiao Gang. All Rights Reserved.

项目协作

  1. 请勿多人同时修改一个蓝图,会造成蓝图的损坏!!!!特别是那个什么关卡蓝图.这种情况就只能保留一个人的工作.
  2. 尽量不要把ini文件给锁了或者改来改去,解决冲突真的很烦!

编码细节

  1. FRotator的默认构造函数时Pitch,Yaw,Roll.而蓝图里面的是Roll,Pitch,Yaw.注意使用区分.

  2. 强制内敛FORCEINLINE,可用于简单的Get方法,不要在里面写复杂语句及循环等.

  3. 在不考虑代码膨胀的情况下,推荐使用Gameplay架构关卡.GameMode运行规则,GameState存放运行数据,PlayerController响应用户控制,PlayerState存放用户数据,HUD管理MainUI,PlayerCharacter为用户控制的角色.

4.推荐在.h文件中前置声明,在.cpp文件实际include,加快编译速度,避免代码膨胀.但有时候前置声明也会带来意想不到的错误.带反射的结构体请直接包含头文件,说的就是GAS的结构体!

参考以下文章:

https://www.zhihu.com/question/63201378

  1. 对于重写的方法请务必使用vitrual及override,推荐表明继承自哪个类,析构函数请虚!

  2. TMap在Num=0的时候去find会崩溃,在运行前判断TMap的数量是否为空,直接返回.这个可能不准确,属于我遇见的奇奇怪怪的问题.

  3. 注释日志输出的管理,对应 不同的核心模块建议自定义输出日志,同时应注意日志的输出级别,Display,Error,Warning等.

  4. 采用提炼和反转来避免代码的嵌套深度,嵌套深度不宜超过3.

  5. 不要在非主线程去对UMG,UObject,Actor及其派生类进行增删改查,你会Crash!也不要去打印日志,你也会Crash!

资产规范

请对各类资产文件分类别放.

此处贴出Lyra内容目录:

img

此处给出常见资产命名,仅供参考

资产 前缀
通用 /
关卡 L_
HDRI HDR_
材质 M_
材质实例 MI_
物理资产 PHYS_
物理材质 PM_
后期处理材质 PPM_
骨骼网格体 SK_
静态网格体 SM_
纹理 T_
OCIO配置文件 OCIO_
蓝图 /
Actor组件 AC_
动画蓝图 ABP_
蓝图接口 BI_
曲线表 CT_
数据表 DT_
枚举 E_
结构 F_
控件蓝图 WBP_
粒子效果 /
Niagara发射器 FXE_
Niagara系统 FXS_
Niagara函数 FXF_
骨骼网格体动画 /
绑定 Rig_
骨架 SKEL_
蒙太奇 AM_
动画序列 AS_
混合空间 BS_
ICVFX /
NDisplay配置 NDC_
动画 /
关卡序列 LS_
Sequencer编辑 EDIT_
媒体 /
媒体源 MS_
媒体输出 MO_
媒体播放器 MP_
媒体配置文件 MPR_
其他 /
关卡快照 SNAP_
远程控制预设 RCP_