马上就要扩展一下职业路线了，想了解一下游戏开发流程、团队分工方面的问题

[Simality]

正在注册一个公司，马上就要着手组建一个团队去做专业领域的3D游戏。商业细节不便透露，但技术目标非常具体。现在想在技术层面上初步拆分一下，看看怎么组建团队比较合理。

既然针对专业领域，就不是做网游，也不对大众开放。游戏是模拟驾驶方面的，玩家通过标准HID游戏接口设备操纵虚拟的交通工具。画面是驾驶室的第一人称视角，交通工具本身是一个复杂的系统，很多组件需要建模，对组件的操作影响到交通工具与虚拟世界之间的互动。

游戏是多角色的，主机可以建立任务，不同玩家可以加入任务进行互动。可以新建AI角色参与其中。

玩家的物理输入基于DirectX中的DirectInput，游戏画面的图像输出基于D3D，需要制作大量的3D模型和2D贴图。还有些额外的输出用于驱动外部的液压作动筒之类，基于什么技术尚待选择。有些数据输出对实时性要求较高，因此所用技术必须做到低延迟。

游戏的物理建模工作量很大，分交通工具本体的建模和外部环境建模两个部分。

交通工具本体建模是从驾驶人员角度出发，对交通工具本身的系统进行建模，比如液压系统、电源系统、计算机系统等。

液压系统的建模最简单的例子就是如果一个管路某个位置发生泄漏，则下游的液压作动筒都无法动作，并且被液压作动筒控制的零件会在外力作用下发生运动。

电源系统需要处理一些逻辑，比如A电源和B电源相互备份工作，正常使用时必须全开，然后才允许开启用电设备C。如果B电源在设备C使用过程中损毁，则要在虚拟的驾驶室某个面板上让一盏红色警告灯闪烁，并播放警报声音。

计算机系统是指虚拟世界中的一个虚拟计算机，举个贴近生活的例子：虚拟世界里的角色拿着一部智能手机在拨打他虚拟家中的固定电话。我们需要模拟这部手机上的整套GUI逻辑，也就是说虚拟的角色按了虚拟的手机屏幕上面一个电话图标，我们得看到这部虚拟手机上出现了拨号键盘。然后这个虚拟角色按下了家里的号码，开始拨打，那么我们要听到虚拟的环境里这部固定电话开始响。前者是纯的界面转换，后者则是界面中的特定对象与虚拟世界大环境中另一些特定对象之间出现的特定关联。界面与关联都要方便编辑修改，像GUI的界面转换规则之类用脚本实现就比较灵活。

外部环境的建模涉及常见的重力场、碰撞与摩擦、作用力与反作用力、弹力等，会涉及一些空气动力方面的物理模型。物理对象包括一些可以与交通工具发生物理碰撞关系的物体，一些用于模拟意外情况下的损毁模型，为数不少的粒子效果。

联机功能方面，需要允许两个或更多个人在不同终端上操作同一个交通工具，各司其职，各自的显示器上显示自己的座位所看到的视角。也需要允许不同玩家相互交流，点对点、点对群发送文本甚至压缩的语音。语音也可以经由TeamSpeak发送。但占用的都是同一个物理连接的带宽。

软件需要具备很强的扩展性。交通工具不只是一个型号，未来需要发展出很多不同型号，在同一个虚拟世界中互动。所有的具体物理细节都要可以扩展，但是虚拟世界的基本物理规律不变。

长远看来这么庞大的系统必须要有自己的引擎，并且引擎本身要有一定的扩展性与灵活性，便于升级。无论是像微软DX10升级到DX11这么重要的更新，还是硬件架构大改动带来的一些新技术，游戏本身也需要做出一定的更新，无论是发布升级包还是发布新版本，需要尽快加入新的支持。当然要做到这个程度，没有几年的技术储备很难。

因此初期需要向其它公司借力。现在有一些公司的现成产品支持我们的大部分需求，有些公司甚至推出了自己的SDK用于二次开发。初期我们会采取这种形式。因此团队的工作内容会有个变化的过程。从二次开发转向自主开发。

我作为一个工程师非常熟悉讨论具体问题的氛围。大家多数时间都是在讨论非常具体的细节问题，但是这个话题比较宏观，我想通过刚才描述的信息先了解一下团队的架构，讨论一下后期的原创开发阶段这些工作应当怎样拆分。希望可以听到不同职业朋友的不同声音，把这个拼图整理出来。本想多给些分数做见面礼的，无奈最高只能给100分，对不住了。

[彩阳]

对于高手，我只能纯支持了。

[大拙男]

对于高手，我只能纯支持了。

[Simality]

大家有啥想法随便说，我是硬件那个区过来的，外设之类的硬件设计我在行，游戏开发我不熟悉。但是现在必须硬啃这块骨头，我不用亲手实现每一个细节，但是必须对流程和架构有个足够专业的认识。我不希望我的公司出现外行领导内行的局面，这是我自己打工的时候最痛恨的事情。

[芳草天]

所谓二次开发，可以到什么层次？如果直接就有个赛车游戏可以套壳，那工作没多少。 不过，我建议楼主还是先深入了解游戏研发的技术特点先吧。 比如： 游戏引擎是什么东西，都包括什么，是怎么做出来的，这能让你更理性的去看待这个行业（PS，看楼主的规划，略托大）。 3d游戏的成像原理是什么，这有助于你了解游戏开发的难点和重点是什么。 游戏的研发周期一般有多长，你这个项目类其实已经是个局域网版的网络游戏了，可以简化的不过是不用考虑服务器的安全性而已。 有了这些之后，再调整一下你的项目规划，制定阶段目标，然后才是团队架构。 其实团队架构，反道不是什么重点，参考游戏行业就可以，主程带几个程序小兵，主美带几个美术小兵，主策带几个策划小兵，后期还要加入测试。 小兵的人数，还要看你这个项目计划做到的规模和使用的引擎工具来定。

[Simality]

引用 4 楼 liuxingzdh 的回复:

所谓二次开发，可以到什么层次？如果直接就有个赛车游戏可以套壳，那工作没多少。 不过，我建议楼主还是先深入了解游戏研发的技术特点先吧。 比如： 游戏引擎是什么东西，都包括什么，是怎么做出来的，这能让你更理性的去看待这个行业（PS，看楼主的规划，略托大）……

谢谢，非常有价值的建议。现在就是信息量太大，不知从哪里啃起。纵向看流程，需要了解每个环节的来龙去脉，依赖什么，又走向哪些分支。横向看资源，每个环节涉及到哪些技术点，需要投入多少人力成本和时间成本，每个人需要具备什么具体的技能。整个看来就是一张大网，我得选一点切入，然后把整张网的关键节点理清。干脆就从游戏引擎开始向四面八方了解吧，除了Google之外实在没啥想得起来的工具，能搜到具体技术方面的东西会比较多，但是具体到本项目的工作量评估、人力需求评估，估计和实际情况会有出入，估不了那么准。但是至少问题可以越来越具体了。如果朋友们有更多想法可以跟帖讨论。我洗耳恭听。

[芳草天]

3D游戏的技术难点是围绕游戏引擎来的。游戏引擎的开发是最难。会写引擎的人很少，国内会设计游戏引擎的人几乎没有。 市面上可以商用3D引擎不多，熟悉引擎使用的人也很少。特别是效果强大的引擎，更少。 关于美术，会做3D游戏资源的美术其实还是很缺的，而且，效果绚丽的引擎还要靠美术堆人堆出来，资源量大。 所以，稳妥的做法是找一个轻型的游戏引擎做项目开发，减少招人难度。 还有就是研发周期，对于3D游戏，如果人员齐备，经验丰富，基本上最少也要半年，才能出来个演示demo。 还有就是资金问题了吧，做游戏还是很烧钱的。小团队，一年少也要烧掉几百万。

[芳草天]

对于现在的技术，现有的物理引擎基本也只能做到一些简单的碰撞，机械关联，载具独特的物理特性，基本都是通过逻辑脚本去修改物理引擎提供的参数来实现的。 通常，很多独特的物理效果和模型改变，都是通过骨骼动画实现的。 物理可以参考网游《坦克世界》。里边几百种坦克，机械性能都不一样。 招人的问题，可以先不考虑研究引擎的事了。 有能力研究引擎的人，要么都是各大网游公司的骨干，要么自己创业。 除非你有熟识的人，可以拉来一起创业，要不然基本没戏。 这几年，死掉的3D工作室太多太多了，大多都是东西都没生出来就死掉了。 布局太大，只会浪费钱。 所有人力都投在保证第一个项目尽快交付，不会黄掉，才是正经。 自研，还是等到能小有名气的时候再来考虑。

[Simality]

引用 6 楼 liuxingzdh 的回复:

3D游戏的技术难点是围绕游戏引擎来的。游戏引擎的开发是最难。会写引擎的人很少，国内会设计游戏引擎的人几乎没有。 市面上可以商用3D引擎不多，熟悉引擎使用的人也很少。特别是效果强大的引擎，更少……

美术方面我们要求不是很高。毕竟不像Crysis那种科幻题材需要创作的。我们所有建模都是基于实际存在的机械装置与建筑，几何外形（3D建模）和外观（贴图素材）都有实际的东西可以参考。光影和渲染效果方面是需要人去校调的，但比重不大。 真正庞大的工作量我觉得是物理引擎。基本上真实世界里存在的一些基本物理现象都要在软件里复现出来。温度、湿度、气压梯度、流场、粒子系统、机械结构的约束与自由度、碰撞检测、电气系统模拟等等。这个是我们所需的游戏引擎里最庞大的一个组件，有些模型需要实时运算的就会比较占用CPU资源，实时运算太复杂的就只能在开发阶段做成表格的形式，运行时查表插值去逼近。更蛋疼的是将来有新型号的载具加入游戏时，它具有的所有物理特性需要从头到尾全部创建出来。那么它和原有的物理引擎到底是什么关系，它作为一个模组，与引擎本身的耦合度如何把握，都是问题。其它部分比如脚本引擎和网络引擎，没有什么很特别的要求。 资金应该没有问题，我们可以筹到需要的资金。时间上来讲，基本上每个客户可以承受的项目周期都是1年。我们作为开发方，时间线自然是不同的。前期1年不够用，成熟后可以同时接待好几个客户。为了缓解起步阶段的巨大压力，我找到了现成的游戏，打算从对方那里购买正版软件，然后使用他们官方公开的文档在那个基础上开发插件，这样引擎的问题就暂时解决了。我们可以在制作插件的同时用相对轻松的心态钻研引擎的开发工作，做一些必要的技术储备。前几个项目的时间应该够我们完成自产软件由内到外的测试了。 这样带来一个问题就是两种开发模式所用到的人力资源怎样最优分配组合。我感觉很多东西受最终需求影响比较大。如果需求变了，技术路线变了，那么原先招的人具备的技能可能就不对口了。乱招人和乱辞人都是不可能的，那么员工自身的学习能力以及他这个职位本身与我们需要他去学的东西是否足够相关，是个很大的问题。我先接着看引擎开发和那个插件开发的文档去。

[芳草天]

引用 9 楼 Alex_rcpilot 的回复:

[quote=引用 8 楼 liuxingzdh 的回复:] 对于现在的技术，现有的物理引擎基本也只能做到一些简单的碰撞，机械关联，载具独特的物理特性，基本都是通过逻辑脚本去修改物理引擎提供的参数来实现的。 通常，很多独特的物理效果和模型改变，都是通过骨骼动画实现的。 物理可以参考网游《坦克世界》。里边几百种坦克，机械性能都不一样……

嗯，坦克世界确实是个不错的参考。做插件的话，骨骼放在3D建模这块，然后物理特性之类用lua脚本实现，所有东西按照说明文档做就行了。 可能很多人都会问你自己没有游戏开发经验为什么要做这一行，没有懂引擎的人为什么要做引擎。其实主要原因是我们和大众娱乐市场没有交叉。而且产品需求和资金供应已经摆在那里了，一不做二不休了。我们做出来的东西不用也不能靠广告去宣传，因此所谓的名气也只是圈子里传一传。不大的圈子，很多的钱。所以自己的核心是必备的，插件开发阶段过后，即使不做自己的引擎，也至少要买一个够用的商业引擎来用。如果对方要卖，至少会提供一些技术支持的吧。[/quote] 基本上，能用的商业引擎的授权费、技术服务费都很贵。也有可以免费使用的，但没有技术支持，没有源码，如果出了莫名奇妙的bug，可以卡到项目停滞。 还有，技术人员和游戏行业有交叉，招人会是个不小的问题。

[Simality]

引用 8 楼 liuxingzdh 的回复:

对于现在的技术，现有的物理引擎基本也只能做到一些简单的碰撞，机械关联，载具独特的物理特性，基本都是通过逻辑脚本去修改物理引擎提供的参数来实现的。 通常，很多独特的物理效果和模型改变，都是通过骨骼动画实现的。 物理可以参考网游《坦克世界》。里边几百种坦克，机械性能都不一样……

嗯，坦克世界确实是个不错的参考。做插件的话，骨骼放在3D建模这块，然后物理特性之类用lua脚本实现，所有东西按照说明文档做就行了。 可能很多人都会问你自己没有游戏开发经验为什么要做这一行，没有懂引擎的人为什么要做引擎。其实主要原因是我们和大众娱乐市场没有交叉。而且产品需求和资金供应已经摆在那里了，一不做二不休了。我们做出来的东西不用也不能靠广告去宣传，因此所谓的名气也只是圈子里传一传。不大的圈子，很多的钱。所以自己的核心是必备的，插件开发阶段过后，即使不做自己的引擎，也至少要买一个够用的商业引擎来用。如果对方要卖，至少会提供一些技术支持的吧。

[Simality]

引用 10 楼 liuxingzdh 的回复:

基本上，能用的商业引擎的授权费、技术服务费都很贵。也有可以免费使用的，但没有技术支持，没有源码，如果出了莫名奇妙的bug，可以卡到项目停滞。 还有，技术人员和游戏行业有交叉，招人会是个不小的问题。

困难都会有，硬挺也得上。你给的参考信息都非常有价值，我会继续深入了解一下整个行业。招人方面我认识了十多年的大学挚交在某大人力资源公司任职多年，猎头方面的事情他可以帮我搞定。引擎方面以后需要人手的话我们可以考虑高薪挖一个人过来负责，不知这职位行情怎样，月薪5万少不少？

[Simality]

引用 10 楼 liuxingzdh 的回复:

还有，技术人员和游戏行业有交叉，招人会是个不小的问题。

事很凑巧，我们专业圈子里有个朋友刚好是一游戏公司的高管，有多年管理经验，带领的团队分工涵盖了3D建模、美工、物理引擎和后台逻辑等等。完全有能力做自己的游戏引擎基础研发。我们有两年没聊了，以前只顾着在一起玩重合的专业，没过问他的工作，不知道他是混这行的。 现在问题彻底解决了。结帖给分，多谢兄弟。

[芳草天]

引用 13 楼 Alex_rcpilot 的回复:

[quote=引用 10 楼 liuxingzdh 的回复:] 还有，技术人员和游戏行业有交叉，招人会是个不小的问题。

事很凑巧，我们专业圈子里有个朋友刚好是一游戏公司的高管，有多年管理经验，带领的团队分工涵盖了3D建模、美工、物理引擎和后台逻辑等等。完全有能力做自己的游戏引擎基础研发。我们有两年没聊了，以前只顾着在一起玩重合的专业，没过问他的工作，不知道他是混这行的。 现在问题彻底解决了。结帖给分，多谢兄弟。[/quote] 恭喜。

[简单并快乐着]

高手贴啊。这个难度很大的。