※ 引述《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