自己有兴趣吗？有兴趣就有，没兴趣就没有。

@taowen 说的很好。但是我觉得大多数人的问题在于缺乏一个愿意为此而活的事情。我觉得可能人受到基因和早期教育影响很大，于是少数人天生就很 high，很有奔头。这种 high 其他人是学不到的，其他人尝试模仿，最后就是精疲力尽。

@e583409 我觉得这更像一种个人的属性，其他人很难“学习”到。好比说我也挺喜欢折腾的，但是一直没坚持下来。

@QBugHunter 至少 XOR 点奇怪的东西一下吧

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

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

@namelosw 说得好~~

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

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

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

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

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

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

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

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

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

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

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

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

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

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

不是代码，但是既然是游戏公司，那么可以考虑

You are standing in an open field west of a white house, with a boarded front door.

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

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

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

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

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

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

话说如果写 C++严格按照一个子集来写，会不会也很好？之前在知乎看到一个帖子，说是大家讨论 C++里面哪些特性应该小心使用，不知道大家怎么看这个？

> 能做到对 C++语言的特性基本分类，然后根据分类正确使用它们我对 C++特性的四大分类为了兼容 C 语言，不得不继承下来的特性，比如#include，强制类型转换，直接内存操作，基础类型和函数系统，宏为了零开销实现 OOP 而设计的特性，比如 class 继承和派生，虚函数，函数重载为了开发效率而设计的特性，比如 template 以及一些列 stl，算符重载，auto 为了解决实际问题不得不向现实妥协而设计的特性，比如 explicit，mutable，xxxxx_cast，register，volatile，inline，asm，template 特化，friend 第一种特性在真正需要和 C 语言打交道是要小心使用，第二种特性才是主要使用的，第三种特性只在遇到开发效率问题时使用，第四种特性要尽量避免使用，尽量不要制造需要这些特性才能解决的问题

作者：姚冬
链接： https://www.zhihu.com/question/444555079/answer/1754123101

@SHSF 比如说需要定制化 alert 系统，Tableau 就做不到，所以我们用 Python 做（不过这个没用到 Dash，是直接 post 到 Teams 里面）。还有就是 Tableau 自动化程度不如 Python，不过也可能是我们对 Tableau 应用的不够深入。举个例子，很多时候每个项目都有共同的 KPI，如果用 Python，我甚至可以把每个项目的数据库表格名称都标准化，这样 Python 后台切换不同项目就是几行代码。我可以直接在 Dash 里用一段前台代码展示所有项目的 KPI 图标。如果用 Tableau 的话，至今没找到一键切换数据来源的办法。

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

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

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

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

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

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

@SHSF 看了下还真是。不过我们公司用 Tableau，只有我们组用 dash 做点复杂的东西。主要是 Python 比较灵活。