第一步：搭基本的、可玩的场景关卡，虚幻提供了非常强大的BSP编辑功能（Convex功能），可以用来进行关卡原型的制作。这个关卡只要可玩就好，一般由编关策划搭出来，基本都是些Box这样的基本物体，满足关卡的可玩性即可。
第二步：替换一些主体模型，主体模型一般应该基于已经固化的玩法关卡来制作，不应改变玩法关卡的主体结构。
第三部，打光、赋予主题场景的材质，把场景的大效果给弄出来。
第四步：添加细节物体和细节表现。
这个就是在国外比较成熟的关卡原型思路，是一种非常好的思路，笔者私以为这种方法对国内的游戏开发遇到的一系列问题也有很大的参考意义，结合笔者得到的资讯和个人的理解，展开一下，供诸位战友参考。
过去我们有些团队做关卡，美术得等把关卡整体都搭个差不多后才会交付策划，然后策划开始布置怪物、触发器、脚本，这种方法显而易见的具有下述问题：
策划一开始必须考虑完全整个关卡的样子和流程，否则美术一旦开始，资源堆上来后，再去调整就是巨大的工作量和士气损失，对团队团结也是非常不利的。但是，平心而论，这对非山寨的创意性项目基本是不可能的，创意期的策划调整本身就是客观规律，对游戏未来也是有好处的，日本的制作人和策划已经足够牛逼了，还会"对不起，我要修改部分规格"，何况中国策划呢？
还有就是协作的问题，一般来说，美术正在改场景的时候，策划是需要停工的，当然好的引擎可以通过层或者其他什么方式来解决这些问题，但是根本上这个整合的工作量是客观存在的。美术提交给策划的美术资源是否可以认为是最终资源？这个基本是不可能的。提交给策划后，策划一方面要在里面布置触发器、怪物，另一方面要去通知美术修改地图和资源，这中间在整合上需要耗费大笔的工作量。
工作时间的无意义浪费：美术搭建整个关卡的时间一般是需要以月来计，在这个过程中策划只能撂荒，当然，团队中总有事情需要去做，策划也一般不会说没事可做，但是如果一个策划的业务重点是负责这个关卡，却总是不能把精力和时间花在这个关卡上，这不是很奇怪吗？另外一点来说，当策划开工的时候，美术基本上也撂荒了。至少在关卡制作的初期，这基本上是一个单线程的工作，同时只能有一条线在执行这个工作，另一条线只能干等着。等着等着，黄花菜就这么凉了。
最后谈一个引擎部门可能会比较敏感的话题：关卡出来前后，有三种选择：出来前程序进驻观测性能和内存问题，出来后观测，以及策划做完后观测。不幸的是一般的团队都会选择后两种方案，然后……我相信这个时候引擎的战友们一般的第一感觉都是"我勒个去，美术又暴走了"！
上面这些如果您的项目全都很好地解决了，壕，友乎？笔者真的很想去你们的项目工作，因为你们创造了可以载入人类史的奇迹。
如果没有，不用担心，笔者所知的项目多数都跟你们一样，这个意义上你们并非没有竞争力，但是接下来才是最好玩的事情：
程序通知美术说，你们爆了内存的菊花，这个不行，限期整改。
美术说，这个我们做不了主，得问策划。
策划说：这个不是我们的问题，美术自己的事情，另外，我们的需求就是这样，一个场景必须得四种不同的美术风格。
最后闹到制作人那里。
程序一句话：你们怎么决定我不管，XP下Win32内存就2GB，Large Address到3GB得玩家自己会搞，现在内存爆了，微软来它也解决不了，你们自己看着办吧。
制作人：啊，这么严重？都给我推倒重来！
几个月的工作白费，美术和策划跟引擎的梁子就是这么结下来的。
把问题回到开头，我们发现这个中间有个最核心的问题：
策划是否真的需要一个场景的美术资源完全出来？
我想，答案应该是否定的，虽然我不是策划，但是我实在想不出来为什么会有这个需求：策划这个工种的重点就应该是玩法、调度、整合，无论哪个，跟场景最后的显示效果有什么根本性的关系吗？
当然，你可以说一些小关系，比如一个破败的小村里不能做金碧辉煌的建筑，但这个你只要提了这个需求我想美术也不会二到偏要在一个教堂里布置一套旧馆的设备。
建议我们的制作人都可以问问策划是否有这种需求，让他们解释清楚必须要等待美术全部资源的理由。
事实上我自己接触到的策划都表示："我们其实只需要这里是个概念上的村子就行，你种俩房子就可以了，不需要种上十几套房子"，这样。真正去抠"村子就得有十几栋房子"这样的人反而是美术……
这个根本问题一旦解决，接下来其实就好办了：
- 策划希望这个场景怎么玩，自己是最了解的，用编辑器已有的工具搭建一套原型出来，摆位置、设属性、刷高度这种操作还学不会的话就不是技术问题，而是智商问题了。实在真不行，配一个兼职美术，就一个，兼职帮他做就好。
- 做完后，自己往里面布怪、布任务、布逻辑、布脚本。
- 然后自己进去测测怎么回事，这个过程中发现的问题，直接调整原型关卡即可。
- 最后，把这个关卡拿给其他成员审批，大家都觉得ok后，再提交美术开工。
- 美术一开始先把大结构、框架性资源放进去，比如房子、城墙、柱子这之类的。
- 装完后，提交引擎查看一版资源占用，性能和内存是否Ok。
- 如果不Ok，就得好好考虑考虑地图的大小和分区问题了。
- 如果Ok，开始往里面放细节物体。
- 每放一段时间，就让引擎审批一次，或者制作一个自动化工具来查资源。一旦超了就开始玩加减游戏——减一件，加一件，减10MB，加10MB。
而且，做加法总是给人希望，辛辛苦苦做了三个月的东西引擎一句话全都推翻了，这样的队伍就算目标再明确，早晚也会分崩离析的。
而且在这个过程中，颇有一些Tricks可以发掘：
测量和标尺：
两个石柱子，A能跳过去，B就跳不过去，结果我这里要搭个机关，正巧是要能跳过去的，但是还觉得B好看，咋整？没法整。
现在，策划自己在制作的时候，就需要把标尺打清楚，后面美术制作资源的时候，跟这种关卡玩法有关的资源必须严格按照标尺执行，说是1.3米就是1.3米，多一分少一分都不行，这才是专业做游戏的思路。好家伙一个城市恨不得所有的建筑都不一样的标尺，拼一起都费劲，哪个老师是这么教你做游戏的？ 您还是去做CG和影视吧，游戏太屈才了。
物理碰撞和Navigation面的简化：
基本上不需要再做了，因为关卡最一开始策划做出来的原型，直接拿这个转化成物理碰撞和Navigation就八九不离十。
UE4有另外一个示例：ShooterGame，展示了这一点。
默认加载的场景：这里面粉色的线条和我正在选中的线，是Blocking Volume，专门用来做阻挡的。这些基本都是一开始搭建场景原型的BSP，直接用Convert转化成的。
细节可以很复杂，但是碰撞非常简单，同一视角下的纯碰撞：
国内开发比较多的时候会就接细节物体的细节碰撞问题——太细了导致各种不可控的问题发生，你要按照这种方式做怎么可能会出问题呢？
模型可以很高贵，但是不影响碰撞和Navigation可以很简单。
另一个场景完全就是原型，刚刚开始制作：
可供大家参考。
建议大家了解一下，上海那边做主机游戏的战友们应该对这些标准比较熟悉，适不适用于网络游戏？我不清楚，但是如果按照过去的那种做法遇到如此多的问题，为什么不尝试一下新的思路，您说呢？