作者devil99 (跌咧嘻嘻嘻)
看板travian
標題Re: [閒聊] 一秒多攻之攻防研究
時間Tue Jun 16 23:38:57 2009
※ 引述《harold0224 (Harold)》之銘言:
: 我呢,是屬於認為有毫秒這件事情存在的人,反正大膽假設,小心求證咩
: 經過一個晚上反覆的測試,對於同一個目標村莊的增援,我無法製造出『
: 後發先至』這件事。而我仍然不死心,到國外論壇找文章。經過一番折騰
: ,我又來做假設了 XD
: 現在的我,仍然認為毫秒是存在的(想噓的晚一點動手啦)。只不過這個
: 毫秒只存在Server & Client 來判斷事件的『註冊』的先後順序而已,系
: 統上紀錄事件,則是以『秒』為單位並加上『排程』。
: 換句話說,對一個村莊而言,當我已經跟Server『註冊』好,我幾點幾分
: 幾秒,部隊會到達目標村,那麼,對於那個目標村,只要我註冊完成的時
: 候是第一個,那麼我就是第一個。在這種『排程』系統下,系統會用到毫
: 秒,但是只是在Server接收到指令的那一瞬間。當『排程』完成,事件就
: 註冊完成。這樣。
: 所以毫秒只是用來在那一瞬間,讓Server在眾多指令之中,分辨先後而已
: 。至於過去的經驗以及有些人提出的案例怎麼解釋?非常有可能的情況是
: ,被插斷的攻擊波,並不是首發攻擊。再白話一點,極有可能是,A 村已
: 經被攻擊波鎖定了,他B 與盟友 C已經開始增援,而這時,D 村也打算發
: 動攻擊波,就該死的,他送指令跟B 或C 同時,結果倒楣被插斷,一切都
: 是命。
: 仔細想想,好像被插斷的攻擊波,都不是第一個發出的那個,但是在戰報
: 上,防禦村只能知道同時到,並無法判斷是誰先發出。所以說,如果是一
: 連串的攻擊波,中間有間隔但是有那種連續20波的同秒攻擊在內,就很可
: 能出現攻擊波被插斷的『假象』。仔細推算,他只不過是跟把他插斷的人
: ,幾乎同時按罷了。
: 好,亂七八糟的假設說完。
: 不管怎樣,其實我只是喜歡想辦法知道真相,但是不會去否定其他可能而
: 已。遊戲咩,討論嘛。輕鬆一點唄。
: PS:系統是排程運做,似乎是絕大多數國外玩家的意見。
網路上封包傳輸的時間,的確是會記錄至毫秒(千分之一秒),
但系統在作運算處理時,除非有特殊目的,通常不會考慮這麼微小的差距。
在此假設系統以毫秒來做比較判斷,那麼再以期望值來估算,
平均每一千次的同秒事件,就會有一次是連毫秒都相同,
那此時該如何判斷先後呢?考慮到微秒(百萬分之一秒)嗎?
PHP的確是可以偵測到微秒,可是網頁程式一般不會計算到這麼細微。
我試著以程式設計的觀點來分析同秒到達的狀況:
同秒事件的處理的確是像原PO說的“排程運作”,但卻不是以毫秒來做判斷,
而是以堆疊、佇列的方式來達成,即先進先出的概念,
即使是MultiThread也會有先後之分,
根本不用考慮各波到達的時間是差了零點零幾秒,
也就是大家所謂的“先出先到”。
網頁遊戲以秒為基本單位已經很足夠了,
故這看起來是比較理所當然的設計方式,就好比開車想右轉時,會將方向盤轉右,
而不是左轉三次般的理所當然。
至於有人提到曾插秒成功的經驗,但大家可以注意到,
沒有一個人是刻意“實測插秒成功”的,每個案例都是“記得曾經成功過”,
那就可以比較合理的推斷當時該位大大看錯、日久記錯,
或是當時遊戲的經驗較不足,對同秒概念不清楚,以致判斷錯誤,
甚至是如前文所提A村攻擊,B村同秒插防,C村再補插秒攻擊的誤判狀況。
記錄到毫秒再做先後判斷的設計方式,不僅多浪費了資料庫的欄位空間,
也降低了程式運算效率,我的判斷是德國程式設計師不會這麼做。
之前還有大大提到過,有謎之程式可以設定到毫秒,這可以肯定絕對是道聽塗說,
從網頁原始檔到封包截取我都檢查過,根本沒有記錄時間的參數,
所有時間的判定都是在伺服器端執行。
甚至不需要像我那麼笨花那些時間測試,只要用膝蓋想一下就知道了,
如果到達時間可以用外掛程式來控制,那麼我只要假造封包,
讓我的部隊在一秒鐘後到達不就好了~ 這遊戲還需要玩嗎?
散播這謠言的人好像告訴大家把程式設計師當白痴一樣。
如果指的是排程送出指令的時間,那麼這謎之程式也設計得很沒意義,
光網路的延遲時間就達數十至上百毫秒了,更何況若是玩家電腦無校時,
排程設定至毫秒更是毫無意義。
--
至於還是有人堅持我沒看過程式碼,而且有人插秒成功過,
所以不能排除毫秒理論的可能性的話,就請噓吧。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.134.70.92
1F:推 kuso0516:推一個 不過推疊太技術性了會不會有人聽不懂 06/16 23:45
3F:推 wanderer1412:怎麼講到stack跟queue了= = 06/16 23:54
4F:→ FDDFDFDA:基本資料結構XD 06/16 23:55
6F:推 streitleak:資料庫的Datetime格式是有毫秒的...除非你輸入有特別 06/17 00:00
7F:→ streitleak:指定 而且資料庫會自動幫你加上毫秒的話 那就會有毫秒 06/17 00:01
8F:→ ccbearxp:可以推「流言破解」了嗎? 06/17 00:15
9F:推 abckk:禾斗 禾斗 禾斗 >////<. 06/17 00:16
10F:推 oneagain12:It's totally Busted!! 06/17 00:16
11F:推 KMar: It's totally Busted!! 06/17 00:21
12F:推 bmfer:我的看法跟這個作者一樣,因為效能差太多了。 06/17 00:27
13F:→ bmfer:德國工程師 應該不會搬石頭砸自己的腳。 06/17 00:28
14F:→ harold0224:我想,我不是程式設計師,表達可能有不足。 06/17 00:35
15F:→ harold0224:我意思也只是認為在server收訊號的先後,才有毫秒的差 06/17 00:36
16F:→ harold0224:別。 06/17 00:37
17F:→ harold0224:我現在認為的毫秒差異頂多是出現在這一端而已。 06/17 00:38
18F:推 nokibot:拿程設的角度來說 記錄毫秒 跟 拿流水號是一樣的不吃效能 06/17 01:13
19F:→ nokibot:index 有設好 其實跟 auto increment 差不多 06/17 01:14
20F:推 sig:樓上你跳針了,用queue排程不用記錄毫秒也不用拿流水號 06/17 01:34
21F:推 baphomat:專業分析文,理論基礎明確 06/17 02:08
22F:→ FDDFDFDA:為什麼用queue會需要用到紀錄時間@"@..不就front和rear就 06/17 02:09
23F:→ FDDFDFDA:夠用了嗎...0.0"> 06/17 02:10
24F:推 wang19871107:我今天被鎖...MH說我搶奪時間準確至微秒... 06/17 03:28
25F:→ wang19871107:按照原PO的說法我是被唬爛囉?我真的只是純手動到秒 06/17 03:29
26F:推 FDDFDFDA:搶奪時間準確到微秒= ="...這MH在唬爛吧....... 06/17 07:47
27F:→ FDDFDFDA:就算今天或許真有可能..碰到一次Delay..不就沒同秒了= = 06/17 07:48
28F:→ FDDFDFDA:我看你寄信給Admin或許比較快... 06/17 07:48
29F:推 wang19871107:Admin是誰阿?? 06/17 11:49
30F:推 SmileJoS:admin 是遊戲管理人員 , MH只是類似工讀生GM 06/17 12:24
31F:→ SmileJoS:admin 可以參考每個網頁底下的信箱位置寄信過去 06/17 12:24
32F:→ visor:nokibot 寫的程式 我不敢用... 06/17 15:01
33F:噓 tim780928:你不覺得 我好帥麻? 06/17 15:07
34F:→ FDDFDFDA:0.0 06/17 15:20
35F:推 nokibot:要用到我寫的程式 那大概TRA 都沒神人了 06/17 17:14
36F:推 nokibot:經過多次MH的加持 只能說好用 06/17 17:17