感觉像用go抄了一遍messiah server？

[lasorda]

entity（上述Account，Player都是entity）则可以在space之间进行迁移。entity可以通过EnterSpace调用进入场景，如果这个场景在其他game上，goworld就会将entity的所有属性数据都打包并发送到目标game，然后在目标game上重建这个entity。这个过程对开发者来说是无缝透明的。 同一个space里的所有entity都在同一个game，因此可以直接相互调用。不同space中的entity很可能在不同的game上，因此只能通过rpc相互调用。

goworld在逻辑开发的时候使用一直单线程事件触发的方式进行开发。game只在主线程（单个goroutine）运行游戏逻辑。 因此任何游戏逻辑都不能调用任何堵塞的系统调用（例如time.Sleep）。单线程的逻辑开发可以大幅度简化逻辑代码的复杂度，因为任何逻辑和数据结构都不需要考虑并发和加锁

既然是单线程，go的优势完全发挥不出来

[xiaonanln]

感觉像用go抄了一遍messiah server？

messiah, kbengine, bigworld这些在概念上都类似，除了bigworld之外，其他都是借鉴了bigworld里的概念。

既然是单线程，go的优势完全发挥不出来

如果在多个goroutine跑逻辑，会让写逻辑变得非常困难，得不偿失。单机负载问题可以通过多个Game进程来解决。

[lasorda]

如果在多个goroutine跑逻辑，会让写逻辑变得非常困难，得不偿失。单机负载问题可以通过多个Game进程来解决。

多个Game进程会限制一个Space内最大人数吧

[xiaonanln]

如果在多个goroutine跑逻辑，会让写逻辑变得非常困难，得不偿失。单机负载问题可以通过多个Game进程来解决。

多个Game进程会限制一个Space内最大人数吧

一般游戏都通过其他方式解决这个问题，这些方法估计你都了解。 目前大部分游戏都是用分线方法，一个场景实际上会对应到多个平行的Space。 还有可以把大场景划分为多个区域，每个区域有各自的Space负责计算，这种方式目前goworld并不支持。

[xiaonanln]

goworld确实借鉴了messiah server的部分概念。 不过并不存在“用Go抄了一遍”的情况。例如dispatcher是messiah server里完全没有的概念。