※ 引述《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
这样就能够保持原本你要的系统,又同时能符合主管的需求.
你把他想像成你正在重构开发方法从黑箱为命令系统,
而这转译就是过渡时期,重构的是你,当然你要多做点事情.
总之,技术问题是一种自我修练,
不要为了架构问题跟别人吵架,文无第一武无第二.
对有些人来说,有时候
把案子做完,不要出包,今年的年终有领到,
家里的小孩没有需要为了医药费烦恼.已经是一种奢求.
我认为能在两边都顾及的方式把事情做完也是一种需要克服的困难及挑战.
共勉之.