若認知有誤請指正......
不是聽說新地圖一個禮拜不會加進RK O_O?
剛剛登上線有更新了，然後一排RK......月球殖民基地
黑人問號.jpg
我還特別確認寫著「競技對戰」四個大字
打完也確實掉分了......
說好的一個禮拜不加RK咧！？
(隊友都不熟地圖被輾過)
作者:
oliverhb (oliverhb)
2017-06-23 15:38:00只有上次Orisa一週不上RK的印象～
the technology just isn't there yet
很想問競技ban圖一週對遊戲公司來說很難嗎=.=?
難不成你覺得他按一個按鈕就可以Ban了喔(-_-)
本來這次要改成延遲一周 但是這樣伺服器會有Bug所以改成下次
作者:
sakyle (Sakyle)
2017-06-23 16:04:00真得很難阿，畢竟是歐美數一數二的大公司，BAN圖一週真難
作者:
w9 (Good Day)
2017-06-23 16:07:00暴雪不意外啦，d3超大bug修不好只好把整個拍賣場拔掉~
WOW的16格包的設定很恐怖...他是把程式一直寫在這設定上面，你只要知道如果他要改這個設定快要變成把整個遊戲都拆了....
作者: as83158 2017-06-23 16:27:00
休正bug需一周 剛好直上 kappa
作者: q4w5e680 (Brian) 2017-06-23 16:44:00
真正寫過程式就知道以前以為的小bug實際上多難修了
作者:
ilohoo (ilohoo)
2017-06-23 16:46:00公告講講都很簡單，工程師才知道可行性如何
作者:
cephas (血法)
2017-06-23 16:50:00大家以為寫程式的動動手指就可以了...顆顆
作者:
jack9731 (hidochunk)
2017-06-23 17:01:00沒寫過程式的真的都覺得好像像很簡單一樣
作者: marx93521 (<阿ㄉ一ㄥˋ>) 2017-06-23 17:05:00
一個迴圈沒寫好拖垮整個server誰要負責?
作者:
sakyle (Sakyle)
2017-06-23 17:05:00公司砸自己腳還要這麼多人護航真是辛苦你們了發公告前自己會不知道有沒有這功能XD
護航的到底是想什麼 公告發出來沒做到本來就bz的錯了啊
作者: marx93521 (<阿ㄉ一ㄥˋ>) 2017-06-23 17:11:00
我贊成是BZ的錯 但錯在沒確定就發公告 程式本來就有變
作者:
w9 (Good Day)
2017-06-23 17:11:00ow團隊縱向聯繫做的不好，不過不意外，一直以來都是這樣
作者: marx93521 (<阿ㄉ一ㄥˋ>) 2017-06-23 17:12:00
數 請不要認為程式很簡單 有問題的是暴雪搞不清楚就發公告
沒說寫程式很簡單吧= =?而是這種設定對大型遊戲公司來說，並非什麼很棘手的問題吧?
作者:
andy8568 (FreeHugs)
2017-06-23 17:31:00上面是說ban圖很簡單吧說實在的我自己完全想不出來ban圖難在哪
或許真的有什麼難處，變相成像我這門外漢根本不懂還覺得很簡單。
作者: marx93521 (<阿ㄉ一ㄥˋ>) 2017-06-23 17:35:00
演算法 資料庫結構 code server架構等等都不知道的狀況下很難判斷說到底難不難 只能確定說BZ公告前根本沒發現
作者:
andy8568 (FreeHugs)
2017-06-23 17:38:00我不覺得地圖資料會跟演算法有關……單純抽掉資料沒有很難
作者:
sakyle (Sakyle)
2017-06-23 17:40:003V3 1V1遊樂場都能有自己一套地圖組，為甚麼RK不行?就是沒寫好吧?
作者:
andy8568 (FreeHugs)
2017-06-23 17:50:00除非BZ真的笨到是直接用編號暴力讀取資料庫內容 不然先把地圖抽掉完全對整個遊戲沒有影響 正常人寫資料庫都是用迴圈去取值 如果出問題不會只有一張地圖出事
說真的這張還是新圖,以一般寫法應該沒理由ban不掉XD
作者: s091572no 2017-06-23 17:57:00
能任意新增地圖 但是卻不能拿掉 感覺怪怪的
作者: marx93521 (<阿ㄉ一ㄥˋ>) 2017-06-23 17:58:00
我在猜說會不會有動選圖機制 要不然用舊的地圖組應該不會有問題才是
作者:
andy8568 (FreeHugs)
2017-06-23 18:00:00如果是動到選圖機制的話 一樣跟地圖資料無關喔因為那是在取值那邊的邏輯運算有改變 資料庫內容不影響
以最直觀的寫法選圖機制ban圖應該是不難的,只能說BZ或許混了些其他演算法在選圖裡才搞得這麼複雜吧
作者: marx93521 (<阿ㄉ一ㄥˋ>) 2017-06-23 18:05:00
之前BZ有公告過他們選圖演算法有改過 一般來說取值完後做運算應該跟資料庫內的資料無關 可是不知道BZ到底是怎麼弄得
作者:
andy8568 (FreeHugs)
2017-06-23 18:08:00混了其他演算法的話整個程式碼會很可怕耶……
作者:
lf41001 (東山燒肉飯)
2017-06-23 18:08:00你剛剛其實打的是快速 隊友都半藏奪命炸彈鼠
BZ之前有說選圖會盡量不重複,所以至少有這套的演算吧
作者:
andy8568 (FreeHugs)
2017-06-23 18:09:00物理演算應該是分開 選角演算要用前端取值再抽角色資料庫 地圖我猜是隨機抽樣 可能再加上不連續重複的保障機制
我也沒碰過那麼大的project,他們可能真的有獨特作法吧
作者:
andy8568 (FreeHugs)
2017-06-23 18:11:00可是保障機制的寫法其實也跟資料庫的資料無關 應該是把上次抽的值多定義出一個變數 寫一段判斷不重複的句子除非他有要每個地圖分開算 那我就不知道他們是怎麼寫的
作者: marx93521 (<阿ㄉ一ㄥˋ>) 2017-06-23 18:18:00
或許真的有可能 排隊機制還要講求效率 或許BZ有一套自
作者:
ilohoo (ilohoo)
2017-06-23 18:19:00忘記把這項功能寫在工作室的白板上
作者: marx93521 (<阿ㄉ一ㄥˋ>) 2017-06-23 18:19:00
己的演算法認為能兼顧隨機性跟效率
我覺得單純只是他們都在忙highlight的新功能XD
99個bug 修正一個放上更新檔 還有255個bug
作者:
danielqdq (摸射裏Moxury)
2017-06-24 10:13:00樓上崩潰屁 就是bz的問題了
作者:
a8500249 (拍拍說再給他們一次機會)
2017-06-25 23:40:00是bz問題啊 但所謂的護航不是在回應 '沒有很難吧？'這種推文嗎xD