前面幾位大大已經很詳細的解釋何謂政治問題與解決方法，
所以我覺得有必要稍微來討論一下技術問題，
先自我介紹一下，我之前曾經跟幾位好夥伴一起搞過個雲端運算+遊戲的平台，
詳細可以參考 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 而已，
(而且還不支援使用者腳本)
先把東西弄出來再說吧，沒必要為它吵架。