PTT遊戲區 / ToS (神魔之塔(Tower of Saviors))

Re: [心得] 官方送抽卡之都市傳說破除

看板ToS (神魔之塔(Tower of Saviors))作者 (kevinjkckung)時間12年前 (2013/12/27 21:54), 編輯推噓18(20推 2噓 15→)
留言37則, 23人參與, 最新討論串3/5 (看更多)
以下是不負責任 感覺文 首先針對主題部分 1. 一開始就決定好是哪一張 2. 獎勵抽卡也是隨機 今天如果我是公司的人 我會選擇2 為什麼? 假設今天使用帳有100個帳號 執行一的動作需要去跑100個RANDOM後執入數據庫 今天神魔帳號裡面將近快有一半的帳號是免洗帳號 因此選擇2，所需要執行的RANDOM數 一定≦100 結論： 資料執行的次數減少 則伺服器壽命增加 (兩種機率一樣 =================分隔線==================== 這邊另外探討 有關抽獎的部分 以下我將會使用 RO 腳本(Script) 的簡易寫法說明我自己的想法 //=================Script1=================== check 抽卡 == AA /確認抽卡種類 可能有1 友情抽 2石抽 3活動 if 抽卡 == 1 goto friend /如果 抽卡種類是1 則執行firend指令 if 抽卡 == 3 goto activities set magic,RANDOM(0,9) /設定一個參數magic 並隨機從0~9取一個數字出來 if magic == 1,2,3,4,5,6 goto 巨像 if magic == 7,8,9 goto 防龍 if magic == 0 goto 狂魔 /同上面 參數對應 則執行該項 .....etc //=================Script1End=============== 這個是 獎勵抽不吃加倍的寫法 上面抽到的是 10% 也就是獎勵抽及平常時候用的指令 活動期間 則要去執行 activities的指令 因為當狂魔機率提升兩倍時 其他機率要下降才能維持100% 則需要另外寫一套指令 另一種 //=================Script2=================== check 抽卡 == AA /確認抽卡種類 可能有1 友情抽 2石抽 3活動 if 抽卡 == 1 goto friend /如果 抽卡種類是1 則執行firend指令 set magic,RANDOM(0,19) /設定一個參數magic 並隨機從0~19取一個數字出來 if magic == 0~10 goto 巨像 if magic == 11~16 goto 防龍 if magic == 17,18,19,20 goto 狂魔 /同上面 參數對應 則執行該項 狂魔： if 抽卡 == 2 get item ID 1,1,1 /如果是石抽 則抽出一張狂魔 1張,1等,技1 if 抽卡 == 3 get item ID 1,30,1 /如果是活動 則抽出一張狂魔 1張,30等,技1 .....etc //=================Script2End=============== 以上是獎勵，活動都吃到狂魔兩倍的情況 但其實同樣是200% 每個人寫出來的設定其實都不太一樣 但老實說 這些東西只有親自去問設計的人才有辦法求證 不然其實程式碼可以利用一些指令 雖然結果可能雷同 但中間會出現很多錯覺 -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 1.173.111.234
→
12/27 21:56, , 1F
...
12/27 21:56, 1F
推
12/27 21:56, , 2F
嗯嗯 快推不然別人以為我們不懂
12/27 21:56, 2F
推
12/27 21:56, , 3F
嗯嗯 跟我想的一樣
12/27 21:56, 3F
推
12/27 21:56, , 4F
你這樣文組的會看不懂
12/27 21:56, 4F
文組的看得懂英文 看得懂中文 合在一起就看不懂了(被揍
推
12/27 21:57, , 5F
簡單的說不是一開始就決定的 詳情請參考source code (爆)
12/27 21:57, 5F
→
12/27 21:57, , 6F
if後面用goto 那下面不用放else
12/27 21:57, 6F
推
12/27 21:58, , 7F
真的
12/27 21:58, 7F
推
12/27 21:59, , 8F
看得懂給推
12/27 21:59, 8F
推
12/27 21:59, , 9F
else 沒用到
12/27 21:59, 9F
更正
推
12/27 21:59, , 10F
結論:這些東西只有親自去問設計的人才有辦法求證
12/27 21:59, 10F
推
12/27 22:00, , 11F
看不懂還是推！
12/27 22:00, 11F
→
12/27 22:00, , 12F
結論才是重點 這種沒辦法考究的 我們也只能瞎猜
12/27 22:00, 12F
推
12/27 22:03, , 13F
if uid=工讀生 then 加倍卡 else 巨像防龍妹子中國獸西方獸
12/27 22:03, 13F
推
12/27 22:04, , 14F
快推，不然人家會以為農科的不懂
12/27 22:04, 14F
→
12/27 22:05, , 15F
以前 我在家裡寫腳本 現在 我在學校寫程式
12/27 22:05, 15F
推
12/27 22:07, , 16F
12/27 22:07, 16F
推
12/27 22:07, , 17F
程式不太可能這樣寫，維護程度太低，修改很困難
12/27 22:07, 17F
只是隨便舉例 畢竟我寫的程式碼只是從RO私服腳本內學的(菸 我本身是商科的XD
→
12/27 22:07, , 18F
這裡面寫到亂數範圍是 9 ~ 500
12/27 22:07, 18F
原來有人有提供了 囧
推
12/27 22:10, , 19F
恩恩 我完全懂了
12/27 22:10, 19F
※ 編輯: kevinjkckung 來自: 1.173.111.234 (12/27 22:12)
推
12/27 22:14, , 20F
快推，不然人家以為法科的看不懂
12/27 22:14, 20F
推
12/27 22:17, , 21F
跟我想的一樣
12/27 22:17, 21F
推
12/27 22:19, , 22F
創1000隻帳號 先計算首抽比例 再算獎品比例大概可解XD
12/27 22:19, 22F
首抽"可能"又是另一個指令庫了
→
12/27 22:30, , 23F
不懂的東西就別亂說..前後都很明顯錯很大
12/27 22:30, 23F
是否能指出哪邊有錯?
推
12/27 22:32, , 24F
快推才不會讓人看扁商科
12/27 22:32, 24F
噓
12/27 22:49, , 25F
前面兩種方法資料處理量都是一樣，沒有減少，無關伺服壽命
12/27 22:49, 25F
推
12/27 22:53, , 26F
補推) 區別只是在request密集度而已，但利用維修事先偷跑
12/27 22:53, 26F
→
12/27 22:54, , 27F
減少伺服上限的負擔也是不無可能，只能說2是比較直覺作法
12/27 22:54, 27F
→
12/27 22:56, , 28F
至於後面兩段，程式肯定不是這樣寫
12/27 22:56, 28F
減少的是執行量 很多免洗 被放掉的帳號 在1裡面會去執行RANDOM決定卡片 但在2因為沒有從獎勵中拉出來 所以減少了RANDOM的執行 至於程式碼部分 我有說了 我是仿照RO私服腳本寫的 畢竟RO私服不是讀取C++ 所以有很多地方會有出入 但意思大概是這樣 ※ 編輯: kevinjkckung 來自: 1.173.111.234 (12/27 23:06)
→
12/27 23:27, , 29F
程式(的邏輯)肯定不是這樣寫，不懂你想表達的是什麼意思
12/27 23:27, 29F
噓
12/27 23:29, , 30F
抽個卡要檢查這麼多if完全是浪費效率
12/27 23:29, 30F
→
12/28 00:40, , 31F
不太懂兩種做法跟伺服器壽命有甚麼差
12/28 00:40, 31F
→
12/28 01:09, , 32F
IF超吃力的
12/28 01:09, 32F
推
12/28 02:03, , 33F
如果你只在意程式怎麼寫最好，那你就是個程式設計師
12/28 02:03, 33F
→
12/28 02:04, , 34F
但通常，不在意那些東西的，叫做「老闆」「主管」
12/28 02:04, 34F
→
12/28 02:04, , 35F
業務 就更不管那麼多 他只管有哪些功能 他比較好賣
12/28 02:04, 35F
→
12/28 02:05, , 36F
結論：這就是資訊業
12/28 02:05, 36F
→
12/28 02:06, , 37F
而且 誰能保證 寫這段東西的 是個商業邏輯好的RD呢？
12/28 02:06, 37F
‣ 更多 kevinjkckung 的文章
文章代碼(AID): #1IlOQBLE (ToS)
ToS 近期熱門文章
更多 近期熱門文章 >>
PTT遊戲區 即時熱門文章
更多 即時熱門文章 >>
‣ 更多 kevinjkckung 的文章
文章代碼(AID): #1IlOQBLE (ToS)