从求生之路到喋血复仇 他们创造了打丧尸时代 也是悲催的倒霉蛋

Posted 2023-04-27

参考技术A 相信在不久前玩家都跑去下载《喋血复仇》（Back4Blood）来体验了吧？不知道玩家玩了这款 游戏 之后，对于这款《求生之路》（Left4 Dead）的精神续作有什么看法呢？而你们又知不知道Turtle Rock Studio这个工作室经历了什么呢？

Turtle Rock Studio作为一个拥有丧尸 游戏 天花板之称的工作室，在2008年和2009年以《求生之路》这一部系列神作成为丧尸 游戏 的标杆。但是，在那之后Turtle Rock Studio却经历了非常多的挫折，今天就来和大家分享下，Turtle Rock Studio从《求生之路》到《喋血复仇》的故事。

Turtle Rock Studio是由Michael Booth所成立的，在还没有成立之前，他和两位朋友Phil Robb和Chris Ashton三人都在Westwood Pacific工作，只要是开发一些RTS 游戏 ，像是《命令与征服》系列作品。

某天，Chris发现了《CS》这款 游戏 ，并且对它产生了很大的兴趣，所以选择帮他们开发 游戏 担任团队的图形设计师。可是，那时候的V社也相中了这个团队的潜力，并且招募他们加入V社。就这样Chris加入了V社，与此同时Westwood Pacific也被EA收购，这一举动让Michael和Phil觉得Westwood的文化会因此变成EA的样子，所以选择了离开，于是Michael选择成立一间小型独立工作室，并且用住宅的名字作为工作室的名字，就这样在2002年Turtle Rock Studio横空出世。

Turtle Rock Studio最初只是一个6人团队，庆幸的是曾经的同事Chris将他们推荐给了V社，让他们也参与《CS》的开发，也因此Turtle Rock Studio在刚起步的时候可以说相当幸运。V社先让他们将《CS》移植到Xbox上，然后在2004年让他们参与了《反恐精英：零点行动》的制作，G胖也在过程中非常欣赏他们的能力，便开始重用他们，让他们参与《反恐精英：起源》和《半条命：死亡竞技》的开发项目。

玩家们应该也知道，《CS》和《半条命》这两个IP在当年有多火爆吧，所以在V社有所成就的他们便决定自己开发一款 游戏 。

起初他们想要制作一款魔法元素的 游戏 ，但那时候的 游戏 技术需要花很多时间去制作，甚至根本做不出来，所以他们打消了这个念头。而其中工作室的员工也不是很喜欢竞技的 游戏 玩法，因为《CS》对他们来说并无法和朋友愉快的游玩，很多时候会因为朋友技术过强而吵架，也会破坏彼此的友情，所以他们想制作一款PVE多人合作的 游戏 ，让朋友或者家人之间可以愉快的游玩。

最初他们选择在《CS》中开发模组来测试，相信玩过老版本《CS》的玩家应该知道，房主可以自己调整AI的武器和地图，而他们开发的那个模组其实就是一个叫做Terror-Strike的模组，主要玩法就是将所有AI设立在敌方，并且只有刀作为武器，而自己则和朋友一起在AI的追杀下生存下去。

刚好那时团队一起看了一部叫《惊变28天》的丧尸片，这让他们产生了非常多的想法，最终决定制作一款PVE的丧尸 游戏 ，这就让他们抛下了所有的《CS》和《半条命》项目，全心投入到这一款 游戏 中，《求生之路》的雏形也诞生了。

Turtle Rock Studio因为本在V社就有一定经验，所以他们很容易就可以向G胖呈现他们的新作品，虽然在会议中展现的《求生之路》比较简陋，画质也不够漂亮，但还是取得了V社的赏识，甚至G胖还决定要将这款 游戏 直接上市，当然这个决定也让Turtle Rock Studio的员工感到惊讶，并且要求V社资助他们，让他们有足够的时间将 游戏 做得更完整才上市，于是在V社的帮助下这一做就是三年。

经过了三年的开发，《求生之路》在2008年正式上市，但在发行前V社决定帮助Turtle Rock Studio扩大市场，让《求生之路》登陆在Xbox平台。由于《求生之路》的成品相当出色，从而得到了G胖的称赞，并且决定与其长期合作将其纳入麾下。

虽然《求生之路》的销量没办法和其他3A大作去做比较，但他们还是被列入了史上最好玩的合作 游戏 之一，并在隔年推出了《求生之路2》，将整个IP的知名度打响全球。

可好景不长，由于G胖想要打造一个3A工作室，可是Turtle Rock Studio的员工比较少，于是决定让自己部门的员工加入进行工作，结果双方出现缺乏沟通的问题，这让Turtle Rock Studio的员工非常不满，因为V社员工开发速度缓慢导致工作节奏不同。Turtle Rock Studio也将这件事告诉了G胖，G胖则提议解散工作室，但前提是《求生之路》的IP将属于V社，Turtle Rock Studio也同意了这个提议，就这样Turtle Rock Studio与V社分道扬镳，再次以独立 游戏 工作室出现在玩家们的眼中。

可是Turtle Rock Studio最初的创始人Michael因为习惯了在V社的生活，所以拒绝了再次运营Turtle Rock Studio选择继续在V社工作。虽然Turtle Rock Studio在重启的初期非常艰难，但庆幸V社在将他们拆解之后并没有和他们决裂，还是给了他们两年的合作合约让他们可以维持生计。他们帮助V社开发了《求生之路2》的DLC，还有《CS：GO》的早期开发。

在开发结束后，Turtle Rock Studio认为他们已经花了两年时间来赚钱，是时候开启新的征程了，所以他们在合约结束之后停止与V社合作，选择开发新的 游戏 ，这就是接下来要说的《恶灵进化》（Evolve）。

早在《求生之路》开发之前，Turtle Rock Studio就想要制作一款非对称竞技 游戏 ，有点类似于2008年的《坎贝拉猎人》或者《黎明杀机》，可以和朋友一起合作外出打猎，但他们想要将打动物变成打怪兽，因为这样才能将敌人呈现出非常强大的模样，借此让玩家们感到刺激，像是史泰龙的《铁血战士》这部电影，以一敌多天线出掠夺者的强大，就这样他们以这个方向去开发，他们将这个项目交给V社过目，希望可以资助他们并帮他们开发 游戏 ，但那时候的V社却沉迷Steam平台的开发，没有兴趣投资其他 游戏 。

所以Turtle Rock Studio在迫不得已下不断寻找投资商，很多投资商认为他们的工作室太小野心却太大，认为他们没办法做出3A作品，纷纷婉拒了Turtle Rock Studio。但THQ发行商的两位主席在看了他们的作品后意外的非常喜欢，表示愿意帮助他们制作这款 游戏 ，并在合作期间为他们提供建议解决问题，至少让 游戏 可以顺利开发。

可命运就是这样难以揣测，发行商THQ迎来了破产的情况，无法再资助 游戏 的开发，唯一的办法就是拍卖 游戏 来弥补，这对Turtle Rock Studio也是巨大的打击，因为如果没有人去喊价的话，那他们的 游戏 会因为资金不足而停止，甚至胎死腹中。于是员工们自掏腰包希望各大开发商可以看到，最终Take two以1100万的报价获得了《恶灵进化》这款 游戏 ，Take Two也成为了Turtle Rock Studio的救命恩人。

有了旗下2K团队的的帮助， 游戏 的工作进度大大提升，在2014年的E3展上，《恶灵进化》获得了多个奖项，成为了当年最让玩家期待的次世代 游戏 ，虽然之后 游戏 跳票，但这并没有打消玩家们的期望，反而让他们更期待 游戏 的完全体。

游戏 在推出不久后，销量就达到了250万，成为了公司最畅销的 游戏 之一。可 游戏 存在大量的氪金系统，怪兽与人类的不平衡，还有地图过大导致人类和怪兽开启你追我跑的模式，这些问题在发售之后逐渐爆发，导致《恶灵进化》被玩家们点爆了差评，在一年之后甚至还变成了免费 游戏 ，最终在2018年2K选择关闭服务器，《恶灵进化》也宣告终结。

在这次重创之后，Turtle Rock Studio销声匿迹，变成了一个四处流浪的工作室。2016年曾宣布会制作一款全新IP，并且由中国发行商发行，但之后这个项目也取消了，他们还去帮助其他工作室开发了一些VR 游戏 ，可是都没有什么好成绩。在那段时间Turtle Rock Studio几乎没有任何消息，直到去年12月才终于回到玩家们的视线。

由Turtle Rock Studio制作，华纳兄弟互动 娱乐 发行的《喋血复仇》，以《求生之路》的精神续作强势登场，这让玩家们都非常期待他们是不是又要再一次掀起当年《求生之路》的热潮？虽然整体 游戏 都有着《求生之路》的影子，但全新的卡片机制也成为了《喋血复仇》特色。这款 游戏 即将在10月正式发售，玩家们你们准备好了吗？

其实Turtle Rock Studio是一个非常厉害的独立工作室，他们在 游戏 行业中达到了非常多的成就，更可以说他们曾经为玩家们打开了一个美好的打丧尸时代。《求生之路》的成功是绝对毋容置疑的，但他们和V社分开后，事业就没有以往那样顺利，难道遇到知音THQ，对方却因为面临破产而散伙，找到了资金充足的Take Two，却被贪婪的2K吞噬了整个IP。希望这次的《喋血复仇》可以再一次让玩家认识到Turtle Rock Studio的能力，虽然现阶段的Bug真的很多，但也希望他们可以利用剩余的时间来优化，为玩家提供更好的 游戏 体验。

云原生时代JAVA语言的求生之路

作者：酷家乐团队 （国际化业务线-橙子）

Introduction

云原生(Cloud Native)相信大家已经不再陌生，它已经被媒体和社区认为是 web 技术体系进化的大趋势。而 Java，已经是一门年龄超过20岁，被广泛使用在个人电脑、移动设备上，覆盖互联网、教育、政府、军工等行业的强大语言。

巨大的生态和年龄的积累带来了沉重的包袱，使得 Java 语言面对云原生的趋势，转型缓慢，应对乏力，被一些专家质疑，可参考这篇文章。

我们观察到，自从 Oracle 收购 Sun Microsystems，掌握了 Java 相关的主要产权之后，管理风格偏向保守。2017年，在 JAVA 社区强大的政治压力之下(主要诉求是解决 Oracle 在 JavaEE 上进展太慢的问题)，Oracle 终于将 Java EE 捐献给了 Eclipse Foundation，最终，新的 Java EE 在更名为 Jakarta EE 后，转由 Java 社区而不是Oracle公司来主导维护(详情参考:这篇文章 )。而现在，整个转交过程尚未全部完成，预计2019年9月份，第一版 Jakarta EE 会正式发布。

另一方面，Spring Framework 和 Spring-boot 框架背后的主要贡献者 Pivotal 公司, 近期股价也承受了压力，它的CEO声称原因在于客户成单率低于预期以及新技术落地困难带来的成交周期变长。这部分反映了 Pivotal 在应对以 Kubernetes 为核心的云原生体系的激烈竞争中没有交出足够好的结果。

本文是一篇综述型文章，笔者将通过归纳梳理多篇技术博客和文献，帮助读者解答两个问题：1. Java 语言在云原生时代到底遇到哪些问题？2.面对这些问题，Java 语言和社区做出了哪些努力，形成了哪些解决方案？

Java语言在云原生转型中的问题

在这篇文章中，原作者直接指出了 Spring 框架下 Java 微服务在云原生世界中的原罪，原文引述如下:

"As companies migrate to microservices, they take their Spring Java services, bundle them into a fat jars, add the JDK and run it in a Linux based container. This solution works but you have to manage heavy weight containers that are 500MB in size and take 10 to 30 seconds to be available; and this is a problem. Many companies after migrating, they slowly move to Python or Java for their backend services; and eventually, to FaaS. Serverless and FaaS are now very popular because allow us to focus on writing functions without worrying about the infrastructure. They still run inside containers but the cloud provider manage its life cycle. The neat thing is that after certain time, the cloud provider will kill completely the container and start it again on the next call, so you only pay for the usage. The first call to a function may take a bit longer, this is the famous cold start. This is happens because the container needs to boot up. With Python or JavaScript this is not a huge problem, but for Java this could be 10–15 seconds which is a deal breaker and the cause of the decline in Java. Now we need code that can run, do its job and then stop. We don’t want multiple threads or long running processes, we want short lived processes that can boot very quickly."

总结起来，是如下这三个方面，影响了 Java 在 Kubernetes, serverless 等技术体系下的应用效果:

1. JVM+OS 需要的硬盘空间较大，最终镜像文件较大，使得镜像拉取和容器创建效率降低，进而使整个容器生命周期拉长(简称为镜像大小问题);

2. JVM 的机制使得它在运行时所需要的内存较大，相较于 JavaScript, Python, Go 等语言，这使得容器运行时资源消耗变大，资源利用率降低(简称为资源利用率问题)；

3. Spring这类重型注入框架带来了较长的启动时间，往往有几十秒，这使得冷启动时间变得不可接受，容器生命周期拉长(简称为冷启动时间问题)。

这些现实问题在云原生时代是如此突出和棘手，以至于 JCP 主席 Heather Van Cura 在一篇名为《让JAVA在云和敏捷时代不掉队》的采访中，说一些 Java 上功能和流程需要更新，以使"Java 能够吸引更多可能保有'Java 是老一辈开发者的语言'成见的年轻开发者"。

Java生态如何应对这些问题

根据 TIOBE指数，Java 指数虽然在长期衰退中，但该语言仍然是最广泛使用的编程语言，这代表 Java 背后有无数的开发者和强大的社区生态。面对问题，Java 的开发者和社区没有退缩，他们在各自的领域给出了很多优秀的解决方案，进展如下:

一、镜像大小问题

云原生世界中，Alpine 已经是容器操作系统的事实标准，整个镜像只有 5MB 左右。优化主要聚焦在 JRE 大小的优化上，这方面实际上业界已有较好解法。

• 通过JDK9的模块化功能，减小镜像总体积

• 使用Alpine-Portola项目，得到最小的java运行环境镜像(最小可达40MB左右)

二、资源利用率问题

JVM 以及在 JVM 上跑的应用程序所消耗的内存较大，是造成资源利用率低的最主要原因。

• Project Panama 一个聚焦于增强 JVM 与其他语言特别是 C 语言交互的项目，通过本项目，JVM 可以获取 Native data，以得到更好的内存使用。现状: 草稿状态，未实装。

• Project Valhalla 给 Java 引入 Value Types，以换取不可变数据类型的高性能和低开销。现状: 草稿，预计 JDK14 实装。

• 多项 String 和 G1 垃圾收集器相关优化，最终带来内存减小和性能提升，参考这篇评测。

• Class-Data-Sharing 在 JDK10 中引入，可以减小内存占用和启动时间。

三、冷启动时间问题

面对容器化转型，代码开发的交付物从应用程序变成了镜像，这带来了一个巨大转变: 我们已经不再需要一份代码"write once, run everywhere", 因为我们的 runtime 可以固定在镜像里，放弃兼容性。很多解决方案就是以此为突破点，牺牲平台兼容性换取性能。

• Graalvm Java世界最近的明星项目，该 vm 支持多个编程语言的运行时，并可以使Java代码编译为机器码，实际上这就是 AOT 编译相对 JIT 编译带来的性能优势。该项目目前活跃度和关注度都很高。

• Micronaut.io 一个基于  Graalvm 的轻量级微服务框架，相对于 Spring-boot，大大减少了启动时间和运行时内存消耗，这篇文章声称，以此框架撰写的 Java 服务，启动时间为20毫秒，内存开销为18M。该项目目前每月有更新。

• Helidon.io Oracle 开发的一个轻量级微服务框架，以 Netty 为核心，可以直接对接成熟的云原生组件如 Prometheus，Zipkin/Jeager, Kubernetes 等，特色是启动时间快，目前项目每月更新。

• Jakarta.ee 由 Eclipse 基金会维护的，面向云原生的新版 Java EE，预计于今年九月份发布第一版。根据这份文档，在新版 JakartaEE 标准的指引下所有 EE4J 项目将全面拥抱云原生。

• Quarkus.io 轻量级微服务框架，可以运行在 Graalvm上，通过 AOT 编译获得启动时间优化。参考这篇博客。该项目目前尚未发布1.0正式版。

• Spring-Cloud-Functions Spring自己也没闲着，这个基于 Java Functions 和 Flux的组件可以让 Java 开发者通过 Bean 的形式直接写出一个函数，而不需要启动一个Spring-boot。项目不太活跃。

• Dagger 一个原来服务于安卓的静态注入框架，通过编译前就静态注入代码，而不是运行时动态注入，来加快启动速度。目前被越来越多java服务端开发者关注。项目非常活跃。

结论

“周虽旧邦，其命维新”，通过综述十几个项目的目标和现状，我们看到整个 Java 社区在云原生转型中付出的努力。在镜像文件大小问题上，业界已经有了成熟和有效的方案；在资源利用率问题上，Java 社区一直在通过各种不同的途径来优化；在冷启动时间问题上，我们看到了很多新的解决方案，但并未有响亮的业界实践反馈，且大部分方案牺牲了 Java 的跨平台性，这都有待未来几年市场的检验。

笔者相信，只要 Oracle 在未来的几年中不破坏和干预 Java 生态，Java 语言必将克服在云原生应用中遇到的诸多问题，焕发出新的生命力。

参考文献

此处仅列出未在原文中直接链接的相关文献

• https://itnext.io/introduction-to-quarkus-cloud-native-java-apps-e205ae702762

• http://openjdk.java.net/jeps/0

• https://pivotal.io/cloud-native

• https://hub.packtpub.com/jakarta-ee-past-present-and-future/

• https://www.theserverside.com/feature/Brian-Goetz-Reveals-Valhalla-for-Java-Ten-and-Beyond-at-JavaOne-2015

• https://codeburst.io/microservices-in-java-never-a7f3a2540dbb

• https://github.com/square/dagger/issues/366

• https://dzone.com/articles/java-memory-management