目录
前言
第一章：工具链开发概述
第二章：游戏工具案例
第三章：实习内容
第四章：工具开发实践1——认识Unity Editor
第五章：工具开发实践2——开发最基本的profiler
专题：unity自带profiler的代码赏析
只有第三章写完了
profiler的话知道怎么写但是没能整理完。
unity自带profiler的代码仅限于知道怎么看，这个文档的工作量过于巨大了。
第三章：关于实习的内容
实习内容：写工具实现新功能；修BUG；写文档；翻TX知识库；蹭课。
本章写的都是我主要负责的。有些工作太过于详细、与项目实机画面关系密切，或者只是按别人思路堆代码，我就不记录在此了。
表格工具 WeaponFactoryCorrector
第一个需求单，恐怕是为了尽快熟悉项目才选了这个让我做。
需求与沟通环节
- 策划：我们现在有一个主表格，记录游戏所有道具的详细信息，这是万恶之源，但这次先处理一些子表格…总之我想自动纠错已经写入表格的内容。
- 【 一长段沟通之后 】
- 我：也就是说核心的需求是“覆盖”已经写入的内容。对于需要修改的道具，策划输入KEY以及要修改的内容，程序生成符合格式的内容字符串，找到并修改KEY对应的那个道具。而修改范围由策划指定。
- MT：最好还有其他的机制减少出错。
任务拆解与重难点
任务目标和路线非常清晰：
- 找出相关表格（翻代码，策划提供的不全），理清表格内行列的意义，以及表格之间的依赖；
- 根据不同输入指定的修改范围，生成对应的内容，并替换。
- 【MT的扩展任务】将表格由手填改为尽量自动生成。
大多数子问题并不难，只是非常繁琐。一共有14个表格需要整理。
但有一个相对更加麻烦，这里记录如下：
一款武器的属性继承自旧武器，但没有文件记录了武器间的继承关系。我现在要修改其继承关系，使得新武器的属性与新指定的父武器一致。
困难的部分在于，不知道原本的父武器是什么。
一个思路是根据武器名进行字符串分析找出父本，但会被历史遗留问题干扰。
然而，实际上，最终的功能效果是“替换”，那么只要知道父武器影响了哪些属性，再根据新的父本直接替换就好。
程序设计与实现
注：这里如果不写的太详细就会很空，写详细了又怕法务部警告。
概要设计
- 纠错功能：
- 策划输入需要修改的武器ID。
- 检查武器是否存在，如果存在，展示可修改的属性（用作KEY的ID也会改）。
- 策划填写必填项，余下内容自动补全。
- 修改前进行最终确认。
- 自动生成功能：
详细设计
两个主要的逻辑模块：内容生成，表格文本替换。
内容生成即从输入出发，根据表格之间的关系，生成新的表格数据项。
举个例子:
其中一个表格有 ID, FATHER_ID, NAME, POSITION, FILE_PATH等项；
输入为：
ID = 10101225
FATHER = 10101220
NAME = XXX_YYY
那么应该生成这个项的其余部分：
POSITION : 读取FATHER_ID对应的武器（为啥要单独提武器？因为项目表格关系）的对应项。
FILE_PATH : 通过字符串拼接生成。
表格文本替换即文件处理功能，使用统一接口读取、修改、保存文件。
程序开发使用MVC模式，定义：
Model为逻辑计算与文本处理环节，使用单例模式实现。
View为界面，只负责接收数据并反馈结果，只负责显示部分。
C目前并没有直接用到。
一些示意图，如果看不清的话，可以切换回“网页白天模式”
工时与代码量
工时里三分之一左右是在到处沟通需求和确定方案。
剩下大部分时间都在读代码，尽量理解项目风格和逻辑。
代码量没有统计，但UI + 功能不会少于2400行。
UI代码就unityEditor那套。
反馈
策划觉得可以。
然而这个工具最终要外包来用……总觉得沟通机制存在一些问题。
扩展1：表格工具需要什么
尽管这里很想吐槽项目规划问题，但表格总是会越来越多的，无奈。
这里只讨论一些代码和工程细节。
表格文件应该有统一读取/写入方法
吐槽：已有代码里14个表格有单独14个方法对应。项目有个统一接口但是没人用。这里有一些BUG但最终改好了。这玩意没人去沟通吗？
每个表格应该对应一个数据结构
每个表格有一个数据类型类。
比如说上文提到的表格
其中一个表格有 ID, FATHER_ID, NAME, POSITION, FILE_PATH等等项；那么应该有个类型
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
|
class TableType
{
public int/ulong ID;
public string FATHER_ID;
// 原始项目如此，父ID和子ID类型不同，此处不做修改
public string NAME;
public Verctor3 POSITION;
public string GetPrimaryKey()
{
return ID.to_String();
}
}
|
- 【UI与交互】阻断危险操作与“修改”的确认
进行改动之前一定要确认。
美术工具的整合 Ugc Factory / Ugc Decorator
起初只是一项优化需求，后来慢慢就变成新功能了。（无奈）
需求与沟通环节
- 策划：美术那边想要能调整UI位置，你去看一下；此外，美术想让武器进入场景内时自动挂载脚本。
- 我：好的
- 【一番沟通】
- 美术：挂脚本那个早都解决了。实际上需求是把两个工具合并到一起。然后有个BUG是有时灯光修改不生效，你看一下。
- 客户端：我这边也有这个问题，有个功能触发以后也会导致光效丢失。
这和需求单完全不一样啊喂！
别的暂且不论，啥事都策划传达这种机制是不是会导致一些沟通问题…
实际上的需求：
- 有两个工具，都用于调整道具姿态（朝向，尺寸），整合到一起；
- 灯光有问题要修复一下。
这里需求2会在下一节介绍。
任务拆解与重难点
整合工具的需求也比较清晰（理论上）。
- 确定两个工具的作用范围；
- 找出两个工具的差异，与美术讨论，确定是否要保留或是变更；
- 合并到其中一个。
实际上两个工具各自有一些独特功能，其中一个还作用在独特测试场景（与游戏玩法无关）内。
最终的妥协方案是独特场景可以不要，在独特场景内可用的功能（镜像、反转）等应该在其他场景或新工具内可用。
听上去不难，实际执行也不难，读表写表而已。但还是有个繁琐的点：
姿态控制功能在工具两边表现不一致。
一番调查之后发现是模型prefab方向没统一，美术解决不了这问题，那就加段代码处理一下吧。
程序设计与实现
这里倒是没什么好说的，主要都是修EditorUI，以及流程合并带来的零碎BUG。
仍然不难，仍然只是繁琐。
武器道具ID问题及解决
这玩意完全就是安全隐患…
背景
一把武器可以分成主武器、副武器、近战武器、投掷武器等。
主武器下又有各种类型，步枪、机枪、霰弹枪等等；
步枪里又可分成AK M4 等等。
而M4系列枪可能有换皮或者其他操作。
因此项目用一个8位ID记录信息：
主类型 + 子类型1 + 子类型2 + 子类型3
然后又引入了武器等级系统，又加了3位数字记录等级。
强化后，武器ID会 + 1。
现在武器ID有8位和11位（可变）两种了。
引入了新的测试插件后，又增加了一种12位ID。
这会导致什么结果呢？
a. 早期的代码和表格用8位，后期代码11位，用后期的武器ID作为KEY，无法关联到早期代码和数据。光照这种旧代码就会失效;
b. 由于每升级一次，ID就会变化，即使记录了新枪的初始ID也没用————ID在武器强化后总是新的，或者说找不到的。
问题
- 不同表格之间使用的ID格式不同
项目使用int和ulong分别保存两种ID。11位ulong转int不会报错，但数字变化。
问题是项目代码真就直接用ulong给Int赋值了
- 功能逻辑不对
举个例子。
读取旧式8位ID，然后送入新表11位查询。这肯定查不到。
当查询不到时，前人做了第一个补救：使用默认光照数值写入新表。
可问题是写进去的ID还是错的。
前人又做了第二个补救：分成两个表分别保存旧ID和新ID，两种ID都写表。
可是升级之后没有写表啊…这样升级之后的武器还是和不存在一样。
应对方式一：统一ID系统
一名Tier比我更高的同事建议我把整个系统的ID统一回8位并删一个表。
我找出所有修改范围以后逐个调整代码并记录。
然后在封版发包的前一天他觉得这样不妥又给改回去了。
应对方式二：特殊处理流程
这是我本来的计划。
检查当前场景，是老场景就读写8位，新场景就11/12位。
如果需要从旧ID转换到新ID，通过读取道具等级实现准确的转换。
新ID转旧ID就除法。（字符串装拆箱，runtime开销控制）。
此外删了一些runtime下前人的补救措施。
runtime反复读写表
前人留下的两个表格仍然生效（不得不生效，两个表格各有其他用途，还是不要删表了），但用途不同。
其他日常BUG
美术和策划会发现一些问题，找出出错的原因并修复。
这活还得程序来干。美术和策划并不擅长找原因。
枪械动画问题
描述：有把武器拿在手里的动画和模型都不对。
原因：武器用的是复制过来的属性，美术填错了avatar数据，导致模型错位。
解决：交回美术部门重做。
武器道具这种有继承关系的就应该统一管理。这只能说是项目设计的问题了，有个工具提供武器属性复制的话会好很多。
枪械旋转问题
描述：美术想要检查武器贴图的内部，反转贴图(localScale.z = -1)之后枪械朝向会乱转
原因：不同外包做的模型，模型坐标系不一致。
解决：
- 和美术反馈意见；
- 增加方向判定，对于异常朝向(
Vector3.dot(gameObject.transform.forward, Vector3.forward ) < 0 )，计算其真实的反转轴（localScale.y）与旋转角度。
灯光失效问题
描述：点击某个功能按钮后，枪械升级，但上一等级的光效失灵。
原因：ID系统问题。
解决：参见 武器道具ID问题及解决 一节。
SVN功能
描述：策划和美术想要个一键提交到SVN的功能。
解决：
- 这就纯封装API。
- 实际上原本已经有个快捷键了，但是美术不知道/键位太别扭不符合工作习惯。
- 改动：增加了SVN一键提交按钮，似乎显式的按钮更符合他们的工作习惯。
一些想法
关于游戏工具
这个项目果然还是太老了。
杂乱的工具、冗余的ID系统、一堆陈年BUG（我接的需求单都是20、21年那些）；
就针对这个项目而言，道具管理组件是很有必要的。
功能上：
- 对于基本的道具：支持创建道具、装配模型与特效、修改姿态、保存合入；
- 对于复刻或换皮道具：支持从已有道具和模型创建新武器，复制道具属性，并记录道具之间的复制关系。
界面上：
- 使用node graph或类似界面。
- 和策划及美术沟通确定最终效果。
关于项目管理工具
纯吐槽。
这个项目似乎有相当多需要调整的问题，我接的都是遗留问题，有作用但不十万火急的单子。
项目里是策划负责部分任务的人员安排，那么他确实应该知道这些需求。但是如果需求单也是他在写，那么就可能有填写不准的问题。虽然目前看来填不准也没啥问题，总是要和实际人员对接的。
那么为啥还要在需求单写那么详细？
尽管IEG有通用需求平台，但是项目策划更喜欢维护一个EXCEL表。或许策划也不喜欢TAPD。
If you like this blog or find it useful for you, you are welcome to comment on it. You are also welcome to share this blog, so that more people can participate in it. If the images used in the blog infringe your copyright, please contact the author to delete them. Thank you !