[討論] 說好的新地圖不加RK?

看板OverWatch作者 (月‧漓)時間7年前 (2017/06/23 15:37), 編輯推噓39(42推 3噓 35→)
留言80則, 24人參與, 最新討論串1/1
若認知有誤請指正...... 不是聽說新地圖一個禮拜不會加進RK O_O? 剛剛登上線有更新了，然後一排RK......月球殖民基地 黑人問號.jpg 我還特別確認寫著「競技對戰」四個大字 打完也確實掉分了...... 說好的一個禮拜不加RK咧！？ (隊友都不熟地圖被輾過) -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.171.74.41 ※ 文章網址: https://www.ptt.cc/bbs/OverWatch/M.1498203456.A.432.html
推
06/23 15:38, , 1F
只有上次Orisa一週不上RK的印象～
06/23 15:38, 1F
推
06/23 15:39, , 2F
the technology just isn't there yet
06/23 15:39, 2F
推
06/23 15:53, , 3F
本來沒要上 出bug就上了 藍帖有說
06/23 15:53, 3F
→
06/23 15:53, , 4F
很想問競技ban圖一週對遊戲公司來說很難嗎=.=?
06/23 15:53, 4F
推
06/23 15:55, , 5F
難不成你覺得他按一個按鈕就可以Ban了喔(-_-)
06/23 15:55, 5F
推
06/23 15:56, , 6F
本來這次要改成延遲一周 但是這樣伺服器會有Bug
06/23 15:56, 6F
→
06/23 15:56, , 7F
所以改成下次
06/23 15:56, 7F
→
06/23 16:03, , 8F
我以為這種事工程師動動手就做得到惹。
06/23 16:03, 8F
推
06/23 16:04, , 9F
真得很難阿，畢竟是歐美數一數二的大公司，BAN圖一週真難
06/23 16:04, 9F
推
06/23 16:06, , 10F
WOW連16格包都改不掉了
06/23 16:06, 10F
推
06/23 16:07, , 11F
暴雪不意外啦，d3超大bug修不好只好把整個拍賣場拔掉~
06/23 16:07, 11F
推
06/23 16:10, , 12F
WOW的16格包的設定很恐怖...他是把程式一直寫在這設定
06/23 16:10, 12F
→
06/23 16:10, , 13F
上面，你只要知道如果他要改這個設定快要變成把整個遊
06/23 16:10, 13F
→
06/23 16:10, , 14F
戲都拆了....
06/23 16:10, 14F
推
06/23 16:27, , 15F
休正bug需一周 剛好直上 kappa
06/23 16:27, 15F
推
06/23 16:28, , 16F
不是伺服器有bug 是伺服器根本沒這個功能
06/23 16:28, 16F
推
06/23 16:37, , 17F
公告完才發現沒這功能有夠好笑的XD
06/23 16:37, 17F
推
06/23 16:44, , 18F
真正寫過程式就知道以前以為的小bug實際上多難修了
06/23 16:44, 18F
推
06/23 16:46, , 19F
公告講講都很簡單，工程師才知道可行性如何
06/23 16:46, 19F
→
06/23 16:50, , 20F
大家以為寫程式的動動手指就可以了...顆顆
06/23 16:50, 20F
推
06/23 17:01, , 21F
沒寫過程式的真的都覺得好像像很簡單一樣
06/23 17:01, 21F
推
06/23 17:05, , 22F
不是說寫程式簡單,而是BZ你公告前要先確認阿XD
06/23 17:05, 22F
推
06/23 17:05, , 23F
一個迴圈沒寫好拖垮整個server誰要負責?
06/23 17:05, 23F
噓
06/23 17:05, , 24F
公司砸自己腳還要這麼多人護航真是辛苦你們了
06/23 17:05, 24F
→
06/23 17:06, , 25F
發公告前自己會不知道有沒有這功能XD
06/23 17:06, 25F
噓
06/23 17:07, , 26F
護航的到底是想什麼 公告發出來沒做到本來就bz的錯了
06/23 17:07, 26F
→
06/23 17:08, , 27F
啊
06/23 17:08, 27F
推
06/23 17:11, , 28F
我贊成是BZ的錯 但錯在沒確定就發公告 程式本來就有變
06/23 17:11, 28F
推
06/23 17:11, , 29F
ow團隊縱向聯繫做的不好，不過不意外，一直以來都是這樣
06/23 17:11, 29F
→
06/23 17:12, , 30F
數 請不要認為程式很簡單 有問題的是暴雪搞不清楚就
06/23 17:12, 30F
→
06/23 17:12, , 31F
發公告
06/23 17:12, 31F
→
06/23 17:22, , 32F
沒說寫程式很簡單吧= =?而是這種設定對大型遊戲公司
06/23 17:22, 32F
→
06/23 17:23, , 33F
來說，並非什麼很棘手的問題吧?
06/23 17:23, 33F
推
06/23 17:25, , 34F
我覺得比較可能的是寫了公告後才發現有問題來不及修
06/23 17:25, 34F
推
06/23 17:31, , 35F
上面是說ban圖很簡單吧
06/23 17:31, 35F
→
06/23 17:31, , 36F
說實在的我自己完全想不出來ban圖難在哪
06/23 17:31, 36F
→
06/23 17:34, , 37F
或許真的有什麼難處，變相成像我這門外漢根本不懂還
06/23 17:34, 37F
→
06/23 17:35, , 38F
覺得很簡單。
06/23 17:35, 38F
推
06/23 17:35, , 39F
演算法 資料庫結構 code server架構等等都不知道的狀況
06/23 17:35, 39F
→
06/23 17:35, , 40F
下很難判斷說到底難不難 只能確定說BZ公告前根本沒發現
06/23 17:35, 40F
推
06/23 17:38, , 41F
我不覺得地圖資料會跟演算法有關……單純抽掉資料沒有
06/23 17:38, 41F
→
06/23 17:38, , 42F
很難
06/23 17:38, 42F
推
06/23 17:40, , 43F
3V3 1V1遊樂場都能有自己一套地圖組，為甚麼RK不行?
06/23 17:40, 43F
→
06/23 17:41, , 44F
就是沒寫好吧?
06/23 17:41, 44F
推
06/23 17:50, , 45F
除非BZ真的笨到是直接用編號暴力讀取資料庫內容 不然先
06/23 17:50, 45F
→
06/23 17:50, , 46F
把地圖抽掉完全對整個遊戲沒有影響 正常人寫資料庫都是
06/23 17:50, 46F
→
06/23 17:50, , 47F
用迴圈去取值 如果出問題不會只有一張地圖出事
06/23 17:50, 47F
推
06/23 17:55, , 48F
說真的這張還是新圖,以一般寫法應該沒理由ban不掉XD
06/23 17:55, 48F
推
06/23 17:57, , 49F
能任意新增地圖 但是卻不能拿掉 感覺怪怪的
06/23 17:57, 49F
→
06/23 17:57, , 50F
也許可能跟客戶端某些一起更新的資料有關
06/23 17:57, 50F
推
06/23 17:57, , 51F
前面兩張圖也沒BAN一周 只有歐瑞莎有BAN過
06/23 17:57, 51F
推
06/23 17:58, , 52F
我在猜說會不會有動選圖機制 要不然用舊的地圖組應該
06/23 17:58, 52F
→
06/23 17:59, , 53F
不會有問題才是
06/23 17:59, 53F
推
06/23 18:00, , 54F
如果是動到選圖機制的話 一樣跟地圖資料無關喔
06/23 18:00, 54F
→
06/23 18:01, , 55F
因為那是在取值那邊的邏輯運算有改變 資料庫內容不影響
06/23 18:01, 55F
推
06/23 18:02, , 56F
以最直觀的寫法選圖機制ban圖應該是不難的,只能說BZ或
06/23 18:02, 56F
→
06/23 18:02, , 57F
許混了些其他演算法在選圖裡才搞得這麼複雜吧
06/23 18:02, 57F
推
06/23 18:05, , 58F
之前BZ有公告過他們選圖演算法有改過 一般來說取值完
06/23 18:05, 58F
→
06/23 18:06, , 59F
後做運算應該跟資料庫內的資料無關 可是不知道BZ到底
06/23 18:06, 59F
→
06/23 18:07, , 60F
是怎麼弄得
06/23 18:07, 60F
推
06/23 18:08, , 61F
混了其他演算法的話整個程式碼會很可怕耶……
06/23 18:08, 61F
推
06/23 18:08, , 62F
你剛剛其實打的是快速 隊友都半藏奪命炸彈鼠
06/23 18:08, 62F
推
06/23 18:09, , 63F
BZ之前有說選圖會盡量不重複,所以至少有這套的演算吧
06/23 18:09, 63F
→
06/23 18:09, , 64F
物理演算應該是分開 選角演算要用前端取值再抽角色資料
06/23 18:09, 64F
→
06/23 18:09, , 65F
庫 地圖我猜是隨機抽樣 可能再加上不連續重複的保障機
06/23 18:09, 65F
→
06/23 18:09, , 66F
制
06/23 18:09, 66F
→
06/23 18:10, , 67F
我也沒碰過那麼大的project,他們可能真的有獨特作法吧
06/23 18:10, 67F
→
06/23 18:11, , 68F
可是保障機制的寫法其實也跟資料庫的資料無關 應該是把
06/23 18:11, 68F
→
06/23 18:11, , 69F
上次抽的值多定義出一個變數 寫一段判斷不重複的句子
06/23 18:11, 69F
→
06/23 18:14, , 70F
除非他有要每個地圖分開算 那我就不知道他們是怎麼寫的
06/23 18:14, 70F
推
06/23 18:15, , 71F
結果只是沒注意到這禮拜程式主管去度假(喂
06/23 18:15, 71F
推
06/23 18:18, , 72F
或許真的有可能 排隊機制還要講求效率 或許BZ有一套自
06/23 18:18, 72F
推
06/23 18:19, , 73F
忘記把這項功能寫在工作室的白板上
06/23 18:19, 73F
→
06/23 18:19, , 74F
己的演算法認為能兼顧隨機性跟效率
06/23 18:19, 74F
推
06/23 19:51, , 75F
我覺得單純只是他們都在忙highlight的新功能XD
06/23 19:51, 75F
推
06/23 20:27, , 76F
99個bug 修正一個放上更新檔 還有255個bug
06/23 20:27, 76F
噓
06/24 08:31, , 77F
阿你對手都不會不熟地圖？
06/24 08:31, 77F
推
06/24 10:13, , 78F
樓上崩潰屁 就是bz的問題了
06/24 10:13, 78F
推
06/25 23:40, , 79F
是bz問題啊 但所謂的護航不是在回應 '沒有很難吧？'這
06/25 23:40, 79F
→
06/25 23:40, , 80F
種推文嗎xD
06/25 23:40, 80F
‣ 更多 evelyn790730 的文章
文章代碼(AID): #1PJCL0Go (OverWatch)