简介这是一套基于Unity引擎开发的3D麻将棋牌游戏完整项目参考腾讯欢乐麻将手游制作适合计算机相关专业学生、教师及企业开发者学习进阶也可作为毕设、课程设计或项目立项演示的参考方案。资源包共约2000个文件压缩后64.94MB包含113个C#脚本、25个Shader、8个材质、3个Unity场景文件及多个AssetBundle资源包另有大量meta、png贴图与xml配置覆盖游戏逻辑、渲染效果与资源管理各环节。项目源码均经本地编译验证可运行评审分达95分以上难度适中。内容涵盖完整的麻将玩法实现、3D牌桌场景搭建与资源打包流程目录结构清晰便于按模块检索学习。目前已有470人学习下载适合希望在Unity 3D棋牌游戏方向积累实战经验的开发者参考借鉴。1. 从零拆解一个 3D 麻将棋牌项目为什么它值得你花两周啃下来很多人第一次听到「基于 Unity 开发的 3D 麻将棋牌游戏」脑子里冒出来的画面是那种街边小游戏——几张牌贴图、点一下出牌、胡了弹个框。但真正参考欢乐麻将这类成熟手游做一遍你会发现它压根不是「贴图 按钮」的活。它同时压着四套系统3D 牌桌与摄像机调度、麻将核心规则引擎胡牌判定、番型计算、听牌提示、四人实时同步的状态机、以及一套能撑住长线运营的 UI 与资源框架。任何一环塌了玩家立刻能感觉到「这游戏不对劲」。这个方向适合两类人一类是想拿一个完整度高、能写进简历或毕设的 Unity 项目练手的同学另一类是已经会写 C# 但没做过「规则复杂 联网状态同步」这类业务的开发者。它最大的价值不在画面而在于你会被迫把「数据驱动的规则引擎」和「表现层」彻底分开——这个习惯一旦养成后面做任何棋牌、卡牌、回合制都能直接复用。下面我按实际落地顺序把选型、规则引擎、3D 表现、同步和优化一层层拆开讲。2. 先定架构再动手Unity 做麻将棋牌的模块划分与选型理由2.1 为什么必须把规则引擎和 MonoBehaviour 解耦新手最容易翻车的地方就是把胡牌判定直接写进PlayerController或者某个GameManager里用一堆if判断手牌。这样写前两天很爽第三天加「七对」「十三幺」「杠上开花」的时候你会发现自己在一坨面条代码里找不着北。麻将规则的本质是纯数据运算给定 14 张牌或 13 张 摸牌判断能不能胡、胡多少番、听哪些牌。它跟 Unity 的渲染、输入、网络一点关系都没有。所以我的做法是规则引擎写成一个纯 C# 类库不继承 MonoBehaviour不引用 UnityEngine输入是手牌数组和操作历史输出是判定结果。这样它既能跑在 Unity 里也能单独写单元测试甚至能拿到服务端复用。表现层只负责「把引擎算出来的结果演出来」。这条边界一旦划清后面所有复杂度都有了落脚点。2.2 目录结构与核心模块清单一个能撑住迭代的工程目录大致这么分。注意这不是让你照抄而是让你理解「为什么这么分」——每个目录对应一个职责边界。目录职责是否依赖 UnityEngineAssets/Scripts/Core麻将规则引擎、牌型判定、番型计算否Assets/Scripts/GameFlow回合状态机、发牌/摸牌/出牌流程是Assets/Scripts/Net房间同步、消息协议、断线重连是Assets/Scripts/View3D 牌桌、手牌排列、动画、特效是Assets/Scripts/UI大厅、结算、设置面板是Assets/Data牌型配置、番型表ScriptableObject / JSON是Core目录是整个项目的命根子它必须能脱离 Unity 编译。我一般会在解决方案里单独建一个.csproj把它编成 DLLUnity 侧只引用。这样做的直接好处是规则改动可以先用 NUnit 跑几百个用例验证再进引擎看表现排查问题时能立刻判断「是规则错了还是表现错了」。2.3 牌的数据表示为什么用 int 而不是 enum 或字符串牌怎么表示直接决定规则引擎写起来顺不顺。常见三种做法字符串1W 9T、枚举TileType.Wan1、整数编码。我强烈建议用整数编码理由很实在——麻将判定里大量涉及「排序」「找顺子」「数同花色张数」整数做这些运算最自然还能直接当下标用数组做计数。// 牌编码花色 * 10 点数方便按花色分组和排序 // 万0, 条1, 筒2, 字牌3 // 例如 1万1, 9万9, 1条11, 9条19, 1筒21, 东31, 中37 public static class TileCode { public const int WanBase 0; public const int TiaoBase 10; public const int TongBase 20; public const int ZiBase 30; public static int Suit(int tile) tile / 10; // 花色 public static int Rank(int tile) tile % 10; // 点数 // 判断是否字牌东南西北中发白 public static bool IsHonor(int tile) tile ZiBase; }这段编码的关键在于「花色 * 10 点数」这个设计。取花色用整除 10取点数用取模 10两个操作都是常数时间。字牌从 31 开始和序数牌天然隔开判断是否字牌只需一次比较。参数上唯一要注意的是点数范围必须控制在 1~9字牌 1~7别越界否则取模会串味。如果你后面要加花牌春夏秋冬建议单独开一段编码区间别混进现有体系。3. 麻将核心规则引擎胡牌判定、听牌计算与番型配置怎么落地3.1 胡牌判定的递归拆解思路胡牌判定的经典做法是「先抽将牌再拆刻子和顺子」。14 张牌里必然有一对将特殊牌型除外把每种可能的将牌抽出来试一次剩下的 12 张如果能全部拆成「刻子三张相同或顺子同花色连续三张」就胡了。这个拆解用递归写最清晰。// 判断剩余牌能否全部拆成刻子或顺子 // counts: 长度 40 的计数数组counts[tile] 表示该牌张数 private static bool CanFormMelds(int[] counts) { // 找到第一张还有剩余的牌 int first -1; for (int i 0; i counts.Length; i) { if (counts[i] 0) { first i; break; } } if (first -1) return true; // 全部拆完成功 // 尝试拆刻子 if (counts[first] 3) { counts[first] - 3; if (CanFormMelds(counts)) { counts[first] 3; return true; } counts[first] 3; // 回溯 } // 尝试拆顺子仅序数牌且点数 7 if (!TileCode.IsHonor(first) TileCode.Rank(first) 7 counts[first 1] 0 counts[first 2] 0) { counts[first]--; counts[first 1]--; counts[first 2]--; if (CanFormMelds(counts)) { counts[first]; counts[first 1]; counts[first 2]; return true; } counts[first]; counts[first 1]; counts[first 2]; // 回溯 } return false; }逻辑说明每次递归都锁定「当前最小的还有剩余的牌」因为拆解顺序不影响最终能否拆完锁定最小值能避免重复搜索。拆完刻子或顺子后递归失败就回溯。参数上counts数组长度取 40 是为了覆盖到 37中留点余量。这里有个性能细节递归本身有重复子问题实战中我会加一个Dictionary做记忆化或者干脆用「预生成所有胡牌模板」的查表法后者在移动端更稳。3.2 听牌计算把「差一张能胡」枚举出来听牌计算就是对当前 13 张手牌枚举所有可能的 34 种牌逐一加进去看能不能胡。能胡的那张就是听的牌。听起来暴力但 34 次判定对现代设备毫无压力完全不用优化。// 返回当前手牌所有能胡的牌听牌列表 public static Listint GetTingTiles(int[] handCounts) { var result new Listint(); var allTiles new Listint(); // 收集所有合法牌编码 for (int s 0; s 3; s) for (int r 1; r 9; r) allTiles.Add(s * 10 r); for (int r 1; r 7; r) allTiles.Add(30 r); foreach (int tile in allTiles) { if (handCounts[tile] 4) continue; // 该牌已用完不可能再摸到 handCounts[tile]; if (IsHu(handCounts)) result.Add(tile); handCounts[tile]--; // 还原 } return result; }这里IsHu就是「抽将 CanFormMelds」的组合。参数上注意handCounts[tile] 4这个剪枝——一副牌每种最多 4 张已经 4 张就不可能再摸到跳过能省一点算力。听牌列表算出来后UI 上给玩家做「听牌提示」就是直接读这个列表规则和表现又一次干净分离。3.3 番型配置用数据表而不是硬编码番型胡牌牌型的得分规则是麻将里最容易膨胀的部分。欢乐麻将那种量级番型几十种如果全用if-else写死维护成本爆炸。我的做法是把番型定义成数据表用 ScriptableObject 或 JSON 存引擎只负责「匹配条件 累加番数」。字段含义示例id番型唯一标识qingyisename显示名清一色fan番数24condition匹配条件标识AllSameSuitexclusive是否与其他番型互斥false引擎里维护一个「条件判定器」字典condition字符串映射到具体判定函数。加新番型时只改数据表 加一个判定函数不动主流程。这套设计的好处是策划能自己配表程序只保证判定器正确。注意exclusive字段要处理好——有些番型互斥比如「清一色」和「混一色」不会同时成立配错了会导致番数虚高这是结算对账时最常见的坑。4. 3D 牌桌与表现层摄像机、手牌排列和粒子特效的实战参数4.1 摄像机调度固定视角 局部特写3D 麻将的摄像机不是随便摆的。玩家视角要能同时看清自己的手牌、桌面打出的牌、以及对手的状态。常见做法是主摄像机固定一个俯视斜角胡牌或杠牌时切到特写机位做动画。主摄像机我一般用透视投影FOV 控制在 40~50 之间太高会有明显畸变太低牌桌显得扁平。// 主摄像机跟随配置固定角度只做轻微呼吸感 public class CameraRig : MonoBehaviour { public Transform target; // 牌桌中心 public Vector3 offset new Vector3(0, 8.5f, -6f); public float smooth 6f; // 跟随平滑系数 void LateUpdate() { // 目标位置 牌桌中心 固定偏移 Vector3 desired target.position offset; transform.position Vector3.Lerp( transform.position, desired, Time.deltaTime * smooth); // 始终看向牌桌中心 transform.LookAt(target.position Vector3.up * 0.5f); } }参数说明offset的 Y 值决定俯视高度8.5 左右能兼顾手牌和桌面Z 值决定前后距离太近手牌会出画。smooth用 6 比较跟手又不抖。LateUpdate里做跟随是为了避免和手牌动画抢更新顺序。这里有个血泪经验别在Update里直接LookAt加位移容易和动画系统打架导致镜头轻微抖动玩家会觉得「晕」。4.2 手牌排列弧形布局与自适应间距手牌不能排成一条直线那样既不好看也不符合真实麻将的手感。常见做法是排成一段圆弧中间的牌略高、两端的牌略低并带一点旋转。牌数变化时摸牌、出牌间距要自适应。// 手牌弧形排列根据牌数动态计算每张牌的位置和旋转 public void LayoutHand(ListTransform tiles) { int n tiles.Count; float totalAngle Mathf.Min(30f, n * 2.5f); // 总弧度封顶 30 度 float step n 1 ? totalAngle / (n - 1) : 0f; float startAngle -totalAngle * 0.5f; float radius 6f; // 弧半径 for (int i 0; i n; i) { float angle startAngle step * i; float rad angle * Mathf.Deg2Rad; // 沿弧线计算位置 Vector3 pos new Vector3( Mathf.Sin(rad) * radius, Mathf.Cos(rad) * radius - radius, // 中间高两端低 0); tiles[i].localPosition pos; tiles[i].localRotation Quaternion.Euler(0, 0, -angle); } }逻辑说明totalAngle控制整段弧的张开程度牌多时封顶 30 度避免两端牌转得太夸张。radius越大弧越平6 左右手感比较自然。位置计算里Cos(rad) * radius - radius这一项让中间的牌 Y 值最高、两端最低形成自然的扇形。参数上要注意牌数超过 14 张比如杠牌后时间距会变挤实战中我会把radius随牌数略微调大或者允许手牌分两行。4.3 粒子特效与内存别让胡牌特效拖垮帧率胡牌、杠牌、自摸这些时刻要有效果但粒子特效是 Unity 里最容易内存泄漏的地方之一。常见翻车场景是每次胡牌Instantiate一个特效预制体播完忘了Destroy打十几局内存就上去了。正确做法是用对象池特效播完回收而不是销毁。// 简易特效对象池避免频繁 Instantiate/Destroy public class EffectPool : MonoBehaviour { public GameObject prefab; private QueueGameObject pool new QueueGameObject(); public GameObject Get(Vector3 pos) { GameObject go pool.Count 0 ? pool.Dequeue() : Instantiate(prefab); go.transform.position pos; go.SetActive(true); return go; } public void Return(GameObject go) { go.SetActive(false); pool.Enqueue(go); // 回收而非销毁 } }参数说明池的初始容量按「同屏最大特效数」估一般 5~8 个够用。特效播放完通过ParticleSystem.main.stopAction或协程回调Return。注意SetActive(false)不会停止粒子模拟回收前要手动Clear()否则下次取出时会看到残留粒子。这个坑我在项目里踩过表现是「特效第二次播放时闪一下旧粒子」排查了半天。5. 四人同步与状态机回合流转、断线重连的避坑清单5.1 回合状态机把「谁该出牌」管清楚麻将的回合流转看着简单实则状态很多发牌、摸牌、出牌、等待其他玩家、碰杠胡的抢牌窗口、结算。用状态机管是最稳的。我一般定义一个枚举状态 一个GameStateMachine类每个状态有进入、更新、退出三个钩子。public enum GameState { Dealing, // 发牌 WaitingDraw, // 等待摸牌 WaitingPlay, // 等待出牌 ClaimWindow, // 碰杠胡抢牌窗口 Settle // 结算 } public class GameStateMachine { public GameState Current { get; private set; } private float stateTimer; public void Change(GameState next) { OnExit(Current); Current next; stateTimer 0f; OnEnter(next); } public void Tick(float dt) { stateTimer dt; // 抢牌窗口超时自动关闭防止卡死 if (Current GameState.ClaimWindow stateTimer 5f) Change(GameState.WaitingDraw); } }逻辑说明ClaimWindow是别人打牌后、其他人可以碰杠胡的时间窗口必须有超时兜底否则某个玩家掉线会导致整局卡死。参数上 5 秒是常见值太长拖节奏太短玩家来不及反应。stateTimer在每个状态进入时清零方便做各种超时判定。5.2 断线重连状态快照比补发消息更可靠断线重连是棋牌游戏的刚需。常见两种做法一是补发断线期间的所有消息二是直接下发一份完整状态快照。我强烈推荐快照——补发消息在消息量大、顺序敏感时极易出错而快照是「当前真相」重连后直接覆盖本地状态即可。快照要包含当前手牌、桌面已打出的牌、各家副露碰杠、当前轮到谁、剩余牌墙数量、当前状态机状态。服务端序列化后下发客户端反序列化重建。注意快照里的「剩余牌墙」不能下发具体牌序否则等于作弊只下发数量即可摸牌时再单独请求。5.3 同步避坑清单现象玩家出牌后别人看到的牌和出牌者不一致。原因出牌消息只发了牌编码没带「谁出的、第几张」客户端各自推断导致错位。解决出牌消息必须带玩家 ID 牌编码 序号客户端严格按消息渲染。现象碰牌时两个人同时点结果都碰了。原因抢牌窗口没有服务端仲裁客户端各自判定。解决所有碰杠胡的最终裁决必须在服务端客户端只发「请求」收到「确认」才执行。现象重连后手牌顺序乱了。原因快照没保存手牌顺序客户端按编码排序重建。解决快照里手牌按原始顺序存数组别排序。现象结算番数和玩家自己算的对不上。原因客户端和服务端各跑一套番型判定逻辑有偏差。解决结算以服务端为准客户端只做展示或者两端共用同一份规则引擎代码。6. 性能优化与打包让 3D 麻将在中低端机上稳 60 帧6.1 包体与 Draw Call合批和纹理图集3D 麻将的模型面数不高真正的瓶颈在 Draw Call。牌面、桌面、UI 如果各用各的材质Draw Call 轻松上百。优化手段牌面用一张图集Atlas所有牌共用材质靠 UV 偏移区分静态的桌面、椅子用 Static BatchingUI 用 Sprite Atlas。做完这些Draw Call 能压到 30 以内。// 运行时给牌面设置图集 UV 偏移示意 // 假设图集 10 列每张牌占 1/10 宽 public void SetTileUV(Renderer rend, int tileIndex) { var mat rend.material; float col tileIndex % 10; float row tileIndex / 10; mat.mainTextureScale new Vector2(0.1f, 0.1f); mat.mainTextureOffset new Vector2(col * 0.1f, row * 0.1f); }参数说明mainTextureScale是每张牌在图集里占的比例10 列就是 0.1。mainTextureOffset是偏移。注意每个牌实例要material而不是sharedMaterial否则会互相覆盖 UV——但这样又会产生材质实例破坏合批。正确做法是用MaterialPropertyBlock既能改 UV 又不破坏合批这是关键细节。6.2 移动端打包注意项打包到手机时几个必查项纹理压缩格式Android 用 ASTCiOS 用 ASTC 或 PVRTC、Shader 变体数量用 Shader Variant Collection 剔除没用的、IL2CPP 编译比 Mono 快但包体大棋牌类建议开。分辨率设置上别锁死 1080p用Screen.SetResolution按设备自适应中低端机降到 720p 能明显提帧。6.3 一个我常用的验证习惯每次改完规则引擎或同步逻辑我会先跑一遍「单机四人 AI 对战」——四个 AI 互相打跑几百局看有没有卡死、番数异常、状态机死循环。这个自动化测试比手动点牌高效得多很多边界 bug比如「最后一张牌被碰后牌墙空了」都是这么跑出来的。规则引擎因为不依赖 Unity可以直接在 NUnit 里跑几分钟出结果。最后说个我自己的教训这个项目最容易让人上头的是画面最容易埋雷的是规则和同步。我早期花了两周调摄像机手感和粒子特效结果联调时发现胡牌判定漏了「抢杠胡」返工重写引擎。后来我养成习惯——先把Core目录的规则用例写满再动表现层。规则稳了画面怎么改都不慌。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/7 10:33:06 · 阅读 1.2k Unity 3D麻将棋牌开发实战：规则引擎与状态同步
简介这是一套基于Unity引擎开发的3D麻将棋牌游戏完整项目参考腾讯欢乐麻将手游制作适合计算机相关专业学生、教师及企业开发者学习进阶也可作为毕设、课程设计或项目立项演示的参考方案。资源包共约2000个文件压缩后64.94MB包含113个C#脚本、25个Shader、8个材质、3个Unity场景文件及多个AssetBundle资源包另有大量meta、png贴图与xml配置覆盖游戏逻辑、渲染效果与资源管理各环节。项目源码均经本地编译验证可运行评审分达95分以上难度适中。内容涵盖完整的麻将玩法实现、3D牌桌场景搭建与资源打包流程目录结构清晰便于按模块检索学习。目前已有470人学习下载适合希望在Unity 3D棋牌游戏方向积累实战经验的开发者参考借鉴。1. 从零拆解一个 3D 麻将棋牌项目为什么它值得你花两周啃下来很多人第一次听到「基于 Unity 开发的 3D 麻将棋牌游戏」脑子里冒出来的画面是那种街边小游戏——几张牌贴图、点一下出牌、胡了弹个框。但真正参考欢乐麻将这类成熟手游做一遍你会发现它压根不是「贴图 按钮」的活。它同时压着四套系统3D 牌桌与摄像机调度、麻将核心规则引擎胡牌判定、番型计算、听牌提示、四人实时同步的状态机、以及一套能撑住长线运营的 UI 与资源框架。任何一环塌了玩家立刻能感觉到「这游戏不对劲」。这个方向适合两类人一类是想拿一个完整度高、能写进简历或毕设的 Unity 项目练手的同学另一类是已经会写 C# 但没做过「规则复杂 联网状态同步」这类业务的开发者。它最大的价值不在画面而在于你会被迫把「数据驱动的规则引擎」和「表现层」彻底分开——这个习惯一旦养成后面做任何棋牌、卡牌、回合制都能直接复用。下面我按实际落地顺序把选型、规则引擎、3D 表现、同步和优化一层层拆开讲。2. 先定架构再动手Unity 做麻将棋牌的模块划分与选型理由2.1 为什么必须把规则引擎和 MonoBehaviour 解耦新手最容易翻车的地方就是把胡牌判定直接写进PlayerController或者某个GameManager里用一堆if判断手牌。这样写前两天很爽第三天加「七对」「十三幺」「杠上开花」的时候你会发现自己在一坨面条代码里找不着北。麻将规则的本质是纯数据运算给定 14 张牌或 13 张 摸牌判断能不能胡、胡多少番、听哪些牌。它跟 Unity 的渲染、输入、网络一点关系都没有。所以我的做法是规则引擎写成一个纯 C# 类库不继承 MonoBehaviour不引用 UnityEngine输入是手牌数组和操作历史输出是判定结果。这样它既能跑在 Unity 里也能单独写单元测试甚至能拿到服务端复用。表现层只负责「把引擎算出来的结果演出来」。这条边界一旦划清后面所有复杂度都有了落脚点。2.2 目录结构与核心模块清单一个能撑住迭代的工程目录大致这么分。注意这不是让你照抄而是让你理解「为什么这么分」——每个目录对应一个职责边界。目录职责是否依赖 UnityEngineAssets/Scripts/Core麻将规则引擎、牌型判定、番型计算否Assets/Scripts/GameFlow回合状态机、发牌/摸牌/出牌流程是Assets/Scripts/Net房间同步、消息协议、断线重连是Assets/Scripts/View3D 牌桌、手牌排列、动画、特效是Assets/Scripts/UI大厅、结算、设置面板是Assets/Data牌型配置、番型表ScriptableObject / JSON是Core目录是整个项目的命根子它必须能脱离 Unity 编译。我一般会在解决方案里单独建一个.csproj把它编成 DLLUnity 侧只引用。这样做的直接好处是规则改动可以先用 NUnit 跑几百个用例验证再进引擎看表现排查问题时能立刻判断「是规则错了还是表现错了」。2.3 牌的数据表示为什么用 int 而不是 enum 或字符串牌怎么表示直接决定规则引擎写起来顺不顺。常见三种做法字符串1W 9T、枚举TileType.Wan1、整数编码。我强烈建议用整数编码理由很实在——麻将判定里大量涉及「排序」「找顺子」「数同花色张数」整数做这些运算最自然还能直接当下标用数组做计数。// 牌编码花色 * 10 点数方便按花色分组和排序 // 万0, 条1, 筒2, 字牌3 // 例如 1万1, 9万9, 1条11, 9条19, 1筒21, 东31, 中37 public static class TileCode { public const int WanBase 0; public const int TiaoBase 10; public const int TongBase 20; public const int ZiBase 30; public static int Suit(int tile) tile / 10; // 花色 public static int Rank(int tile) tile % 10; // 点数 // 判断是否字牌东南西北中发白 public static bool IsHonor(int tile) tile ZiBase; }这段编码的关键在于「花色 * 10 点数」这个设计。取花色用整除 10取点数用取模 10两个操作都是常数时间。字牌从 31 开始和序数牌天然隔开判断是否字牌只需一次比较。参数上唯一要注意的是点数范围必须控制在 1~9字牌 1~7别越界否则取模会串味。如果你后面要加花牌春夏秋冬建议单独开一段编码区间别混进现有体系。3. 麻将核心规则引擎胡牌判定、听牌计算与番型配置怎么落地3.1 胡牌判定的递归拆解思路胡牌判定的经典做法是「先抽将牌再拆刻子和顺子」。14 张牌里必然有一对将特殊牌型除外把每种可能的将牌抽出来试一次剩下的 12 张如果能全部拆成「刻子三张相同或顺子同花色连续三张」就胡了。这个拆解用递归写最清晰。// 判断剩余牌能否全部拆成刻子或顺子 // counts: 长度 40 的计数数组counts[tile] 表示该牌张数 private static bool CanFormMelds(int[] counts) { // 找到第一张还有剩余的牌 int first -1; for (int i 0; i counts.Length; i) { if (counts[i] 0) { first i; break; } } if (first -1) return true; // 全部拆完成功 // 尝试拆刻子 if (counts[first] 3) { counts[first] - 3; if (CanFormMelds(counts)) { counts[first] 3; return true; } counts[first] 3; // 回溯 } // 尝试拆顺子仅序数牌且点数 7 if (!TileCode.IsHonor(first) TileCode.Rank(first) 7 counts[first 1] 0 counts[first 2] 0) { counts[first]--; counts[first 1]--; counts[first 2]--; if (CanFormMelds(counts)) { counts[first]; counts[first 1]; counts[first 2]; return true; } counts[first]; counts[first 1]; counts[first 2]; // 回溯 } return false; }逻辑说明每次递归都锁定「当前最小的还有剩余的牌」因为拆解顺序不影响最终能否拆完锁定最小值能避免重复搜索。拆完刻子或顺子后递归失败就回溯。参数上counts数组长度取 40 是为了覆盖到 37中留点余量。这里有个性能细节递归本身有重复子问题实战中我会加一个Dictionary做记忆化或者干脆用「预生成所有胡牌模板」的查表法后者在移动端更稳。3.2 听牌计算把「差一张能胡」枚举出来听牌计算就是对当前 13 张手牌枚举所有可能的 34 种牌逐一加进去看能不能胡。能胡的那张就是听的牌。听起来暴力但 34 次判定对现代设备毫无压力完全不用优化。// 返回当前手牌所有能胡的牌听牌列表 public static Listint GetTingTiles(int[] handCounts) { var result new Listint(); var allTiles new Listint(); // 收集所有合法牌编码 for (int s 0; s 3; s) for (int r 1; r 9; r) allTiles.Add(s * 10 r); for (int r 1; r 7; r) allTiles.Add(30 r); foreach (int tile in allTiles) { if (handCounts[tile] 4) continue; // 该牌已用完不可能再摸到 handCounts[tile]; if (IsHu(handCounts)) result.Add(tile); handCounts[tile]--; // 还原 } return result; }这里IsHu就是「抽将 CanFormMelds」的组合。参数上注意handCounts[tile] 4这个剪枝——一副牌每种最多 4 张已经 4 张就不可能再摸到跳过能省一点算力。听牌列表算出来后UI 上给玩家做「听牌提示」就是直接读这个列表规则和表现又一次干净分离。3.3 番型配置用数据表而不是硬编码番型胡牌牌型的得分规则是麻将里最容易膨胀的部分。欢乐麻将那种量级番型几十种如果全用if-else写死维护成本爆炸。我的做法是把番型定义成数据表用 ScriptableObject 或 JSON 存引擎只负责「匹配条件 累加番数」。字段含义示例id番型唯一标识qingyisename显示名清一色fan番数24condition匹配条件标识AllSameSuitexclusive是否与其他番型互斥false引擎里维护一个「条件判定器」字典condition字符串映射到具体判定函数。加新番型时只改数据表 加一个判定函数不动主流程。这套设计的好处是策划能自己配表程序只保证判定器正确。注意exclusive字段要处理好——有些番型互斥比如「清一色」和「混一色」不会同时成立配错了会导致番数虚高这是结算对账时最常见的坑。4. 3D 牌桌与表现层摄像机、手牌排列和粒子特效的实战参数4.1 摄像机调度固定视角 局部特写3D 麻将的摄像机不是随便摆的。玩家视角要能同时看清自己的手牌、桌面打出的牌、以及对手的状态。常见做法是主摄像机固定一个俯视斜角胡牌或杠牌时切到特写机位做动画。主摄像机我一般用透视投影FOV 控制在 40~50 之间太高会有明显畸变太低牌桌显得扁平。// 主摄像机跟随配置固定角度只做轻微呼吸感 public class CameraRig : MonoBehaviour { public Transform target; // 牌桌中心 public Vector3 offset new Vector3(0, 8.5f, -6f); public float smooth 6f; // 跟随平滑系数 void LateUpdate() { // 目标位置 牌桌中心 固定偏移 Vector3 desired target.position offset; transform.position Vector3.Lerp( transform.position, desired, Time.deltaTime * smooth); // 始终看向牌桌中心 transform.LookAt(target.position Vector3.up * 0.5f); } }参数说明offset的 Y 值决定俯视高度8.5 左右能兼顾手牌和桌面Z 值决定前后距离太近手牌会出画。smooth用 6 比较跟手又不抖。LateUpdate里做跟随是为了避免和手牌动画抢更新顺序。这里有个血泪经验别在Update里直接LookAt加位移容易和动画系统打架导致镜头轻微抖动玩家会觉得「晕」。4.2 手牌排列弧形布局与自适应间距手牌不能排成一条直线那样既不好看也不符合真实麻将的手感。常见做法是排成一段圆弧中间的牌略高、两端的牌略低并带一点旋转。牌数变化时摸牌、出牌间距要自适应。// 手牌弧形排列根据牌数动态计算每张牌的位置和旋转 public void LayoutHand(ListTransform tiles) { int n tiles.Count; float totalAngle Mathf.Min(30f, n * 2.5f); // 总弧度封顶 30 度 float step n 1 ? totalAngle / (n - 1) : 0f; float startAngle -totalAngle * 0.5f; float radius 6f; // 弧半径 for (int i 0; i n; i) { float angle startAngle step * i; float rad angle * Mathf.Deg2Rad; // 沿弧线计算位置 Vector3 pos new Vector3( Mathf.Sin(rad) * radius, Mathf.Cos(rad) * radius - radius, // 中间高两端低 0); tiles[i].localPosition pos; tiles[i].localRotation Quaternion.Euler(0, 0, -angle); } }逻辑说明totalAngle控制整段弧的张开程度牌多时封顶 30 度避免两端牌转得太夸张。radius越大弧越平6 左右手感比较自然。位置计算里Cos(rad) * radius - radius这一项让中间的牌 Y 值最高、两端最低形成自然的扇形。参数上要注意牌数超过 14 张比如杠牌后时间距会变挤实战中我会把radius随牌数略微调大或者允许手牌分两行。4.3 粒子特效与内存别让胡牌特效拖垮帧率胡牌、杠牌、自摸这些时刻要有效果但粒子特效是 Unity 里最容易内存泄漏的地方之一。常见翻车场景是每次胡牌Instantiate一个特效预制体播完忘了Destroy打十几局内存就上去了。正确做法是用对象池特效播完回收而不是销毁。// 简易特效对象池避免频繁 Instantiate/Destroy public class EffectPool : MonoBehaviour { public GameObject prefab; private QueueGameObject pool new QueueGameObject(); public GameObject Get(Vector3 pos) { GameObject go pool.Count 0 ? pool.Dequeue() : Instantiate(prefab); go.transform.position pos; go.SetActive(true); return go; } public void Return(GameObject go) { go.SetActive(false); pool.Enqueue(go); // 回收而非销毁 } }参数说明池的初始容量按「同屏最大特效数」估一般 5~8 个够用。特效播放完通过ParticleSystem.main.stopAction或协程回调Return。注意SetActive(false)不会停止粒子模拟回收前要手动Clear()否则下次取出时会看到残留粒子。这个坑我在项目里踩过表现是「特效第二次播放时闪一下旧粒子」排查了半天。5. 四人同步与状态机回合流转、断线重连的避坑清单5.1 回合状态机把「谁该出牌」管清楚麻将的回合流转看着简单实则状态很多发牌、摸牌、出牌、等待其他玩家、碰杠胡的抢牌窗口、结算。用状态机管是最稳的。我一般定义一个枚举状态 一个GameStateMachine类每个状态有进入、更新、退出三个钩子。public enum GameState { Dealing, // 发牌 WaitingDraw, // 等待摸牌 WaitingPlay, // 等待出牌 ClaimWindow, // 碰杠胡抢牌窗口 Settle // 结算 } public class GameStateMachine { public GameState Current { get; private set; } private float stateTimer; public void Change(GameState next) { OnExit(Current); Current next; stateTimer 0f; OnEnter(next); } public void Tick(float dt) { stateTimer dt; // 抢牌窗口超时自动关闭防止卡死 if (Current GameState.ClaimWindow stateTimer 5f) Change(GameState.WaitingDraw); } }逻辑说明ClaimWindow是别人打牌后、其他人可以碰杠胡的时间窗口必须有超时兜底否则某个玩家掉线会导致整局卡死。参数上 5 秒是常见值太长拖节奏太短玩家来不及反应。stateTimer在每个状态进入时清零方便做各种超时判定。5.2 断线重连状态快照比补发消息更可靠断线重连是棋牌游戏的刚需。常见两种做法一是补发断线期间的所有消息二是直接下发一份完整状态快照。我强烈推荐快照——补发消息在消息量大、顺序敏感时极易出错而快照是「当前真相」重连后直接覆盖本地状态即可。快照要包含当前手牌、桌面已打出的牌、各家副露碰杠、当前轮到谁、剩余牌墙数量、当前状态机状态。服务端序列化后下发客户端反序列化重建。注意快照里的「剩余牌墙」不能下发具体牌序否则等于作弊只下发数量即可摸牌时再单独请求。5.3 同步避坑清单现象玩家出牌后别人看到的牌和出牌者不一致。原因出牌消息只发了牌编码没带「谁出的、第几张」客户端各自推断导致错位。解决出牌消息必须带玩家 ID 牌编码 序号客户端严格按消息渲染。现象碰牌时两个人同时点结果都碰了。原因抢牌窗口没有服务端仲裁客户端各自判定。解决所有碰杠胡的最终裁决必须在服务端客户端只发「请求」收到「确认」才执行。现象重连后手牌顺序乱了。原因快照没保存手牌顺序客户端按编码排序重建。解决快照里手牌按原始顺序存数组别排序。现象结算番数和玩家自己算的对不上。原因客户端和服务端各跑一套番型判定逻辑有偏差。解决结算以服务端为准客户端只做展示或者两端共用同一份规则引擎代码。6. 性能优化与打包让 3D 麻将在中低端机上稳 60 帧6.1 包体与 Draw Call合批和纹理图集3D 麻将的模型面数不高真正的瓶颈在 Draw Call。牌面、桌面、UI 如果各用各的材质Draw Call 轻松上百。优化手段牌面用一张图集Atlas所有牌共用材质靠 UV 偏移区分静态的桌面、椅子用 Static BatchingUI 用 Sprite Atlas。做完这些Draw Call 能压到 30 以内。// 运行时给牌面设置图集 UV 偏移示意 // 假设图集 10 列每张牌占 1/10 宽 public void SetTileUV(Renderer rend, int tileIndex) { var mat rend.material; float col tileIndex % 10; float row tileIndex / 10; mat.mainTextureScale new Vector2(0.1f, 0.1f); mat.mainTextureOffset new Vector2(col * 0.1f, row * 0.1f); }参数说明mainTextureScale是每张牌在图集里占的比例10 列就是 0.1。mainTextureOffset是偏移。注意每个牌实例要material而不是sharedMaterial否则会互相覆盖 UV——但这样又会产生材质实例破坏合批。正确做法是用MaterialPropertyBlock既能改 UV 又不破坏合批这是关键细节。6.2 移动端打包注意项打包到手机时几个必查项纹理压缩格式Android 用 ASTCiOS 用 ASTC 或 PVRTC、Shader 变体数量用 Shader Variant Collection 剔除没用的、IL2CPP 编译比 Mono 快但包体大棋牌类建议开。分辨率设置上别锁死 1080p用Screen.SetResolution按设备自适应中低端机降到 720p 能明显提帧。6.3 一个我常用的验证习惯每次改完规则引擎或同步逻辑我会先跑一遍「单机四人 AI 对战」——四个 AI 互相打跑几百局看有没有卡死、番数异常、状态机死循环。这个自动化测试比手动点牌高效得多很多边界 bug比如「最后一张牌被碰后牌墙空了」都是这么跑出来的。规则引擎因为不依赖 Unity可以直接在 NUnit 里跑几分钟出结果。最后说个我自己的教训这个项目最容易让人上头的是画面最容易埋雷的是规则和同步。我早期花了两周调摄像机手感和粒子特效结果联调时发现胡牌判定漏了「抢杠胡」返工重写引擎。后来我养成习惯——先把Core目录的规则用例写满再动表现层。规则稳了画面怎么改都不慌。希望帮到你。本文还有配套的精品资源点击获取