MeteorCat

Godot分包方案 主要针对的是在 Godot 实现 Unity 的 AB包(Asset Bundle Package) 概念. 对于商业游戏来说都会把非核心资源切分成网络包, 通过CDN把资源包发布上加速资源下载速度; 也就是默认启动游戏应用都会生成空白游戏场景, 之后会把资源包从CDN更新到最新业务代码之中. 这种方式也算是一种热更新方式, 通过将非核心功能(场景|皮肤等)提取出来设置动态客户端的资源替换. 很有必要的流程, 可以直接做些临时的动态皮肤热更不用全面覆盖更新, 已上架的游戏不修改版本可以直接更新 这里需要说明的是, 以下示例都是采用 Godot C# 版本开发, 方便契合 Unity 转移到 Godot 开发; 并且 C# 能够尽可能复用 .net 相关的第三方社区扩展, 比如 Protobuf 这些相关的功能. 不过目前截止在 Godot 4.5 版本还无法做 Web 打包, H5 游戏支持需要后续版本解决才能出包 这里想构建项目, 并且追加两个场景分别是初始化入口场景和网络加载场景, 注意后续 C# 版本脚本文件都是尽可能采用 .net 规范(大驼峰): 注意: 一般推荐材质贴图单独封成材质包抽离出来, 做到 美术 和 业务 分离 一般需要准备材质表来加载其中所有的材质路径, 比如: user://Packages/UI.pck → https://cdn.localhost/Packages/UI.pck 这里具体流程如下: 请求远程接口确定目前最新版本的材质包文件 MD5 哈希码 获取本地 UI.pck MD5哈希码是否匹配, 不匹配需要删除本地的 pck 包 启动网络下载到本地 pck 资源, 写入到 user://xxx 最好和远程路径匹配方便映射 下载完成之后通过 ProjectSettings.

Godot 集成 Protobuf Godot 版本默认指 Godot C# 版本 目前的 Godot 默认版本的 GDScript 脚本第三方的 Protobuf 库水平高低不平, 并且本身 Godot ABI 维护变动之下很容易某些属性|特性|方法在更新之后出现异常 所以如果需要采用 Godot 做网络序列化传输, 建议采用 C# 版本而非官方默认版, 从而才能利用上 .net 相关周边的第三方组件优势. 以上文档都是采用 LTS 版本的 .net 库相关 默认构建之后的项目之下有 XXXX.csproj 的 C# 配置文件, 这里就是主要的 .net 相关项目配置: <!-- 请留意这里, 这里代表默认采用 Godot-NET 自定义绑定, 也就是其实内部并不是完全支持全部 net 相关 --> <!-- 所以有些打包命令可能无法唤起, 像是 Protobuf 可能在常规 C# 项目当中引入可能没办法触发 Protobuf-Tools 自动打包命令 --> <!-- 需要注意的是因为采用的是 Godot.Net 绑定, 所以这里面默认加载目录分隔符号是 '/' 而不用区分 '\\' 和 '/' --> <Project Sdk="Godot.

网络游戏的场景同步 回归到游戏本质就是对于游戏客户端角色的操控, 单机游戏客户端通过操作指令来操作让其位移; 如果架构在网络游戏该怎么规划? 怎么把这方面的指令操作移交到服务端执行? 对于网络游戏来说, 客户端传上来的有可能是伪造数据, 最常见开启 变速齿轮 让游戏环境速度加速的情况, 这时候客户端肆无忌惮手动数据封包推送大量数据打乱游戏内部所有平衡. 但还有种情况是不需要在服务端频繁维护玩家实体状态, 场景中位移频繁都要提交到服务端对于CPU消耗比较庞大, 而有的场景实际上不具有太大的意义. 最常见的某些场景约等于材料本( 游戏中负责材料产出的副本 ), 这种玩家支付体力实际上只需最后结算奖励发放, 所以没必要同步太多细节. 需要明确几种游戏环境情况, 根据这些游戏环境才需要判断是否是否需要同步客户端场景同步: 多人同步: 这种是最常见需要同步操作场景, 因为场景内状态并不是单个玩家拥有的, 需要实时推送给同场景的不同玩家客户端 对战同步: 双人对战竞技场这种也是比较广泛场景, 常见用于双方竞技排名的情况, 最后决出的就是竞技分数和输赢情况 大逃杀模式: 最近兴起的多玩家在大地图互相猎杀的游戏, 这里面设计区域分块设计和多玩家状态同步设计, 这种中小厂目前没有驾驭的能力 塔防游戏: 塔防需要有具体的出怪逻辑和建筑攻击不断算血, 所以需要定时模拟计算攻击范围和血量变动. 上面就是比较常见的情况, 其实能够看出具体大部分都是强交互的情况, 这些情况也十分消耗CPU资源; 因为本身作为单机调用 Update 的情况就十分频繁, 而现在需要上万同时在线请求来维持游戏运转, 可以想象你上万人同时在线游玩来执行服务器的 Update 的 CPU 消耗也是非常惊人的. 偏轻度弱交互的移动端游戏, 则尽可能避免这种频繁需要消耗服务端 CPU 情况, 所以对于明确平台是移动端大部分采用相对简单的状态同步方式而非频繁帧同步. 建议如果对游戏服务端没有概念的, 可以先学习 skynet 试着学习 agent 概念设计和实现; 其中最主要概念就是对于单人在场景和玩法之中其实在服务端看来就是对自己所在数据的 自娱自乐, 轻度弱交互其实就是游玩游戏策划提供的玩法并且写入到服务端数据库. 这里按照最常见游戏帧( 60帧=Update每1/60s执行,30帧=Update每1/30s执行 ), 这种情况下需要在服务端动态创建 Update 定时器来处理. 高频率定时器 1/60s=16.7ms, 所以需要构建出 16.

建筑系统构建 网络游戏当中比较常见建筑功能经过大量版本迭代, 移动端为了节约性能消耗从地图区块拖动放置演变到固定建筑解锁; 这里先从客户端说明怎么去设计两种系统, 基本上只需要掌握这两种方式就能应对: PixelBuild: 允许玩家拖动建筑在平面上建成单位, 只要在平面不冲突就允许灵活构建单位 UnlockBuild: 平面上已经预设好建筑单位, 只需要按照条件激活该建筑进行工作 两者首先是必须要生成平面, 这里采用 Godot 来编写样例( Unity|UE 实际上思路也差不多 ); 现在构建最简单的生成 矿场(Gold) 和 农场(Farm), 具体自定义策划作用: Gold: 建成矿场之后 每5s 会提取游戏的金币资源到个人资源 Farm: 建成农场之后 每5s 会提取游戏的体力资源到个人资源 注意: 初始的资源收获周期是允许策划自定义的, 这里可以先考虑写死做成初版. 首先是像素点构建出建筑, 具体最后完成结果类似如下( PixelBuild ): 之后第二种建筑解锁方式就类似如下, 直接满足条件解锁激活建筑即可( UnlockBuild ): 注意: 之后内容要求具有一定服务端设计经验才能理解, 主体还是做状态同步到服务器共享. 如果想要达到满足玩家自由交互性, 最好采用 像素构建 让玩家在指定区域内选择构建建筑; 而如果只是简单想做个建筑解锁出资源点让玩家定时上线 收菜 获取收益的话, 直接采用 解锁激活 来激活建筑. 解锁建筑 这种建筑解锁方式目前大部分另外简称为 家园系统, 主要就是提供给玩家升级解锁产出游戏资源来维持游戏内部的经济系统; 以比较知名的二次元品类 “明日方舟” 为例, 初版内部就是家园解锁建筑从而生产出游戏内部货币 “龙门币” 等, 这种简单家园系统不需要太多客户端逻辑, 可能只需要 玩家等级提升|游戏货币解锁|游戏任务解锁 然后服务端协议统治下就能处理. 这方式只需要服务端去自行检查是否满足条件通知客户端解锁即可, 客户端所需要做的就是接收到协议获取多少秒之后可以领取的道具就行了

游戏授权登录服务端 游戏登录授权最好和游戏端脱离开来, 有时候需要接入

网络游戏在线奖励设计 在线奖励是网络游戏比较常见的, 客户端表现常见: 客户端加载在线时长奖励表 确定目前最后一次领取完时间戳 确认最后领取时间与当前时间戳差距 显示差距时间秒数确定可以被领取 点击推送指定时间戳满足条件奖励id 服务端判断是否满足,满足更新玩家资源信息 这种设计最常见早期二次元游戏品类的体力槽设计, 相当于每分钟回复1点体力然后玩家依靠体力解锁游玩副本. 这里先以最基础的在线体力增值做样例, 配置数据库字段和业务Actor来设计对应功能. 首先必须要在玩家信息实体当中挂载对应的体力相关字段, 主要用于记录玩家体力值相关数据: /** * 玩家实体对象 * 异步保存数据到数据库之中, 同时挂载在进程内存中用于读写 */ @Entity @Table(name = "tbl_player_info") public class PlayerInfoModel { /** * 玩家第三方登录uid, 这里采用主键自递增记录 */ @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(nullable = false, columnDefinition = "BIGINT COMMENT '主键ID,同时也是标识玩家UID'") private Long uid; /// 以下体力值系统是必须的 ------------------------------------------------------ /** * 体力值 */ @Column(nullable = false, columnDefinition = "INT COMMENT '体力值'") private Integer health = 10; /** * 体力值最后更新时间 */ @Column(nullable = false, columnDefinition = "BIGINT COMMENT '体力值最后更新时间'") private Long healthUpdateTime = 0L; /// 其他略.

策划CSV转JSON共享 这里可以 参考样例 日常的游戏开发中, 策划编辑配置表一般都是通过 Excel 在 Windows 环境进行配置, 如果是传统的 APP 开发, 一般都是在 WEB 网页端进行配置（在生成 JSON 下载）, 所以对于 APP 开发和游戏开发这就存在里比较大的差异, 导致目前我们做很多游戏类应用玩法我们都是采用后者或者采用让产品去编辑 Json|XML 的方式, 更复杂的情况甚至去代码中编写配置表. 这里有 客户端代码库 做CSV据转JSON样例 具体表格格式如下: ##这是一个测试 ID 名字 描述 速度 int string string float 1 谢大脚 我是谢大脚 3.3 2 赵四 我不是找死 3.4 具体每一行数据的作用: 第一行: 策划的关注的表注视信息, 采用 ## 开头标识格式表( 实际上我感觉这行可有可无 ) 第二行: 需要表达的字段属性名, 可以是中文但最好是采用英语防止某些环境字符集导致的问题 第三行: 指定描述第二行对应属性的数据类型, 需要简单向策划或者产品做取值讲解让他们配置 实际上可以第一行就是字段中文含义, 第二行就是字段在代码的 key 取值, 注意策划也是必须要看懂的字段意义 优化之后我常规是这样处理: 标识 名字 描述 速度 key name desc speed int string string float 1 谢大脚 我是谢大脚 3.

场景过渡 最近在制作游戏过程之中碰到就是场景要过渡切换到另外另外场景, 在单机游戏和网络游戏当中场景切换应对方式感觉有所不同: 单机游戏: 常见开源项目场景切换都是直接无状态重载场景, 之后加载本地保存的数据 网络游戏: 所有场景优先加载到场景隐藏, 之后根据需要切换指定场景显示, 所有场景都不会释放而是采用隐藏处理. 在这种过程之中, 常常纠结于去怎么实现, 像 Godot 单机方面直接 SceneManagent 那样直接切换这种情况是不需要说明, 主要最近像开发 H5 品类的网络游戏, 一直在思考怎么做到状态维持的网络游戏转场切换. 读取场景是在当前场景还是之后场景? 场景黑屏切换过渡场景要求下个场景需要有相同的黑屏切换保持切换状态. 这里面的是需要保证场景A和场景B过渡场景都需要保持一致, 也就是场景A在黑屏读条准备加载场景B的过程之中, 这种情况要求所有被切换都要求先做好场景铺垫. 之后就是另外默认场景带有黑屏方式做转换: 这里把过渡放置在需要切换的场景, 默认 show 的时候自带黑屏读条等待初始化之后等待去展示. 这种切换方式其实更灵活点, 这样把切换加载读条逻辑转移到所在场景处理, 而且不会出现因为上个场景和当前场景冲突. 前置场景加载并非一无是处, 比如需要启动的时候动态加载所有资源的情况; 有的关卡需要常驻加载大场景的情况, 这时候就需要专门做过渡场景来处理. 在随机性大地图等动态地图情况就需要这样在切换成读条来动态构建地图, 这种构建过程的时间就需要动态创建场景之后附加到节点之后等待完成展示. 这里追加个 ColorRect 的颜色渐变样例: ''' 基于 ColorRect 颜色区块做的淡入淡出功能 ''' extends ColorRect class_name Fade ''' 默认初始化隐藏状态 ''' @export var is_hidden:bool = false ''' 淡入淡出的速度 ''' @export var speed:float = 1 ''' 是否还在执行切换 ''' var _running:bool = false ''' 确定是否淡入还是淡出 ''' var _use_fade_in:bool = false ''' 淡入事件信号 ''' signal fade_in_event ''' 淡出事件信号 ''' signal fade_out_event ''' 初始化 ''' func _ready(): if is_hidden: print_debug("hidden") hide() else: print_debug("display") show() set_process(false) '''' 调用淡入 ''' func fade_in(): color.

事件信号推送 无论什么游戏引擎都有类似的跨场景推送要求, 本质上就是不同节点的事件监听: Unity3D的A预制件如何通知B预制件? Godot的A场景对象如何通知到B场景? …… 这里说个最简单的场景应用: 玩家通过点击商人购物的场景, 需要同步更新玩家GUI的金额和背包内部物品信息, 内部蕴含的就是这种不同场景( 商品界面GUI|玩家界面GUI|背包界面GUI )的多处同步更新. 甚至大型游戏需要细致到点击之后同步不同节点播放多个复杂动画效果, 让游戏效果更加绚丽 这里制作个简单样例: Merchant 是商店购买界面 Status 是玩家信息状态界面 Player 是详细购买信息提示界面 可以看到以上都是分布三个节点, Merchant 具体负责触发购买事件, 之后需要让 Status 和 Player 获取到购买信息. 具体难点就是 Button 信号事件全在 Merchant 身上, 最简单就是 Shop 根节点挂载具体处理脚本, 之后把由他通知其他所有节点. 但是这种父节点通知下属节点方式是有很大问题的, 因为 Merchant 所有 Button 信号触发事件必须绑定到最上层的 Shop 父节点; 这种绑定锁死上下级关系导致节点千万不能随意变动, 因为按键信号绑定需要类型 ../../Shop.gd 反向绑定节点, 随意变动上下级关系会导致直接事件失效, 而且场景复用频繁也会因为这样没办法绑定指定触发事件. 观察者模式 这是常见的设计模式, 采用全局唯一管理器挂载在进程中等待订阅和推送: Subscrib: 订阅端, 初始化的时候绑定监听调用服务函数方法 Publish: 推送端, 运行时推送数据给订阅类对象 这里伪代码编写: # ============================================================= # 假设商人对象等待触发支付 # ============================================================= extends Node class_name Merchant # 初始化的时候商人需要订阅结算事件, 因为其无法获取是否能够完成支付 func _init(): PubSub.

字体集成 注意开发游戏拉取出来的字体默认采用本地PC|手机当中保存的地区字体合集, 如果有的地区没有默认集成该字体则会出现 ‘口口’ 这样占位字体, 所以如果要游戏支持全球通用则必须要在开发中先在项目集成构建自己的游戏字体. 注意: 字体是有版权问题, 不要等到最后接收到律师函要求大量赔偿的时候才留意到这个问题 目前支持中文的开源免费且可以商用字体有以下: 阿里巴巴普惠体, 支持178个语种, 支持不同地区语种广泛 思源字体, 该字体授权最宽松可以任意修改打包再传播, 托管在Github 查询字体版权可以通过 WhatFontIs 查询是否支持商业免费. 这里采用阿里惠普体导入游戏当中测试 Godot 构建默认字体 需要注意新版本 Godot 默认会默认切换本地字体字符集, 其他电脑不含相同字体会导致在另外电脑字体错误. 另外还需要注意 Godot3 和 Godot4 版本字体引入方式不一样, Godot3是采用 FontTheme 方式而 Godot4 则直接引入调用即可. 最容易看出效果就是利用 Web 导出模板启动样例, 利用 Web 启动的默认采用自定义的默认字符集, 也就是构建 H5 游戏.