简介这份资源是基于ET4.0框架开发的斗地主Demo面向希望快速上手ET游戏服务器框架的初中级开发者。包内共10487个文件以cs脚本、meta资源、bin与dll编译产物、png界面素材、xml配置与文档等类型为主整体约81.99MB压缩包包含Server服务器端代码、Unity客户端工程、Proto协议定义、使用说明及构建目录便于对照学习分布式部署、网络通信、热更新与Unity客户端接入等关键环节。资源目前已有1133人学习浏览。通过学习该Demo可理解ET框架的Actor模型与事件驱动机制掌握服务器与客户端的代码组织方式熟悉协议定义及热更新流程适合作为从理论转向实际游戏开发的重要练习项目。1. 基于ET框架的斗地主Demo一次把服务端架构和联机流程讲透的实战想做斗地主联机Demo选ET框架的理由很直接它把客户端和服务器用同一套C#语言、同一套ECS架构组织起来写服务端逻辑和写客户端逻辑用的是同一批思维模型开发效率比传统TCP回调的写法高出一截。这个Demo不是做个单机发牌动画而是要把匹配、建房、发牌、出牌、结算这条完整链路跑通让两台设备能真实对战。适合的人群是已经跑通过Unity基础教程、想进入联机游戏开发但又不满足于只写个“收发消息”的例子、打算用ET框架做正式项目的团队或个人。这篇文章从框架核心概念讲起落地到具体的代码和命令最后把那些文档里不会写的坑都整理出来。2. ET框架的底层逻辑为什么斗地主这种玩法天然适合ECS加Actor模型2.1 ECS架构里的“地主”“农民”“牌桌”分别是谁ET框架的核心是Entity-Component-System。要理解这个你先忘掉Unity里GameObject挂MonoBehaviour的习惯。在ET里一个Entity就是一个有Id的对象Component是挂在Entity上的数据片段System是处理这些数据的逻辑。斗地主里牌桌是一个Entity玩家是一个Entity每张牌也可以是一个Entity——但实际项目中牌不会建Entity那样太浪费牌用Component或普通数据结构去存更合理。写ET代码时你的习惯要改成“先想清楚谁是什么再想谁挂什么数据”。比如Player Entity挂一个HandCardsComponent字段是List 存牌的编号再挂一个PlayerStateComponent字段是枚举记录当前是叫地主、出牌还是旁观。逻辑则放在System里比如出牌校验这样的纯逻辑方法可以做成一个静态方法也可以挂到某个System上。ET的框架代码把这些组织得很规整新手最怕的就是拿到项目不知道从哪下手我的建议是先读Entity、Component这两个基类再读一个完整的消息处理流程比如登录流程把“Entity发消息→服务器收到→处理→回消息→客户端收到→处理”这条链路读明白再去动业务代码。有一件事必须提醒你ET框架的文档版本迭代很快网上很多教程基于ET5.0或更早版本而当前主流的ET6.0以上版本目录结构大变。你搜到的很多“ET框架详解”里的代码路径已经对不上了。我在下文写到的路径以ET6.x为参照如果你用的是其他版本路径需自行调整这一点后面“避坑章节”会再展开。2.2 Actor模型如何承载“房间”这种天然隔离的玩法斗地主的一个显著特点是每一局游戏是一个独立的房间房间内的玩家只关心自己房间内的牌局状态房间与房间之间不需要频繁通信。这正好是Actor模型的用武之地。ET框架中每个Actor有一个唯一的ActorId消息发到ActorId上Actor内部串行处理。你在服务器上开一个房间这个房间就是一个Actor玩家加入房间其实是把自己的消息绑定到房间这个Actor上。出牌、叫地主、抢地主这些消息都发给房间Actor房间Actor按状态机推进牌局。这样设计的好处是你不需要自己去写加锁逻辑。多个玩家同时操作例如三个农民同时点击出牌服务器收到消息后是串行处理的不会出现两个玩家同时改变了手牌数据导致内存冲突。这一点看着简单实际写起来很值钱——传统多线程网络模型里处理房间内共享数据要小心翼翼的加锁出牌、加倍、托管这些操作同时触发时很容易出并发bug。Actor模型把并发复杂度降到零。在实际开发中房间Actor内部通常还挂着一些组件。比如TimerComponent用来处理出牌超时如果玩家20秒不操作自动出最小的牌再比如GameStateComponent记录当前是叫地主阶段还是出牌阶段。ET的Actor模型天然支持这种组合你把需要的Component往房间Entity上一挂逻辑就齐了。2.3 事件系统和双端共用代码怎么影响斗地主的逻辑组织ET框架的事件系统是一个发布订阅模型。客户端和服务器都可以发事件、监听事件。斗地主里的典型场景客户端收到服务器广播的“有玩家出了牌”消息在UI层弹一个出牌动画。动画播完需要通知逻辑层“动画结束可以更新手牌区域了”。这类时序问题用事件系统处理很舒服。事件系统落实到代码里形如某个类继承EventHandler监听一个自定义事件在另一个地方调用EventSystem.Instance.Send()。ET的发布订阅是同步的也就是说Send之后监听者立刻执行。如果你需要异步等待比如“等动画播完再执行下一步”ET6提供了协程支持用 async/await 配合 ETTask 可以实现。这里不是草率设计而是你可以利用协程在出牌动画的代码里直接写 await TimeComponent.WaitAsync(动画时长)再执行后续逻辑。这一下就避开了“回调地狱”。双端共用代码是ET框架的另一大特点。你定义的消息结构体、常量的枚举、工具方法放在一个共享程序集里客户端和服务器都能引用。斗地主里的牌型判断——单张、对子、三带一、顺子、炸弹——这类纯逻辑函数放在共享代码里客户端做“预校验”提醒玩家“这手牌出不了”服务器做“权威校验”防作弊两端用同一套逻辑不会出现“客户端觉得能出、服务器觉得不能出”的尴尬局面。3. 用ET框架在本地把最小可玩链路跑通从拉代码到首次登录3.1 拉取源码与目录结构先搞清楚你拿到手的是什么ET框架本体在GitHub上有开源仓库你需要通过Git把代码拉下来。常见做法是拉取发布分支或某个Release标签而不是最新master——最新代码往往处于重构中跟着跑容易中途撞上未知问题。以ET6.x为例拉到本地后你会看到几个关键目录UnityUnity工程、Server服务器工程、Share共享代码。还有启动器相关的工程用于启动服务器进程。拉取命令大致如下git clone --recursive https://github.com/egametang/ET.git cd ET git checkout 某个Release标签 git submodule update --init --recursive参数说明--recursive 是为了拉取子模块ET框架依赖了一些子模块代码不拉子模块会导致编译缺文件checkout到某个Release标签是因为ET一直在重构不同版本之间目录结构差别很大网上很多教程的代码路径是基于特定版本写的你锁定版本后对照教程才不会踩“文件找不到”的坑。3.2 用命令行编译并启动服务器进程在Windows下进入Server目录找到对应的sln解决方案文件用Visual Studio打开。首次编译会还原NuGet包耗时比较长需要耐心等。编译产物会在Server/Bin目录下生成里面是一批dll和exe。启动服务器不需要手动一个个点击exeET框架在开发模式下通常是先启动一个名为“启动器”的控制台进程它会按配置拉起多个子进程比如负责登录的进程、负责房间逻辑的进程。常见做法是在Visual Studio里把启动器项目设为启动项目直接F5运行。如果你更习惯命令行方式也可以这样做cd Server/Bin dotnet App.dll --AppTypeLauncher --AppId1参数说明--AppTypeLauncher 表示以启动器身份运行它会读取配置并拉起其他子进程--AppId1 是当前进程的编号每个进程都要有一个唯一AppId用于进程间通信和消息路由。启动成功后控制台会打印各子进程的启动日志看到类似“Start Init OK”这样的输出基本可以确认服务器层起来了。3.3 在Unity端连接服务器改一个地址和端口打开Unity工程后先确认ET框架要求的最低Unity版本。ET6.x通常需要2020.3或更高版本用太老的Unity版本会直接编译报错。Unity工程里有一个初始化场景场景里有一个全局的Game对象上面挂着模式选择组件你可以把当前模式设为开发模式Development并在配置里填上服务器IP和端口。这个步骤最简单也最容易翻车。很多人卡在“连不上服务器”排查下来是填了localhost但手机或另一台电脑访问时并没有把IP改成局域网地址。正确做法是同一局域网下把IP填成运行服务器那台机器的局域网IP比如192.168.1.100而不是127.0.0.1。如果你在云服务器上跑填公网IP还要确认防火墙和云安全组放行了对应端口ET默认的端口从10000往后比较多具体看配置文件。3.4 跑通第一对消息从登录按钮到服务器回复现在你有了一个能跑的服务器和一个能连上服务器的Unity客户端。下一步就是把登录消息跑通。ET框架的消息定义在共享代码中用Proto格式定义。登录相关的消息大致是这样的message C2R_Login // 客户端发给服务器请求登录 { string Account 1; string Password 2; } message R2C_Login // 服务器返回登录结果 { int32 Error 1; string Message 2; string Token 3; }字段说明这里的数字1、2、3是字段编号用于Protobuf序列化时识别字段不能重复修改字段名不影响协议兼容性但修改字段编号会破坏兼容性。Error为0表示成功非0表示失败具体错误码表需要约定好。Unity端点击登录按钮后的代码逻辑大致如下这是一个简化版的调用方式// 发送登录请求的Demo代码客户端侧 async ETTask OnLoginBtnClick() { // 构建请求消息 C2R_Login request new C2R_Login(); request.Account accountInput.text; request.Password passwordInput.text; // 通过Session发送并等待响应 R2C_Login response (R2C_Login)await session.Call(request); if (response.Error ! 0) { Log.Error($登录失败: {response.Message}); return; } // 保存Token后续进入游戏流程会用到 PlayerPrefs.SetString(token, response.Token); // 登录成功切换到游戏场景 await SceneManager.LoadSceneAsync(GameMain); }代码说明session.Call是一个请求响应模式的方法底层会发送消息并挂起协程等待响应直到服务器返回才继续往下执行。这种写法比注册回调的方式直观很多。这里使用的session是当前客户端到服务器的一条逻辑连接。调用前要确保session已经完成连接步骤否则会抛出异常。这套最小链路跑通后你就有了一个“客户端发消息→服务器处理→客户端收到响应”的闭环接下来做斗地主玩法都是在这个闭环之上扩展。每次加新功能前先确认这个闭环还在开发效率会稳得多。4. 斗地主核心玩法落地房间、发牌、出牌与结算的代码实现4.1 房间管理与匹配逻辑三个玩家凑一桌的过程是怎么写的斗地主的第一个核心是“凑齐三个人”。你可以做最简单的匹配逻辑玩家点击“开始匹配”后服务器把他加入一个匹配队列当队列里人数达到3人时创建一个房间Actor把三个玩家加入房间。这里用ET框架的Actor模型实现起来很干净。服务器端的伪代码如下// 当匹配队列人数达到3人创建房间并分配玩家 public static async ETTaskRoom CreateRoomForThreePlayers(ListPlayer players) { Room room EntityFactory.CreateWithIdRoom(Game.Scene, IdGenerater.GenerateId()); room.AddComponentDeckComponent(); // 牌堆 room.AddComponentGameStateComponent(); // 游戏状态叫地主-出牌-结算 room.AddComponentTimerComponent(); // 出牌计时 for (int i 0; i players.Count; i) { // 将玩家加入房间分配座位号0、1、2 await room.AddPlayer(players[i], i); } // 通知所有玩家房间已创建 M2C_RoomCreated roomCreatedMsg new M2C_RoomCreated(); roomCreatedMsg.RoomId room.Id; room.Broadcast(roomCreatedMsg); return room; }代码说明EntityFactory.CreateWithId创建了一个新的房间实体AddComponent挂上所需要的组件让牌堆、游戏状态、计时逻辑各司其职。把创建房间和加入玩家分开是为了复用——比如以后做“好友开房”可以直接创建房间再邀请好友加入不必走匹配队列。这里的AddPlayer内部还需要给每个玩家生成一个座位号。座位号在斗地主玩法里很重要因为叫地主是轮流按座位号来的出牌顺序也是按座位号循环。实现时用一个简单的取模算法即可当前出牌玩家座位号 (上个出牌玩家座位号 1) % 3。4.2 发牌逻辑洗牌、发牌与手牌的序列化传输斗地主的牌是一副54张的扑克牌用0到53编号其中52、53是大小王。洗牌用Fisher-Yates算法这是概率均匀且实现简单的经典做法。发牌时按座位号轮流各发17张留3张底牌。底牌在叫地主结束后归地主所有。洗牌和发牌的代码可以放在共享代码中因为客户端做“预展示”时可能也需要知道某副牌长什么样。代码如下// 洗牌并返回一副乱序的牌组 public static Listint ShuffleCards() { Listint cards new Listint(); for (int i 0; i 54; i) { cards.Add(i); } // Fisher-Yates洗牌 Random random new Random(); for (int i cards.Count - 1; i 0; i--) { int j random.Next(i 1); (cards[i], cards[j]) (cards[j], cards[i]); } return cards; }代码说明洗牌逻辑的位置放在共享代码里有一个直接好处以后做“观战”或者“回放”功能客户端可以本地重放某一局不需要服务器把每一张牌的数据都传过来只需传一个种子数然后客户端用同样的洗牌算法生成同样的牌序。这比传整副牌省流量。发牌后服务器需要把“各玩家的手牌”和“底牌”广播给客户端。这里的消息字段设计要留意不能只发“我的手牌”还要发玩家的座位号客户端才能在自己的UI上把三家玩家的手牌显示在对应的位置自己的牌在下方左右玩家只显示数量。消息结构大致是每个玩家一个PlayerCards字段内容为手牌数组。一个容易忽视的细节牌的数据用int列表传序列化出来体积很小但在客户端做UI绑定时手牌通常需要排序所以客户端拿到牌后要先排序再绑定到UI。这个排序逻辑也建议放在共享代码里保证排序规则一致——比如从大到小排列牌型分析时就不用关心顺序了。4.3 出牌校验与出牌广播服务器永远是正确的裁判出牌阶段是状态机最复杂的部分。每个玩家出牌时服务器要做两件事第一校验玩家出的牌是否符合牌型规则第二校验是否大过上家。这两步一个都不能少少了就会有人作弊打出非法牌型。牌型判断是斗地主最核心的纯逻辑。常见做法是写一个PokerHelper静态类提供方法如bool CheckCardType(Listint cards)和bool CompareCards(Listint curCards, Listint lastCards)。这里不展开所有牌型只展示一个关键逻辑——炸弹的判断与比较因为炸弹的处理特殊既属于牌型校验又影响倍率// 判断是否为炸弹四张点数相同的牌 public static bool IsBomb(Listint sortedCards) { if (sortedCards.Count ! 4) { return false; } int firstValue GetCardValue(sortedCards[0]); for (int i 1; i 4; i) { if (GetCardValue(sortedCards[i]) ! firstValue) { return false; } } return true; }代码说明GetCardValue把牌的编号0到53映射为点数3到2再到大小王这种映射关系需要在工具类里统一定义。炸弹的判断逻辑很简单但在校验“是否能压过上家”时炸弹是跨牌型参与比较的唯一特例普通牌型只能压同牌型而炸弹可以压任何牌型两个炸弹相遇时再比较点数。这个特判逻辑千万别漏。服务器校验通过后将出牌消息广播给房间内所有玩家。这里建议广播一条统一的消息包含出牌者座位号、出的牌列表、以及剩余手牌数量这样客户端拿到消息后知道怎么更新界面。这里有一个设计决策需要提前做要不要广播手牌的具体内容我的建议是——公开自己的出牌即可不要广播未出的手牌防止玩家通过内存查看器作弊。其他玩家只需要看到“剩了5张”即可之后“报单”提示也是基于剩余数量做的。4.4 胜负结算农民与地主各拿各的分倍率怎么累加斗地主结算的核心是积分计算。默认一局基础分是1分叫地主加倍、抢地主加倍、炸弹加倍、春天加倍。这些倍率需要在游戏过程中不断累加存于房间的GameStateComponent中。结算逻辑伪代码如下// 结算isLandlordWin表示地主是否赢了 public static SettlementInfo CalculateSettlement(GameStateComponent state, bool isLandlordWin) { int baseScore state.BaseScore; // 基础分比如1 int multiplier state.Multiplier; // 当前累计倍数 int landlordScore 0; int farmerScore 0; if (isLandlordWin) { landlordScore baseScore * multiplier * 2; // 地主赢两家 farmerScore -baseScore * multiplier; } else { landlordScore -baseScore * multiplier * 2; farmerScore baseScore * multiplier; } SettlementInfo info new SettlementInfo(); info.LandlordScore landlordScore; info.FarmerScores farmerScore; // 两家农民各得该分 return info; }参数说明state.BaseScore是底分通常为1也可以做成一局内的变量由房间创建者配置state.Multiplier在每次叫地主、抢地主、炸弹打出时累加这个累加时机需要注意必须在动作生效时立刻更新不要在结算时才统一算否则容易漏算。结算后通知所有玩家的消息里要带每个玩家的最终得分和当前的倍率列表客户端做结算界面的展示。5. 避坑与排查ET框架做斗地主时最常遇到的5个坑5.1 实体ID对不上消息发到了不存在的玩家身上现象服务器统计日志时发现某些“出牌”消息被路由到了已退出的玩家导致房间内其他玩家卡在等待状态。原因ET框架的实体有一个InstanceId一个实体销毁后Id可能被复用或者消息里存的还是旧的实体ID。常见于玩家断线重连后旧的实体被销毁、新的实体被创建但房间内广播列表没有更新。解决确保在玩家加入房间和退出房间时都更新房间内的玩家实体引用列表。断线重连逻辑要单独做重连时通过Token找到玩家的新实体再把它重新挂到原来的房间下。我的习惯是所有消息处理前先校验实体是否存在不存在则直接丢弃并打印告警日志。5.2 手牌集合用List存储移除多张牌时索引越界现象玩家一次性出了多张牌比如顺子或者飞机服务器移除手牌时抛异常把整个出牌流程打断。原因用for循环遍历List并从List中Remove元素删除前面的元素后后续元素的索引改变了导致越界。解决不要边遍历边删除。推荐做法是先把要出的牌收集到一个HashSet中然后一次性重建剩余手牌列表。代码如下// 从手牌中移除指定的牌 public static Listint RemoveCards(Listint handCards, Listint cardsToRemove) { HashSetint removeSet new HashSetint(cardsToRemove); Listint result new Listint(handCards.Count); for (int i 0; i handCards.Count; i) { if (!removeSet.Contains(handCards[i])) { result.Add(handCards[i]); } } return result; }代码说明这里为了避免重复牌的问题手牌里有两张5你只出了一张5实际项目中不能用HashSet直接去重而是要把每张牌当作“一个可区分个体”用“牌编号手牌下标”或记录每张牌唯一标识的方式处理。更简单可靠的做法是遍历原手牌逐张标记被移除的牌而不是用值去重。这一点需要特别小心否则会出现“两张同点数只移除了一张”的隐患。5.3 出牌轮转逻辑写错导致玩家乱序出牌现象某个玩家出牌后下一个轮到的玩家不对有时候跳过一个玩家有时候又回到自己。原因轮转逻辑用了固定顺序而斗地主里存在“农民一伙、地主单独”的特殊轮转规则当某个玩家出牌后其他两家如果都不要则这个玩家重新出牌。没有保存“当前最大牌是谁出的”这个状态。解决在GameStateComponent里增加LastPlaySeat和LastPlayCards字段每次出牌时更新这两个字段。当两个玩家连续选择“不出”后轮转重置为LastPlaySeat出牌。5.4 客户端动画节奏没处理导致UI状态和服务器状态不一致现象收到服务器广播的出牌消息后客户端立刻更新手牌UI但出牌动画还没播完玩家已经点了下一手牌导致UI显示和最终逻辑结果对不上。原因客户端逻辑直接依赖服务器消息驱动UI没有做一个“动画期间禁用操作”的缓冲。解决在客户端加一个简单的状态锁。收到出牌广播后先播动画动画播完前禁止玩家点击任何操作按钮动画播完后解锁并刷新UI。实现可以用ET的协程工具出牌动画的代码前面已经提到过await一个动画时长即可。5.5 压测时内存只升不降服务器运行几小时就卡死现象多开客户端跑了一晚上服务器进程占用的内存在持续增加最后操作卡顿。原因ET框架的日志系统在开发模式会打印全量日志而日志写到内存中未及时释放另外有些事件订阅后没有反订阅Unsubscribe导致已经销毁的实体还在被事件系统引用内存无法回收。解决开发模式下临时把日志级别调高比如只输出Error以上日志同时在实体销毁的Dispose方法中把该实体订阅过的所有事件都取消订阅。这两种做法能显著降低内存泄漏风险。正式压测前先用小规模客户端跑半小时观察内存曲线是否平稳是判断泄漏的快速方法。6. 进阶验证与优化从Demo走向可长期维护的小项目Demo跑通后还有几步能拉开差距。第一个是压测至少开10个客户端进程同时匹配、同时出牌观察服务器的CPU、内存和消息延迟。ET框架自带一些性能统计工具你可以把每轮出牌的服务器处理耗时打印出来。正常情况下一次出牌消息从收到到广播给三个客户端耗时应该低于10毫秒如果高于50毫秒说明逻辑里有阻塞或过重的同步操作优先排查日志打印和数据库操作。第二个是日志的规范化。开发调试时把关键业务日志打全但发布后只保留登录、创建房间、结算这类关键操作日志出牌日志可以降级为Debug级别否则磁盘撑不住。ET框架的日志系统支持按级别过滤这个配置花十分钟就能学会性价比很高。第三个是断线重连。Demo阶段可以不处理断线但要做到可演示的完整程度至少要保证玩家在出牌过程中断线服务器等待10秒后自动代打自动出最小的牌并且玩家重连后能回到原房间继续游戏。这个功能一开始就考虑能为你后续做正式项目省下大量重构时间。代打逻辑代码量不大但对框架理解的提升很有效。第四个是客户端表现层的优化。比如手牌拖动、出牌飞行动画、提示“要不起”的按钮置灰这些做得细不细直接决定别人看了Demo之后觉得“这是个玩具”还是“这已经像产品了”。我见过不止一个团队服务端逻辑完善但Demo的UI停留在“按钮文字”展示时观感差很多。斗地主的交互表现在手牌排序动画和出牌飞行动画上你花一周时间打磨这两个细节比加十个功能都有效。做这个Demo我的经验是把“验证框架和学习成本”当作第一目标不要一味堆功能。我早期做某个联机Demo时花了太多时间在复杂的匹配算法上结果基础消息链路反而不稳展示时频频出状况。后来收敛目标先把三人在同一房间里完整打一局跑通再逐步加匹配、加托管、加重连路反而走得更顺。最后分享一个我的个人习惯每次写完一关键节点比如发牌、出牌校验、结算我都会用两个客户端实测三个玩家的完整对局并在本子上记录每步操作后的界面状态。很多“玄学”问题最后查出来都是服务器广播了消息但客户端刷新逻辑漏写了。养成把消息流和UI状态对应起来的调试习惯你后面做任何联机功能都会顺很多。希望帮到你。本文还有配套的精品资源点击获取
简介这份资源是基于ET4.0框架开发的斗地主Demo面向希望快速上手ET游戏服务器框架的初中级开发者。包内共10487个文件以cs脚本、meta资源、bin与dll编译产物、png界面素材、xml配置与文档等类型为主整体约81.99MB压缩包包含Server服务器端代码、Unity客户端工程、Proto协议定义、使用说明及构建目录便于对照学习分布式部署、网络通信、热更新与Unity客户端接入等关键环节。资源目前已有1133人学习浏览。通过学习该Demo可理解ET框架的Actor模型与事件驱动机制掌握服务器与客户端的代码组织方式熟悉协议定义及热更新流程适合作为从理论转向实际游戏开发的重要练习项目。1. 基于ET框架的斗地主Demo一次把服务端架构和联机流程讲透的实战想做斗地主联机Demo选ET框架的理由很直接它把客户端和服务器用同一套C#语言、同一套ECS架构组织起来写服务端逻辑和写客户端逻辑用的是同一批思维模型开发效率比传统TCP回调的写法高出一截。这个Demo不是做个单机发牌动画而是要把匹配、建房、发牌、出牌、结算这条完整链路跑通让两台设备能真实对战。适合的人群是已经跑通过Unity基础教程、想进入联机游戏开发但又不满足于只写个“收发消息”的例子、打算用ET框架做正式项目的团队或个人。这篇文章从框架核心概念讲起落地到具体的代码和命令最后把那些文档里不会写的坑都整理出来。2. ET框架的底层逻辑为什么斗地主这种玩法天然适合ECS加Actor模型2.1 ECS架构里的“地主”“农民”“牌桌”分别是谁ET框架的核心是Entity-Component-System。要理解这个你先忘掉Unity里GameObject挂MonoBehaviour的习惯。在ET里一个Entity就是一个有Id的对象Component是挂在Entity上的数据片段System是处理这些数据的逻辑。斗地主里牌桌是一个Entity玩家是一个Entity每张牌也可以是一个Entity——但实际项目中牌不会建Entity那样太浪费牌用Component或普通数据结构去存更合理。写ET代码时你的习惯要改成“先想清楚谁是什么再想谁挂什么数据”。比如Player Entity挂一个HandCardsComponent字段是List 存牌的编号再挂一个PlayerStateComponent字段是枚举记录当前是叫地主、出牌还是旁观。逻辑则放在System里比如出牌校验这样的纯逻辑方法可以做成一个静态方法也可以挂到某个System上。ET的框架代码把这些组织得很规整新手最怕的就是拿到项目不知道从哪下手我的建议是先读Entity、Component这两个基类再读一个完整的消息处理流程比如登录流程把“Entity发消息→服务器收到→处理→回消息→客户端收到→处理”这条链路读明白再去动业务代码。有一件事必须提醒你ET框架的文档版本迭代很快网上很多教程基于ET5.0或更早版本而当前主流的ET6.0以上版本目录结构大变。你搜到的很多“ET框架详解”里的代码路径已经对不上了。我在下文写到的路径以ET6.x为参照如果你用的是其他版本路径需自行调整这一点后面“避坑章节”会再展开。2.2 Actor模型如何承载“房间”这种天然隔离的玩法斗地主的一个显著特点是每一局游戏是一个独立的房间房间内的玩家只关心自己房间内的牌局状态房间与房间之间不需要频繁通信。这正好是Actor模型的用武之地。ET框架中每个Actor有一个唯一的ActorId消息发到ActorId上Actor内部串行处理。你在服务器上开一个房间这个房间就是一个Actor玩家加入房间其实是把自己的消息绑定到房间这个Actor上。出牌、叫地主、抢地主这些消息都发给房间Actor房间Actor按状态机推进牌局。这样设计的好处是你不需要自己去写加锁逻辑。多个玩家同时操作例如三个农民同时点击出牌服务器收到消息后是串行处理的不会出现两个玩家同时改变了手牌数据导致内存冲突。这一点看着简单实际写起来很值钱——传统多线程网络模型里处理房间内共享数据要小心翼翼的加锁出牌、加倍、托管这些操作同时触发时很容易出并发bug。Actor模型把并发复杂度降到零。在实际开发中房间Actor内部通常还挂着一些组件。比如TimerComponent用来处理出牌超时如果玩家20秒不操作自动出最小的牌再比如GameStateComponent记录当前是叫地主阶段还是出牌阶段。ET的Actor模型天然支持这种组合你把需要的Component往房间Entity上一挂逻辑就齐了。2.3 事件系统和双端共用代码怎么影响斗地主的逻辑组织ET框架的事件系统是一个发布订阅模型。客户端和服务器都可以发事件、监听事件。斗地主里的典型场景客户端收到服务器广播的“有玩家出了牌”消息在UI层弹一个出牌动画。动画播完需要通知逻辑层“动画结束可以更新手牌区域了”。这类时序问题用事件系统处理很舒服。事件系统落实到代码里形如某个类继承EventHandler监听一个自定义事件在另一个地方调用EventSystem.Instance.Send()。ET的发布订阅是同步的也就是说Send之后监听者立刻执行。如果你需要异步等待比如“等动画播完再执行下一步”ET6提供了协程支持用 async/await 配合 ETTask 可以实现。这里不是草率设计而是你可以利用协程在出牌动画的代码里直接写 await TimeComponent.WaitAsync(动画时长)再执行后续逻辑。这一下就避开了“回调地狱”。双端共用代码是ET框架的另一大特点。你定义的消息结构体、常量的枚举、工具方法放在一个共享程序集里客户端和服务器都能引用。斗地主里的牌型判断——单张、对子、三带一、顺子、炸弹——这类纯逻辑函数放在共享代码里客户端做“预校验”提醒玩家“这手牌出不了”服务器做“权威校验”防作弊两端用同一套逻辑不会出现“客户端觉得能出、服务器觉得不能出”的尴尬局面。3. 用ET框架在本地把最小可玩链路跑通从拉代码到首次登录3.1 拉取源码与目录结构先搞清楚你拿到手的是什么ET框架本体在GitHub上有开源仓库你需要通过Git把代码拉下来。常见做法是拉取发布分支或某个Release标签而不是最新master——最新代码往往处于重构中跟着跑容易中途撞上未知问题。以ET6.x为例拉到本地后你会看到几个关键目录UnityUnity工程、Server服务器工程、Share共享代码。还有启动器相关的工程用于启动服务器进程。拉取命令大致如下git clone --recursive https://github.com/egametang/ET.git cd ET git checkout 某个Release标签 git submodule update --init --recursive参数说明--recursive 是为了拉取子模块ET框架依赖了一些子模块代码不拉子模块会导致编译缺文件checkout到某个Release标签是因为ET一直在重构不同版本之间目录结构差别很大网上很多教程的代码路径是基于特定版本写的你锁定版本后对照教程才不会踩“文件找不到”的坑。3.2 用命令行编译并启动服务器进程在Windows下进入Server目录找到对应的sln解决方案文件用Visual Studio打开。首次编译会还原NuGet包耗时比较长需要耐心等。编译产物会在Server/Bin目录下生成里面是一批dll和exe。启动服务器不需要手动一个个点击exeET框架在开发模式下通常是先启动一个名为“启动器”的控制台进程它会按配置拉起多个子进程比如负责登录的进程、负责房间逻辑的进程。常见做法是在Visual Studio里把启动器项目设为启动项目直接F5运行。如果你更习惯命令行方式也可以这样做cd Server/Bin dotnet App.dll --AppTypeLauncher --AppId1参数说明--AppTypeLauncher 表示以启动器身份运行它会读取配置并拉起其他子进程--AppId1 是当前进程的编号每个进程都要有一个唯一AppId用于进程间通信和消息路由。启动成功后控制台会打印各子进程的启动日志看到类似“Start Init OK”这样的输出基本可以确认服务器层起来了。3.3 在Unity端连接服务器改一个地址和端口打开Unity工程后先确认ET框架要求的最低Unity版本。ET6.x通常需要2020.3或更高版本用太老的Unity版本会直接编译报错。Unity工程里有一个初始化场景场景里有一个全局的Game对象上面挂着模式选择组件你可以把当前模式设为开发模式Development并在配置里填上服务器IP和端口。这个步骤最简单也最容易翻车。很多人卡在“连不上服务器”排查下来是填了localhost但手机或另一台电脑访问时并没有把IP改成局域网地址。正确做法是同一局域网下把IP填成运行服务器那台机器的局域网IP比如192.168.1.100而不是127.0.0.1。如果你在云服务器上跑填公网IP还要确认防火墙和云安全组放行了对应端口ET默认的端口从10000往后比较多具体看配置文件。3.4 跑通第一对消息从登录按钮到服务器回复现在你有了一个能跑的服务器和一个能连上服务器的Unity客户端。下一步就是把登录消息跑通。ET框架的消息定义在共享代码中用Proto格式定义。登录相关的消息大致是这样的message C2R_Login // 客户端发给服务器请求登录 { string Account 1; string Password 2; } message R2C_Login // 服务器返回登录结果 { int32 Error 1; string Message 2; string Token 3; }字段说明这里的数字1、2、3是字段编号用于Protobuf序列化时识别字段不能重复修改字段名不影响协议兼容性但修改字段编号会破坏兼容性。Error为0表示成功非0表示失败具体错误码表需要约定好。Unity端点击登录按钮后的代码逻辑大致如下这是一个简化版的调用方式// 发送登录请求的Demo代码客户端侧 async ETTask OnLoginBtnClick() { // 构建请求消息 C2R_Login request new C2R_Login(); request.Account accountInput.text; request.Password passwordInput.text; // 通过Session发送并等待响应 R2C_Login response (R2C_Login)await session.Call(request); if (response.Error ! 0) { Log.Error($登录失败: {response.Message}); return; } // 保存Token后续进入游戏流程会用到 PlayerPrefs.SetString(token, response.Token); // 登录成功切换到游戏场景 await SceneManager.LoadSceneAsync(GameMain); }代码说明session.Call是一个请求响应模式的方法底层会发送消息并挂起协程等待响应直到服务器返回才继续往下执行。这种写法比注册回调的方式直观很多。这里使用的session是当前客户端到服务器的一条逻辑连接。调用前要确保session已经完成连接步骤否则会抛出异常。这套最小链路跑通后你就有了一个“客户端发消息→服务器处理→客户端收到响应”的闭环接下来做斗地主玩法都是在这个闭环之上扩展。每次加新功能前先确认这个闭环还在开发效率会稳得多。4. 斗地主核心玩法落地房间、发牌、出牌与结算的代码实现4.1 房间管理与匹配逻辑三个玩家凑一桌的过程是怎么写的斗地主的第一个核心是“凑齐三个人”。你可以做最简单的匹配逻辑玩家点击“开始匹配”后服务器把他加入一个匹配队列当队列里人数达到3人时创建一个房间Actor把三个玩家加入房间。这里用ET框架的Actor模型实现起来很干净。服务器端的伪代码如下// 当匹配队列人数达到3人创建房间并分配玩家 public static async ETTaskRoom CreateRoomForThreePlayers(ListPlayer players) { Room room EntityFactory.CreateWithIdRoom(Game.Scene, IdGenerater.GenerateId()); room.AddComponentDeckComponent(); // 牌堆 room.AddComponentGameStateComponent(); // 游戏状态叫地主-出牌-结算 room.AddComponentTimerComponent(); // 出牌计时 for (int i 0; i players.Count; i) { // 将玩家加入房间分配座位号0、1、2 await room.AddPlayer(players[i], i); } // 通知所有玩家房间已创建 M2C_RoomCreated roomCreatedMsg new M2C_RoomCreated(); roomCreatedMsg.RoomId room.Id; room.Broadcast(roomCreatedMsg); return room; }代码说明EntityFactory.CreateWithId创建了一个新的房间实体AddComponent挂上所需要的组件让牌堆、游戏状态、计时逻辑各司其职。把创建房间和加入玩家分开是为了复用——比如以后做“好友开房”可以直接创建房间再邀请好友加入不必走匹配队列。这里的AddPlayer内部还需要给每个玩家生成一个座位号。座位号在斗地主玩法里很重要因为叫地主是轮流按座位号来的出牌顺序也是按座位号循环。实现时用一个简单的取模算法即可当前出牌玩家座位号 (上个出牌玩家座位号 1) % 3。4.2 发牌逻辑洗牌、发牌与手牌的序列化传输斗地主的牌是一副54张的扑克牌用0到53编号其中52、53是大小王。洗牌用Fisher-Yates算法这是概率均匀且实现简单的经典做法。发牌时按座位号轮流各发17张留3张底牌。底牌在叫地主结束后归地主所有。洗牌和发牌的代码可以放在共享代码中因为客户端做“预展示”时可能也需要知道某副牌长什么样。代码如下// 洗牌并返回一副乱序的牌组 public static Listint ShuffleCards() { Listint cards new Listint(); for (int i 0; i 54; i) { cards.Add(i); } // Fisher-Yates洗牌 Random random new Random(); for (int i cards.Count - 1; i 0; i--) { int j random.Next(i 1); (cards[i], cards[j]) (cards[j], cards[i]); } return cards; }代码说明洗牌逻辑的位置放在共享代码里有一个直接好处以后做“观战”或者“回放”功能客户端可以本地重放某一局不需要服务器把每一张牌的数据都传过来只需传一个种子数然后客户端用同样的洗牌算法生成同样的牌序。这比传整副牌省流量。发牌后服务器需要把“各玩家的手牌”和“底牌”广播给客户端。这里的消息字段设计要留意不能只发“我的手牌”还要发玩家的座位号客户端才能在自己的UI上把三家玩家的手牌显示在对应的位置自己的牌在下方左右玩家只显示数量。消息结构大致是每个玩家一个PlayerCards字段内容为手牌数组。一个容易忽视的细节牌的数据用int列表传序列化出来体积很小但在客户端做UI绑定时手牌通常需要排序所以客户端拿到牌后要先排序再绑定到UI。这个排序逻辑也建议放在共享代码里保证排序规则一致——比如从大到小排列牌型分析时就不用关心顺序了。4.3 出牌校验与出牌广播服务器永远是正确的裁判出牌阶段是状态机最复杂的部分。每个玩家出牌时服务器要做两件事第一校验玩家出的牌是否符合牌型规则第二校验是否大过上家。这两步一个都不能少少了就会有人作弊打出非法牌型。牌型判断是斗地主最核心的纯逻辑。常见做法是写一个PokerHelper静态类提供方法如bool CheckCardType(Listint cards)和bool CompareCards(Listint curCards, Listint lastCards)。这里不展开所有牌型只展示一个关键逻辑——炸弹的判断与比较因为炸弹的处理特殊既属于牌型校验又影响倍率// 判断是否为炸弹四张点数相同的牌 public static bool IsBomb(Listint sortedCards) { if (sortedCards.Count ! 4) { return false; } int firstValue GetCardValue(sortedCards[0]); for (int i 1; i 4; i) { if (GetCardValue(sortedCards[i]) ! firstValue) { return false; } } return true; }代码说明GetCardValue把牌的编号0到53映射为点数3到2再到大小王这种映射关系需要在工具类里统一定义。炸弹的判断逻辑很简单但在校验“是否能压过上家”时炸弹是跨牌型参与比较的唯一特例普通牌型只能压同牌型而炸弹可以压任何牌型两个炸弹相遇时再比较点数。这个特判逻辑千万别漏。服务器校验通过后将出牌消息广播给房间内所有玩家。这里建议广播一条统一的消息包含出牌者座位号、出的牌列表、以及剩余手牌数量这样客户端拿到消息后知道怎么更新界面。这里有一个设计决策需要提前做要不要广播手牌的具体内容我的建议是——公开自己的出牌即可不要广播未出的手牌防止玩家通过内存查看器作弊。其他玩家只需要看到“剩了5张”即可之后“报单”提示也是基于剩余数量做的。4.4 胜负结算农民与地主各拿各的分倍率怎么累加斗地主结算的核心是积分计算。默认一局基础分是1分叫地主加倍、抢地主加倍、炸弹加倍、春天加倍。这些倍率需要在游戏过程中不断累加存于房间的GameStateComponent中。结算逻辑伪代码如下// 结算isLandlordWin表示地主是否赢了 public static SettlementInfo CalculateSettlement(GameStateComponent state, bool isLandlordWin) { int baseScore state.BaseScore; // 基础分比如1 int multiplier state.Multiplier; // 当前累计倍数 int landlordScore 0; int farmerScore 0; if (isLandlordWin) { landlordScore baseScore * multiplier * 2; // 地主赢两家 farmerScore -baseScore * multiplier; } else { landlordScore -baseScore * multiplier * 2; farmerScore baseScore * multiplier; } SettlementInfo info new SettlementInfo(); info.LandlordScore landlordScore; info.FarmerScores farmerScore; // 两家农民各得该分 return info; }参数说明state.BaseScore是底分通常为1也可以做成一局内的变量由房间创建者配置state.Multiplier在每次叫地主、抢地主、炸弹打出时累加这个累加时机需要注意必须在动作生效时立刻更新不要在结算时才统一算否则容易漏算。结算后通知所有玩家的消息里要带每个玩家的最终得分和当前的倍率列表客户端做结算界面的展示。5. 避坑与排查ET框架做斗地主时最常遇到的5个坑5.1 实体ID对不上消息发到了不存在的玩家身上现象服务器统计日志时发现某些“出牌”消息被路由到了已退出的玩家导致房间内其他玩家卡在等待状态。原因ET框架的实体有一个InstanceId一个实体销毁后Id可能被复用或者消息里存的还是旧的实体ID。常见于玩家断线重连后旧的实体被销毁、新的实体被创建但房间内广播列表没有更新。解决确保在玩家加入房间和退出房间时都更新房间内的玩家实体引用列表。断线重连逻辑要单独做重连时通过Token找到玩家的新实体再把它重新挂到原来的房间下。我的习惯是所有消息处理前先校验实体是否存在不存在则直接丢弃并打印告警日志。5.2 手牌集合用List存储移除多张牌时索引越界现象玩家一次性出了多张牌比如顺子或者飞机服务器移除手牌时抛异常把整个出牌流程打断。原因用for循环遍历List并从List中Remove元素删除前面的元素后后续元素的索引改变了导致越界。解决不要边遍历边删除。推荐做法是先把要出的牌收集到一个HashSet中然后一次性重建剩余手牌列表。代码如下// 从手牌中移除指定的牌 public static Listint RemoveCards(Listint handCards, Listint cardsToRemove) { HashSetint removeSet new HashSetint(cardsToRemove); Listint result new Listint(handCards.Count); for (int i 0; i handCards.Count; i) { if (!removeSet.Contains(handCards[i])) { result.Add(handCards[i]); } } return result; }代码说明这里为了避免重复牌的问题手牌里有两张5你只出了一张5实际项目中不能用HashSet直接去重而是要把每张牌当作“一个可区分个体”用“牌编号手牌下标”或记录每张牌唯一标识的方式处理。更简单可靠的做法是遍历原手牌逐张标记被移除的牌而不是用值去重。这一点需要特别小心否则会出现“两张同点数只移除了一张”的隐患。5.3 出牌轮转逻辑写错导致玩家乱序出牌现象某个玩家出牌后下一个轮到的玩家不对有时候跳过一个玩家有时候又回到自己。原因轮转逻辑用了固定顺序而斗地主里存在“农民一伙、地主单独”的特殊轮转规则当某个玩家出牌后其他两家如果都不要则这个玩家重新出牌。没有保存“当前最大牌是谁出的”这个状态。解决在GameStateComponent里增加LastPlaySeat和LastPlayCards字段每次出牌时更新这两个字段。当两个玩家连续选择“不出”后轮转重置为LastPlaySeat出牌。5.4 客户端动画节奏没处理导致UI状态和服务器状态不一致现象收到服务器广播的出牌消息后客户端立刻更新手牌UI但出牌动画还没播完玩家已经点了下一手牌导致UI显示和最终逻辑结果对不上。原因客户端逻辑直接依赖服务器消息驱动UI没有做一个“动画期间禁用操作”的缓冲。解决在客户端加一个简单的状态锁。收到出牌广播后先播动画动画播完前禁止玩家点击任何操作按钮动画播完后解锁并刷新UI。实现可以用ET的协程工具出牌动画的代码前面已经提到过await一个动画时长即可。5.5 压测时内存只升不降服务器运行几小时就卡死现象多开客户端跑了一晚上服务器进程占用的内存在持续增加最后操作卡顿。原因ET框架的日志系统在开发模式会打印全量日志而日志写到内存中未及时释放另外有些事件订阅后没有反订阅Unsubscribe导致已经销毁的实体还在被事件系统引用内存无法回收。解决开发模式下临时把日志级别调高比如只输出Error以上日志同时在实体销毁的Dispose方法中把该实体订阅过的所有事件都取消订阅。这两种做法能显著降低内存泄漏风险。正式压测前先用小规模客户端跑半小时观察内存曲线是否平稳是判断泄漏的快速方法。6. 进阶验证与优化从Demo走向可长期维护的小项目Demo跑通后还有几步能拉开差距。第一个是压测至少开10个客户端进程同时匹配、同时出牌观察服务器的CPU、内存和消息延迟。ET框架自带一些性能统计工具你可以把每轮出牌的服务器处理耗时打印出来。正常情况下一次出牌消息从收到到广播给三个客户端耗时应该低于10毫秒如果高于50毫秒说明逻辑里有阻塞或过重的同步操作优先排查日志打印和数据库操作。第二个是日志的规范化。开发调试时把关键业务日志打全但发布后只保留登录、创建房间、结算这类关键操作日志出牌日志可以降级为Debug级别否则磁盘撑不住。ET框架的日志系统支持按级别过滤这个配置花十分钟就能学会性价比很高。第三个是断线重连。Demo阶段可以不处理断线但要做到可演示的完整程度至少要保证玩家在出牌过程中断线服务器等待10秒后自动代打自动出最小的牌并且玩家重连后能回到原房间继续游戏。这个功能一开始就考虑能为你后续做正式项目省下大量重构时间。代打逻辑代码量不大但对框架理解的提升很有效。第四个是客户端表现层的优化。比如手牌拖动、出牌飞行动画、提示“要不起”的按钮置灰这些做得细不细直接决定别人看了Demo之后觉得“这是个玩具”还是“这已经像产品了”。我见过不止一个团队服务端逻辑完善但Demo的UI停留在“按钮文字”展示时观感差很多。斗地主的交互表现在手牌排序动画和出牌飞行动画上你花一周时间打磨这两个细节比加十个功能都有效。做这个Demo我的经验是把“验证框架和学习成本”当作第一目标不要一味堆功能。我早期做某个联机Demo时花了太多时间在复杂的匹配算法上结果基础消息链路反而不稳展示时频频出状况。后来收敛目标先把三人在同一房间里完整打一局跑通再逐步加匹配、加托管、加重连路反而走得更顺。最后分享一个我的个人习惯每次写完一关键节点比如发牌、出牌校验、结算我都会用两个客户端实测三个玩家的完整对局并在本子上记录每步操作后的界面状态。很多“玄学”问题最后查出来都是服务器广播了消息但客户端刷新逻辑漏写了。养成把消息流和UI状态对应起来的调试习惯你后面做任何联机功能都会顺很多。希望帮到你。本文还有配套的精品资源点击获取
)
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
