Building Virtual World:

Building Virtual Worlds is the core curriculum in the first semester, "Immersive Semester" in Entertainment Technology Center of Carnegie Mellon University. 

Students choose their professional roles as programmer, artist, sound designer and producer. 

Students are divided into 4-5 people interdisciplinary teams to create immersive virtual worlds in one or two weeks on different platforms. 

Students not only improve their professional skills, but also are trained for communication, collaboration and rapid prototyping.

Pioneered by ETC co-founder Randy Pausch, Building Virtual Worlds (BVW) challenges students to work quickly, creatively and collaboratively. As part of the immersion semester, BVW gives small teams of students two weeks to create a virtual world, with new groups and goals for each round. It all culminates in a public festival to hundreds of spectators – and an incredible sense of accomplishment. In fact, many BVW ideas go on to become full-time research projects, student spin-offs and commercial successes.

World I. Solo World: Cube Dash

Platform: PC                        Engine: Unity3D                  Language: C#            Time: 1 week

Prime work: programming, map & mechanic design, modeling, animation, UI & UX Design

This is the Building Virtual World round 0 project. In this assignment, students build a world on their own without any limitation. 

So I designed the low-poly retro game style of controlling a cube with flexible shape to explore a huge world, and I build a tutorial level introducing map mechanics through a linear game flow. 

In game, player controls a cube rotating and jumping to travel through maps and achieve goals. 

I developed the control interaction of cube and fluent camera motion, also implement map mechanics to improve the game's interest curve.

I used voxel modeling software MagicalVoxel to build models, and create animations in Unity Animation Editor. 

World II. I've Got Your Back

Platform: HTC Vive        Engine: Unity3D                 Language: C#         Time: 2 week

Prime work: programming, map & mechanic design, animation, play test

This is the Building Virtual World round 1 project. In this assignment, guests may help virtual character A from B in the game. 

So we designed a character called Woha, who is going to take his first performance on stage. He is nervous, and afraid that audience will boo at him. Guest will act as his best friend, throw popcorn on those unfriendly audience to stop them. 

In game, guest has a  right hand similar to Woha, and can grab infinite popcorn from a bucket in guest's left hand. Guest can only hit bad audiences when they start booing at Woha to make Woha happy and sing again. If throwing at wrong guest or throwing at a wrong time may cause the audience throw back, which may them booing at Woha instantly after they turn back. 

I developed the throwing model, and implement the game mechanics. I also use Unity animator controller to make animations for properties in scene, including curtain, chairs of audiences and lightning. 

？

这是我们BVW课程的第二轮项目。与第一周在磨合方面花费了大量时间所不同，这一轮我们的时间安排趋于合理，并且不同职责间的分工也变得逐渐明确了起来。我的队友们都有大量的团队工作经验，因此我们很快就确定下了一周的日程，并开始按部就班地执行。

Day1 -  Day2 Brainstorming

由于这一轮的游戏需要我们在满足naive-guest-friendly的同时又具有较高的自由度，因此我们同样寻找了许多具有类似feature的游戏。我们经过讨论，提炼出了他们的一些特点：

· 游戏可以拥有一块巨大的地图，最好没有明确的边际

· 游戏不应该对人物的移动具有限制，而应该用其他的方式去暗示和引导玩家去destination

· 游戏的目标不应该是单一的，要让玩家享受探索的过程

· 游戏应该具有教程部分，且操作应该足够简单

因此我们结合Meta2 的操作特点，在brainstorm过程中提炼出了一些有吸引力的idea。我们在征求了Dave Cuylba和Jesse Schell的意见后，将这些idea中的精华部分进行提炼，并构想出了一个基本的原型。

我们最初的想法之一是想尝试利用很多的立方体组成一块平面地图，并控制一个character像跳格子一样绕过障碍，解开谜题并到达某个地点。基于这个设想，我们对交互方式进行了设计。我们设想提拉其中的一块的同时可以将周围的立方体同样提拉起一段距离，从而形成一种像素化的布料风格的交互方式。因此如果要形成通路，玩家需要考虑到提拉每一块路径时对周围高度的影响，从而让游戏变得更有挑战性。

如果以”形成一条可供specific character“行走的通路作为游戏机制，我们则可以从三方面对玩家进行挑战：形成通路的速度，形成通路的精度，和形成通路的难度。我和组内的另一名程序员Tom对Meta II平台的几种主要交互方式：触碰，旋转，抓握及推拉 进行了测试和对比。利用这几种交互方式的接口，我们制作了利用不同交互方式控制立方体高度的原型。经过数轮playtest的对比，我们公认抓握是最为直观也最易操作的改变立方体高度的交互方式，因此我们决定将游戏的交互方式设置为抓握一种。即使是使用了抓握的交互方式，Meta II对手部动作的识别仍不尽如人意，因此如果在游戏中挑战玩家形成通路的速度，则会因为平台本身的识别问题给玩家造成强烈的挫败感。另一方面，由于无法准确的判定hand release time spot， 我们无法精确的控制通路的高度；‘因此经过对比，我们决定该游戏将更类似于解密游戏，而不是竞速游戏。

因此通过两天对游戏机制的探讨，我们决定将游戏的机制设置为在一片由高度不同的立方体组成的地图上，玩家通过改变立方体的高度形成一条可通行的路径，以帮助游戏中的人物：Mr.purple到达目的地。

Day 3 -Day 7

在Interim之前的几天里，由于很快敲定了游戏机制，我们开始对游戏机制的实现进行研究。

· 如何实现立方体的高度改变

在Meta II的SDK中，手部抓取被设置为一个Trigger型事件。此外，我们也可以实时获取手部与物体发生接触点的坐标位置。因此，我们对算法进行了设计：在手部做出”抓取“动作后，触发手部抓取的事件，并实时获取指尖附近的坐标，直至触发手部的“松开”事件。我们将一个高度为1单位的立方体设置为一个空物体的子物体，并将空物体放置于立方体的底部。如果我们获取指尖的Y轴坐标，并求出立方体底面和指尖的高度差，在每一帧将立方体的高度Scale值实时设置为该值，就实现了利用手部抓握实时控制立方体高度。

· 如何实现寻路

在Meta II的场景内，由于AR对实景多边形的构造算法具有缺陷，大部分场景都需要被缩小到非常小的尺度上以匹配其摄像机设置。因此，在Interim之前我们遇到的主要问题是，我们预设的场景被缩小的过于夸张，以至于通路的半径达不到Unity Navigation Agent所要求的0.1单位的最小值，因此Unity Navemesh 系统无法计算出可行通路。我们查阅了Meta II相关文档，并对之前遇到过相同问题的队伍进行了询问，得到的结果是Meta II不支持更大Scale下的场景，否则会大于Meta II的可操作空间而无法进行交互。

为了解决该硬件问题，我们首先尝试尽可能扩大游戏的场景，例如将场景内的立方体数量减少，并尝试在立方体上利用分形和添加斜面提高游戏的复杂度，但收效不好，因为斜面的高度差仍小于Navemesh的最小单步高度。

另一方面，我们尝试利用等距投射的方法，让玩家的手部控制一个比例较小的地图，并将地图的高低差映射到较大的地图上。此时对大点的地图进行Navemesh烘培，并在该地图上帮助Mr.purple到达目的地。经试验，该方法可以有效解决烘培问题，但对Mr.purple的位置坐标的计算上经常出现偏差，因为Meta II摄像机位置的原因导致地图坐标不在原点，因此对地图的缩放需要进行复杂的运算和调试。由于时间限制，我们也放弃了这个想法。

因此为了在Interim persentation提供一个具有游戏基础机制的Demo，我们选择徒手编写一个简单的寻路算法。我们设定好预先的行进路径，为每个可行走的立方体编写对象，并赋予相应的中心点，起跳点，终点距离等属性。每当Meta II的‘松手’行为被触发，我们对Mr.purple所在的立方体与周围立方体的高度进行判定。每个可以行进的立方体都将下一块可行的立方体存储为对象，若两个cube之间的高度差小于一定值，则判定Mr.purple可以向前进行跳跃/行走/下滑三种动画。

· 如何提拉周边立方体

由于我们想要实现一种像素风的布料效果，因此我们选择在将一个立方体拉伸至A长度时，其周围的9个立方体被拉伸至A/2的高度。一开始，我们尝试为每一个立方体添加范围Collider。在游戏开始时，在Start方法中获取每一个立方体在固定半径内的所有临近立方体，并储存在一个list中。此后若某一立方体被提拉，在每一帧中，其周边的立方体获取该立方体高度，并进行运算以获取其自身高度。

此后，我们发现利用该方法占用的内存过大，因此我们对该方法进行了优化。我们利用Overlapsphere方法，在每次立方体被提拉时，我们调用三个不同半径的Overlapsphere区域，获取其周围三层的立方体对象，并通过取差集将三层的立方体分别存储于三个数组中。在每次cube触发Meta II的’抓取‘行为时，调用该方法获取周围三层立方体，并实时获取高度。

因此在Interim之前，我们推翻了一部分最初设定的游戏机制，在不断的迭代机制的过程中，我们也在寻求更为合理，直观和高自由度的交互方式。

Day 8 - Day 11 Mechanics Re-design

在Interim之后，我们及时获取了对游戏机制的反馈。Jesse Schell在测试我们游戏的过程中，提出该游戏的操作并不够直观。例如如果要提拉边缘的立方体，玩家需要向前走，在真实世界中“穿过”部分地图以触碰到该立方体。而这一流程对大部分naive guest来说无法理解，且在一些视角下，这种提拉操作并不好控制，会给玩家带来较强的挫败感。

针对这一反馈，我们对游戏机制进行了重新思考，并在有限的时间内推翻了交互方式。首先，我们收到了一条反馈，其中建议我们使用六边形作为地图的最小元素。我们立刻采纳了该建议，因为正六边形不仅具有双心性，可以完美铺满一个平面，且六边形意味着每个可供行走的点位都有六个可供选择的下个点位，可以在不提高游戏难度的情况下有效提高游戏的复杂度。因此我们很快利用六边形重构了一个大小近似的地图，并根据玩家的视觉角度将地图设计为坡度型，以便玩家的抓握操作。

此外，由于收到的大量Peer Feedback中不建议我们允许玩家穿越建模，因此我们考虑用另一种交互方式，让玩家可以站在某一固定位置，就能控制到地图上的所有六边形。因此我们首先尝试只有一部分固定多边形可以移动，玩家可以利用一个悬浮于地图上方的handle控制该六边形及周围六边形。

我们在完成该原型后进行了play test。根据反馈，这种交互方式尽管避免了玩家穿过地图，但同样不够直观，大量用户反馈不知道handle和对应六边形间的关系。因此我们尝试用不同的信息来标注六边形和handle，例如颜色，六边形上的装饰和贴图。经过对比，我们认为颜色可以足够直观的表达六边形和handle之间的关系，因此我们选择将地图上的某几个六边形添加颜色，并利用对应颜色的handle控制不同颜色区域的六边形高度。

此时我们发现，如果地图上只有部分六边形可以进行拉拽操作，其周围六边形的高度会因为无法取整，而造成部分相邻六边形永远无法达到相同高度的问题。此时我们征求了guests的意见，决定将handle对特定颜色六边形的控制延伸到整个地图。不同于之前只有几块六边形具有颜色，我们选择将为所有六边形添加颜色。此外，我们选择让handle控制同样颜色的所有六边形改变同样的高度，而不是初始原型中改变某一六边形而对周围地形进行小范围提拉的效果。此外，我们重新将地图内六边形的高度进行设计，让地图呈现出类似于丘陵般的参差效果。

此时，游戏和interim persentation时截然不同，但却已经具有一个solid的structure了。我们需要利用剩下的三天对游戏进行playtest和iteration。

Day 12 - Day 14 Playtest & Iteration

在拥有了Solid Structure后，我们开始寻找Naive Guests对我们的游戏进行测试。由于该轮项目要求我们在Guests完成游戏体验后为他们提出三个关于游戏内体验的问题，因此我们决定将三个问题结合进一份游戏调查问卷内。我选取了游戏流程中几个较难理解的点，询问guests理解所花费的时间和实践难度。此外，我们也想了解游戏内的信息反馈是否直观，以及Guests眼中的游戏难度和完成游戏后的成就感，因此我们让Guests为这几项进行1-10分的打分。

在第一轮Playtests中，我们邀请了很多熟悉Meta II操作的Guests，例如一起进行Meta II项目开发的同学。他们第一轮对游戏的反馈并不满意，例如大部分玩家对操作手感不是非常满意。即使游戏内Mr.purple可以上跳/下滑一定距离，但是由于六边形的高度均不是整数且根据玩家的手部位置实时变化，因此想在一个特定的狭小区间内松手以构成通路是一件很困难，且挫败感很强的事。

为此，我们决定将六边形的高度从连续值域变为离散值。之前我们将六边形父对象的Scale值设置为0-4的连续值，在接收到playtest的反馈后，我们将该值域变为10个离散值，分别为0.4, 0.8...直到4.0。而对应的，Handle具有10个高度，对应的六边形高度也为10个对应值。此外，我们也为不同的高度提拉时Handle的音效加入了不同的音调，这样玩家可以获取另一层对handle高度的反馈，也为游戏的音效系统添加了多样性。

在修改完这一点后，我们进行了第二轮Playtest。这一轮玩家们对游戏操控性的接受度变高了，但对游戏难度和直观性的不良反馈仍然存在，例如大部分玩家花费了很长时间才理解游戏机制，特别是游戏内Mr.purple可以向上跳/向下滑的机制。

为此，我们尝试加入平面化UI以提示某一块六边形是否成为通路。我们最初尝试在六边形的顶面加入提示下一块六边形的箭头，并且在通路被联通时闪烁。在后来的测试中，我们觉得这种UI形式不够美观，因此我们尝试直接在每一块六边形表面加入道路模型。在六边形的侧面，我们为每一个通路口留出一格的高度，因此在玩家改变六边形高度时，可以通过观察六边形的侧面以获得通路是否联通。

此后，我们在接下来的几轮Playtest中不断收获反馈，并对造成Guests们理解困难的地方进行改进。

例如我们将整体通路分为三段，这样第一段作为只需要玩家操作一次的简单通路可以作为教程，以让玩家了解基本操作。后两段逐渐提高难度，以为玩家不断形成挑战。

例如我们为Mr.purple的头顶添加了一个Billboard形式的Bubble，在通路联通前持续存在。Bubble内有简笔画标识的target，为Guests提示通路的目标位置。

例如我们为地图上端加入了布景物体，不仅美化了地图，强化了地图的艺术theme，也为Guests规划出了唯一一条通路。

我们在最后的三天中不断打磨游戏的细节，为游戏加入环绕性的背景音效，不断地调节地图颜色和Mr.purple的移动速度。我们不断地进行playtest，并改进细节以让游戏变得更加naive guest friendly。

项目收获

这是我第二个BVW的项目，相比于第一轮的匆忙，这一轮我们对时间管理方面有了更多的经验，因此我们项目的完成度也更高。这是我第一次在AR平台进行游戏开发，尽管Meta II作为一个不甚成熟的平台仍具有许多的缺陷，但在开发流程中我们对SDK的掌握和对交互方式进行探索的经验也非常珍贵。这一轮要求我们的游戏具有Naive Guest Friendly的feature，因此我们学会从Guest的角度对游戏机制进行思考，并通过Playtest这种高效的反馈方式对游戏进行不断地迭代。BVW这门课程一直在利用这样的方式为我们传递游戏开发中最关键的内容，而每一轮学到的知识和经验都在接下来的每一轮中发挥了巨大的作用。

这是我们BVW课程的第三轮项目。由于该轮的目标是让我们在短短一周时间内完成一款足够好玩的游戏，因此一个好的创意在游戏的开发流程中占有了很大比例的时间。

Day1 - Day 2 Brainstorm

这一轮，我们可以使用的平台包括Kinect，Leap Motion和Phidgets。其中Phidgets侧重于可交互的实体按键， Leap Motion侧重于利用红外摄像头捕捉手部动作，而Kinect则偏向于捕捉整个人体的动作。我们在第一次开会时，我们都表露出了对Kinect平台的兴趣。我们每个人都有过在Wii U，Xbox 360等平台进行体感游戏的经验，而且觉得调动玩家全身的运动可以让游戏变得更加有趣。因此经过一番简单的讨论，我们确定了使用Kinect作为游戏平台，并且开始寻找体感游戏中基于“好玩”而建立的游戏机制。

经过一天的头脑风暴，我们在第二天的会议上达成了几点共识：

· 玩家最容易控制的关节点是手部，脚部和肩部，因此应该主要利用这几个关节点为玩家提供挑战。

· Kinect支持多人同时游戏，而最佳人数可以控制在2人，因此无论是竞争机制还是合作机制都具有迭代的potential。

· 由于Kinect的检测空间有限，因此玩家的移动范围应该控制在2M宽度的矩形内，而且对关节的判定不要过于复杂，因为Kinect的空间精确度不高，且几乎没有纵深检测。

因此我们对BrainStorm出的idea进行了筛选，其中最有吸引力的Idea是一个由2位玩家手中的Paddle互相击球的游戏。该游戏的灵感来自于第一个电子游戏：PONG，其中两名玩家各控制一个可以垂直移动的竖板，在2D平面上进行模拟乒乓球的游戏，接不住球的玩家则会输掉比赛。

而Kinect的游戏空间同样近似为2D平面，且利用玩家双手模拟接球的交互方式既有趣又简单。因此我们经过短暂讨论，基于该交互方式设计出了一个原型：在一个封闭空间内，两名玩家的双手控制一个平板的两端，该平板可进行伸缩，玩家可以用该平板击打一个bouncy的ball，ball同样可以与封闭空间的边缘进行物理碰撞，其余游戏机制待定。

而我和另一名程序员，Calla Carter对原型的开发进行了分工。我们首先一起阅读了Kinect的SDK，并对Kinect官方提供的Unity Demo进行了尝试。我们发现，我们可以获取每一帧中每个Kinect捕捉到的关节点的位置和朝向信息。因此Calla Carter负责在Unity场景内保证Kinect的摄像头可以同时探测到两名玩家的手部，我负责将对双手的位置进行运算，以保证平板的位置和长度流畅地受玩家手部的控制。

因此，我将平板设置为一个可以伸缩的Cube对象，并在每一帧设定它的位置，旋转和缩放值。

因此我首先将两只手的位置存为Xa， Ya， Za，以及Xb，Yb，Zb。

· 如何设定平板的位置

再将一个Cube设为一个空对象的子物体，并将该空对象置于Cube的一端。此时Cube的位置和Scale由空对象决定。在每一帧，我们获取两只手的位置XYZ值，并取中值为Xm，Ym，Zm。我们在Update方法中设定Cube的位置为（Xm,Ym,Zm）。

· 如何设定平板的旋转

我将空对象的位置设置为永远与左手重合，并令该对象永远遵守Unity自带的LookAt方法，其LookAt对象为玩家右手的坐标。此时，Cube永远从左手朝向右手的位置，并永远位于两只手的中央位置。

· 如何设定平板的Scale

由于Unity中的Scale不具有计量单位，因此想利用双手间距离直接换算成平半的长度并不可行。为此，我尝试利用媒介计量单位进行换算。首先，我决定将初始两手间距设为单位长度。因此在Start方法中，利用Vector3.Distance方法获取第一帧的双手间距离，并存储为单位距离。此外，在Start方法中获取Cube父物体的Scale（X，Y，Z）值。之后每一帧获取两手间距离，并获取该距离和单位长度间的倍数关系。之后每一帧将父物体的Scale乘以该倍数关系即可。

此时，Cube会准确的检测到玩家的双手，并可以随着玩家双手的运动进行伸缩和移动。