简介这是一套面向十三水罗宋牌游戏玩家及棋牌UI设计师的界面资源定位于帮助开发者快速理解并复用网狐荣耀版十三水游戏的视觉与交互方案。压缩包大小约8.15MB目前已有1458人学习/下载。资源围绕牌面布局、操作按钮、得分展示及触控反馈等关键环节组织可适配中国风、现代风等视觉风格同时兼顾手机与平板等不同屏幕尺寸。对于希望改进既有十三水产品体验的开发者可通过拆解这套UI资源梳理牌桌信息架构、按钮层级和动效反馈的实现思路对于初学棋牌界面设计的人员也能从中获得一套现成的配色方案、组件划分和交互状态参考用于临摹与二次开发。包内文件明细暂未收录建议下载后先解压并对照目录查看其中包含的图片资源、布局描述及相关配置内容以便结合自身项目进行定制调整。1. 网狐荣耀版做十三水 UI难点不在画牌而在状态不少团队拿到网狐荣耀版这套框架后第一反应是“UI不就是换皮吗”。真把十三水这个玩法接进去才发现画牌只是最表层的工作排墩交互、倒计时、比牌结算这些强状态界面才真正磨人。网狐荣耀版 - UI - 十三水这个方向本质上是在成熟框架里塞进一个“牌桌状态机”界面要跟着玩家的每一次摸牌、摆墩、亮牌、比牌走同时还要兼顾分辨率适配和低端机性能。这篇文章会按我实际接项目时的顺序把荣耀版的 UI 组织方式、十三水各区块的排版逻辑、最小可跑场景和那些让我返过工的坑一次讲清。适合准备在荣耀版上做十三水或者正在被牌桌布局和动画状态折磨的客户端开发者。2. 摸清荣耀版 UI 的组织方式从 HALL 到游戏子包的分工与配置入口2.1 荣耀版 HALL 与游戏 UI 的结构关系荣耀版这类棋牌框架UI 层最核心的概念是“大厅与游戏子包分离”。HALL 负责账号、菜单、商城、公告这些公共界面十三水属于一个独立的游戏子包牌桌场景、牌面资源、玩法逻辑都在子包里。之所以这样拆是因为大厅和游戏的更新节奏不一样大厅改动频繁但界面轻游戏子包体量大但相对稳定。改十三水 UI 时如果动到大厅层的公共控件会影响所有子包所以我一般只在游戏子包内做界面调整。游戏子包内部又分两层引擎层和脚本层。引擎层负责渲染、事件分发、资源加载这些基础能力脚本层用 Lua 描述界面结构、按钮回调、动画序列。荣耀版的常见做法是角色、组件、面板都由脚本创建换 UI 不需要重新编译引擎只替换资源目录和 Lua 文件即可。这个特性决定了十三水项目的 UI 工作大部分落在“写脚本 排资源”上而不是改底层渲染。对不熟悉这套结构的开发者最容易犯的错是直接在大厅场景里挂牌桌节点。大厅节点生命周期由公共模块管理退出登录时会自动销毁牌桌数据还没结算完就被清了。正确做法是把牌桌 UI 挂在游戏子包自己的场景下由子包内的场景管理器控制生命周期。这也是我在新项目里第一个跟后端对齐的事大厅进出游戏到底由谁负责创建和销毁牌桌场景。2.2 十三水项目进来后先看的三个配置位置接手一套荣耀版源码我先不看代码逻辑先翻配置。第一个配置是游戏 ID 与子包路径。HALL 通过这个 ID 拉起游戏子包ID 配错会导致大厅点“进入游戏”后黑屏或闪退。第二个配置是设计分辨率与适配模式荣耀版默认是按标屏坐标设计的这个参数决定牌桌布局在手机上的缩放基准后面适配的很多问题都出在这里。第三个配置是字体和语言包牌桌里的“前墩”“中墩”“后墩”这些文案不一定写在代码里可能走多语言表改 UI 时漏了文案表容易出“文字叠文字”的现象。这三个配置往往分布在不同的配置目录里游戏 ID 在 HALL 的配置表分辨率在引擎的启动参数语言包在公共资源下。我的习惯是进项目第一天先建一个“配置索引”文档把这三个位置记下来后面每次调 UI 都能快速定位。这个动作很枯燥但能省掉很多到处翻资源的无效时间尤其是当项目经过多次交接后配置项可能分散在多个文件里只靠记忆很容易漏。2.3 资源目录与命名约定改 UI 前先定规矩荣耀版十三水 UI 涉及的资源类型比其他棋牌游戏复杂牌面、牌背、人物头像、表情、特效、音效、背景再加上不同尺寸的资源。如果不先定目录和命名规矩做到一半就会出现“牌面_new.png”和“牌面_new2.png”同时存在的局面到时候连谁在用都查不清。我一般会在游戏子包内按功能切目录并在文件命名里带上尺寸和用途。res/ game/ cards/ # 普通牌面 12 生肖 大小王按 id 命名card_01.png backs/ # 牌背back_default.png / back_red.png ui/ # 界面控件btn_confirm.png / panel_result.png effect/ # 特效effect_deal_card.png / effect_compare.png sound/ # 音效sound_deal.wav / sound_win.wav common/ font/ # 字体文件 language/ # 多语言表lang_zh_cn.lua avatar/ # 玩家头像这套命名逻辑的好处有两个。第一牌面 ID 可以直接和逻辑层的牌类型映射比如后端下发“牌值 12”前端查一下卡表就能拼出card_12.png不用在 Lua 里做一大串分支判断。第二资源目录按用途隔离后续做热更新时只需要更新的子目录不会把特效和界面控件混在一起。命名上我要求所有文件名用小写下划线禁止中文和空格否则在部分打包工具里会出现资源丢失。定完目录后我会顺手在游戏子包入口写一个“资源预加载列表”把牌桌启动时必用的牌背、倒计时图标、结算面板提前加载避免玩家进桌时白屏。3. 十三水 UI 的核心玩法区块手牌区、墩位区、倒计时与结算面板3.1 十三水界面布局的区块拆分十三水的牌桌和斗地主完全不同。斗地主界面重心在“出牌区”而十三水的核心交互是“把 13 张手牌摆成前墩 3 张、中墩 5 张、后墩 5 张”。所以界面天然分成几个职责明确的区块顶部区显示房间号、庄家标记和玩家信息中间区域是对手状态和公共信息底部是手牌区玩家在这里完成摸牌、理牌、摆墩手牌区上方是墩位区三行分别对应前中后墩再往上一点是倒计时和操作按钮区比牌结束后弹出结算面板。每个区块都有独立的坐标系和生命周期。手牌区是动态区牌数从 0 到 13 变化墩位区是静态区但需要响应拖拽落点结算面板是弹层要遮挡点击并居中展示。我在拆 UI 时把每个区块都封装成独立的组件组件之间只通过事件通信比如手牌区拖牌完成就发一个on_drop_done事件墩位区接收后更新显示。这样后续改样式只会影响单个组件不会把整个牌桌脚本翻个底朝天。3.2 牌桌坐标排版13 张牌的三墩摆放计算牌桌排版最容易踩坑的是“牌的缩放比例”。十三水一桌最多同时显示十几张手牌如果按真实牌面 1:1 摆放低分辨率手机会把牌桌挤爆。我处理时先定一个基准牌尺寸再根据手牌数量动态计算牌间距让整组牌始终保持在安全区内。下面是一段常用的排版计算我把它放在手牌组件里每次手牌数量变化时就重算一次。-- hand_group.lua local CARD_W 90 -- 基准牌宽像素 local CARD_H 126 -- 基准牌高 local MAX_WIDTH 720 -- 手牌区最大可用宽度 local GAP_MIN 4 -- 最小牌间距 local function layout_hand(cards) local count #cards local gap GAP_MIN local total_w CARD_W * count gap * (count - 1) if total_w MAX_WIDTH then -- 牌太多先缩牌宽再缩间距 local scale MAX_WIDTH / (CARD_W * count) gap math.max(GAP_MIN * 0.5, scale * 10) total_w CARD_W * scale * count gap * (count - 1) return total_w, scale, gap end return total_w, 1.0, gap end这段代码的逻辑是先按完整牌宽和最小间距计算总宽度如果超出可用宽度就按比例缩小牌面同时把间距也压小。返回的三个值里scale用来设置牌节点的缩放gap用来依次摆放每一张牌total_w用于把整组手牌居中。参数MAX_WIDTH我是按安全区宽度减两边留白算出来的不是直接等于屏幕宽。留白一般左右各 20 像素防止牌边缘顶到屏幕外。排墩时的坐标计算要更细致。前墩 3 张、中墩 5 张、后墩 5 张三行左对齐或居中对齐都可以但必须保证三行的牌位置在视觉上是“墩”而不是“乱放的牌”。我用的办法是给三行各建一个容器节点行内按同样的间距摆放行与行之间的垂直间距固定为牌高的 0.35 倍。拖牌时监听手指位置判断落点落在哪个行容器范围就把牌移动过去并且让目标行的牌重新居中。这个逻辑看似简单但对齐判断的阈值要调落点判定区域不能太大否则牌会“粘”到错误的行上。3.3 倒计时与回合状态的 UI 联动十三水每个玩家操作时间有限倒计时 UI 是玩家体验里最容易出问题的一块。荣耀版里倒计时常见做法是本地定时器驱动进度条和数字更新但本地计时和服务器回合结束时间对不上时会出现“界面上还有 5 秒服务器已经判定超时”的体验落差。我在做这个模块时把倒计时拆成两个来源服务器下发的起始时间和剩余秒数本地只负责按帧刷新显示。-- countdown.lua local end_time 0 -- 服务器下发的回合结束时间戳 local function update_countdown(now) local remain end_time - now if remain 0 then label:set_text(0) progress:set_percent(0) on_timeout() -- 触发超时逻辑 return end label:set_text(string.format(%d, math.ceil(remain / 1000))) progress:set_percent(remain / total_duration * 100) end这里的核心是end_time必须来自服务器而不是本地“开始倒计时时记一个时间”算出来的。原因是本地设备时钟可能不准也可能在游戏切后台回来后时间被系统暂停。我用服务器时间戳的好处是哪怕断线重连只要重新拉一次end_time倒计时就自动校准了。倒计时刷新频率我用每帧更新数字变化是平滑的但为了省电也可以在剩余秒数变化时才刷新文字进度条每帧刷新即可。另一件容易被忽略的事是倒计时结束时要同步把操作按钮置灰并广播一个on_timeout事件给手牌区和墩位区让它们回到等待状态否则玩家会看到“倒计时没了但还能拖牌”的错觉。4. 动手落地最小可跑的十三水 UI 场景代码参数4.1 从 HALL 进游戏的一屏流程拿到荣耀版源码后我一般先不急着画界面而是先把“从大厅点按钮到看到牌桌”的最小链路跑通。这个链路里涉及 HALL 拉起游戏子包、子包加载场景、创建牌桌 UI 三个环节。HALL 那边通常已经写好了拉起游戏子包的接口我需要做的是在子包入口处把牌桌场景初始化好。-- game_enter.lua local function on_enter_game(game_id, room_id) -- 通知服务器进入房间 GameServer:enter_room(room_id, function(resp) if resp.code ~ 0 then Toast:show(进入房间失败) return end -- 创建牌桌场景 local scene DeskScene:new() SceneManager:switch_to(scene) -- 初始化手牌区、墩位区、倒计时组件 scene:init_ui_layout() scene:start_round(resp.round_data) end) end这段脚本的业务顺序是先向服务器请求进房拿到当前回合的牌局数据后再创建场景和 UI。注意DeskScene不能提前创建否则进房失败时会出现一个空牌桌卡在屏幕上。这里的resp.round_data包含玩家手牌、庄家位置、倒计时起点等信息UI 初始化依赖这些数据所以顺序不能颠倒。我在项目里看过有人把init_ui_layout放在进房请求之前结果请求失败后还是要手动销毁场景多写了一段处理完全没必要。4.2 牌桌场景分辨率适配与安全区处理荣耀版默认设计分辨率是标屏但市场上手机屏幕比例从 16:9 到 20:9 都有。直接按标屏摆牌桌的后果是宽屏手机上左右两侧出现大片空白或者上下被拉伸变形。我采用的适配策略是“等比缩放 居中显示”理想情况下的最大可视区域不够时用黑边或背景图填充而牌桌的核心操作区始终保持在安全区范围内。-- adapter.lua local DESIGN_W 1280 local DESIGN_H 720 local function calc_safe_area(real_w, real_h) local scale_w real_w / DESIGN_W local scale_h real_h / DESIGN_H local scale math.min(scale_w, scale_h) -- 取小值保证不拉伸变形 local view_w DESIGN_W * scale local view_h DESIGN_H * scale local offset_x (real_w - view_w) / 2 local offset_y (real_h - view_h) / 2 return scale, offset_x, offset_y end这里的逻辑是分别计算宽和高的缩放比取较小值作为统一缩放这样画面不会变形。offset_x和offset_y是把设计坐标系平移到真实屏幕居中位置的偏移量。我在设置牌桌根节点时会把这个偏移量加到节点位置并把根节点的锚点设为(0.5, 0.5)。安全区的处理上顶部要留出系统状态栏和刘海底部要避开 Android 虚拟按键所以偏移量在y轴方向还会额外加上一个“底部安全高度”参数不同机型这个值不同我从系统接口读取而不是写死。这里有一个容易忽略的细节特效节点和结算弹层也要走同一套缩放和偏移不能单独用绝对坐标。特效尤其明显在标屏上居中的特效到了全面屏上如果不随根节点走就会明显偏上或偏下。我通常把特效挂在牌桌根节点下而不是屏幕层这样适配代码只写一份。4.3 发牌、亮墩、比牌三段动画的状态机十三水一局里最影响手感的是三段动画发牌、亮墩、比牌。发牌动画要求连贯不能一张一张生硬跳出来亮墩是玩家按下“确定”后三墩牌依次翻开比牌是最后公示各家牌型并显示输赢。这三段如果用临时的 if 嵌套写很快会卡在动画回调的层层嵌套里。我用的方案是一个简单的状态机每个状态对应一个动画阶段。-- desk_anim.lua local STATE_DEAL 1 local STATE_SHOW 2 local STATE_COMPARE 3 local current_state STATE_DEAL local function on_anim_done() if current_state STATE_DEAL then current_state STATE_SHOW play_show_anim() elseif current_state STATE_SHOW then current_state STATE_COMPARE play_compare_anim() else current_state nil on_round_end() end end local function play_deal_anim() current_state STATE_DEAL -- 逐张发牌每张间隔 80ms -- 所有牌发完回调 on_anim_done end代码里每个状态结束后调用on_anim_done进入下一个状态。这样做的好处是动画卡在哪一步、玩家在哪个阶段点了退出都能通过current_state精准判断。参数上发牌间隔我用 80ms太短没节奏太长玩家等待明显亮墩每墩之间间隔 150ms突出“前中后”的顺序比牌动画则用固定时长 400ms太快看不清楚输赢原因太慢影响下一局节奏。三个时间参数我建议都收进“动画配置表”方便不同渠道的包体单独调而不是散落在各脚本里。需要额外注意的是动画播放期间必须锁住手牌区的触摸。否则玩家在发牌过程中拖牌会出现牌被拖到一半又被动画拉回原位的鬼畜现象。我在状态机里加了is_locked标志触摸事件在STATE_DEAL和STATE_COMPARE时直接拦截只有STATE_SHOW之后才交给手牌区处理。这个标志位别漏十三水 UI 翻车重灾区基本都在这。5. 荣耀版十三水 UI 开发避坑5 个让我返工过的实际问题5.1 现象替换素材后花屏或透明块项目里美术给了一套新牌面我直接丢进资源目录后测试机上牌面显示出一块块紫黑色或完全透明。原因不是素材本身坏了而是荣耀版的图片加载对格式有要求有些设计给的 PNG 是 32 位带预乘 Alpha直接加载会和引擎的混合模式冲突导致颜色发花或边缘透明。解决办法是统一把素材转成引擎默认格式我一般会写一个批处理脚本把所有牌面统一转成 RGBA8888 的 PNG并且强制去掉 PNG 里多余的色彩空间信息。另外新素材的尺寸最好和原图一致否则布局里按原尺寸计算的牌间距会错位图片明显偏大或偏小。5.2 现象高分屏下牌局元素错位在 1080p 上调试好的牌桌换到 2K 屏上手牌区整体右移了倒计时数字也半截出了屏幕。查下来是代码里有一部分控件的坐标直接用了物理像素另一部分用了逻辑坐标混在一起后高分屏被放大的倍数不一致元素就错位了。解决方法很朴素牌桌根节点走适配缩放后所有子节点一律用设计分辨率下的逻辑坐标不要再乘屏幕比例。我会在代码评审时专门检查有没有写pos_x 屏幕宽度 * 0.8这类公式一旦发现就改成基于设计宽度计算再交给根节点统一缩放。5.3 现象倒计时与服务器不同步测试时发现玩家手机上的倒计时还剩 3 秒但服务器已经判定超时踢出了房间。原因是我一开始用“进房时本地时间 固定时长”来算结束时间玩家切到后台或者系统时间被调整后倒计时就失真了。改成以服务器下发的结束时间戳为准并且在每次收到服务器任何回合消息时都重置一次倒计时问题就消失了。另一个隐藏点是服务器下发的剩余秒数有时是向上取整有时是向下取整需要和后端约定统一口径否则会差 1 秒显示误差玩家会盯着数字较真。5.4 现象iOS 上内存持续上涨跑了几局十三水后iOS 设备内存涨了快 200MB随后被系统杀进程。排查发现是牌面资源在每局开始时都重新加载了一次上一局的图片节点虽然被移出场景但 Lua 侧的引用没断导致引擎无法释放。解决方法是两个牌面这种高频资源做常驻缓存一局结束只释放特效和结算面板的临时资源另外手牌区的牌节点用一个“对象池”管理牌回收后复用节点而不是每次新建。对象池的实现不复杂就是维护一个可用节点列表取牌时先看池子里有没有空闲的有就从池子拿没有才创建。5.5 现象点击被特效层挡住比牌动画播放完后玩家点击“下一局”按钮没反应但过几秒又能点了。原因是比牌动画的特效节点播放完后节点本身没有自动销毁而且它创建的时间最晚层级最高挡住了按钮的触摸事件。解决方法是给特效节点设置一个“是否接收触摸”的开关播放动画前打开动画结束后关闭并延迟到回调里再销毁节点。我后来在特效组件的通用基类里强制加了销毁回调只要特效结束就必须走统一的回收流程触摸穿透问题基本就不复现了。6. 一个验证习惯用“四指滑动”检查十三水 UI 的触摸与动画并发荣耀版十三水 UI 最容易出问题的都不是静态效果而是“动画和触摸同时发生时”的状态。所以我把一个验证动作固定成了习惯每次改完牌桌布局或动画参数后先在模拟器上打开帧率监控然后同时用四个手指在屏幕上做不同的操作——一根手指拖手牌、一根手指点倒计时按钮、一根手指在结算面板区域快速点击再一根手指来回滑动牌桌背景。这个动作能暴露三类问题触摸事件被最高层节点吃掉的穿透问题、动画播放中事件响应被卡住的问题、以及高并发节点创建时掉帧的问题。验证时我看四个指标第一是帧率是否掉到 25 以下第二是倒计时数字是否出现跳跃第三是拖牌时牌是否出现“跳一下才跟手”的迟滞第四是特效播放完是不是所有按钮立刻能点。任何一个指标不对就缩小范围定位。顺手还会开一下框架自带的节点树调试面板看当前场景里节点数量有没有异常增长——如果比牌结束后节点数比开局时多出几十个说明资源没释放。这个排查步骤不复杂但能拦住大部分线上才会暴露的交互问题。另一条长期养成的习惯是每次调完分辨率适配我都拿三个不同比例的测试机过一遍一个 16:9、一个 19.5:9、一个带底部虚拟按键的。荣耀版的标屏适配很容易在“刚好压住安全区边界”的地方出问题只有真实机型才能暴露。被十三水的 UI 适配翻过车之后我现在改动任何牌桌布局第一件事都是把安全区上下边界的牌位置写进自查清单而不是等测试提 bug。希望这些从框架结构到动画状态的思路能帮你在荣耀版上做十三水 UI 时少走几趟弯路。本文还有配套的精品资源点击获取