空间句法理论认为，共同在场是指一群互不认识的人，或一群熟人，同时出现在他们共同分享使用的空间。共同在场的人们并不代表一个社区，这只是形成社区的基本必要条件，也许条件成熟之后，今后有可能形成社区。①
本文为译文，原文发表于http://smus.com/copresence-webvr/
Web平台是最能够表现网路共同在场形式(networked copresence)[译注：详见译文参考论文]的。作为演示，我构建了一个能让用户点对点传输音频和数据的多人聊天的原型，以建立一个虚拟音频的体验。每个用户接收到的音频会根据三维位置信息和方向信息，使用Web Audio进行空间化。同时，你可以放大或者缩小你的人物模型，通过改变声音频率来处理你的声音。例如，当你放大了人物模型，你的声音听起来就像一个巨人那样低沉。当缩小时，就会变得非常尖锐！
有土鳖的视频地址： https://youtu.be/FPJDNQJt2DQ
你可以自己来 体验这个demo 。这个demo可以在桌面浏览器上（鼠标操作视角，空格移动）或者手机浏览器上（全屏模式、VR模式）上运行。
开黑更精彩：共同在场的体验是难以抗拒的
生活中最美好的经历通常是在他人的陪伴中度过的，虚拟体验也不例外。我最美好的游戏回忆就是在20多年前，和好朋友们围在一个显示器面前，操作着麋鹿、大象等角色 比赛赛车 ，又或者一起在 文明系列 中制定战略。这种游戏体验并不是太关乎于游戏本身，而更多的是身边的人以及和人一起的体验。
没错，将一个电脑贴到你脸上是能很大程度上增加你的独立游戏体验。但是VR的一个最大的缺点就是更难产生社交体验。想要在VR中实现实际的共同在场还有很多需要面临的挑战。而当你完全沉浸于虚拟世界，你身边实际存在的朋友却显得那么的不相干。在这种约束之下，或许最好的补救措施就是提供网路上的好友，这样也可以很有趣！在PBX上玩 魔兽争霸 ，开黑不？
WebAudio + WebRTC + WebVR = ❤
Web是构建VR共同在场体验的理想平台。VR共同在场需要低延迟的连接，同时也要求一个实时的音频传输。与此同时对于视频内容就不那么着重，因为用户本身就戴着一个头戴显示器，挡住了他们的脸。强大的 Web Audio API 一直为现代浏览器提供服务，它拥有各种处理音频空间化和音频效果的功能。同时，WebRTC 也能够让你在网上获得更多的连接可能性，除了某个浏览器 和在 Service Workers 上的应用。
在经过一些来得及时的 bug修复 之后，现在你可以将远程的 WebRTC 流输入到 Web Audio 的上下文中。这让开发者可以空间化音频流或者对流进行开发者的应用的核心处理方法。举个栗子，上述的作品有几个让我笑出声的特性：
技术细节：荒芜中的 WebRTC
我不太想要去学习 WebRTC 中的纷繁难懂之处，它的API相当底层和难搞。因此我想要找到一个高度抽象的组件。我找到最高人气的组件是 peer.js ，但是这项目好像已经不再继续维护了。而且，这东西依赖于一个特殊的，经常让客户端掉线的Node.js WebSocket服务器。
所以我决定转移到 Firebase，一个在我的实现中能很好地充当信令服务器的项目，能够展现所有当前连接的用户和他们的状态。对于每一个已连接的用户，我保存了他们的昵称（由用户自定义）以及房间ID（如果已经在一个房间里面）。
{
username: 'Your Name',
roomId: 'A Random Room Identifier'
}
鸟瞰 WebRTC
放弃使用 peer.js 之后，我就不能再依赖第三方去处理 WebRTC 中难懂的部分了，我只能自己去深入理解。特别重要的是要理解怎么在不仅仅是点对点的情况下处理多个RTCPeerConnections 。尽管我发现文档十分落后，但是 WebRTC API 的核心部分相当直观：
- 阿祖得到了本地流之后，通过信令服务器发送了offer信息给阿占，这个信息包含了阿祖的本地流的信息。
- 阿占拿到阿祖的offer信息后把阿祖的本地流注册为阿占的远程流。然后阿占可以拿到阿祖的本地流，通过信令服务器发送包含自己的本地信息的应答信息去回应阿祖的offer信息。
- 阿祖得到阿占的应答后会把阿占的本地流注册为阿祖的远程流。在这个时候，阿祖与阿占都能够额达到对方的关于本地流和远程流的基本信息。
- 到这个步骤，阿祖与阿占会交换 ICE（Interactive Connectivity Establishment， 互动式连接建立）的候选信息，计算出建立点对点流的细节信息。最终，双方都得到满意的结果后，阿祖与阿占可以进行通讯了。
希望上面的概要能帮助你理解。我觉得这个概要很有用，因为现在的 WebRTC 文档有点奇葩。大部分的例子都是自己连接自己，根本没法帮助我理解两个clients之间的连接协议。
在互动式连接建立的部分，有超多缩写的术语。STUN（NAT会话穿越应用程序）和 TURN (Traversal Using Relay NAT，允许在TCP或UDP的连线上跨越NAT或防火墙) 在复杂网络拓扑中会出现。 Google 默认提供了一个STUN服务器， 但我最后用了一个 免费 的TURN服务。每一个 RTCPeerConnection 都会在我们用的STUN或者TURN服务器上初始化。
共同在场是VR不可缺少的
由于虚拟现实本身固有的孤立属性，共同在场变得比以前更加重要。共同在场是VR不可缺少的部分，而web正是一个能很好实现这个部分的平台。跟你的朋友 试一试 或者用你自己的两个设备去玩。如果你发现有任何bug请在 github 上报告。
译文参考论文
[1] Hillier, B. (1996, 2007), Space is the Machine: A Configurational Theory of Architecture. Space Syntax: London, UK. pp.141 [2] 童强. 共同在场:从传统到现代〔J〕. 南京工业职业技术学院学报, 2009年03期
