简介在游戏开发中客户端架构设计决定了项目的可维护性与扩展性。以Unity和C#为技术栈纸牌类游戏作为典型的实时交互应用其核心在于将复杂的UI状态、网络消息与逻辑层解耦。通过分析一套完整的Unity纸牌游戏客户端源码可以深入理解消息分发机制、事件驱动模型、以及UI与逻辑分离的工程实践。从数据序列化、粘包拆包处理到UI拖拽优化这些基础技术点共同支撑起流畅的玩家体验。掌握这些原理不仅有助于开发棋牌游戏也能迁移到其他联机游戏项目中。以“扑克手云”为例拆解其模块划分与核心实现为开发者提供可参考的客户端架构范本。 最近在拆一套“扑克手云”的Unity纸牌游戏客户端源码拆完以后最大感受是一个项目能不能被称为“优秀源码”跟它用了多少高级技巧没关系更多是看代码结构能不能让人在一个月以后还能看懂换个人接手能不能改得动。这套项目的架构属于“简单但规整”那一类Unity C#核心围绕牌桌场景、手牌管理、出牌逻辑、网络消息收发和UI状态同步来展开。如果你项目空窗期想找个完整的棋牌类客户端例子或者想学习怎么从0搭一套游戏客户端这套源码值得花一个周末仔细过一遍。先说这套源码能解决什么问题。第一它告诉你纸牌类游戏客户端的通用模块长什么样第二它给了一套比较清爽的C#分层方式第三它把“服务端下发消息客户端响应刷新UI”这个高频场景做得直接明了。不是那种堆了一堆类、改一个功能牵连五个脚本的写法读起来负担比较小。下面按我实际拆解的顺序来写。1. 项目整体设计与模块划分1.1 为什么选Unity加C#做纸牌客户端棋牌类项目普遍有一个特点玩法逻辑不算复杂但UI状态特别多。手牌要排序、出牌要拖拽、倒计时要跳、聊天消息要滚动、牌局结果要弹窗这些如果全部用原生代码写界面工程量不小。Unity在2D UI上的成熟度很高UGUI配合Animator做纸牌类交互非常顺手所以“扑克手云”选Unity属于最自然的路线没必要为炫技去换引擎。C#这个语言也比较划算。它的类型系统让手牌这类数据不容易在传输过程中被改出奇怪的值委托和事件又可以很自然地处理“用户点了一下牌”“收到服务端通知”这类回调逻辑。源码里大量用到了事件和委托这正好是对C#核心特性的一次实战示范比如出牌区点击回调、房间状态变更通知。有C#基础的人读起来会觉得很亲切刚好还能看看委托在实际业务里怎么用而不是停留在语法层面。1.2 客户端源码的模块边界打开项目以后目录划分很清晰大致是GameEntry程序入口负责初始化SDK、加载全局配置Net网络层封装连接、消息编码、消息分发UI所有UGUI界面一个界面一个Prefab对应一个ControllerGameLogic纯逻辑层主要放手牌、牌型、局内状态Data数据表、玩家信息、协议对象Tool公共工具方法。这套划分不是花架子它最大的好处是UI和逻辑被隔开了。我在实际项目里见过很多把出牌规则写在按钮点击事件里的写法当时改着方便后期加了机器人、加了重连以后就是灾难。“扑克手云”把出牌逻辑放在GameLogic里UI层只负责把玩家的点击转换成一句RequestPlayCards(cardIds)这样多端复用和测试都会容易很多。1.3 客户端和服务端的接口约定客户端源码要跑起来理解网络协议这块绕不开。项目用的是自定义二进制协议包头是消息长度加消息ID包体是JSON字符串。虽然JSON串在性能上不如直接二进制序列化但胜在调试方便人在断点里直接能看到可读数据。这套源码把消息分发做成了注册表风格每个消息ID对应一个Handler收到包后按ID分发不搞一堆if else。public class MsgDispatcher { private Dictionaryint, Actionbyte[] _handlers new Dictionaryint, Actionbyte[](); public void Register(int msgId, Actionbyte[] handler) { _handlers[msgId] handler; } public void Dispatch(int msgId, byte[] body) { if (_handlers.TryGetValue(msgId, out var handler)) { handler(body); } } }这里要理解一件事纸牌游戏服务端是权威的客户端不能自己决定“我出了这手牌就真出了”。客户端做的是把请求发出去等服务端返回结果再更新界面这样能避免很多不同步问题。在这套源码里点出牌后本地会先进入灰色等待状态而不是立刻把牌打出去这是对的做法。很多新手写单机玩法写习惯了总想本地立刻响应放到联机环境里就容易出逻辑漏洞。2. 核心玩法与UI交互细节2.1 牌桌场景与UI层级设计牌桌场景在纸牌项目里是整个客户端的脸面。“扑克手云”的场景结构并不复杂但层级设计值得说说。最底层是背景和桌面装饰中间层是玩家信息区和手牌区最上层是操作按钮区、倒计时、弹窗、飘字提示。这样的层叠关系保证了任何情况下操作按钮都不会被手牌挡住弹窗出现时又天然盖住全局。UGUI的层级对性能也有影响。像牌桌这种经常有牌进出的场景如果每个牌对象都是一个带大图集的Image再叠加各种描边、阴影特效重建网格的开销会很高。这套源码的处理方式是把静态背景和动态牌面分开背景永远不参与层级重建只有手牌和出牌区频繁动这样Draw Call控制起来就简单得多。2.2 手牌拖拽与点击出牌手牌交互有几个细节处理不好会非常难受。最典型的是“拖拽灵敏度”用户按下鼠标后手指稍微动了几个像素到底算点击还是拖拽源码里给出的方案是记录按下位置位移超过阈值才进入拖拽状态否则等抬起时按点击处理。private const float DragThreshold 20f; private Vector2 _downPos; private bool _isDragging; public void OnPointerDown(PointerEventData eventData) { _isDragging false; _downPos eventData.position; } public void OnDrag(PointerEventData eventData) { if (Vector2.Distance(eventData.position, _downPos) DragThreshold) { _isDragging true; } if (_isDragging) { transform.position eventData.position; } } public void OnPointerUp(PointerEventData eventData) { if (!_isDragging) { // 处理点击出牌 GameEvents.RequestPlay(CurrentCardId); } }这个逻辑看起来简单但难在工程化。卡牌对象本身要接收UGUI的Pointer事件Image身上必须勾选RaycastTarget同时手牌区域和出牌区的高层容器不能把这个事件吞掉。源码里专门在牌桌画布上挂了自研的CardRaycastFilter处理哪些区域能响应鼠标、哪些区域要穿透这样拖拽到出牌区外松手不会误触发。2.3 牌型计算逻辑牌型计算是棋牌项目里最容易写乱的模块因为玩法规则多分支判断很容易堆成屎山。“扑克手云”的写法是把牌型枚举和判断方法分开每种牌型一个判定函数统一收进一个静态类。public static class CardTypeChecker { public static CardType Check(ListCardData cards) { if (cards null || cards.Count 0) return CardType.None; cards.Sort((a, b) a.Rank.CompareTo(b.Rank)); if (IsStraightFlush(cards)) return CardType.StraightFlush; if (IsFourOfKind(cards)) return CardType.FourOfKind; if (IsFullHouse(cards)) return CardType.FullHouse; if (IsFlush(cards)) return CardType.Flush; if (IsStraight(cards)) return CardType.Straight; if (IsThreeOfKind(cards)) return CardType.ThreeOfKind; if (IsTwoPair(cards)) return CardType.TwoPair; if (IsOnePair(cards)) return CardType.OnePair; return CardType.HighCard; } }这种写法看着繁琐但后续扩展规则很方便。比如要加“同花顺大于四条”还是“红桃同花大于黑桃同花”只需要在判断函数里调大小关系不用动调用方。另外要注意玩牌规则里2和A的大小在不同玩法里不一样所以源码里没有硬编码int rank而是抽象出一个RankRule接口把“A最大还是2最大”这种差异留给配置去决定。这个设计很聪明同一个客户端可以适配多种玩法。2.4 动画与状态反馈纸牌项目动画多处理不好会显得很硬。“扑克手云”里出牌、弃牌、收牌的动画不是每个单独做逻辑而是统一走一个CardAnimCtrl用DOTween批量控制位置和旋转。比如出牌时卡片从手牌区飞到出牌区同时做一次翻转和放大动画时长固定180毫秒这样手感和节奏是稳定的。动画状态和游戏状态需要同步。“扑克手云”的做法是在动画播放期间把操作锁住等动画回调结束再恢复输入。这个细节很重要否则用户疯狂点屏幕可能触发好几轮出牌请求会造成服务端数据错乱。我在别的项目里就踩过这个坑最后不得不在请求层加一个节流阀其实源头就是动画期间没锁输入。private IEnumerator PlayCardCoroutine(CardView view, Vector2 targetPos) { _inputLocked true; view.rectTransform.DOMove(targetPos, 0.18f).SetEase(Ease.OutCubic); yield return new WaitForSeconds(0.18f); _inputLocked false; }3. 客户端核心功能实现3.1 MonoBehaviour脚本架构与对象生命周期看这套源码的方便之处在于整个客户端没有把逻辑全部塞进MonoBehaviour里。MonoBehaviour一方面方便在Inspector里拖引用另一方面生命周期和场景绑得太死场景切掉对象就没了。“扑克手云”把大部分数据和逻辑放在纯C#类中MonoBehaviour只做视图组件负责监听UI事件和驱动表现。举个例子RoomModel是纯C#类保存房间号、玩家列表、当前局状态、手牌数据RoomView是MonoBehaviour只负责把RoomModel的数据刷新到UI上。当网络层收到“玩家加入”消息后直接改RoomModel再通过事件通知RoomView刷新二者解耦。这样做有一个明显好处断线重连的时候RoomModel可以直接恢复不需要重新等场景加载。测试也方便单测直接new一个RoomModel给逻辑注入数据不依赖Unity的播放模式跑得也快。3.2 数据序列化与消息分发客户端网络层最容易忽略的点是粘包和拆包。“扑克手云”在Socket接收数据时维护了一个缓冲区每次收到数据先检查包头里的长度字段够长才解析出完整消息体否则继续等下一包。这个处理是网络层的基本功但很多初学者写网络都会漏。public class PacketParser { private byte[] _buffer new byte[8192]; private int _offset 0; public void Append(byte[] data) { Array.Copy(data, 0, _buffer, _offset, data.Length); _offset data.Length; while (_offset 8) { int len BitConverter.ToInt32(_buffer, 0); if (_offset len 8) break; int msgId BitConverter.ToInt32(_buffer, 4); byte[] body new byte[len]; Array.Copy(_buffer, 8, body, 0, len); _msgDispatcher.Dispatch(msgId, body); _offset - len 8; Array.Copy(_buffer, len 8, _buffer, 0, _offset); } } }这套逻辑里解析的时候用的是大端还是小端要看服务端的约定源码注释里写得很清楚服务端是C#的BitConverter默认小端所以客户端也用小端省了一次字节序转换。如果对接的服务端是Java或者Go那就要注意字节序否则会出现消息头解析错误。3.3 资源加载与配置表Unity项目的资源管理最容易让人头疼的是引用满天飞。“扑克手云”没有用Addressables这类重量级方案而是用Unity原生的Resources.Load加一层缓存。项目不大牌面、背景、特效这些资源加起来也就二三十个Resources目录管理完全够用。但代码里有个经验值得学所有资源路径不是硬编码到业务脚本里的而是统一在一个ResPath静态类中定义常量。这样以后要改成AssetBundle或者Addressables只改加载方法不用满项目找字符串。配置表方面项目使用ScriptableObject来存卡牌的基础数值比如花色、点数、特效绑定等。用ScriptableObject的好处是改配置不需要重新打客户端包策划同学直接在编辑器里改资产就行。而且它天然支持Unity的Inspector编辑不容易写错字段名。3.4 跨平台分辨率和输入适配纸牌客户端一般会同时面向PC和手机分辨率适配不能只做一个设计尺寸然后拉伸。“扑克手云”用的是Unity UGUI的CanvasScaler模式设为Scale With Screen Size参考分辨率1280x720。虽然PC和iPhone屏幕比例不同但通过Match Width Or Height的中间值让UI在竖屏和横屏下都能保持不错的位置。不过在开发机测试时要特别注意的一件事是不同平台上EventSystem的行为有一点点差异鼠标点击和触摸点击虽然都走IPointerClickHandler但在某些安卓机型上会有点击位置偏移。源码里没有硬编码屏幕像素而是始终用RectTransformUtility.ScreenPointToLocalPointInRectangle做坐标转换这个细节对手机端体验影响很大。4. 实战中遇到的坑和优化记录4.1 导入源码以后报一堆错拿到Unity项目源码第一件事不是看代码而是打开Project Window确认Assets目录结构和包管理器里的依赖。这个项目的坑在于它用了DOTween如果你本地没有安装导入后会有几十个找不到命名空间的报错。处理方案是先去Package Manager或者从官方网站导入DOTween插件再等IDE重新编译。还有一类报错是版本问题。Unity每年更新都会废弃一些API比如老的OnGUI写法、UnityWebRequest的旧接口导入到2022以后会报过时警告。大部分警告不影响运行但如果你使用的是2021以上的版本建议把项目先把API升级到对应版本否则有些打包配置会变得不可控。4.2 UI拖拽事件被遮挡我在跑“扑克手云”的时候曾经遇到一个问题拖动一张牌到出牌区上方明明位置已经进入目标区域却不触发高亮。排查后发现出牌区的碰撞检测区域被它下面一个透明的全屏Image挡掉了。这个Image本身是用于控制点击穿透的但因为RaycastTarget没有关闭导致事件被它截胡。解决办法是给透明Image关闭RaycastTarget或者根据事件状态动态切换RaycatTarget。这也是UGUI一个问题反复出现的根源很多人不知道RaycastTarget不光是决定这个UI能不能点到还会直接影响整个UI事件系统的性能。像这种全屏透明层开着射线检测等于每帧都多做了大量UI射线检测白白消耗性能。4.3 GC与卡顿优化纸牌项目的GC压力主要来自字符串拼接和JSON解析。“扑克手云”在收到网络消息时会做一次JsonUtility.FromJson如果在Update里随手Debug.Log拼接消息内容很容易产生大量瞬时垃圾。源码的做法是所有日志走自定义LogUtil发布版本直接禁掉Debug避免不必要的字符串分配。手牌列表频繁增删也会造成GC。源码里没有在主线程用List.RemoveAt到处删除而是先把要删除的索引收集起来最后统一批量移除同时复用卡牌对应的CardView对象。这个优化策略在老手机上效果很明显真机测试帧率从37帧提回到60帧左右卡顿感基本消失。4.4 升级Unity版本以后UI错位很多项目源码能跑但一升级Unity版本就会出现UI错位或字体发虚。“扑克手云”原来在Unity 2019上开发升级到2022以后Text组件的渲染方式变了部分场景里的中文字体无法显示。原因是旧项目用的是动态字体字体文件是“Dynamic”模式而新版本对动态字体的默认回退逻辑做了调整导致字体丢失。解决方式有两个一是把字体改成Legacy模式并手动指定字体资产二是用新的TextMeshPro重做一遍UI组件。这套系统里统一换了TMP并做了字体资产重新生成顺便把各种字号也统一成了TMP的样式表反而比原来更好维护了。5. 从源码里透出来的工程习惯5.1 命名、注释和提交习惯看源码过程中我挺感慨的是它的一致性。私有字段统一用_camelCase公共属性统一用PascalCase消息类名后面统一挂Msg后缀事件名统一带On前缀。这些约定虽然不复杂但能坚持到上百个脚本都遵守是团队协作的底线。很多项目代码乱不是大家不懂规范而是没在编码规范里落到强制规则。注释这块源码没有每行都注释而是在关键节点上写“为什么这么写”。比如出牌动画那里注释不是写“播放动画”而是写“动画期间必须锁输入否则用户连续点击会发出多个请求”这种注释才有价值。我在整理项目时也习惯把“为什么”写清楚比把“是什么”写清楚更重要。5.2 给热更新和混淆留后路棋牌类游戏在国内上线基本躲不开热更新和代码混淆。虽然“扑克手云”本身没有接热更新框架但它的代码分层方式让热更新接入成本很低。只要把GameLogic和Net层做成程序集打成一个DLL或者进AssetBundleUI层继续留在主工程就能实现逻辑热更。代码混淆这个点做棋牌的人应该早有耳闻客户端如果明文发布很容易被逆向看到协议和逻辑。“扑克手云”源码没有做混淆但它的协议本身就带了一个token字段每次连接由服务端下发客户端后续消息都要带上这个临时token过期后就失效一定程度防止了简单重放攻击。如果要上生产建议配合商用混淆工具把关键字符串和逻辑混淆掉。5.3 后面可以怎么扩展这套源码虽然已经完整但要变成能上线的产品还有几个地方可以扩展。第一是增加牌局录像功能。现在源码里没有保存对局记录如果要做回放需要在服务端留一份对局事件流客户端只负责播放事件。这其实不难因为客户端本身就依赖事件驱动把网络消息顺便写进列表就能得到回放数据。第二是增加机器人和托管出牌。源码里的GameLogic是纯逻辑层加入AI出牌只要实现一个IPlayerStrategy接口给机器人挂一个自动出牌策略就行。UI层几乎不用改。第三是增加语音聊天和表情互动。纸牌游戏需要强互动源码目前只有文字聊天。接入语音SDK时注意把语音录制和播放的代码也放到相对独立的模块不要和牌局逻辑混在一起否则后期排查问题会很折磨。最后再说一点实际体会这个项目我前后大概花了一个通宵加一个下午梳理完。从最开始看网络层、理解协议到后来把手牌管理逻辑过了一遍最大的收获其实不是某个技术点而是明白了“客户端的价值在于把不确定的网络状态转化成流畅的界面反馈”。你要协调网络延迟、输入响应、动画时长、资源加载这些矛盾哪块没处理好玩家体验都上不来。如果你正在学Unity和C#而且手头缺一个完整的客户端项目做参照去把“扑克手云”这类源码从头到尾过一遍比看十篇教程都好用。重点看三样东西消息分发怎么设计、UI和逻辑怎么解耦、出牌判断怎么扩展。把这三块吃透再去做联机游戏项目思路会清楚很多。还有一个容易被忽略的细节就是一定要养成看Console日志的习惯很多问题不是代码写错了而是场景里面某个组件没挂对日志会直接告诉你。祝你把这套源码啃下来以后能写出比它更顺手的棋牌客户端。本文还有配套的精品资源点击获取