企业官网建设流程全解析

简介：网狐荣耀版十三水UI组件包面向棋牌游戏开发者与界面设计师，以13水UI为核心标签，用于解决十三水（罗宋牌）对局中牌面分组、按钮布局、视觉风格与触控反馈统一的问题。压缩包大小约8.15MB，以zip格式封装，文件类型与数量未在资源页完整展示，解压后通常可得到牌面与按钮的图片素材、界面布局描述、音频配置及交互参数，方便在既有框架中替换资源或按项目需求扩展。已有1458人学习、下载，适合需要快速搭建十三水游戏界面或进行二次定制的团队参考。通过拆解资源内thirteenx目录，可梳理控件层级关系、主题配色、比牌动画与得分栏展示的组织方式，对双屏适配、操作提示和音效触发等模块均有直接借鉴价值。这套设计兼顾静态排版与动态反馈，既照顾了牌区分组的清晰度，又在按钮尺寸、按压状态和动画节奏上匹配移动端操作习惯，能减少从零绘制UI的时间，尤其适用于快速原型验证、风格改版或整合到网狐荣耀版项目中的场景。

1. 网狐荣耀版做十三水，难点不在画牌桌，而在「分墩」这件小事

十三水的UI，第一眼看上去就是一张牌桌加13张牌，比斗地主还简单。但真在网狐荣耀版上动手做一次，你会发现最难的不是画牌桌，而是「分墩」：玩家必须在3张头墩、5张中墩、5张尾墩之间反复调整，牌型判定、拖拽交互、动画时序全压在这一个动作上。这篇文章把十三水UI从布局、分墩交互到比牌动画、断线重连完整过一遍，重点讲参数怎么设、坑在哪。适合两类人：一是在网狐荣耀版上接棋牌定制需求的客户端开发，二是想搞清楚十三水UI技术难点在哪里的产品、测试或刚转行的新人。

2. 十三水UI的牌桌布局：先定三墩结构，再写摆放参数

2.1 网狐荣耀版UI层的基本结构：场景节点与牌桌容器

网狐荣耀版的客户端UI层，常见做法是基于Cocos或Laya这类引擎搭H5场景。整张牌桌是一个场景节点，下面挂背景、座位区、手牌区、操作按钮、弹窗等子节点。节点树的组织方式，决定了后面加动画、做重连时改代码的顺手程度。

table-scene ├── background // 背景图，固定在最底层 ├── seat-layer // 四个座位：对手的下牌区、自己的三墩区都挂这里 │ ├── seat-1 │ ├── seat-2 │ └── seat-3 ├── hand-card-layer // 自己的13张手牌，位于屏幕底部 ├── op-btn-layer // “理牌”“确认”“提示”按钮 └── popup-layer // 比牌结果弹窗、断线提示等

这段节点树和真实项目的差异在于：有的团队会把三墩区挂在每个座位节点下，有的会单独建一个 zone-layer。我一般建议把「自己的三墩区」独立出来，因为十三水的核心交互都发生在这里，座位节点只负责显示对手的牌背和结果，避免后续改动画时把座位逻辑一起拖下水。

节点层级定了之后，剩下就是坐标和尺寸的约定。设计分辨率一般按 1280x720 做，后续换安卓、iOS、Web端只用做等比缩放。我这个项目里第一版直接按960x640做，结果换到平板整个牌桌偏小，最后全部重排，所以一开始就把设计分辨率定成主流档位，后面能少走很多弯路。

2.2 三墩区域与手牌区的坐标规划：头3中5尾5怎么摆

三墩区的位置是十三水UI的第一个关键参数。常规做法是从屏幕底部往上依次放：手牌区（13张牌）、尾墩区（5张）、中墩区（5张）、头墩区（3张）。为什么头墩放最上面？因为头墩牌最少，视觉上放在顶部最轻；尾墩是比牌的胜负关键，放最下面离手牌最近，方便玩家把大牌往上推。

以 1280x720 设计分辨率为基准，我常用的参数是这样：

// 十三水牌桌核心布局参数（设计分辨率 1280x720） const tableLayout = { cardW: 100, // 牌宽 cardH: 150, // 牌高 handY: 80, // 手牌区中心Y坐标 tailY: 230, // 尾墩区中心Y坐标 midY: 350, // 中墩区中心Y坐标 headY: 470, // 头墩区中心Y坐标 zoneGap: 30, // 相邻墩位区的最小间距，用于判定拖拽落点 handGap: -55, // 手牌区相邻牌间距（负值=重叠） };

先说明倒数第二行 zoneGap 的作用：三墩区之间的垂直间距是拖拽手感的决定因素。间距太小，手指头一粗就拖到隔壁墩；间距太大，屏幕高度不够用。30像素是我在720p分辨率下的常用值，如果你的牌更大，适当加到40；牌小就压到20。

再说明手牌区为什么用负间距 -55：13张牌如果摊开放，13×100=1300像素，超出1280屏宽，所以必须重叠。-55的间距让手牌区实际宽度约等于 100 + 12×(100-55)=640 像素，居中显示，既放得下又不会太挤。每张牌叠压在下一张上面，视觉上像收拢的扇形。

这里还要注意发牌顺序和排序的关系。我见过很多团队在开局就把13张牌按点数排好，然后再让玩家分墩，这个顺序其实是错的。玩家习惯看到自己拿到的牌，就像现实中摸牌一样，先按发牌顺序展示；点「理牌」按钮时才排序。新手的常见误解是以为开局就要整理，实际上一开局就排序会让玩家对「系统动过我的牌」产生不信任感。

注意：这里的Y坐标是「节点中心位置」，不是锚点底部。Cocos/Laya 的节点默认锚点是 (0.5, 0.5)，如果锚点改了，坐标要对应调整。这是新手最容易翻车的地方，我调试时被这个坑过整整一个下午。

2.3 三墩内部牌间距：为什么头墩要正间距、尾墩要负间距

三墩的张数不同——头墩3张、中墩5张、尾墩5张。如果都按手牌区那套负间距，头墩3张会挤成一团，尾墩5张又会超出屏幕。我按「区域视觉等宽」来调每个墩内部的牌间距：

头墩3张用正间距12，看起来像三张牌「摊开」；中墩和尾墩用负间距-6，五张牌轻轻叠在一起，既不超出区域范围，又能看清每一张的牌角——牌角是点数标记的位置，必须露出来，否则玩家认不出牌。这里有个工程上的处理细节：每个墩内部，牌从左到右排列，后一张牌叠在前一张上面。叠放顺序（z-order）必须是「后加入的牌在前面」，否则点牌时会点到被压住的那张。

// 把牌加入某个墩位区，并保持正确的叠放顺序 function addCardToZone(cardNode, zoneNode) { zoneNode.addChild(cardNode); cardNode.setSiblingIndex(zoneNode.children.length - 1); // 置于顶层 }

z-order这行注释是重点。大部分十三水UI的「点不到牌」「点了没反应」问题，都出在这里，而不是出在触摸事件没绑上。排这块的时候，我习惯先做一个「点击牌就打印牌ID」的调试开关，把所有牌叠放顺序打一遍，肉眼就能看出哪张被哪张盖住了。

关于自适应，不同分辨率下这套参数要整体缩放。我一般只缩放 cardW 和 cardH，间距跟着牌宽等比走，不单独改。如果新手非要单独调，结果就是某台手机上牌间距怪怪的，这属于自找的，别问我是怎么知道的。

3. 分墩交互：自动分墩算法与拖拽换牌的落地实现

3.1 自动分墩算法：从13张牌里切出三墩的判定逻辑

自动分墩是十三水UI的「标配中的标配」。玩家开局点一下「理牌」，系统立刻给出一个合法且牌型尽量大的三墩排列。这个功能的难点有两个：一是合法性判断（头墩 ≤ 中墩 ≤ 尾墩），二是选最优解还是选「够用解」。

我先写一个可读性优先的解法：

# 自动分墩：穷举头墩3张 + 中墩5张的所有组合 from itertools import combinations def auto_split(cards): best = None best_score = -1 for head in combinations(range(13), 3): rest1 = [i for i in range(13) if i not in head] for mid in combinations(rest1, 5): tail = [i for i in rest1 if i not in mid] # 合法性：头墩牌型 <= 中墩 <= 尾墩 if cmp_hand(cards, head, mid) < 0: continue if cmp_hand(cards, mid, tail) < 0: continue # 评分：三墩牌型分相加，取最大 score = calc_score(cards, head, mid, tail) if score > best_score: best_score = score best = (head, mid, tail) return best

这个穷举的复杂度是 C(13,3)×C(10,5)=72072 次，在手机上纯JS跑会有几百毫秒的卡顿，能接受但体验不好。所以工程上一般不直接这么写，而是先排序再做启发式裁剪。常见做法是：先把13张牌按点数降序排好，优先从尾部挑出最大的5张组成尾墩，再从剩余8张里挑最大的5张组成中墩，剩下的3张做头墩；如果发现中墩比尾墩大之类的非法情况，再做局部交换。

两种方案各有用处：穷举能拿到「当前手牌下最大牌型」，适合玩家点一下就不管的场景；启发式更快，但偶尔会给出「虽然合法但头墩太弱」的结果。我一般把启发式作为默认，穷举只用在玩家点「提示」按钮时，因为此时玩家期待的是最优解。

这里有个参数值得单独说：cmp_hand的比较顺序必须按十三水规则来。先比牌型级别，同级别再比点数：

A2345 这种顺子视为最小顺子，10JQKA 是最大顺子，这两个边界在写比较函数时最容易漏。我见过线上版本把 A2345 判成非法牌型，玩家截图骂了一个礼拜。

3.2 拖拽换牌与墩位交换：触摸事件的三步处理

自动分墩只是起点，玩家大概率还要手动调整。拖拽交互的完整流程是：按下浮起 → 拖动跟随 → 落点判定。落点判定之后还有两个分支：落点区域未满就直接加入，已满就把区域内最靠边的一张牌挤回手牌区，或者交换当前拖拽牌与该区域内最后一张牌。

// 拖拽事件处理（Cocos Creator 风格，Laya 逻辑一致） onTouchStart(event: EventTouch) { const card = this.hitTestCard(event.getUILocation()); if (!card) return; this.dragCard = card; card.y += 25; // 浮起高度：25px，视觉上明显但不脱离手牌区 } onTouchMove(event: EventTouch) { if (!this.dragCard) return; // 节点跟随手指移动，注意坐标空间必须是同一个 this.dragCard.setPosition(event.getUILocation()); } onTouchEnd(event: EventTouch) { if (!this.dragCard) return; const zone = this.hitTestZone(event.getUILocation()); if (zone && zone.cards.length >= zone.maxCount) { // 区域已满：把最外侧的牌挤回手牌区，当前牌放进来 const backCard = zone.cards[zone.cards.length - 1]; this.backToHand(backCard); } if (zone) { this.addCardToZone(this.dragCard, zone); } else { this.dragCard.y -= 25; // 落点无效：回到原位 } this.dragCard = null; }

浮起高度25px是手感调出来的：太小玩家看不出选中，太大牌会遮挡其他牌。落点检测这里用的是AABB矩形判定，检测的矩形要比实际牌区域放大20px左右，因为手指点的位置和牌的视觉中心有偏差。

墩位已满的「挤回」策略有一个细节：被挤回的牌不一定是拖进来的那张牌的替换对象。更通用的做法是交换——把拖进来的牌放进区域末尾，同时把区域里离落点最近的那张牌换出来回手牌区。这个「离落点最近」的判断，代码上就是遍历区域内每张牌的中心点，算欧氏距离取最小。

还有一个手感玄学：拖拽时手指会挡住牌面。我习惯在 onTouchMove 里把被拖的牌往上偏移30px，让牌的底部露出来，玩家能看到自己拖的是什么。这个小改动放到真机上，玩家反馈明显变好。

3.3 提交协议与回滚：本地合法不等于服务器合法

分墩完成后，客户端要把结果提交给服务端。这一步的协议结构各家不同，但核心信息一致：牌ID + 它属于哪个墩位。

{ "cmd": "submit_zones", "seatId": 0, "zones": [ { "zoneId": 0, "cards": [1001, 1002, 1003] }, { "zoneId": 1, "cards": [1004, 1005, 1006, 1007, 1008] }, { "zoneId": 2, "cards": [1009, 1010, 1011, 1012, 1013] } ] }

服务端收到后会重新校验：这13张牌是否属于当前玩家、三墩牌型是否合法。校验失败返回错误码，UI要做两件事：一是回滚到提交前的墩位状态，二是给玩家一个明显提示。

回滚的工程实现，我习惯在提交前保存一份「墩位快照」，就是每个zoneId到cards数组的映射。收到失败消息后，把快照还原到UI，同时播放一个轻微的抖动动画提示玩家。这里不需要重新算牌，因为本地数据其实没变过，只是界面状态被玩家拖乱了。

注意：千万不要在收到服务器校验结果前就清空本地状态。有些实现为了「快」，提交成功就把手牌区置空，结果服务器返回失败时手牌已经没了，只能重新开局拉数据，这属于低级但常见的翻车现场。我后来是直接在提交按钮的回调里加了一个isSubmitting锁，提交期间按钮置灰，服务端没回包之前什么都不许点。

4. 比牌动画、结果展示与状态同步：别让时序毁了整局体验

4.1 比牌数据结构：谁赢了哪一墩

所有玩家提交分墩后，服务端计算比牌结果并按约定下发。比牌结果的数据结构一般包含三墩的胜负和总分胜负：

{ "cmd": "compare_result", "roundId": 128, "zones": [ { "zoneId": 0, "winner": 1 }, { "zoneId": 1, "winner": -1 }, { "zoneId": 2, "winner": 2 } ], "totalWinner": 0 }

winner字段用座位号标识赢家，-1表示平局。UI消费这份数据时要注意：每个墩的winner指的是「这墩谁赢了」，而不是「谁牌最大」。因为平局在十三水里意味着「没赢也没输」，展示上比一般扑克游戏多一个「平」的状态。

UI拿到这份数据后，要做的是：先亮三墩的牌，再在每墩附近弹出胜者标记，最后弹总分结果。这个展示顺序不能乱。从玩家视角看，头墩、中墩、尾墩的胜负是分开的，偶尔出现「头墩我输了，尾墩我赢了，总分我赢」的情况，如果顺序乱了，玩家根本理解不了总分为什么是这个结果。

这里还要考虑四个座位同时都要展示的问题。服务端下发的数据里，通常每个座位都会有一份 zones 对比结果。UI可以在比牌阶段把所有座位的手牌一次性翻开，然后按座位逐个播三墩对比。做之前先确认清楚服务端的数据是全局的还是视角相关的，我在这上面栽过：一开始只处理了自己的数据，结果其他三个座位的比牌结果全是默认值。

4.2 串行动画序列：先翻墩、再亮结果

比牌动画最忌讳并行播放。如果三墩的亮牌和胜负标记同时出现，玩家的视线完全不知道聚焦哪里。正确做法是串行：从头墩开始，先翻转该墩的牌（从牌背翻成牌面），停顿，再显示该墩胜者标记，停顿，然后进入下一墩；尾墩播完，再弹总胜负。

// 串行播放三墩的比牌动画 async function playCompare(result: CompareResult) { const seq = [0, 1, 2]; // 播放顺序：头墩、中墩、尾墩 for (const zoneId of seq) { await flipZoneCards(zoneId); // 该墩所有牌翻面 await sleep(600); // 停留600ms，让玩家看清牌型 await showWinnerMark(zoneId, result.zones[zoneId].winner); await sleep(400); } await showTotalWinner(result.totalWinner); await sleep(800); // 总结果停留久一点 UIManager.close("ComparePopup"); }

两个时间参数是经验值：翻牌后停600ms，是为了让玩家在这段时间里自己先判断「这墩谁大」，然后再亮胜者标记；如果没这个停顿，玩家会觉得结果是被硬塞进来的。总结果停留800ms后自动关闭，但实际项目里这个弹窗一般需要玩家点击确认才关闭，因为紧接着就是下一局的发牌。

动画播放期间还有一个工程细节：引擎的节点操作大多是异步帧驱动的，如果中途玩家点了「跳过」，要能立刻把动画走到终态。实现方式是每步动画都检查一个isSkipped标志，播完当前帧就跳出循环，直接设置三墩的最终显示状态。我见过有人把跳过实现成「把动画速度调成100倍」，结果动画系统直接崩溃，属于血泪经验。

4.3 超时、托管与断线重连：UI状态机的三个边界

分墩交互有时限，一般15到30秒。倒计时是服务端权威：客户端不能只在本地起一个定时器，因为断线重连、网络延迟都会造成本地时间与服务端不一致。常见做法是：服务端在开局消息里带上「剩余秒数」，客户端收到后以这个值为基准做本地递减，每收到一次心跳或同步消息就校正一次。

// 倒计时的本地推进逻辑 onRecvDealMsg(msg) { this.countdown = msg.timeLimit; // 以服务端下发的剩余秒数为准 this.schedule(this.tick, 1); // 每秒推进 } tick() { this.countdown -= 1; if (this.countdown <= 0) { // 超时：本地不做提交，等待服务端自动分墩结果 this.unschedule(this.tick); this.showAutoSubmitTip(); } }

超时的UI表现各项目不同。有的在倒计时归零时直接置灰操作按钮，等服务端广播「已自动分墩」后再进入比牌；有的会先本地触发自动分墩给玩家看一眼。我建议前者——超时的处理完全交给服务端，客户端只负责「变灰」和「等待」，避免本地自动分墩的结果和服务端不一致，导致界面闪一下又回滚。

断线重连是十三水UI最容易漏的状态。重连成功后，服务端会下发一整套牌桌场景数据：当前阶段、剩余倒计时、手牌、三墩状态、所有对手的牌状态。UI拿到后要能整体重建，而不是增量修改。这个重建过程最容易出错的是：重建时不能触发拖拽事件绑定、不能重置倒计时定时器导致时间跳跃。我的做法是重连消息进来时先设一个isReconstructing标记，跳过所有玩家的输入事件处理。

这里还要多说一句托管状态。有些房间规则里，超时后服务端直接下发托管分墩，客户端不要自作主张再上一套「自动分墩」逻辑。托管分墩的结果是服务端算的，客户端只管展示。

5. 十三水UI开发的血泪避坑记录：5个高频问题

5.1 手牌排序「看着乱」：排序与花色优先级

现象：自动分墩后，手牌区13张牌的排列忽大忽小，明明有对子却被拆开，玩家一眼就觉得牌序不对。

原因：排序只按点数排，没把花色纳入比较；或者排序发生在分墩之后，把墩位内的相对顺序也打乱了。

解决：排序做两级——先按点数降序，点数相同按花色降序（黑桃>红心>梅花>方块）；排序只作用于手牌区展示层，不改变分墩数据结构。代码上就是 sort 的比较函数里写两个维度：

// 手牌排序：点数优先，花色次之 cards.sort((a, b) => { if (a.point !== b.point) return b.point - a.point; return b.suit - a.suit; // suit 值：黑桃3 红心2 梅花1 方块0 });

另一个容易被带偏的实现：有人会在排序的同时把牌重新发给牌节点，导致牌节点的触摸事件丢失。排序只动数组和节点位置，不要重建节点。

5.2 本地判定合法，提交后被服务器打回

现象：玩家手动把三墩摆好了，本地显示一切正常，点击确认后服务器返回「分墩不合法」，UI回滚，玩家一脸懵。

原因：最常见的两种——A2345顺子被本地当成了「顺子」，实际上十三水的规则里A2345是合法顺子且是最小顺子，但有些实现漏了这个特例；另一种是本地没有做「头墩 ≤ 中墩 ≤ 尾墩」的完整链式比较，只比较了相邻两墩。

解决：把牌型判定抽成一个独立模块，同时被UI校验和提交前二次校验复用；在代码里显式处理A2345特例；提交前重新执行一次完整的三墩合法性检查，不让玩家把不合法的布局发出去，而不是等服务器打回。

这个独立模块我一般叫hand-rule.js，只放纯函数，不依赖任何引擎API。这样UI层和提交协议层都能引用，也方便写单元测试。

5.3 动画播放中收到新消息：时序错乱

现象：比牌动画正播到中墩，下一局的发牌广播就到了，结果动画还在翻牌，界面出现「牌叠着牌」「胜者标记飘在半空」的错乱。

原因：动画是异步串行，消息处理是同步顺序执行，两者没有互斥保护。

解决：加一个状态锁，动画开始时置位，动画结束复位；动画期间收到的UI类消息全部压入队列，动画结束后统一取出来处理。

// 动画期间屏蔽业务消息 if (this.isAnimating) { this.pendingMessages.push(msg); return; } // 动画结束后统一补处理 async playCompareDone() { this.isAnimating = false; while (this.pendingMessages.length > 0) { const msg = this.pendingMessages.shift(); this.handleMsg(msg); } }

注意，这个锁只能锁「业务消息」，像心跳、断线重连这种系统级消息不能压队列，否则重连逻辑会被无限期拖住。我一开始把所有消息都压队列，结果断线重连的消息排在发牌后面，界面白屏了十秒才恢复。

5.4 特殊牌型检测被普通牌型短路

现象：玩家手牌明明是「三同花」甚至「一条龙」，点提示时UI只提示普通牌型，最佳策略没出来。

原因：检测顺序写反了。代码里先判断普通牌型，一旦命中就用 else if 跳过后面的特殊牌型检测，特殊牌型根本没机会执行。

解决：严格先特殊后普通，并且特殊牌型之间也要有优先级——至尊清龙 > 一条龙 > 十二皇族 > 三同花 > 三顺子 > 六对半 > 报到。报到在十三水规则里是特殊牌型里的最小档，但它仍优先于所有普通牌型。检测函数写成一张有序规则表，逐条匹配，而不是散落的 if/else。

这个问题隐蔽在：大多数测试数据都是普通牌型，特殊牌型要凑才能测到。我后来在测试工具里加了一个内置发牌器，可以一键发出指定牌型，专门用来测这条链路。

5.5 开局手牌先空白再闪烁：纹理加载顺序

现象：进入牌桌瞬间，手牌区先显示一片空白，然后13张牌「啪」一下同时出现，偶尔还闪白屏。

原因：牌面的纹理贴图是异步加载的，开局时13张牌同时创建节点，各自的纹理没加载完就上屏。引擎的回调顺序不可控，叠加的过程被玩家看到了。

解决：开局前先预加载所有牌面纹理，加载完成再创建牌桌节点。牌节点要做对象池——每局结束不要销毁，回收复用，避免反复创建节点带来的GC卡顿。如果项目用远程图库加载牌面，记得把「加载完成再开局」处理成倒计时的一部分，而不是等到加载失败再重试。玩家看到牌桌黑屏几秒的耐心是有限的。

6. 十三水UI的验证清单：上线前花一小时自测这些点

这套自测清单是我每次交付十三水UI前必跑的，六项，快的话一小时能跑完：

1. 倒计时边界：进入分墩阶段后等倒计时自然归零，确认按钮必须置灰，且不能出现「超时后还能提交成功」的报错；同时确认超时后服务端下发的自动分墩结果正确展示。
2. 拖拽落点边界：手牌区与尾墩区的交界线附近松手，看落点是否稳定归位到某一侧，不能出现「半只牌在墩里、半只牌在手牌区」的悬空状态。
3. 墩位满员交换：三墩全满时从手牌区拖入新牌，看被挤回的牌是否正确回手牌区、顺序是否对。重点测尾墩满5张时拖第6张。
4. 断线重连：在分墩阶段杀进程重进，验证倒计时、手牌、三墩全部恢复；再在比牌动画播放到一半时断网，验证动画状态锁能正常兜住。
5. 快速连点：连续快速点两次「确认」，不能发出两次提交；连续点两次「理牌」，自动分墩不能把已经摆好的牌打乱。
6. 特殊牌型展示：用测试工具分别发出至尊清龙、一条龙、报到、三同花这几手牌，验证提示文案、牌型标记、比牌时的特效都正确。

每跑完一项，截一张图或者录一段视频存档。我自己的习惯是，每接手一个十三水UI需求，先把上面6条录成一段操作视频，再动代码。倒计时、动画状态锁、纹理预加载这三块，几乎每轮迭代都会有人改出错，视频能让你快速定位是回归还是新问题。玩棋牌UI的都知道，这类交互不需要多花哨，稳定不闪就是最好的体验。希望帮到你。

本文还有配套的精品资源，点击获取