下载 App

修仙文明-开发日志02

修改于10/176 浏览
本期进展
性能归因和长局验证。 凌晨保存了源码冻结清单,并对主地图绘制进行 full / map-off 对照,各完成 180 帧采样和 554 项断言。关闭主地图绘制后,回调间隔的 wall p95 从 91ms 降到 33ms,地图绘制相关采样归零,说明地图绘制是这次测试环境中 wall 时间的重要来源;这不是 GPU 或真机性能结论。长局方面,seed 1、88、137、2026、654321、98765 分别推进到 300、400、500、600、700、200 年并留下检查点。经济自测在 4 个种子上各通过 52 项,日志仍标注长局覆盖为 PARTIAL。
青岚三十格地图。 将地图目标落实为 6×5、每格 100 里,并交付 assets/image/qinglan30/ 的 30 张格图、总览图和 metadata;同步写成《青岚三十格世界环境规划》。规划明确本轮只制作青岚流域环境底图,人物、建筑、道路等由玩法运行时叠加,不预画在地形中。移动端集成检查覆盖地图协议、流式、投影与命中等项目,记录为零失败;这些检查不等同于 GPU 或美术验收。
纪事内容与阅读界面。 补充经济、政治、山河、妖兽、修行、人生等纪事模块,并把纪事接入相关系统。desktop-final 完成 37,489/37,489 项断言,推进到第 40 年,保留 345 条纪事,最短记录 2,051 字。之后增加 UI_ONLY、窄屏和双人详情页检查:桌面与窄屏首轮各有 2 项失败,修正后桌面、窄屏、矮屏均通过 1,184/1,184 项。境界桌面验收为 50/50;众生闭合与人生记录、人口索引等检查也留下通过记录。
人物、HUD 与性能回归。 建立人物身份、劳作、修行、归属、年度账本与回放等模块,并完善众生索引和面板。紧凑 HUD 的动效检查通过 180 项。晚间性能回归中,visibility 的 CPU 采样 p95 从 4.626ms 降到 0.569ms;UI 专项 45/45 通过,报告记录 HUD 重复 SetStyle=0。这次回归有明确的局部收益,但不代表整帧性能已达标。
问题与风险 人物名册桌面端未收口。 people-v2-desktop 有 7 项失败,集中在功法页控件、所得正文和人物地图定位;复测报告随后超时,最高单帧约 26.3 秒。同期移动端为 2,798/2,798 通过。14 日结束时,没有证据证明桌面端原失败用例已解决。 存档容量约束已显现。 当日出现“模拟人物留卷空间不足”导致年度回退;另一次独立导入检查因籍册保守 JSON 预算超过 1.5MB 而失败。两者都指向人物与纪事数据增长后,预算、存档提交和年度事务需要一起验证。 性能报告不能只看断言。 多份报告断言通过,但总结果仍为 FAIL,因为 frame spike 被计为引擎错误。采样设备为 llvmpipe 软件光栅,wall 间隔包含调度和 sleep,不能据此宣称真实设备帧率或 GPU 耗时达标。 验证覆盖仍有缺口。 seed 77001(目标 1050 年)和 2147483000(目标 1200 年)没有长局 segment;地图 cell 图片缓存命中率为 0%,单张首载记录约 104–270ms。卡牌查重文件还记录了 6 条重复项,涉及 #56、#147、#240、#322。 阅读布局存在溢出告警。 纪事正文、事件面板和窄屏列表都出现过子元素超出容器,以及 ScrollView 零高度告警。逻辑断言通过不代表这些尺寸问题已经在所有屏幕上消失。
下期计划
  1. 拆分年度演化和存档工作预算 把年度模拟与存档从一次性长任务改成可分步恢复的工作单元,避免人口、人物账本或大存档在单帧中占用过多时间。
为年度演化建立显式任务状态:准备、逐阶段计算、验证、提交或取消。每次恢复只处理预算允许的工作量;未完成年度只写入私有草稿,不更新正式世界、年份、繁荣、人口账本和纪事。 为存档写入建立分段流程:冻结待保存状态、计算编码数据、写临时文件、回读校验、准备备份、原子替换目标文件。记录源档版本和内容指纹;保存期间若槽位、原档、权限或任务所有者发生变化,应终止本次任务,不能覆盖新数据。 将取消与提交做成互斥状态:提交前取消要清理本任务的临时文件并保留原档;提交开始后按事务结果处理,不能把已替换的文件误报为未保存。多个保存任务并发时,不得删除或提交其他任务的临时数据。 为验证、序列化、解码、磁盘写入、回读、备份、重命名和恢复都加入预算检查。未变化的状态应避免重复完整校验、重复编解码和无效磁盘写入。 对旧档格式、备份恢复、只读模式、存档尺寸上限、外部修改、短写、损坏字节、回读不一致、备份失败、替换失败及恢复失败分别设计注入测试。所有测试写入隔离测试路径,不使用玩家原档。 **计划验收:**同步保存与分步保存得到相同世界数据;在每个写入阶段注入失败或取消,原档和有效备份仍可恢复;年度任务被取消后正式世界没有半年度状态,继续时不漏年、不重年。
  1. 解决人物留卷与存档容量的增长风险 在继续扩充众生和人物历史前,先明确索引、年度账本、人生事件、纪事和整档的容量边界,避免空间不足时丢失身份或让年度事务反复回退。
分别测量籍册 JSON、年度账本、人生记录、纪事快照、序列化副本及备份的体积,区分逻辑数据大小、编码后大小和运行时峰值内存。 用人口数量、年份和事件密度构造递增负载,绘制数据增长曲线;测试接近 1.5MB 籍册预算及接近整档 8MB 限制时的保存、开卷、复制、恢复和查询成本。 检查人物 ID 区间压缩、年度节点共享、事件索引及查询重放是否能保持身份稳定和来源可追溯。只有不改变公开语义的冗余数据才能压缩;不得裁掉重要事件、重新分配已有 ID、静默重置姓名或把群体统计推断成某人的个人经历。 预算耗尽时显示明确原因、占用分类、是否已提交和安全恢复方式;设计年度回退提示,保证用户能辨别最后一个完整年份与被放弃的草稿年份。 **计划验收:**在预算上限附近进行旧档往返和故障恢复;确认身份映射、人物历史和纪事快照不变;超限时原档保持可读,并能明确指出失败边界,不允许自动清空或覆盖。
  1. 建立可解释且不可重复刷分的文明目标评分 把繁荣、资源、魔气/妖气、境界人口、升阶星评等评分所依赖的数据源和规则固定下来,使分数可复算、可解释,且缺失数据不会被伪装成零或高分。
为每个指标定义唯一权威来源、单位、取值范围、未知状态、计算公式、权重、扣分条件及其与其它指标的归属关系。真实存粮和修行资源不得用财富替代;修士总数和五境界人数不得重复计分;魔气和妖气需要区分来源、正负影响及健康区间。 建立固定的指标注册表和分组预算,分别验证各项贡献、组内小计、总分上限和版本号。为每项保留原始值、归一化结果、实际积分、上限和原因文本,支持从 HUD 打开解释。 把当前文明等级与历史升阶记录分开:人数不足时按规则退阶;只有整段演化真实完成后才能记录一次星评;重复提交同一阶段不得重复加分;退阶不得抹除真实历史;旧档缺少证据时不得补造星级。 为新档、旧档、缺字段、损坏字段、超大数、负数、重复结算、跨年恢复、连降和多次查询编写纯逻辑回归。验证保存前后分数和解释一致。 **计划验收:**相同状态重复评分完全一致且不修改世界;未记录字段显示“未知/未记录”;同一真实升阶最多冻结一次;总分可从各指标重新算出,且无重复归因。
  1. 实现“人人如龙”的长期目标规则 将“凡人亦可天地同寿”设计成需长期维持的世界目标,而非只看一次总分的通关按钮或免死效果。
明确公开传承、凡人修行机会、粮食与修行资源、污染与杀伐、生态、境界文明等条件的当前值、目标值、计量口径和未达成原因,并提供逐项解释。 设计连续稳定年数:只有全部必要条件满足时才能累计;发生失守时依规则中断或重置,并记录原因及发生年份。旧档缺少依据时不补算此前已满足的年份。 定义年结算顺序:完成当年经济结算,检查世界条件与资源,再支付长生护持成本,最后处理后续人口死亡。支付不足时不得追溯保护已经结算的死亡;相同年度重入不能重复支付或重复授予护持。 把连续年数、护持状态、已支付年份、资源成本和最近失守原因写入存档协议。覆盖年初重入、跨档续跑、护持失守后重新建设、资源不足、灾害/战争、预算中止和恢复续跑。 **计划验收:**短时达到条件不能提前完成目标;连续期限必须逐年证明;护持只在条件持续成立且本年付款成功后生效;失守、死亡和资源不足按已定义顺序处理,并可在保存恢复后复现。
  1. 接入 HUD、阅读界面与地图显示模式 把文明评分与因果解释放进现有界面,同时修复滚动、溢出和窄屏可读性问题。
在文明 HUD 附近规划目标指标入口及排行榜入口,保持地图和主要操作区可用。指标解释需要展示名称、数据来源、当前值、目标值、得分归属和缺失原因;弹窗必须在可视区域内。 适配道藏收纳盘、卡牌列表、人物名册、人物详情、功法正文、人生记录和纪事详情。为各自的滚动区域给出明确高度,处理安全区、逻辑分辨率、窄横屏、短屏和大字号;修复 ScrollView 零高度和子元素超过容器的问题。 检查真实触摸滚动、拖拽卡牌、打开与关闭详情、人物定位地图、窄屏目录进度和相邻篇章导航。不能只依赖控件存在性断言,要验证实际点击后的内容与目标一致。 为地图增加只显示环境和建筑的查看方式,并明确人物、兽群、势力标记及迁徙线何时隐藏。分别验协议/流式加载、资源可见、实际画面和美术质量,不以纯逻辑地图检查替代图像验收。 覆盖桌面、手机竖屏、手机横屏、平板横屏和竖屏;将交互失败、布局告警、帧时尖峰分开记录。 **计划验收:**每种尺寸下主要按钮可达,文本可读,列表可滚动,弹窗不越界;人物定位指向正确个体;地图显示模式不修改模拟或玩家存档。
  1. 支持演化进度观察与安全中止 在长时间演化期间提供可信进度反馈和取消方式,并与分段年度事务、存档任务共同工作。
展示当前处理年度、已完成年度、阶段名称和任务状态;进度只在相应工作真实结束后前进,不把草稿阶段报告成已提交年度。 提供取消入口,并定义其对年度任务、自动保存、待提交档案及 HUD 状态的影响。重复取消、取消与继续同时触发、取消发生在写入提交边界等情况都要确定行为。 取消时保留最后一个完整年度,丢弃未完成的年度草稿;恢复时显示实际保留年份,并从正确的下一年继续。繁荣、人口、账本、志向年数、纪事和升阶星评不得多结算一次。 增加进度提示的跨设备布局与可读性检查,并将演化逻辑正确性、帧时性能和用户反馈分别验收。 **计划验收:**分别在年度开始前、阶段处理期间、年度完成待提交时和保存准备期间取消;检查当前年、存档字节和关键世界字段,确认没有半年度状态,并能在后续恢复。
  1. 设计玩家公开主页与在线天榜 为文明成绩提供自愿公开渠道,但避免上传私人历史、自动上榜或在云请求超时后意外覆盖高分。
制定公开资料白名单,只包括文明分数、当前阶段、目标指标摘要、真实升阶记录及玩家主动选择的头像预设。人物姓名库、人生事件、私人经济账本、卡牌手牌和整份存档不得上传。 分离本地实时分数、账号历史最佳和云端排行榜状态。演化只更新本地候选值;只有用户明确选择上榜时才提交。提交前先读取账号已有最高分;分数降低时不得覆盖高分。浏览榜单、查看主页或更换头像不得改变积分。 实现分页榜单、本人名次、玩家主页、头像修改及明确的加载/空榜/错误/过期提示。榜单行使用精确账号 ID,昵称只从账号昵称服务取得;公开主页数据异常不能使合法分数行整体失效。 处理新旧数据版本、分页缺项、账号切换、并发提交、请求超时及“服务端可能已写入但客户端未收到回调”的不确定结果。未确认不确定写入结果前暂停同账号后续写操作;不自动重发可能导致历史最佳回退的请求。 先用独立 mock 覆盖竞态、超时、坏数据和禁网验证;之后再使用明确授权的测试账号单独联调真实云端,并确认验证/预览模式没有真实云写入。 **计划验收:**离线模式不联网;默认演化不写榜;手动提交只更新正确账号且不降低历史最佳;数据版本较新时拒绝覆盖;超时后按安全屏障等待确认;云端测试结果与 mock 结果分别记录。
  1. 扩写纪事并保障来源与阅读质量 扩展人物、妖兽、组织和世界纪事内容,同时确保叙事只基于实际事件,且长篇在桌面和窄屏均可读。
为每类故事明确可使用的事件字段和历史快照版本;没有事实来源的伤亡、灾害、因果和个人经历不得写成已经发生。 扩充人物经历、妖兽生态、组织演变、修行与年度世界事件等类别;检查章节衔接、不同角色视角、重开详情、邻篇跳转与历史快照一致性。 加入重复文案检查,重点检查相同卡牌、日期、人物或组织是否被错误复用;对风险提示区分“可能后果”和“已发生事实”。 验证目录、阅读进度、字号缩放、长文本滚动、窄屏布局和真实点击流程。内容真实性、逻辑断言、UI 交互、性能和文风审阅单独记录,不把一个断言总数当作完整质量结论。 **计划验收:**故事内容可回溯到有效事件与对应历史快照;相同输入不生成重复记述;桌面与窄屏可完成阅读、跳转、重开;性能尖峰单独标识,不掩盖内容或交互失败。
修仙文明-开发日志-01截图
修仙文明-开发日志-01
以「涌现 EMERGENCE」为命题的修仙文明演化沙盘 —— 玩家扮演执棋者,打牌投入变量,看世界在无数有思想的个体行为中自己长出文明。 本期进展 • 集成卡牌与年度演化主循环:209 张道卡、人口与社会经济模拟、瓶颈锁及文明形态变化。 • 完成十五格大地图、小地图、缩放与拖动;加入妖兽迁徙、捕食、争斗和共生等年度结算。 • 完成三槽存档、自动保存及损坏存档保护。当日官方构建成功。 问题与风险 •
5 赞
【童谣镇】聚光灯第二次开发日志截图
【童谣镇】聚光灯第二次开发日志
开发进度: 美术 1、主角人物立绘已细化完成 2、所有NPC的QQ人形象与呼吸动画已设计完成 3、大部分UI界面已设计完成 4、面包房建模与树屋建模以及基础房屋、路灯、树木模型已完成。 5、制作过场动效,制作通用动效材质ing 6、广场资产替换、永续桥和植被的资产替换、房屋资产替换,河流制作 7、学校模型的材质完成 8、石墩子、小道具模型制作ing 9、NPC正比胸像绘制ing 策划 1、任务系统
11 赞
10 回复
《卡牌工业》开发日志 01|从“涌现”到产线对打截图
《卡牌工业》开发日志 01|从“涌现”到产线对打
大家好,我们正在用 Godot 做一个暂名《卡牌工业》的游戏。目前已经跑通了最小的生产与战斗循环,也做了两轮迭代。这篇先记录一下:面对“涌现”这个题目,我们讨论过什么,又为什么最后收敛到卡牌和工厂。 第一步:头脑风暴,涌现可以是什么? 刚看到“涌现”这个题目时,我们的想法几乎朝每个方向散开了。塔防、物理搭建、探索、解谜、经济系统、叙事,甚至增量游戏,都能让简单规则在玩家的操作中长出新的结果。再想下
1 回复
00:34
《荒原复苏指南》开发日志④:关卡演示堂堂袭来!!截图
《荒原复苏指南》开发日志④:关卡演示堂堂袭来!!
- 人类曾因掌握元素合成技术而一度辉煌,又因滥用元素能量而逐渐从内里衰败。 - 30世纪80年代。社会文化充斥着激进乐观主义与庞大机械美学,在这里,污染和能源共生,幸福与痛苦并存。官方广播和宣传画里依旧在宣扬“科学将战胜一切”、“元素能量将再造新农田”的口号,而世界主城却已经因为污染过度而濒临崩溃、空间挤压严重。为了寻找新的生存空间与无污染能源,官方启动了“重构拓荒计划”。 - 玩家将作为前线拓展
18 赞
6 回复
《气味之城》开发日志#1|为什么"涌现"和猫是天作之合截图
《气味之城》开发日志#1|为什么"涌现"和猫是天作之合
大家好,我是一个人报名了 2026 聚光灯 21 天游戏创作挑战 的独立开发者。今年主题公布那一刻我就笑出了声——涌现。因为我已经想做这个游戏很久了: 《气味之城》:你不是猫神,你只是一只猫。 先说一个所有养猫人都懂的事实:你永远无法"教会"一只猫任何它自己不想学会的事。但你家猫可能自己学会了——听见冰箱开门就瞬移到厨房;你心情不好时过来踩奶;凌晨三点准时在你身上练马拉松。没人教过它,这些行为是它
3 赞
6 回复
【2026聚光灯日志01】什么叫你把手牌,骰子和战棋融合了?截图
【2026聚光灯日志01】什么叫你把手牌,骰子和战棋融合了?
大家好啊,我是官方小编,一位还在学校的独自开发的苦逼带学生 这次算是第二次正式参加GameJam,而这回的比赛主题是【涌现】 嗯…老实说,一开始我还真只是从中文语义上来看,理解成“大量的出现”,直到询问ai哦哦哦我这就才想起来还有英文的“整体大于部分之和”意思来着 说起这个主题的意思,立马想起的类 吸血鬼幸存者 ,或者是 文明 系列的各种爆怪,爆兵的设计,即大量的出现敌人或者单位 而从第二个
4 赞
4 回复
00:07
雨天決行 开发者日志02-人工智能的自我修养截图
雨天決行 开发者日志02-人工智能的自我修养
又和大家见面啦!第二篇日志,说实话一开始不知道该怎么编排,但团队里惊喜的成果越来越多,我们已经迫不及待把更新的内容端上来给大家啦!那么事不宜迟,快来看看都有什么新情报吧ദ്ദി˶ー̀֊ー́ )✧ 一.美术(重磅升级) 以主美小为的生命力作为燃料(bushi)本次美术组取得了大进程!首先是各个ui界面的优化和细化,上次大家看到时还只是初具雏形的草稿,现在大多都完整起来了哦! 同时,随着配色的补全,手
43 赞
36 回复
修仙文明-开发日志05截图
修仙文明-开发日志05
本期进展 年度演化逐段执行与事务校验。 推进协作式年度工作预算、分段提交和异常回退验证,重点检查年度中止或提交失败时,正式世界状态是否仍停在最后一个完整年度。CivSimulationBudgetValidation 多次运行记录分别为 154,380、104,485、94,333 项检查通过;CivEvolutionCancelValidation 记录 1,598 项主动终止检查通过。各报告计
5 赞
5 回复
00:30
《失心》游戏开发者日志01|游戏UI迭代及实机演示截图
《失心》游戏开发者日志01|游戏UI迭代及实机演示
进入《失心》之前,玩家首先看到的是我们工作室 UNLOOK 的标识。我们将原来的标识转成 SVG,并让其中的红色瞳点转动、观察,再逐步显露完整字形,希望这个短暂的开场能带出一点好奇和不安。 这次《失心》的开局 UI,我们围绕小灵通(因为游戏的主要交互道具就是小灵通)做了几轮调整,希望玩家从打开游戏开始,就能感受到故事里的年代和气氛(故事年代背景为2000s)。 早期版本先确定了一个方向:把菜单放进
15 赞
10 回复
00:10
群迹·上取其下,下取其上截图
群迹·上取其下,下取其上
#聚光灯gamejam开发者日志 向大家汇报一下今日进度,目前在和蚁群的默认移动算法进行斗智斗勇。或许是我的AI对蚂蚁有别样的理解,其实最初写出的方案更接近于围绕着恒星公转的行星。 哦我还以为文章里可以插入多支视频视频,想要展示一些其它的运动方式,可惜了。那么就简单在上方传一个比较典型的,有点类似于蟑螂的运行方式。 目前仍在解决蚁群的随机运动,和玩家可操纵性之间的平衡问题。以及如各位所见,目前的
4 赞
1 回复