golang的数据类型转换是困惑新gopher的一大问题之一。相对于python,golang的数据类型转换可要麻烦的多,而且还不走寻常路地诞生了些新的方法跟名词。因此本文讲解golang常见数据类型string、int、rune等数据类型相互之间的转换方法,给大伙儿避坑。
在讲述方法之前,首先非常有必要讲下go源码对这些数据类型的表述:
golang的数据类型转换是困惑新gopher的一大问题之一。相对于python,golang的数据类型转换可要麻烦的多,而且还不走寻常路地诞生了些新的方法跟名词。因此本文讲解golang常见数据类型string、int、rune等数据类型相互之间的转换方法,给大伙儿避坑。
在讲述方法之前,首先非常有必要讲下go源码对这些数据类型的表述:
UE4在构建场景光照时,会启动swarm agent
进行构建,但如果只用一台电脑会出现构建速度较慢的情况。为了加快编译的效率,需要配置联机渲染。
首先需要注意的是,在UE4中自动打开swarm agent
和手动打开swarm agent
会用到不同的配置。因此,建议的方法是手动打开swarm agent
进行配置(对于所有机器),然后再开UE4。每个swarm agent
以及调度器swarm coordinator
的可执行文件位置,都在引擎的Engine\Binaries\DotNET
下
在官方文档中,有Unreal Swarm
配置的例子可以参考。假设你有一台性能强劲的机子,和一台你日常工作但性能一般般的机子。这样可以如下配置:
许多游戏,尤其是MMO,会包含“副本”这个概念,玩家通过打副本从而获得物品奖励及属性收益。通常来讲,单个游戏所涉及的副本数量/品种较多,因此在游戏测试过程当中,很难一次性全部遍历完所有副本的流程与玩法。为了解决这个问题,可以通过自动化测试的方式去冒烟副本玩法流程、检查奖励。为了让自动化测试用例执行更加稳定且易于维护,需要一套通用的逻辑模版去实现副本玩法自动化。自动化测试流程涉及多个部分,包括玩家账号的准备、副本的进入、副本流程、奖励检查,而本文主要考虑“副本流程”的实现。
副本玩法的机制可以如下描述:玩家在进入副本后,服务器会为玩家创建一个分线并让玩家执行切线操作切入副本内,而后下发副本信息,客户端则缓存信息,为玩家创建场景及指引,而后玩家根据指引游玩副本内的内容。每当玩家执行了特定的行为,比如走到指引的位置/干掉指引的怪物,就会触发这些指引绑定的触发器,触发器生效后,服务器就会同步触发出来的下一阶段的信息给到客户端,客户端便展示出下一阶段的指引,直到副本结束或者发生错误、意外退出为止。从副本机制可以看到,副本玩法的每一个步骤,在客户端中都有缓存相关的信息,在自动化的实现上,只需要每一个轮次读取副本信息,执行相关的行为即可(任务也是如此)。因此,我们可以设计如下的行为来自动跑副本:
excel-differ是游戏测试常用的测试工具。在有些业务场景下,excel-diff的结果可能需要通过web展示。Vue技术栈下的vxe-table表格组件能够支持大量数据的展示,因此可以用vxe-table展示excel-diff的结果。
excel-diff的算法本身,先前的文章已有讲解,在结果展示上会按file->sheet来分。为了让结果展示更加人性化,需要对表格的样式进行区分。在vxe-table的api列表中,我们可以通过cell-class-name
的回调函数指定每个单元格的样式。针对excel-diff的结果可以这样设计样式:
在射击类游戏中,不可避免地需要对各种枪械武器进行测试。大多数情况下,枪械种类繁多,人工遍历测试会花非常多的时间,因此引入自动化测试替代人力执行部分冒烟用例,能够增加严重问题提早发现的可能性。枪械测试包括基础行为、伤害、弹道、后坐力等方面,从功能冒烟的角度考虑,基础行为和伤害是需要优先覆盖的部分。因此,本文以UE4引擎下的枪械测试为例,讲解基础行为跟伤害测试的一些设计。
后端的服务间通常采用固定的协议&rpc框架通信,当前主流的方案是以protobuf协议为基础,采用grpc进行通信,这种方式在Golang的开发中尤其突出。因此,笔者决定做一个小的golang应用来踩坑protobuf+grpc编码模式,上传到github分享——这便是protobuf-grpc-starter。
protobuf-grpc-starter主要受到了PasteBin的启发,用户post一段代码到服务器,得到一个短链接(shortLink),其它用户可以通过这个短链接取查看这个用户所发送的代码,实现代码文本分享。当存储文本量较大、且用户访问量较多时,数据库不一定能够承载的了查询的压力,这样就需要缓存来分担查询的任务。因此在protobuf-grpc-starter中,笔者编写了两个小server:WebSvr和CacheSvr,其中WebSvr用于处理用户的查询以及post文本请求,post的文本存储在单独的文件中;CacheSvr则在内部实现了一个驻留内存的LRU缓存,用来缓存短链接查询的结果(短链接only,保证强一致)。WebSvr和CacheSvr间基于protobuf协议采用grpc-go框架通信,处理获取/设定查询缓存的操作。为了保证新接触protobuf+grpc的同学能够专注于此,这个项目的prerequisities里也不会引入类似redis的中间件,而只有go、grpc、protobuf等相关的内容,包括:
整个项目的结构如下:
策划表格数据检查是游戏测试工作的刚性需求。在游戏开发期中,有大量bug的起因是策划同学在配置上不够规范到位。因此作为测试角度而言,需要更加便捷、更加精准的方法去定位到策划表格配置的问题。除了依靠业务人员自身对业务的熟悉程度之外,也更加依赖于一个强大有力的工具,辅助表格数据检查。
表格数据检查的目的有以下一些:给定某个数值策划案,检查实际配置与策划案是否有出入;给定某个配置规则,检查实际配置是否有不符合规则,造成风险的地方(除去程序导表检查的那一部分)。针对这些需求,简单粗暴的方法就是强行coding的方式,将读取表格(Excel)数据出来(或者将表格数据转化为程序文件),然后用编码的方式联表,继而通过coding逻辑,去导出不符合规则的数据。这一种方式虽然灵活,但对于业务侧同学,还存在壁垒以及需要突破的地方:
因此总体来看,除了采用coding这一备选方案之外,另外一个较好的方法是采用声明式、配置化的方式描述表格检查规则,通过一系列数据处理规则的串联,导出来一份最终数据。这样一来相对减少了学习成本,从业务侧角度而言,从“学习coding”变成了“理解配置”;二来解决了联表效率的问题,业务侧只需要描述一个联表的数据处理规则,后台就可以自动按照规则描述的方式对数据处理,最终呈现到业务的,直截了当,就是最终的结果;三来解决了根本目的,不论是策划案比对(通常是另外的文档,不能按版本diff)还是检索不合规的数据,本质上都是数据导出,因此用数据处理规则的串联,就能解决大部分的需求。
在UE4游戏开发中,官方文档推荐了2套功能:Data Driven Gameplay Elements以及Programming Subsystems。我们可以结合这两者的功效,实现一个简单的表格配置数据管理模块。
Data Driven Gameplay Elements讲述了一套通过DataTable数据表的asset驱动gameplay的方式。在C++代码中,我们可以预先定义好表结构所对应的USTRUCT,然后通过导入CSV文件的方式,去创建以该USTRUCT为结构基础的DataTable。这样在游戏里,如果需要读取配置数据的话,就可以直接在蓝图中添加获取DataTable以及获取行数据的节点,填写对应的asset路径与rowname(表格主键,以---
为标题的列),就能够获得对应行的数据了。注意这种方式如果在需要热更的手游中是不适用的,需要用其他的方式(比如将表格配置转化为lua)
Programming Subsystems讲述了UE的Subsystem编程模式。Subsystem重点解决了单例Manager在游戏中生命周期的问题,并且能够直接导出方法到蓝图中,供蓝图侧调用。因此,Subsystem一个很棒的用途,就是分担BlueprintFunctionLibrary的工作。
以下,我们观察一个利用Subsystem模式在C++侧创建一个DataTable Manager的功能实例:
2021,新的开始,曾经精心制作的轻量级web后端框架start-fastapi也经历了一次升级。这次升级,是基于这一年来使用start-fastapi开发以及应用与业务工作的经验,对已有框架进行的结构性的优化。
start-fastapi,甚至是FastAPI本身,其专注的方面都是在快速实现轻量级应用当中。在升级后2021版的结构中,针对如何更加效率地组成FastAPI应用,下了很多手笔。我们可以一探究竟: