真实语音社交模拟器
1.产品功能 2.列表型社交的缺陷 3.技术架构 4.技术难点 5.未来优化的部分 6.总结
场景模拟：
服务器：新建一个特定场景【xx歌星主题ktv】。场景内可播放歌曲。
用户A【歌迷A】加入。A在场景内可以随意走动。
用户B【歌迷B】加入。B在场景内也可以随意走动。然后B走向A。当AB之间的距离小于一定值时，AB之间可以进行语音通信。
用户A：你觉得这首歌好听吗？
用户B：我是xx歌星多年的粉丝了。
......
用户C: 靠近用户AB。当距离小于一定值时，C可以听到AB的语音信息，并参与交流。
......
用户AB不想C来参与话题。远离C。则C无法再与他们交流。
......
用户A：明晚我们7点再见。
用户B：不见不散。
模拟器提供在自定义场景下，用户彼此靠近来通过语音进行交流。
互联网社交是新时代最为普遍的一种社交模式，主流的社交模式为列表型交流方式，如微信，soul等。在列表交互的基础上，有些产品是带有一些小游戏的社交模式。针对列表型的交互方式有诸多不便。本产品旨在解决以下问题：
无法缩短交往对象之间的距离感。即用户无法确定对方是否有想和自己聊天的意愿。双方都在等待对方先发起聊天。PS:并不是所有男性都敢先跟女性搭话。PPS:不是说我自己。
而在本模拟器中，需要交流的对象必须通过相互靠近所控制的角色来达到目的。以此来模拟真实生活中的交往场景。先彼此靠近然后再进行搭话。
用户无法产生与其交往对象处于同一环境下的心理。比如最经常用的开场白“你在哪里”“你在做什么”等。没有同一环境则很难酝酿共同话题。
在本模拟器中，应创建大量的真实场景。比如【粉丝见面会，舞会，KTV，酒吧，棋牌室】等。不同的场景可以提供不同的功能。比如ktv可以有人唱歌，可以给所有其他用户发送语音而不用靠近对方。粉丝见面会可以让玩家自由布置会场等真实场景。有了一定背景衬托之后，可以使第一次交流更加容易。
交流是人类的最为强大的能力。但是聊天文字式的交流并不能准确传达信息，肢体语言以及声音高低同样是交流的关键部分。
在本模拟器中，如果你不想与某用户交流时，你可以控制自己的角色远离他，从而不接受他的信息。
互联网社交的方式让用户可以在任意时间和任意对象进行交流。但会产生，“你和我聊天的同时，是不是还在和其他好多人聊啊？”这种问题。
本模拟器只能通过缩短与其他用户的距离来发送信息。所以可以解决这一问题。
在有些情况下，用户更倾向于和多个对象进行交流。但是在列表型群聊中，用户并不能直观感受到自己的言论的受众数量。
在本模拟器中，只要你的言论吸引人。周围就会慢慢聚集很多人。可以让用户更有交流的欲望。
1.游戏客户端采用unity3D搭建，脚本语言为C#。服务器采用java语言实现。后端数据存储为mysql。
2.通信以及玩家移动指令的传输协议：grpc ，数据库集成：mybatis。
3.多人游戏同步方案： 帧同步。每一帧用户的移动，动作以及状态都会以指令的形式传递给服务器。服务器接收到所有用户的移动请求后，将所有用户每一帧的指令转发到所有用户的客户端。客户端根据指令来本地计算各用户的动作。由统一的开始状态来执行相同的指令。从而达到帧同步。网络要求比较高，当有一个用户网络较卡时，会使其他人也变卡。但所有人最终状态是时刻一致的。
4.数据传输方案：采用grpc的HTTP2协议长连接来传输数据。因为grpc是基于netty的架构，保有零拷贝的特性。所以用来做服务器相对高效的。而且连接建立后既可以客户端异步传输数据给服务器，服务器也可以主动的传输数据给客户端。虽然没有udp传输速度快，但能保证数据的可靠和开发的效率。
5.实时语音传输方案：采用unity的API进行声音采集。为了更好的空间利用率，采集到的数据被放入一个循环数组。将采集到的数据发送到服务器后，服务器转发给其他客户端。为解决网络传输延迟带来的卡顿问题，声音播放时设置一定大小的缓冲区。实现准实时的语音传输。