引擎工具链开发3-关于实习内容

目录

前言
第一章：工具链开发概述
第二章：游戏工具案例
第三章：实习内容
第四章：工具开发实践1——认识Unity Editor
第五章：工具开发实践2——开发最基本的profiler
专题：unity自带profiler的代码赏析

只有第三章写完了

profiler的话知道怎么写但是没能整理完。
unity自带profiler的代码仅限于知道怎么看，这个文档的工作量过于巨大了。

第三章：关于实习的内容

实习内容：写工具实现新功能；修BUG；写文档；翻TX知识库；蹭课。
本章写的都是我主要负责的。有些工作太过于详细、与项目实机画面关系密切，或者只是按别人思路堆代码，我就不记录在此了。

表格工具 WeaponFactoryCorrector

第一个需求单，恐怕是为了尽快熟悉项目才选了这个让我做。

需求与沟通环节

• 策划：我们现在有一个主表格，记录游戏所有道具的详细信息，这是万恶之源，但这次先处理一些子表格…总之我想自动纠错已经写入表格的内容。
• 【 一长段沟通之后 】
• 我：也就是说核心的需求是“覆盖”已经写入的内容。对于需要修改的道具，策划输入KEY以及要修改的内容，程序生成符合格式的内容字符串，找到并修改KEY对应的那个道具。而修改范围由策划指定。
• MT：最好还有其他的机制减少出错。

任务拆解与重难点

任务目标和路线非常清晰：

1. 找出相关表格（翻代码，策划提供的不全），理清表格内行列的意义，以及表格之间的依赖；
2. 根据不同输入指定的修改范围，生成对应的内容，并替换。
3. 【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：表格工具需要什么

尽管这里很想吐槽项目规划问题，但表格总是会越来越多的，无奈。
这里只讨论一些代码和工程细节。

1. 表格文件应该有统一读取/写入方法
   吐槽：已有代码里14个表格有单独14个方法对应。项目有个统一接口但是没人用。这里有一些BUG但最终改好了。这玩意没人去沟通吗？

2. 每个表格应该对应一个数据结构
   每个表格有一个数据类型类。

比如说上文提到的表格
其中一个表格有 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();
}
}

3. 【UI与交互】阻断危险操作与“修改”的确认
   进行改动之前一定要确认。

美术工具的整合 Ugc Factory / Ugc Decorator

起初只是一项优化需求，后来慢慢就变成新功能了。（无奈）

需求与沟通环节

• 策划：美术那边想要能调整UI位置，你去看一下；此外，美术想让武器进入场景内时自动挂载脚本。
• 我：好的
• 【一番沟通】
• 美术：挂脚本那个早都解决了。实际上需求是把两个工具合并到一起。然后有个BUG是有时灯光修改不生效，你看一下。
• 客户端：我这边也有这个问题，有个功能触发以后也会导致光效丢失。

这和需求单完全不一样啊喂！
别的暂且不论，啥事都策划传达这种机制是不是会导致一些沟通问题…

实际上的需求：

1. 有两个工具，都用于调整道具姿态（朝向，尺寸），整合到一起；
2. 灯光有问题要修复一下。

这里需求2会在下一节介绍。

任务拆解与重难点

整合工具的需求也比较清晰（理论上）。

1. 确定两个工具的作用范围；
2. 找出两个工具的差异，与美术讨论，确定是否要保留或是变更；
3. 合并到其中一个。

实际上两个工具各自有一些独特功能，其中一个还作用在独特测试场景（与游戏玩法无关）内。
最终的妥协方案是独特场景可以不要，在独特场景内可用的功能（镜像、反转）等应该在其他场景或新工具内可用。

听上去不难，实际执行也不难，读表写表而已。但还是有个繁琐的点：

姿态控制功能在工具两边表现不一致。

一番调查之后发现是模型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在武器强化后总是新的，或者说找不到的。

问题

1. 不同表格之间使用的ID格式不同
   项目使用int和ulong分别保存两种ID。11位ulong转int不会报错，但数字变化。

问题是项目代码真就直接用ulong给Int赋值了

2. 功能逻辑不对
   举个例子。
   读取旧式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)之后枪械朝向会乱转

原因：不同外包做的模型，模型坐标系不一致。

解决：

1. 和美术反馈意见；
2. 增加方向判定，对于异常朝向( Vector3.dot(gameObject.transform.forward, Vector3.forward ) < 0 )，计算其真实的反转轴（localScale.y）与旋转角度。

灯光失效问题

描述：点击某个功能按钮后，枪械升级，但上一等级的光效失灵。

原因：ID系统问题。

解决：参见 武器道具ID问题及解决 一节。

SVN功能

描述：策划和美术想要个一键提交到SVN的功能。

解决：

1. 这就纯封装API。
2. 实际上原本已经有个快捷键了，但是美术不知道/键位太别扭不符合工作习惯。
3. 改动：增加了SVN一键提交按钮，似乎显式的按钮更符合他们的工作习惯。

一些想法

关于游戏工具

这个项目果然还是太老了。

杂乱的工具、冗余的ID系统、一堆陈年BUG（我接的需求单都是20、21年那些）；

就针对这个项目而言，道具管理组件是很有必要的。

功能上：

1. 对于基本的道具：支持创建道具、装配模型与特效、修改姿态、保存合入；
2. 对于复刻或换皮道具：支持从已有道具和模型创建新武器，复制道具属性，并记录道具之间的复制关系。

界面上：

1. 使用node graph或类似界面。
2. 和策划及美术沟通确定最终效果。

关于项目管理工具

纯吐槽。

这个项目似乎有相当多需要调整的问题，我接的都是遗留问题，有作用但不十万火急的单子。

项目里是策划负责部分任务的人员安排，那么他确实应该知道这些需求。但是如果需求单也是他在写，那么就可能有填写不准的问题。虽然目前看来填不准也没啥问题，总是要和实际人员对接的。

那么为啥还要在需求单写那么详细？

尽管IEG有通用需求平台，但是项目策划更喜欢维护一个EXCEL表。或许策划也不喜欢TAPD。

• ← Previous Post
• Next Post →