2024 年准备系统复盘一下我在 Cash Club 这条产品线里的开发工作。
这不是一篇产品介绍，也不是把所有模块列一遍的流水账，而是给后面几个月的文章先打一个地基：这个项目为什么会采用 Unity + xLua-framework + Lua 的组合，客户端和 Python 后端分别承担什么职责，多主题老虎机和周边系统又是怎么被组织起来的。
我在这个项目里前后做过登录、大厅、商店、任务、大师任务、活动框架、礼物系统、好友系统、部分小游戏接入，以及一系列性能优化和 SDK 集成工作。回头看，真正值得总结的不是某个单点功能，而是这类强运营 Slot 项目为什么必须把“通用层”和“主题层”拆开。
一、为什么 Cash Club 这类项目不适合只靠纯 Unity 场景思维来做
很多刚接触 Slot 项目的人，容易把它理解成“很多机台 + 很多 UI + 一些数值玩法”。
这个理解不算错，但如果只按 Unity 常规页面开发的思路推进，很快就会遇到两个问题：
- 新主题上线频率高，机台之间既有共性又有差异。
- 活动、任务、支付、推送、通知这些外围系统和核心玩法耦合得很深。
也就是说，这类项目不是做完一个玩法就结束，而是长期运营、持续迭代、频繁换皮、不断加活动。
如果一开始没有把客户端技术栈拆层，后面最常见的问题就是：
- 新机台接入越来越慢
- 活动代码散在各个页面里
- 同一套领奖、倒计时、状态同步逻辑重复出现
- 某个主题改 UI 时把通用逻辑一起改坏
Cash Club 能长期稳定迭代，一个很重要的前提就是把“会反复复用的部分”和“主题差异化的部分”尽量隔开。
二、项目里的技术栈分层
当时项目的主要技术栈可以粗分成四层。
1. Unity + C#：运行时壳子和基础能力层
Unity 这一层主要负责：
- 资源加载与 AssetBundle 管理
- UI 基础框架
- 动画、粒子、音效、场景切换
- 原生 SDK 对接
- 网络封装、平台差异处理
- 编辑器工具和部分自动化流程
这层更像地基。它不直接承载大量高频变化的玩法逻辑，但负责把运行时环境和工程能力兜住。
我自己在这个阶段做得最多的是通用系统框架、商店框架、部分大厅能力，以及后续大量围绕包体、内存和 UI 性能的优化工作。
2. xLua-framework：C# 和 Lua 之间的桥
xLua-framework 在这个项目里的价值，不只是“支持 Lua 热更新”这么简单。
它更重要的作用是把客户端业务逻辑从 Unity 运行时里抽出来，让页面状态、流程控制、数据驱动逻辑可以在更轻量的脚本层迭代。
对这种强运营项目来说，这个抽象非常关键，因为：
- 新活动和新机台的业务逻辑更新频繁
- 很多页面流程本质上是状态机和配置驱动
- 脚本层更适合快速试错和持续维护
后面我会单独写一篇，专门拆 xLua-framework 在业务项目里到底怎么分模块、怎么管生命周期、怎么处理 C# 和 Lua 的边界。
3. Lua：大部分业务逻辑和主题玩法层
项目里大量基础业务逻辑最终落在 Lua 层，包括：
- 大厅和机台入口流程
- 任务、活动、领奖等状态控制
- 主题玩法的流程编排
- 部分小游戏规则层实现
- 配置驱动的页面展示逻辑
把这些逻辑放在 Lua，不是为了追求“全脚本化”，而是因为这类内容变化快、复用多、容易被活动系统反复调用。
如果全部放到 C# MonoBehaviour 里，后面维护成本会迅速上升。
4. Python 后端：主题玩法结果和服务端业务能力
服务端不是只负责发一个 spin 结果回来这么简单。
在实际项目里，后端往往要承担：
- 主题玩法结果生成
- 奖励发放和状态校验
- 活动进度累计
- 支付相关状态同步
- 用户资产、安全和日志链路
前端负责表现、流程和交互，后端负责结果、规则和可信状态，这样分工才能让项目既能高频运营，又不至于把关键逻辑压在客户端本地。
三、这类 Slot 项目为什么一定要拆“核心玩法层”和“周边系统层”
从用户角度看，大家玩的当然是机台。
但从研发角度看，真正支撑留存和付费的并不只是机台本身，而是机台外那一整圈系统：
- 商店和支付系统
- 任务和大师任务
- 成就和阶段目标
- 每日、每周、每月活动
- 礼物、好友、社交反馈
- 岛屿挑战、宠物系统、Bingo 等扩展玩法
如果把这些东西都写进某个主题机台自己的代码里，代码会很快失控。
更合理的做法是拆成两块：
核心玩法层
关注每个机台真正不同的部分：
- reel 布局
- symbol 规则
- bonus 触发流程
- 免费局、乘数、特殊演出
- 主题专属小游戏
周边系统层
关注所有机台共享、并会被频繁复用的部分：
- 商品售卖和支付
- 任务统计
- 活动入口和倒计时
- 通用领奖流程
- 通知、推送、分享、评分等外部能力
这个边界划清楚以后，团队协作效率会高很多。
策划加活动时，不需要总去碰核心机台代码。
客户端接新主题时，也不需要每次都重新发明一套领奖、引导、入口管理和数据刷新逻辑。
四、我在项目里体感最深的，其实不是“做功能”，而是“做框架化”
回头看 Cash Club 这类项目，最有价值的工作往往不是把某个页面堆出来，而是把重复问题变成框架能力。
比如这些事情，一旦做成通用能力，后面收益会持续放大：
- 页面模板和主题模板
- UI 找控件与自动生成代码工具
- 配置表导出和校验流程
- 活动基类和活动入口管理
- 资源依赖分析和包体控制
- 场景流式加载和低端机降级策略
这些工作单独看都不算“显眼功能”，但它们会直接决定项目的迭代速度和线上稳定性。
也是因为这一点，我后来越来越倾向于把技术复盘写成系列文章，而不是只记录某个功能点的实现细节。
五、这个系列后面准备怎么写
后面这组文章，我准备按下面的顺序展开：
- 先讲客户端业务框架和 Lua 分层。
- 再讲 Slot 核心玩法、多主题机台和前后端协作边界。
- 然后拆商店、支付、任务、成就、活动这些周边系统。
- 最后再回到 Bingo、Coin Master 风格小游戏，以及整个阶段的研发复盘。
这样写的好处是，每篇文章都聚焦一个问题，但又不会脱离真实项目上下文。
六、总结
如果只从表面看，Cash Club 像是一个“主题很多、活动很多”的社交博彩项目。
但从研发角度看，它更像一个长期运营的平台型产品：
- Unity 和 C# 负责底层运行时与工程能力
- xLua-framework 负责搭起业务脚本层
- Lua 承担高频变化的客户端逻辑
- Python 后端负责可信结果和服务端状态
而真正让这个项目能持续跑下去的，不是单个机台做得多炫，而是有没有把通用系统、主题差异和运营活动三者的边界拆清楚。
这也是我准备把这一段开发经历完整写下来的原因。
后面几篇文章，就从客户端业务框架开始拆。