这里是全站文章的归档入口，下面是按时间倒序排列的全部文章。若想按主题浏览，请从首页的专题分类进入。
游戏客户端本地资源加密：保护成本和加载性能的取舍
资源加密不是万能保护 游戏客户端资源迟早会到玩家设备上，完全防止提取并不现实。资源加密的目标应该明确：提高批量搬运成本，保护未公开内容，防止简单篡改，配合完整性校验发现异常。它不能替代服务端权威，也不能指望保护所有商业秘密。
posts
文章归档
PlumePHP 全站文章的归档入口，按时间倒序汇总各专题的技术文章，并提供按主题浏览的专题分类入口。
SaaS 早期定价：不要等产品完美后才收费
开场：不收费的反馈经常不真实 很多 SaaS 团队会说：“先免费给大家用，等产品成熟了再收费。”这听起来谨慎，其实很危险。免费用户当然会给反馈，但他们的反馈不一定代表购买行为。一个人可以免费试用十个工具，却只为其中一个掏钱。收费会让客户重新计算价值、预算、替代方案和内部流程，这些才是 SaaS 创业必须面对的问题。
Steam 游戏回放调试实战：2021 年 6 月个人项目如何记录输入、随机种子和关键状态
回放调试解决什么问题 玩家反馈低频 bug 时，文字和截图常常不够。比如“第三层某个房间闪避后穿墙”“打完精英怪奖励没出现”“机关偶尔卡住”。如果游戏有随机地图、物理、复杂输入或状态机，开发者很难凭描述复现。
权威随机抽取架构：宝箱、卡池和掉落为什么不能只靠客户端表现
背景：一个小功能背后往往有多条状态链 随机抽取是游戏里最容易产生争议的系统之一。玩家关心概率是否真实、保底是否生效、断线后结果是否丢失；研发关心抽取是否幂等、概率配置是否正确、审计是否能复盘。客户端可以播放动画，但抽取事实必须由服务端权威生成。
游戏客户端推送跳转：从通知栏到正确页面的状态恢复
推送点击不是简单打开游戏 运营推送常见文案是“奖励待领取”“好友邀请你组队”“世界 Boss 开启”。玩家点通知后，期待直接到对应页面。如果客户端只是启动游戏停在主界面，推送价值会大幅下降；如果盲目跳页面，又会遇到未登录、资源未下载、活动过期、角色不满足条件、路由参数被伪造等问题。
SaaS 行业观察：基于使用量的定价模式探索
开场：一个客户的抱怨 一家做数据分析 SaaS 的公司收到了一个中型客户的反馈：「我们的团队只有 10 个人，但每个月处理的查询量差异很大。淡季可能只有几千次查询，旺季会达到几十万次。你们的订阅制定价让我们淡季付太多，旺季又担心超出限额。能不能按实际使用量收费？「 这个反馈不是个例。
投降投票状态机架构：竞技对局里的少数服从多数并不简单
背景：一个小功能背后往往有多条状态链 投降投票看起来只是发起、投票、通过或失败，但在实时竞技里边界很多：开局多久才能发起，几分钟内能发起几次，掉线玩家算不算弃权，四人队和五人队阈值是否相同，投票通过后如何进入结算。规则不清楚会直接引发公平争议。
Steam 平台抽象层实战：2021 年 6 月个人游戏如何封装成就、云存档、覆盖层和离线模式
为什么需要平台抽象层 个人游戏接 Steamworks 时，常见做法是在需要成就的地方直接调用 Steam API，在存档处直接判断 Steam Cloud，在 UI 里直接打开覆盖层。短期很快，长期会让代码和平台强绑定。
游戏客户端动态 UI 皮肤：节日换肤不能改坏基础界面
UI 换肤最怕把按钮变得看不清 节日版本、联动活动、赛季主题都会要求 UI 换肤：主界面按钮换边框，活动入口换背景，弹窗标题换材质，货币栏加装饰。换肤能增强氛围，但如果没有边界，很容易把基础界面改坏：文字对比度不足、按钮尺寸变化、资源缺失、旧主题残留、低端机加载变慢。
道具绑定规则架构：可交易、账号绑定和临时绑定不能靠硬编码
背景：一个小功能背后往往有多条状态链 同一个道具可能因为来源不同拥有不同规则：商城购买可交易，活动赠送账号绑定，副本掉落限时可交易，任务奖励角色绑定。玩家合成、邮寄、上架拍卖、跨服转移时，都需要判断这件道具能不能流转。绑定规则如果写死在各处，交易系统会越来越难维护。
Steam 游戏 NPC 日程与世界状态实战：2021 年 6 月个人项目如何做时间、位置和事件
NPC 日程的价值和风险 生活模拟、叙事冒险、经营和 RPG 常需要 NPC 日程：早上在店里，晚上回家，任务后换位置，节日时出现特殊对话。日程能提升世界感，但也会带来大量问题：玩家找不到 NPC，任务提交点消失，读档后 NPC 位置错误，时间跳转漏触发事件。
游戏客户端任务对话分支：选择、条件和回滚都要可追踪
对话分支不只是几行文本 任务对话经常会出现选择：接受或拒绝、询问不同情报、选择奖励、决定剧情走向。客户端如果只把它当成文本和按钮，会在条件、回滚、弱网、本地化和剧情状态上出问题。玩家点了一个选项后，NPC 表情、任务状态、奖励和后续对白都可能变化。
2015年游戏创业失败复盘五：失败之后，我真正学到的十件事
系列说明 这是 2015 年游戏创业失败复盘的第五篇，也是最后一篇。前四篇分别写了出发时的错觉、第一款产品的失控、团队与现金流的撕裂，以及发行和市场的打击。本文不再按时间线写，而是总结失败之后真正留下的十件事。
2015年游戏创业失败复盘四：不会发行的游戏，根本没有被看见的机会
系列说明 这是 2015 年游戏创业失败复盘的第四篇。前面三篇分别写了出发时的错觉、第一款产品的失控，以及团队和现金流压力。本文写发行和市场。对技术出身的游戏创业者来说，发行经常被低估。我们会把大量精力放在玩法、客户端、服务端、资源、后台、数据和稳定性上，认为只要游戏做得足够好，后面的事情自然会发生。
游戏客户端活动小游戏容器：临时玩法也要有边界
临时小游戏最容易变成长期债务 节日活动里经常会加小游戏：翻牌、打地鼠、接金币、拼图、答题、节奏点击。需求看起来短平快，代码也容易写成一个独立页面。问题是临时玩法越来越多后，资源加载、输入接管、奖励发放、关闭恢复、埋点和适配都重复造轮子，最后每个小游戏都有一套 bug。
玩法日历编排架构：限时玩法、重置和跨时区活动如何统一管理
背景：一个小功能背后往往有多条状态链 长线游戏里每天、每周、每赛季都有大量时间规则：世界 Boss 周三开放，竞技场每天结算，限时副本按区服时区开启，节日活动跨自然日，维护又可能临时打断。玩法日历编排架构的目标，是让这些时间规则有统一事实来源，而不是每个系统自己写定时器。
Steam 游戏程序生成实战：2021 年 6 月个人项目如何设计种子、规则、回放和坏图兜底
程序生成的核心是可控随机 程序生成很适合个人游戏：少量手工内容可以组合出更多变化，Roguelite、探索、解谜、战斗房间都能受益。但程序生成也很容易制造坏体验：出口不可达，关键道具不生成，敌人刷在墙里，奖励过于极端，玩家反馈某张图有 bug 时开发者无法复现。
2015年游戏创业失败复盘三：团队、外包、现金流和自研之间的撕裂
系列说明 这是 2015 年游戏创业失败复盘的第三篇。第一篇写出发时的错觉，第二篇写第一款产品如何从热血变成失控。本文写更现实、更不浪漫的一部分：团队、外包、现金流和自研理想之间的撕裂。很多创业复盘喜欢谈战略、产品、商业模式，但真正压垮小团队的，往往是每天都在发生的小消耗。
游戏有状态服务发布架构设计
无状态后台可以滚动重启，有状态游戏服务不能这么粗暴。房间服里有战斗，场景服里有玩家位置，网关上挂着长连接。一次普通版本发布，如果没有架构支持，就会变成“凌晨发版仍然踢掉一批玩家”。2021 年很多团队开始把发布从运维动作前移到服务设计里，因为有状态服务能不能发布，取决于它平时是否允许状态被关闭、转移和恢复。
2015年游戏创业失败复盘二：第一款产品如何从热血变成失控
系列说明 这是我复盘 2015 年开始游戏创业失败过程的第二篇。第一篇写的是出发时的错觉：我把在腾讯、搜狐畅游做游戏和游戏社区的工程经验，误认为足以支撑自己从零做一家公司。本文更具体，写第一款产品是怎样从热血、兴奋、快速推进，慢慢变成失控、犹豫和消耗的。