站在 VR 世界的大门前 - 项目特质与设计开发流程的策略选择

2016-09-25 21:17:00

尝试边听Tupac边做博客，再一次不成功。Ice Cube或N.W.A也是差不多的样子。毕竟是所谓的文字工作（这样抬举自己不觉得羞愧？），总有那么一个或一群黑老哥在耳边一刻不停的絮絮叨叨哼哼唧唧算怎么回事？平日的设计工作则另当别论，多数时候的思考和操作对象并非文字，于是说唱这一类偏重“语言”的音乐便不易形成干扰；非但不会干扰，反倒很是享受，有动听的旋律、生猛的节奏、玩世不恭的黑人英语、自负又自勉的态度、黑黑白白的人间百味，简直像在播放电影 - 仅凭听觉这单一的感官所接受的刺激便可营造出如此丰韵的体验，于工作时间，夫复何求。可知道我究竟在讲些什么？

说到电影，上周看掉了《巴黎危机》（近来也真是再没什么片子可以跑去影院看，能看的几乎已看绝 - 这究竟是国产保护月还是保护年？），还不坏，小格局小故事，无功无过。昨天补了《老炮》，谈不上多好看，一众咋咋呼呼的小白脸儿也不禁让人揣摩片子究竟叫做老炮还是娘炮，只是那京腔京味与北方冬天的景观和气息，以及若干不那么真实的、甚至略为梦幻却又令人动容的情节还是让我触碰到了一些《阳光灿烂的日子》或是《顽主》里的什么东西，一些会闪光的东西，虽然所剩无几，但所幸仍在。

而我分明感到，于自身，近来同样有些什么在潜滋暗长一般的愈合着，复原着。与天台相关，与五毫克中南海香烟相关，与黑羊餐厅或是完成了人生大突破的酒吞相关，与周日傍晚的十九楼跑步机相关，与时不时看着落日温和舒缓的消失在西边的地平线相关。与很多美好而温暖的东西相关。甚至认真的有在考虑要不要打起精神重新拾起已经放下半年有余的iOS开发学习，或是能否投入更多时间更为专注的继续探索VR领域，平日中午要不要跑去鼓教室增加练习，公众号要不要再充实一些相关或不那么相关的内容，等等诸如此类。

当我将自己在坚持做的、一直以来想要去做而未做的、善于去做的、大约有能力学会去做的等等这样一些事情列成一份清单，我分明感到即便生活、生命中切实有太多东西是不可预计或难以抵御的，即便这些东西给身心带来的猛烈或隐抑的痛苦需依赖漫长的年月才可能接纳、适应或对抗，但在力所能及的区域中，同样潜伏着什么东西，一些会闪光的东西，虽然所剩无几，但所幸仍在。

时间怎样飞。之前仅做了两期“传统”UX文章和一篇村上接力书单（包括一周跳票），便已进入九月下旬。一个多月未有VR话题，不妨从本周开始继续。和之前的一篇相同，原文仍来自微软的VR技术布道者Liv Erickson女士，主题是VR项目流程分析，实战经验之谈。此外从本周开始，会尝试在公众号（beforweb）中再增加一些有的没的，例如平日在微博或朋友圈里发布的一些设计相关的闲言碎语或零散的摘译等等；终归是一些更加个人化的内容，与“前言”、“正文”和“彩蛋”一并放出，希望不会过分叨扰。

那，下面进入本周译文。

最近，借着新项目的机会，我（英文原文作者）对过去在Oculus Launchpad项目中的经验进行了总结。在本文中，我来和各位聊一聊我通常会以怎样的方式开始新项目。

正常情况下，我手头会有两到三个项目同时进行。取决于规模与复杂度的差异，我在规划阶段所花费的时间也有所不同。从形成最初的想法，到最终完成demo，我通常会将整个流程划分为以下几个步骤。

规划

刚刚有说到，规划阶段的工作量取决于项目自身的性质。如果打算研究一种新引擎或是开发技术，我甚至会跳过这一阶段，直接上手代码并尽快实现一些东西出来。不过通常情况下，我还是会预先对整个项目的流程框架进行规划。我手头的项目多数来自于类似“我们需要在月底的大会上演示一段五分钟左右的VR demo，有没什么合适的想法？”这样的需求，所以我在创意及技术运用等方面所拥有的自由度还是很高的。通常，我会制作一些不包含任何射击元素的FPS（第一人称射击）类小游戏，譬如让玩家在VR环境中寻找或躲避一些东西，以此积分或记录最长游戏时间等等。

而对于较复杂的项目，我则会在规划阶段将具体的实施步骤及相关细节尽可能详细的描述出来，例如游戏模式、互动元素等等，从而使具体的设计与开发流程更加顺畅。

我在规划阶段通常会采用的具体方法包括：

1.画草图，使自己对想要创建的3D环境产生较为直观的感知。

在小项目中，我会用普通的铅笔在纸上简单画些环境结构和游戏元素；而对于较大的项目，我会在草图中加入多种颜色，使细节更加丰富和直观。无论你想创建机甲风格的科幻场景，还是美轮美奂的童话仙境，事先通过草图大致的描绘出来都能帮你在开发阶段更加轻松高效的选用素材，尤其是当你在使用GitHub一类的云基解决方案的时候。

2.用一句话描述项目的本质

对于比较复杂的项目，要言简意赅的描述出你想做的事情其实并不容易。我时常会不由自主的将太多细节一股脑的端出，不过每一次也都在努力试着通过一句话来言简意明的指出项目的核心所在，例如“用于Oculus Rift的小猫找物游戏”或是“用于Google Cardboard的机甲射击游戏”等等 - 总之是一些很基础性的描述，但可以帮你对项目方向进行清晰而明确的定义，便于接下来进行任务分解。

3.对于复杂的项目：创建一份游戏元素清单

我有时会迷失在各种有趣想法当中，甚至会慢慢背离自己最初的构想。在初期探索时，这还不算太坏，只是一旦发生在实际开发阶段，这种习惯就有可能带来非常严重的问题了。起草一份清单，将组成游戏的各类元素，包括互动对象、行为规则、胜负条件等等按照不同的颗粒度划分为独立的模块，并清晰的列出，根据不同阶段的具体情况而适时更新，让一切保持在可控、可追踪的范围之内。

设计与开发

在这两个阶段里，事情才真正变得有趣起来。对于小项目（三到五天的开发工作量），我会跳过正式的设计环节，直接开始编程工作，当然期间还是会通过草图来明确玩家与游戏元素之间的互动规则。取决于不同的平台，我通常会在两种方式之间进行选择：

1.Cardboard（移动VR）

在移动VR项目中，我一开始就会将平台提供的camera组件放置到场景当中（理论上讲，我或许可以在所有的项目中都采用类似的做法，只是目前对于桌面VR平台，我仍然倾向于在搭建完整个环境之后再放入camera），然后开始创建最基本的环境（如果游戏机制足够简单，我会直接使用现成的素材包），接下来是编写游戏脚本，包括互动规则和控制器组件等等；最后是添加必要的动效和光影效果，然后进行测试。

2.桌面VR

对于桌面VR系统，方式会略为不同。相比于移动VR，桌面系统提供的主角组件通常会复杂很多，所以多数时候我不会从第一人称视角相关的组件出发来开始工作，而是首先打造出环境场景及游戏机制，就像前面提到的那样。我会从最小化的环境创建工作入手，使用最基本的构件来制作最为必要的环境组件，而不是使用大而全的素材包。在此基础上完成脚本编写，然后再回过头来补充和优化环境元素，最后将平台提供的专用camera组件放置进来，完成人机互动机制，然后打磨光影和视效，优化调整，进行测试。