下载 App

生成正面、背面、侧面,可以走动的角色形象

05/053 浏览
当前 NPC 角色编辑器的数据结构
编辑器使用 32×32 像素画布,数据结构大致是:
3 个朝向:正面、背面、侧面
2 个动画状态:静止(idle)、行走(walk)
每个状态可以有多帧,支持帧率控制
每帧本质上是一个 32×32 的颜色数组
要解决的 3 个问题
步骤 问题 方案
1. 图片→编辑器 128×128 PNG 导入为 32×32 像素数据 加载图片后逐像素采样(每4×4取1像素),写入 CharData 格式
2. 正面→背面/侧面 从一个视角推导其他视角 用 AI 图片生成(以正面图为参考,描述"背面/侧面"),生成后同样导入
3. 静止→行走 生成走路动画帧 AI 生成 2~3 帧不同腿部姿势的变体,逐帧导入
具体流程设想
原始图片 (128×128)
    │
    ├─ AI 生成 → 正面站立 (已有)
    ├─ AI 生成 → 背面站立 (参考正面图,提示"同一角色背面")
    ├─ AI 生成 → 侧面站立 (参考正面图,提示"同一角色侧面")
    │
    ↓ 每张图
  缩采样 128→32  →  写入 CharData 的对应 [朝向][idle][帧1]
    │
    ├─ AI 生成 → 正面行走帧×2~3
    ├─ AI 生成 → 背面行走帧×2~3
    ├─ AI 生成 → 侧面行走帧×2~3
    │
    ↓
  同样缩采样  →  写入 CharData 的对应 [朝向][walk][帧1~3]
技术难点
像素读取:UrhoX 中可以用 Image:GetPixel(x,y) 读取图片像素颜色,这部分没问题
AI 一致性:AI 生成的背面/侧面可能与正面风格不完全一致,像素风格比写实风格好控制一些,但仍需要人工微调——这恰好是编辑器的用途
色彩映射:128×128 缩到 32×32 后颜色会更丰富(混合色),需要决定是精确保留还是映射到调色板最近色
结论
完全可行。流程是:
AI 批量生成 3 朝向 × 2 状态 的像素图 → 自动导入编辑器 → 用户在编辑器里微调
需要给编辑器加一个 “导入图片” 功能按钮,选择图片后自动缩采样并填充到当前朝向/状态的帧数据中。
右键拖拽平移
一、问题本质 不是平移公式写错,而是 UrhoX UI 库指针事件派发的两个不对称陷阱叠加: 陷阱 现象 根因文件 OnPointerMove 不向父冒泡 右键按下 isPanning_=true,但 move 事件永远到不了 mapView urhox-libs/UI/Core/Widget.lua(OnPointerDown/Up 有 parent 冒泡,OnPointerMove 没有) H
官方
4 赞
穿透层修复
经验一:CSS transform 穿透层修复模式 问题本质 当容器使用 CSS transform: translateX/Y/scale 平移/缩放子树时,即使父容器有 overflow = "hidden",引擎的命中检测可能不裁剪越界区域。如果 transform 后的子树有更高的 zIndex,它会在视觉范围外拦截其他兄弟节点的指针事件。 受影响的场景 地图编辑器(右键平移/滚轮缩放后)
官方
4 赞
【日常更新】支持2人、3人、4人对战截图
【日常更新】支持2人、3人、4人对战
优化了排行榜显示玩家昵称
3 赞
图片加载三层优化设计
目标场景:地图编辑器"物品/墙体/地面/房间/人员"调色板弹窗的图片首帧显示 文档目的:沉淀"图片为什么慢、怎么治、发布后玩家体验如何、未来加资源时 preload_groups 怎么取舍"的完整结论,避免重复踩坑。 一句话结论 WASM 下图片"慢"不是单一问题,而是下载 / 解码 / 上传 GPU 三件事全堆在"玩家点弹窗那一刻"做导致的。优化的本质是把这三件事提前到启动期做(让玩家点的时候图
官方
1 赞
地图编辑器仿真 tick 重建抑制
UI 重建频率 = 事件分发的可靠性上限。 只要有一帧 SetRoot 销毁了正在处理 pointer 事件的控件,跨重建边界的 Down/Up 对就会被吞。高频仿真 tick 必须在 UI 边界按页面过滤。 关键代码(scripts/main.lua HandleUpdate) 四步走:先原地处理人员 → 聚合所有仿真 changed → 地图页强制压制 → 只放行显式/登录态变化。 -- ma
官方
4 赞
修复"地图编辑器刷新数据丢失"
问题诊断过程 用户报告:编辑器建好房间 → 保存 → 刷新页面 → 进编辑器 → 数据全没了。 关键线索:用户发现"校园日"模式刷新后能看到房间,但一进编辑器就没了。 这直接指向了编辑器页面自身的初始化逻辑,而非持久化链路。 根因 地图编辑模式.lua 的 EnsureBlankEditorLayout() 设计意图是"首次打开编辑器提供空白画布",用模块级布尔 editorLayoutClear
官方
4 赞
以鼠标为锚点缩放
核心数学原理 缩放前后,鼠标指向的那个世界坐标点必须保持在同一屏幕位置。 已知:旧缩放 oldZoom、新缩放 newZoom、鼠标锚点屏幕坐标 (ax, ay)、当前偏移 (panX, panY) 步骤1:算出旧缩放下鼠标指向的世界坐标 wx = (ax - panX) / oldZoom wy = (ay - panY) / oldZoom 步骤2:新缩放后反解新偏移,让 wx/wy
官方
1 赞
地图编辑器地面交互与视觉优化
一、问题链 用户截图反馈了三个递进的问题: 问题 1:点击地面类型(如食堂地砖),弹窗不关闭,挡住画布无法操作 ↓ 修复 v0.10.94 问题 2:地面贴图太大,一块地砖比小人还宽,比例失调 ↓ 修复 v0.10.96(改配置值) 问题 3:改了配置值后刷新仍然太大——旧存档的 tileSize=256 优先级高于新 config ↓ 修复 v0.10.97(反转渲染优先级) 二、关键代码
官方
4 赞
槽位变更只走原子方法
经验 下标 = 视觉格子,空槽是合法状态。定长 9 槽,inventory[i]=nil 即第 i 格空着,中间允许空。任何"把物品往前挪/压缩/重排"的操作都会让"你看到的格子"和"数组真实下标"脱节 → 物品消失。渲染直映 inventory[i],数据层绝不重排。 稀疏表禁用 #。带 nil 洞的表 #inv 是未定义的(可能=0 直接读成空包,或=洞前边界)。所有遍历上界一律 Player
官方
4 赞
四个原则(数据驱动、组件化、组合优于继承、对象池)
四个原则(数据驱动、组件化、组合优于继承、对象池)确实是系统从"能跑"到"能维护"的分水岭。 先看看你的游戏现状,再说怎么落地。 你的游戏现状分析 你的《自由的校园》不是传统战斗游戏,但已经有大量"对抗性交互": 已有机制 对应战斗系统概念 主角投掷物品(粉笔、扫把) 投射物 / 技能 行为违规 → 目击 → 怀疑累积 Debuff 叠加 冲突事件 → 保安响应 Boss 技能 / AI 响应链
官方
4 赞