在顶级游戏开发的过程中需要怎样的编程实力？

NoiseFloor · 发表于 2021-9-20 11:27

本题已加入知乎圆桌 >>游戏的奥秘 I 游戏制作者在路上，更多「游戏设计」讨论欢迎关注。
在3a大作以及顶级ip的游戏开发中。程序员的实力如何？比起顶级程序员有哪些差距？顶级程序员是否不屑于开发游戏？
---
游戏开发过程中，最需要大批水平一般的码农还是坐镇大拿？
----
在如《荒野之息》这种系统复杂的游戏中，普通程序员是否有瓶颈？
在如育碧式开放世界的游戏开发中bug频出，是否源于程序员实力不足？
在性能羸弱的掌机游戏开发中，一个优秀程序是否能创造神迹？

RedZero9 · 发表于 2021-9-20 11:35

做游戏技术主要讲究的是套路，以及对套路的掌握程度。比如说你要搞个体积光，那么从用mesh+uv动画，到volumetric scattering你都得知道，而且要知道这些方案的优缺点，以及具体的实现细节，比如camera会不会到体积光里边之类的，这种细节的了解会让你更加有信心做出各种技术决策。
所以3a级游戏的大神技术也是对各种领域的套路玩得比较溜，这里我也分享一些做游戏20来年自己领悟出的一些套路吧。
美术用工具输出的3d模型，材质一定要做一个导出插件，否则做出来和进引擎效果不一样，就只能做做手游这种无光照的手绘贴图质量的产品了。
动画要想不滑步，就只能用animation driven的方法，这个需要跟策划做好深度的沟通，得让策划知道移动不是说配置一个速度就可以了，得去找动画师一起调整移动的动画。
动态天气的困难不是制作上的困难，是可以用lightmap的物件会少很多，性能不一定扛得住，这个要在项目初期一定得和制作团队沟通清楚。
球类游戏要达到非常自然的动画，一方面动画肯定是要动捕的，另一方面更重要的是搭建一套动画选择机制，然后根据运动中的球类位置来选择最合适的动画来匹配，再加上小部分的ik。
头上冒字和冒血这种hud就应该用hud的标准方法来制作，切记不能涂省事用ui的方法，对性能效率会有非常大的影响。
音频对最终品质影响很大，一般遵循46原则，即图像资源在最终包中占6成，音频资源占4成。给音频设计师配置一个独立的程序来达成音频的设计需求。
状态机最好是用可视化的方法来实现，游戏中80%的bug都是和状态没切对有关，有个可视化的状态机对于找bug非常方便。
control是最需要状态机化设计的（不同的情况下按同样的按键达成不同的逻辑）
做面部表情，如果不是捕捉就用骨骼简单搭搭就好，如果是捕捉，制作成本会变得非常的高（制作各种morphing target）
对最终画面影响最大的是镜头效果，所以尽量节省渲染时间留给镜头特效。一般影响最大的是校色，如果硬件平台允许尽量给美术提供带深度校色的工具。
有比较宽广视野的游戏，室外可以用一些很取巧的方法来模拟mie scattering和rayleigh scattering，加上哪怕是假的对画面的提升也是巨大的。
对于不同的数据采用不同的配置方法，不要什么数据都用excel，对于有可视化需求的配置，比如ui或者角色身上需要装配一些武器的，提供可视化的工具。对于需要描述父子关系的例如技能树解锁之类的用json或者xml来描述，对于纯数字逻辑的就用csv就好了。
场景的材质如果制作normal map对于你们团队比较复杂，多加一层detail map也能对效果获得较大的提升。
角色的材质，如果性能有限或者说制作成本无法承受的话specular map比normal map的效果要好。
如果角色会近距离看脸，脸部的眼睛一定要单独拿出来处理，脸可以糊，眼睛一定不能糊。
脚步声的标准做法是在地面上放一层低模做和脚的碰撞检测（脚步声如果追求真实，最少得有3个以上的样本随机）
如果要提升动画效果，考虑主角的前臂加上twist骨骼，左肩和右肩不要从脖子上搭建骨骼，要从胸口开始（做head lookat的时候效果会更好）
衣服的标准做法是通过贴图来控制哪些顶点受skin和物理影响的权重比，那张贴图还可以用一个通道来控制流汗的时候哪些地方的smothness要提高。
搭建一个运行时数据库，并且游戏中经常需要访问的数据都放入数据库，可以类似redis那样非常简单的提供一个set和get就行了，运行时数据库可以帮助你找到绝大多数bug。
制作ai尽量使用行为树，并且花时间一定要让策划具备编辑和调式行为树的能力。
顶点色可以各种花式使用，无论是用来bake ao还是决定detail map的权重，都可以用很低廉的代价来获得非常棒的效果。
动画不是在任何时候都可以blend的，要想效果好，牢记：左脚落地的时候只能blend到左脚落地开始的动画，右脚同上。
做上下楼梯的locomotion的时候，用椭球碰撞体会非常简单的获得还不错的效果。
如果画面会经常快速的运动，可以加入一个vector based motionblur，效果会出奇的好。
要想场景生动，一定要使用decal，一个方便美术的decal工具可以让美术一天之内让整个场景提升几个档次。
暂时想到这些，不说了，休息好了继续干活。
~~~~~继续更新一波套路
解决alpha透贴排序的标准方法是两次绘制，第一次在不透明队列里渲染一次alpha test（cutout），打开zwrite，第二次在transparent队列里开alpha blend不开zwrite，ztest lessequal渲染就能还原美术在maya里看到的效果。
弹簧是个非常好用的物理组件，其虎克系数可以有效的模拟力的衰减来做出很多感人的效果，从乳摇，臀摇，尾巴，头发马尾，布料，脸上被重拳击中的肌肉变化都可以看到弹簧的身影。
adobe fuse cc + mixamo可以非常快速的搭建模型和动画来帮助策划找到剧情的场景的感觉。
脚下ik从程序来讲是很方便实现的，大多数引擎都有ik功能，但是工作流程我发现很多公司都没有正确使用。正确的流程是对输出的动画有一个左右脚高低的分析工具，逐动画生成每个脚步离水平面的高度曲线，然后运行时根据脚步的高低来决定ik和skin的权重。
镜头的设置很重要，最好给美术一个和相机镜头类似的算法来反过来计算fovx和fovy，我看到很多产品的fov都是一水的60之类的。
对于类似铁丝网或者其他半透物体的mipmap的标准做法是先自动生成mipmap，然后要美术手动的来降低不同lod贴图的alpha，换句话说近处看有铁丝网，远看就只有框中间近乎全透了来降低锯齿感。
dx10以上的平台上特效的shader加一句根据当前depth和已经绘制的depth的差来控制alpha可以实现简单且效果不错的软粒子效果。
头发的物理效果可以参考衣服的做法，发根受skin影响多，发梢受物理多一些即可。（额前刘海受物理要关掉重力）
如果实时sss负担太重，可以简单的把模型厚度信息烘培在顶点色的某个通道上，然后只需三两行代码就可以让皮肤有sss效果。
看到好多项目用双面材质只是在shader中简单加一句cull none，这个是完全错误的实现。正确的做法是需要把三角形索引信息走vs传递进来，然后判断是否顺逆时针，对于反面需要把法线反转才能获得正确的渲染结果。
先更新到这。
完了，感觉思绪开始打开了，又更新一些，怕一会会忘。
动画驱动的模式下，转向最少需要8个动画，原地左转90，右转90，左转180，右转180，移动同样四个，然后根据控制器的输入来决定混合的权重，一般神海这种级别的产品光locomotion牵扯到的动画会在40-50个这种量级。
对于衣物和皮肤，detail normal十分重要，可以瞬间让你的衣服能看出针织的材质。
处理声音的时候，远处的声音混响需要程序来手动提升，近处降低混响，对临场感增加很多。
声音如果样本有限，也一定要做随机，哪怕就一个脚步声样本，播放的时候也应该随机pitch和volume。
给策划提供一个调整动画曲线的工具，横轴是动画时间，纵轴是动画播放的速度，策划通过这个工具可以调整出情绪非常饱满的动画效果（例如：攻击前摇动画速度变慢，攻击过程加速之类的）这个需要和动画师沟通清楚，要求他们只需要k好几个相关pose即可。
卡通渲染的时候有一步是非常关键也是很多公司都忽略的，就是手动调整模型法线，这一步得在美术工具内完成，通常是定义toon shading的光方向之后，通过调整法线来让一些部位有“看起来”较为舒服的受光，主要是鼻子，腋下和两个胯这三个位置。
游戏加载的正确做法是，在出包的时候对各资源的单位加载时间进行预计算（适合配置固定的主机游戏）。之后在运行时加载的时候，根据每一帧cpu的可用空闲时间来决定当前帧可以加载的资源类型和数量。
渲染阴影的时候，很多人都会忽略绘制阴影那个pass的优化，以前做上一代游戏机的时候所有会有实时阴影的模型都会做一个低模和专门的材质（如果有透贴阴影的需求）。
对于写实类型的游戏，decals的正确制作方法是拿相机去拍，比如地上的水渍，墙上的裂痕，车上的划痕之类的，开闪光灯拍照，然后回来在ps里面抠出来。
有很多arpg的游戏中都有霸体的设计，霸体中不会受击，其实这个的正确做法是动画新增一个受击层，在播放霸体动画的同时轻微的blend一个受击动画，打击感会舒服很多。
午饭时间！
反响不错啊，再来一波=）
写实风格的贴图，推荐尽量使用Substance制作，打包不同目标平台的时候，可以根据目标平台的实际硬件情况，决定是Bake出Texture还是用Procedual Texture，其实很多时候会发现很多PBR贴图除了Google图片出来修改之外，只有Substance才能比较好的制作出来。

有一个关于Animation Driven的系统中，AI的制作问题，主要是因为动画状态机自己有自己的行为准则，所以传统的AI设计思路就变得比较无力，比如说我希望我的NPC每0.3秒攻击一次，但是攻击动画本身就超过0.3秒了，怎么办？或者说状态机的逻辑无法响应到0.3秒的攻击。这个时候需要跟策划沟通，在Animation Driven的系统下，要完全的分开设计，NPC的大脑是AI，NPC的体格是动画状态机，很多时候AI的设计要根据体格的情况来酌情调整。要在行为树里增加一些检查身体体格的节点，比如说，我要转向某个方向，那么在适当的时候需要检查自己的身体是否真的转到指定方向了；同时对于大脑向身体发送的指令要分优先级，优先级的实现方法是该指令的有效时长，比如说我的身体在受击的状态中，但是我的大脑仍然下命令让我攻击一次对方，这条指令优先级存在时间0.2秒，如果受击状态在0.2秒内复原了，则该指令身体可以执行一次，如果0.2秒内身体仍然无法攻击，就丢掉此次指令。

Volumetric Cloud/Fog/Light的使用一定要提前和美术进行商量，因为计算过程中牵扯到大量的Depth sampling，所以画面中多大会存在多大面积的这类效果一定需要严格控制，否则到了后期不得不移除这些效果的时候会让整个产品瞬间降低一个档次。

在一些中低端设备上可以用一些简单的压缩算法来把RGB + Luminance除以一个除数来压缩到32bits的颜色空间中来获得非常划算的HDR效果，相比较RGBM，用除数可以免费获得“假”正确的alpha blend效果。这一条无需和美术沟通，直接上就行。（移动平台可用，效果很好）

关于差值，差值计算最大的问题是需要和策划沟通清楚，越是符合现实生活运动规则的，只能使用物理的方法进行差值，物理的方法是没有办法精确的保障差值的最终位置和时间，但是却可以获得完美的差值效果。这里有一个非常小的tips来实现物理差值：一个物体从旋转R0，位置P0，差值到旋转R1，位置P1，需要差值的时候，在物体上挂一个弹簧，弹簧的另外一端挂在位置P1上，另外物体的运动规则增加两条：1，每帧运动转角不能超过XX度；2，物体的实际运动位置是当前朝向 * 力矩；即可，差值出来效果棒棒哒，无论是飞个火球还是跟踪导弹都可以用这个。

美术资源的优化，这件事情比较好的方法是要严格的关注，但是尽量不要过早的修改这些问题，因为开发的过程中始终要留一些空间用来提升画面效果，所以过早的修改掉性能瓶颈，可能会导致到最后不得不放弃已经集成进版本的一些效果，非常不划算。所以等大家都对画面比较满意了之后，再进行一轮性能优化，结果还能再增加一些效果，对于美术大兄弟们来说就变成一件很好的事情了。
本来没打算写这么多，只是开始写了个头，就发现还有很多类似的问题也都可以罗列出来，于是出现这么多杂乱的内容，回头有时间会仔细整理整理，比如说配个图什么的，如果有朋友对于一些tips有疑义或者想知道一些详细的实现细节，欢迎私信单聊。

应某同学的要求
更新一波手游的经验ヽ(ω )ゝ
贴图进版本的时候做一个alpha通道的剥离，一方面可以比较方便的适配安卓ETC1压缩格式，另一方面后期要压包的时候alpha通道可以随意缩大小，美术基本无感知。
如果是UI资源比较重的游戏可以采取layout和资源分离的方式来获得大量的性能提升。针对unity引擎来说就是遍历ui里所有用到的material，把里面的贴图替换成4*4的空白贴图，另外建立一个从材质对应贴图的索引。因为手机是ssd的缘故所以磁盘io读取贴图的速度是非常快的，这样就可以把整个ui的layout都留在内存中不用切场景释放，不同场景对应加载不同的贴图做一个运行时的对应即可，加载ui的时间能提升80%。这一步建议新项目中前期使用，后期项目做这种级别的修改不划算，风险高。
如果是动画资源比较重的产品，建议使用自定义的动画格式，采取float16的四元数储存关键帧数据，然后加载时还原引擎需要的动画数据，以前做wii上的产品，1000个左右的人形动捕数据可以压缩到23m左右。
经历过很多手游项目的全屏大图比较多（推广图，loading图），有的会占到整个贴图量的30%甚至更多，这时候一定要优化大图的制作工艺，和美术沟通把背景，文字和前景拆开制作，一方面可以更好的压缩（方形，2的次幂），另一方面背景图可以采取比较极端的压缩参数。
加载的过程中往往最后会卡一下，这个是第一次shader提交到gpu产生编译消耗的时间，可以通过在屏幕上绘制一个透明的三角形来完成warmup，这一步基本上主流引擎都有接口，如果单帧消耗过高，可以考虑分布在若干帧里完成。
打击感的一个小trick，击中的一瞬间把时间tick调成0持续个0.1秒左右，又轻巧效果又好。
搭建UI框架的时候给每页ui增加一个fadein和fadeout的接口并且管理好状态机的切换，今后可以很方便策划或者美术增加ui打开和关闭的动态效果。

2018国庆更新
国庆期间玩了一些当下比较流行的游戏产品，感触还是挺大的，玩法设计都非常的优秀，但是整体的产品的质量差得还是比较远的，所以这一次我打算更新一期专门讲UI开发的套路。

在国产游戏中，UI是比较重的一块，基本上一个项目会有70%-80%的开发量都集中在UI上面，那么有效的提高UI的生产开发效率以及UI的品质，就会让整个产品无论是成本还是效果上都会提升很大一个档次。
为每个UI上看得到的控件都封装一个独立的类，不要去直接用Button或者AnimationButton这种级别封装的类，太底层了，至少要封装到：OKButtonGeneral, CancelButtonGeneral这种级别的类，因为UI往细节上调整无非就是加动画，加效果，如果不想一个个来搞就从最开始设计UI的时候就先把这些基类建好。
给每个可以交互的控件都要单独设计一个响应范围，例如有一个很小的图片，很难点中，但是把图片放大了又不太好看，所以最好的方式就是用小图，但是扩大响应范围。对应的要开发一个开关，让策划人员可以随时看到每个控件的响应范围。
UI开发中比较大的痛点就是每次重构或者换风格的时候，有大量的旧资源搞不清楚是否还在使用，删又不敢删，之前的美术或者策划或者程序又离职了，这样整个项目越开发越臃肿，越不可维护，碰到这种情况千万不要犹豫，在开始换风格的时候就一定要说明，原有的UI Atlas一个都不能重用，全部用新的，因为做一次atlas的时间是你清理一次资源的1/10的时间和精力，资源的版本管理本来就是技术分内的事情。
给每一页UI取一个有意义的名字，我就见过好几个美术策划程序为一个UI问题争吵了很长时间，最后发现大家在讨论的是不同的东西，UI的命名一定不能重名，否则到了后期，哪个UI在用，从哪边跳转过来的都分不清，文档都没法写。
UI的跳转，不要简单的切换一下页面，把之前的隐藏，新的显示出来这样。一定是先push一个切换UI的请求，然后UI控制中心要根据当前UI的动画播放情况，逻辑是否处理完了等等来决定是否切换，而且切换只是把当前页面指向栈顶元素，因为还要通过pop来处理返回的逻辑。
我以前看过一个程序小朋友开发UI，发现他工作中有接近30%-40%的时间是在处理显示层级的问题，即谁显示在谁前面。这里分享一个小技巧，如果你无法想明白究竟谁应该在前，谁应该在后，那就说明这两个东西本身就应该是同一个东西，写一个新的类来包含这两者，比如说有个ITEM的图标，图标上面要画一个高亮选择光圈，光圈上面还要显示ITEM的数量，那么说明这三者就应该放到一个统一的类里面去，例如说GlowableCountableItems
UI里面除了图片之外，其他的控件都应该采用九宫格，或者反过来说，只有碰到你没有办法采用九宫格的元素，才考虑不使用九宫格。
做屏幕适配的时候，不要考虑缩放图片这样的方法，按照九宫格的原理进行挂靠，如果内容太多，就需要考虑在细节元素上面再挂一个父节点，通过挂靠父节点来完成适配
字体不要乱用，一般一款游戏控制在3种字体以内，不要轻易的给字体加类似粗体/斜体之类的效果，因为最终字体是要画到贴图上缓存起来的。用到专门的字体一定要购买一个版权，省的上线以后打官司。
UI的本地化问题遵循的原则是开发一个类似于LocalizableText之类的控件，里面输入什么文字自动的写到数据库里，否则到了后期UI量大了要把文字提取出来都不是件容易的事。
另外一个本地化相关的就是美术字也应该做成特殊的资源，类似LocalizablePictureText这样的，也是节约后期本地化的时间。这些统称为LocKit(Localization Kit的简称)了这些基础设施，之后无论是产品出海到哪个国家都可以比较安心，不慌。
有一些UI效果可以考虑用shader来完成，举个例子，类传奇的游戏装备图标都会有一圈光圈围着转，这个东西用shader可能就是10行之内的事，我看到过最奇葩的实现方法就是创建了10多个小珠子，每一帧计算这10多个小珠子的位置来实现，当时我就惊呆了。
输入法这个东西要谨慎处理，如果是单机游戏，都可以考虑在弹出输入法的时候让游戏暂停，因为你在输入的时候其实是没有办法和游戏进行其他交互的。
很多游戏都有某个窗口弹出来的时候，背景模糊掉之类的需求，这种的正确制作方法是实现一个类叫BackBufferPicture，然后这个类可以配置截图的参数和属性，这样在任何地方都可以很方便的来实现这样的效果。
同样也有很多需求是在UI中嵌入3D模型，这个也是要实现一个独立的类来实现，如果3D模型上还要增加一些UI来对3D模型进行一些说明，则应当用HUD的方式在3D中实现。另外UI中嵌入3D模型很多程序直接用正交投影，这样出来的效果就会比较奇怪，但是一时又说不上来，记住，任何情况下显示3D物体都请用透视投影。
释放UI的时候一定要记得释放Render To Texture的内存，现在动不动就是2K屏幕，一块FrameBuffer很耗内存的。

kirin77 · 发表于 2021-9-20 11:42

谢邀,这个话题挺喜欢的, 但是题主这个问题有把复杂问题简单化得倾向,我这里定向为资深程序员的作用好了.
>游戏行业和其他行业的资深程序员对比
首先这个&#34;资深程序员&#34;,就是单纯指技术综合实力强的程序员,和年龄,从业时间,头衔都无关.
3a大作中尤其是强技术类型的,其规模复杂度和技术深度的挑战都非常高,另外大量的作品在多年间保持一代代的出, 中间在不停的进化, 对开发效率要求也不低.横向对比,不输于大型的商业软件,能够hold住这些的程序员,起码不比这些领域中的程序员差.
另外像cppcon,siggraph这种会议上,也能看到领域重叠的其他程序员和研究者的成果,也是一样的结果.
&#34;不屑于开发游戏&#34;的顶级程序员,如果来开发游戏的话也不会成为真正顶级的程序员,真正顶级游戏程序员对游戏的热爱和理解是必要条件.

>游戏开发过程中，最需要大批水平一般的码农还是坐镇大拿？
应该说是需要普通程序员和资深程序员以正确方式配比,形成有效的团队, 不要把程序员想象成乐高积木,简单量化. 团队更像一个生物,是一个复杂的有机体.
好的程序员会提升这个生物的dna水平.
具体在开发中的资深程序员呈现是:

然后就是不要把复杂问题简单化,这里只是谈到很有限的一部分,大量情况下你会发现没这么大的作用,比如团队就处理很简单的小游戏的时候,所谓资深程序员是一个不爱打交道的人,团队因为各种原因限制了资深程序员的发挥...具体问题具体说了.

>在如《荒野之息》这种系统复杂的游戏中，普通程序员是否有瓶颈？
普通程序员的瓶颈:可以通过模块的设计,把大问题分治成这个程序员能够承受的松耦合的小模块,这样复杂的游戏就简化成可控的简单模块了,如果不能分离处理(这种情况有的),普通程序员处理不来,那就是会成为瓶颈.
>在如育碧式开放世界的游戏开发中bug频出，是否源于程序员实力不足？
游戏质量是一个函数的话,中间有这几个变量, int GameQuality(程序员实力, 团队综合实力, 游戏复杂度, 开发周期);
程序员实力强,确实就会写出bug更少的代码, 甚至会驱动QA团队更有效的测试,进而导致更高效的产出高质量的结果.
但如果QA团队不行, 游戏规模太大, 很短的时间上线, 那就没办法了.
>在性能羸弱的掌机游戏开发中，一个优秀程序是否能创造神迹？
性能羸弱的掌机或者说现在对于性能要求更高的手机, 相比console和pc, 游戏规模会降低, 那么单人的影响会上升.
能否创造神迹...何为神迹呀?
准确说资深程序员更会创造出, 这个平台上, 比竞品更卓越的游戏了.

Baste · 发表于 2021-9-20 11:48

今天时间比较多，就多回答几个问题，也结合自己这几年在这方面工作的经验来综合回答一下。很多朋友都回答了很多具体的技术和细节，就不重复了，今天主要讲几个方面。

1: 专业知识和基础。在任何行业坚实的基础都是最重要的必备素质和能力，这包含了计算机的知识比如组成原理，程序语言，数据结构等等。包含了数学的知识比如3d数学，线性代数，等等。也包含了游戏开发的知识比如游戏的各种系统，引擎，等等。

2: 解决问题的能力。很多学生和新人，都觉得真正在公司工作要写“完美的代码”，“最优化的程序”等等，实际上，在公司工作，大部分的时间你不一定是在写代码，或者说很多时候你是在“和恶心的限制下”写代码和解决问题，写出“完美的代码”有时候是不可能的或者不现实的。解决问题的能力包括你遇到了技术或者设计的问题之后，你如何分析，尝试和高效率的解决问题，你会遇到“这个引擎不支持但是我也要做出来某个功能，但是又不能花太多时间”，你会遇到“这个很旧的codebase我必须要想办法修好某个问题但是我没办法大改”种种问题，这些问题都是综合的难题，不完全是技术程序问题，程序员的一大工作内容就是解决开发中的问题而不是纯写代码。

3: 和他人合作的能力。3A游戏需要的团队基本在100人以上，2-300人很常见，程序员需要和各种开发人员打交道，通常一个程序需要支持几个美术或者design，如何和不同领域的人顺畅的工作让大家高效的进行是非常重要的能力。这项能力可能包含，你需要耐心的和非技术的人员解释技术限制，你需要想办法在不浪费美术的时间的情况下帮他们解决问题，你需要在别的部门出现困难的时候作为他们的坚强后盾让团队度过难关。和人沟通，让人信任你的能力不只是团队成功的关键，还是你个人成功的关键。

4: 理解自己开发的游戏。理解自己开发的游戏类型，了解并知道如何改进，如何优化，把自己当成用户玩家，去体验感觉这个游戏的优缺点，发现了问题如何改进，优点如何更优化？这些都是需要积累和试验的。

总结，游戏开发的程序绝对不是单纯的写出“漂亮的代码”，综合训练自己的能力，把自己看成优秀的开发人员，而不是纯写代码的coder很重要。

rustum · 发表于 2021-9-20 11:53

个人认为，跨领域的职能发展路线，对于目前的游戏行业，其实比什么进入管理层更值得我们去追逐。不懂技术，那么就无法直面技术进行流畅交流，不懂美术也无法与美术直面交流；同理，技术、美术也一样。无论游戏行业流水线的哪个环节，在不知晓其他环节的操作方式的时候，盲目评价其他节点的工作质量、工作效果，都是无理取闹，都是神经病。

最后，我觉得，我们策划每天都要琢磨琢磨，程序小伙伴是否值得我们去配合，更重要的是，我们是否给程序小伙伴造成了困扰；我们是否做得足够好，学习到足够多的内容，来配合程序小伙伴的工作。别把自己当成填表的机器，而程序小伙伴也不要把自己当成码农。

---------------------------------------------------临时分割，补充描述，以下正文-----------------------

我以策划的立场看待这个问题...我回忆了一下自己的过往经历，接触的一些程序方向的技术人员...

我发现，顶级程序不是不屑于开发游戏，而是他们大多数的工作在产品的前期筹备过程中，就做了好多了，这些准备工作促使策划、美术在产品装配的过程中，准确、流畅、返工率低...而他们随产品推进而带来的工作内容，更多的是在结构上的完善维护...

我接触的比较牛逼的程序(我没做过3A，我不懂那里的程序是什么样)

1.可以搭建一个足够应对大部分策划脑洞的架子，这个架子大多数时间都是非常稳固的，足够应付大多数的脑洞。比如战斗技能设计，我可以在他提供的平台上，编辑出大多数技能，并且脑洞够大的也可以实现出来。而他的主要工作，可以理解为，就是在完善框架，避免框架应付不了我的脑洞。

2.他可以为我和美术提供一个可视化的展示，我和美术完全可以脱离技术，完成一些资源的装配体验，获取反馈之后，进行设计调整。这里的可视化，并不是一个限定环境的可视化，我记得很多需要技术支撑的步骤，他的结构都为我们准备好了，很多都是引擎自主完成的，我们只要导入就好，即使是以错误的操作方式，都能应对，总之就是让没技术相关知识的人，可以进行无脑操作。

3.实现的内容实际上超出策划、美术的预估，我个人大多数时间的设计，并不是一成不变的，很多时候，在没有可视化支撑的情况下，我并不知道自己的设计是否是一个可执行很高的设计。而顶级的技术，往往看到我第一版的设计的时候，可能他会根据自己的游戏经验、工作经验，加入自己的设计，无非是这些设计我不用，他关闭掉。而往往就是他加入的这些内容，促成了我的设计进行顺利的返工。

与顶级的程序合作，我感觉自己非常自由，他的工作量不是表面上的那些。在与他们交流的时候，获得的大多数反馈，都是这样的，“我教你一个办法，这里有一个小功能，你拿去，按照我说的办法，你就可以看见你想要的东西了。然后，现在你别来烦我，我有更重要的事情要去做”；而与一些比较差的程序合作的时候，大多数都是这样的，“你这个想法不成，太难实现了，框架不容许，要么就是重新搭框架，这得返工”，然后就是一顿撕逼...

一个产品要上3A的级别，我作为策划，经验告诉我，瓶颈在于技术提供的支撑，可以让美术、策划的设计放大到什么程度。无论是表现力的处理、逻辑过程的处理，技术限定了策划、美术的发挥，比如一个常见的问题，“同屏20人的客户端效率，可以流畅的展示同屏50人么？”

顶级技术可以最大限度的为设计团队提供支撑，这不是一个小程序员能够托起来的一个大盘子...

BlaXuan · 发表于 2021-9-20 11:59

反对下楼上说技术不重要的。技术是否重要要看项目类型。何况楼上回答都偏题了。
游戏开发与艺术创作一样有两条不同的驱动方式，一条是技术驱动，一条是内容驱动。所有项目都有内容和技术，根据项目驱动方向的不同站的比例也不同。对于内容驱动的项目，技术并不是很重要，只要能表达内容就可以。技术驱动的项目则相反，只有达到特定标准的技术才能体现出游戏乐趣。
但是技术与内容不同的是，技术很容易传播和重复使用，一个技术出来不出一两年就会有一大波游戏公司在使用，而内容你要是这么干，一帮人会告你抄袭，而且玩家也没兴趣反复体验。

回到问题。
如果只是一般程序员，代码和API/常用库熟悉，能根据问题合理选用数据结构和算法，逻辑和代码清晰干净，能跟同事正常沟通，对工作认真负责，基本就能完成自己的任务了。还有就是遇到正常问题能通过 google github stackoverflow 解决掉。
高级点的程序，要解决项目中的各种问题。
需求分析，要能将项目需要实现的口头说明和文案转成对应的程序功能，划分模块，规划制作内容。要考虑需求变更和扩展，要考虑通用性。
进度管理，要能根据需要实现的功能估算项目时间和进度，合理安排人员和功能实现，根据当前进度和项目里程和需求变更情况进行调整，取舍，重新规划。
技术，解决自己专长方向的技术问题，配合项目需求。通常面临的技术问题图形图像，优化显示效果，跟概念设计人员一起研究性能开销允许下的最好实现标准，实现特定的艺术效果等。根据平台机能优化运行效率和内存管理。网络的话还涉及到数据处理，延迟，同屏最大人数之类的。
人员管理，感觉管理不应该算到程序员技术这里，不过国内公司好像挺喜欢把人事也塞到主程组长之类的职位上。

acecase · 发表于 2021-9-20 12:04

以下单从技术角度出发来说。
众生皆有佛性，顶级游戏的开发也是一样。出发点很重要，就是你有没有立志要让你的产品达到行业顶级的水准。如果带着这样一个决心去驱动开发工作，对每一个开发中遇到的问题都零容忍，对每一个程序细节一定程度上极致考究，只要能做到这样，每个程序员都能是顶级游戏的开发者。
别太迷信所谓优秀的顶级技术，君不见纵使云风或叶劲峰这种公认的游戏行业技术大牛，也没能直接决定某个顶级游戏的现世，也从来没有某个游戏因为某个大神程序员而封神。技术的高低不是决定因素，举个简单的例子，基础不差的话，如果能下苦功去读读一些关于游戏开发前沿领域的相关PAPER，再花个半年一年时间做个研究做个实际案例或编写个相关开源库，我相信你也能就这个领域跟大牛们围坐在圆桌旁侃侃而谈，但这并不是开发顶级游戏的必要条件。很多别具匠心的大作，往往出自名不经传的团队或个人开发者，所以匠心和执着才是真正决定一款作品，有这样的心态，哪怕经验经历尚有不足，顶级开发者之名，亦当之无愧！

DungDaj · 发表于 2021-9-20 12:07

第一个问题，游戏程序和普通有什么差距吗:
首先，3a游戏和普通游戏不同的是规模。规模大了，分工更细。很难和不是游戏行业的程序员对比。

程序员的核心能力是什么，我觉得是解决问题的能力。
一个3a大作基本要解决的问题:
跟上画面，图形程序员
给开发者用的工具，引擎程序员，工具程序员
游戏本身，逻辑程序员，游戏性程序员
多人游戏，网络程序员
提供碰撞检测和物理模拟，物理程序员

在这些程序员里面，有一般的也有很厉害的。

拿渲染来说吧。可能顶尖的是siggraph那些发新的渲染算法。顶级的游戏图形就是把他们移植到对应游戏里面。对算法做更适合游戏调整的。差距不会太大。你说我都可以理解你的套路，并且合理运用，差距会大吗？

另外，当年的cryteck还是自己发明了各种针对游戏的伪全局光照相关的算法。据说有个u3d和unreal在用的寻路烘焙，也是他们弄出来的。

反正业界顶尖，在某些3a项目，是肯定有的。但是都更偏向实用和商业。首先，你的游戏要成功，才能说你的技术屌。不幸的是游戏成功不止靠程序和技术。

第二个问题，有多少屌得顶尖程序在3a游戏开发里面呢:

我也不完全清楚。但是规模到了，肯定不会都顶尖吧。让世界前五十强程序员都来开发一个3a游戏，这是不可能滴。

正常的可能是，三五十个程序，内部又有分组。负责一个模块的。比如上面的各种分类，都有自己的主程序员，所以一个大作，主程序可能不止一个。但是干活的更多。毕竟，做出一款游戏，技术门槛一到，剩下的都是体力活。

但是3a游戏，程序平局实力的确会比一般二三十人的强一些。首先招聘要求在那里。

最后，题主问的，关于bug是否是程序的锅:

我的回答是，当然不是。

首先，如果是国内小公司，肯定是策划美术或者测试的问题咯。锅可以摔嘛。

3a，有自己严格的流水线，出问题了，是一个团队的问题。

而且由于育碧这种公司的3a会跨工作室，沟通大家有耦合又不在一起上班，说不定我改过你的代码但是一辈子都不会见面。单个程序能力更是不在决定因素。

出bug，可能是地图某个东西没放对，策划配置有问题。程序可以想法避免，但是参与其中的每个人都有责任。

最后的最后，题主问优秀的游戏程序可以力挽狂澜吗，主宰项目吗:
这个我不知道。但是，一个坑的程序，如果身居高位，应该可以毁掉一个项目: 比如他可以让服务器老宕机。

unityloverz · 发表于 2021-9-20 12:11

与其说需要编程实力，不如说更需要强大的工程项目管理能力以及系统架构能力。
好的项目管理，可以做到灵活应对各种突发问题和情况，让整个项目有条不紊的进行下去。
而好的系统架构能力，能让每个小兵只关注自己的分工部分，做精做好，而不用过于担心因为自己加了一些功能，反而影响其他人的功能，甚至整体的功能运行, 导致系统复杂度的管理失控。
打个比喻，就好比带兵打仗，有10来个人，个人武艺起决定性作用。而10万人打仗，小兵的个人实力就很难体现出来，相反更需要排兵布阵的统帅和管理能力。
当然核心算法性能也是很重要的，能体现个人技术水平的差异，并且如果有提高也能得到很大的收益，但是一般上，这些算法并不是项目的主要成败关键所在，很多都是业界通用的算法，或者之前已经稳定下来的也不太需要老改。

RecursiveFrog · 发表于 2021-9-20 12:19

有人说钱能解决的问题都不是问题，同样，游戏开发中能用编程解决的问题都不是问题。

		自动登录	找回密码
密码			立即注册