Re: [閒聊] 藍帖翻譯~ 不要在囤卡包了..

看板Hearthstone作者 (kons)時間12年前 (2014/01/08 14:58), 編輯推噓56(58推 2噓 91→)
留言151則, 58人參與, 最新討論串2/4 (看更多)
※ 引述《powordisland (豹子~)》之銘言： : 將來的內容問題： : 有些玩家攢了一堆包不開打算等開新卡了 : 再開。 : 包裡的有什麼卡，是在獲得包的瞬間就決定了麼?如果不是，那是什麼時候決定的? 　　 : 解答：現在攢的包只有現在存在的卡。如果你一年後打開，它不會包含新卡。 : 如果這篇翻譯沒有翻錯~ 或者是消息正確 : 現在囤的卡包 恩... 沒有用 你不會開到"新卡".. 我對程式語言不是很熟，有錯請見諒 但我認為當下玩家獲得的卡包，就像薛丁格的貓一樣 不去打開永遠不知道裡面的情況， 會得到什麼卡片是在開卡包的當下程式運算決定的。 也就是系統只在的帳戶裡記錄了， kons擁有一個未開卡包 而不是kons擁有一個未開卡包，裡面有 紅龍 炎魔 安東尼達斯 霍格 佛丁 如果只記載未開卡包數量，那程式儲存很容易，只要一組資料紀錄數量就好， 得到什麼卡，開卡包時再交由程式運算決定，簡單完美。 如果得到卡包的同時程式就已經運算好裡面裝那些卡 那每一個卡包就需要額外儲存一個資料，有四十個未開卡包，就有四十組資料 我想BZ不會用這麼笨的方式。 除非之後爐石戰記推出的卡包有所分別 例如現在的卡包是V1包，之後有包含新卡片的叫V2包 這樣帳戶的紀錄就會變成有多少類別的卡包，就有多少組紀錄 如kons有V1卡包 兩包未開 V2卡包 三包未開 然後開V1卡包時用A邏輯去判斷會得到什麼卡，開V2卡包就用B邏輯 這樣也不算太困難。 只是隨著遊戲不斷擴充，以後卡包越出越多種，維護起來可能比較辛苦。 只是目前開卡包的介面，除非改寫， 否則系統要怎麼判定你現在要開的是V1卡包還是V2卡包呢？ 謝謝。 -- 至今我仍然深深相信，我是個帥哥，不過是量子力學定義中的帥哥。 當沒人觀測我的時候，我肯定是全地球最帥的男人。 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 123.194.32.106
推
01/08 15:00, , 1F
你也可以不用管那些~ 開心玩就好了~
01/08 15:00, 1F
推
01/08 15:01, , 2F
照籃帖講得，是買的當下就決定好卡包內的卡了
01/08 15:01, 2F
推
01/08 15:01, , 3F
不一定吧，你又不知道背後是怎麼寫的 話說你多加卡
01/08 15:01, 3F
→
01/08 15:02, , 4F
片的資料 那也不會占多少空間好嗎
01/08 15:02, 4F
→
01/08 15:02, , 5F
牌庫都存在伺服器了，卡包只佔一點點而已，不用擔心
01/08 15:02, 5F
→
01/08 15:04, , 6F
他大可以直接出一個新的卡包物件類別吧 XD
01/08 15:04, 6F
→
01/08 15:04, , 7F
重點不是數據大小，是維護問題啊
01/08 15:04, 7F
→
01/08 15:05, , 8F
如果卡包有記時間的話也許可以用這個去判定隨機範圍
01/08 15:05, 8F
→
01/08 15:06, , 9F
我是覺得每一個卡包要佔一個儲存格，很不科學
01/08 15:06, 9F
→
01/08 15:07, , 10F
會造成維護問題
01/08 15:07, 10F
推
01/08 15:07, , 11F
每張卡片設個編號 每個卡包也就5個號碼而已
01/08 15:07, 11F
推
01/08 15:07, , 12F
記錄卡片發行日跟卡包購買日
01/08 15:07, 12F
→
01/08 15:07, , 13F
今天全伺服器有一萬包未開卡包，就有一萬筆資料
01/08 15:07, 13F
→
01/08 15:07, , 14F
只會random購買日之前發售的卡片就可以吧
01/08 15:07, 14F
這種做法沒有比較科學，重點不是在於紀錄的長短，現在硬碟那麼大 而是每一個卡包就有一組獨立資料，是很可怕的一件事情 有一百萬組未開卡包，就有一百萬組資料，這系統維護是很可怕的
推
01/08 15:07, , 15F
反正到時候再把介面改一改出現各式各樣的卡包就好了
01/08 15:07, 15F
我覺得這是比較可能的做法，從卡包類別分 ※ 編輯: kons 來自: 123.194.32.106 (01/08 15:10)
→
01/08 15:09, , 16F
只儲存文字檔根本沒佔多少空間
01/08 15:09, 16F
推
01/08 15:09, , 17F
百分之八百是開啟的當下計算 謝謝
01/08 15:09, 17F
推
01/08 15:09, , 18F
但你要想，如果每次開卡包都要伺服器隨機一次，
01/08 15:09, 18F
→
01/08 15:10, , 19F
佔用的伺服器資源是很恐怖的
01/08 15:10, 19F
→
01/08 15:10, , 20F
之前競技場BUG~ 還沒開包卡片就會進牌庫拉
01/08 15:10, 20F
推
01/08 15:10, , 21F
交易安全的考量，每個包至少都會有一個id才對
01/08 15:10, 21F
→
01/08 15:10, , 22F
所以是拿到包的時候就已經決定了
01/08 15:10, 22F
推
01/08 15:10, , 23F
沒有人是背後的designer 沒什麼百分之八百的東西
01/08 15:10, 23F
→
01/08 15:11, , 24F
任何設計都會有他的考量 如果能佔些空間 而減少一些
01/08 15:11, 24F
推
01/08 15:11, , 25F
如果是別家公家可能會有儲存空間的問題 但B社沒問題
01/08 15:11, 25F
→
01/08 15:11, , 26F
那不如用空間換取CPU資源，反正BZ錢多夠買硬碟
01/08 15:11, 26F
推
01/08 15:11, , 27F
得到卡包當下隨機跟開的時候隨機對伺服器有差嗎??
01/08 15:11, 27F
→
01/08 15:11, , 28F
Id就很可能是開出來的seed
01/08 15:11, 28F
推
01/08 15:11, , 29F
產生卡包的同時就決定了內容物為何才好維護
01/08 15:11, 29F
→
01/08 15:11, , 30F
換取一些防禦措施 也是有可能
01/08 15:11, 30F
→
01/08 15:12, , 31F
這東西沒啥吧 一堆遊戲當場打怪當場噴東西 會有人在
01/08 15:12, 31F
→
01/08 15:12, , 32F
意伺服器負擔太重嗎
01/08 15:12, 32F
→
01/08 15:12, , 33F
而且買卡包的等待畫面不會讓使用者有等很久的感覺
01/08 15:12, 33F
推
01/08 15:14, , 34F
卡包只要記個購買時間 就可以解決很多問題
01/08 15:14, 34F
→
01/08 15:14, , 35F
伺服器Loading這種用錢就能解決的問題根本不是問題..
01/08 15:14, 35F
推
01/08 15:15, , 36F
如果你讓使用者去"啟動"隨機選牌功能 就有被洗的可能
01/08 15:15, 36F
→
01/08 15:15, , 37F
如果依暗黑的設計...那就是得到當下數值就決定好了
01/08 15:15, 37F
還有 74 則推文
還有 4 段內文
噓
01/08 16:44, , 112F
也可以只加一個得到時間的Tag，用時間控制就好
01/08 16:44, 112F
推
01/08 16:45, , 113F
一般設計是開的時候才決定 如果目前不缺卡可以囤看看
01/08 16:45, 113F
→
01/08 16:46, , 114F
如果出新卡時發現玩家囤了很多 肯定會寫卡牌包V2
01/08 16:46, 114F
→
01/08 16:46, , 115F
要控制舊包開舊卡的方式太多了
01/08 16:46, 115F
推
01/08 16:48, , 116F
分開抽也比較有趣吧 不然一直抽魔塵感覺也不好ww
01/08 16:48, 116F
→
01/08 16:48, , 117F
有直接的方法基本上不會特地繞遠路走另一條
01/08 16:48, 117F
→
01/08 16:48, , 118F
控制的方法的確很多 但一開始不太可能這樣寫自找麻煩
01/08 16:48, 118F
推
01/08 16:50, , 119F
為何新卡包的ID要跟舊卡包一樣?
01/08 16:50, 119F
推
01/08 17:00, , 120F
其實還好你就當他已經進你的牌庫但是沒有被enable
01/08 17:00, 120F
→
01/08 17:01, , 121F
沒被enable的牌不要算你的配對潛值跟顯示卡牌簿
01/08 17:01, 121F
→
01/08 17:01, , 122F
資料量並不用分開放也不會多多少
01/08 17:01, 122F
推
01/08 17:14, , 123F
說真的..這個資料量非常非常的小..一個卡包1kB都不到
01/08 17:14, 123F
推
01/08 17:22, , 124F
硬碟便宜的要死誰管這一點資料量阿
01/08 17:22, 124F
→
01/08 17:31, , 125F
比起D3 卡包資料更少 D3物品都能掉落時就決定數值
01/08 17:31, 125F
→
01/08 17:31, , 126F
卡包怎麼可能無法這麼做...
01/08 17:31, 126F
→
01/08 17:34, , 127F
真的說起來，D2時期就已經沒有這問題了...
01/08 17:34, 127F
→
01/08 17:35, , 128F
當時有些人會刻意不去鑑定物品，然後整批交易讓買方
01/08 17:35, 128F
→
01/08 17:36, , 129F
自己去開獎，如果有有問題當時也都該發現了...
01/08 17:36, 129F
推
01/08 17:51, , 130F
藍帖並沒有說當下就決定裡面的卡，只說現在的卡包
01/08 17:51, 130F
→
01/08 17:51, , 131F
只能開到現有的卡，說不定以後會出電競包、傳奇包.等
01/08 17:51, 131F
推
01/08 17:56, , 132F
很有可能卡包+time stamp來區分內容
01/08 17:56, 132F
推
01/08 18:14, , 133F
"交易"這種事情 當然是要當下就完成 把你想的事情
01/08 18:14, 133F
→
01/08 18:14, , 134F
乘以數十萬數百萬交易次數規模去想像 當下就完成最好
01/08 18:14, 134F
→
01/08 18:15, , 135F
以blizzard長久的經驗 每一樣東西出生就被track
01/08 18:15, 135F
→
01/08 18:15, , 136F
沒理由開包時做隨機 何況做隨機本身就很複雜
01/08 18:15, 136F
→
01/08 18:55, , 137F
D3對比就很清楚 裝備有多少數值可以鑑定前就決定好
01/08 18:55, 137F
→
01/08 18:55, , 138F
為啥卡包不行..
01/08 18:55, 138F
→
01/08 18:56, , 139F
你屯40個卡包 相對D3也才存40件裝備不鑑定..
01/08 18:56, 139F
推
01/08 19:05, , 140F
小品遊戲類的爐石 資料量怎麼樣都比不上D3或WOW啊
01/08 19:05, 140F
推
01/08 19:12, , 141F
在資料庫中 你購買的卡包資料列中多一欄記錄卡包批號
01/08 19:12, 141F
→
01/08 19:13, , 142F
他就知道用哪個批號裡的卡牌亂數給你了吧
01/08 19:13, 142F
→
01/08 19:28, , 143F
寫入卡牌種類也不用多少容量 幾組數字就結束了
01/08 19:28, 143F
推
01/08 19:32, , 144F
你說的那個「不可能」剛好就是正確答案耶XDD
01/08 19:32, 144F
→
01/08 19:53, , 145F
講那麼多沒用 存錢最靠譜
01/08 19:53, 145F
→
01/08 19:56, , 146F
他卡包要生出什麼卡可以考一個seed決定 就一個數字
01/08 19:56, 146F
→
01/08 19:58, , 147F
這種獲得卡包的東西一定會有紀錄 真的不差這一點資料
01/08 19:58, 147F
噓
01/08 20:07, , 148F
開頭說自己程式不熟，下面腦補一大堆...
01/08 20:07, 148F
推
01/09 01:13, , 149F
D2裝備一掉落就決定了 鑑定後的東西回朔也一樣
01/09 01:13, 149F
推
01/09 02:41, , 150F
機率只會大於零，且小於等於一，所以百分之八百就是
01/09 02:41, 150F
→
01/09 02:41, , 151F
不可能的意思吧XD
01/09 02:41, 151F
‣ 更多 kons 的文章
文章代碼(AID): #1IpFSZn- (Hearthstone)
討論串 (同標題文章)
以下文章回應了本文 (最舊先)：
完整討論串 (本文為第 2 之 4 篇)：
排序： 最新先 | 最舊先 | 留言數
在新視窗開啟完整討論串 (共4篇)
‣ 更多 kons 的文章
文章代碼(AID): #1IpFSZn- (Hearthstone)