PTT動漫區 / C_Chat (希洽)

Re: [FGO] 石頭回收完了 會顯示負數

看板C_Chat (希洽)作者 (夕提)時間19小時前 (2024/12/27 16:08), 18小時前編輯推噓11(11推 0噓 43→)
留言54則, 11人參與, 17小時前最新討論串5/6 (看更多)
※ 引述《allen20937 (旅行者)》之銘言： : ※ 引述《seer2525 (月月)》之銘言： : : 標題: Re: [FGO] 石頭回收完了 會顯示負數 : : 時間: Fri Dec 27 12:57:25 2024 : : 你跟這張圖的主角應該比FGO工程師還厲害 : : https://i.imgur.com/BTC2EYz.png
: : 明明就寫得很清楚 : : 抽之前有償26 無償-149 : : 抽下去會變有償23 無償-149 : : 這就是扣有償啊 看不懂有償無償意思就算了 : : 不會連有跟無都分不出來吧 : 首先我要先澄清這篇文章不是在說實際上FGO就是這樣，我沒玩宇宙神遊也不在乎這件事 : 情到底是真是假。 : 我只是想解釋當某種情況下出現免費石變負數後還越扣越負這種Bug在遊戲程式邏輯上 : 是完全說得通，實際上也有可能會發生。 : 但我沒有說FGO就是這種情況 : 但我沒有說FGO就是這種情況 : 但我沒有說FGO就是這種情況 : 很重要所以說三次，免得有人亂扣帽子說我就是在指宇宙神遊 : 首先要先解釋的是通常這種結果預測的UI顯示出來的數字是工程師預期玩家做了某些動作 : 之後會產生這樣的結果。 : 因為實際上玩家還沒行動，所以一切的數字都只是預測，而不是已成事實的結果。 : 有做過實驗的人都知道吧，預測跟實際出來的結果有差別根本是家常便飯 : (我沒有說這種差別在手遊上很普遍，只是提出這種情況有可能會在現實中發生) : 假設你身上有免費石A顆，課金石B顆，抽一次要花費X顆好了 : ・UI邏輯 : { : 如果玩家的免費石A < X : 顯示:A數量不變，B-X → 免費石數量不夠，消耗課金石 : (這邊實際上還要加入檢查課金石數量的條件判斷，但我省略了) : 否則顯示:A-X，B數量不變 → 滿足一抽需要的數量，優先消耗免費石 : } : 但像我剛才所說的這充其量只不過是預測，不是實際行動後的結果，實際上要等到玩家按 : 下了按鈕後才會執行轉蛋抽取的程式。 : 10個公司可以寫出11種不同的程式碼，如果有間公司把UI跟轉蛋執行的處理分開來寫的 : 話，可能出現下面這種東西 : ・抽取邏輯 : { : 如果玩家免費石A >= 0，且 A < X : 執行:扣除課金石X顆，且抽取轉蛋 → 免費石數量不夠，消耗課金石 : (一樣省略了課金石的數量判斷) : 否則執行:扣除免費石X顆，且抽取轉蛋 → 不考慮負數的情況下，A肯定會大於等於X : } : 上面兩種邏輯在正常情況下都是可以運作也不會出錯，但如果像這次一樣工程師沒事先 : 考慮到石頭變負數的情況，下面的情況就有問題了，因為免費石A是負的，所以直接執行 : 了下面的扣除免費石X顆且抽取轉蛋的處理。 不好意思小弟是文組，可能不太了解工程師的邏輯 想問一下如果工程師沒有考慮到石頭有負數的可能 為什麼要在判斷式寫if(免費石A >= 0)？ : 所以我說這種情況是「有可能」，不表示宇宙神遊的程式就是這樣寫 : 會不會發生端看工程師怎麼寫，但要說一定不會發生的話那就太過武斷了 : 解Bug的時候自認絕對不會出問題的地方就是問題所在的情況我實在見得太多了 : : 推 nineflower: 笑死，還在凹，你職業是檢察官喔 12/27 13:14 : 不是，我的職業是遊戲工程師。 : 文章有錯誤的話歡迎指證，絕對不會凹 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 42.77.68.133 (臺灣) ※ 文章網址: https://www.ptt.cc/bbs/C_Chat/M.1735286934.A.3F0.html
推
12/27 16:13, 19小時前 , 1F
正常是直接指定數值類型就好，比如uint這種沒負數的
12/27 16:13, 1F
→
12/27 16:13, 19小時前 , 2F
這樣也不用擔心會發生邏輯錯誤來著，不過這不重要了
12/27 16:13, 2F
推
12/27 16:17, 18小時前 , 3F
因為那行的邏輯只是在判斷免費石夠不夠而已
12/27 16:17, 3F
如果是判斷免費石夠不夠，用免費石A<X就好了吧？ 工程師寫的這段 如果玩家免費石A >= 0，且 A < X 不就代表　免費石為正數，且免費石低於X 那麼既然都特地寫條件判斷免費石是否為正數了 為什麼會說沒考慮到變負數的情況？ ※ 編輯: fish770130 (60.249.144.164 臺灣), 12/27/2024 16:22:21
推
12/27 16:20, 18小時前 , 4F
邏輯是有石頭才讓你抽 所以只判斷你石頭夠不夠
12/27 16:20, 4F
→
12/27 16:22, 18小時前 , 5F
多一個>0是fgo有分有償跟無償石 可能有總體石夠但無償不夠
12/27 16:22, 5F
推
12/27 16:23, 18小時前 , 6F
問題是有有償石還是可以抽啊=3= 幹嘛if免費石，直接when有
12/27 16:23, 6F
→
12/27 16:23, 18小時前 , 7F
償或無償就好了，大師就是大師
12/27 16:23, 7F
推
12/27 16:24, 18小時前 , 8F
有寫判斷免費石為正數 不表示考慮到免費石為負數的情況
12/27 16:24, 8F
哦... 我想說寫if(A>=0 and A<X) OOO else XXX 應該會考慮到如果A<0就會去執行else...
→
12/27 16:25, 18小時前 , 9F
根本不需要在判斷式這樣算正數，事實也是總計負數也給抽
12/27 16:25, 9F
→
12/27 16:25, 18小時前 , 10F
樓上說的對 但現實就是有人可能這樣寫
12/27 16:25, 10F
→
12/27 16:26, 18小時前 , 11F
這就是上一篇在凹的問題 講自己不是指fgo但一堆前提又直接
12/27 16:26, 11F
→
12/27 16:26, 18小時前 , 12F
套fgo的情況 混在一起做大雜燴
12/27 16:26, 12F
→
12/27 16:27, 18小時前 , 13F
當然有可能，但不需要紮個笨蛋稻草人然後打得很開心
12/27 16:27, 13F
→
12/27 16:27, 18小時前 , 14F
他文章說fgo工程師沒考慮到負數問題 可是圖中石頭明明就有
12/27 16:27, 14F
→
12/27 16:27, 18小時前 , 15F
扣對 然後開始硬凹
12/27 16:27, 15F
→
12/27 16:27, 18小時前 , 16F
實際就沒有靶在那邊，也可以嗨~ zz
12/27 16:27, 16F
→
12/27 16:28, 18小時前 , 17F
表示他自己為了辯自己邏輯都混成一團了
12/27 16:28, 17F
推
12/27 16:28, 18小時前 , 18F
前面不是有說他扣對嗎? 只是有人轉圖講錯
12/27 16:28, 18F
※ 編輯: fish770130 (60.249.144.164 臺灣), 12/27/2024 16:30:46
→
12/27 16:29, 18小時前 , 19F
他這個例子就是明明自己要舉一個假設 結果扣石頭的想法還
12/27 16:29, 19F
→
12/27 16:29, 18小時前 , 20F
原圖就沒看到下面列有償無償，只看到上面總計就嗨了
12/27 16:29, 20F
→
12/27 16:29, 18小時前 , 21F
非員工正常也看不到程式碼邏輯，所以沒法確認是怎樣吧
12/27 16:29, 21F
→
12/27 16:29, 18小時前 , 22F
是套用fgo這種會先扣無償再扣有償的作法
12/27 16:29, 22F
→
12/27 16:29, 18小時前 , 23F
上車就算了還要搞一篇來假設倒底要怎麼出錯，阿就沒出錯zzz
12/27 16:29, 23F
推
12/27 16:30, 18小時前 , 24F
現在才發現原來中午還在爭"有可能"XD 也太歡樂了吧
12/27 16:30, 24F
→
12/27 16:31, 18小時前 , 25F
雖然她們系統爛但也不至於搞到抽抽扣錯石拉
12/27 16:31, 25F
→
12/27 16:31, 18小時前 , 26F
這也不用通靈吧 結果都出來了還在假設一堆
12/27 16:31, 26F
→
12/27 16:31, 18小時前 , 27F
宇宙神遊屎的地方有一堆 偏要拿這種有長期營運最不可能出
12/27 16:31, 27F
→
12/27 16:32, 18小時前 , 28F
錯的地方酸 又雲又蠢被抓到還想顧面子
12/27 16:32, 28F
→
12/27 16:33, 18小時前 , 29F
一般來說有償跟無償石存的欄位不同，不管前面判斷是怎
12/27 16:33, 29F
→
12/27 16:33, 18小時前 , 30F
FGO文日常了 又雲又愛高談闊論酸
12/27 16:33, 30F
→
12/27 16:33, 18小時前 , 31F
樣，不太可能發生抽有償扣無償或者反過來的狀況
12/27 16:33, 31F
→
12/27 16:33, 18小時前 , 32F
除非這程式很久很久之前就寫反了
12/27 16:33, 32F
→
12/27 16:34, 18小時前 , 33F
就很有趣 搞錯造謠的都下車了 結果還有人另外開XD
12/27 16:34, 33F
推
12/27 16:34, 18小時前 , 34F
先不講可能性，但之前每日一有償跟只負無償做得出來，就能
12/27 16:34, 34F
→
12/27 16:34, 18小時前 , 35F
就硬要扯罷了 現在哪個UI資料不是API傳過來接的 又不是十
12/27 16:34, 35F
→
12/27 16:35, 18小時前 , 36F
理解公司沒那麼蠢了吧，還可以if那麼多，只能期望他不在我
12/27 16:35, 36F
→
12/27 16:35, 18小時前 , 37F
玩的遊戲附近
12/27 16:35, 37F
推
12/27 16:36, 18小時前 , 38F
年前那種還會把資料放在客戶端的
12/27 16:36, 38F
推
12/27 16:37, 18小時前 , 39F
我也只是單純回答這篇的問題
12/27 16:37, 39F
推
12/27 16:37, 18小時前 , 40F
某a: 欸你這個程式output錯了 工程師f:我驗算完沒錯啊,
12/27 16:37, 40F
→
12/27 16:37, 18小時前 , 41F
是不是你看錯output format了 某a:你確定你的output是
12/27 16:37, 41F
→
12/27 16:37, 18小時前 , 42F
正確的嗎?我懷疑你程式邏輯寫錯才造成這個output看起來
12/27 16:37, 42F
→
12/27 16:37, 18小時前 , 43F
是對的 工程師f:所以哪裡有錯你能舉例嗎? 某a:我是說你
12/27 16:37, 43F
→
12/27 16:37, 18小時前 , 44F
有可能會寫錯不是說你真的寫錯啊,你這麼生氣幹嘛 工程
12/27 16:37, 44F
→
12/27 16:37, 18小時前 , 45F
師f:神經病
12/27 16:37, 45F
→
12/27 16:37, 18小時前 , 46F
a<0確實會去執行else 但不表示else內執行的是你針對免費
12/27 16:37, 46F
→
12/27 16:38, 18小時前 , 47F
架構老又大的話是可能有些細節或特殊狀況，像這次BUG
12/27 16:38, 47F
→
12/27 16:38, 18小時前 , 48F
石為負時要處理的狀況
12/27 16:38, 48F
→
12/27 16:38, 18小時前 , 49F
但最基本的東西不太可能出問題的，畢竟這一按就知道
12/27 16:38, 49F
→
12/27 16:52, 18小時前 , 50F
上面那種人還真的遇過 "我過程都對可是結果錯"
12/27 16:52, 50F
→
12/27 16:52, 18小時前 , 51F
"你是怎麼做對的 是不是過程有問題"
12/27 16:52, 51F
→
12/27 17:26, 17小時前 , 52F
這麼簡單的東西 為什麼可以討論這麼多...
12/27 17:26, 52F
→
12/27 17:53, 17小時前 , 53F
因為有沒寫程式的人在談啊 其實邏輯不好面試或試用期就直
12/27 17:53, 53F
→
12/27 17:53, 17小時前 , 54F
接篩掉了 聽這些鬼扯邏輯很痛苦
12/27 17:53, 54F
‣ 更多 fish770130 的文章
文章代碼(AID): #1dRc2MFm (C_Chat)
C_Chat 近期熱門文章
更多 近期熱門文章 >>
PTT動漫區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 fish770130 的文章
文章代碼(AID): #1dRc2MFm (C_Chat)