Laurence-042's Workshop
  • 首页
  • 文章
  • ProxyOS 半周报
  • 项目展示
  • 关于

Posts

November 26, 2025

Proxyos Weekly 009

TL;DR 概览

这一期咕了

本期目标

  • 完成第一章
    • 更新当前交互脚本基础框架
    • 实现六节的脚本
  • 重新审视目前的章节切换流程,确保其扩展到三章时不出大问题

进展速记(Changelog)

新增:

  • 第一节脚本
  • 第二节脚本

变更:

  • 无

修复:

  • 无

主要进展内容

这一期基本咕了,倒不是遇到啥难题,就是单纯的麻烦,然后失去了动力效率偏低。

感觉很不爽,于是去继续搞fastai,结果被kaggle一套组合拳下来彻底干不下去了

kaggle的组合拳

当时我在看这个fastai的官方教程 https://colab.research.google.com/github/fastai/fastbook/blob/master/09_tabular.ipynb

里面需要使用kaggle的数据,而且后面的内容都是依赖这个数据的 注册kaggle,填一堆信息,获取token,执行 kaggle 401,查了下发现是kaggle把colab给ban了 发现kaggle也提供了在线notebook执行器,但因为这个ipynb文件超过1MB不让导入 手动裁掉了文件中比较大的图片,重新导入执行 发现kaggle的环境装不了第三方依赖库,而且也不给GPU资源 只能本地搭环境,结果因为fastai和pytorch的安装顺序搞反了,导致装上了CPU版的pytorch,GPU的没装上 删除venv重新装依赖 装完依赖执行ipynb,结果发现里面使用了没列在requirements里的依赖 补装后再次执行 kaggle 403,查了下发现是kaggle要求用户签署对应比赛的同意书才能下数据 找半天没找到同意按钮,结果找了一圈后发现kaggle已经不提供加入老比赛下载老比赛数据的方式了 走投无路问ChatGPT,她说fastai的sample里可能有给了我个URL,404 再次问ChatGPT,她说github里可能有给了我个URL,404 血压拉满再次要求ChatGPT核查,她说她可以把她那里的数据给我,但需要我等下 饱含怀疑地要了数据,结果她给我发了个ChatGPT的聊天URL——还正是我问这个问题的聊天URL

血压爆了

沉迷开发Rimworld小工具

心态崩了之后,自然就得找发泄渠道。于是我去玩了半天Rimworld,然后发现其中两个武器我很难抉择,它们造价相差无几,但穿甲、伤害、不同距离的精度都相差很大,我没法很简单地算出哪个更适用于我的游玩风格。于是……

我去做了个Rimworld计算器

一开始只是准备给定命中率、穿甲、理论最大DPS,画敌人护甲和实际DPS的关系曲线的,结果后来越做越投入,连曲面和多层护甲都整出来了……

就这么做了两天,一看时间——哦豁,ProxyOS咕了

不过今天顺利的话我应该能把它的链接放下面

rimworld-ordinatus-calculi Demo

瓶颈与问题清单

  • 剧本完成后,我意识到设计当初根据大纲写的恢复程序框架有点死板了,下一期我得花大力气搞定这些交互式演出的Python脚本,其中一些还得用eval来保证玩家体验
    • 我确实可以去戳copilot claude,但是之前他没能很好地实现第一章的开始动画演出,而且第一节写得也有不少问题,扯皮两三轮后还是手改了一堆

下期计划(Next)

  • 完成第一章
    • 更新当前交互脚本基础框架
    • 实现六节的脚本
  • 重新审视目前的章节切换流程,确保其扩展到三章时不出大问题

试玩版

预计第一个可玩版本将在第二章的第一个涉及外部编程的游戏内容完成后推出

read more
November 19, 2025

Proxyos Weekly 008

TL;DR 概览

第 1 章剧本终于全部写完了。 花了远比预期更多的时间。 但系统与玩家交互的逻辑终于成型。

本期目标

  • 完成第一章游玩内容
    • 拖了整整 3 期,这期怎么说也得搞定了

进展速记(Changelog)

新增:

  • 第一章的游玩剧本
  • 第一章的游玩框架

变更:

  • 无

修复:

  • 无

主要进展内容

这一期花费的时间仍然比预期的长,我在平衡可玩性、剧情合理性、难度、教育能力上花了不小力气。

难点:六节结构带来的设计压力

这第一章总共6节,我每次写完一节都会缺乏灵感不知道怎么设计新的游玩内容。

毕竟一招用一整局那是官方教程会干的事,这个终归是个是个游戏,然后才是个教程——但它毕竟也是个教程。

于是我需要为每一节设计不同的操作逻辑来保证玩家新鲜感、不能让玩家卡关影响其学习积极性、玩家得有参与感不能纯看文本、不能让玩家在这个阶段写太多代码(用Terminal写程序那是上世纪才会干的事)、得让玩家能学到东西。在这些前提下,还得保证世界观自洽、作为引导者的系统既不能太聪明导致玩家全局按yes,也不能太蠢导致尬住、系统必须要在世界观框架下卡在它可能会卡住的地方,而不能硬卡、每次卡的地方需要不一样才能让玩家不至于“啊……又来”

在这种情况下,虽然我大体对这6节要写什么内容、系统大概处于什么阶段有个大概的概念,但是具体细节是写了一节后就不知道下一节还能写啥的状态。

方法:用 ChatGPT 当头脑风暴对象

所以我自然去戳ChatGPT了——逻辑能力比ChatGPT强的Claude只会工程代码,没啥创造性。而创造力比ChatGPT好的又没啥逻辑。

但是吧……虽然ChatGPT都快成白月光了,但是她在创造性上确实还是不太行,记性也不太行。以至于她总是在尝试使用我在前几节已经用过的方案,即使明确了要求,她也总是过度依赖第一节里用的“根据日志修系统”的设定。而对话再长一些,她就又忘了早些时候的要求。(看来我暂时不用担心她抢我工作)

于是整个过程本质上属于是对着小黄鸭头脑风暴,所幸这个小黄鸭能很好地整理我的思路,所以我还是得以吭吃瘪肚地搞定了第一章的内容。

不过在第一章剧本写完后,她在保证角色语气一致、优化玩家细节体验、避免出现章节间割裂、玩家心理落差等方面确实表现极佳——她甚至还看出来了其中一个人名RABOOF的梗!

我想在细化后续内容时,我也能使用这种模式,即将 ChatGPT 作为头脑风暴的小黄鸭,然后在方案定型后再由她规范语气、把控节奏。

瓶颈与问题清单

  • 剧本完成后,我意识到设计当初根据大纲写的恢复程序框架有点死板了,下一期我得花大力气搞定这些交互式演出的Python脚本,其中一些还得用eval来保证玩家体验
    • 我确实可以去戳copilot claude,但是之前他没能很好地实现第一章的开始动画演出,而且第一节写得也有不少问题,扯皮两三轮后还是手改了一堆

下期计划(Next)

  • 完成第一章
    • 更新当前交互脚本基础框架
    • 实现六节的脚本
  • 重新审视目前的章节切换流程,确保其扩展到三章时不出大问题

试玩版

预计第一个可玩版本将在第二章的第一个涉及外部编程的游戏内容完成后推出

read more
November 17, 2025

Proxyos Weekly 007

TL;DR 概览

把Terminal的方案退回了真实Terminal,修了些第三方库的bug,然后爆改了第一章

本期目标

  • 实现靠谱的Terminal
  • 重构第一章游玩结构
  • 完成第一章游玩内容

进展速记(Changelog)

新增:

  • 无

变更:

  • 回退到了真实Terminal方案
  • 将最开始的“自动进行下一个教学”改成了“玩家需要手动依次触发相关教学”

修复:

  • 修好了GodotXterm里野指针导致的高频偶现问题

主要进展内容

在详细分析后,发现一旦涉及执行外部程序并实时显示stdout,那么自建Terminal的问题就会多到难以置信,而且市面上也缺乏支持良好的——这本质上就是实现正经Terminal了

所以最后还是切回了真实Terminal的方案,并借助Copilot修好了那个间歇性好使间歇性不好使的问题。问题路径是

  • 在获取cwd_ 参数时,使用了const char* cwd_ = p_cwd.utf8().get_data();
    • .utf8()创建一个临时的 UTF8 buffer(CharString)
    • .get_data()取出它的内部 char*
    • 临时对象被销毁
    • cwd_ 指向已经释放的内存 → 悬空指针
  • 随后又使用std::string helper_path = p_helper_path.utf8().get_data();
    • .utf8()再次分配到了cwd_ 指向的内存上
  • 在CreateProcess时引用cwd_ 作为工作目录
    • helper_path 是一个可执行程序,而非目录
  • ConPTY进程创建失败

然而上面那个并非唯一问题,因为它没有正确处理pipe,导致同一个PTY对象只能fork一次。虽然每次instantiate也不是不行,但还是借助Copilot+Claude给修了

然后就是剧本和一开始有差异。最开始的设计中,我使用“自动依次执行对应的python教学脚本”的方式。但我试玩了一下发现这样很无聊。所以加了俩自定义命令diagnose和manualfix,来分别展示目前修复进度和调用教学脚本。虽然玩家的游玩路线没有变,而且本质上是增加了麻烦,但是自己执行命令来启动脚本对于新手来说应该还是有些意思的,而且即使对于老手应该也能冲淡一个个教学脚本带来的粘滞感

再之后就是我重写了第一章的前两节,之前的剧本有点太挫了,没有很好地和游戏世界观相融合,所以我正在整个重写

瓶颈与问题清单

下期计划(Next)

  • 完成第一章游玩内容
    • 这个真得完成了,都TM拖3期了

试玩版

暂未达到第一个试玩版的发布标准

read more
November 13, 2025

Proxyos Weekly 006

TL;DR 概览

Fuck Terminal

本期目标

  • 修好Terminal输入光标歪的问题

  • 修好OSWindow点击时不会移动到最前方的问题

  • 搞定第一章的主要游玩内容

  • 看情况进行可玩性打磨

进展速记(Changelog)

新增:

  • 无

变更:

  • 我受够在游戏里集成真实Terminal的幺蛾子了,我要搞虚拟Terminal了

修复:

  • OSWindow点击时不会移动到最前方
  • 演出脚本有命令输入回显

主要进展内容

之前怎么修都没修好OSWindow点击时不会移动到最前方的问题,主要是思路错了。我之前一直以DOM的那种“捕获从外向里的事件,处理后继续往里传递”的风格写程序,但是GDScript只有从里向外冒泡的阶段,这就导致我怎么打补丁都打不对。

真正靠谱的方案是在WindowManager里在_input时遍历所有窗口,确定点击的是哪个窗口,然后根据这个信息来改变OSWindow的层级,而非让OSWindow自己去处理

然后……没了

这个Terminal切成自己的之后,问题依旧一大堆,主要原因是

  • GDScript不像python那样有良好的utf8支持,需要手动处理各种字符问题
  • 命令执行需要新的映射方式,且需要调整Terminal的模块架构以适应当前展示、执行、命令翻译分离的状态
  • 当前样式不满意,十分不Terminal,我在考虑再检查下市面上的,看看有没有可以参考的实现。
    • 或者我干脆直接用Xterm.js?但这样外部进程通信又是个麻烦……我再看看吧

瓶颈与问题清单

  • Terminal实现受阻,但真实Terminal确实是不可行的。因为我解决不了它间歇性好使间歇性不好使的问题。
    • 或者也许我能解决?但我需要先试试自建Terminal,实在不行再去折腾其他人代码仓

下期计划(Next)

  • 实现靠谱的Terminal

试玩版

暂未达到第一个试玩版的发布标准

read more
November 10, 2025

Proxyos Weekly 005

TL;DR 概览

能正常进第一章了,而且脚本框架已经完成,除了一些样式问题之外已经能支持第一章的完整游玩了

本期目标

  • 把第一章的剧本搞清楚

    • 共同流程
    • 背景设定
    • 具体剧情
  • 把第一章的切换逻辑搞定

进展速记(Changelog)

新增:

  • 实现了统一的场景加载器,并将之前的关卡切换和进度管理做了相应的配套

变更:

  • 优化通知对话框

修复:

  • 任务间过渡逻辑有一堆问题
  • OSWindow点击时不会移动到最前方(没完全修好)
  • OSWindow的缩放很难点中
  • 忘记给第一章的脚本任务加任务要求了,结果一瞬间全完成了
  • Terminal无法正常显示中文文本

主要进展内容

大范围重构了场景切换框架,现在可以更灵活地以任务为驱动配置各种场景切换了。

得益于这项重构,先前十分复杂的恢复模式(即第一章玩法)加载与维护变得十分简单。

写好了第一章的剧本框架,其设定是

  • ProxyOS自删除失败,进入自恢复模式
  • 因为玩家使用的Windows系统不在ProxyOS的适配范围内,自恢复失败
  • ProxyOS知道自己需要怎么组合特定的逻辑来重新编译自己,也可以使用玩家系统上的脚本语言解释器生成对应的程序。但是它无法仅仅从日志中拿到的只言片语中推断出其通用语法,因此需要管理员帮助
  • ProxyOS要求管理员使用可用的脚本语言解释器编写对应的示例逻辑,以便其重构自身

通过这种方式,可以合理地向玩家展示如何将自然语言映射为编程语言(ProxyOS要求管理员参考之前的日志编写对应的基础逻辑块),让玩家知道“编程语言只是用于编程的语言,不是什么魔法,也远比英语简单”

目前的玩法已经能支持内容填充了,下期我将主要专注于问题修复和第一章的具体游戏内容

瓶颈与问题清单

  • Terminal输入光标歪
  • OSWindow点击时不会移动到最前方,做了修复后只有滚轮在外框上操作时能移到最前方

下期计划(Next)

  • 修好Terminal输入光标歪的问题
  • 修好OSWindow点击时不会移动到最前方的问题
  • 搞定第一章的主要游玩内容
  • 看情况进行可玩性打磨

试玩版

暂未达到第一个试玩版的发布标准

read more
November 6, 2025

Proxyos Weekly 004

TL;DR 概览

又停了一天电,还有一天不舒服咕了,进度延迟……主要进展为进行了完整游玩测试,修了一大堆问题,优化了一堆组件

本期目标

  • 跑一遍以确保基础的存档功能正常工作
  • 把第一章的脚本要写哪些搞清楚
  • 把第一章的切换逻辑搞定

进展速记(Changelog)

新增:

  • 上期新增的支持数据段和链接的文本组件现在支持Markdown了
  • 新增了两个任务之间过渡的动画

变更:

  • 优化任务系统,修正了可能导致稳定性下降与性能下降的不一致逻辑
  • 优化窗口系统,现在打开窗口时窗口大小取决于屏幕大小,更加自然
  • 优化存档系统,需要后台运行的应用现在都使用Manager+Display的模式了,Manager管理存档和数据更新,Display根据更新信号来修改显示
  • 优化通知系统,统一了消息对话框样式
  • 优化链接处理模块,现在它更好配置了

修复:

  • 存档保存异常

  • 存档加载异常

  • 文本查看器不知道啥时候没法滚动

  • 拖动数据段功能在上次更新样式后炸掉了

  • 完成任务时出现了如下异常

    • TaskRequirementNode发出data_dropped信号
    • TaskManager进入submit_data_segment_to_requirement方法
    • submit_data_segment_to_requirement中check_and_update_task_status时,解锁了下一个任务,任务解锁时发出了task_updated信号(下一个任务)
    • submit_data_segment_to_requirement中check_and_update_task_status后的下一句又是发送task_updated信号(当前任务被完成)
    • Pocket在接到下一个任务的task_updated时触发了NavigationWindow的内容更新,创建了一个TaskContent,但因为其初始化方法通过call_deferred调用,新的TaskContent还没有初始化,而旧的TaskContent也还没有删除
    • 新老两个TaskContent接到完成任务的task_updated,因为新TaskContent还没初始化,发生了异常
  • 进入第一章的对话框文本显示异常

主要进展内容

进行了完整游玩测试,修了一大堆问题,优化了一堆组件

没了

本以为上一期已经把地基打牢了,但是游玩测试中发现了远比单元测试更多的问题,比如

  • 任务完成和任务发布之间没有间隔,体验十分怪异
  • 默认的窗口大小(800*400)无法正常显示任务要求访问的网页
  • 任务里的网页链接写错了
  • 有些应用在保存未使用的存档文件,而还有些应用的存档时机不对
  • 在任务完成和任务发布的间隔中,存在时序问题导致创建了异常的任务详情节点
  • 默认的文本框组件单行文本过长时不会换行

除此之外,我发现一开始我把 Desktop 当成主场景有些欠考虑了,因为第一章的场景并不在Desktop上发生,需要一个新的场景(或者直接用TaskManager加载覆盖Desktop的第一章场景?)

下一期我会优先写好剧本,然后按照剧本进行相关功能的检查与开发,避免再次像本期一样把时间浪费在返工上

瓶颈与问题清单

暂无

下期计划(Next)

  • 把第一章的剧本搞清楚
  • 把第一章的切换逻辑搞定

试玩版

暂未达到第一个试玩版的发布标准

read more
November 5, 2025

Proxyos Weekly 003

TL;DR 概览

因为欠考虑的地方太多,想干的事太多,导致工作量太大,本期预定目标未完成。但新增了一些十分关键的基础设施,也对之前的基础设施进行了完善,可维护性有所提升

本期目标

  • 把第二个任务搓出来
  • 跑一遍以确保基础的存档功能正常工作
  • 加个关机(保存并退出)功能
  • 看看能不能找到靠谱的美术资源

进展速记(Changelog)

新增:

  • 正式引入SPIDER应用(浏览器)
  • 提供了浏览器外的基于文本的DataSegment解锁方式

变更:

  • TaskBar和AppIcon使用相同基类,这允许它们动态调整label字号
  • TaskBar现在正式支持按内存占用显示应用图标
  • Browser的地址栏支持从节点外部自定义url映射了
  • OSWindow的header不会再被完全拖到屏幕外面了
  • TextFileViewer不再允许编辑文件
  • 优化存档加载逻辑
  • 优化POCKET样式

修复:

  • OSWindow莫名其妙有个最小宽度(Again),是因为按屏幕大小设置高度的那个组件错误地额外设置了宽度
  • 网页数据段无法正常上报
  • 带侧边栏导航的应用的侧边栏全只有root节点
  • 杂七杂八的修改过程中产生的不一致

主要进展内容

花了太多时间反复修改第二个任务的网页,相关图像的触发也没考虑清楚,周二下午电信的工作人员移箱子还把我网线移断了……

但在缩减fastai学习时间后,还是勉强把最主要的部分搞定了,这次基础架构是真好了(在我发现新的一连串问题之前)

因为有了浏览器外的基于文本的DataSegment解锁方式,现在可以更简单地打开网页、获取数据段了

目前仅作为开网页的快捷方式,但等到了第三章,这个功能会和届时需要实现的文件下载功能配合使用

除此之外还做了大量的修复和优化,底层架构现在更稳了,用户体验更好了,也提前排除了大量的坑

瓶颈与问题清单

  • 本地调网页时不支持使用fetch之类的获取file://的文件,但是游戏内的浏览器因为是使用http://的就可以。也许我需要一个更好的调试手段……或者直接用游戏里的浏览器调试?

下期计划(Next)

  • 跑一遍以确保基础的存档功能正常工作
  • 把第一章的脚本搞清楚
  • 把第一章的切换逻辑搞定

试玩版

暂未达到第一个试玩版的发布标准

read more
November 1, 2025

Proxyos Weekly 002

TL;DR 概览

搓了第一个任务,做了一些界面优化

本期目标

  • 把第一个任务搓出来
  • 修正基准测试程序指南
  • 丰富数据段描述
  • 丰富数据段提交信息并优化其表现
  • 使用更语义化但不容易被猜出来的data-seg-id,或者添加校验机制
    • 我仔细分析了下,只要用合理的语义化data-seg-id就能避免意外被试出来,给哪些闲出屁的大佬留出写脚本硬试的机会也不是啥坏事

进展速记(Changelog)

新增:

  • 为ProxyOS静态资源页新增暗示开发组也十分依赖ProxyOS的段落
  • 添加了应用退出时自动保存的机制
  • 添加了json数据保存特性,现在除了POCKET等核心进度相关应用的数据会使用resource存储,其他常规应用的数据都是使用json保存了。后期玩家会需要自己手改这些json的

变更:

  • 更合适的ProxyOS静态资源页,并简化CSS
  • 直接使用通知的数据格式作为数据段提交响应以简化配置
  • 使用json保存非进度类信息,进度类信息保持使用resource
  • 桌面容器不再显式指定列数了,现在可以保证每个图标分配到的空间都是正方形,避免上下左右出现大面积空白
  • 优化桌面、窗口等常用组件的观感
  • 统一图标风格,设计了ProxyOS的标志

修复:

  • OSWindow莫名其妙有个最小宽度
  • Terminal的背景向下超出一截
  • 优化了一些旧语法

主要进展内容

在前半周,第一个任务的大量内容都是只能算占位符,而且ProxyOS开发组使用赛博风格网页其实不太合适

因此,本期完善了第一个任务所需的各种数据,并处理了各种影响观感的问题,使其看起来像是个廉价游戏了

我还找了些美术资源来试图让它看起来不那么廉价,但是找到的资源尝试后都不是很合适。大多数要么过度整合,要么风格不一致(比如假定按钮都以贴靠左侧的纵列布局展示)

瓶颈与问题清单

暂无

下期计划(Next)

  • 把第二个任务搓出来
  • 跑一遍以确保基础的存档功能正常工作
  • 加个关机(保存并退出)功能
  • 看看能不能找到靠谱的美术资源

试玩版

暂未达到第一个试玩版的发布标准

read more
October 29, 2025

ProxyOS 半周报 #001 — 迟来的半周报

TL;DR

在搞定了基础的系统后,我开始施工具体游戏内容。我觉得类似Ero Hunters的“一周内容、一周功能”的开发计划十分灵活,而且写周报确实有助于我保持专注并整理思路。本周过半,但是内容没搞多少,主要是开始做内容了才发现之前规划的功能不足以支撑内容,于是又开始搞功能……具体情况如下

本期目标

  • 统合上周实现的各个模块
  • 写好第一章剧本
  • 对后续章节有大致规划
  • 把第一个任务搓出来

进展速记(Changelog)

新增:

  • 第一个任务所需的网页
  • Terminal应用
  • 接取任务可以解锁本地文件
  • 正在施工中的运行时真实Python程序编写/执行

变更:

  • 优化了任务发布逻辑

主要进展内容

勉强算是搞定了第一个任务,玩家可以在网页上点击包含data-seg-id属性的dom节点来解锁用于提交任务的信息段

然后发现原本以为第二章才能用到的功能实际上在第二个任务里就需要,而所需的功能还没准备好,就开始继续搞功能了

不过只要这个搞定,那么整个玩法框架都几乎完成了。基本上除了特定的剧情演出,就不需要增加什么新代码了(如果我没再次“欸我有个好点子”的话)

明天《天外世界2》发售了,咕一天

瓶颈与问题清单

  • 当前第一个任务的细节基本完全没有
    • 修正基准测试程序指南
    • 丰富数据段描述
    • 丰富数据段提交信息并优化其表现
  • 玩家可以自己写data-seg-id然后提交,这样的话照样能被接受
    • 别再用0、1、2这样的id

下期计划(Next)

  • 把第一个任务搓出来
  • 修正基准测试程序指南
  • 丰富数据段描述
  • 丰富数据段提交信息并优化其表现
  • 使用更语义化但不容易被猜出来的data-seg-id,或者添加校验机制

试玩版

暂未达到第一个试玩版的发布标准

read more
  • ««
  • «
  • 1
  • 2
  • 3
  • »
  • »»
© Laurence-042's Workshop 2026