update resume
This commit is contained in:
parent
5d94e417d8
commit
a0e32a2ae9
@ -1,6 +0,0 @@
|
|||||||
[[Android SDK]]
|
|
||||||
[[Engine]]
|
|
||||||
[[环境搭建]]
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
6
src/m/me/bingfeng/bingfeng.md
Normal file
6
src/m/me/bingfeng/bingfeng.md
Normal file
@ -0,0 +1,6 @@
|
|||||||
|
[[Android SDK]]
|
||||||
|
[[Engine]]
|
||||||
|
[[src/m/me/bingfeng/环境搭建]]
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
328
src/m/me/bingfeng/冰风网络工作细节.md
Normal file
328
src/m/me/bingfeng/冰风网络工作细节.md
Normal file
@ -0,0 +1,328 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
creation date: 2025-02-07 09:47
|
||||||
|
modification date: Friday 7th February 2025 09:47:38
|
||||||
|
---
|
||||||
|
# 工作记录
|
||||||
|
|
||||||
|
## History
|
||||||
|
|
||||||
|
- 2022
|
||||||
|
- 08
|
||||||
|
- 聚宝盆
|
||||||
|
- IOS好评
|
||||||
|
- GM历史记录
|
||||||
|
- 09
|
||||||
|
- 遗迹战场
|
||||||
|
- 10
|
||||||
|
- 武魂优化
|
||||||
|
- 战阶系统
|
||||||
|
- 符文塔
|
||||||
|
- 11
|
||||||
|
- 装备副本优化
|
||||||
|
- 副本提示
|
||||||
|
- 好友、仙缘优化
|
||||||
|
- 集市
|
||||||
|
- 角色属性优化
|
||||||
|
- 12
|
||||||
|
- 稀有首领
|
||||||
|
- 技能收缩
|
||||||
|
- ==红点系统==
|
||||||
|
- 暗器优化
|
||||||
|
- 2023
|
||||||
|
- 01
|
||||||
|
- 暗器副本优化
|
||||||
|
- 宝图妖王
|
||||||
|
- 暗器合成
|
||||||
|
- 02
|
||||||
|
- 商城优化
|
||||||
|
- 商会
|
||||||
|
- 福利大厅
|
||||||
|
- 通关礼包
|
||||||
|
- 折扣礼包
|
||||||
|
- 每日礼包
|
||||||
|
- 投资礼包
|
||||||
|
- 成长礼包
|
||||||
|
- 月度礼包
|
||||||
|
- 月卡礼包
|
||||||
|
- 03
|
||||||
|
- 搬箱子
|
||||||
|
- 主界面UI动画
|
||||||
|
- 福利大厅
|
||||||
|
- 每日礼盒
|
||||||
|
- 每日签到
|
||||||
|
- 开服活动
|
||||||
|
- 排行榜
|
||||||
|
- 限定宝箱
|
||||||
|
- 飞行坐骑
|
||||||
|
- 相机镜头优化
|
||||||
|
- ==辅助施法==
|
||||||
|
- 移动遥感优化
|
||||||
|
- 辅助遥感
|
||||||
|
- 04
|
||||||
|
- 开服活动
|
||||||
|
- 代码优化
|
||||||
|
- boss首杀
|
||||||
|
- 限定宝箱
|
||||||
|
- 战斗系统
|
||||||
|
- 锁目标
|
||||||
|
- 神秘实验室
|
||||||
|
- 05
|
||||||
|
- 动画系统
|
||||||
|
- 上下半身骨骼分离
|
||||||
|
- 魔法编辑器
|
||||||
|
- 支持动作分离
|
||||||
|
- 添加标签系统
|
||||||
|
- 添加属性面板
|
||||||
|
- 任务系统
|
||||||
|
- 多段对话
|
||||||
|
- 战斗系统
|
||||||
|
- 走A
|
||||||
|
- 06
|
||||||
|
- 剧情编辑器
|
||||||
|
- 相机优化
|
||||||
|
- API优化
|
||||||
|
- 对话气泡
|
||||||
|
- 选角剧情、开场剧情
|
||||||
|
- 07
|
||||||
|
- PVS预计算裁剪
|
||||||
|
- 37SDK
|
||||||
|
- 问卷星
|
||||||
|
- 健康游戏忠告
|
||||||
|
- 雪人求生优化
|
||||||
|
- 技能优化
|
||||||
|
- 挂机技能优化
|
||||||
|
- 排序
|
||||||
|
- 优先级
|
||||||
|
- 公共CD
|
||||||
|
- 08
|
||||||
|
- 魔法编辑器
|
||||||
|
- 摆怪
|
||||||
|
- 小功能优化
|
||||||
|
- 09
|
||||||
|
- 点击特效
|
||||||
|
- 转职优化
|
||||||
|
- 10
|
||||||
|
- 省电模式
|
||||||
|
- 恭喜获得优化
|
||||||
|
- 11
|
||||||
|
- 玩家和boss最小距离
|
||||||
|
- boss开荒优化
|
||||||
|
- 一测2023.11.29~2023.12.05
|
||||||
|
- 移动普攻
|
||||||
|
- 之前有移动身体的魔法时，是不可移动的
|
||||||
|
- 受击特效优化
|
||||||
|
- 原先特效很大，在怪物胸部生成，大体型boss看不到效果
|
||||||
|
- 改成小特效，然后绑定骨骼和半径，进行偏移计算真实位置
|
||||||
|
- 剧情优化
|
||||||
|
- 相机贝塞尔曲线轨迹
|
||||||
|
- 支持慢放、字幕、模型UI展示
|
||||||
|
- 支持贝塞尔曲线移动
|
||||||
|
- 卡顿优化 隐藏场景物件
|
||||||
|
- 支持播放CG视频
|
||||||
|
- 魔法编辑器
|
||||||
|
- 三连击效果
|
||||||
|
- 终点相对坐标(带朝向)
|
||||||
|
- 摆怪优化
|
||||||
|
- 资源预加载
|
||||||
|
- 修复特效丢失bug
|
||||||
|
- 二测2024.05.28~2024.06.04
|
||||||
|
- 抄原神
|
||||||
|
- 路径特效
|
||||||
|
- 对话按钮
|
||||||
|
- 遥感滑动优先级高于聊天栏
|
||||||
|
- 修复剧情抖动，相机镜头慢一帧
|
||||||
|
- 三段跳 飞行，显示体力值
|
||||||
|
- 寻路优化，路点寻路
|
||||||
|
- 飘字优化，满屏爆炸效果
|
||||||
|
- 三测2024.09.11~2024.09.17
|
||||||
|
- 资源优化
|
||||||
|
- 消息推送
|
||||||
|
## 核心功能
|
||||||
|
#### **战斗系统**
|
||||||
|
|
||||||
|
- **战斗优化**：受击反馈、推怪机制、技能动画流畅性提升
|
||||||
|
- **锁定系统**：优化目标锁定逻辑，镜头锁定，提高战斗操作体验
|
||||||
|
- **飘字系统**：改进战斗伤害飘字，优化美观度和视觉冲击力
|
||||||
|
- **移动施法**：支持施法过程中移动，提高战斗自由度
|
||||||
|
- **辅助施法**：辅助调整技能施法，提高玩家操作性
|
||||||
|
|
||||||
|
#### **游戏系统**
|
||||||
|
|
||||||
|
- **红点系统**：简洁强大的红点框架，bug少，易维护
|
||||||
|
- **寻路系统**：优化路径点寻路，提高导航精准度
|
||||||
|
- **省电模式**：优化功耗管理，降低设备发热，提高续航能力
|
||||||
|
- **资源优化**：优化首包大小，减少玩家下载压力，提高留存
|
||||||
|
|
||||||
|
#### **工具开发**
|
||||||
|
|
||||||
|
- 魔法编辑器
|
||||||
|
- 支持动作分离，提高动画编辑灵活度
|
||||||
|
- 新增标签系统，提升数据管理效率
|
||||||
|
- 增强摆怪功能，优化怪物位置调整方式
|
||||||
|
- 剧情编辑器
|
||||||
|
- 相机运动曲线优化，实现流畅转场
|
||||||
|
- 支持贝塞尔曲线移动，提高剧情表现力
|
||||||
|
- 增加CG播放功能，丰富叙事手段
|
||||||
|
|
||||||
|
#### **UI & 交互优化**
|
||||||
|
|
||||||
|
- **对话系统**：优化对话按钮交互体验，提高用户点击反馈
|
||||||
|
- **主界面UI动画**：增强界面动态效果，提高视觉吸引力
|
||||||
|
- **点击特效**：增加点击反馈，提高用户交互感知
|
||||||
|
|
||||||
|
#### **SDK & 数据分析**
|
||||||
|
|
||||||
|
- **37SDK对接**：问卷星、健康游戏忠告、埋点数据采集
|
||||||
|
- **消息推送**：实现精准推送，提高用户活跃度
|
||||||
|
|
||||||
|
# 平行内测
|
||||||
|
|
||||||
|
## 一测
|
||||||
|
2023/11/30~2023/12/05
|
||||||
|
|
||||||
|
### 数据
|
||||||
|
|
||||||
|
| 用户 | 充值 |
|
||||||
|
| ---- | ----- |
|
||||||
|
| 4705 | 68464 |
|
||||||
|
|
||||||
|
| 留存率 | 次留 | 3留 | 4留 | 5留 | 六留 |
|
||||||
|
| ------ | ----- | ---- | ---- | ---- | ---- |
|
||||||
|
| 11.30 | 19.8% | 9.2% | 5.8% | 5.0% | 4.2% |
|
||||||
|
| 12.01 | 20.7% | 8.5% | 5.5% | 4.1% | |
|
||||||
|
|
||||||
|
| | 11.30 | 12.01 | 12.02 | 12.03 | 12.04 | 12.05 |
|
||||||
|
| ------ | ----- | ----- | ----- | ----- | ----- | ----- |
|
||||||
|
| 付费率 | 8.6% | 5.5% | 3.7% | 3.8% | 4.9% | 5.0% |
|
||||||
|
| 充值额 | 22184 | 12848 | 7462 | 8946 | 14342 | 2650 |
|
||||||
|
| 新用户 | 1863 | 957 | 875 | 711 | 247 | 49 |
|
||||||
|
|
||||||
|
### 问题
|
||||||
|
|
||||||
|
- 留存偏低
|
||||||
|
- 数据只有仙王一半还差一点
|
||||||
|
- 前期新手流程太长，无目标
|
||||||
|
- 付费率偏低
|
||||||
|
- 留不住人
|
||||||
|
|
||||||
|
### 问卷调查
|
||||||
|
|
||||||
|
总问卷数量184， 84%的玩家愿意继续游玩
|
||||||
|
|
||||||
|
| 剧情设定 | 画面表现 | 战斗感受 | 性能体验 | UI交互 | 游戏引导 |
|
||||||
|
| -------- | -------- | -------- | -------- | ------ | -------- |
|
||||||
|
| 3.89 | 4.03 | 3.91 | 3.83 | 3.92 | 3.95 |
|
||||||
|
|
||||||
|
- 战斗感受差
|
||||||
|
- 打击感不佳
|
||||||
|
- 按键操作不舒服
|
||||||
|
- 伤害跳字不美观
|
||||||
|
- 画面表现差
|
||||||
|
- 战斗动画特效
|
||||||
|
- 模型精度、流畅度
|
||||||
|
- 引导体验差
|
||||||
|
- 过于繁琐
|
||||||
|
- 没有目标感
|
||||||
|
- 游戏画风好
|
||||||
|
- 未来都市
|
||||||
|
- 赛博朋克
|
||||||
|
|
||||||
|
### 调整方案
|
||||||
|
|
||||||
|
- 任务流程优化
|
||||||
|
- 前三张地图任务流程加快
|
||||||
|
- 加速进入核心玩法
|
||||||
|
- 增加在线玩法和平矿洞
|
||||||
|
- 体验优化
|
||||||
|
- 受击、推怪、技能优化、移动施法
|
||||||
|
- 付费优化
|
||||||
|
- 货币优化
|
||||||
|
- 降低小R压力，促使大R从玩家手中购买货币
|
||||||
|
- 首充优化
|
||||||
|
- 首充档次隐藏
|
||||||
|
- 限时礼包
|
||||||
|
- 新增每日128元累充奖励
|
||||||
|
- 月卡、投资购买展示
|
||||||
|
- 剧情优化
|
||||||
|
- 提升游戏品质
|
||||||
|
|
||||||
|
## 二测
|
||||||
|
|
||||||
|
2024/05/28~2024/06/04
|
||||||
|
|
||||||
|
### 数据
|
||||||
|
|
||||||
|
| 用户 | 充值 |
|
||||||
|
| ---- | ----- |
|
||||||
|
| 3862 | 22642 |
|
||||||
|
|
||||||
|
| 留存率 | 次留 | 3留 | 4留 | 5留 | 六留 | 七留 |
|
||||||
|
| ------ | ----- | ----- | ---- | ---- | ---- | ---- |
|
||||||
|
| 05.29 | 22.4% | 11.3% | 7.9% | 5.3% | 3.8% | 3.1% |
|
||||||
|
| 一测 | 20.1% | 9.0% | 5.7% | 4.7% | 3.8% | 3.1% |
|
||||||
|
|
||||||
|
| | 05.29 | 05.30 | 05.31 | 06.01 | 06.02 | 06.03 | 06.04 |
|
||||||
|
| ------ | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
|
||||||
|
| 付费率 | 9.1% | 5.0% | 3.7% | 3.3% | 4.0% | 5.9% | 9.5% |
|
||||||
|
| 充值额 | 8418 | 5766 | 2942 | 2572 | 1364 | 844 | 736 |
|
||||||
|
| 新用户 | 2001 | 879 | 780 | 136 | 36 | 20 | 10 |
|
||||||
|
|
||||||
|
### 问题
|
||||||
|
|
||||||
|
- 留存前几天略有提升，进步不大，依然很低
|
||||||
|
- 首充付费仅利于第一天小R用户，后面付费反而掉了
|
||||||
|
- 玩家没有升级、升战力目标
|
||||||
|
- 游戏内容少
|
||||||
|
|
||||||
|
### 解决方案
|
||||||
|
|
||||||
|
- 美术画风优化
|
||||||
|
- 加入魔化风格
|
||||||
|
- 核心循环
|
||||||
|
- 等级战力闭环
|
||||||
|
- 加强战力对经验之地的效率影响
|
||||||
|
- 目标优化
|
||||||
|
- 目标精灵，细分目标，无处不在
|
||||||
|
- 天神时装
|
||||||
|
- 在线玩法
|
||||||
|
- 离线挂机加回来
|
||||||
|
- 商业化
|
||||||
|
- 首充改回来
|
||||||
|
- 开服冲榜调整
|
||||||
|
|
||||||
|
## 三测
|
||||||
|
|
||||||
|
### 数据
|
||||||
|
|
||||||
|
| 用户 | 充值 |
|
||||||
|
| ---- | ----- |
|
||||||
|
| 3614 | 34994 |
|
||||||
|
|
||||||
|
| 留存率 | 次留 | 3留 | 4留 | 5留 | 六留 | 七留 |
|
||||||
|
| ------ | ----- | ----- | ----- | ----- | ---- | ---- |
|
||||||
|
| 09.11 | 36.9% | 21.6% | 15.4% | 10.9% | 9.6% | 7.4% |
|
||||||
|
| 09.12 | 30.9% | 18.8% | 13.0% | 11.1% | 7.3% | |
|
||||||
|
| 二测 | 22.4% | 11.3% | 7.9% | 5.3% | 3.8% | 3.1% |
|
||||||
|
| 一测 | 20.1% | 9.0% | 5.7% | 4.7% | 3.8% | 3.1% |
|
||||||
|
|
||||||
|
| | 09.11 | 09.12 | 09.13 | 09.14 | 09.15 | 09.16 | 09.17 |
|
||||||
|
| ------ | ----- | ----- | ----- | ----- | ----- | ----- | ----- |
|
||||||
|
| 付费率 | 15.4% | 13.5% | 7.3% | 6.5% | 6.9% | 7.6% | 7.7% |
|
||||||
|
| 充值额 | 3024 | 13804 | 4596 | 4964 | 3790 | 2690 | 2126 |
|
||||||
|
| 新用户 | 1666 | 1720 | 159 | 31 | 20 | 9 | 9 |
|
||||||
|
|
||||||
|
### 问题
|
||||||
|
|
||||||
|
- 付费率低，留存率不高
|
||||||
|
- 内容少不够玩，玩法不够爽
|
||||||
|
|
||||||
|
### 解决方案
|
||||||
|
|
||||||
|
- VIP体系加回来
|
||||||
|
- 结婚玩法全部移回来
|
||||||
|
- 首包资源优化
|
||||||
|
|
||||||
|
- 任务节奏优化
|
||||||
|
|
||||||
97
src/m/me/xindong/心动工坊.md
Normal file
97
src/m/me/xindong/心动工坊.md
Normal file
@ -0,0 +1,97 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
creation date: 2025-02-08 15:07
|
||||||
|
modification date: Saturday 8th February 2025 15:07:42
|
||||||
|
---
|
||||||
|
# 心动工坊
|
||||||
|
嘿！这是你当前的**家园工坊系统**设计需求总结：
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **1. 结构概述**
|
||||||
|
|
||||||
|
- **工坊由 16 个房间组成**，玩家可以自由改造房间结构。
|
||||||
|
- **墙壁为厚墙体**，允许多种连接方式（90°、180°、270°）。
|
||||||
|
- **房间改造功能**：
|
||||||
|
- 可敲墙、砌墙，连通或封闭房间。
|
||||||
|
- 可抬升或下沉房间，形成高台结构。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **2. 透视隐藏系统（建造模式）**
|
||||||
|
|
||||||
|
- 进入建造模式时，**系统需选中一个目标房间**。
|
||||||
|
- **隐藏阻挡视野的墙壁**，确保目标房间可见。
|
||||||
|
- 需要基于**相机视角**自动判断哪些墙壁需要隐藏。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **3. 立柱 & 墙壁连接方式**
|
||||||
|
|
||||||
|
- **立柱**：用于处理墙壁的连接点，增强灵活性。
|
||||||
|
- **墙壁连接方式**：
|
||||||
|
- 90° 转角
|
||||||
|
- 180° 直连
|
||||||
|
- 270° 三向交叉
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **4. 包边系统（墙壁顶部装饰）**
|
||||||
|
|
||||||
|
- **墙壁顶部需加包边**，避免墙面过于简洁。
|
||||||
|
- **包边结构**：
|
||||||
|
- **中间部分**：使用**长方体**模块堆叠。
|
||||||
|
- **边缘部分**：使用**斜面体**拼接，形成自然过渡。
|
||||||
|
- **包边拐角拼接方式**：
|
||||||
|
- **半凹角 + 半凹角** → 形成**完整的内角**（凹角）
|
||||||
|
- **半凸角 + 半凸角** → 形成**完整的外角**（凸角）
|
||||||
|
- **半凹角 + 半凸角** → 形成**平滑过渡的包边**
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **5. 家具系统**
|
||||||
|
|
||||||
|
- **家具可放置在**：
|
||||||
|
- 地面
|
||||||
|
- 墙壁
|
||||||
|
- 天花板
|
||||||
|
- **跨房间家具**：如果房间**连通且高度一致**，可放置在房间边界。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### **6. 其他细节优化**
|
||||||
|
|
||||||
|
- **自动适配系统**：
|
||||||
|
- **检测墙壁连接方式**，自动匹配正确的包边和立柱样式。
|
||||||
|
- **材质支持**：
|
||||||
|
- 墙壁两面可以使用**不同材质**，但需要避免重叠视觉问题。
|
||||||
|
- **渲染优化**：
|
||||||
|
- 确保隐藏的墙体不会影响性能，同时正确渲染可见部分。
|
||||||
|
## 📌 你的方案（多四叉树）
|
||||||
|
### **✅ 优势**
|
||||||
|
|
||||||
|
1. **高效的平面查询**
|
||||||
|
|
||||||
|
- **单独的四叉树**，能直接忽略无关的家具，减少计算量。
|
||||||
|
- **地面、墙壁、天花板各自管理**，查询**只需要在当前平面**，不浪费资源。
|
||||||
|
2. **特化的第三维检测**
|
||||||
|
|
||||||
|
- 不是所有物体都需要高度检测，你**只有必要时才计算第三维投影**。
|
||||||
|
- 对于墙面家具，可以跳过**地面高度检测**，避免额外计算。
|
||||||
|
3. **避免八叉树的复杂性**
|
||||||
|
|
||||||
|
- **四叉树只处理2D平面查询**，计算**更简单，插入/删除成本更低**。
|
||||||
|
- 八叉树管理**3D空间，增加不必要的复杂度**。
|
||||||
|
|
||||||
|
### **❌ 潜在问题**
|
||||||
|
|
||||||
|
4. **跨房间家具的管理**
|
||||||
|
- 你的方案**每个房间都有独立的四叉树**，如果家具**跨房间（如长桌、楼梯）**，就需要额外处理。
|
||||||
|
- 解决方案：允许家具**同时注册到多个四叉树**，或者引入**跨房间管理**。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
|
||||||
|
这个设计已经相当完整了！💡 你接下来是要实现它，还是想优化某个部分？🚀
|
||||||
|
|
||||||
52
src/m/me/红点系统.md
Normal file
52
src/m/me/红点系统.md
Normal file
@ -0,0 +1,52 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
creation date: 2025-02-06 17:55
|
||||||
|
modification date: Thursday 6th February 2025 17:55:18
|
||||||
|
---
|
||||||
|
# 红点系统
|
||||||
|
## 特点
|
||||||
|
- 分层级
|
||||||
|
- 红点的显示位置分层级，一层层显示到系统功能的子界面中
|
||||||
|
- 红点层级类似树状结构，适合使用红点树来实现红点系统
|
||||||
|
- 界面独立
|
||||||
|
- 红点显示逻辑与界面无关，在子界面打开之前，主界面就要显示红点
|
||||||
|
- 红点虽然依赖于UI进行显示，但是红点系统的实现不能强依赖于UI
|
||||||
|
- 在性能优化时，可以考虑延迟更新看不到的红点
|
||||||
|
- 系统管理
|
||||||
|
- 红点系统是一个层层套娃的结构，并且涉及到游戏中的绝大部分模块。需要有一个设计合理的红点系统来统一管理红点功能，保障红点的可维护性，提升系统性能，减少bug
|
||||||
|
## 老红点系统
|
||||||
|
基于事件自上而下的刷新红点树，通过代码来手动模拟树状结构
|
||||||
|
- 缺少系统管理
|
||||||
|
- 红点逻辑有负责各个模块的程序员各自管理，导致现在的红点代码杂乱无章，维护困难，bug也比较多
|
||||||
|
- 使用不方便，维护困难
|
||||||
|
- 父子节点的关系没有统一维护，增添红点时还需要在上级模块写红点的判断和触发大门。上级模块的红点逻辑杂糅了所有子节点的逻辑，维护起来非常困难。
|
||||||
|
- 自上而下刷新不全面，有bug
|
||||||
|
- 只在界面的创建和主要的功能事件中，才会重新刷新红点树。经常漏掉红点的刷新事件，导致错误的红点状态。
|
||||||
|
- 重复，不必要的红点判断，性能浪费
|
||||||
|
- 同样的红点逻辑即存在子节点中，又存在父节点中，部分逻辑每次都会重复判断。部分红点采用定时、可能导致数据变化的事件来更新红点状态，很浪费性能。
|
||||||
|
## 新红点系统
|
||||||
|
基于外部事件刷新叶子节点状态，基于父子关系自下而上刷新红点树
|
||||||
|
- 红点系统统一管理红点树
|
||||||
|
- 红点系统维护了节点间的父子关系，并提供了通用的红点功能函数，减少了重复任务量。
|
||||||
|
- 红点系统拓展性好
|
||||||
|
- [x] 支持非循环的网状节点关系
|
||||||
|
- [x] 支持文件配置红点与动态增删
|
||||||
|
- [x] 通过脏标记支持延迟刷新与避免父节点重复刷新
|
||||||
|
- [x] 支持不同类型的父子关系 与或非
|
||||||
|
- [x] 支持辅助事件函数，统一处理道具变化等性能敏感型事件
|
||||||
|
- [x] 支持不同的红点表现，如小红点、感叹号、数字红点
|
||||||
|
- [x] 支持多粒度的红点屏蔽
|
||||||
|
- 使用方便，只需关注叶子节点
|
||||||
|
- 设置叶子节点状态即可保证整颗红点树状态都是最新的
|
||||||
|
- UI表现层与红点树节点绑定，可以实现小红点、感叹号，等多种样式
|
||||||
|
- 主界面和侧边栏的节点由红点系统自动绑定与刷新，程序只需关心自身模块内的红点
|
||||||
|
- 兼容老红点系统
|
||||||
|
- 老系统涉及的模块和代码非常多，全部改成新红点系统工作量大且难以实现
|
||||||
|
- 新红点系统支持新老红点的混合与嵌套使用，新功能使用新红点系统，老功能可以逐步替换成新红点
|
||||||
|
## 问题
|
||||||
|
- 调试不方便
|
||||||
|
- 红点每次操作都会进入元表方法，之后才会进入真正的调用函数，且元表函数也会带来性能开销
|
||||||
|
- 红点树维护
|
||||||
|
- 为了保证红点树的正确性，需要保证每一个节点的数据正确，即使这个节点暂时无需使用。这需要监听大量的事件，也可能维护了多余节点。
|
||||||
|
|
||||||
268
src/m/me/面试.md
Normal file
268
src/m/me/面试.md
Normal file
@ -0,0 +1,268 @@
|
|||||||
|
---
|
||||||
|
aliases:
|
||||||
|
tags:
|
||||||
|
creation date: 2025-02-06 13:39
|
||||||
|
modification date: Thursday 6th February 2025 13:39:59
|
||||||
|
---
|
||||||
|
## 招聘
|
||||||
|
|
||||||
|
### 心动网络
|
||||||
|
|
||||||
|
1. 3年游戏经验，完整参与一款上线游戏开发过程
|
||||||
|
2. c++、lua 编程基础好，学习能力强
|
||||||
|
3. 解决问题能力，团队能力 * 3
|
||||||
|
4. 掌握3D图形学原理
|
||||||
|
|
||||||
|
### 叠纸游戏
|
||||||
|
|
||||||
|
- 3年游戏经验（优先UE4）
|
||||||
|
- 玩法系统经验、专精
|
||||||
|
- 战斗技能
|
||||||
|
- 游戏系统流程逻辑
|
||||||
|
- 装备武器系统
|
||||||
|
- 特效
|
||||||
|
- 怪物人工智能
|
||||||
|
- 寻路和寻路数据
|
||||||
|
- 按键输入
|
||||||
|
- UI系统模块
|
||||||
|
- 红点系统
|
||||||
|
- 引擎底层开发经验
|
||||||
|
- c++、lua 编程基础好，学习能力强
|
||||||
|
|
||||||
|
### 友塔游戏
|
||||||
|
|
||||||
|
- 2年游戏经验，大世界游戏项目优先
|
||||||
|
- 熟练掌握游戏引擎
|
||||||
|
- 具备一定的图形学基础
|
||||||
|
- 计算机基础、团队能力、认真负责
|
||||||
|
|
||||||
|
### B站游戏
|
||||||
|
|
||||||
|
- 3年游戏经验，至少一款大中型游戏研发经验
|
||||||
|
- c++基础、常用算法、熟悉游戏开发工具UE4
|
||||||
|
|
||||||
|
### 西山居
|
||||||
|
|
||||||
|
- 2年游戏经验，熟悉至少一款商业引擎
|
||||||
|
- 游戏底层有研究，性能定位和优化
|
||||||
|
- 游戏引擎开发优先，熟悉渲染管线、图形API、GPU硬件架构
|
||||||
|
|
||||||
|
## 技巧
|
||||||
|
|
||||||
|
- STAR原则
|
||||||
|
- Situation 情景
|
||||||
|
- Task 任务
|
||||||
|
- Action 行动
|
||||||
|
- Result 结果
|
||||||
|
- 项目经历
|
||||||
|
- 我负责什么
|
||||||
|
- 遇到了什么问题
|
||||||
|
- 我做了什么
|
||||||
|
- 结果如何
|
||||||
|
- 提出亮点
|
||||||
|
- 我的思考与复盘（成长和进步）
|
||||||
|
- 挖坑，引导提问
|
||||||
|
-
|
||||||
|
- 为什么问项目经历
|
||||||
|
- 查看能力水平、成长潜力
|
||||||
|
- 技术背景、工作匹配
|
||||||
|
- 团队、沟通能力
|
||||||
|
- 解决问题能力
|
||||||
|
- 为了问问题？
|
||||||
|
- 判断真实性
|
||||||
|
- 核对细节问题
|
||||||
|
- 如何解决问题
|
||||||
|
|
||||||
|
## 实例
|
||||||
|
|
||||||
|
### **🎯 面试官的可能看法**
|
||||||
|
|
||||||
|
✅ **优点**：能看到你在多个核心系统上有实际经验，说明你有较强的**适应能力**和**综合技术能力**。
|
||||||
|
⚠️ **可能的疑问**：
|
||||||
|
|
||||||
|
- 你的优化是**独立完成**还是配合团队进行？
|
||||||
|
- 你在这些模块的**具体贡献**是什么？（如代码实现、架构调整、调试等）
|
||||||
|
- 你的深度如何？是否有能力深入研究某一方向？
|
||||||
|
|
||||||
|
### **🎯 总结：面试官重点关注你哪些能力？**
|
||||||
|
|
||||||
|
1️⃣ **独立分析 & 解决问题的能力**（能找出 bug & 解决问题）
|
||||||
|
2️⃣ **对系统架构的理解**（知道修改一个地方会影响哪些模块）
|
||||||
|
3️⃣ **优化 & 提升用户体验的能力**（不仅让功能跑起来，还要优化体验）
|
||||||
|
4️⃣ **团队协作 & 沟通能力**（能和策划、美术、后端高效配合）
|
||||||
|
|
||||||
|
------
|
||||||
|
|
||||||
|
### **🎯 你的面试策略**
|
||||||
|
|
||||||
|
**如果面试官问：** *“你修复相机抖动的过程是怎样的？”*
|
||||||
|
✅ 先说 **问题现象**（帧率波动时，目标跟随抖动）
|
||||||
|
✅ 再说 **分析过程**（检查代码逻辑，发现相机比剧情快一帧）
|
||||||
|
✅ 然后说 **解决方案**（同步相机更新，或者插值平滑）
|
||||||
|
✅ 最后说 **验证方法**（测试不同帧率，观察动画流畅度）
|
||||||
|
|
||||||
|
这样回答，能让面试官觉得你是一个 **能独立 debug & 解决问题** 的开发者，而不仅仅是“按需求改代码”的人！
|
||||||
|
|
||||||
|
## **❌ 按需求改代码（错误示例）**
|
||||||
|
|
||||||
|
### **面试官：你是怎么发现相机抖动的？**
|
||||||
|
|
||||||
|
**💬 错误回答**：
|
||||||
|
|
||||||
|
> “策划反馈说剧情相机会抖动，我去看了一下代码，发现可能是更新顺序的问题。然后我调整了一下，让它不卡了。”
|
||||||
|
|
||||||
|
### **面试官：你是怎么修复的？**
|
||||||
|
|
||||||
|
**💬 错误回答**：
|
||||||
|
|
||||||
|
> “我改了一下更新逻辑，让相机跟随主角时不卡顿了。”
|
||||||
|
|
||||||
|
### **🚩 这个回答有什么问题？**
|
||||||
|
|
||||||
|
1. **❌ 被动执行** → 只是在“策划反馈”后去修复，缺乏主动思考。
|
||||||
|
2. **❌ 分析不清晰** → “看了一下代码” 太模糊，没有说如何定位问题，也没有数据支撑。
|
||||||
|
3. **❌ 解决方案模糊** → “调整了一下” 没有说明改动细节，无法评估效果。
|
||||||
|
4. **❌ 缺乏验证** → 只提到“不卡了”，但没说如何测试，是否真的彻底解决问题。
|
||||||
|
|
||||||
|
------
|
||||||
|
|
||||||
|
## **✅ 真实的思考 & 解决过程（优秀示例）**
|
||||||
|
|
||||||
|
### **面试官：你是怎么发现相机抖动的？**
|
||||||
|
|
||||||
|
**💬 你的回答（正确示例）**：
|
||||||
|
|
||||||
|
> “一开始，我怀疑是相机和主角的相对运动不一致，所以我尝试把相机固定在主角后方。但观察后发现抖动依然存在，说明问题不是单纯的跟随逻辑导致的。
|
||||||
|
>
|
||||||
|
> 于是，我开始打印每一帧的相机位置和主角数据，并录屏逐帧对比分析。这时候，我注意到某些帧的数据并不匹配，像是相机‘超前’了一帧。
|
||||||
|
>
|
||||||
|
> 这让我怀疑帧率可能是关键因素。于是，我手动调整帧率，观察到帧率波动时抖动更加明显。
|
||||||
|
>
|
||||||
|
> 最终，我深入代码分析，确认了问题的本质：相机的更新逻辑比剧情系统早了一帧，导致主角更新位置后，相机要到下一帧才会跟随，帧率不稳定时就会抖动。”
|
||||||
|
|
||||||
|
### **面试官：你是怎么修复的？**
|
||||||
|
|
||||||
|
**💬 你的回答（正确示例）**：
|
||||||
|
|
||||||
|
> “找到原因后，我考虑了两种方案：
|
||||||
|
> 1️⃣ **调整相机更新顺序**，让它在剧情系统更新后执行，确保同步。
|
||||||
|
> 2️⃣ **用插值平滑相机位置**，减少帧率波动的影响。
|
||||||
|
>
|
||||||
|
> 我分别做了测试，发现第一种方案虽然解决了同步问题，但在某些特殊剧情情况下可能会有新的延迟问题。而第二种方案能有效平滑相机运动，同时不影响剧情系统的执行顺序。
|
||||||
|
>
|
||||||
|
> 最终，我选择了方案 2，并在不同设备、不同帧率下做了测试，确保问题彻底修复。”
|
||||||
|
|
||||||
|
------
|
||||||
|
|
||||||
|
## **🎯 关键对比**
|
||||||
|
|
||||||
|
| **对比点** | **❌ 按需求改代码** | **✅ 真实思考 & 解决问题** |
|
||||||
|
| ------------ | ------------------------------ | ------------------------------------------ |
|
||||||
|
| **问题定位** | “策划反馈了问题，我去看了下” | **主动分析，尝试不同假设，排除错误路径** |
|
||||||
|
| **分析过程** | “看了一下代码，可能是更新顺序” | **打印数据、逐帧对比、调整帧率验证假设** |
|
||||||
|
| **解决方案** | “调整了一下更新逻辑” | **提出多种方案，分析优缺点后选择最佳方案** |
|
||||||
|
| **验证过程** | 没有详细说明如何测试 | **在不同设备、不同帧率下进行验证** |
|
||||||
|
| **展示能力** | 只会改代码，没展现思考过程 | **体现逻辑思维、调试能力、优化意识** |
|
||||||
|
|
||||||
|
------
|
||||||
|
|
||||||
|
## **🎯 总结**
|
||||||
|
|
||||||
|
✅ **一个好的回答，应该清晰地展现你的思维过程，而不仅仅是“改了个 bug”！**
|
||||||
|
✅ 你的真实分析过程已经很好了，不需要编造优化数据，而是把**你的分析和调试过程讲清楚**，这样更能打动面试官。
|
||||||
|
|
||||||
|
你觉得这样对比是不是更清晰？😆
|
||||||
|
|
||||||
|
## 面经
|
||||||
|
|
||||||
|
- 介绍实习和项目经验 | 自我介绍
|
||||||
|
|
||||||
|
- 22年毕业后，我加入了冰风网络，进行自研引擎的MMO游戏开发。一开始我负责的是ui功能开发，当时的红点系统设计比较简陋，主界面和侧边栏红点之间没有建立父子关系，在新增、修改、刷新红点时，需要连带更新上级节点。维护非常困难，经常出bug。由于老红点使用太过麻烦，我主动尝试优化红点系统。基于红点树，我设计了一个全新的红点系统。子节点可以通过与或非等关系，影响到父节点。且额外支持了隐藏节点、条件节点。由于老红点涉及的模块和代码很多，不能完全迁移到新红点。因而我的新红点设计成支持老红点，新功能采用新红点系统，老功能则在迭代修改时，逐步替换成新红点。设计完成后，新红点功能稳定易上手，轻易推广到公司的其他两个团队项目中。
|
||||||
|
- 20年时我有一年的UE4开发经验，当时我先是参加了心动的夏令营活动，在坦克AI大赛，获得了第一名。然后加入了心动网络的翠星物语MMO大世界项目。当时我负责的是家园系统的功能开发。我当时设计优化重构了家具之间的碰撞检测规则，后期还额外负责清理UE4奇怪的错误日志，阅读底层源码，消除了100%的错误日志，和90%的警告日志。很遗憾的是这个项目在2022年砍掉了。
|
||||||
|
|
||||||
|
#### **冰风网络 | MMO 自研引擎游戏开发**（2022 - 至今）
|
||||||
|
|
||||||
|
**核心技术：C++、自研引擎、UI 框架**
|
||||||
|
|
||||||
|
- 负责 UI 相关功能开发，主动优化并**重构红点系统**，提高**维护性、扩展性**和**性能**。
|
||||||
|
- 问题分析
|
||||||
|
- 旧红点系统未建立**父子关系**，需手动更新上级节点，导致维护复杂且易出 Bug。
|
||||||
|
- **刷新方式低效**，每次 UI 变更均**全量计算红点状态**，带来性能开销。
|
||||||
|
- 优化方案
|
||||||
|
- **基于红点树重新设计系统**，支持 **与/或/非逻辑、条件节点、隐藏节点**，子节点可**自动影响父节点**。
|
||||||
|
- **缓存 + 增量刷新策略**：避免重复计算，减少无效更新。
|
||||||
|
- **延迟批量刷新**：脏节点**每秒合并刷新**，减少频繁触发父节点更新。
|
||||||
|
- **兼容旧系统**：新功能采用新红点逻辑，老功能逐步迁移，降低切换成本。
|
||||||
|
- 优化成果
|
||||||
|
- **减少约 30% 的重复红点逻辑**，提升代码复用性，降低维护成本。
|
||||||
|
- **计算开销减少约 50%**（缓存中间结果、增量刷新、批量更新），显著提升 UI 响应速度。
|
||||||
|
- **方案推广至公司另外两个团队项目**，标准化 UI 逻辑，提高团队开发效率。
|
||||||
|
|
||||||
|
------
|
||||||
|
|
||||||
|
### **问题解答**
|
||||||
|
|
||||||
|
数据是我结合对比新老红点，进行逻辑估算得出的。虽然没有进行严格的性能测试，但在实际使用中，UI 响应速度明显提升了。
|
||||||
|
|
||||||
|
1. **30% 的重复逻辑减少**来源：
|
||||||
|
- 旧系统：**所有 UI 组件手动监听并刷新红点状态**，代码高度重复。
|
||||||
|
- **新系统交由红点树自动管理**，简化红点逻辑，减少大量重复代码。
|
||||||
|
- **辅助功能（条件节点、隐藏节点、逻辑节点）**使代码更加简洁，减少冗余实现。
|
||||||
|
2. **50% 的计算开销减少**来源：
|
||||||
|
- **缓存中间计算结果**，避免父子节点**重复执行相同逻辑**。
|
||||||
|
- **由全量刷新改为增量刷新**，只更新变更部分。
|
||||||
|
- **延迟刷新机制**：叶子节点频繁变更时，**父节点仅每秒刷新一次**，减少无意义的更新。
|
||||||
|
- **事件驱动**：统一处理**道具变化、等级升级**等性能敏感事件，避免无效计算。
|
||||||
|
|
||||||
|
### **冰风网络 | 自研引擎 MMO 游戏开发**
|
||||||
|
|
||||||
|
📅 **2023.08 - 2025.02** | **游戏开发工程师**
|
||||||
|
|
||||||
|
**职责**：前期负责 **UI 开发**（红点系统优化），后期转向 **核心系统（剧情、战斗、寻路、技能）** 开发与优化，内测阶段专注 **游戏品质提升 & 疑难 Bug 修复**。
|
||||||
|
|
||||||
|
#### **核心开发 & 质量优化**
|
||||||
|
|
||||||
|
- **UI 框架优化**：重构 **红点系统**，采用 **红点树结构（支持条件节点 & 增量刷新）**，计算开销降低 **50%**，提升 UI 响应速度。
|
||||||
|
- **剧情系统**：优化 **相机运动 & 游戏接口**，**消除相机抖动**，增强沉浸感。
|
||||||
|
- **战斗系统**：优化 **受击特效、飘字、目标锁定**，提升打击感 & 操作反馈，使战斗更流畅。
|
||||||
|
- **寻路优化**：改进 **寻路算法 & 路点网络**，**解决大地图卡死问题**，提高寻路效率。
|
||||||
|
- **技能系统**：优化 **施法逻辑 & 摇杆控制**，提升战斗精准度 & 流畅度。
|
||||||
|
- **游戏品质提升**：内测期间专注修复 **核心 Bug & 复杂问题**，大幅提升产品稳定性。
|
||||||
|
|
||||||
|
**技术栈**：C++, UE4, UI 框架优化, 路径寻路, 战斗系统
|
||||||
|
|
||||||
|
------
|
||||||
|
|
||||||
|
### **心动网络 | UE4 大世界 MMO 游戏开发**
|
||||||
|
|
||||||
|
📅 **2019.08 - 2020.07** | **游戏开发实习生**
|
||||||
|
|
||||||
|
#### **家园系统开发**（团队协作）
|
||||||
|
|
||||||
|
- **家具碰撞检测**：优化检测算法，性能提升 **20%**。
|
||||||
|
- **伙伴 AI**：独立实现 **自由移动、交互 & 行为树控制**。
|
||||||
|
- **UE4 工具链扩展**：优化策划数据配置，提升开发效率。
|
||||||
|
- **日志优化**：清理 **100% 错误日志**，修复 **90%+ 警告**，降低调试成本。
|
||||||
|
- **技术分享**：撰写 **4 篇技术文档**，总结优化经验。
|
||||||
|
|
||||||
|
#### **家园工坊系统（核心贡献）**
|
||||||
|
|
||||||
|
- **建造 & 改造**：支持 **敲墙、砌墙、房间抬升/下沉**，动态调整结构。
|
||||||
|
- **智能家具摆放**：优化检测逻辑，支持 **墙壁、天花板、地面吸附**。
|
||||||
|
- **墙体透视优化**：建造模式下自动隐藏遮挡墙体，提高可视性。
|
||||||
|
- **碰撞检测优化**：采用 **四叉树加速**，减少无效计算，提高检测效率。
|
||||||
|
|
||||||
|
**技术栈**：C++, UE4, AI 行为树, 物理碰撞, 四叉树优化
|
||||||
|
|
||||||
|
------
|
||||||
|
|
||||||
|
### **引擎架构研究 & 关键模块开发**
|
||||||
|
|
||||||
|
📅 **2023.08 - 至今** | **个人技术探索**
|
||||||
|
|
||||||
|
🔗 [GitHub 项目]()
|
||||||
|
|
||||||
|
- **C++ 反射 & 序列化**：构建高效 **反射系统**，支持 **序列化 & 反序列化**。
|
||||||
|
- **XMake 多模块架构**：开发模块化 **游戏引擎架构**，提升可维护性。
|
||||||
|
- **渲染系统优化**：基于 **Vulkan** 设计 **Framegraph**，优化渲染流程。
|
||||||
|
- **资源管理优化**：改进 **RHI 资源管理**，提升加载 & 渲染性能。
|
||||||
@ -15,7 +15,7 @@ modification date: Wednesday 8th January 2025 13:56:02
|
|||||||
|
|
||||||
- 对资源进行垃圾回收
|
- 对资源进行垃圾回收
|
||||||
- 这样死循环判断是否性能不太好
|
- 这样死循环判断是否性能不太好
|
||||||
- 看错了，这是在资源主线程中，每秒回收的
|
- 看错了，这是在资源线程中，每秒回收的
|
||||||
- 感觉实际上回收时间可以延长一点，因为有时候需要使用预加载功能
|
- 感觉实际上回收时间可以延长一点，因为有时候需要使用预加载功能
|
||||||
- 每个资源的回收时间应该不一样吧
|
- 每个资源的回收时间应该不一样吧
|
||||||
- 同时提供一个切换地图时的主动回收
|
- 同时提供一个切换地图时的主动回收
|
||||||
|
|||||||
@ -160,3 +160,13 @@ modification date: Saturday 4th January 2025 11:22:39
|
|||||||
- 需要能让资源还能正常组装，而没有深度依赖
|
- 需要能让资源还能正常组装，而没有深度依赖
|
||||||
- 需要知道何时加载完毕
|
- 需要知道何时加载完毕
|
||||||
- 可以由异步切换到同步
|
- 可以由异步切换到同步
|
||||||
|
# 功能分层
|
||||||
|
## 内存管理 + 多线程
|
||||||
|
- 每个线程应该使用独立的内存管理
|
||||||
|
- 资源加载 序列化和反序列化
|
||||||
|
- 多线程 + 序列化 + 反序列化 + 内存管理
|
||||||
|
- 使用帧内存
|
||||||
|
- 帧内存改成资源内存
|
||||||
|
- 使用临时内存
|
||||||
|
- 不会就去抄别人的引擎啊
|
||||||
|
-
|
||||||
Loading…
Reference in New Issue
Block a user