岁迹

本文从 LearnByCompany 原始文档 自动同步。

项目确实将原来 7476行 的 NewActivityModel.lua 大文件拆分成了 门面模式 + 17个子Model 的架构： 门面类: ActivityModel.lua (278行) 子Model数量: 17个核心功能模块 + 大量活动实例Model 总Model数量: 约 120+ 个活动相关Model 🔧 核心设计机制1. 子模块注册系统123-- 批量注册事件常量到类表ActivityModel.Events = ActivityModel_EventConstants_RegisterEventConstants() -- 自动挂载所有非函数属性 2. 动态方法注册123456-- 外部事件 → 门面类 → 对应子模块function ActivityModel:RegisterEvents() self:AddListener(_MOE.EventEnum.ON_PANDORA_RED_POINT_STATE_UPDATED, self, function(self, appId) self.m_redDot.OnPando...

12345678910111213141516171819202122232425262728293031323334353637383940414243444546474849505152535455565758596061626364656667686970717273747576777879808182838485868788899091929394959697989910010110210310410510610710810911011111211311411511611711811912012112212312412512612712812913013113213313413513613713813914014114214314414514614714814915015115215315415515615715815916016116216316416516616716816917017117217317417517617717817918018118218318418518618718818919019119219319419519619719819920020120...

1. 服务器数据是怎么来的（协议是什么意思）1.1 “协议” = 服务端和客户端约定的通信格式1服务端（C++） ←——协议——→ 客户端（Lua） 协议就是一种约定： 服务端说：”我推一坨二进制数据给你，按 CsAllPlayerActivityInfo 格式解读” 客户端说：”好的，我用 pb.decode("com.tencent.wea.protocol.CsAllPlayerActivityInfo", 数据) 解码” 1.2 协议的两种方向 方向 名称 含义 举例 C → S C2S（Client to Server） 客户端发给服务端 “我要领奖”、”请给我活动数据” S → C Ntf（Notify 通知） 服务端推给客户端 “你的任务完成了”、”活动开始了” 1.3 协议的数据传输过程123456789101112服务端 │ 原始数据: { activityId=10017, score=30, taskList=[...] } │ ↓ Protobuf 编码（压缩成二进制字节流）...

项目中 “Model” 的含义在元梦之星项目中，Model 是数据模型层，对应 MVC/MVP 架构中的 M 层，是整个游戏的数据核心。 一句话定义Model 负责 数据存储、业务逻辑、协议收发、配置查询，通过事件系统与 View（UI层）解耦通信，绝不直接操作 UI。 职责划分 能做 不能做 存储游戏数据（道具、邮件、任务等） 操作 UI / 调用 UIManager 处理业务逻辑（计算、判断、状态变更） 直接刷新界面 与服务器 Protobuf 通信（发协议、绑推送） — 读取游戏配表 — 通过 DispatchEvent 通知 View 刷新 — 继承体系123BaseModel (基类) └── SystemBaseModel (一级系统Model) └── SystemSubModel (子Model，分 Persistent/Temporary) 创建语法：_MOE.class("BagModel", _MOE.SystemBaseModel) 核心生命周期12345Ctor → ...

本地新增活动时，配置表数据是如何被读取的核心结论配置表数据和服务端数据不是两份独立的东西，而是同一条数据链路： 1234567你在 Excel 里填配置表 ↓ 导表生成 txt/lua 文件（本地） ↓ 服务端也读取同一份配置表（或服务端自己有对应配置）服务端组装数据 → 通过 Ntf 推送给客户端 ↓客户端 Model 接收 → 存储 → View 读取 关键点：你在本地配置表填的数据（activityName、activityUIDetail、tagId 等），服务端也会读取，然后服务端把这些配置表字段和玩家的动态数据打包在一起，通过协议推送给客户端。 完整链路：从你填配置表到 View 显示第 1 步：你填配置表12345678H_活动中心配置.xlsx 新增一行: id: 30999 activityName: 春日兑换 activityUIDetail: UI_ActivityTemplate_ExchangeLinearView tagId: 1 activityShopType: 142 backgroundUrl: spring_...

1.UEC++实现第三人称角色移动 + 视角框架层级组件： ASCharacter(继承ACharacter，自带胶囊体 + 骨骼网络 + 移动组件) RootComponent = CapsuleComponent（胶囊体，ACharacter自动创建） SpringArmComp 弹簧臂（挂载到胶囊体） Camera 摄像机（挂载到弹簧臂） 12345SpringArmComp = CreateDefaultSubobject<USpringArmComponent>(TEXT("SpringArmComp"));SpringArmComp->SetupAttachment(RootComponent); // 弹簧臂挂胶囊体CameraComp = CreateDefaultSubobject<UCameraComponent>(TEXT("CameraComp"));CameraComp->SetupAttachment(SpringArmComp);...

1 model1234567891011玩家进游戏 → FirstChargeModel 注册事件 → 任务系统初始化完成 → 请求服务器 → 服务器返回 resIds = {2, 3} → 用 resIds 读配表 ResFirstChargeConfData → configMap[2] = {title, price, taskGroupId, subViweName, ...} → configMap[3] = {title, price, taskGroupId, subViweName, ...} → 用 taskGroupId 读任务系统 → taskMap[2] = {task1, task2, ...} → taskMap[3] = {task3, task4, ...} → 派发 GET_FIRST_CHARGE_INFO 事件（通知数据就...

1.先将本地分支提交到远程：feature/leohujiang - >origin2.在工蜂平台上创建MR，目标选择develop 3.等待审查提交 几个分支的理解1.develop 和 sX-dev 是什么关系？ 1234567赛季开始时：develop ──拷贝──▶ sX-dev（赛季版本分支）赛季开始后：各干各的develop ──────继续往后开发（下个赛季的内容）──────▶sX-dev ──────专注当前赛季（修bug、加活动）──────▶ develop：永远往前走，开发未来的东西sX-dev：从 develop 拷贝出来后，就独立了，专门服务当前赛季⚠️ 关键点：sX-dev 上的改动不会自动回到 develop。比如你在 sX-dev 上修了个 bug，develop 上那个 bug 还在，除非你手动合回去 2.线上”是哪个分支？“线上” = 当前玩家正在玩的那个版本，对应的分支就是上一次发布的那个 release 分支。 123比如这周三刚发布了 release_v3.5那"线上"就是 relea...

Git / UGit 多仓库分支管理通用说明1. 适用场景本文适用于以下常见情况： 一个项目由一个或多个独立 Git 仓库组成； 日常开发在主开发分支进行； 某项功能、演示版本或实验性修改保存在独立分支； 独立分支暂时不合并回主开发分支； 偶尔需要查看、修改或维护该独立分支。 为便于说明，本文统一使用以下占位名称： 名称 含义 示例 <主开发分支> 日常开发使用的分支 develop、main <功能分支> 保存特定功能或版本的分支 feature_xxx、demo_version origin 默认远端仓库名称 origin 实际操作时，应将占位名称替换为项目中的真实分支名。 Git 会严格区分分支名称。拼写、下划线、连字符或大小写不一致，都可能指向不同分支或导致命令失败。 2. 分支之间的关系Git 分支可以理解为不同的代码版本线或代码快照。 假设某项修改只提交在 <功能分支>： 切换到 <主开发分支> 后，看不到该功能是正常现象； 切换分支不会删除另一个分支中的代码； 已提交并推送...