Re: [問題] 如果兩邊一起破主堡會發生什麼
※ 引述《kobegirl5566 (尻屄女孩)》之銘言:
: 3.[問題]發文須知說明
: 針對詢問或任何相關議題之深入探討、意見蒐集等用途使用之一般分類標籤。
: 如為新手發問,請於標題註記「新手」以利板友辨識。
: ---------------- 以上為問題文 相關發文須知 請詳閱後ctrl+y刪除 ---------------
: 如題
: 因為我沒有朋友可以一啟測= =
: 只好上來發問
: 請問有人有類似的經驗嗎?@@
不可能。
因為任何你玩的遊戲,不管是永哪種遊戲引擎(Unreal之類),或是自己刻一個(如LOL),
都會有一個叫做game loop的迴圈
例如你例如伺服器方的頻率是60, 那就是一秒做60次迴圈
他會把畫面要呈現的物體、10個連線操作訊號+伺服器端的資料等等做整合
然後把整個地圖上該確認的操作一個一個計算完畢,做法大概會類似
條件代號 條件內容
1. 藍方主堡破了嗎?
2. 紅方主堡破了嗎?
...
10. 處理p1的操作
11. p2
...
也就是說,每個操作你看起來雖然是同時的,可是還是會有處理的先後順序
一定會有一個操作先被系統處理完然後觸發主堡爆炸條件,然後終止其他條件。
這邊可能會有點小小的不公平,
也就是系統可能會優先處理某一個人的操作 如" 藍方p1 "
不過這超過人類可以感知的範圍,大概要在1/60秒內兩個人同時砍下去才會有爭議
但也沒辦法,為了這個不是很重要的小問題爭論,或是增加系統的複雜度
說不定會讓系統出更多錯,也不見得公平。
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.165.26.9
※ 文章網址: https://www.ptt.cc/bbs/LoL/M.1498802194.A.857.html
推
06/30 13:58, , 1F
06/30 13:58, 1F
跑跑卡丁車也不太可能平手
因為卡丁車的引擎3D的,每輛車都會有一個判斷是否到終點的點
例如(x1,y1,z1)一號車、(x2,y2,z2)二號車,跟終點線的一個平面方程式,
這兩個空間中的點小數點可能精確到0.0000001公尺(遊戲虛擬座標系)
而車子時速可能只有20m/s(遊戲虛擬座標系)
也就是有爭議的時間間隙只有 5.0e-9 秒(反正就是很多0.00000...)
基本上小於1/60 所以還是同樣的game loop 1/60秒 內才會有爭議
順代一提,有的遊戲伺服器端還是 1/20 那就會有爭議了,例如打CS就不能用1/20週期
很多職業選手的操作都發生在0.01秒之間, 0.05秒稍嫌太久
一般來說,真的要搞平手的話,大概就自定義一個時段 t,
第一名抵達時間+t 都算同時抵達 t定成1/100秒 之類的
但競速遊戲這樣做蠻鳥的。
除非是什麼奧運的特殊比賽,測量的儀器有最小誤差範圍(真實世界中的比賽)
推
06/30 13:59, , 2F
06/30 13:59, 2F
剛好休閒是刻遊戲引擎
推
06/30 14:00, , 3F
06/30 14:00, 3F
推
06/30 14:04, , 4F
06/30 14:04, 4F
推
06/30 14:04, , 5F
06/30 14:04, 5F
推
06/30 14:05, , 6F
06/30 14:05, 6F
推
06/30 14:05, , 7F
06/30 14:05, 7F
^__^/
推
06/30 14:10, , 8F
06/30 14:10, 8F
推
06/30 14:10, , 9F
06/30 14:10, 9F
對,比較公平的方法可能會是 每1/60秒 收到的10個人的操作隨機處理
但意義好像不大就是了,因為這樣做的哲學是"有時你佔他便宜 有時他佔你"
好像沒什麼差別
※ 編輯: tonylo2ooo (118.165.26.9), 06/30/2017 14:12:23
推
06/30 14:13, , 10F
06/30 14:13, 10F
推
06/30 14:13, , 11F
06/30 14:13, 11F
推
06/30 14:16, , 12F
06/30 14:16, 12F
→
06/30 14:17, , 13F
06/30 14:17, 13F
→
06/30 14:18, , 14F
06/30 14:18, 14F
恩,炸彈超人好像是以最後一顆炸彈爆炸後 火焰消失才結算
總而言之要做到平手也可以 沒有做不到的 只是有沒有必要 會不會提升體驗?
→
06/30 14:18, , 15F
06/30 14:18, 15F
※ 編輯: tonylo2ooo (118.165.26.9), 06/30/2017 14:19:18
推
06/30 14:18, , 16F
06/30 14:18, 16F
推
06/30 14:18, , 17F
06/30 14:18, 17F
推
06/30 14:20, , 18F
06/30 14:20, 18F
推
06/30 14:22, , 19F
06/30 14:22, 19F
→
06/30 14:23, , 20F
06/30 14:23, 20F
推
06/30 14:24, , 21F
06/30 14:24, 21F
噓
06/30 14:27, , 22F
06/30 14:27, 22F
推
06/30 14:27, , 23F
06/30 14:27, 23F
推
06/30 14:29, , 24F
06/30 14:29, 24F
推
06/30 14:29, , 25F
06/30 14:29, 25F
推
06/30 14:30, , 26F
06/30 14:30, 26F
推
06/30 14:30, , 27F
06/30 14:30, 27F
推
06/30 14:34, , 28F
06/30 14:34, 28F
推
06/30 14:34, , 29F
06/30 14:34, 29F
推
06/30 14:44, , 30F
06/30 14:44, 30F
推
06/30 14:47, , 31F
06/30 14:47, 31F
推
06/30 14:48, , 32F
06/30 14:48, 32F
推
06/30 14:49, , 33F
06/30 14:49, 33F
→
06/30 14:49, , 34F
06/30 14:49, 34F
→
06/30 14:50, , 35F
06/30 14:50, 35F
→
06/30 14:50, , 36F
06/30 14:50, 36F
推
06/30 14:51, , 37F
06/30 14:51, 37F
→
06/30 14:52, , 38F
06/30 14:52, 38F
→
06/30 14:53, , 39F
06/30 14:53, 39F
→
06/30 14:54, , 40F
06/30 14:54, 40F
→
06/30 14:54, , 41F
06/30 14:54, 41F
發了廢文抱歉@@....
→
06/30 14:56, , 42F
06/30 14:56, 42F
推
06/30 14:59, , 43F
06/30 14:59, 43F
→
06/30 14:59, , 44F
06/30 14:59, 44F
噓
06/30 15:14, , 45F
06/30 15:14, 45F
原來,那就代表開發的時候一定有刻意加入最小測量誤差
例如0.001秒內算同時抵達
※ 編輯: tonylo2ooo (123.194.181.51), 06/30/2017 15:20:52
推
06/30 15:20, , 46F
06/30 15:20, 46F
推
06/30 15:20, , 47F
06/30 15:20, 47F
推
06/30 15:21, , 48F
06/30 15:21, 48F
推
06/30 15:42, , 49F
06/30 15:42, 49F
推
06/30 15:51, , 50F
06/30 15:51, 50F
→
06/30 15:51, , 51F
06/30 15:51, 51F
推
06/30 15:51, , 52F
06/30 15:51, 52F
→
06/30 15:51, , 53F
06/30 15:51, 53F
推
06/30 16:07, , 54F
06/30 16:07, 54F
推
06/30 16:23, , 55F
06/30 16:23, 55F
推
06/30 16:24, , 56F
06/30 16:24, 56F
推
06/30 17:09, , 57F
06/30 17:09, 57F
→
06/30 17:09, , 58F
06/30 17:09, 58F
推
06/30 18:18, , 59F
06/30 18:18, 59F
推
06/30 18:27, , 60F
06/30 18:27, 60F
推
06/30 18:40, , 61F
06/30 18:40, 61F
推
06/30 19:03, , 62F
06/30 19:03, 62F
→
06/30 19:04, , 63F
06/30 19:04, 63F
推
06/30 20:41, , 64F
06/30 20:41, 64F
討論串 (同標題文章)
完整討論串 (本文為第 2 之 3 篇):