对接过发行系统的开发会频繁看到 数据归因 这个名词, 简单来说就是投放数据需要溯源分析从而知道获客来源多
以现实例子在抖音推广来说:
(广告曝光)需要投入资金购买抖音广告位
(广告展示)需要分析展示效果和频率(这部分可有可无, 有的主要只计算点击率)
(广告点击)用户看到广告之后点击推广触发下载跳转落地页等行为, 这种就是获得点击量
(安装激活)用户下载到设备安装完成, 首次启动代表整体链路激活, 这种就是设备激活量
(用户转化)用户启动之后注册/登录账号的时候, 就代表正式转化为我们的用户, 这就是用户转化量
(付费用户)如果用户正式在应用触发付费行为, 那么这就代表该用户为核心付费用户, 也就是购买广告位获得的正向收益
数据归因 所要做的就是跟踪整体链条保证让投入产出比持续健康, 保证收益 就是归因的最终目的
广告位这部分是真金白银投入的, 如果投放的渠道收益差(投入资金但收益低)就要赶快停止或者切换渠道
数据核心指标
CAC = 获取客户的成本 = Customer Acquisition Cost
计算公式: CAC = 总投放费用 ÷ 有效新增 ...
常规开发游戏初期都不需要网络处理, 部分测试开发的时候需要用授权体系来解锁功能, 针对这部分就需要前置网络授权模块
其实这种授权方式很容易被跳过, 只是作为测试的时候上报游玩数据统计而已
这种授权机制好处就是能够构建自己的游戏社区, 能够营造类似于 Steam/WeGame 这类社区来单个账号体系多个游戏共享
而且 GitHub/Bitbucket 等平台都提供规范的 OAuth 体系用于构建应用授权体系, 方便在平台发布并且授权登陆测试游玩游戏
目前 Godot 并没有类似 WebView 之类的内部浏览器渲染功能, 所以没办法直接在游戏弹出浏览器渲染, 需要比较取巧的方法
Godot 是支持 GDNative 集成 ChromiumEmbedded 内置浏览器功能; 但还是那句话, 官方直接集成否则稳定性都不好说
OAuth 授权机制的流程如下, 这里主要对象有三个, 就是 客户端/我们自己服务端/第三方平台 :
在平台创建应用, 主流基本上需要配置并且设置好以下地址:
client_id: 对外公开的应用ID
client_secret: 自己服务器使用的验证标识, ...
对于一些要求比较高的数据采集流程, 会采用模拟正常浏览器处理方式来避免被风控, 这种技术就是 浏览器模拟/浏览器渲染型爬虫
核心是用真实浏览器内核执行 JS、渲染页面, 完全模拟真人访问行为来绕过风控
比较老牌的就是 Python 的 Selenium 处理, 但如果采用 PHP 做底层采集框架(接口服务)就感觉没必要引入额外的开发语言
而 PHP 之中第三方也是具有这方面组件库, 也就是这篇文章的主角 php-webdriver
利用 php-webdriver 可以实现模拟玩家浏览器行为来采集数据, 并且一步到位来暴露自身 API 服务接口功能
注: 这里采用 PHP 的 Composer 来做包管理功能
环境安装
首先需要知道模拟玩家浏览器行为是需要用到底层浏览器驱动的, 目前底层浏览器驱动有以下方案:
ChromeDriver: https://sites.google.com/chromium.org/driver
EdgeDriver: https://developer.microsoft.com/en-us/microsoft-edge/tools/we ...
简单处理 显示设置(Display Settings) 之后就是另外 音频设置(Audio Settings) 相关
音频部分就相对来说比较简单, 游戏内部对音乐管理需求不高的话, 直接采用如下配置:
主音量(Master Volume): 全局整体游戏总音量
背景音乐(BGM Volume): 游戏当中涉及到场景/剧情等背景音乐
游戏音效(SFX Volume): 游戏当中释放技能/触发交互的弹出音乐
如果是偏剧情向(GalGame)之类, 那么需要追加人物音量(Voice Volume), 甚至要单独另开配置页面来为每个角色添加音量
音量部分都是采用 0.0~1.0 的浮点数代表百分比处理(0代表静音), 所以不会专门单独定义枚举处理, 处理也就相对显示设置简单
而 Godot 内部会用到的 API 如下所示
API 全路径
方法/属性用途
参数/返回值
核心说明
AudioServer.GetBusIndex(string busName)
通过总线名获取音频总线索引
参数：string（音频总线名，如Master/BGM/SFX）返回值：int ...
游戏当中最底层需要的就是调整系统设置, 这里列举下常见的游戏内部显示设置
如果只需要简单的显示设置, 可以按照如下这种方式设置:
这种就是标准的将所有配置简略合并成单个配置修改, 适用于简单游戏类型(无3D交互和不做手柄操作)
而相对比较复杂的显示设置, 就需要这样来设置:
这种就是相对比较复杂的, 而且会把游戏显卡游戏效果之类单独移动到游戏设置(Game Settings)
游戏设置: 双显卡切换和特效切换(高/中/低), 还有伽马值/阴影/环境光/抗锯齿/帧率上限等高级选项
这里回过头来说下应该实现的 显示设置(Display Settings), 底层用到的系统配置并且都是一次实现后续复用的功能
以最简单的设置来说, 哪怕最简单的游戏差不多多多少少需要实现以下显示设置功能
桌面模式(Display Mode): 设置游戏渲染窗口, 可以按照以下选项来切换(游戏桌面一律不运行鼠标点击拖动调整分辨率)
全屏(Fullscreen): 将界面直接拉伸填充当前主显示器, 需要知道全屏也是可以拉伸分辨率的(高分辨率屏幕设置低分辨率)
窗口化(Windowed): 将窗口默认调 ...
之前定义过 P21 项目作为示例, 这里是从 P21 项目当中扩展出来的项目工程化补充说明
工程化项目当时创建过以下目录作为项目分层:
P21Game: 游戏引擎相关
P21Tests: 游戏内部测试单元
P21Utility: 内部扩展通用功能
这个篇章就是基于 P21Utility 这方面展开的, 简单说下为什么有 Utility 层
有时候项目需要用到底层工具库, 比如 Protobuf 序列化、网络、寻路算法 等仅需要纯 C# 的通用功能
这种通用功能只需要 C# 来处理成单独功能库, 那么就不适合放在对外的 P21Game 游戏引擎相关工程之中
并且基于 C# 保证脱离游戏引擎存在, 如果后面迁移到 Unity3d 之类使用 C# 平台还能复用相关代码库
把封装代码塞到 Game 层之中会让游戏工程变得臃肿, 核心游戏逻辑(UI、玩法、节点交互)被这些代码淹没导致后期找 Bug、改功能都会极其繁琐
所以 P21Utility 只做纯 C# 通用功能封装, 对外提供清晰、简洁的 API 从而让 P21Game 只需要 调用 而不用关心底层实现
对于 Ut ...
在 GodotC# 的好处就是就是依靠引入 dotnet 大量支持, 相比 GDScript 更加现代化, 而目前主流单元测试框架以下方案:
xUnit: 比较简洁小型的测试单元框架
文档: https://learn.microsoft.com/zh-cn/dotnet/core/testing/unit-testing-csharp-with-xunit
MSTest: 微软官方的测试单元框架
文档: https://learn.microsoft.com/zh-cn/dotnet/core/testing/unit-testing-mstest-intro
NUnit: 大型且文档齐全的的测试单元
文档: https://learn.microsoft.com/zh-cn/dotnet/core/testing/unit-testing-csharp-with-nunit
这里采用比较简洁小巧的 xUnit, 避免引入过重测试单元
注意: GodotC# 和 GDScript 要求是不一样, GodotC# 更加需要严格工程化, 也就是 UI 层和功能层 ...
因为目前主要系统迁移到 Ubuntu/Debian 上, 基于这种情况就全面转移到 Linux 平台做相关游戏业务开发
这里主要是针对 Ubuntu 的 Godot C# 版本, 需要配置 dotnet 环境相关和 JetBrains Rider 的开发环境, 首先需要安装对应组件依赖:
这里官方文档都有脚本安装和 apt 安装配置; 注意不要安装 snap 版本, 这个版本会让 Rider 无法自动扫描到环境变量配置
dotnet 安装: https://learn.microsoft.com/zh-cn/dotnet/core/install
新版本 Rider 现在对于个人已经是免费提供, 所以直接去官网下载安装配置就行了; 只要你提前安装好 dotnet, Rider 就会自动扫描工具链
工具链配置在 Settings → Build,Execution,Deployment → Toolset And Build 内部, 确认 CLI 和 MSBuild 已经自动扫描到
之后就是 Godot 版本, 目前 Godot 官网默认下载不带 C#, 需要去对应页面选择下载
...
之前大部分操作都是针对单体 Actor, 但是实际生产之后免不了要操作数据库, 而 Pekko 内部已经集成这部分功能
JDBC 数据库操作: https://pekko.apache.org/docs/pekko-projection/current/jdbc.html
Slink 数据库操作: https://pekko.apache.org/docs/pekko-projection/current/slick.html
大部分情况都会看到内部所有模块都标注 用于对象持久化处理, 这些都是用于保存 Actor 状态, 如果想简单使用的话太过复杂
Slink 集成另外说明, 因为数据库相关篇幅很复杂没办法直接讲清楚; 绝大部分情况 Slink 是在 Scala 上用, Java 用 JDBC 熟悉
这里采用 pekko-projection-jdbc 官方模块和文档说明, 最后说下这个过程踩过的坑, 这里通过 Maven 引入第三方库:
123456789101112131415161718192021222324252627282930313233343536373839 ...
对于 A* 其实就是需要将整体游戏地图网格化(Grids), 很多人都戏称这种方式为 “刷格子”
网格化之后地图寻路操作其实就像是五子棋连线即可, 其中棋盘上不可获取就是障碍物列表和网格最大值.
一般寻路系统只需要做二维处理即可
对于网格化默认都是以地图左下最初地方设置为 (0,0) 起始点, 后续需要确定整个地图的最大定点值, 这部分代码如下:
12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314 ...
