摘要:
我们做了一版"对局时长反作弊":客户端只负责老实记录,判定权全部交给服务端。这篇不讲代码有多难,讲一个人人都能听懂的核心问题——两个时钟口径不一样,怎么比? 先说结论:问题的本质是"没人能证明你玩了多久" Roguelike 手游里,单局时长(GameRecord.Duration)是个很忙的数字: 阅读全文
我们做了一版"对局时长反作弊":客户端只负责老实记录,判定权全部交给服务端。这篇不讲代码有多难,讲一个人人都能听懂的核心问题——两个时钟口径不一样,怎么比? 先说结论:问题的本质是"没人能证明你玩了多久" Roguelike 手游里,单局时长(GameRecord.Duration)是个很忙的数字: 阅读全文
posted @ 2026-10-11 16:47
鑫鑫哥Adam
阅读(19)
评论(0)
推荐(0)

先说人话:我们遇到了什么鬼 事情是这样的。我们游戏用的是 Unity + Addressables,热更就是往 CDN 上丢新的 bundle 文件,玩家打开游戏时比对一下,只下载变了的那些。 按理说,你这次更新就改了一张图,那玩家应该只多下那一个 bundle 才对。结果我们打出来的热更包里,躺着
深度解析一次 Unity Addressables 热更事故的调查全过程。 起因:392 个 bundle 进了 patch,但只有 94 个真的变了 事情要从一份调查文档说起。 我们 iOS 的某次热更(内部编号 #195),patch 里居然有 392 个 bundle,加起来 465 MB。这
一个从零到落地的真机 UI 冒烟测试工作流:录制 → 编排 → 执行 → 报告。全文都是实测数据,包含它什么时候会脆——这部分比成功经验更值钱。 一、起因:冒烟测试为什么让人烦 手游每次出包都要过一遍手工冒烟:进游戏 → 到大厅 → 进要塞 → 开商店 → 关商店 → 回大厅…… 单次 2~3 分钟
一次由 TheApp.Instance.GetSystem<T>() 引发的架构思考。 一、缘起:一行让我"不舒服"的代码 这事儿的起因特别简单,就是项目里有这么一段实现: public StaffHireState GetHireState(StaffItem item) { int level
项目背景:Unity 2022.3.62f2 手机 Roguelike。 代码热更走 HybridCLR(Assembly-CSharp.dll 作为热更 DLL 下发),资源热更走 Addressables。 启动器 Launcher 位于 AOT 程序集(Launcher.asmdef),在热更
写业务代码的时候,很少有人会主动去想 int 的边界。直到某天金币显示成 -2147483648,或者伤害算出个巨大的负数,你才意识到——这个数不知道什么时候转了一圈。 这篇文章不用你背补码公式,我们从"里程表"开始,一步步把这件事说清楚。 一句话本质 int 只有 32 个二进制位,能表示的范围是
读这篇能拿到什么 读完这篇你会拿到三样东西。一是一套“轻量运行时数值保护”的完整实现思路:怎么用一个 struct 就让内存里的生命、金币、伤害不再以明文躺着,怎么让“改一个内存地址”这种最常见的作弊手段在下次读取时自己暴露。二是一条从“客户端探测”到“服务器判定”的证据链设计:探测到异常不崩溃、不
项目:Unity 2022.3 模拟经营游戏 环境:macOS / Unity 2022.3.51f1c1 / Unity Pipeline(com.unity.pipeline 兼容分支) 一、背景:为什么需要这套工具链 在做 ChaRestaurant 这个 Unity 2D 模拟经营游戏时,我
浙公网安备 33010602011771号