从 DOOM 启示录和戴森球游戏工作组中得到的启示

[levelworm]

我在公司做业务分析，最头疼的就是在不同的组之间沟通。任何一个项目我都至少需要开三个会：第一个会是和游戏设计师和市场部门讨论 KPI 和监测指标；第二个会是和本组成员头脑风暴，确保没有漏下比较重要的东西；第三个会是在写下需求文档之后，和研发以及数据库组进行沟通，敲定所需要的 telemetry 和数据库表的结构。换句话说，我同时做需求分析和数据建模（之后还要做 ETL ）。也正是这些工作让我觉得自身在研发这块比较欠缺，所以目前在学校进修计算机科学的课程。

但是这三个会议仅仅代表我工作的一小部分。大部分时间其实都花在和研发的沟通上。鉴于我自己对编程知识并不了解，所以我的 telemetry 需求文档其实和研发的程序架构往往离得很远。比如说我们的游戏采用微服务结构，在我对我们是如何实现微服务完全不了解的时候，我其实是把它当作 Monolith 来看的。也就是说我的 telemetry 需要研发从很多个微服务中调取数据。然而研发采用微服务正是为了让各个部分之间相对独立，所以在一开始这对我造成了很大的困扰。等到现在稍微对研发的架构有所了解，我就逐渐注意到相关问题了。比如说我看研发对于某项目的文档，就能大致琢磨出来大概需要哪几个微服务之间互相调取数据，于是我可以在尽量符合架构的条件下提 telemetry 的需求。但是总体来说，和研发的沟通大致占我工作时间的八成——这里头还有一些其它的原因，比如说我们这边有时候考虑的不周到，会临时加需求，或者研发那边完全没有文档，于是我得找人一个个问下来。这些都太占时间了。

我因此感觉到，项目管理的确是个比较困难的事情。因为项目管理本质上就是在不同的组之间进行沟通，而沟通就必然带来信息的损耗。很多时候这种损耗是不可逆和很难察觉的。双方可能都觉得这次沟通非常完美，但是最后的结果却不尽然。我理想中的项目管理者，应该是个出身研发（因为最后需要研发落地，所以这块必须熟悉），但是对业务非常熟悉，又擅长向上管理的人。缺少任何一点都会有重大问题。如果出身不是研发，那么基本上没发和研发有效沟通，鸡同鸭讲；如果对业务不熟悉，那么做出来的东西业务根本看不上；如果不擅长向上管理，就很难在效率和质量之间做平衡。

说来说去回到标题。我读 DOOM 启示录的时候，对 ID Software 早中期这段经历（大致上是从尚未成立 ID Software 、还在原公司做大蓝碟，到 1997 年 Romero 离开这 7 年）尤其感兴趣。如果说我工作的感受是在泥泞中爬行，那么 ID Software 的这段经历给我的感受就是行云流水一般的顺畅。不断地有新作品、新技术涌现出来，每个人都尽情投入到工作之中，并且不断地给自己找事。我们当然可以说，这是因为他们是在给自己打工——但是我认为这并不能解释所有的事情——比如说你就无法解释为何在做蓝碟的那一年他们依然效率很高，创出了一年十几个游戏的纪录。你能感受到，这是一个特别有激情、特别有战斗力的一个小组。

时间转到前几天。V2 上正好有个关于戴森球的帖子。把戴森球小组和 ID Software 中早期一对比，就发现这两个小组之间的相似度很高：第一，双方人数都很少，但是经验都很丰富；第二，小组中所有人的兴趣高度一致；第三，小组做的是他们感兴趣的游戏。这就导致游戏开发上两者也有很多相似的地方。比方说两者在项目管理上都没有什么损耗——我甚至想说，其实那不是项目管理，而是大家把蓝图科学的勾画出来而已。这对个体的要求很高。如果每个开发人员没有相当的开发经验的话，就非常容易制定太高的目标，甚至随机行走，想到什么做什么。如果大家只是为了钱做游戏，那么也不可能有这么顺畅的沟通——你让一个经验丰富但是对科幻经营类游戏毫无兴趣的程序员去写代码，那他很可能就是仅仅根据需求给你 1 、2 、3 、4 、5 做出来就是了，不是说不好，但是想要做爆款我觉得可能性不高，更别说需求沟通也会带来困难，很多游戏术语都需要被再翻译。

说了半天，其实也都是大家知道的事情，只是有所感触罢了。能够看到有才能的人尽情挥洒才能，我们都应该为他们感到高兴。至于我自己，我想我得到的启示就是，我还得慢慢学编程，争取做到研发、数据、业务三栖。不敢说精通任何一块，但是至少能够在现有和将来的工作岗位上发挥更大的作用。成熟游戏公司和 Indie 开发组的玩法的确是不一样的。

[happinessnch]

你想要造一艘船，你不需要去指挥他人去购买工具，也不需要给人安排任务，你只需要激发他们对大海的渴望。

这是一种很理想，且可遇不可求的状态，一般情况下都不建议这么做。

[EvanG]

没得比啊 ID_Soft 初期团队里哪一个不是大神，卡马克这种级别的人才你能招到么。。。

[skyworker]

大部分上班只是为了一份薪水而已, 对业务或者编程本身可能不感兴趣, 只对薪资和是否 996 感兴趣

[sillydaddy]

> “第三个会是在写下需求文档之后，和研发以及数据库组进行沟通，敲定所需要的 telemetry 和数据库表的结构”
很好奇为什么需要你做这件事。做项目管理的为何要关心数据库表的结构呢？这就是导致你“大部分时间其实都花在和研发的沟通上”的缘由吧。需求表达清楚了，自然由研发来设计相应的框架，难道还要根据研发使用的框架来修改需求吗？即使需要这样，也应该与一个研发的代表来讨论沟通啊。

[levelworm]

@happinessnch 的确，感觉都是可望不可求。这两家公司的模式都是志同道合者联盟。

[levelworm]

@EvanG 卡马克成就 ID, ID 我觉得也成就卡马克。当然这种大神的确罕有。

[levelworm]

@sillydaddy 你说的很好。因为数据组不做，所以只有我做。不过我之后就去数据组了，所以也算是数据组做了，大家也都觉得还是数据组做而不是分析师做比较符合常理。严格来说我也不是做项目管理，而是做业务分析。项目经理仅仅负责协调大家开会，所以具体的组之间的沟通是我来做。最早的时候，其实也没有我这么做的，但是那时候就特别混乱，我觉得得做点改变所以就揽下来了。

不过这个并不是占时很多的（全部）原因。我进行沟通时间最多的还是研发，而不是数据组。就我个人的体会来说，有几个原因，一个是需求会有变动，这个是我们这边的问题；一个是研发那边赶进度，所以没办法同时照顾游戏设计的需求，和数据分析的需求，所以很多时候出来的 telemetry 和我的需求是完全两样。我需要不断地盯着每个研发，否则到最后就完全走样了。但是我觉得这也有我的问题，因为我不了解研发的架构，所以我提的需求可能本身也不靠谱；一个就是你说的，研发那边没有对等的人，所以我必须和所有研发进行沟通。

我其实一直觉得，研发所需要的需求文档，不应该由分析师来做，应该是研发自己那边有类似职位的人来做。因为作为分析师，我不可能了解程序的架构，怎么能指望我写出来的文档研发可以照套呢？

这是我准备在今年解决的一系列问题。我去计算机系进修也是因为此。如果今年内解决不了，我就觉得我的工作没有什么很大价值了，就准备专心做数据这块（这块其实才是我真正的兴趣所在，我其实也不喜欢到处找人沟通），甚至跳槽也有可能。

[sillydaddy]

@levelworm #7 >

不懂游戏这块，你说的数据建模，是针对的游戏本身的数值平衡，还是针对的游戏玩家数据呢？
做业务分析的话，懂一些程序肯定能有所帮助。不过我觉得，大部分时候，知道大概就足够了吧。比如我的业务需要保存这块、这块和这块的数据，在需要的时候能把这些数据调出来以供分析。至于研发用什么框架用什么数据库，我不需要关心啊。难道研发能说，你这个需求不合理，这 3 种数据不能一起拿，会影响效率？？也就是说，提靠谱的需求，需要了解研发的架构吗？？
你说的这些给我的感觉是，你因为感觉无法亲手控制研发的工作，又感觉没办法给研发解释清楚自己所理解的东西，以至于他们没办法充分配合，当然也可能因为研发本身就没有什么积极性，所以，你想要自己去学习一下程序世界里的概念，然后用这些概念去和开发人员沟通。

[sillydaddy]

@levelworm #7 >
问题是，你这是在迁就研发啊，效率的瓶颈不在你这里。研发为什么不能理解你说的需求呢？是他们不上心，还是说你没有解释的很清晰？ 我觉得不论是哪个，解决的的根本之道都不在于你是否去进修计算机。

可能问题还在于项目的流程吧。你自己也提到过之前的项目流程比较乱。有没有了解过“敏捷开发”这种项目流程，它跟你理想中的项目小组挺像——每个成员都充分参与项目的讨论，充分理解需求，充分沟通。你一直在说的“需求文档”，在这种项目流程里面，根本没有那么重要。贴一下敏捷宣言：

“个体和互动 高于 流程和工具
工作的软件 高于 详尽的文档
客户合作 高于 合同谈判
响应变化 高于 遵循计划

也就是说，尽管右项有其价值，
我们更重视左项的价值。”

[levelworm]

@sillydaddy 数据建模我指的是数据库里头的 data modelling，不是数据平衡。比如说 telemetry 从 Kafka 进来，需要丢到 Vertica 里，这个表应该是什么样的？ telemetry 里哪些部分需要进什么表，表和表之间关系是什么的，等等。

你的感觉十分正确啊，我觉得我说的不是很清楚，但是你理解的很对。另外研发的确是可以拒绝需求的（我觉得这也很正常）。所以就像你说的，我觉得我得至少了解研发的工作，才能给他们提需求。

我举个例子，比如说某个游戏里头的某一场战斗总共有创建、开始、作战、奖励 4 个设计师设计好的阶段，对于分析师来说，我不需要细节，我只要汇总，所以我最早提的需求完全是根据分析师的需求来的，表的每个字段都是汇总，比如说战斗中总共杀死了多少敌人，总共获取了多少金币，等等。但是后来去看研发自己的文档，发现不对，他们做不了这个，他们只能按照游戏设计师的 4 个阶段来输出数据，于是我就改成 4 个 telemetry 。后来又发现有些数据服务器端拿不到，只有客户端才有，或者是有些数据某些微服务才能输出但是这个战斗的程序不需要这个微服务，所以就没有相关数据。所以最后我还得把需求拆成几个需求，分别给不同的程序员，又放弃了几个特别困难的，最后才算是凑齐了大部分的需求。

[levelworm]

@sillydaddy 我们其实就是这么做的。每个大项目都有个 task force，每个成员参与讨论，我的这几个会议也是讨论的一部分。至于为什么不是那么有效，除了我说的那些，我也不知道还缺点什么了。

我有一点不理解，如果没有完整的文档的话，程序员怎么知道该怎么写输出 telemetry 的代码呢？数据组怎么知道数据库的表是什么样子的呢？难道这些不都是事先要说好的吗？

如果我完全按照分析师的要求说给研发听的话，我觉得就是鸡同鸭讲了，因为我们只会说，“我们想做什么分析”，问题是程序员如何把问题变成我们需要的数据？他们不做分析啊，所以最后还是得我和他们说，我们做分析，需要如下这么多字段，且在某个时刻输出，这时候程序员就会说，OK，这里头 ABCD 等等我们做不到，因为框架不支持，然后我再进行修改，等等。

[sillydaddy]

@levelworm #11
嗯，数据相关的文档肯定是不能省的。我上面指的需求文档主要是程序逻辑相关的，比如业务逻辑。

至于你说的程序不支持相关的数据，按照我的理解，没有什么不支持的数据吧：
>表的每个字段都是汇总
为什么开发人员不能提供汇总后的数据，而需要你去拆分数据？
>有些数据服务器端拿不到，只有客户端才有
既然数据分析需要这些数据，为什么拿不到？如果要拿到，需要哪些工作？
>有些数据某些微服务才能输出但是这个战斗的程序不需要这个微服务，所以就没有相关数据
数据分析需要这些数据，这个问题不能够被技术解决吗？
>最后我还得把需求拆成几个需求，分别给不同的程序员，又放弃了几个特别困难的，最后才算是凑齐了大部分的需求
感觉你太委屈了。
作为一个开发，虽然我不懂具体你说的这些技术，但我能相当肯定，这些数据来源的问题是可以用技术解决的。可能你跟具体的开发人员中间，少了一个沟通的渠道，比如对接的人，或者说是一个对接的机制(比如敏捷会议)，以至于额外的工作都被你负担了。但你不懂开发啊，这些技术细节交给你处理就不合理。

另外，友情提醒一下啊：
> 比如说 telemetry 从 Kafka 进来，需要丢到 Vertica 里，这个表应该是什么样的？ telemetry 里哪些部分需要进什么表，表和表之间关系是什么
从这句话，可以发现你的表达方式是可以改进的。因为这里面的几个名词，甚至对于一般开发人员来说，都是无法理解的，如果把它们换成可以被理解的概念，是不是好一些？ 这就引申出一点： 如果你与你们公司的开发沟通，能不能采用一种大家都可以理解的中间语言，来避免“鸡同鸭讲”的现象？你也就不用去学习那么多开发的东西了。

[yxysnao]

其实就是菜，有卡马克的公司 管它是 id 还是 oculus，有可能不成功吗，卡马克也不是科班，卡马克也爱玩游戏，卡马克在商场上和市场营销上还很不成熟，卡马克还很不会沟通，一言不合就开人。但他是卡马克，这就足够了，仅凭一人的技术力洗牌游戏市场的人

[levelworm]

@sillydaddy 多谢多谢，多谢理解。不过目前的确没什么很好的办法了，可能还是得就这样下去。不过我觉得我可以想办法找个接头的人，虽然不乐观，毕竟这活又烦又没实际功效。

另外关于表达方式，这句话的确是不好的，也不够精确。我和研发表达就是直接一个个列出来，他们也说这样最好（省心嘛）。不过你说的也对，如果我能把需求用这么一种中间语言描述一下，而不是用试图模仿程序员代码的形式描述出来，可能更好。问题就是怎么用。。。毕竟英文是我的外语，呆了这么久还是不够利索呀～

[levelworm]

@yxysnao 对。。。ID 明确技术优先的确是走对了，卡马克的确牛，不服不行。无论是头脑还是效率都是一顶一的。就像你说的他也没怎么上过大学。

[Justin13]

你说的三个点，核心就一点，良好的沟通能力
至于技术，产品，向上管理，其实都是领域知识，能锦上添花，无法雪中送炭。沟通能力不行，技术，产品等再熟悉也没用
再一个，领域知识绝非沟通的必要条件，良好的倾听理解能力才是，因为作为各方交汇的岗位，理解偏差是最要命的
如果觉得不了解领域知识就沟通不了，那说明双方都应该学习增强沟通能力，而非去了解领域知识。

[BeautifulSoap]

@Justin13 最近学领域驱动设计，有点自己拙见

你说的沟通能力，不同团队不同人的沟通能力都不一样，领域驱动开发里就是为了减少不同人团队之间的沟通障碍，才不厌其烦地(甚至到了啰嗦的地步)强调开发中必须坚持使用领域模型和通用语言进行交流(UBIQUITOUS LANGUAGE)

因为领域模型和通用语言是领域专家和开发人员共同制定的，本身就自带了领域知识，并且坚持使用它们能大幅减少不同团队和人之间的沟通成本，减少误解


戴森球团队之所以开发如此顺畅，我觉得一个解释是因为他们大部分人都经验非常丰富，甚至可能团队中很多人都算是领域专家。他们都了解这个领域也了解程序开发，领域知识无需过度沟通。自己即是设计者又是开发者（虽然各有分工），因此团队内就很轻松地能统一领域模型和通用语言，从而提高开发效率

[Justin13]

@BeautifulSoap
拥有相同的故事上下文和背景知识可以大幅度降低沟通的门槛
在同一个团队里面可以搞，也很有意义，因为大家做的事件是同样的，比如开发内部沟通。
但是对于管理，这不现实，再怎么学习领域知识，
也不可能接近开发的程度，更何况还有可能出现领悟知识的偏差，在对方看来，这变成外行指挥内行的。
至于不同团队间努力构建相同的故事上下文，这当然有用，但是显然难度远大于增强自己的沟通能力

[zj9495]

"你让一个经验丰富但是对科幻经营类游戏毫无兴趣的程序员去写代码，那他很可能就是仅仅根据需求给你 1 、2 、3 、4 、5 做出来就是了，不是说不好，但是想要做爆款我觉得可能性不高"
工作中遇到过很多产品经理，自己对需求都不够了解，还不清楚到底想要什么，就想让研发奇迹般掏出一个让领导客户都满意的核弹级产品，想一想这也不可能

[yxysnao]

还有些写的没续上。所以这本书会受美国推崇，卡马克本人的所体现出的个人英雄主义，比虚构的都还要夸张，就像没人能写好盖茨或巴菲特的故事，能力太强的人成功得很是枯燥乏味，卡马特至少还有个升级的过程。不是卡马克选择了技术优先，是 ID 的发展不得不让步于卡马克的技术，你罗梅罗能力爆表设计的游戏一顶一的爆款，那 ID 也许就成为第二个任天堂了，但这种事情没发生吧 。另外说一句任天堂的技术力可一点都不拉跨，看跟谁比。那本书要效果写了一波人，实际上那拨人在现实中也就打了个酱油，出了 ID 也没掀起任何风雨，所以看懂这本书的小扎深谙此道，合伙人不合格立马出局，公司成就了你，分一杯羹很客气了。

[v2orz]

从另一个角度来说，席德梅尔的系列呢？仿佛是另一种思路和方法

[nicebird]

@yxysnao 很多人后面还是很牛逼的，比如 EPIC 老板 Tim Sweeney 。

[levelworm]

@nicebird 他的意思是从 ID 出去的那些人。

[namelosw]

我看过 DOOM 启示录, 还看过一些 Carmack 的 talk, 最近也在关注戴森球, 同时最近还玩了 Valheim 也是五个人做的. 最近也偶尔会想这个问题.

---

软件开发相关:

我觉得你想说的这个很好概括: 就是《人月神话》倒过来.

Brooks 的《人月神话》里面说了效率会随人数快速递减. Paul Graham 后来在回忆他用 LISP 创业的文章里面写到, 《人月神话》反过来也是成立的 — 人越少效率越高, 3 个工程师打 100 个并不是什么稀奇的事情.

至少一个精英 Ruby 程序员吊打几十个官僚型企业的 Java 程序员在职业生涯中并不鲜见, 特别是自己做自己用产品的那种, 需求都在自己脑子里, 随着思路就打出来了.

---

游戏相关:

我理解游戏产业这些年的趋势就是大公司逐渐瓦解, 独立工作室以后会蓬勃发展. 一方面大公司导致他们不敢做出改变, 每年只能保守挨打, Bioware 龙腾世纪 1 之后就再也做不出像样的游戏, CDPR 的 Cyberpunk 搞这么多年也没能达到想要的完成度, 暴雪如今除了炒冷饭什么也做不出来. 另外一方面独立工作室虽然死死生生, 但是没人知晓就有放手一搏的成本, 总能看到戴森球和 Valheim 这种新星.


---

戴森球相关:

感觉这个 team 还是挺厉害的, 这个游戏的优化做得很好. 而且看采访说开发过程中基本都是按预想顺利进行的, 感觉在软件项目里较罕见, 很多有点技术挑战的游戏项目都喜欢中间推倒一部分, 或者发现跟预想的不一样.

---

ID 相关:

很多 70 年代创业都跟摇滚明星一样, Steve Jobs 也类似, 都是小破屋里面几个叛逆小孩搞出来的. 现在的环境其实不太一样, bar 太高了, 发挥想象力之前先要念书赶上别人的起跑线. 资本也没有那时候宽容, 因为大家都等着用电脑和玩游戏.

听 Carmack 聊天很有收获, 干货特别多, 也不像其他架构师讲一堆云里雾里的, 很直接就进入技术环节. 不太在意别人的感受, 比较直, 就事论事. 跟我们经常能碰到的那种动不动就给自己和别人戴“工程师思维”帽子的那群高不成低不就的人不一样.

Carmack 其实后来不那么关心游戏, 他更关心技术, 总得来说他更像做引擎的. 至于游戏本身没有什么特别的内容, 就是打枪. 前 ID 员工做出 Deus Ex 不知道比 ID 的游戏高到哪去了.

---

随机感慨:

好像盖茨这种家庭优越的, 和 Carmack 这种家庭破碎的都有很多成功人士. 一个是总有退路可以放手做, 另外一个是没有什么可以失去, 总是放手一搏的状态. 像我们这种高不成低不就的人过日子战战兢兢的, 想到创业也是谨慎再三, 创业走的路线也都是求短求快, 没有 Carmack 他们那种大开大合的风格.

[namelosw]

@yxysnao Carmack 在 Oculus 其实跟在 ID 很不一样, 重要决策都是下面很厉害的人决定的, 很长时间他都不咋管 Oculus. 而且他自己说 FB 对他的要求也出奇地宽松.

后来干脆转成顾问角色了, 他现在在研究自己感兴趣的东西(AI 和火箭).

[levelworm]

@namelosw 说得好~~

>我觉得你想说的这个很好概括: 就是《人月神话》倒过来.

对我也想到人月神话了，有时候觉得开发生产力真的是会有天差地远的区别。有时候也不完全是 10X 程序员吊打 1X 程序员的问题，有时候就是像你说的，技术水平差别问题很大，但是一个没有沟通成本且有动力，另外十个沟通成本很大且就指望着早点回家，这个差别实在是太大了。大企业如何解决这个问题？可能没法解决。对于个人来说，得有自己想做的产品，有时候虽然有技术但是未必真的想做自己的产品，那就也会有限制了。

>我理解游戏产业这些年的趋势就是大公司逐渐瓦解, 独立工作室以后会蓬勃发展.

这个我赞同，很可能就是戴森球这种模式，大公司的人离职去组建自己的工作室。AAA 的成本太高了，错一个弄不好公司就死了，现在资本也未必愿意投 AAA 游戏了，可能还是更愿意投人。

>现在的环境其实不太一样, bar 太高了, 发挥想象力之前先要念书赶上别人的起跑线. 资本也没有那时候宽容, 因为大家都等着用电脑和玩游戏.

前几年就有说 Indie 红海，现在看起来对于 Indie 新人来说，的确是九死一生。以后可能就是业内大牛自行组建工作室的 Indie 模式了。其实现在也差不多这样，真正的 Indie 新人很难生存。所以我觉得，假如说我自己去做的话，就肯定是为了兴趣，对销量无所谓。

>Carmack 其实后来不那么关心游戏, 他更关心技术, 总得来说他更像做引擎的. 至于游戏本身没有什么特别的内容, 就是打枪. 前 ID 员工做出 Deus Ex 不知道比 ID 的游戏高到哪去了.

我觉得 ID 成就于技术优先，但是最后也是因为这个导致游戏过于单薄，好在是 FPS 大家也不讲究什么。本来 Carmack 和 Romero 是一对很好的平衡，但是分开之后的产品从设计上来看就没有什么有意思的地方了。

>像我们这种高不成低不就的人过日子战战兢兢的, 想到创业也是谨慎再三, 创业走的路线也都是求短求快, 没有 Carmack 他们那种大开大合的风格.

我觉得现在国内的生活还是有些“卷”了，很难让人放松下来做真正想做的事情。我相信和戴森球小组那几个人一样牛的人肯定不少，但是能出来自己做的就不多了。我觉得也许在业内沉浸多年，有了一定收入和水平的人是有机会的，但是怎么让自己能够放下已有的出来追求自己真正喜欢的？不是一件容易的事情。更别说很多人那个时候都说不上有什么真正特别喜欢的东西了。

[levelworm]

@namelosw #25 Carmack 其实有点十九世纪末那种绅士科学家的味道。他不是走学术路线的那种，而是靠自己的聪慧琢磨自己喜欢的东西。所以他在尚未成熟的领域（早期的三维游戏）非常厉害，看看他在 AI 会怎么样。

[namelosw]

> 大企业如何解决这个问题？可能没法解决。

可能的确没法解决, 但是现在游戏界的大公司很多都在更落后的阶段 — 太官僚导致没办法有效做游戏.

大企业最大的问题是很多都是上面拍脑袋, 有 deadline 倒算工期然后推出游戏. 这样游戏肯定只能越做越烂. 我感觉现在很多比较成功的游戏发售日期都是 when it's done. 游戏不是计划出来的, 到日子做成什么样都匆忙上线, 而是必须要匹配一开始的愿景.

最近我感觉 Larian Studio 各方面就做得很厉害, 从小工作室逐渐成长成中大型的路上, 不仅同时能伺候挑剔的老玩家, 还能吸引新用户, 各种平台策略(比如 Steam - Switch 存档同步), 数据驱动(各种游戏内统计分析, 跟搞大数据的互联网公司一样), 社交媒体运营推广(梗玩得飞起, 热点一个不落)都游刃有余. 老牌公司和工作室和这种工作室比起来简直菜得抠脚.

所以我想大游戏公司缺乏的:
1. 把游戏做好做完, 不要倒算时间. 钱不够大不了 3A 不做做 2A, 好玩是最重要的.
2. 多开发新 IP 新机制, 暴雪这种只做年货就是等死.

但是这些问题能解决嘛? 我觉得对现有公司很显然不能. 这些公司的根本问题在于老板, 股东, 资本市场, 游戏公司和游戏在这些股东眼里就是个会变钱的数字, 榨干价值收回来继续投别处.

相比之下股权结构简单的公司稍好一些, Steam, 和以前的 Zenimax 之类的, 公司是自己的, 游戏也是自己的, 用自己的钱慢慢做.

很多 Indie 成长起来的过程中处理的没有 Larian 这么好, 希望以后像 Larian 这样的工作室越来越多.

[kruskal]

@namelosw #24 大公司逐渐瓦解怕不是在做梦，现在手游公司都开始搭 3A 那套工业化流程了

[namelosw]

@kruskal 可能我们理解的不一样, 我们说的是 EA, UBI, 动视这种

[kruskal]

@namelosw #30 如果你了解游戏工业化流程的搭建逻辑，就会明白这是当前市场环境下的必然趋势，不会受个别厂商的经营状况改变。

[namelosw]

@kruskal 是个别的嘛? 现在还有几个 3A 大厂还能混的顺风顺水? 大部分都越过越难了吧.

[levelworm]

@namelosw #28
这样的话必然导致精英游戏制作者离开原公司创业，反正本来也不缺钱，失败了也不愁再找工作。基本上什么公司只要成长起来之后资本市场介入了，之后就是那副样子了。

[charlie21]

（对要做的事的理解。）<=（在钱给够了的情绪下 激发人类潜能 <= 巨大回报 即使是巨大精神回报）