※ 引述《LaPass (LaPass)》之铭言： : 打算用websocket在网页上写个对弈游戏 : 例如黑白棋、五子棋、围棋等等 : 目前已经将websocket的连线转接过 : 所以可以不用管那些技术细节 : 现在我在做的是对奕室的SERVER部份 : 就是，两人轮流子，以及把棋盘的结果传输给观众的部份 : 里面有 : 1.一群观众 : 2.玩家（a） （要考虑网页视窗多开的可能性，因为应该会有人这样干） : 3.玩家（b） : 流程是这样： : 1.轮到玩家(a)下棋，通知玩家a进入落子模式 : 2.等候玩家(a) : 3.当任何一个玩家(a)的连线收到落子讯号时，忽略其他玩家（a）连线的落子 : 并关闭玩家(a)的落子模式 : 4.通知所有使用者（玩家a、玩家b、观众）棋盘上多了颗旗子 : 5.判断胜负，如果出现胜负就切换到游戏结束的流程 : 6.轮到玩家（b）落子，以下略 : 因为没看过别人关於这部份的设计 : 也不知道该用什麽关键字去找这样的范例或设计模式 : 自己想了两个.... : 一是依照一般的游戏流程，分成update()跟draw()两部份 : 由更上层的执行序控制的逻辑，去定时呼叫计算跟绘图两部份 : 一般游戏的是60fps，不过如果是对弈类的，应该300毫秒就很即时了 : 但是 ，这样可能会让程式变得很复杂 : 理由是每次执行到update()时，他都要去判断现在的流程到哪个地方 : 然後在决定要作什麽事情这样 看不懂这方案是啥 你不是C/S的程式吗? 为啥会需要draw? : 二是专门开一条执行序去跑游戏逻辑的loop : 如果跑到要等待的地方就把他blok在那边 : 这样程式会比较好写 : 但是我觉得这方法可能会有个问题就是..... : 万一有一千个人在下棋，就有一千个游戏室 : 那不就意味着有一千条执行序在跑？ : 我没写过什麽太大的、一堆人同时在线的程式 : 不知道这样写会不会有什麽问题..... 这是很正常的写法 至於大量Thread倒是不用太担心 Jetty就很多Thread堆出来的 : 所以想请问 : 一般游戏SERVER是怎麽处理这种游戏逻辑的？ 这边才是真正回答XD 方法二才算合理的方法 不过你只是对亦 并不需要大量及时的资料交换 开了一堆Thread其实也浪费 看你这边... 说实在不知你Server端怎生的XDD 不过你用WebSocket应该是捡现成的 (手刻的话... 建议改用现成的) 而这部份自然是event driven的设计模式 (真要手刻也请改event driven 不然... 还是数不完的Thread XDD) 所以你这边最适合的作法就是每个棋局都用一个obj来管理 而每个WS连线只要知道该用哪个obj 剩下就看收到啥内容去呼叫obj内对应的方法 而obj内自然就塞了棋盘 谁下 使用这obj的连线 等... 主要也就一个下旗的方法 先做逻辑判断 如果不是该下棋的人就直接回 再来检查下的位置合法性 是否有输赢或旗子吃掉之类的 最後在把这颗旗子的资讯传给每个使用这obj连线 (这边就直接解决了多开 然後客户端下子只送WS 不显示棋) (等这边确认完会送出以下子的讯息 这时再显示 也就是跟其他人一样处理法) 然後在一个回传目前棋盘的方法 给新加入的观众客户端显示用的 上面基本Server端就写完啦XD 至於可能还是会好奇Thread到底怎配XDD 说真的这部分是WS Server要做的 不是搞App要在意的部分 一般WS Server大概就用java的non-blocking socket实作 然後固定跑上几个Thread负责处理新入的request request基本确认完(验证 SSL初始化之类的) 就另外开个Thread来实际处理request 总之用event driven去设计 因为对弈类的游戏本来就是玩家动了才有事做 而既然用event driven去设计 其实thread就不大跟自己有关了XD 不过处理资料时可能还是要注意下thread safe的问题 毕竟不像NodeJS单一Thread处理全部request XDD --

※ 发信站: 批踢踢实业坊(ptt.cc) ◆ From: 140.115.216.102