Game

代码:升变

程序已然错乱,规则由你改写

UnityC#RoguelikeShader Graph

实机截图

选择码文界面
01码文选择界面 —— 词条携带增益与缺陷,装配到组件
战斗画面
02上升电梯上的战斗,面对如潮水般涌来的敌人
战斗画面
03子弹行为效果:分裂 / 追踪 / 环绕
战斗画面
04组件与词条叠加,构筑独特的战斗流派
装备界面
05装备界面 —— 头部 / 背部 / 手部 / 腰部组件配置

核心亮点

🔩

化 BUG 为神力

每个 Kodo 代码残片同时携带强化词条与潜在缺陷,玩家要接受缺陷、把它转化为力量,而非追求纯增益。

🧩

可组合的词条系统

词条 × 组件 × 叠加构成海量构筑流派。核心挑战是如何让「组合爆炸」被一套解耦的架构驯服。

⚙️

主程 · 团队协作

作为主程,负责程序架构与核心系统实现,与美术、策划协作,在十天内完成可游玩的 demo。

核心思考

DESIGN & ENGINEERING
01

词条组合爆炸:如何驯服「千变万化」

问题

Kodo 残片带有随机的强化词条与潜在缺陷,能装配到不同组件上,还能相互叠加。词条数 × 组件数 × 叠加层数,组合会指数级膨胀——如果照搬「每种效果写一份逻辑」的做法,代码根本写不完,加一个新词条就要改动十几处。

思考

问题的本质,是「一个词条是什么」和「它作用在谁身上、叠加了几层」被写死在了同一段代码里。要让它能自由组合,就必须把「效果」与「装配」这两件事解耦。

解决

把每个词条做成独立、可配置的行为单元,运行时由装配管理器根据装配关系动态组合,效果层统一解耦执行。新增词条,只需要改配置,不动核心逻辑。

反思

解耦解决了「能不能组合」,却没能解决「组合出来平不平衡」——有些词条叠加后强得离谱。这让我意识到:系统设计不只有技术,还有数值与边界的权衡。这是做完之后仍然想继续挖的地方。

数据驱动ScriptableObject 配置装配管理器效果解耦
词条组合爆炸:如何驯服「千变万化」 架构图
02

子弹行为:分裂 / 追踪 / 环绕 / 爆炸

问题

词条会产生分裂、追踪、环绕、爆炸等多种子弹行为,且同屏弹体数量巨大。如果每种行为各写一套,既重复,又难以控制性能。

思考

这些行为「长得不一样」,但「子弹从生成到销毁」的生命周期是一样的。把它们抽象成同一种东西的不同行为,就能统一管理。

解决

统一的子弹管理 + 对象池复用弹体,把「怎么飞」抽成可替换的行为策略。

策略模式对象池弹体生命周期管理
03

斜行电梯:移动平台上的物理稳定性

问题

战斗发生在不断上升的斜行电梯上。角色在移动平台上容易出现抖动、穿透、手感崩,比例尺不统一会进一步放大这些问题。

思考

移动平台的物理本质是「平台在动、角色相对平台静止」,但物理引擎默认按「各自独立运动」处理,两者关系需要被显式地维护。

解决

统一比例尺,物理步长统一于 FixedUpdate,移动平台采用 kinematic 处理,让角色稳定附着在平台上战斗。

统一比例尺FixedUpdate 物理步长Kinematic 平台
04

循环进化:跨局保留最强构建

问题

Roguelite 要求「成功后保留最强 Kodo 进入下一轮」,但 Kodo 是运行时动态组合出来的,如何把局内的临时构建可靠地留到下一局?

思考

需要一个「跨局状态」的出口,把局内临时的构建结果序列化成可持久化的状态。

解决

独立的存档系统,将最强构建序列化持久化,让「最强 Kodo」真正进入下一轮循环。

状态序列化存档系统

技术细节

引擎Unity 2022 LTS
语言C#
平台PC / Web
URPShader GraphScriptableObjectAddressablesObject Pool

分层架构:表现层(URP / UI / 3C)→ 逻辑层(战斗 / 敌人 AI / 码文词条 / 物理)→ 核心系统层(EventBus / ObjectPool / SaveSystem)→ 数据资源层(ScriptableObject / Addressables)。

运行时架构图

外部链接