Re: [閒聊] 一秒多攻之攻防研究

看板travian作者devil99 (跌咧嘻嘻嘻)時間15年前 (2009/06/16 23:38)推噓16(17推 1噓 18→)

留言36則, 17人參與討論串14/18 (看更多)

※ 引述《harold0224 (Harold)》之銘言： : 我呢，是屬於認為有毫秒這件事情存在的人，反正大膽假設，小心求證咩 : 經過一個晚上反覆的測試，對於同一個目標村莊的增援，我無法製造出『 : 後發先至』這件事。而我仍然不死心，到國外論壇找文章。經過一番折騰 : ，我又來做假設了 XD : 現在的我，仍然認為毫秒是存在的（想噓的晚一點動手啦）。只不過這個 : 毫秒只存在Server & Client 來判斷事件的『註冊』的先後順序而已，系 : 統上紀錄事件，則是以『秒』為單位並加上『排程』。 : 換句話說，對一個村莊而言，當我已經跟Server『註冊』好，我幾點幾分 : 幾秒，部隊會到達目標村，那麼，對於那個目標村，只要我註冊完成的時 : 候是第一個，那麼我就是第一個。在這種『排程』系統下，系統會用到毫 : 秒，但是只是在Server接收到指令的那一瞬間。當『排程』完成，事件就 : 註冊完成。這樣。 : 所以毫秒只是用來在那一瞬間，讓Server在眾多指令之中，分辨先後而已 : 。至於過去的經驗以及有些人提出的案例怎麼解釋？非常有可能的情況是 : ，被插斷的攻擊波，並不是首發攻擊。再白話一點，極有可能是，A 村已 : 經被攻擊波鎖定了，他B 與盟友 C已經開始增援，而這時，D 村也打算發 : 動攻擊波，就該死的，他送指令跟B 或C 同時，結果倒楣被插斷，一切都 : 是命。 : 仔細想想，好像被插斷的攻擊波，都不是第一個發出的那個，但是在戰報 : 上，防禦村只能知道同時到，並無法判斷是誰先發出。所以說，如果是一 : 連串的攻擊波，中間有間隔但是有那種連續20波的同秒攻擊在內，就很可 : 能出現攻擊波被插斷的『假象』。仔細推算，他只不過是跟把他插斷的人 : ，幾乎同時按罷了。 : 好，亂七八糟的假設說完。 : 不管怎樣，其實我只是喜歡想辦法知道真相，但是不會去否定其他可能而 : 已。遊戲咩，討論嘛。輕鬆一點唄。 : PS：系統是排程運做，似乎是絕大多數國外玩家的意見。網路上封包傳輸的時間，的確是會記錄至毫秒(千分之一秒)，但系統在作運算處理時，除非有特殊目的，通常不會考慮這麼微小的差距。在此假設系統以毫秒來做比較判斷，那麼再以期望值來估算，平均每一千次的同秒事件，就會有一次是連毫秒都相同，那此時該如何判斷先後呢？考慮到微秒(百萬分之一秒)嗎？ PHP的確是可以偵測到微秒，可是網頁程式一般不會計算到這麼細微。我試著以程式設計的觀點來分析同秒到達的狀況：同秒事件的處理的確是像原PO說的“排程運作”，但卻不是以毫秒來做判斷，而是以堆疊、佇列的方式來達成，即先進先出的概念，即使是MultiThread也會有先後之分，根本不用考慮各波到達的時間是差了零點零幾秒，也就是大家所謂的“先出先到”。網頁遊戲以秒為基本單位已經很足夠了，故這看起來是比較理所當然的設計方式，就好比開車想右轉時，會將方向盤轉右，而不是左轉三次般的理所當然。至於有人提到曾插秒成功的經驗，但大家可以注意到，沒有一個人是刻意“實測插秒成功”的，每個案例都是“記得曾經成功過”，那就可以比較合理的推斷當時該位大大看錯、日久記錯，或是當時遊戲的經驗較不足，對同秒概念不清楚，以致判斷錯誤，甚至是如前文所提Ａ村攻擊，Ｂ村同秒插防，Ｃ村再補插秒攻擊的誤判狀況。記錄到毫秒再做先後判斷的設計方式，不僅多浪費了資料庫的欄位空間，也降低了程式運算效率，我的判斷是德國程式設計師不會這麼做。之前還有大大提到過，有謎之程式可以設定到毫秒，這可以肯定絕對是道聽塗說，從網頁原始檔到封包截取我都檢查過，根本沒有記錄時間的參數，所有時間的判定都是在伺服器端執行。甚至不需要像我那麼笨花那些時間測試，只要用膝蓋想一下就知道了，如果到達時間可以用外掛程式來控制，那麼我只要假造封包，讓我的部隊在一秒鐘後到達不就好了~ 這遊戲還需要玩嗎？散播這謠言的人好像告訴大家把程式設計師當白痴一樣。如果指的是排程送出指令的時間，那麼這謎之程式也設計得很沒意義，光網路的延遲時間就達數十至上百毫秒了，更何況若是玩家電腦無校時，排程設定至毫秒更是毫無意義。 -- 至於還是有人堅持我沒看過程式碼，而且有人插秒成功過，所以不能排除毫秒理論的可能性的話，就請噓吧。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 220.134.70.92

推

kuso0516

06/16 23:45, , 1^F

06/16 23:45, 1^F

推

FDDFDFDA

06/16 23:52, , 2^F

06/16 23:52, 2^F

推

wanderer1412

06/16 23:54, , 3^F

06/16 23:54, 3^F