→ bnn: 廣告文(X 03/07 23:05
推 emptie: 原來是書商（誤 03/07 23:06
推 prismwu: 妳要用先講結論當作第一句 03/07 23:07
推 ayubabbit: 原來是業配(X 03/07 23:08
推 kungfutofu: 好喔 來買書 03/07 23:09
推 SilentRain24: 身為寫扣人士這篇我推 03/07 23:13
推 seaEPC: Design Patterns跟Data structure確實很重要 03/07 23:14
→ seaEPC: 不過最可怕的是接他人的code然後發現裡面滿滿return A+B; 03/07 23:15
推 LiNcUtT: 感謝解惑~ 03/07 23:22
→ SPDY: 推專業清晰的講解 03/07 23:25
推 zseineo: 猝不及防的葉配XDDDD 03/07 23:26
推 guogu: 可是合成那種就不需要大量重複的運算，那邊用rand就沒差？ 03/07 23:27
當然這不是絕對的，看情況簡單CALL個RAND()也行，
但是如果牽涉到網路、多人遊戲、REPLAY、SAVE等問題，就算無關效能問題，
你大部分的情況還是得乖乖使用亂數表。
再來還有一個很基本的問題，對於正常玩家，我使用即時運算跟亂數表，有甚麼區別?
就像如果你是使用遊戲引擎內建的腳本語言的rand()來寫遊戲的話，
那實作上絕大部分都是基於亂數表的亂數產生器，
或是該引擎其實會提供不同的亂數產生器
，只是你不知道，但也不太需要知道，因為這些老問題引擎開發商早就幫你解決了。
→ zseineo: 防玩家SL也不一定是替玩家著想啦，有時候玩家會選擇不好 03/07 23:27
※ 編輯: extemjin (61.230.200.156), 03/07/2018 23:41:07
→ zseineo: 玩但簡單無腦的玩法（某些SL），不過這又跟其他設計方面 03/07 23:28
→ zseineo: 又關就是了 03/07 23:28
推 arrenwu: 你說的情況 只要運算都在伺服器就可以不用亂數表了吧？ 03/07 23:29
→ zseineo: *有關 03/07 23:29
→ arrenwu: 我以為本地端主要管的是rendering 03/07 23:29
→ aaaaajack: 有點疑惑，照理說這些東西都以server算的為主吧 03/07 23:30
一個簡單的反問，那如果是單純的區網遊戲呢?
線上遊戲絕大部分的情況SERVER大多情況一般來說只做DATA紀錄、玩家分發、
以及驗證等等基本的動作而已，光是做些動作就已經夠操SERVER了。
當然例如抽卡轉蛋這種需要比較高安全性的大多會在SERVER，
主要是沒這麼即時情況或遊戲，最重要往往牽涉到交易，要比較高安全性
，所以放在SERVER端運算。
但是大部分網路需求較高的動作遊戲進行中，SERVER甚至不會時時都保持連線的，
可能固定時間或是有向SERVER發送要求，才會來驗證一些資料。
※ 編輯: extemjin (61.230.200.156), 03/08/2018 00:08:32
→ aaaaajack: 沒事，大概懂了 03/07 23:42
推 sdd5426: 簡單來說寫的程式碼要有sense 不能像學生那樣什麼都用最 03/07 23:45
→ sdd5426: 簡單的想法 03/07 23:45
→ aaaaajack: 不過這篇講的是同步的問題，但原po問單機遊戲... 03/07 23:49
推 sdd5426: 他有提到啊 使用函數不好實作replay等 03/07 23:53
→ linzero: replay直接把所有得到的亂數存起來不就好了？ 03/08 00:00
→ aaaaajack: 那段我覺得他在亂講，rand沒這問題... 03/08 00:02
→ know12345: 猝不及防賣書XDDD 03/08 00:03
→ LiNcUtT: 實作上絕大部分都是基於亂數表的亂數產生器 < 這不對吧 03/08 00:04
推 holymars: 實作上都是deterministic的PRNG演算法..然後讓generator 03/08 00:05
→ holymars: 同步.... 03/08 00:05
→ aaaaajack: 或者說rand跟亂數表根本是一樣的吧 03/08 00:05
是啊，就邏輯上來說是一樣的
→ LiNcUtT: 絕大部分的亂數產生器都是算出來的,不是查表啦 03/08 00:05
→ holymars: 會寫成先骰好一張表再整張sync，應該是對PRNG有所誤解 03/08 00:06
→ holymars: 平白浪費流量在傳無用資訊 同樣的演算法下你傳10000個值 03/08 00:06
我基本上就是說這個
→ seaEPC: 會出現不同結果我覺得比較像撞到multi-thread執行順序問題 03/08 00:06
→ holymars: 和傳一個值，在deterministic的PRNG算法下結果完全一樣 03/08 00:06
→ holymars: 不是 PRNG最常踩到的陷阱是硬體和lib的實作問題... 03/08 00:07
→ LiNcUtT: h大說的比較有道理 03/08 00:07
→ holymars: 你「以為」演算法一樣，實際上要保證不同平臺不同硬體的 03/08 00:07
→ holymars: PRNG演算法跑出一模一樣的結果，通常踩到雷都是這個 03/08 00:08
→ holymars: 至於保證rand()呼叫的順序和次數是相同的，這是另一個問 03/08 00:09
→ seaEPC: 看reply指的是哪種囉,我指的是像在同個條件/輸入下重跑 03/08 00:09
→ holymars: 題，不管你有沒有隨機因素，event發生的次數和順序本來 03/08 00:09
→ holymars: 就要保證是同步且正確的.. 03/08 00:10
→ seaEPC: 所以沒寫好的情況下就會出包啊 工作上還真遇過... 03/08 00:11
推 holymars: 同步沒寫好，應該不止有隨機的部份會出包，是全部都會出 03/08 00:13
→ holymars: 包才對... 03/08 00:13
沒錯
※ 編輯: extemjin (61.230.200.156), 03/08/2018 00:21:37
→ seaEPC: 我們那邊是收前端資料解碼後丟去DB更新,基本上多個threads 03/08 00:25
→ seaEPC: 分別處理自己所屬資料,是不用管誰必須先做的 03/08 00:26
推 Logan2934: 神奇寶貝 MHW 本來都是卡匣遊戲，可能整個遊戲就只要 03/08 03:16
→ Logan2934: 骰0～9，為了省空間以及加速，就自製了個很簡化的rand 03/08 03:16
→ Logan2934: ()，結果就一路繼承到現在 03/08 03:16
推 Neil000: 書商推 03/08 07:58
推 yshinri: 同樣是表, 寫程式時先建好表跟實際執行時先求一萬個亂數 03/08 08:45
→ yshinri: cache 成表還是有差, 你在講的表多半是後者這種 03/08 08:45
→ yshinri: 那後者這種表其實除了你提的優點之外, 其他方面都比前者 03/08 08:47
→ yshinri: 來的好, 但我想不只這裡推文, 原 PO 多少也以為建表是 03/08 08:47
→ yshinri: 前者那種建表, 這才是這一串開頭在問的問題 03/08 08:47
→ yshinri: 然後我提的神魔的例子則是真的少數用前者這種方法建表 03/08 08:48
→ yshinri: 的奇葩例子 03/08 08:49
→ yshinri: replay 這種事情就算使用先 cache 的表, 只要把開頭的 03/08 08:57
→ yshinri: 種子給紀錄下來, 之後 replay 回放時重新產生就行了 03/08 08:57
→ yshinri: 至於區網連線遊戲的隨機傷害這種東西, 你該傳的不是 03/08 08:57
→ yshinri: 「我打了你, 你幫我算個傷害」而該是「我打了你多少點」 03/08 08:58
→ yshinri: 那這個隨機傷害怎麼產生就跟什麼同步的無關了 03/08 08:59
→ yshinri: 當然這種狀況的 replay 就必須把每次的傷害都紀錄下來 03/08 08:59
推 hanmas: 推專業 不過物件導向學校也是有教的吧 03/08 09:35
推 stfang925: 推推～～ 03/08 10:17
推 j456789a: 感謝偉大的物件導向讓我們減少更多爆肝時間 03/08 11:15
推 gn00063172: 推推 03/08 12:20
推 GKki2012: 專業推推推 03/08 14:33
推 linja: 專業推。實務上封包收發真的會產生很多問題 03/08 17:48
推 PassthebyLai: 給推 03/08 20:25