※ 引述《tommady (tommady)》之銘言：
: 争議點在command handle，
: 我原本期待的是game server收到任何
: client傳來的命令，只需要by pass給這interface就好，
: 這個interface會自行處理。
: 但是主管堅持，他只提供client命令的讀寫 ，
: 其餘的遊戲邏輯搞定。
: 也就是他只管server client之間溝通的library。
: 這樣變成我的遊戲邏輯得處理命令的接收，
: 邏輯得fork一個thread去聽有無命令進入，
: 而不是定義該怎麼處理命令，
: 然而這樣會讓未來每款遊戲都需要重覆的處理命令。
: 怎麼想都覺得這樣十分鬼異，
: 我說，
: 我想要的是只需要填肉，骨幹可以通用的架構。
你的架構是data driven的一種.
理想上 應可以彈性同時支援 你自己的需求 以及 你主管的需求 , 才是好設計.
你執著在於要給data的人照你的方式給,就失去合作跟分工的意義了.
我以往實作幾次類似的系統, 我把這邊的Data叫做Command.
我想像成這樣的事情是將 Client Game Logic 原本是大量黑箱的情形
"解放" 將控制權拆給 給Command的人. 讓Client變成一個Command播放機.
Client詢問 -> Server回覆可能不同的Command(s) -> Client 播放Command
但是為了要把Command的類型定義的詳細有彈性.
Server的Command內容最好是懂Client的人一起做,(我當時是主程式S/C一把抓)
避免Server背景的人比較沒有Client運作概念,
所以不知道Client需要甚麼,想像起來比較抽象.
打比方說 當戰鬥開局,對Server請求戰鬥結果,同時要播放戰鬥後特效時
你的想法比較接近
Server 回覆
Command_UI_VictoryFadeIn (介面進場)
Command_Effect_VictoryExplosion (煙火特效)
Command_Audio_Victory (勝利音效)
你主管的想法比較接近
Server 回覆
Command_Victory (勝利)
接著Client 就應該知道要播放介面,特效,音效
後者的想法並沒有特別不好,
其實兩者都能夠達到規格目的,
因為從某個角度來說Client的規格,對Server來說就是一個黑箱.
所以你Client的責任就是把這個黑箱作好, Server可以不想知道這黑箱的內容.
如我一開始所說,你的架構裡應能支應兩種不同的角度(才是好架構)
你應該換個角度來看當Server回覆 Command_Victory 的時候
其實 Command_Victory 的運作內容 可以是由Client轉譯為播放:
Command_UI_VictoryFadeIn
Command_Effect_VictoryExplosion
Command_Audio_Victory
這樣就能夠保持原本你要的系統,又同時能符合主管的需求.
你把他想像成你正在重構開發方法從黑箱為命令系統,
而這轉譯就是過渡時期,重構的是你,當然你要多做點事情.
總之,技術問題是一種自我修練,
不要為了架構問題跟別人吵架,文無第一武無第二.
對有些人來說,有時候
把案子做完,不要出包,今年的年終有領到,
家裡的小孩沒有需要為了醫藥費煩惱.已經是一種奢求.
我認為能在兩邊都顧及的方式把事情做完也是一種需要克服的困難及挑戰.
共勉之.