Insomniac's Acton Rejects OOP as Abstractions Cripple Big Game Teams

Insomniac技术总监Acton摒弃面向对象编程：抽象拖垮大型游戏团队 深层面向对象类层次结构带来人为复杂性，拖慢工作室工程进度，唯有贴合硬件的数据转换才是应对规模化开发的唯一可行模式。 主持人Casey Muratori与Insomniac Games引擎总监Mike Acton展开对话，探讨技术领导力、软件架构以及面向数据设计的理念。Acton驳斥了大规模编程必须依赖重度面向对象抽象的说法，解释了不必要的概念负担如何增加复杂性并降低AAA团队的性能表现。讨论涉及诸多实际工程挑战——从《日落过载》（Sunset Overdrive）中的开放世界流式加载预算和Maya管线瓶颈，到归档文件格式记录的必要性。Acton还阐述了他的招聘观点，认为求知若渴与刻意、一次性的每日练习是杰出工程师的核心特质，随后详述了他在分析和调试空间数据库时采用的实证方法。 Mike Acton驳斥了大型软件团队规模化必须依赖面向对象编程层级的说法，指出经久不衰的历史系统依赖的是清晰的数据驱动接口而非继承。 (5:00) 诸如移动速度等关键游戏数值属于核心变量，它们根据物理磁盘带宽决定内存预算和流式加载窗口；在后期改动这些数值可能会让价值数百万美元的世界设计付诸东流。 (20:00) 求知若渴是Insomniac Games在招聘中唯一与应聘者未来成功持续相关的特质，而学历、成绩和常规编程测试几乎没有预测价值。 (55:00) 刻意的编程练习需要在此类简短的日常练习（如30分钟）后彻底丢弃写出的代码，而非去开发长期的业余项目，从而迫使核心技能不断精进。 (60:00)

Speaking at HandmadeCon 2015, Insomniac Games Engine Director Mike Acton argues that effective software engineering derives from physical hardware constraints, empirical data transformations, and relentless problem-specific context rather than abstract object-oriented hierarchies. Debunking OOP and the Myth of Elegance (5:00) Acton rejects the claim that deep object-oriented inheritance and conceptual abstractions are necessary to scale large development teams. At Insomniac, an engine group of roughly 20 engineers supports three to six productions simultaneously by prioritizing data layouts over abstraction layers. Acton asserts that compounding hierarchies only adds mental friction and makes code brittle, pointing out that historically enduring systems rely on simple input-output interfaces rather than heavy abstractions. He also criticizes the software industry's insecurity around mathematical elegance detached from concrete constraints. Citing Tommy Refenes's character controller math in Super Meat Boy, Acton defends pragmatic, hand-tuned solutions: if an empirical formula satisfies the player experience, it is an optimal engineering solution. Attempting to enforce realistic Newtonian physics or generic patterns where they do not belong wastes time and produces worse results. Keystone Variables and Physical Production Budgets (14:59) Technical teams must identify and lock down 'keystone variables' early in production because foundational gameplay parameters dictate physical hardware budgets. In open-world titles like Sunset Overdrive, fixed mechanical disc or drive read speeds establish a hard throughput limit. Traversal speed directly determines the streaming time window between asset chunks; altering baseline player speed from 10 m/s to 15 m/s dramatically shrinks streaming budgets, potentially forcing a studio to discard a year of environment art. Acton stresses that technical leads must force creative teams to commit to these variables or explicitly accept the massive financial cost of later changes. Documenting Internal Data and Preserving Architecture (33:04) Acton highlights data primacy: because runtime behavior is derived downstream from source data layouts, documenting internal file formats is crucial even for closed, proprietary systems. Modern tools often treat data as opaque black boxes, worsening the already difficult task of long-term archival and drastically increasing the cost of future platform ports. Citing Electronic Arts' 1980s IFF standard as an example of clean data documentation, Acton advises that teams document schemas incrementally during change reviews rather than during bug crunch at ship time. Furthermore, Acton criticizes the industry's failure to read foundational hardware manuals, such as Intel, AMD, or ARM architecture guides. Developers cannot expect systems to operate efficiently without understanding the physical platform targets. The Context Advantage of Small Teams (45:00) Acton warns independent developers against copying generic AAA architectural patterns, such as arbitrary actor-component models seen in Unity or Unreal. Large studios introduce complex abstractions partly to handle massive, distributed organizations. A small team's primary competitive advantage is deep, specific context. Tailoring an engine to a specific game—such as building an editor button that places ladders only where valid geometry exists—radically accelerates iteration compared to manipulating generic objects in a heavy engine harness. Curiosity, Practice, and Empirical Debugging (55:00) Evaluating candidate engineers, Acton found that university pedigrees, grades, and standard coding test scores fail to correlate with job success. The sole reliable predictor is an insatiable, self-directed curiosity that leads a developer to thoroughly investigate technical topics. Furthermore, he emphasizes deliberate daily practice over passive learning. Real practice requires discarding the code afterward—such as rewriting an Asteroids clone in 30 minutes from scratch repeatedly—to prevent an exercise from turning into an unfinishable hobby project. This empirical rigor extends to debugging. While analyzing Insomniac's SpatialDB, Acton logged runtime entry points to create an offline, scrubbable test harness. Feeding real gameplay query logs into an offline plane clipper not only eliminated the need to boot the full game client, but instantly exposed a hidden geometry-clipping bug across thousands of real-world cases. Acton contends that physical typing accounts for less than one percent of an engineer's job, rendering complaints about boilerplate or explicit data-oriented layouts irrelevant compared to the core work of understanding problem spaces.

Insomniac Games 引擎总监 Mike Acton 认为，软件工程的根本在于理解硬件限制与具体数据转换，深层抽象和面向对象范式不仅无法应对大规模团队开发，反而会制造认知冗余并掩蔽工程事实。 破除面向对象与抽象神话 (5:00) Acton 驳斥了“面向对象编程（OOP）是大团队跨规模协作所必需”的行业论调，直言该观点毫无经验与实证支持。历史上生命周期最长、扩展最成功的软件系统和代码库，普遍依赖清晰简单的输入输出接口，而非深层的继承层级。在成百上千人的团队中，层层封装与抽象会成倍放大认知摩擦，迫使后续开发者去理解人为构造的概念模型而非实际问题，最终导致代码脆弱、难以重构且性能低下。 针对游戏开发中对所谓“数学优雅”的盲目崇拜，Acton 以 Tommy Refenes 为例指出，针对特定手柄输入调校出的操控手感公式，其有效输出就是良好的玩家体验，属于完全正确且精准的工程解法；若强行引入牛顿物理等真实模拟，反而会产生不可玩、无乐趣的结果。Acton 强调，脱离硬件环境与具体业务约束去追求虚无的通用设计模式毫无意义，能准确解决当前问题的最简方案才是唯一合理的选择。 关键变量约束与团队生产代价 (14:59) 技术负责人必须尽早识别系统中的“关键变量”（Keystone Variables）并迫使团队尽早决策，因为底层物理约束会层层传导至整个生产线。以开放世界游戏《Sunset Overdrive》为例，主机的物理光驱或机械硬盘存在固定的寻道时间与带宽上限，当玩家移动速度从每秒 10 米提升至 50 米时，世界图块的流式加载（Streaming）时间窗口将被极度压缩，直接决定了内存预算、资产细化程度与关卡布局。 若团队在开发一年后才随意将移动速度从 10 米/秒调至 15 米/秒，流式加载预算骤缩将导致此前耗时一年搭建的环境资产全数作废，给几十至数百人的团队带来数以百万美元计的返工损失。反之，若早期预估过于保守，后期留出过剩的性能冗余，又会导致游戏场景单调空旷，无法充分利用硬件潜力。Acton 警告，绝不能抱有“最后阶段再来优化”的侥幸心理，创意团队若无法立时拍板，也必须明确承担日后推翻改动的巨额工期与财务成本。 数据优先、文档化与资产长效保存 数据是驱动系统运行的核心输入，系统的运行时行为完全派生自底层数据布局。Acton 提出，只要底层源数据格式清晰，任何工程师都能推导并还原系统的全部运作逻辑。然而，现代游戏行业在文档沉淀上严重退步，鲜有工程师会通读 Intel、AMD 或 ARM 的官方硬件手册，对内部专用格式的记录也极为匮乏。像 Electronic Arts 在 1982 年制定的 IFF 标准那样规范、模块化的格式定义，在当今软件工业中已十分罕见。 若不在日常的代码审查流程中渐进式维护数据文档，而是拖延到项目交付前的修复 Bug 阶段，文档记录便几乎不可能落实。不透明的数据格式不仅直接阻碍了游戏历史档案的长期封存，更为十年后的跨平台移植埋下灾难性隐患；届时原班人马早已忘却实现细节，不得不耗费巨大成本逆向反推自身曾经写过的软件。此外，Acton 提及 Autodesk Maya 导出 Collada（XML）文本格式的管线瓶颈，在复杂动画序列下单次导出长达 30 分钟，严重制约了动画师的日常迭代效率，只能依靠拆分子资产并在内部工具中缝合来规避。 独立团队反过度通用化与招聘选拔 (45:00) 许多独立开发者常盲目照搬虚幻、Unity 或 3A 引擎的通用“Actor-组件”系统，Acton 认为这是忽视运作上下文的典型反模式。5 到 10 人的独立小团队核心竞争优势在于其业务上下文极其狭窄具体；与其在编辑器中手动拖入通用模型并附加梯子组件，不如依据固化的关卡规则直接制作“梯子生成按钮”，以 3 秒内的单次点击取代繁琐的通用实体装配。追求过度的通用性不仅拉低运行性能，更浪费了专有上下文带来的生产力红利。 在团队人才选拔上，Acton 梳理后发现应聘者的毕业院校、在校成绩、学历乃至编程测试得分，均无法有效预测其入职后的实际工程表现，唯一的可靠预测指标是“永不满足的求知欲”。相较于千篇一律的课后大作业，能够针对某一复杂技术主题彻底刨根问底、撰写详尽技术分析的人才更受青睐。同时，Acton 强调开发者必须建立如刷牙洗澡般严谨的日常刻意练习习惯，例如在 30 分钟内编写代码并在结束后彻底删除成果，避免练习沦为长期积累的个人业余项目，从而高频锻炼从零解决问题的肌肉记忆。 基于日志回放的离线可视化诊断 (63:52) 在优化 Insomniac 内部用于空间查询的底层机制“SpatialDB”时，Acton 放弃了直接抓取复杂内存快照的思路，转而记录该数据库所有变更接口（初始化、添加、编辑、删除）的操作事件流。借助这一轻量命令日志，开发人员得以构建确定性的离线回放工具，在微秒级别任意拖动时间轴，精确重构任意帧的数据库状态，并将测试流程解耦至轻便的笔记本或 Linux 环境下以子秒级速度运行。 为了将查询范围的多面体凸包直观呈现，Acton 调用多边形裁剪例程将包围盒沿各平面方程进行切割，却在回放真实数据集时意外渲染出破碎几何体。这表明问题并非出在 SpatialDB 本身，而是潜伏在共享多边形裁剪库中的隐蔽算法缺陷。Acton 指出，键入代码在程序员的日常工作中占比不足百分之一，核心精力应投入到观察、可视化与理解数据形态上；依托真实操作日志建立的可视化管线，往往能快速将罕见的几何边缘缺陷转化为可瞬时复现的离线测试用例。 Acton 倡导以严谨的数据认知、硬件物理约束以及刻意练习来重构软件工程实践，主张以最简方案对标具体问题。尽管这一理念在高性能引擎与特定工业领域展现出极高的执行效率，但如何在不具备全员高水准底层素养的大型异构团队中全面推行这一严苛标准，仍是一个持续存在的组织协同难题。

## Background 该视频由 Molly Rocket 于 2016 年 5 月 16 日发布在 YouTube 平台上。页面描述提供了 HandmadeCon 的官方网站链接，内容记录了在 HandmadeCon 2015 现场对 Insomniac Games 技术总监 Mike Acton 的深度访谈。 ## TL;DR 在本次对谈中，Mike Acton 结合在 Insomniac Games 带领 20 人核心引擎团队支撑多款 3A 游戏的经验，直言不讳地抨击了软件工程中对面向对象抽象和复杂心智模型的盲目崇拜。他深入探讨了诸如玩家移动速度与机械硬盘吞吐等硬件物理边界如何直接决定关卡资源预算，并强调了数据格式规范文档化对长期资产留存的关键意义。针对独立开发者和新人入行，他主张摆脱 3A 框架的生搬硬套、充分利用自身特定上下文，指出“不可遏制的好奇心”是筛选人才的唯一真理，并提倡每天进行 30 分钟“用后即删”的刻意练习。最后，他以自身排查 SpatialDB 与多边形裁剪器的经历说明，程序员的核心职责是捕获并理解底层真实数据，而非单纯敲打键盘写代码。 ## Atmosphere & style 整场对话气氛热烈、硬核且充满火药味，Mike Acton 以其极具标志性的犀利毒舌和直言不讳掌控了全场节奏，台下笑声与掌声接连不断。主持人 Casey Muratori 与 Mike 之间默契十足，两人在工程哲学上的高度共鸣让访谈宛如一场撕开工业界伪优雅假象的快意批判。从对“留到最后再优化”的愤怒驳斥，到对枯燥打字论调的爆粗嘲弄，听众能清晰感受到两位资深底层开发者对机器本质的纯粹敬畏与对务实工程精神的极致执着。 ## Bulletin - [05:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=300s) Mike Acton 驳斥了“面向对象继承是大型团队扩展唯一途径”的观点，指出生命力最持久的基础库（如 libc）均基于扁平的输入输出，深层对象层级只会隐藏关键信息并增加心智与维护负担。 - [16:32](https://www.youtube.com/watch?v=qWJpI2adCcs&t=992s) 开放世界设计的物理法则受制于磁盘寻道和流式加载带宽，角色的移动速度是直接决定地块数据预算、美术细节和关卡切分的关键核心变量，后期微调可能导致数百万美元开发资产作废。 - [55:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=3300s) 在招聘中，学历、笔试成绩等硬性指标与实际工程表现缺乏强相关性，不可遏制的好奇心与脱离作业要求的自主钻研成果是用人主管唯一看重的特质。 - [01:00:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=3600s) 针对程序员的刻意练习，Acton 提出应设定严格的 30 分钟限时，并在每次练习结束后立即将代码彻底删除，以防止练习演变成维护项目的业余爱好。 ## Key takeaways - [03:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=180s) 技术总监的核心价值在于充当杠杆放大器，通过架构评审、提出关键问题并辅导成员成长来提升全团队效能，而非深陷具体代码实现。 - [05:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=300s) 没有证据表明深层对象继承体系有助于大规模团队协作；相反，深层层级隐藏了关键数据，给客观问题强加了多余的心智模型与认知负担。 - [12:45](https://www.youtube.com/watch?v=qWJpI2adCcs&t=765s) 软件工程不存在脱离具体语境的抽象“优雅”，针对特定问题以最简单、直接的输入输出逻辑达成预期目标就是最佳解法。 - [16:32](https://www.youtube.com/watch?v=qWJpI2adCcs&t=992s) 开放世界游戏受到磁盘寻道与流式传输带宽的硬性物理限制，玩家移动速度锁定了数据预算加载时间窗口，是必须尽早确立的核心变量。 - [20:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=1200s) 忽视核心变量并寄希望于“上线前最后优化”是极不专业的逃避行为，后期变更核心参数往往会引发跨部门灾难性的资产报废与返工。 - [25:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=1500s) 基于 XML 的 Collada 等冗长文本格式在大体量过场动画导出中暴露出严重的解析瓶颈，单次导出耗时 30 分钟会彻底破坏开发者的迭代节奏。 - [30:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=1800s) 许多程序员严重缺乏通读 Intel、AMD 或 ARM 处理器硬件架构手册的基本功，在未知底层硬件机制的情况下全凭臆测写代码十分不可取。 - [35:10](https://www.youtube.com/watch?v=qWJpI2adCcs&t=2110s) 源输入数据定义直接决定了系统行为，内部自研文件格式规范必须融入日常迭代同步记录，否则将导致长期的游戏资产归档与向后移植危机。 - [45:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=2700s) 独立小团队的核心竞争优势在于对单一游戏上下文的深刻理解，不应盲目照搬 3A 大厂或通用商业引擎繁重的通用实体组件架构。 - [55:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=3300s) 游戏开发招聘中最关键的衡量指标是不可遏制的好奇心，候选人应展示由个人意志驱动并刨根问底的技术成果，而非千篇一律的学校课业。 - [57:37](https://www.youtube.com/watch?v=qWJpI2adCcs&t=3457s) 日常工作不能等同于职业技能的刻意练习，专业程序员应建立如刷牙洗澡般每日坚持的自律训练机制。 - [01:00:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=3600s) 刻意练习的核心价值在于思维与解题速度的迭代，每次 30 分钟练习后彻底删除源码能有效避免心态退化为长期工程维护。 - [01:04:19](https://www.youtube.com/watch?v=qWJpI2adCcs&t=3859s) 对复杂系统进行离线调试与分析时，拦截关键入口点录制结构化命令流，比周期性导出全量内存镜像更高效且支持时序精确回放。 - [01:06:40](https://www.youtube.com/watch?v=qWJpI2adCcs&t=4000s) 将抽象数学定义（如空间查询多面体）转换为直观几何进行可视化呈现，能够极快暴露出隐蔽的数学边界缺陷并提供庞大的测试用例集。 - [01:10:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=4200s) 程序员的本质工作是捕获、观察并理解底层真实数据，抱怨代码量大、打字耗时完全是对软件工程核心职责的本末倒置。 ## Detailed walkthrough ### [00:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=0s) 开场介绍与 Insomniac 引擎团队的规模 Casey Muratori 在 HandmadeCon 2015 的舞台上做开场。他提到平时在 Twitch 直播或聊天室里，一旦讨论到“面向数据编程（Data-Oriented Programming）”等话题，大家几乎会一致推荐：“去看 Mike Acton 在 CppCon 上的主题演讲吧，讲得太棒了！”那个演讲不仅极其契合 Handmade 社区经常讨论的底层与硬件交互哲学，而且出自一位在业内拥有极高声誉的技术专家之手。Casey 表示自己此前与 Mike 素不相识，只是抱着试一试的心态发了封邀请邮件，没想到 Mike 爽快地答应参会。此外，Mike 刚才在 Tommy Refenes 演讲时一直在做笔记，手头积累了不少自己想聊的话题。 登台时，观众报以热烈的掌声。Mike 笑着调侃：“I do have to say this is an entirely different reaction than I got from the C++ program.”（我不得不说，这里的反应跟我在 C++ 会议上得到的完全不同），暗指他在 CppCon 批判传统面向对象编程时引发的争议与抵触。Casey 随后切入正题，请 Mike 为那些不在游戏行业的人介绍一下他在 Insomniac Games 担任“技术总监（Technical Director）”的具体职责。Mike 解释道，在当今的 3A 游戏领域，Insomniac 的引擎团队规模其实处在较小的一端，总共只有大约 20 名程序员，外加 2 名负责测试与组织等支持工作的非程序员。这个仅 22 人的团队不仅要维护底层的引擎运行时（runtime），还要负责全部开发工具链，并且需要同时支撑工作室内部 3 到 6 款正在并行开发的游戏项目。 - **引擎团队编制**：约 20 名引擎程序员 + 2 名非编程支持人员（负责测试与流程协同）。 - **支持范围**：负责引擎运行时、工具链研发，同时支撑全工作室约 190 名处于各产品线与技术共享组的其他开发人员。 - **并行项目**：整个团队需在极快节奏下，同时支持 3 到 6 款不同阶段的游戏开发，容错空间极小（“no room for slop”）。 ### [03:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=180s) 技术总监的角色与“倍增器”价值 谈到这 22 人的团队如何在应付发行商展示、消除日常突发技术故障、开发引擎前瞻特性的高压下保持推进，Mike 阐述了他作为技术总监的核心理念：“Your job is what you make it.”（你的工作取决于你如何定义它）。他认为每个人都应该主动去寻找自己对团队贡献最大的方式。在导演与管理层面上，他的日常工作包括参与架构评审，帮助组内成员以及 Lead 们梳理解决问题的路径，通过适时提出关键问题，提前砍掉那些注定会浪费大量时间的死胡同分支。 Casey 追问 Mike 是否还会亲自下场写代码。Mike 回应称偶尔确实会参与底层代码审查甚至亲自编码，但那种情况通常只在极其关键的节点发生，因为那往往不是他能发挥出的最高价值。Mike 强调：“My job, as much as possible, to be multiplied by what everybody is doing. So as much as possible, I need to be making everybody else better and spending time figuring out how to help them become better programmers.”（我的工作应当尽可能去乘上大家所做的事情；我需要尽可能让其他所有人变得更优秀，花时间去帮助他们成为更好的程序员或更好的 Lead，这才是我的价值所在）。 ```mermaid flowchart TD accTitle: 技术总监的职责层次与价值杠杆 accDescr: 展示技术总监从具体写代码到高层架构审查再到提升团队能力的杠杆放大过程 subgraph DirectWork["低杠杆执行"] A["亲自编写关键核心代码"] B["底层代码审查 (Low-level Review)"] end subgraph Architecture["中杠杆决策"] C["架构评审与方向把控"] D["提出关键问题 / 砍掉无用技术路径"] end subgraph Multiplier["高杠杆乘数效应"] E["辅导成员与 Lead 成长"] F["团队整体效率与认知倍增"] end DirectWork --> Architecture Architecture --> Multiplier ``` ### [05:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=300s) 团队理念的分歧、尺度与面向对象的规模神话 Casey 将话题引向 Mike 著名的 CppCon 演讲（倡导聚焦于实际问题、硬件特性与数据变换），询问在 Insomniac 这支 20 人的引擎团队中，大家对于这种“面向数据”的理念是否高度一致，是否存在关于“要不要用更多面向对象抽象”的内部冲突。Mike 坦言，相比起自己这种极端风格，任何人看起来都显得温和；越远离核心引擎团队（比如玩法逻辑业务层），这种激进程度就越低。但即便如此，整个引擎团队在根本原则上是高度统一的：团队的底色是理性与深入理解本质。团队里可能会就某些具体权衡与妥协尺度产生分歧，但“There is certainly no one on the team that's saying, 'you know what we really need here is more abstraction. What we really need here is to spend some time making UML diagrams.' There is no one on the team that's doing that.”（团队里绝对没有任何人会跳出来说：‘我们这里真正需要的是更多的抽象，我们真正需要的是花点时间画画 UML 类图。’绝对没人会干这种事）。 接着 Casey 抛出了一个经常被观众问及的问题：很多程序员认为，面向数据或针对具体问题的编程方式或许适合单打独斗，但无法拓展到 20 人甚至更大的团队；他们坚信面向对象编程及其封装、层次结构是项目规模扩大时维系协作的“必要之恶”。当被问及这种观点是否准确时，Mike 毫不留情地予以彻底反驳。 Mike 直言这种问题往往站不住脚，提问者根本无法自圆其说，因为这种论调大多不是源自第一手实践经验，而仅仅是听信了别人的说法。Mike 犀利地断言：“No, that's complete bullshit. It makes no sense... There's no evidence to support, none, zero evidence to support that.”（不，这纯粹是一派胡言。根本讲不通……没有任何证据，零证据可以支持这种说法）。Mike 指出，纵观软件工程界，那些经受住了几十年时间检验、生命力最顽强、最成功的底层代码库或通用库，内部几乎从不存在深层嵌套的庞大对象继承树；相反，它们几乎无一例外都采用了极为简单、纯粹的输入-输出（I/O）接口。正是这种贴近本质的设计，才真正支撑起了无数庞大而复杂的历史项目。 ### [10:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=600s) 抽象层的累赘与心智模型的危害 Mike Acton 认为，像 C 标准库（`libc`）或数学库（`libm`）这类基础库之所以能支撑超大规模项目，是因为它们直截了当；相反，深层次的对象继承体系（deep object hierarchies）对于项目的规模化扩展不仅没有帮助，反而适得其反。当开发者构建繁冗的对象层级时，隐藏了大量原本极具价值的底层信息，同时制造出海量无价值的信息附着在问题之上。当团队规模达到上百甚至上千人时，如果每个人都在把问题搞得比原本更复杂，最终累积起来的就是几个数量级的冗余和废话（bullshit）。这样的系统不仅脆弱、难以理解、极难修改和测试，而且性能通常非常糟糕。 ```mermaid flowchart TD accTitle: 复杂抽象与极简方案对比 accDescr: 对比面向对象深层继承带来的额外心智负担与面向数据/极简模型直接解决问题的区别。 subgraph Heavy["过度抽象的方案"] P1["实际问题"] --> OOH["深层对象层级 / 抽象模型"] OOH --> Mental["强加的心智模型与命名负担"] Mental --> Bloat["性能低下、脆弱且难以维护的系统"] end subgraph Lean["极简/数据导向方案"] P2["实际问题"] --> MinSet["描述问题的最小必要集合"] MinSet --> DirectSol["精准解决实际问题的高效系统"] end ``` Mike Acton 强调，向问题中强加东西永远不可能让问题变简单，只会增加复杂度。他指出：“向问题中添加东西并不会让问题变得更简单。它永远不会让问题变简单。增加东西总是会让它变得更复杂。”（“Adding stuff to the problem does not make the problem simpler. It never makes the problem simpler. Adding something always makes it more complicated.”）因此，程序员应当寻找能描述解法或问题的绝对最小集合。一旦开发者将自己脑海中“我看待这个问题的方式”投射成抽象模型，其他读代码的人就必须先解读并消化这层多出来的个人心智模型，这正是编程界公认“命名”是一大难题的根源所在——因为通过命名，开发者往往强加了本不存在的预设与认知负担。 - 深层继承模型隐藏关键信息，引入大量干扰信息，导致系统在大团队协作中迅速脆化。 - 无论采用数据导向（Data-Oriented Design）还是单纯的简化模型，核心原则都是最大程度削减抽象层级。 - 编程中许多命名困难的根源，在于开发者试图将自己的主观心智模型强加到客观的问题空间之中。 --- ### [12:45](https://www.youtube.com/watch?v=qWJpI2adCcs&t=765s) 为 Tommy Refenes 的“垃圾公式”正名 Mike Acton 将话题引向现场的 Tommy Refenes（《超级食肉男孩》开发者），直接拿 Tommy 在前一场演讲中的措辞开刀。Tommy 当时在介绍角色控制手感与物理行为时，称自己写的是“垃圾公式”（garbage formula）、输入的是“垃圾数据”（garbage data），因为那些数学逻辑在真实物理学中根本讲不通。Mike 极为反对这种自我矮化的用词，他指出认为“现实世界的物理模型天生优于游戏特定算法”本身就是一种错误的预设。Tommy 耗费三个月硬核调试并反复迭代出来的控制器，输入是手柄物理按键，输出是“让 Tommy 露出笑容”（Tommy smiles），这已经构成了一个清晰无比的输入输出闭环。 主持人 Casey Muratori 随之点破了行业中普遍存在的虚荣与包袱：人们总迷信存在某种所谓的“正统编程”（proper programming）或“优雅”（elegance），导致开发者如果没去硬套一套现成的完整物理引擎，就不得不委曲求全地称自己的代码为“黑客补丁”或“垃圾公式”，以防被人挑刺说不会编程。Mike 断然支持并升华了这一观点：“用最简单的解法精确解决我遇到的问题，那就是正确答案。其他任何做法都是不可理喻的。为什么我要去做别的事情？”（“It's the simplest solution that solves exactly the problem that I had. That's the right answer. Anything else is fucked up. Why would I do anything else?”）在 Mike 看来，脱离具体上下文、幻想着以某种凭空存在的放之四海而皆准的“优雅通用解”来解决问题，纯粹是彻头彻尾的荒谬。 - Tommy 历经数月打磨出的控制器模型完全服务于游戏本身的乐趣，其有效性已由最终成品完美证明。 - 真正“垃圾”的做法反而是强行塞入所谓的真实世界物理模型，因为那样做不仅浪费时间，游戏也不会好玩。 - 编程的评判标准唯有是否以最简单的方式达成预期结果，不存在脱离场景的抽象“优雅”。 --- ### [16:32](https://www.youtube.com/watch?v=qWJpI2adCcs&t=992s) 开放世界游戏开发中的物理法则：磁盘带宽与移动速度 Mike Acton 随后谈到 Tommy 演讲中提到的另一个关键经验：早期未能尽早敲定角色控制手感，导致关卡设计无法提早定型（因为关卡必须围绕角色操控来构建）。Mike 强调这是全行业绝不可忽视的重要教训。他以自己参与 Insomniac Games 制作开放世界游戏《日落过载》（Sunset Overdrive）的切身经历作类比：在开放世界中，有一项底层数据决定了整个游戏方方面面的设计，那就是角色的**移动速度**（movement speed）。 在开放世界开发中，所谓的“物理法则”并非物理引擎模拟，而是物理世界中旋转的机械硬盘或光盘读取介质的物理极限。内存无法塞下整个开放世界，数据必须源源不断从磁盘流式加载（streaming）。在主机平台上，尽管厂商可能为了控制成本而采购了极具性价比甚至相对孱弱的硬件，但其优势在于读写基准是固定的；开发者能明确估算出驱动器的寻道时间（seek speed）与带宽上限（而 PC 平台下限则不可预测）。当硬件读取速度固定时，玩家从 A 点移动到 B 点所耗费的时间，就严丝合缝地限定了引擎能将下一块区域加载进内存的时间窗口。 ```mermaid flowchart LR accTitle: 开放世界资源预算与移动速度因果链 accDescr: 展示硬件读取瓶颈、玩家移动速度与世界切片预算之间的因果关系。 subgraph HardConstraint["硬件物理瓶颈"] Disk["磁盘旋转与寻道速度"] BW["流式加载带宽上限"] end Speed["角色移动速度<br/>(例如: 10 m/s vs 50 m/s)"] Time["可用流式加载时间窗口"] Budget["地块数据预算<br/>(美术、几何与世界设计)"] HardConstraint --> Time Speed --> Time Time --> Budget ``` 如果将世界划分为网格切片（tiles），角色以 10 米/秒移动与以 50 米/秒移动所对应的完全是两款截然不同的游戏。角色跑得越快，引擎流式传输留出的缓冲时间就越少，每一个地块的几何、贴图和实体数据预算（tile budget）就会被极度压缩。角色的移动速度这单一变量直接锁死了数据预算，进而自上而下辐射到整个大团队：它直接决定了关卡该如何构筑、世界如何切分、美术资源能精细到什么程度。 - 开放世界的核心物理限制是物理驱动器的旋转寻道与带宽上限。 - 主机平台胜在拥有明确的硬件下限，而 PC 平台的性能低谷则无法预测。 - 角色移动速度直接决定了流式加载的时间窗口，速度越快，每个地块可分配的内存与性能预算就越严苛。 ### [20:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=1200s) 关键核心变量的影响与“留到最后再优化”的危害 迈克·阿克顿（Mike Acton）与凯西·穆拉托里（Casey Muratori）深入探讨了游戏开发中“关键核心变量”（Keystone Variables）对团队各工种产生的巨大连锁反应。以角色移动速度为例，美术人员必须根据这一速度来决定场景物件的精细度以及 LOD（多细节层次）的设计；程序团队则需要依据它来平衡系统负荷与数据流式加载（Streaming）。迈克指出，假设项目初期设定的移动速度为每秒 10 米，经过整整一年的迭代开发后，如果程序员突然觉得“每秒 15 米更有趣”，这往往意味着必须推翻并重做此前一年内完成的所有关卡。如果团队有 50 人、200 人，甚至像育碧（Ubisoft）那样有数千人协同制作关卡，这一微调就相当于把数百万美元的开发成本直接扔进水里；反过来，如果一开始按每秒 50 米的高速设计，一年后决定大幅放缓，由于资产最初是按极高的数据吞吐上限进行精简设计的，最终呈现的效果就会显得异常空旷和简陋，完全未能利用空余出来的性能预算。 迈克强调，这一教训的本质并不局限于控制手感或移动速度本身，而在于尽早识别出游戏或特定问题领域中的核心变量：“因为如果你忽视了它们，如果你不明白这些核心变量是什么——而它们始终是客观存在的——如果你不知道这些核心要素，接下来发生的事情就是你会把自己彻底玩死。”（“Because if you ignore them, if you don't understand what they are, and they're always there, and if you don't know what these keystones are, what's going to happen is you're just going to fuck yourself.”）很多团队在忽视核心变量后，往往会抱有侥幸心理，认为关卡总能顺利加载，甚至抛出“反正最后可以做优化”的论调。迈克直言：“每当我听到这句话，我就想扇人耳光。”（“Anytime I hear that, I just want to slap somebody.”）凯西随即调侃道，如果开发团队中有人说出这种话，那这人背后一定有一整条需要被连环掌掴的责任人链条，就像在走廊里一路飞奔着挨个打耳光一样。迈克补充道，无法利用好硬件潜力是对玩家的不负责任，也是极不专业的表现。在《日落过载》（Sunset Overdrive）等项目中，一旦团队识别出具有巨大连锁反应的关键决策，他就必须全力四处呼吁，迫使相关人员尽早敲定，或者至少让所有人清醒意识到推翻决定的代价。 ```mermaid flowchart TD accTitle: 核心变量变动对游戏开发管线的连锁冲击 accDescr: 展示以移动速度为代表的核心变量如何直接制约美术资产、流式加载预算与关卡返工成本。 subgraph CoreDecision["核心变量决策 (例如：玩家移动速度)"] Speed["设定移动速度"] end subgraph ArtAndTech["技术与资产约束"] Streaming["内存流式加载预算 (Streaming Budget)"] LOD["美术资产精细度与 LOD 规划"] Balance["系统性能与玩法平衡"] end subgraph ImpactOnLateChange["后期随意修改设定的后果"] TooFast["若大幅提速：资产超出流式加载瓶颈，关卡资产作废重做"] TooSlow["若大幅减速：环境细节严重不足，未能榨干硬件潜力"] Cost["数百万美元预算浪费与团队效率灾难"] end Speed --> Streaming Speed --> LOD Speed --> Balance Streaming --> TooFast LOD --> TooSlow TooFast --> Cost TooSlow --> Cost ``` - 核心变量的任何变动都会跨部门联动，直接颠覆美术、程序与策划原本依据旧指标建立的设计基准。 - 抱着“上线前最后阶段再优化”的心态进行开发，本质上是逃避前期必须锁定的架构限制。 - 如果设计团队确实无法立刻做出抉择，也必须明确评估并主动承担“未来变更决策”所带来的工期与金钱成本。 --- ### [25:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=1500s) 过场动画导出的规模瓶颈与 Collada 的三十分钟梦魇 在聊完核心变量后，迈克将话题转向开发清单上的下一个痛点：过场动画（Cinematics）的数据导出。此前汤米·雷芬内斯（Tommy Refenes）曾提到《超级食肉男孩》（Super Meat Boy）中动画导出极耗时间，而迈克指出，无论团队规模膨胀到多大，导出过场动画的痛苦丝毫不会减轻。在《日落过载》中，所有过场动画都是在引擎内即时渲染（Real-time）的，但这并不意味着流程轻松。动画师在 Maya 中需要进行极其繁重的手工 K 帧工作，利用过场工具逐帧排布轨道、处理镜头切换，甚至要把大量动作严格匹配到音轨节奏上。例如，《日落过载》的开场动画镜头数高达 90 个，在保证即时渲染、纹理流式加载等系统平稳运行的同时，这种庞大体量给资产导出带来了严峻考验。 问题最严重的瓶颈出在中间交换格式上。该项目当时采用 Collada 作为导出格式，而 Collada 本质上是未经压缩的 XML 纯文本文件。当动画师试图从 Maya 中导出开场动画纯粹的底层动作源数据时——甚至还不包含引擎专有的轨道与场景配置——仅仅在 Maya 中点击保存并导出 Collada 文件的过程，就需要足足耗费 30 分钟。这意味着每位动画师一天最多只能导出十几次，甚至在上一版动画还没导出完成时，就不得不盲目开始着手下一轮修改。凯西对导出纯源数据就需要半小时感到十分震惊，迈克坦言这在当时极其残酷，逼得工程团队后续必须着手重写性能更优的 Collada 导出器，并积极探寻替代方案。 - 《日落过载》采用完全基于引擎的即时渲染过场动画，开场动画包含多达 90 个镜头切镜，复杂度和资产负荷极高。 - 行业早期缺乏通用的资产交换标准（除了表达力不足的 OBJ），Collada 作为基于 XML 的开放文本格式被采用，但其冗长和解析开销在大型资产面前暴露无遗。 - 相比之下，FBX 后来之所以成为事实上的行业通用标准，很大程度上是因为 Autodesk 在三维制作软件领域形成了垄断地位。 - 单次导出耗时长达 30 分钟，彻底破坏了美术和动画师的日常迭代节奏，成为大规模生产管线中极具代表性的性能堵点。 ### [30:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=1800s) 过场动画导出的通病与“去读那该死的手册” Casey Muratori 和 Mike Acton 延续了关于美术管线痛点的讨论。对于动画团队导出一个长过场动画可能耗时 30 分钟的问题，Mike Acton 解释说，实际开发中总有变通手段（workarounds）：动画师可以不把整段过场作为一个庞大的单一体导出，而是拆解成若干小片段，再利用公司内部专门的拼接工具把它们组合起来。虽然这种绕弯子的做法谈不上理想，但至少不至于立刻阻碍管线运转。Mike 感慨道，过场动画导出从来都是大麻烦，而且永远都会是个麻烦，这种痛苦全行业感同身受。 随后话题转向之前关于 SWF 导入器的讨论。Casey 之前提到自己编写导入器时就是直接坐下来把规范手册从头到尾读完（RTFM），台下观众为此报以热烈掌声。Mike Acton 借此直指台下所有开发者：在座绝大多数人不是用 x86/x64 就是用 ARM 架构的 CPU（全场仅举手了一位非 x86/ARM 用户），既然 AMD、Intel 和 ARM 都有详尽的手册，大家理应早就把它们读透了。然而事实恰恰相反，在座几乎没有人真正花时间通读过这些处理器的架构手册。 Mike Acton 指出这种现状令人难以接受，尤其是大家每天都要在这些架构上耗费数月甚至数年工作： > “Without putting you all on the spot, I'm pretty confident that 100% of you have not, in fact, read those manuals. And that's kind of shitty, right?” 他以主机开发背景现身说法：在主机行业，硬件厂商每隔三到五年就会彻底废弃旧平台的所有东西，换上一套截然不同的全新架构；可即便明知几年后这套硬件就要进垃圾堆，去精读那几本手册依然绝对物有所值。Casey 总结道，Mike 的逻辑非常直接——写 SWF 导入器前要通读 SWF 规范，那么在这套硬件架构上写代码，第一步自然就是去精读实际的架构手册，不要全凭臆测。 - 动画师通过将长过场动画切片导出、再用内部独立工具拼接来绕过耗时过长的瓶颈。 - 绝大多数程序员从未通读过正在使用的 Intel Architecture Guide、AMD 架构文档或 ARM 参考手册。 - 主机行业硬件生命周期仅有数年，即便架构终将被废弃，精读硬件手册依然是开发者的基本功与价值所在。 --- ### [33:14](https://www.youtube.com/watch?v=qWJpI2adCcs&t=1994s) IFF 格式与现代文件格式文档化的缺失 从 SWF 规范出发，Mike Acton 联想到了 Electronic Arts 早期制定的经典文件格式 IFF（Interchange File Format）。为了照顾年轻听众，Mike 和 Casey 解释了什么是 IFF：早在 1982 年左右（实为 Commodore-Amiga 与 EA 合作制定），EA 就推出了这种极其干净整洁的交换格式。其核心结构极为简单，就是一个包含数据类型（通常是 4 字节 ASCII 标识）和数据长度的头部，其后紧随实际内容。Mike 盛赞 IFF 是文档化与数据共享的黄金标准，在那个行业甚至还没意识到这有多重要的年代，它就已经被极其严谨地记录下来，以至于三十多年后任何人都可以立刻查阅规范并无障碍理解。 相比之下，现代工业界的文件格式文档化却退步严重。Casey 提到了 Adobe 的 PSD 格式规范——其结构混乱无序，读起来令人匪夷所思。Mike Acton 则强调，这不仅仅是外部商业格式的问题，就连游戏团队自己内部定义的数据格式也是重灾区。例如在制作《Ratchet & Clank》这类大型项目时，团队普遍严重忽略了为“仅供内部使用”的文件格式编写规范文档。 ```mermaid flowchart TD accTitle: 数据输入驱动系统架构逻辑 accDescr: 展示源输入数据如何决定整个系统的运行逻辑，以及公开格式规范对逆向工程和开发的作用。 subgraph Core["数据核心"] Src["源输入数据 (Source Input Data)<br/>文件格式与结构定义"] end subgraph System["系统推导"] Logic["引擎逻辑与运行状态<br/>(System Behavior)"] end subgraph Ext["外部价值"] Hack["逆向与模组社群<br/>(Modder / Hacker Community)"] Archive["跨平台移植与历史存档<br/>(Porting & Long-term Archival)"] end Src -->|"决定并可反推"| Logic Src -->|"提供规范描述"| Hack Src -->|"保留数据语义"| Archive ``` - IFF 采用简明清晰的 `Type`（类型标识）加 `Size`（数据块长度）Chunk 结构。 - 现代许多商业格式（如 PSD 规范）往往晦涩且组织混乱，远不如早期经典格式严谨。 - 游戏团队内部自研格式往往完全缺乏任何书面规格说明。 --- ### [35:10](https://www.youtube.com/watch?v=qWJpI2adCcs&t=2110s) 内部格式文档化的价值、实施时机与历史归档危机 Casey 追问 Mike Acton，既然是绝不对外公开的纯内部文件格式，团队为什么还要煞费苦心地去写文档。Mike 坚定地指出，数据是进入系统的最根本源头，是开发中最核心的资产；系统的行为完全可以从源数据的组织方式中推导出来。如果把任意一款商业游戏的源数据格式说明直接扔给逆向或黑客社区，他们瞬间就能把这款游戏摸个底朝天，正因为数据包含了一切关键信息。然而具有讽刺意味的是，开发团队往往最忽视对这部分最重要资产的文档记录。 关于文档化应在何时完成，Mike 认为关键在于“精准度”。如果将写文档推迟到项目封版送厂（Ship）的那一天，往往会演变成灾难——那是整个团队承受 500 个 Bug 轮番轰炸、在几十台机器间精疲力竭排查崩溃的最痛苦时刻，如果在此时强压文档任务，只会激化团队矛盾。因此，更健康的做法是将文档化融入日常开发迭代，作为修改数据格式时必须同步执行的变更流程。 最后，两人探讨了数据格式文档化对游戏文化遗产保存的沉重代价。Casey 指出，过去像《Doom》（DOOM）因格式规范公开而催生了庞大的 Mod 社区和对代码的彻底研究；而现代环境（如 Steam Workshop）普遍依赖集成化黑盒工具，玩家不再接触底层原始数据，开发商也缺乏对外文档化的外部压力。Mike 对此警告，由于缺乏文档，现代游戏的数字归档已陷入巨大危机： > “How to archive a PS3 game that runs on a network on PSN is already a really, really hard problem. And to make that even harder is... pretty much just presumes that it's not important to archive the data.” 如果团队不记录数据定义，未来当公司想要把老游戏重制或移植到新平台时，原本可以轻松推进的工作将会因数据格式无人知晓而寸步难行，整个业界正在无声地流失过去十几年里积累的海量游戏资产。 - 源输入数据（Source Input Data）是系统最核心的定义，理解了源数据即可推导出系统其他模块的职能。 - 封版上线（Ship Day）是最不适合补写文档的时刻，格式变更与文档更新应在日常迭代中作为同一流程同步完成。 - 在网络化平台（如运行在 PSN 上的 PS3 游戏）时代，缺少清晰的文件格式说明导致数字保存与向后移植变得异常艰难。 ### [40:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=2400s) 数据格式归档、十年后的移植与万维网提案的讽刺 Casey Muratori 和 Mike Acton 继续围绕老游戏资产保存与格式展开讨论。Casey 提到，某些经典游戏在十年后必然会被人怀念并渴望重玩，但届时的硬件架构可能已经发生翻天覆地的变化。届时需要移植它的往往不是原作者本人，而是其手下大批后续接盘的工程师。原作者自己很可能早已忘得一干二净，正如 Mike 调侃道：“你会想：‘搞什么鬼？我根本不记得了。那是十年前的事。我甚至得回去看自己当年的演讲视频才能想起来我到底干了些什么。’”（“What the fuck? I don't even remember. That was ten years ago. I'm going to have to watch videos of myself talking about it to even remember what I was doing.”）因此，完善的数据格式文档和清晰的数据结构定义至关重要，只有这样后人才可能理清迁移成本，将作品带到未来的全新计算平台上。 随后，Mike Acton 话锋一转，提到由刚才 Tommy 关于导入 SWF 格式文件的讨论，让他联想到了蒂姆·伯纳斯-李（Tim Berners-Lee）当年撰写的万维网提案文档（World Wide Web Pitch document）。Mike 极力推荐每个人都去阅读这篇仅有几页的简短提案： - 提案撰写于 20 世纪 90 年代初（互联网诞生之前），详细列举了作者试图解决的问题。 - 讽刺的是，万维网彻底颠覆了全球的商业形态和人类交互方式，但他最初承诺要解决的核心问题，几乎一个都没解决。 - 提案的核心痛点是“人们找不到对自己至关重要的文档，系统太复杂，信息极难检索”。而时至今日，大家依然面临找不到工作所需文档的困境；当年设想中类似 Wiki 的系统，在五年之后往往也逃不过荒废和不可维护的命运。 - Casey 戏谑地补充，这其实是个“数据转换问题”——如果能把重要技术文档统统转换成贾斯汀·比伯（Justin Bieber）的流行金曲，所有人就能秒速搜到了。 Mike 感慨，面对全人类历史上“检索重要信息与沟通”这种宏大不可攀的难题，万维网给出了解决方案，改变了世界，然而最原本的目标却依然未果，甚至催生出了更多、更庞大、更有趣的新问题。 ```mermaid flowchart TD accTitle: 理想与现实的技术演进闭环 accDescr: 描述技术演进中原始愿景与现实结果的偏差闭环 subgraph Problem["原始痛点"] A["核心诉求：快速检索重要文档与数据"] end subgraph Solution["技术解决方案"] B["提出宏大架构<br>(如 万维网 / 通用引擎架构)"] end subgraph Outcome["现实结果"] C["重塑了外部世界与协作形态"] D["原始问题依旧未解决<br>(仍旧找不到文档/读不懂老格式)"] E["衍生出更多全新复杂问题"] end A --> B B --> C B --> D D --> E E -.->|"循环往复"| B ``` --- ### [45:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=2700s) 独立开发者的误区：盲目照搬 3A 引擎架构 Casey 顺势将话题引回最初悬而未决的核心议题：团队规模（Scale）对开发模式的根本影响。Mike 经常与独立团队及学生交流，现场也有相当比例的独立开发者。Mike 指出，许多独立团队在开发自研引擎或工具时，往往会不自觉地照搬商业大厂（如 Insomniac、Epic）或通用商业引擎（如 Unity、Unreal）的设计模式，最典型的就是一上来就搭建“在场景里摆放 Entity/Actor，然后挂载通用组件（Component）”的通用编辑器与运行时结构。 Mike 强调自己作为底层引擎程序员，完全支持且热爱自研工具，但独立开发者往往忽略了自己所处的真实语境（Context）： - **规模与沟通成本的天壤之别**：大厂为了协同数百人、跨多个大型项目，必须做出某种程度的妥协与通用化设计；而一个 5 到 10 人的独立小团队，人与人之间具备极高深度的即时沟通效率，根本无需背负通用化架构的巨大包袱。 - **盲从权威的心智陷阱**：在软件工程中，认为某种心智模型是绝对真理而其余皆错是极其狭隘的。Mike 直言：“因为 Insomniac 这么做了，或者因为 Epic 这么做了，或者因为随便谁这么做了，就认为这一定是正确的方法，从而照搬过来，这也是错误的。因为这与你的具体问题毫无关系。”（“To say, you know, because Insomniac did it, or because Epic did it, or because whoever did it, that must be the right approach, so I'm just going to sort of copy that, is also wrong. Because it has nothing to do with your problem.”）大团队的方案是为了解决大团队的问题，与小团队当下的目标截然不同。 为了具体说明定制化思考与通用抽象的差距，Mike 以关卡中的“梯子（Ladder）”为例进行对比： - **通用引擎的低效做法**：团队花费大量工时写一套通用的 Actor/Component 编辑器。关卡策划在场景里拖入一个通用三维模型，手动调整位置，再为它配置 Ladder Component，反复调试校验。 - **针对当前游戏语境的定制做法**：团队明确知道自己只做这款游戏。关卡中哪些结构符合放置梯子的硬性约束，代码和工具一清二楚。编辑器里直接做一个“梯子按钮”；点击后，场景中所有合法的位置直接半透明高亮显示（Ghosting），策划只需单击目标高亮位，耗时 3 秒即可完成摆放。 Mike 总结道，独立团队必须直面自己游戏的具体约束，而不是去构建任意通用场景：“我不必把时间浪费在拖拽任意物体、再挂载任意组件上，因为我做的不是一款任意的游戏，我做的是眼前这一款特定的游戏。”（“I don't have to waste time like dragging some object in and it's an arbitrary model that's attached to some arbitrary component because I'm not making an arbitrary game. I'm making this game.”） ### [50:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=3000s) 上下文的威力与独立开发者的独特优势 Casey Muratori 和 Mike Acton 继续深入探讨“具体上下文”（Context）在工具与引擎开发中的决定性价值。Casey 指出，如果开发者是在为某一款具体的游戏编写工具，那么所拥有的丰富上下文信息能让人把问题解决得漂亮得多；反之，若无视上下文、试图把工具做得过于通用化（Generic），实际上是在自找麻烦、让运行效率变慢，并且凭空把问题的人为难度提高了一个数量级。Casey 形象地比喻道，这完全对应了前面关于代码设计的讨论——如果某些东西对解决手头的问题没有实质帮助，就绝不该引入。Mike 对此高度赞同，他补充说，一旦强求“必须通用”或套用某种现成的抽象模式，就是在把原本根本不存在的心理模型强加给现实问题。Casey 进而吐槽道，如果最终折腾半天只是做出一个劣质版的 Unity 或 Unreal，那最初直接用现成引擎不就好了吗？ Mike 强调，独立开发团队的核心竞争优势正是在于对自身具体上下文的深刻理解：“我认为这正是你作为该领域的独立开发者所拥有的优势：你对自己的上下文有着深刻的理解，并且能够充分利用它；你可以写出完全无法用于其他任何项目的代码，但它们在当前这一件事上表现得极为出色，这太棒了。”（“I think, and that's the--that--just your advantage as an indie in the space, right, is that you have that deep understanding of your context, and you can take advantage of it. You can write things that are just--that cannot be--that cannot be used to make anything else. But they just kick ass at this one thing, and that's awesome.”）Mike 坦承，即使以 Insomniac Games 的技术体量，虽然比需要服务成千上万外部开发者的通用引擎团队更能针对具体硬件做特化，但也依然比不上真正小而精的独立团队。因为 Insomniac 内部同时有多个项目在并行推进，彼此之间存在细微差异，引擎团队不得不支持更广泛的需求范围，无法像单一游戏独立团队那样将特化做到极致。 ```mermaid flowchart TD accTitle: 游戏开发中的特化优势对比 accDescr: 独立团队、大型工作室自研引擎与商业通用引擎在上下文利用与特化程度上的对比链条。 subgraph Generic["商业通用引擎（如 Unity / Unreal）"] G1["面向数十万外部开发者"] G2["被迫高度抽象与泛化"] G3["牺牲针对特定硬件与玩法的极致性能"] end subgraph Studio["大型工作室自研引擎（如 Insomniac）"] S1["内部多项目并行推进"] S2["需兼顾不同项目的细微差异"] S3["特化程度较高，但仍受多线需求牵制"] end subgraph Indie["专注单款产品的独立团队（Indie）"] I1["对单一游戏上下文拥有 100% 洞察"] I2["代码完全无法复用到其他项目"] I3["在特定目标上发挥出无与伦比的极致表现"] end G3 -.->|"特化能力递增"| S3 S3 -.->|"特化能力递增"| I3 ``` --- ### [52:03](https://www.youtube.com/watch?v=qWJpI2adCcs&t=3123s) 新人入行困境与游戏公司的招聘筛选 Casey 将话题引向无数追随《Handmade Hero》系列教程的新人最关心的问题：如今想要进入游戏行业，到底该怎么做？Casey 感慨道，自己入行的时代过于遥远，如今的行业环境与当年早已天差地别；他每天都会收到来自学生和转行者的各类求助——是否该读大学、该练习什么、简历该怎么写、该如何申请职位。对于这些自己无法回答的问题，Casey 希望 Mike 能从用人主管的视角，谈谈游戏公司如今的真实招聘机制，以及他最希望推门而入的求职者具备怎样的特质。 Mike 坦言自己其实也很难对如今刚入行的新人体同身受。现在的求职者面临着海量的专业院校可供挑选，网络上充斥着无数现成的文档、范例和开源资源，这与他当年的起步环境完全不同；他打趣说，了解当下入行现状的最佳人选其实是四年前刚入行的新人。不过谈到招聘本身，Mike 分享了自己在长期面试中总结出的残酷现实：他在筛选候选人时，曾长期试图寻找能够与“招到优秀员工”强相关的客观指标，无论是毕业院校、编程笔试分数、笔试答题思路，还是过往工作经历。 令人无奈的是，绝大多数人们以为重要的硬性指标其实根本不成立。Mike 透露，Insomniac 确实会给求职者做编程笔试，但残酷的事实是：“如果我说，你是否在我们的笔试中取得高分，实际上与你未来在我们团队中能否成为一名优秀程序员并没有太大的强相关性。”（“Like, if I said, whether or not you pass our test well, actually doesn't really correlate strongly with how good of a programmer you're going to be for us.”）面对 Casey 追问“那既然不相关，为什么还要坚持考测试”，Mike 苦笑着承认，这其中有部分原因源于恐惧——作为招聘负责人，如果没有这道测试，他暂时也拿不出更好的替代筛选方案，毕竟大家归根结底都是会感到不安的凡人。 --- ### [55:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=3300s) 唯一有效的衡量标准：不可遏制的好奇心 在排除了学历、经验和测试分数后，Mike 给出了他在多年招聘中总结出的唯一真理：在所有可观测的特质中，**好奇心（Curiosity）**是唯一能与最终优秀工作表现产生强相关的指标。这种好奇心必须达到“不可遏制”（insatiable）、肉眼可见且无法否认的程度。Mike 描述了一种典型的反面候选人：当在面试中聊到某个底层机制或技术细节时，他们不仅回答不知道，更表现出一副“我既不知道也不关心，反正做好日常本职工作不需要懂这些，所以我根本没想过”的态度；在 Mike 看来，这种缺乏探索欲望的心态绝对无法在他所带领的核心引擎团队中立足。相反，一个拥有极度好奇心的人，即便时间有限不可能把天下所有事情搞懂，也必然保留着刨根问底的强烈冲动。 针对求职者该如何向雇主展示这一点，Mike 给出了极具针对性的实战建议： - **拒绝流水线式的作业展示**：千万别拿学校里完成的三个作业项目写进作品集。由于那是全班每个人都被强制要求完成的作业，在面试官眼里没有丝毫吸引力。 - **展现具有个人意志的深度钻研**：展示一个由纯粹的自我驱动而产生的技术成果。哪怕仅仅是一篇深入的技术博客，只要能体现出候选人面对一个技术问题时，不断向下挖掘直到探底，把一个月内能挖出的所有技术细节、分支问题统统抽丝剥茧搞明白的魄力，就足以让人眼前一亮。 - **完全忽视传统教育标签**：Mike 斩钉截铁地表示，他完全不在意候选人毕业于哪所学校、GPA 成绩是多少、上过什么课程，甚至根本不在意候选人是否通过了考试或是否顺利拿到了毕业学位。 Mike 在阐述自己的评价标准时掷地有声地总结道：“所以，是的，我真正在意的是你所展现出的成果，而且主要是你在出于自身意志的情况下所展现出的成果。”（“So, yeah, I care about what you've demonstrated, mostly what you've demonstrated on your own will. That's what I'm interested--”）Casey 对此高度评价，认为这个回答直接切中了技术人才的核心特质。 --- ### [57:37](https://www.youtube.com/watch?v=qWJpI2adCcs&t=3457s) 职业发展的核心缺失：大多数人根本不懂如何“刻意练习” Casey 接着开玩笑地试探道，如果刨除好奇心，单纯在技术基本功层面，Mike 是否期望求职者掌握更多技能——比如“大量练习 Java 编程”？Mike 顺着玩笑一笑置之，随后给出了一个同样非技术性的根本答案：**练习（Practice）**。Mike 严肃地指出，当今绝大多数技术人员根本不知道该如何科学有效地练习，也完全没有认真对待过日常练习，这对程序员的整个职业生涯来说是一个极其严重的致命问题。 许多人抱着“我在日常工作中干活就是最好的学习”的心态，但 Mike 明确指出这种想法完全不够。他剖析了“工作”与“职业”的本质区别：雇主雇佣你来做特定的工作，你把工作保质保量做完是应当的；但如何学习、如何刻意练习、如何让专业技能持续精进以支撑个人的职业长远发展，完全是你自己的独立责任，绝不能与单纯的公司上班混为一谈。 当 Mike 询问候选人平时每天都在练习什么时，对方最普遍的托辞往往是“我每天工作太忙，实在抽不出时间练习”。对此，Mike 用极其犀利的日常习惯作对比进行了反驳：“所以除了你的家人之外，这是你一生中花费时间最多的事情，你却连为了它抽点时间都做不到？就像你每天绝不会忘记刷牙一样，因为刷牙对你很重要，所以你每天都能坚持做；你每天大概也会换洗衣服，你可能还会每天洗澡……”在 Mike 看来，如果一个人将编程视为一生的志业，却连每天像刷牙洗澡一样抽出固定时间进行刻意练习都无法保障，那么其所谓的职业追求便根本经不起推敲。 ### [01:00:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=3600s) 抛弃产出的刻意练习：专业程序员的 30 分钟基本功 许多程序员在日常生活中总能抽出时间做那些自认为至关重要的琐事，却偏偏在职业技能的打磨上找尽借口。迈克·阿克顿（Mike Acton）对常见的推脱嗤之以鼻——尤其是那种“作为程序员，我必须一次坐上好几个小时才能进入状态，而我只有一点零碎时间”的说辞。阿克顿直接反驳道：“行了吧，你又不是小孩子了；作为一个专业人士和成年人，我认为你应该有能力规划好自己的时间，哪怕只有 30 分钟，也能从中有所收获（I think you should be able to organize your time so that, you know, you can get something out of 30 minutes if that's all you have）。”他强调，对练习敷衍了事不仅影响团队贡献，更是对自己职业生涯的极不负责。 当凯西·穆拉托里（Casey Muratori）询问如果每天真下定决心拿出 30 分钟，新手该拿什么项目起步（例如写个《Asteroids》小行星游戏）时，阿克顿给出了一个违背直觉但极其关键的建议：**每次练习结束后，立刻把写的所有代码全部删掉，不留任何代码继承性**。阿克顿指出：“因为如果你留着它，它就不再是练习了；它会变成一个项目，到了那个阶段它就变成了一种业余爱好（Because if you keep it, it doesn't become practice. It becomes a project. And it becomes a hobby at that point）。” 在阿克顿看来，练习的目的在于迫使自己思考得更快、寻找更优的解法。你可以每天都做同一个题目，但绝不允许保留前一天的任何产出。第一天可能在 30 分钟内连框架都没搭完，第二天依然差得远，但到了第 300 天，或许就能在 30 分钟内干净利落地完成一个完整的《Asteroids》。阿克顿总结道，无论练习的是开源代码、自己的项目还是性能剖析，前两分钟做好规划，执行 30 分钟后立刻停止并清空，因为“练习的全部价值就在于练习本身（The value of the practice is the practice）”。 - **拒绝借口**：专业程序员必须具备在 30 分钟有限时间内制定计划并产生技术产出的自律能力。 - **删掉代码的原则**：练习必须与“做项目”、“搞副业（Hobby）”和“做作品集（Portfolio）”严格区分，保留代码会导致心态转变为维护工程，从而失去速度与思维迭代的训练意义。 - **重复与重构**：同一道题目在不保留源码的前提下每天重写，通过成百上千次的清零重来逼近极致的速度与熟练度。 --- ### [01:04:19](https://www.youtube.com/watch?v=qWJpI2adCcs&t=3859s) 从 SpatialDB 优化到重构多边形裁剪器的离线调试管道 访谈临近尾声时，凯西询问阿克顿最近在 Insomniac Games 的工作日常。阿克顿分享了自己最近研究引擎内“SpatialDB”的经历。所谓 SpatialDB 并不是传统意义上的关系数据库，而是引擎内部用于执行空间查询的核心机制。阿克顿想摸清其性能边界并寻求优化空间。起初他的设想是在游戏运行时以固定周期（每隔 $n$ 秒）将整个空间数据库序列化导出到磁盘，随后离线加载并比对快照；然而该系统的内部数据结构高度优化且复杂变动，序列化整个状态代价高昂。 出于程序员所谓“偷懒”的心态，阿克顿改变了策略：他不再抓取数据库的完整内存镜像，而是转去拦截进入数据库的有限入口点（Entry Points）——包括添加、修改、删除和初始化调用，将这些操作记录为结构化的命令流。正如阿克顿自嘲的那样：“每当程序员说‘我打算换个做法，因为我有点偷懒’时，通常意味着新方案要比原先设想的工作量大得多（Whenever a programmer says, 'I'm going to do something else because I'm feeling lazy,' usually it involves way more work than the original thing, which is true, absolutely, in this case）。” 但这套命令回放系统带来了巨大的调试优势。阿克顿在离线工具中重构了操作历史，建立起可供任意拖动时间轴（Scrubbing）的完整回放时间线，能够随时还原出游戏运行过程中任意时刻的空间数据库全貌。 ```mermaid flowchart TD accTitle: SpatialDB 调试与离线分析流程 accDescr: 展示了从游戏运行期间录制入口点命令流，到离线重构时间线并最终暴露裁剪器 Bug 的完整流水线。 subgraph Runtime ["游戏运行时 (Runtime)"] A["引擎空间查询调用 (SpatialDB)"] --> B["拦截 Entry Points (添加/修改/删除/初始化)"] B --> C["录制为连续命令流 (Command Stream)"] end subgraph OfflineTool ["离线重构与分析 (Offline Tool)"] C --> D["回放命令流并重构时间线 (Reconstruct Timeline)"] D --> E["任意时刻状态还原与数据深度分析"] end subgraph Visualization ["凸包可视化与意外发现 (Polytopes & Clipper)"] E --> F["解析查询凸多面体 (平面方程 Polytope)"] F --> G["多边形裁剪例程 (Poly Clipper: 雕刻大立方体)"] G --> H{"输出是否异常?"} H -->|"是 (暴露陈年 Bug)"| I["获得几十万个真实查询的自动化测试集，迭代时间 < 1s"] H -->|"否"| J["生成几何体用于视效呈现"] end ``` 为了直观理解这些空间查询，阿克顿尝试将查询范围可视化。引擎中的空间查询通常表现为由一组平面方程界定的凸多面体（Polytope）。为了将其绘制为多边形网格，阿克顿采用了一种经典方法：在空间中生成一个足够大的立方体包围盒，然后调用引擎内现成的多边形裁剪例程（Clipping Routine），用各个平面像雕刻大理石一样把立方体外侧削掉。然而在部分用例下，可视化结果完全崩溃，输出了大量垃圾数据。 阿克顿顺着异常排查，发现问题根本不在 SpatialDB，而是引擎中多处复用的老旧多边形裁剪算法本身存在缺陷。由于他在游戏中录制了包含数十万次真实查询的历史流，这个原本用于数据库优化的回放系统瞬间变成了一个规模庞大、覆盖极端边界情况的自动化多边形裁剪器测试套件。修复该算法时，离线重放的迭代反馈时间甚至被压缩到了 1 秒以内。阿克顿感叹，深挖底层数据并尝试可视化的过程，往往会在完全意想不到的地方给开发者带来意外的收获。 - **命令流优于全量镜像**：对仅有少量入口点的复杂系统，录制操作命令流（Event/Command Stream）比定时全量序列化内存更加高效、确定且易于时序倒带。 - **可视化即压力测试**：把数学抽象（如由半空间平面定义的凸多面体）转化为直观几何形态时，极端情况下的视觉破损能瞬间暴露出被忽略的数学边界错误。 - **副产物转化为黄金测试集**：一次真实游戏会话录制下的海量查询数据，意外为原本缺乏测试的几何算法库提供了数十万量级的真实测试用例。 ### [01:10:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=4200s) 捕获与可视化数据：程序员的核心工作不是“敲代码” Mike Acton 接着阐述了他解决复杂技术问题时最为推崇的工作流：建立庞大的真实场景测试数据库。他会把游戏运行时的真实数据录制下来，随时随地调用，从而彻底摆脱每次调试都必须重新加载游戏所带来的漫长迭代成本。更重要的是，这套流程完全解耦，不仅可以在便携笔记本电脑上运行，也可以搬到他偏爱的 Linux 环境下使用各种 Linux 原生工具进行分析与批处理。正因为能够直面这些底层真实数据，迭代变得极其轻松迅速，得出的优化结果也远比凭空猜测好得多。Mike Acton 强调，无论面对何种问题，只要亲自去观察数据，总会撞见一些事先完全预料不到的情况，这也是他在工程实践中最享受、认为最实用的一点。 ```mermaid flowchart TD accTitle: 数据驱动的调试与迭代流程 accDescr: 展示从录制真实场景到捕获可视化，再到发现隐蔽缺陷并优化的完整循环。 subgraph Capture["1. 数据捕获"] A["真实游戏场景录制"] --> B["构建离线测试数据库"] end subgraph Analyze["2. 环境解耦与分析"] B --> C["脱离游戏引擎重载<br/>(支持笔记本 / Linux 工具链)"] C --> D["捕获与可视化<br/>(视觉 / 听觉等多维度呈现)"] end subgraph Insight["3. 洞察与验证"] D --> E["发现隐藏缺陷与意外数据表现"] E --> F["精准迭代优化算法"] F -.->|"回归验证"| B end ``` Casey Muratori 对此深表赞同，指出“捕获并可视化”（capture and visualize）正是绝大多数硬核难题最终得以迎刃而解的方式。许多时候，程序里隐藏着开发者甚至根本不知道存在的暗病，直到把数据真正绘制成图形、呈现在眼前时，才恍然大悟。Mike Acton 进一步引申指出，寻找不同的维度去审视问题——无论是用眼睛看、用耳朵听，还是用其他感官形式去感知数据——才是程序员应当花费绝大部分精力的核心工作，而不是把生命耗费在编辑器里敲代码。对于业内某些认为“这种写法代码太长、打字太累”的借口，Mike 毫不留情地予以痛斥，认为敲键盘打字充其量只应占到工作精力的不到 1%。 - Mike Acton 直言许多程序员误解了自己的职业本质：“Like, programmers think that their job is to write typing, like, write in code, and that's really not it.”（程序员总以为自己的工作就是打字、写代码，其实根本不是那么回事。） - 他对抱怨代码量多、打字慢的论调极为反感，爆粗口直言从来没有项目死于打字：“Like, really? Fucking nobody ever didn't ship a game because it took too long to type.” - Casey Muratori 顺着话头打趣道，要是打字管用，“给足够多的猴子和足够多的打字机，连莎士比亚都能敲出来”。 - 访谈在观众的笑声中走向尾声，Casey 对 Mike Acton 带来的深度分享以及精彩的技术清单表达了由衷的感谢，正式结束了本次 HandmadeCon 2015 的精彩对话。 ## Notable quotes > [10:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=600s) Adding stuff to the problem does not make the problem simpler. It never makes the problem simpler. Adding something always makes it more complicated. — Mike Acton > [12:45](https://www.youtube.com/watch?v=qWJpI2adCcs&t=765s) It's the simplest solution that solves exactly the problem that I had. That's the right answer. Anything else is fucked up. Why would I do anything else? — Mike Acton > [01:04:19](https://www.youtube.com/watch?v=qWJpI2adCcs&t=3859s) Whenever a programmer says, 'I'm going to do something else because I'm feeling lazy,' usually it involves way more work than the original thing, which is true, absolutely, in this case. — Mike Acton > [01:10:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=4200s) Fucking nobody ever didn't ship a game because it took too long to type. — Mike Acton > [01:10:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=4200s) Like, programmers think that their job is to write typing, like, write in code, and that's really not it. — Mike Acton > [03:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=180s) My job, as much as possible, to be multiplied by what everybody is doing. So as much as possible, I need to be making everybody else better and spending time figuring out how to help them become better programmers. — Mike Acton > [01:00:00](https://www.youtube.com/watch?v=qWJpI2adCcs&t=3600s) I think you should be able to organize your time so that, you know, you can get something out of 30 minutes if that's all you have. — Mike Acton ## Mentioned Mike Acton, Casey Muratori, Tommy Refenes, Tim Berners-Lee, Justin Bieber, Insomniac Games, Molly Rocket, Epic Games, Ubisoft, Autodesk, Adobe, Electronic Arts, Commodore-Amiga, Sunset Overdrive, Super Meat Boy, Ratchet & Clank, Doom, Asteroids, Handmade Hero, Maya, Unity, Unreal Engine, Collada, FBX, IFF, SWF, PSD, OBJ, SpatialDB, x86, x64, ARM, PlayStation 3, PlayStation Network, Linux, CppCon, HandmadeCon 2015 ## Video description For more information, or to purchase tickets to a future HandmadeCon, see http://handmadecon.org. [Source](https://www.youtube.com/watch?v=qWJpI2adCcs)

[10:00] Mike Acton: Adding stuff to the problem does not make the problem simpler. It never makes the problem simpler. Adding something always makes it more complicated. [12:45] Mike Acton: It's the simplest solution that solves exactly the problem that I had. That's the right answer. Anything else is fucked up. Why would I do anything else? [64:19] Mike Acton: Whenever a programmer says, 'I'm going to do something else because I'm feeling lazy,' usually it involves way more work than the original thing, which is true, absolutely, in this case. [70:00] Mike Acton: Fucking nobody ever didn't ship a game because it took too long to type. [70:00] Mike Acton: Like, programmers think that their job is to write typing, like, write in code, and that's really not it. [3:00] Mike Acton: My job, as much as possible, to be multiplied by what everybody is doing. So as much as possible, I need to be making everybody else better and spending time figuring out how to help them become better programmers. [60:00] Mike Acton: I think you should be able to organize your time so that, you know, you can get something out of 30 minutes if that's all you have.

[70:35] Mike Acton: Fucking nobody ever didn't ship a game because it took too long to type. [50:00] Mike Acton: It's like you're intentionally making the problem harder by ignoring the context, by trying to make it too generic. [35:10] Mike Acton: If I can understand the source input data, then I can pretty much figure out what the rest of the system is doing, or must do, right? [60:00] Mike Acton: You know, as a professional and as an adult person, I think you should be able to organize your time so that, you know, you can get something out of 30 minutes if that's all you have.

[0:00] So it's about time to get started again. So one of the things that people who watch the series on Twitch know that oftentimes in the Twitch chat or even on the stream, data-oriented programming or other terms like this come up, and pretty much universally what everyone mentions and what I mention on the stream is, Go watch the CPPCon keynote by Mike Acton. Go check it out. It's a fantastic lecture. And it's just the perfect thing to point people to as an introduction to sort of the same sorts of stuff that we always talk about and given by somebody with a... with a lot of credibility industry as well is pretty great. And so when I was putting together who I wanted to come talk to you today, I was like, well, I don't know Mike Acton, I never met him, but I was like, I'm just going to send him an email and see if he wants to come because I know that everyone would love to hear what he had to say and he was able to make it so. Thank you very much for coming, and we're going to talk to him. I guess he was making notes during Tommy's talk, So he actually has some stuff that he wants to talk about separate from my list, so this should be pretty good. So please join me in welcoming Mike Akin. All right, so Mike. I do have to say this is an entirely different reaction than I got from the C++ program. Okay. What can you do? So before, you know, we'll--we--we--I'm interested to know what's on the list, but before I ask about that, I just wanted to say quickly, for people who don't know very much, Like, for people who aren't in the game industry, for example, obviously you do the technical direction at Insomniac. Tell them just a little bit about what that actually is, because there's probably people who have never worked at a game company before. Those people would not even know what that necessarily means, so-- Okay, so we have an engine team, and... In the AAA space, I'd say we're about... We're at the low end of size in the AAA space, so our engine team is about 20 people. 20 people. And that includes the--our--our--our team. Engine support people, which we have. Two people who are not programmers. on the team, basically doing testing and other organization stuff for the team. Um... And so, yeah, it's the engine team. And we do not just the engine runtime, but also the tools. and supporting all the current that we're working on, which tends to be somewhere between three and six active games in the studio. That's a lot for 22 people. Sure. I mean, so, yeah, I mean, we do all that engine and tool support and chase around the studio. I mean, the rest of production, which is another roughly 190 people, are divided into their various productions and shared... you know, groups and things, and so, yeah, we're running around supporting all the games development, and working on the engine and active forward features and whatever, you know, the current fire and problem is and whatever the current demo is and whatever the current thing that the publisher wants and that we want, you know, to show off in terms of, our vision of the game and-- in tech. So yeah, it's a lot of stuff, and I think, you know, there's that, you know, we are, like I said, sort of the small end of AAA. But, you know, that means that it's very rapid. Like, you really have to be moving fast, and there's no room for slop at our scale, right? a bunch of games in development and a team, you know, of this size, and you have to support everybody, and you stop to make forward progress on an engine, and you have to make all the tools and everything. Everybody's moving all the time. And so what's your role in that? So my role is the director of the team, which is you know, largely to work with, you know, work with the team, and work with the leads on the team, and organize, and, and make sure that we, you know, it's, Well, I like to tell the team that your job is what you make it. And I think that's true of just about anybody, right? You find out, you figure out what your best way to contribute is. And for me, you know, as a director, that's really sort of sitting down with everybody. Sometimes it's architectural review and saying, you know, what it is that you are doing and how do we approach it and is there a better way or is there Can I just ask the right questions to sort of cut off this, you know, a path that's going to waste a bunch of time? Okay. Um... Or is it sort of low-level review? I'm just looking at some code and doing that. Or is it, you know, it's actually valuable for me to sit down and write something here, right? Okay, so sometimes you'll actually jump in and do something if that's, like, really critical at that point or something. Sure. Yeah. I mean, it happens sometimes. You know, usually, though, that's not the highest-value thing I can be doing, right? I want... My job, as much as possible, to be multiplied by [5:00] You know what everybody is doing? So as much as possible, I need to be making everybody else better. and spending time figuring out how to help them become better programmers. And that's really where--or better leads or whatever it is, right? And that's really where the value comes in for what I do. So, like, you know, obviously, I think most people have probably seen the CppCon lecture and the sort of stuff you talked about, about focusing on, you know, what the actual problem is and the data and transformation and the hardware, all of these things. Do you find that at, you know, at your scale, which is, you know, 20 or so programmers who are working on, you know, Engine--Console Engine stuff, Do you get a lot of... are most of the people on that team of the same opinion as you about those things? Or is that, like, is there some degree of tension among people about, like, a lot of people want a lot of object-oriented stuff? Like, how does that look on your team? Because I don't really know. Because you're essentially a person with a very specific opinion about that. And what does the rest of the team look like? I would say, well, I mean, to be fair, most... you would be... everybody looks moderate by comparison to me. Okay, okay. So that's true as well, I think, on our engine team, right? And the further away I think you get from the engine team, the more that's true. You know, when you get to the sort of the gameplay team, they're going to be... less in that space. Okay. But I think even among--I think even among the engine team, though, I mean, I think we're all, you know, about the same-- kind of fundamental principles. We're all about understanding what it is that we're doing. And it's really the small things that are different. And it's about how much we compromise that's a difference. So there's no fundamental argument. There's certainly no one on the team that's saying, you know what we really need here is more abstraction. What we really need here is to spend some time making UML diagrams. There is no one on the team that's doing that. So yeah, it's a matter of scale. how much is too much and how much is it-- where is something else really more valuable to spend time on? So I think maybe as a team we look extremely as a whole compared to other teams. So you're extreme in an extreme team, in some sense? Yeah, to some degree. But I think, yeah, I mean, I think everybody really wants to understand, you know, not just their data, but what it is that they're doing and and fundamentally solve, be rational about how they solve problems. So within that space, if you're working with smart people who want to be rational, Um, it's hard to go wrong, really. So-- So, uh, like, one of the questions I wanted to ask, because it's something that I get asked a lot of times, and I'm not really in a position to answer, on the show is A lot of people worry or have the understanding that a lot of the things that have to do with maybe like object oriented programming or other--the kinds of programming that you were explicitly saying aren't very helpful, like in the Cppcon thing. that those are necessary for larger scale... They have this opinion that, yeah, okay, if they start to believe that focused problem-solving kinds of programming works for one person, they don't believe it would work for 20 people, and somehow the, like, object-orientedness is necessary for... or it comes as part of this attempt to make the programming scale up to larger teams. And so as someone who is actually, you know, in charge of making sure that such a team runs smoothly, Would you say that's accurate, inaccurate? Would you--you know, what are your thoughts on that kind of a comment or question? Right. So here's the problem with the question. Perfect. Which is that you can't defend the question. Okay. Right? You're giving me a secondhand question. Certainly, yes. Right? So, you know, what I would be asking whoever was asking the question was, you know, who From where do you get this? Is it because somebody told you? Is it because this is your actual experience that you've been working in space for this But, you know, I mean, basically the answer is no, that's complete bullshit. It makes no sense. Like, that's why you would want to get to the heart of the question, because the question doesn't make it sense. Okay. There's no evidence to support, none, zero evidence to support that. In fact, I think, you know, if you looked at, if we just did a search of the most successful, you know, you know, the libraries, for instance, that have survived the longest or have been the most successful, you probably wouldn't find a deep object hierarchy in them, right? Okay. You would find sort of simple, you know, interfaces. You know, they might have their own problems, but, you know, the simple, you know, input-output interfaces are going to certainly last long. you know, the test of time and be complicated and support--I mean, how many projects have [10:00] Lib C or Lib M, right? You know, that's a fairly large scale, right? And lots of projects have used them. And, you know, to be honest, I think that the real answer to that is it's actually counterproductive to scaling to a large scale. project. You know, if we look at deep object hierarchies and that kind of design, you know, and I'm sort of imagining in my head what... that design looks like. What happens is you're hiding so much valuable information and you're creating so much not valuable information, sort of adding to the problem, right? that you're making the problem more complicated than it is, And when you have a bunch of people, a hundred people, a thousand people, all making the problem more complicated than it actually is, it's orders of magnitude, ultimately, of just bullshit that you have to get through to get to what you actually need to do. Yes. More bullshit, right? And that, I think, is problematic. Like, it's actually going to be more brittle and harder to understand and more difficult to change and more difficult to test. to be poor performing, than the equivalent You know, you don't even know that it's equivalent sort of data-oriented model, but it's just the equivalent simpler model. Right, just reduce the level of that abstraction as much as you could have instead of-- thinking that you were adding some benefit by making things more removed. Right. I think adding--I mean, and this is the thing that I disagree with a lot of people on, is that adding stuff to the problem does not make the problem simpler. It never makes the problem simpler. Adding something always makes it more complicated. So you want to find the absolute minimum amount that describes the solution that you're dealing with or even the problem right this is the minimum set this is the minimum thing And that's what your solution is, right? That's what you're dealing with. As soon as you start adding, Even just adding small models that are in your head, like, "I'm thinking of the problem in this way," that's something that you're now adding to... the problem space. And now somebody else is going to come and read it, and they have to reinterpret this model that you had in your head on top of what the actual problem is. And that's going to cause confusion and it's going to, you know, And this is why, you know, this is why they say one of the difficult problems in programming is naming. Because by naming something, you are introducing... - A preconceived notion. - Yeah, you are introducing problem space. So you're introducing your mental model to the space. That just doesn't exist there. To that point, I did have one of my notes from Tommy's talk. where he... Tommy, where are you? Yeah, sorry. You were first. Sorry. You're just going to have to live with it. Um... You said that, you know, you had-- you're talking about the physics. stuff that you were doing, or the controls actually, you were talking about the controls. And you were saying, you know, you have this sort of garbage formula, this is your word, right? Garbage formula, garbage data. And that didn't make any physical sense. Right. That was also your quote. Now, so here's the problem I have with that language of that, is that I think that, you know, the preconceived idea that the physical... model, that take trying to apply sort of a real-world model to this That's better. is a problem. that that's not...it's not better. In fact, you've demonstrated through your game that that's not better, right? That you've picked a model that is better for your game based on your testing, based on that three months of hard work, based on, you know, Having a very clear input and output, right? The input is the controls, right? Your physical input. The output is Tommy Smiles. Right? That is very clear input output scenario, right? And Uh, but the answer to that is the stuff that you came up with. It's not garbage, it is the right answer. It works. It's the appropriate response. The way you did it, sort of testing it and iterating on it, and it doesn't matter that there's not a name, you know, you had to create a name for, you know, twisting physical whatever in the air, you know, but it doesn't matter that it's not real. Right? It doesn't matter that it doesn't fit the model. I think you, you probably lost time by thinking that it should have fit the model. And I think coming back and now even reflecting on it and still using the word, say, garbage, when you're referring to it, sets the wrong message. It's in fact the opposite. It's exactly the right thing. Garbage would have been trying to make it... real, right, because it wouldn't have been fun. That kind of gets at sort of an--I suppose an interesting mentality there that's true for a lot of stuff, which is just there's a notion of-- [15:00] That there is some like, you know, proper programming, elegance, something, blah, blah, blah. And then if you're not doing that, you kind of have to couch your statement about what you did. Like, if you're not using a real physics engine, simulating all of this stuff or whatever, you have to call it a garbage formula. so that people don't say, "Oh, you don't know how to program, you're just doing these, like, hacky formulas or something." Kind of sounds like what you're saying is like, no, no, no. Like... The problem is to make this thing do what it's supposed to do, and whatever is the correct solution to that is the best programming you could have done, basically. Yes. Across the board. It's the simplest solution that solves exactly the problem that I had. That's the right answer. Anything else is fucked up. Why would I do anything else? And so yeah, that whole idea that there's that you can take There's a solution in the ether without context, without understanding the problem that must be the right solution to this problem, is such complete nonsense. I... There is no other space that I can think of that's like that. That's just complete and utter nonsense. So why we think that that's even a thing is unfathomable to me. But it is, and we know it is, and people do bring that kind of stuff all the time. Okay, so did you want to... I don't know what's on the secret list over there. I'm kind of like leaning over my list here. Let me see. So I asked you some of the... Let's see what's on your list first, because if you had something you wanted to talk about, I should not... I should not interrupt. So you tell me. Okay, my list is totally random. Just stuff that you're talking, Tommy, just sort of like occurred to me. What I need to do is get you and Tommy up here to talk and then I can go to lunch. So-- You mentioned that you couldn't lock down controls. early. which sort of locked down the level design, or designed the levels around it. And I think this is a really super important takeaway for everybody. This is not a lesson to ignore. Another--so I'll bring an alternate--another example of a similar kind of thing. which is you know working on an open world game, which is much more common nowadays, right? And we were working on Sunset, the Sunset Silver World game. And one of the things that people-- many people don't realize that it's sort of a fundamental function-- everything is a fundamental function of, like, this one piece of information is critical to designing everything in the game, and that's movement. the... Especially in an open world game. Because when we're talking about an open world game, we're talking about physics. I mean, real world physics. Like we're streaming off of a disk, ultimately. Everything's not a memory. It's got to come from a disk, and that disk has real speed. It's actually moving around. So when you say real world physics, you don't mean simulated physics, you mean the actual physics of the world spinning the disk. But this is a more human-relatable physical problem. Like, there's a spinning thing. Um... And so, you know, getting the data off that, this is a real issue, right? And even under the best scenario, the best circumstances, where, like, the best circumstance is really, say, a console space, where you know the console manufacturers just bought the shittiest hardware on the planet, right? But at least you know that, right? There is a baseline there that you can work with, unlike the PC. Where there's probably a whole barrel that they missed that's below that, that somebody who's buying a PC could find. Right. So you have to work with that, right? And you have to know that this is-- Basically the expected seek speed that you can potentially get off this drive and this is the absolute you know what you what you could do Statistically, guess, you could get off of these drives in terms of bandwidth. So those are sort of baseline information that you absolutely have to have to make any decisions at all. And then you have movement speed, right? Yeah. So you're moving around, and that's determining sort of what you're loading in, which is determining how much-- Right, how fast can you get from here to here is how much time I have to stream in whatever's there. Exactly, right. So, which will ultimately determine your budgets, right? If I'm moving faster, my budgets get smaller because I can only-- Very good point. Um... Assuming you have your world divided up in some kind of tile, right? And so, you know, you say your movement speed is, say, it's like 50 meters a second. That's a completely different game. than if it's, say, 10 meters a second. Because now your world, you know, your sort of tile budget is significantly different between those two things, right? Radically different. How you design the world, how much you can load, you know, all that is just these radical differences between those two choices based on this one variable. That's pretty interesting, too, because that sort of is, especially if you're talking about a large team, that basically affects everything. [20:00] Almost everybody who's working. Yes. The artists have to know this because they need to know how detailed to make their stuff, what it will look like, you know, especially if there's lotting that happens or something like this, What can I really expect to see? It affects the programming team, because they have to think about, like, okay, what are we--you know, how are we going to design this for balancing the thing and everything? So that really--that one number, I guess, could-- could pretty much change literally everyone's job in the company depending on where you set it. Sure. So let's say you started, I mean, we can go one of two ways. Let's say you started out slow, right? You say, I'm just making up numbers here. Let's say you started at 10 meters a second. And you're going through-- you do a year of development. And all of a sudden, through iteration and everything, programmer says, no, wait, you know what? 15 meters a second, that's fun. Okay. So now you have to go back and basically toss all the level work that you've done, redo everything, in a year, and if you have 50 people or 100 people or 200 people, or if you're Ubisoft and you have like 5,000 people all working on levels, you're potentially throwing millions and millions of dollars to say start over. And maybe that's worth it. Yeah. Probably it's not. You know, and that's just because, you know, if you're moving that much faster, your budgets have to be that much smaller. Right? or if it's the other way, right? Let's say it's the other way. You start out 50 and you go a year of development, you say, you know what, really? We're not getting much, much out of that. We can slow this way down and we can, being comfortably, just like maybe you have more detailed environments, but at the same time, now you have the opposite problem, right? You've done all this work, and hasn't taken advantage of now this extra buffer. Right. So your game may look kind of lousy by comparison to somebody because you could have put all this detail in there, and instead it's very spare because it had to... fit some streaming budget for, like, basically a racing game at this point, whereas you're a walk around, look at this game. So, I mean, the lesson isn't really about locking down controls or about the movement speed. It's about, you know, figuring out what these sort of keystone variables are in your game. or in whatever the problem space that you're dealing with is. because if you ignore them, if you don't understand what they are, and they're always there, and if you don't know what these keystones are, what's going to happen is you're just going to fuck yourself. Because if you didn't pay attention to that, you're just going to assume that I can just load the level. You're just going to assume that it's going to work out. And then you're going to say, well, I can just optimize at the end, which is the worst. Anytime I hear that, I just want to slap somebody. You're going to get to the end. who's paid to be like slapped. I think there's a chain of people. Okay. By the time it gets to that one person saying there must have been a chain behind them of people that need to be slapped. A big long slap, like a running slap. . Yeah, I'm just imagining that right now. Sort of fun. So yeah, I mean, understanding what those keystone variables are is critical to doing your job properly. Otherwise, you're just going to end up with sort of garbage, and you may or may not be able to make it work and ship it, but it's either going to be really poor or it's not going to take advantage of what it could have had. And if it's not taking advantage of it, then it's doing a disservice to your players, ultimately. Um, and it's, you know, that's unprofessional. So is that something that you sort of do organically, I guess, or is that something that's actually more, a little more, I don't want to say formal, but like, Do you actually sit down when, like, you're working on a project at the early end and... you know, come back to the design team and go, look, These, you know, looking at the way we're--this, you know, we're sort of talking about this game, these are the very critical factors that you guys need to nail down, like, now. Because you can't be, you know, changing this or that. Or is it not, like, you know, how does that actually play out for you when you're actually doing something like Sunset Overdrive, let's say? So, yes, I think there are some, you know, when we can identify them, and, you know, basically as soon as we can identify them. And we say, there is a massive knock-on effect to making this decision. then yes, we absolutely bring that to everybody who will listen. Everybody has to just shut me up about it, basically. Because yes, this is absolutely critical and must be decided. Or you have to understand the cost of changing your mind. Of what's going to happen. Which is sometimes happens. Sometimes they say, I understand the cost of changing my mind. I accept that cost, but I still don't know the answer, so we have to move forward. Okay. Okay, fine. That's just the way it is. But yeah, I mean, absolutely, you want to identify those and make it as loud as possible. And you know what, sometimes people don't want to hear it. People don't want to hear that, I have to make this decision now, and you just have to do it anyway. Sorry, it doesn't matter if you don't want to do it. So yeah. Uh... Yes, that's the answer. Makes perfect sense. Was there another thing on the list? I have more things on the list, yes. Okay. Well, so I have, I think I can figure... [25:00] The thing I was going to ask, we've got to, let's see, 12.50 is an hour, so we've got plenty of time left, so why don't you do a couple more on there, because the other things I have to ask I think will fit relatively easily. You have to ask. There's a couple things I'm like, I gotta ask these. I gotta ask these. So, exporting cinematics. Right. So Tommy mentioned exporting cinematics as a problem on Super Meat Boy, a time-consuming iteration thing, right? So I would like to share that exporting cinematics as a problem does not go away at any scale. And in fact, I mean, Ron, who is, I guess, the inventor of the cinematic for the most part, could probably attest to this being true from the very beginning. So you can ask him that. If that was true, I'll add him right now. So, you know, we were looking at sort of cinematics in Sunset Overdrive, and all of our cinematics are real so you expect that that would in fact not be a problem But real or not there is a large animation and a lot of hand work that the animators do in Maya in our case. And when you're saying cutscene here in this case, nowadays it's an in-engine kind of a thing? It's in-engine. It's all real-time. It's all real-time, so it's not pre-rendered, but it is actually... Pre-designed. Right, and the canvas here and this and that. Yeah, yeah. I mean, it's somebody by hand. Like, we have a cinematics tool that lets them lay out tracks and do all the things and set up per frame. And, you know, you have a music track that everything has to be synchronized to the music track in some cases. You have, like, the first, the opening cinematic in Sunset Overdrive had 90 shots. So it's a very complicated cinematic, right? And you have to still deal with all the fact that it's the game and it's all the real-time things. and you still have to deal with texture streaming and all the things that happen. 90 shots in the opening cutscene. Yeah. That's a lot of shots. So it's a time-consuming process to build, but it's also a time-consuming process to export, which we have, which was not a real limit, and were not a real problem until we got to Cinematics and the scope And when you really this is when you really see the limits of the work that you doing we use Collada as our export format Okay. And you can say what you want about Collada, which is, you can start with saying it's not a great format. I totally agree with you. Is it like compressed text? Compressed would be a stretch of the word. So is it like text? It is text. Okay. It's XML. All right. All right. It's, yeah, that's about all. We don't really have to get into anything. Fair enough. Keep going. So, you know, the point of Colada is it's an interchange format, right? It is supposed to be an interchange format, of which, at the point at which it was designed, there wasn't very many. There was no successful interchange format. Right. Other than OBJ, which is not sufficient. And since then, we now have, unofficially anyway, FBX, right? And that's somewhat more compatible with more stuff, mostly because Autodesk owns everybody. Right. Once you own everybody, you can kind of just say, everyone has to read this file format. Yeah. So that's largely the reason why FBX is successful. So anyway we used Colada And it turns out at least using the exporter that we had at the time the exporting the shot you know a cinematic of the scope from Maya and at least just the animation stuff not even including all our sort of real-time tracks. This is just the straight-out animation stuff. Right, just the source input data for the cutscene. Right, just exporting from Maya, just like save this file, was something like 30 minutes. Wow. Just save the file. So you haven't exported it, or that is the export? Are you talking about just saving the NB? Saving the Collada file. Okay, saving the Collada file. I thought you meant saving the NB file. Mike is not including all our stuff or setting up the cinematic. So exporting the Collada file, 30 minutes. Yeah. Okay. So that was brutal. So you can afford to export the stuff from Maya, like 16 times a day tops or something like this before it actually runs out the workday. So you have to start making your next change before the previous one is even exported. Wow. Okay. That was brutal. And that's something, you know, that we have since tried to work around, and, you know, we have looked into, you know, obviously writing a better exporter for Collada, and, you know, looking at alternatives to Collada ultimately. But, you know, I think for now we'll probably stick with it. So it's kind of on your radar, but it has not been solved? Like it's still like, you guys, 30 minutes. Well, I think we have enough in terms of [30:00] workarounds of the problem. Okay. So that it's not-- yeah, it's not on my radar immediately. Like, we can work around it. And we can make it so that it's not-- like, the animators can make it so it's not 30 minute export, for instance, by just not having one giant one. OK, right, so they just break it up into pieces, and then they can pull them in because you said you have a separate tool. We have a tool, and they can set them together. So it's workaroundable. It's not ideal, but it's workaroundable. And so, yeah. But cinematics remains a problem. will always remain a problem. Like, there's always something. So I just wanted to share that exporting cinematics is... From the pain we all share. Um... So, let's see. Um... I can't read my own notes. I'm guessing I probably won't be any better. Um... So, oh, okay, so I'll skip to the next one, then. You were talking a lot about SWF. - Importing. - Importing, right. I don't have any Swift stories, but it reminded me of two things. One is, in terms of, you know, you said you just sort of sat down and read the fucking manual. Like, great, you know, and everybody clapped. Yay, everybody read the manual. So, yes, first of all, read the manual. I mean, looking at your, you know, whatever CPU you're using, you know, most people hear, okay, he was either not using... and x64 base-- x86, x64 base are ARM-based CPU in this room. That's going to be nobody, right? Who's not? Okay. Oh, there's one non-X64, non-ARM. Okay, so that would be--so to cover all of you except that one guy right there, you can read, you know, between AMD's manuals, Intel's manuals, and the ARM manuals, you know, every single one of you should have already read these manuals. right? Um, And I suspect... You're talking about the Intel Architecture Guide. Yeah, you know, or AMD's documentation. But yeah, the Intel books for sure. Yeah. Or the ARM manuals, right? But here's the thing. Without putting you all on the spot, I'm pretty confident that 100% of you have not, in fact, read those manuals. And that's kind of shitty, right? You're spending most of your time on these architectures, you're going to probably spend a long time on them. You're certainly going to spend more than a few months And so it's worth it. If you're spending more than a few months on pieces of architecture, it's worth it. And this is, you know, and I come from a console background, and you know what, every few years or every five years or whatever, they just throw away the shit that we've done and give us something completely different. It's still worth reading the manual, even though we know they're gonna throw it away, right? Um... So just, you know, definitely do that. I mean, take the lesson, and the fact that you all clapped is indicative that you think it's a good idea. So just go home and do that. I also, you know, when I think-- So basically you're equating reading the SWS spec to write an importer with writing, you know, if you're going to write code in this architecture, read the actual architecture and know what it is. Yeah, yeah, yeah. I mean, you should know. I agree, obviously. There's information there that you could find useful that is canonical. Yeah. Start there, right? Basic You know, don't assume, right? Yeah. Yeah. Um, I--there's--you know, it also reminded me of the IFF-- format document, which I think is a classic You mean like the IFF document from Electronic Arts? Yeah. The original one? Yeah. Okay, so just for people who aren't as old as we are, tell them what that is. Most people probably don't know what IFF is. IFF is a really, really simple format that breaks the It breaks things into... and has basically a header definition that says size and type. It was for Electronic Arts back in, I don't know when they introduced it, probably 1982. So it's like a four-byte type, I think, and a four-byte. size. And they're usually ASCII. No, it's 16-bit size, right? No, I don't remember. Anyway, so it's very straightforward. I think it's 32-bit now, but I don't, yeah. Anyway, it doesn't matter. It doesn't matter. The point is that we can look it up. That's the point. That it's well-documented. and it was well documented in 1982, well before, you know, well before it was a good idea to do it. Um, And I think it's the gold standard, which we still have yet to follow very well, of sharing documentation and... sharing ideas and being very clear about these formats. So are you saying that you don't feel like modern-day sort of The modern-day way of doing file formats and that sort of stuff does not adhere to this. [35:00] Perhaps talking about something like PSD, for example, where you look at the spec and it's like, what I'm talking about--oh, okay. PSD is a good example. Okay. Right? It's not well documented. Yeah. Great. But I'm also talking about your own format. OK, so you're talking about, like, on a game, So you're making a Ratchet and Clank game or something like this, and you have some file formats that you're doing. You actually think, for example, that your team should document those internal-only file formats, for example. OK, so why? Uh, okay, why should you document your file for--? Yes, internal--why would you document an internal-only file for? Um, I mean, it describes your data, right? And it's, you know, it's the source--it's source inputs to your system, and it's, you know, probably the most important thing that you're working with. Okay. You know, the most important set of things that you're working with. Everything else can be derived from that. If I can look at--if I can understand the source input data, then I can pretty much figure out what the rest of the system is doing, or must do, right? So I'm pretty sure that if I took, you know, any arbitrary game, out there, and I said, "This is a description of what the source data looks like," and I just released it to the hacker community, they could go to town on this game, right? And because that's the most important information. Okay. And that's obvious that it's the most important information. That's the thing that you would want to start with. And yet, we don't do a great job about... documenting what is, you know, probably the most important information that we're working with. Do you think that's something that needs to be done during the active development so that there is a document which actually evolves with changes to that data? Or are you saying more like when the game ships, part of the process of shipping should be to take the final state of the data and document that? Well, I think it should be accurate. So however that works. Whatever the way... So at the day that the thing ships... Whatever the way is to make sure that the data description is the most accurate, that is the thing you would like. to see happen. Yeah, I mean, I think that some teams, for instance, doing it at the day it ships would be a really bad idea. Because that's the most stressful time for the team and they're already overwhelmed and they're already working extra hard. and to say, "You know what? I know you are working on this sort of like 500 bugs on 20 different PCs and some guys and stuff. You know, I know you're working on that, but can you write some documentation on this file format? The slap goes the other direction at that point, right? It's like wham. So that's probably not going to fly for some teams, right? So it may be much better to do it incrementally as you go and as you change, and just make it part of the change process. Um, But I do think we're talking about multiple different things. I think we're all talking about the internal formats, but we're also talking about the external things when we share, right? Okay. Making that interoperability more and more possible. It does seem like there's been-- I don't want to say a loss of that, but there's definitely, I guess, less of an external incentive for that now to some degree, too, because I guess it just--this is the first time I've ever thought about this, because I don't think anyone's ever said that to me before. So I'm kind of like going in my brain. In the past, we saw things like, for example, Doom had a very well documented file format so that people could mod it, and it led to--there's a-- complete understanding pretty much of everything that goes into that game or something like this. But as I suggest we get more towards the... Steam Workshop style of, like, there's just these tools that people use and no one's ever really touching the data besides the programmers. I guess there's no longer much external pressure on a developer, because there, you know, maybe it's all integrated inside, so it wouldn't... we maybe wouldn't see things like Doom so much anymore. I mean, is that a fair characterization, perhaps, of that? Well, I think one of the things that we should consider is the historical aspect, right? Yeah. And you know, how easy it is to archive and save things. I mean, we can certainly imagine it being much easier to save Um... much easier to save an older game, much easier to save-- certainly an older game that's well documented, much easier to port it to a new platform, you sort of keep it alive. Yes. And the less information you have about it, the less-- you know, the harder it is to save. And we're talking about, you know, if we're-- once we get into sort of a much-- the last 10 years basically, it's already a hard problem. How to archive a PS3 game that runs on a network on PSN is already a really, really hard problem. And to make that even harder is... you know, pretty much just presumes that it's not important to archive the data. Um, And we're gonna lose a lot of that data. I don't know if that's important to everybody, and I'm undecided of whether or not it's important to me. and the scope of things. But if it were important, it definitely is the case that we're not really... Not set up for it, I suppose. And there's something else I think that comes up in practice, right? At some point, somebody's going to say, hey, can you port this forward, right? Yeah, yeah. Um, you know, can you take this, you know, assume, like, okay, [40:00] What we're talking about. It's not that long ago, right? But would you guys consider it a classic at this point? Yes? Yes? More or less, right? Which means that in 10 years, somebody's probably going to think about it, remember it, and want to play it again, right? Maybe all this architecture that we currently presume is different, very, very different, right? And somebody's going to want to port it, and then somebody's going to ask, not you, but the mountains of people that work for you, um, to abhor it, right? Um... And you're going to go, "What the fuck? I don't even remember. That was ten years ago. I'm going to have to watch videos of myself talking about it to even remember what I was doing." you know, having the ability to go back and, you know, have that be well documented, at least in terms of what the formats were and what the data looks like. So you could, in theory, you know... at least break it down and figure out what the cost is but pulling it forward, would be totally worthwhile. um And I suspect very strongly that that will, in fact, happen. That, you know, at some future point, this will happen on some architecture that's hard for us to imagine today. Um, and that you will have completely forgotten, um, what all the data looks like, right? So yes. I don't remember the question. Oh, so another completely random point. I'm as a I have no insight into the list. This is still the same point. We're still talking about SWF. One document I think everybody should read is the Tim Berners-Lee World Wide Web Pitch document. This is--you know, I want to make a World Wide Web. This is the pitch. This is what I'm going to make. And it's very short. It's like a few pages long. Everyone should read this, because what you will learn is pretty much everything that he set out to accomplish, all the problems that he set out to accomplish. Now imagine this worldwide, you know, this is before the web, so this is early 90s or whatever. And everything that he set out to accomplish, all these problems that he wanted to solve, he's literally solved none of them. None of them. All--like, you imagine how much the world has changed, right? How much the web has changed everything--everything that we do, and how we interact with each other, and our business, and, you know, everything, and yet-- Fundamentally, we've solved none of these problems. I'm very interested to see what they are now. You know, which is really, you know, it's really about, you know, You know, it starts with, like, I can't find these documents that are important to me, you know, and it's so complicated and I can't find the documents. Okay, who has a problem finding information that, you know, is relevant to their work right now, today? Right? That's still true. It's still true that it's hard to find that document. It's still true that, you know, even if you have what he imagined was something, you know, very clearly something like a wiki. Right? Okay, how many people have wikis that survive the test of time? Like after five years, you can find everything. It's totally there. It's totally documented. Well, okay, to be fair though to them, as soon as they finish figuring out how to turn these important documents into Justin Bieber songs, the web will work perfectly, right? Because you can always find and get those. So, I'm not down on Justin Bieber. I think he's fine. I'm a huge pop fan. Um... But yes. Continue. It's a data transformation problem. We just have to take the things we can find and turn the things we can't find into that. I think there is some legitimacy to that. arguments You know, I think, you know, and it's in terms of what you can associate information with. I think there's some legitimacy. But in terms of taking the lesson of You know, you have, and I don't know what to take away from this. You've taken, you know, you've taken a problem of insurmountable scope. You know, I want to be able to get this, I want to be able to track down this information. I want to be able to communicate with people. And I want to be able to-- in very specific things, like, I-- I can't find the document that I want. I want a solution that-- I want something that solves this for me. and which has sort of always been a problem in sort of all of human history. Yes. And say, I have a solution for it. And it changes the world, and yet, and yet, you still can't find the document that you want. I find that fascinating. And I don't know what the lesson is, but it's super fascinating. So, yeah, like, I guess, so you're basically saying, take a look at this pitch document. see the things he said he wanted to solve. He hasn't managed to solve any of them, I guess, even though he created a whole bunch of solutions to other [45:00] Problems or whole new problems even. Yeah, that's basically what we've done, right? Create more problems. We've created a lot more problems. Super fascinating, interesting problems. Huge, hugely interesting problems. And you're sitting over there listening to Tommy talk about importing an SWF file. Yeah. And that was what you thought of. Yeah. There's a connection, right? There's SWF format, reading the document, and something to do with that document. Anyway, there you go. All right. So I have some questions for you I want to ask. Is there anything else on the list? Yeah, sure, but go ahead. All right. Because I wanted to ask the things that I can only ask you, or at least out of the people that are at HandmadeCon. So going back to, you know, putting documents aside for one second, because as we already said, you can't find them anyway. So, you know, it's largely academic. Or you can't read them. Or you can't read them. You can't read them or we can't find them, either or. One of the things that I wanted to ask you or to try to get some perspective on, Because, like, I opened this with a question that I had for you that I didn't know the answer to that people often ask me, which was the, you know, sort of scaling, you know, scaling up. Does that change versus whatever, that sort of stuff. But then another question that I get asked often Oh so go back to that question So scaling up Let put your other one aside for a minute That all right So scaling up. So, you know, sometimes I talk to, like, indie groups. Who's indie, considers themselves indie in the room? Fair number. Okay, that's a pretty good number. Sometimes I talk to indie groups. So now I'm talking to you guys, indie group. And they'll talk to me about the engine that they're making or, you know, that they want to make. And they'll be asking questions. And often what I'll see is that they are doing it very similar to, say, what we would do. Or they're looking at Unity and they're doing something similar to Unity or Unreal or whatever. Sort of copying those concepts. You mean, like, looking at, you know, making sort of an editor thing that you put entities down, like starting with that? Yeah, or at the runtime or the tools or whatever. You know, and I have no problem with people making their own tools. And, you know, fundamentally I'm an engine programmer and, you know, that's kind of what I like to do. So I get it, I get it. And, you know, I don't have a problem with people doing that and that's what you like to do. But, you know, what I think that people miss is the context in which they're working. You know you working with a You working on a game right You know in your indie space you working by yourself or with a group of people or students you working with a group of students or whatever and you're missing the context in which you're working. You're looking at what other people have done, and you're sort of just copying that model, right? And so you're looking at Unreal, you're looking at Unity, and you're saying, okay, they have actors and entities and things, and I'm sort of copying that model because that's how you do it. And I think that in the same way that, you know, taking a physical model, mental model, and saying this must be right and everything else is wrong, this is also a poor approach. To say, you know, because Insomniac did it, or because Epic did it, or because whoever did it, that must be the right approach, so I'm just going to sort of copy that, is also wrong. Okay. Because it has nothing to do with your problem. Okay. It has to do with our problem, which are very, very different. And to talk about, you know, to go back to your point, which is sort of what's the difference of scale, right? The difference is huge. It's massive. So when you're talking about one game, or at least one game at a time, and you're talking about an indie team, there's a group of small people who communicate really on a deep level, right? You have seven people, or ten people, or five people, or whatever, that can just communicate together on a deep level That totally changes the game I was talking to one team recently and they started out with the actors and components thing similar I just like okay why do you even have this? Conceptually, these are the components I have. I'm like, forget all of this. What's your game? What are the problems you're actually trying to solve? And they would say something like, okay, well, we have ladders in our game. Okay, cool. We can start with ladders. Why do you have ladders and what are they doing? But let's start with ladders. I'm saying the difference between what you're talking about building, you're talking about building sort of this general purpose editor where, you know, a designer's going to spend time placing a ladder and assigning it a ladder component and doing all that. Now imagine a different scenario by comparison. I know the context in which I'm making the game. You guys are like seven people. I'm going to make an editor that understands that I use ladders. There's a ladder button. Right, there is a literal ladder button, and it shows me on the screen only the places that a ladder could possibly appear. Right. Right? And you understand the constraints. I've defined the constraints under which a ladder can appear. So it's sort of ghosting in all the places that it could possibly appear. And I just click on one. That's the one. Ladder goes there. That's like three seconds to put a ladder. I don't have to waste time like dragging some object in and it's an arbitrary model that's attached to some arbitrary component because I'm not making an arbitrary game. I'm making this game. Yeah. [50:00] And I'm making tools for this game. And that fact that you have that much more context means you can solve the problem that much better. Ignoring the context or, alternatively, if you want to look at it a different way, is trying to make it too generic. Yes. Is the call... you're causing problems. You're making it slower. It's like you're intentionally making the problem harder by ignoring the context, by trying to make it too generic. It's basically the analog of what you were talking about with code before. It's just like, don't introduce extra things in here if they were not actually relevant to solving the problem. Right, and to say it has to be generic or it has to follow this other model is introducing this whole mental abstraction, this whole mental model, into the problem that just didn't exist. And you just made it in order of magnitude harder. It also doesn't seem clear why you would really want to go that route, because if you just want to end up with Unity or Unreal again, you could have just used them. Right, well, for sure. You should be trying to do something that you want to do that's somehow different. For sure, that's your advantage. I think, and that's the--that--just your advantage as an indie in the space, right, is that you have that deep understanding of your context, and you can take advantage of it. You can write things that are just--that cannot be--that cannot be used to make anything else. Yes, yes. But they just kick ass at this one thing, and that's awesome. Um, And even at our scale, right, we can do that better than, say, a team that has to support, you know, millions of people or hundreds of thousands of people. We can do it better than that, but we still can't do it to the extent that a small one, really small... Because we do have multiple games in flight that all have slight differences, and we do have to be more... support a wider range of stuff. So we can't even be as good as those smaller teams. So that's their advantage. Anyway, that... No, that was excellent. I love the list. Scaling. So anyway, back to your... Yes. So my question-- sort of a couple different questions, but it's sort of all the same basic idea, which is that You know, when I got into the game industry, it was so long ago that it didn't look anything like it looks now, for example. So a lot of times, you know, especially because, uh, with the series, It's, you know, a lot of people who aren't in the game industry, but might want to get in the game industry, are starting to, you know, watch it, or try to practice, or do that stuff. And I get asked the question, like, what should I do if I actually want to pursue a career here? Like, what does that look like? And I get... all kinds of questions that I simply can't answer. Should I go to college? What should I be practicing? What does my resume just look like? How do I apply? All these sorts of things. As someone who actually presumably has a little more insight into A, the process by which people come into the industry now, and two, as someone who presumably has spots they need to fill on occasion, and two, I would imagine has a bunch of things they wish were true about the people who were coming through the door. Like, could you give me a little perspective on that so when I get asked that question, I can say, "Well, I don't know, but Mike said This. Right. If it's too tough of a question, then we can... No, I mean, I have an opinion. I can certainly share. I've opinioned about everything. Um... But to start with, I mean, I'll agree with your point. That it's really hard for me to relate to people who are getting into the games industry now as a concept. Like, I can't, I simply can't, I don't have that exact experience that you're dealing with right now. I have nothing to relate to that. You know, you have this mountain of schools you can choose from. I'm like, I don't even know what that's like. You knock yourself out. You know, you have the Internet and documentation and examples and... So yeah, it's a completely different playing field that I don't know. The best person to ask is somebody who just did it, like, four years ago. I guess so, yeah. They're the best people to ask. But in terms of hiring, I can certainly give some insight into what I look for. Um... You know, over time, I've looked for things that correlates strongly with good hires, And whether that's what school you're going to or your test score, because we do have a test. You give a programming test. We do give a programming test. Or your response on the test. Or your work history or whatever. I'm trying to look for things that correlate strongly with with I'm good hires. And there's literally only one thing that I've found that correlates. And everything else doesn't. And that's really, really hard, because it just doesn't. Like, if I said, whether or not you pass our test well, actually doesn't really correlate strongly with how good of a programmer you're going to be for us. Why do you still get it? Partially because, you know, it... And there... There are bits in there that do tell me something. So I do find it useful or insightful. Part of it is just... Fear? Like, what do I do if I don't have it? I don't have an alternative answer here. Fair enough. Okay. You know, I am human at the end of the day, so yeah, I don't have, you know... Always a strong. [55:00] Motivator. Yeah. So, yeah, I mean, the one thing that I have found that correlates is curiosity. Curiosity. Okay. That's literally the only thing. And curiosity to a point where it's insatiable, where I cannot-- Where it's undeniable. Like, you know, if I'm talking to somebody and they aren't They aren't very curious, ultimately. It's obvious that they aren't very curious. I'm going to ask questions and they're going to say, not only do I not know, but I don't care. It's not important for me to know that, to do my job. So I haven't thought about it. That's just a level of non-curiosity that just doesn't do well for working with people. with the group that I work with, with my team. Um, Now, on the flip side, somebody who's insatiably curious, right, where it's just like everything, they may not have enough, you certainly don't have enough time to satisfy it all. But you want to know. You're interested in knowing, right? You dig in and... That sort of thing correlates strongly with being successful on our team. How does that help people who are you know trying to find a job? I don't know I Well, it kind of does in some sense, too. Be curious, certainly, for us on the list. but maybe demonstrate demonstrable curiosity, right? Show me that you are so-- you're curious about something deeply, from, you know, Top to bottom, even if it's just one really great blog post, where you've just dug into something deeply and you've just kept digging until you hit sand. And you're just like, this is everything that I could possibly learn about this in a month. All the little tangents, all the little interesting bits. I just pulled every thread until I ran out of time over a month or whatever. That's interesting and that would be striking to me and that's something that I would want to see. If it's just like, oh, here are three projects that I did and, you know, that's not even a little bit interesting to me. really. Especially if they're school projects, because it's like everybody did that. They had to do them, right? So it's... Whatever. It's an assignment. Big deal. You know, things that I don't care about. You know, I don't really care about what school you went to. I don't really care about your grades. We certainly don't care about what projects you did, I don't care about what classes you took, I don't care anything at all to do with your school. I don't actually even care if you passed or finished or-- Interesting. So, yeah, I care about what you've demonstrated, mostly what you've demonstrated on your own will. Yes. That's what I'm interested-- That's a fantastic answer. So. Thank you very much. All right, so I guess my secondary question maybe is not as relevant. That was... kind of perfect, but I guess I'll just ask it anyway, which was, so... You know, if there was something that I was going to tell people you should... practice or know how to do is there anything that you find lacking in terms of fundamentals, right? Like, it's like, hey, I wish that all the applicants would get, like, even the ones who were curious and, like, you know, they have the right mentality for being on the engine team at Insomniac. Like, that's all set, but I just wish they had done more of X or known more about Y would have been really helpful to us, right? So separate from maybe the hiring question, just more like what do you want them to be to do when they get there. Lots of Java programming, right? I'm guessing. Yes. So again, the answer is not a very technically specific answer. The answer is... practice. Okay. Most people do not know how to practice. And most people don't take it very seriously. And that, I think, is a massive problem. Massive problem for them, really. Massive problem for you and your career if you don't know how to practice. And, you know, not taking it seriously is a big problem. You know, I'm learning--you know, I'm learning what I need to know based on what I'm doing in my--my job. Well, you know, that's not enough. Okay. It's your career. You need to take seriously as your own problem you know and how do you learn and how do you practice and how do you advance your skills for your own career this is your responsibility Yes, you have a job and you're going to do that work. That's great, but separately you have to deal with your career and where you're going and what you need to know. And you have to know how to do that well. And most people do not know how to practice well. I talk to somebody and I'll say, "What do you practice every day?" And they'll say, "Well, I don't really have time every day." I'm like, "Really?" So aside from your family, this is the most important-- this is the thing you're going to spend your entire life doing. So you don't have time for the thing, like you forget to brush your teeth. Like you manage to do other things every day. every day, you brush your teeth every day because it's important to you. You probably change your clothes every day. You might shower [60:00] - You know, there are things you do every day because it's important, because it's part of who you are. And yet, you don't practice. the thing that you don't do with your career. The second thing I'll get is, you know, well, I only have a little bit of time, and as a programmer, I really need to be able to sit down for hours in order to get into the mood to...I'm like, okay, you're not a child. You know, this is, you know, as a professional and as an adult person, I think you should be able to organize your time so that, you know, you can get something out of 30 minutes. if that's all you have. You know, you can absolutely do that. You can absolutely have a plan for how I'm gonna use this 30 minutes and what I'm gonna do, and that's better than doing nothing. Yes. And, you know, this is, you know, it's just sort of a series of excuses of why I don't practice and why I don't know how to practice. And so not taking that seriously, I think, is a huge problem for people. Not necessarily in terms of their contribution to a team, but for their own sake. Like as a programmer, as an individual person with a career that you have to curate for yourself, like this is the investment that you need to put in. Or you're just not gonna be as good as you could possibly be, and, you know, that's presumably what you want, right? You want to be as good as you can be, 'cause this is your chosen career. So you need to spend that time. You need to figure out how to do it well. So what's a good example of how someone might practice for 30 minutes if they, like, take this advice at heart and go, "You know what? That is something I should be doing." What's a good starter project? A lot of times I tell people who are starting out in games, I'll be like, asteroids... is the one to make first when you're, like, learning, you know, how to make games because it's the simplest possible thing, and blah, blah, blah, right? So let's talk about practice, like you said it. What's the simplest way to get started practicing? What would you say would be something-- if you had 30 minutes a day, you were going to start devoting to getting better at programming games? Well, I mean, you could pick something like, say, let's say you were going to pick asteroids, right? Fine. But my biggest advice would be, for a while, for at least, if you're just starting to learn how to practice well, is to throw away everything you do after every practice. do not have any kind of continuity. Interesting. So maybe you work on the same problem, but you are not allowed to keep anything that you did before. I see. So that you simply have to get better at it. You have to get faster. You have to try a different way next time and see if it works better and that sort of thing. Because if you keep it, it doesn't become practice. It becomes a project. And it becomes a hobby at that point. And it's not about a hobby, it's about real practice. So just throw it away and then get better at it. So if it's about asteroids, then ultimately maybe your practice is how can you make it in 30 minutes? What are you doing first? The first day you don't even close. The second day you don't even close. The 300th day? Maybe you're pretty close to be able to do it in 30 minutes. You've done it so many times. That's practice. and that's valuable, right? Maybe you're not practicing the right thing you've gotten really good asteroids in 30 minutes but there's probably something valuable to be taken from that But I mean, really, I think it's, you know, I would say pick pretty much anything, right? Pick a project, an open source project, your own project, whatever. And just start picking it apart, right? You have a plan. How am I going to spend the first two minutes saying what am I going to do for 30 minutes? Have a plan. Got it. And if that's, I'm going to analyze this so I can gather more information, or I'm going to make this bit faster, whatever. Fine, do that. You know, you have a plan. Spend your 30 minutes doing that and then stop and then throw it all away. And then tomorrow, have a new plan. And that's, you know, it's a different, it's a completely different kind of thing than a hobby or a project or a portfolio piece or your work. It's just about the value of the practice is the practice. Is the practice. Well, I think we're just about out of time, so did you have any stuff you wanted to talk about? I don't want to miss anything on the list, but also just if you wanted to say a few closing remarks just about, you know... I guess I asked Tommy sort of if he had any stuff he wanted to mention that he's working on, or stuff that he wanted to talk about, just as sort of a closing remark. So if you've got any...I don't know what you would...yeah, what's your... Days look like these days, but-- What am I working on? So there was a problem. that... I decided to dig into it a little bit. Uh, we have something called a spatial DB, which is not really a database, it's just, uh-- Spatial DB? Yeah. Okay. just to sort of our, it's a sort of our, our mechanism to query things, um, spatially, in our engine. We call it SpatialDB. And I was interested in it and sort of seeing where the edges were and seeing if there was anything that we could do in terms of optimization. And so my approach was, [65:00] I wanted to look into this more deeply, so I'm just sort of sharing what my approach to this was. And so I thought, okay, well, maybe as the game is playing, I can sort of just serialize it at certain points, and then I'm sort of sampling it, right? Serialize it and then analyze it offline and say, where was this at this point? And so I can look more deeply into the data. So periodically, you would just sort of say, at this, every n seconds or something, I'm going to stream out, what does the DB look like here? And later I'll go gather them back up in a separate thing and start to see what's the new. Yeah, that was my original plan. And I'm looking at it and I'm like, okay, well, one, it's not really DBE in any kind of, it's an interface, and that format is fairly optimized and fairly complicated and changing. And I'm like, you know what? I'm not going to do that. I'm feeling a little lazy. So instead, I said, well, you know, what I'm actually going to do is there's a very limited number of entry points into this data, right? Very limited number of ways that you can even change the data. So to sort of like add something to the database or edit something or delete it, really, that pretty much the whole initialization function So that pretty much it I like fine I just gonna stream out like a command I going to stream out all the entry points to this database so I can recreate it offline Now, whenever a programmer says, I'm going to do something else because I'm feeling lazy, usually it involves way more work than the original thing, which is true, absolutely, in this case. So I streamed out all the entry point stuff, and now I have a system that, you know, I used to command, but from reading system, where I'd just read it all back in and reconstruct the databases at any point. So now I can have a complete timeline. I'm playing the game, a complete timeline, and I can scrub or whatever of everything that happened to the database at any point while I was playing. That's awesome, right? So I can do a lot of queries in here and see how it's going. And sort of discovering, sort of doing analysis and spinning out a bunch of data and analyzing tons of information that was super valuable. And then I said, you know what? There's a bunch of queries that are coming in, you know, people asking in the game, you know, I want to get stuff out of it. That's the whole point of the space of the data is to do queries against it. So I'm like, I want to visualize the queries, like visually. Oh, nice. Like I want to see, you know, what they look like. So I'm, I'm, and our queries all come in as sort of convex hull divided by, defined by planes Okay so it comes in as a series of plane equations that bound some 3D space like a polytope Right So I like okay that fine You know I want to visualize that so I going to visualize it as the hole, right, as polys. So we have a clipping function that will take a set of planes and clip it against a predefined hole, or a triangle defined hole. And so I'm like, okay, that's I'll just take a big, basically a big cube and slice it up by all these planes. Right, just make sure the cube is bigger than whatever the bounds of the planes are, and then I'll just let it carve everything that's not the elephant. We remove that marble and the elephants left. Right, yeah, so it's fairly straightforward, which we use for various things. And I'm just going to use this to sort of visualize the spatial. Okay. Right? And it doesn't work in some cases. Okay. So I'm looking at it, and I'm like, okay, well, you know, there's these cases where it's just, you know, I'm just basically getting garbage out of this, right? Yeah. And, you know, I'm just, I wanted to visualize it. And it turns out that the problem is in that clipping routine. Yeah. Which we use in various places but you know the problem only showed up because you know I have this huge set of data that I gathered and all these different queries you know hundreds of thousands of queries over time and every variation on it right And I pretty much just have this massive test database now. For the Polygon Clipper, yeah. Right. And just this gigantic test and I can split it against like, you know, because I just have this like, you know, because I just have this sort of history of the data, I can just go back and forth and see exactly what goes wrong and there's not actually a slider, right? That's mentally sliding. But, you know, so I went down this rabbit hole of, like, fix the clipper. Yeah, yeah. We've gotten to fix the clipper from I'm going to take a look at the spatial database. Right. But, I mean, the thing about it is is just looking at the data, right? The lesson for me here is, you know, I started out with something else, right? But it's just about visualizing the data, looking at it and analyzing it. And while I did find out lots of interesting things about the spatial database, I did also discover things about a completely unrelated system that I didn't expect. Like I found some prizes in just trying to visualize the data that also needed some attention. So just the sort of effort of visualizing and just the sort of effort of digging into the data, not only, and it's helpful to fix. Like offline now I have this gigantic database I can test against. It's a perfect test suite. Absolutely, my turnaround time is like, you know, less than a second to just test against [70:00] massive database of tests that are all real world scenarios, right, that I've just recorded and I can get as many as I want. Certainly not reloading the game, the iteration-- that kind of iteration time. And I can do it on my laptop, or I can do it in Linux, right? I like Linux tools, so I can do it there. So super easy to iterate on and I have a much better result just because I'm looking at the data. For me, this is the approach that I like to take to problems, the approach that I find to be useful. And it's always surprising, you know, it's I it's there's always something that I hit that I didn't expect to hit just because I looked yes and I feel like capture and visualize is kind of like the way most hard problems end up getting solved. And sometimes problems you don't even know that you had, because until you actually see the visualization, you don't actually realize. I think finding different ways of looking at the problem, like in terms of your eyes, your ears, or whatever, looking at it... is an important part of what we do. Like, that's where we should be spending most of our time, and not in the code. Like, programmers think that their job is to write typing, like, write in code, and that's really not it. Like, that should be less than 1% of your effort, right, is the typing part. Which is why I don't want to hear, like, it took too... I don't want to do this because it takes too long to type. Like, really? Fucking nobody ever didn't ship a game because it took too long to type. Well, if you get enough monkeys and enough typewriters, right? Well, I think that's all the time we have. Thank you so much for the conversation. It's been awesome. All right. And that was an excellent list as well.