---

前面幾位大大已經很詳細的解釋何謂政治問題與解決方法，

所以我覺得有必要稍微來討論一下技術問題，

先自我介紹一下，我之前曾經跟幾位好夥伴一起搞過個雲端運算+遊戲的平台，

詳細可以參考 http://kami-gami.jp/
(這個是2012年的成果，該專案已死)

正好我是負責製作遊戲引擎、遊戲腳本、運算實體跟協作負載平衡的人，

自認為有點資格稍微提供一些淺見(也只有一些淺見XD)

以下假設你們是用 C 或 JAVA 土炮一個遊戲伺服器出來。

※ 引述《tommady (tommady)》之銘言：
: 我是原po, 先感謝各位前輩的指教和建議,
: 小弟覺得還是畫圖來解釋可能比較清楚.
: 我主管的想法: thought1
: https://goo.gl/fz9ktO

這張圖有幾個問題



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 而已，
(而且還不支援使用者腳本)

先把東西弄出來再說吧，沒必要為它吵架。

--
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.193.10.222
※ 文章代碼(AID): #1O0swFL0 (Soft_Job)
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1476619919.A.540.html