前面几位大大已经很详细的解释何谓政治问题与解决方法，
所以我觉得有必要稍微来讨论一下技术问题，
先自我介绍一下，我之前曾经跟几位好伙伴一起搞过个云端运算+游戏的平台，
详细可以参考 http://kami-gami.jp/
(这个是2012年的成果，该专案已死)
正好我是负责制作游戏引擎、游戏脚本、运算实体跟协作负载平衡的人，
自认为有点资格稍微提供一些浅见(也只有一些浅见XD)
以下假设你们是用 C 或 JAVA 土炮一个游戏服务器出来。
※ 引述《tommady (tommady)》之铭言：
: 我是原po, 先感谢各位前辈的指教和建议,
: 小弟觉得还是画图来解释可能比较清楚.
: 我主管的想法: thought1
: https://goo.gl/fz9ktO
这张图有几个问题
1. server 部分的绪配置不太合理。我不太懂为什么要拆成三个绪来做，你可以参考传统
服务器的结构，理论上会有一个主绪+多个子绪。主绪负责管理整个process的事情，
子绪负责其他所有事务。通常每个子绪都完全相同没有差别。
2. game logic 端的事情其实一个绪也办的到，请参考 libev、select、epoll
3. 我看不到资料是如何回传的，这其实很影响设计。
上面三个问题，可能表示你对整体架构还不够了解，你应该多去了解一下。最起码 game
server 的部分要画的完整些，不然也只能用猜的。
: 我的想法: thought2
: https://goo.gl/3dFlLi
前一张图有的问题，这边也有，另外还多了几个缺点
4. 我看不到 game server 如何将 command 传递给 game script，这部分据你所说，应该
是你跟你主管最主要的歧异。这边不画清楚的话，有画跟没画一样喔XD
5. 假设 command 是 follow 在 start 之后一起传递，那等于说：
‘你每次要处理 command 的时候都一定要先 wait start’
‘你的 game script 的 process 没有 sleep 的能力’
如果你 game script 的 process 启动时要读取各种资料，会额外多花很多时间。
(一般会从资料中心读取一些使用者资料、购买资讯、游玩纪录等)
: 其中,
: thought1的game logic thread1 处理命令,
: thought2的command handle,
: 都是同一个function,
: 只是由哪一个地方执行, 而有了争议.
: 小弟以为, 按照我的想法, 可以减少重复的"听"这个动作,
: 也减少不必要的IPC传送, 还有一堆的Mutex.
: 还请各位指教指点.
: 感谢.
你应该再多去了解一下整体设计，很多时候不需要急，让时间证明一切。
以上是一些个人浅见，完全没有谈论到 response time 、 memory usage 、 scalable
因为你们的专案离这些细节还差太远，只是一个最基本的 game engine 而已，
(而且还不支援使用者脚本)
先把东西弄出来再说吧，没必要为它吵架。