我的建议是分的，一个系统盘，一个其他盘

假如机器是你用，系统是你装，你还会备份，甚至还会用 PE ，那分不分也就看你习惯，因为备份、找回数据大概你也懂

如果是不懂的人，强烈建议是要分的。不然他把机器拿出去给人修一下，重装了系统，你觉得修电脑的人会给你留个 windows.old 吗？顶多重装的时候让你备份一下数据，这时候不分区还备份得过来吗

至于利用率的问题，我很少遇到还硬盘用得差不多满还不加硬盘的

@willx12123 为啥要同步工程代码？我都是直接把 win 下的目录共享到 VirtualBox （ VMware 也有类似的功能）里的虚拟机，在里面可以直接用这个目录

一般都不会有问题。极少数情况不兼容，比如解压 tar.gz 的包里要创建软链接，或者 coredump 无法在这个目录创建，但很少遇到或者或者绕过

不懂 go ，但那段 C++的代码，你得保证 header 那个结构体是 POD 数据类型，然后去掉对齐，再写入。那这样写入的就是结构体里的各个字段的值，和手动把各个字段的值取出来再写进文件是一样的。

大小端这个有处理了那就不说了

这样其他程序读出来应该是没问题的，我们的协议有些就是这么发，对方不是 C++

@JimmyLX 啥游戏公司，这在游戏行业算很不错了

@litujin1123 西二巷那边，如果你是刚搬过去的那肯定不是同一栋。这是房东个人自己要改造，不是大片区域的搬

@MiCMiC 不是，在东圃明珠新村这块

@wolfie 这边的合同，一般是租客提前退租要赔，房东是不会赔的。要不然一开始他就不会租给你，因为所有房东都这样操作，只有小部分公寓会赔

@EliStone 你下班早，我 9 点算正常下班

@mortal 就在车陂南这边，去黄埔租的话有点远，去那边买有点贵，暂时没发现合适的

@murmur 能给一下大概位置、面积、总价来参考一下么。在 app 上看海珠没啥上车的可能

@darknoll 租的时间短东西就不多。我刚毕业的时候，就一个背包一个行李箱。但现在有自己的台式电脑，划船机，桌椅什么的，搬家不请人自己搞不定

@leavic 一天要花 3 个小时在路上，这个真不太好。而且现在是 995 ，晚上回去都比较晚了。遇到加班，打车有时候人家都不愿意去

@lakehylia 广州是有便宜的房子。但是番禺市桥那边到天河也得 1 个多小时。另外广州的工资也低，如果位置好，买得起，房子早就被买走了

@Leonard 租到合适的，我都没主动搬过，这不是被赶了好几次么

@Jeyfang 新塘到车陂南这边，因为下地铁后两边都要走一小段路

@mrhhsg 买房的话整栋楼被改造的概率比较小，即使改造，也不会像租房一样直接在半个月内被赶出来

@Lancer777 我一般不和别人合租，小区极少有合适的

@233373 一般是会退的。但是房东往往会多算一点。我上次被赶出来那房东水电就是比我算的要多，搞不懂他怎么算的

```
因为 luacluster 已经成为了事实上的技术标杆。
只要你想研究无缝大地图和万人同屏甚至游戏服务器就绕不开 luacluster
```
楼主实在狂得可以，不去拉投资实在可惜。做技术讲究的是脚踏实地，你犯了这个大忌，难免在论坛里被人锤。

“成为事实上的标杆”要有事实，是哪个游戏用 luacluster 实现，并且成为标杆了？？我倒是没听过
“无缝大地图”之前就有人在做了的，网易、腾讯的一些网游都有，当然除非你觉得他们的地图不够大
“万人同屏”这个需求最大的限制是客户端而不是服务器，服务器其实只有 aoi 这一模块有压力而已

摘取自 https://www.v2ex.com/t/847585?msclkid=c2b79945bef311eca9160fa12532cb75 的一些信息：

```
这样我们就实现了一个非常惊人和高效的异步通信系统。任意进程和线程中的对象通信只要最多 2 步就可以完成。找到 upd 端口发过去，找到线程队列发过去。在任意环境下只要拿到 entity id 就可以快速知道封包的目的地。实现在分布式网络内的任何对象之间像普通函数调用一样的调用。什么网络编程，什么多线编程可以统统见鬼去了。
```
事实上我们公司的 rpc 调用早就可以实现根据玩家 id 唯一直接异步调用，也可以根据服务器 id 异步调用，还能根据 lua 函数函数指针直接调用，比你这个方便多了，这个可以提高开发效率，但对运行效率有个毛用。游戏行业各家都有自己封装的 rpc ，没什么大惊小怪的


```
万人同屏顾名思义要做服务器上处理 1 万个玩家的位置同步问题。1 万个玩家的位置同步每次要产生 1 亿个消息。1 万乘 1 万产生 1 亿个消息。请记住 1 亿这个数字后面我们要反复提及到。

首先我们先分析 1 亿个消息的产生流程。服务器会收到 1 万个客户端发起移动的请求。1 万个请求是没有问题的，现在服务器处理 10 万个链接问题都不大。所以这 1 万个请求一般的服务器压力都不大。问题是这 1 万个请求，每个请求要产生 1 万个新的请求发送给其他的玩家。这样服务器就扛不住了。一下产生了 1 个亿的 io 需求，哪种消息队列都扛不住，直接 mutex 就锁死了。

所以我使用了 CreateMsgList 接口创建了一个消息 list 。哪么 io 请求就转变为插入 1 万个 list 的操作。然后将这个 list 和消息队列合并在一起。这样就 1 亿个 io 请求变为 1 万个 io 请求，io 请求一下就压缩了 1 万倍。同样的道理我们也可以把发送给给客户端的封包进行压缩。处理 1 亿个封包请求很难但处理 1 万个封包难度就低很多了。下面是封包压缩的部分代码
```
我寻思楼主是不是没做过游戏，甚至之前没做过底层。我见过的游戏服务器，哪个没有个 buffer ，所有发送的 io 都是缓冲成二进制流发出去，怎么就产生了 1 个亿的 io 。另外在游戏中请慎用压缩，游戏和 web 不一样的地方是通信频繁，但数据量小，一个攻击包、移动数据包才几个字节，启用压缩会导致客户端解包压力比较大。现在流量不值钱，还不如直接发送


```
我们要把玩家的移动描述成一段时间的状态。有位置，方向，速度，开始时间，停止时间的完整状态。这样在每个客户端就可以根据这些信息，推断出玩家移动的正确状态
```
这个，我都不知道要怎么说了。需要做在场景里移动的游戏，哪个不是这么做的？难道楼主之前做游戏是定时持续发送玩家的状态？ 而不是有变化才发？


要实现万人同屏的核心：比如如何减少 aoi 事件，用哪种 aoi 更优。客户端如何支持这么大的量还能不发热，如何渲染这么多实体，视角切换如何才能避免渲染看不见的实体，这些东西完全没提到