- 博客(16)
- 收藏
- 关注
RSS订阅原创 GCS 如何用可视化内容创作与 FlowGraph，重新定义卡牌肉鸽游戏的创作方式
GCS 将可视化内容创作、FlowGraph 玩法编排与 Monitor 运行观测整合进同一条工作流，145 个内置节点覆盖卡牌、状态与敌人意图，让创作者能够更直观地构建、验证和持续调整卡牌肉鸽玩法
2026-08-04 18:07:12
325
原创 跨场景事件：没人聊但人人踩的持久化问题
Unity场景与事件系统的持久化矛盾是开发多场景游戏时的常见痛点。静态事件会导致幽灵订阅，实例事件难以跨场景通信，而DontDestroyOnLoad方案存在初始化顺序和重复对象问题。GameEventSystem（GES）通过ScriptableObject事件资产和可视化生命周期管理，从根本上解决了这一矛盾，这种架构使开发者能够专注于游戏逻辑，而非底层事件管理的基础设施问题
2026-04-06 12:15:39
636
原创 调试不可见的东西：为什么事件系统需要自己的可观测层
本文探讨了Unity游戏开发中事件系统面临的可观测性挑战，包括调试困难、性能分析不足、依赖关系模糊等问题。当出现"玩家捡起钥匙门未开"等间歇性Bug时，传统调试工具难以追踪事件链路。文章分析了现有工具（如Debug.Log和Profiler）的局限性，并提出了GES系统的双工具解决方案，这套方案通过增强事件系统的可观测性，解决了重构恐惧、递归循环等痛点，为开发者提供了更高效的调试工作流
2026-04-06 12:15:11
544
原创 上线才发现的事件系统坑：内存泄漏、数据污染、递归陷阱
本文总结了游戏事件系统常见的七类问题：孤儿订阅导致内存泄漏、跨会话数据污染、递归触发事件、丢失调度句柄、Lambda陷阱、错误移除所有监听器以及昂贵谓词评估。这些问题在规模化时会导致性能下降、内存泄漏和逻辑错误。文章提出了关键解决方案：严格遵循OnEnable/OnDisable配对模式来管理监听器生命周期，避免使用匿名委托，谨慎处理跨会话状态，并对条件监听器的谓词进行性能优化。这些实践能帮助开发者在QA阶段前预防大多数事件系统相关的问题
2026-04-05 11:34:56
396
原创 运行时构建事件流：当可视化编辑器不够用的时候
文章探讨了程序化生成内容中的事件连接难题，提出了传统方案的局限性和理想解决方案，包括问题核心、现有方案缺陷、理想方案特性以及GES解决方案，该方案特别适用于Roguelike地牢生成、动态AI行为和Mod支持等需要运行时事件拓扑变化的场景。
2026-04-05 11:34:29
440
原创 执行顺序的隐患：‘谁先响应‘背后的 Bug
本文深入剖析了游戏开发中常见的事件系统执行顺序问题。当玩家受到伤害时，UI可能显示错误血量值，这种"执行顺序Bug"源于监听器注册顺序的不确定性。文章指出原生C#事件系统的结构性缺陷：执行顺序取决于脚本加载顺序、场景层级等不可控因素，导致"先数据后视图"原则难以强制执行。此外还揭示了条件执行带来的性能损耗、跨场景持久化问题以及Lambda表达式可能导致的内存泄漏。最后介绍了GES监听系统的解决方案，通过四种监听器类型和确定性执行管线，解决了事件顺序、条件过滤等核心问题
2026-04-04 12:58:59
391
原创 时间驱动事件：为什么协程不适合做延迟和循环
摘要：Unity协程的痛点与GES调度方案 Unity协程在实现时间驱动逻辑时存在多个痛点：简单延迟功能迅速膨胀为大量样板代码，需要手动管理协程引用、空检查、状态标志；缺乏生命周期回调机制，无法区分自然完成和被取消；重复性任务管理复杂；协程与GameObject绑定导致脆弱性问题。GES框架提出了一种基于事件调度的替代方案，通过RaiseDelayed()等方法提供简洁API，自动处理取消、状态追踪和参数捕获，解决了协程的诸多缺陷。该方案将调度逻辑与事件系统深度集成，显著减少了时间驱动行为的管理复杂度
2026-04-04 12:58:32
368
原创 并行还是顺序：每个事件系统都需要的两种执行模式
本文探讨了游戏开发中事件处理的并行与顺序执行难题。通过玩家死亡流程的案例，揭示了传统Unity事件系统的局限性，文章分析了并行执行的异常处理和优先级问题，以及顺序协程在复杂度增长时难以维护的困境。针对这些问题，提出GES解决方案的两种核心模式，这两种模式可在可视化流程图中混合使用，解决了游戏逻辑中常见的"并行开始但部分步骤必须顺序完成"的需求，如死亡特效同时触发但重生必须按步骤执行的情况
2026-04-03 09:21:01
416
原创 看不见的事件链：你无法调试看不见的东西
事件驱动架构虽然解耦了系统，却带来了严重的可见性问题：执行流变得不可见且难以调试。本文揭示了这一"脏秘密"及其具体表现，这种可视化工具让原本隐式的事件链变得显式，大幅降低了调试和学习成本。其他领域(如CI/CD、数据工程)已证明可视化执行流的价值，游戏开发领域也终于有了相应工具
2026-04-03 09:20:38
368
原创 告别 if-else 地狱：可视化条件逻辑的正确打开方式
游戏开发中，条件判断（if-else）的快速繁殖会导致代码难以维护。原型阶段简单的if语句在正式开发中会演变成复杂的条件网络，这种状况导致迭代效率低下，策划调整简单数值也需要程序员介入重新编译。 Visual Condition Tree提供了一种可视化解决方案，通过AND/OR分组和比较节点构建布尔逻辑，支持四种数据源类型：事件参数（支持5层深度属性访问）、场景对象引用、随机值和常量值。该系统使非程序员也能直观地创建和修改复杂条件，无需代码或重新编译，大幅提升开发效率
2026-04-02 16:42:32
398
原创 策划不写代码也能配事件：设计师与程序员的协作问题
在传统 Unity 开发流程中，事件响应通常写死在代码中，导致策划每次调整参数都需要程序员介入，形成“改代码 → 编译 → 测试”的低效循环。GES 的 Behavior Window 将事件响应的配置完全可视化，通过可视化方式支持条件判断、延迟执行、循环调度、多 Action 绑定，让策划无需写代码即可独立完成玩法调优。这种模式实现了明确的职责分离：程序员只负责“何时触发事件”，策划负责“如何响应事件”。不仅显著提升迭代效率，还从根本上解决了团队协作中的瓶颈问题，使游戏调优从分钟级缩短到秒级
2026-04-01 12:18:14
405
原创 5 分钟上手：从零搭建你的第一个事件驱动系统
本文提供一份极简上手指南：在约 5 分钟内，从安装 GES、初始化系统，到创建事件、编写发送端脚本，并通过 Behavior Window 配置接收端，实现一个完全解耦的事件驱动交互。核心流程是“事件资产连接发送者与接收者”，无需直接引用即可完成通信。随后可扩展到带类型事件、自定义数据与复杂逻辑。其价值在于以极低成本建立可扩展的事件架构，为后续功能与系统解耦打下基础
2026-04-01 12:17:49
387
原创 当你的项目有 200 个事件：为什么组织管理会崩溃？
当事件数量从几十增长到上百时，Unity 项目中的事件管理会从“可记忆”迅速演变为“不可控”：命名混乱、重复创建、缺乏类型与状态信息、难以追踪使用关系，最终拖慢开发效率。传统方案如命名规范、文件夹或文档都无法长期奏效。GES 通过多数据库架构将事件按模块拆分，并基于 GUID 实现安全重组与无冲突协作；配合 Event Editor 提供分类、类型、搜索与状态可视化等工具，实现高效检索与批量管理。其核心价值在于让大规模事件系统保持可维护、可扩展与团队协作友好
2026-03-31 17:19:36
397
原创 零反射、零 GC：“高性能“事件系统到底意味着什么?
多数事件系统的“高性能”并无统一标准，真实瓶颈来自反射调用、装箱拆箱、GC 分配与字符串匹配，尤其在移动端与 VR 中会放大为明显卡顿。GES 通过在初始化阶段将可视化条件编译为 Expression Tree 并生成原生 delegate，实现运行时零反射、零 GC、接近直接方法调用的性能。基准测试显示其在事件分发与条件评估上远快于反射方案（最高约 250 倍），且随规模增长仍稳定。结合分区、短路与批量控制等策略，GES使可视化与极致性能不再冲突，达到工程级“零开销”标准。
2026-03-31 17:18:55
407
原创 Unity 泛型序列化之墙：类型安全的事件不该有样板代码税
Unity 无法序列化泛型，导致 GameEvent<T> 无法在 Inspector 使用，开发者被迫为每种类型手写具体类，产生大量可预测却易错的样板代码，甚至破坏架构一致性。常见方案如放弃类型安全或手动维护，都存在明显缺陷。GES 通过在创建事件时自动生成具体类与绑定代码，彻底消除样板代码，并保持类型安全与可视化工作流。其提供预生成类型覆盖大多数需求，自定义类型也能即时生成支持，配合维护工具处理协作与升级问题，实现高效、可靠的事件系统工程化方案
2026-03-30 20:04:01
884
原创 告别隐形意大利面：为什么你的事件系统正在拖垮项目？
修改一个方法名竟导致全线崩溃？你可能正面临 Unity 开发中最隐蔽的“隐形意大利面代码”。本文深度剖析传统 C# 事件与 UnityEvent 的三大致命缺陷：隐形依赖、重命名静默失败及跨场景通信地狱。并分享一种基于 ScriptableObject + GUID 保护的现代事件架构方案，实现真正的视觉化解耦与零风险重构，助你把脆弱的代码串联变成健壮的资产化架构
2026-03-30 18:07:45
1102
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人