Re: [閒聊] 希臘落珠的新證據！消失

看板ToS作者時間10年前 (2013/09/15 22:58), 編輯推噓6(6推 0噓 39→)
留言45則, 9人參與, 最新討論串3/5 (看更多)
※ 引述《FableKevinS (FableKevinS)》之銘言： : 大家都知道只要一進關 : 沒有網路也可以照樣玩 : 中間會掉什麼卡都確定 直到結算畫面才需要網路 : 所以才會有掉落卡的偷看程式.. : 換句話說 一進關卡 所有參數都已經確定了 : 掉什麼卡 落珠的參數 等等 : 從這個影片的例子來看 很明顯落珠的方式一定有公式可循 : 這是隨機嗎？ 一般人可能說絕對不是 : 但從程式的觀點來講 : 可能是在取亂數的時候 忘了增加一些變動的參數了 ( 時間 ip .. etc : 才會每次的落珠方式都一樣 （ 並不是沒取亂數 而是取亂數方式都一樣 結果自然一樣 : 當然以上只是我的臆測 : 不過可以確定的是 : 這個遲早會被改掉的... : 但就實際面來講 也不能有效運用啊 大家看看就好 其實這個問題 早在我刷首刷的時候就有這個疑問 記得首刷的的幾個教學 指引的路徑都一樣 落珠也都一樣 所以大膽推測 落珠應該是固定的公式 固定的消珠路徑會得到固定的盤面，說不定開局的盤面 也是固定的種類隨機選一個，而教學模式則是指定某一固定個盤面 -- ※ 發信站: 批踢踢實業坊(ptt.cc)
→
09/15 22:59, , 1F
那是因為要設計導引才故意的吧... 而且最後落珠會隨
09/15 22:59, 1F
→
09/15 22:59, , 2F
機
09/15 22:59, 2F
推
09/15 22:59, , 3F
我依稀記得教學的落珠有點不一樣耶@@
09/15 22:59, 3F
推
09/15 22:59, , 4F
這是有可能的 不過用機率統計來看 能符合不同色3連的也不少
09/15 22:59, 4F
推
09/15 23:09, , 5F
基本應該是會在有所謂的落珠表...但抓取表的依據就不確定了
09/15 23:09, 5F
→
09/15 23:10, , 6F
會有表的存在主要應該是為了要減少運算畢竟要每一格都隨機
09/15 23:10, 6F
推
09/15 23:11, , 7F
記得全體攻擊完的火魔女嗎？用三顆火珠打的，我曾經少
09/15 23:11, 7F
→
09/15 23:11, , 8F
一掉一顆火珠就卡死了-_-
09/15 23:11, 8F
→
09/15 23:11, , 9F
先撇開做不做得到..光手機CPU 就忙死了= ="除了要繪圖
09/15 23:11, 9F
→
09/15 23:12, , 10F
還要順便管你其他程式運作...所以最簡單作法就是先做好夠多
09/15 23:12, 10F
→
09/15 23:13, , 11F
30格填滿的落珠表，每次玩家一清掉就取其表直接落下
09/15 23:13, 11F
→
09/15 23:15, , 12F
因為人的想法本身就會構成落珠表真正落下後其最大變因
09/15 23:15, 12F
→
09/15 23:15, , 13F
樓上這樣不就更麻煩，你又不知道玩家一次會消幾個幾排
09/15 23:15, 13F
→
09/15 23:16, , 14F
(除非你每一輪都能清乾淨盤面)那這樣的話問題就在於如何取得
09/15 23:16, 14F
→
09/15 23:16, , 15F
直接random個1~5 map到各顏色不是更快
09/15 23:16, 15F
→
09/15 23:18, , 16F
每一張落珠表的關係，PS依此類推 希臘跟北歐應該有專屬自己
09/15 23:18, 16F
→
09/15 23:18, , 17F
的落珠表
09/15 23:18, 17F
→
09/15 23:19, , 18F
TAI 管玩家消幾排反正他消了就把落珠表依序填下去，填完看要
09/15 23:19, 18F
→
09/15 23:19, , 19F
痾... 那單希臘你要怎麼講XD
09/15 23:19, 19F
→
09/15 23:20, , 20F
直接換新的表還是把新的落珠表填寫在將要落下的表內
09/15 23:20, 20F
→
09/15 23:21, , 21F
你覺得去計算消去後的空位 要填入你所謂的表 比較快嗎
09/15 23:21, 21F
→
09/15 23:21, , 22F
就分成兩類就好單希 雙希 4珠一算 3珠一算 總共也才4類
09/15 23:21, 22F
→
09/15 23:22, , 23F
你這樣也只是省了第一次RANDOM的時間吧，之後你說的填表
09/15 23:22, 23F
→
09/15 23:22, , 24F
回TAI我是覺得比較可能做法是每次玩家一消除就換新的表
09/15 23:22, 24F
→
09/15 23:22, , 25F
也和RANDOM沒有兩樣，RANDOM也是取SEED，你的填表也是一
09/15 23:22, 25F
→
09/15 23:23, , 26F
種SEED，個人認為不會特別做這種事
09/15 23:23, 26F
→
09/15 23:24, , 27F
應該說要看他後續表取得運算了，但直接取表應該比全部隨機快
09/15 23:24, 27F
→
09/15 23:25, , 28F
畢竟假設每次取表都得重新隨機好了也才一次做一次隨機運算
09/15 23:25, 28F
→
09/15 23:27, , 29F
接下來就是填表了，若是全部隨機平均要做15個隨機運算加填表
09/15 23:27, 29F
→
09/15 23:28, , 30F
但不管怎樣若真要破解後續盤面我覺得很有難度= ="
09/15 23:28, 30F
→
09/15 23:30, , 31F
但表的話代表每一個群組應該不會超過50種表才是(隨機運算+人
09/15 23:30, 31F
→
09/15 23:31, , 32F
這兩種變因已經足以應對這樣的隨機性才對~~甚至可以推至20種
09/15 23:31, 32F
→
09/15 23:31, , 33F
random也可以一次產生一大串數字，另外你這個假設是建立
09/15 23:31, 33F
→
09/15 23:32, , 34F
所以才會造就原PO那種現象(同樣落珠方式~
09/15 23:32, 34F
→
09/15 23:32, , 35F
在CPU跑不動的情況下，我不認為就算是一顆一顆隨機加處
09/15 23:32, 35F
→
09/15 23:32, , 36F
理，現在的手機CPU會跑不動
09/15 23:32, 36F
→
09/15 23:33, , 37F
我只說忙死，不代表不行阿..我之前想找一下桌電跟手機CPU效
09/15 23:33, 37F
推
09/15 23:34, , 38F
...看到六星主角的技能 你還沒想到怎麼作最省嗎
09/15 23:34, 38F
→
09/15 23:35, , 39F
能比較一直找不到，但可以預估應該還好畢竟是模擬器可以負擔
09/15 23:35, 39F
→
09/15 23:35, , 40F
把上面的珠子利用那個seed生成不就好了 再用mod跑迴圈
09/15 23:35, 40F
→
09/15 23:35, , 41F
LUKE 大你是問我還是?
09/15 23:35, 41F
→
09/15 23:36, , 42F
這樣講的話，你所謂的表應該可以在client端挖得到吧?
09/15 23:36, 42F
→
09/15 23:37, , 43F
那你要不要少說點，去挖一個來瞧瞧不就解了
09/15 23:37, 43F
推
09/15 23:38, , 44F
假設他真是這樣做的話，那就是YES。重點是他怎生成該場的表
09/15 23:38, 44F
→
09/15 23:43, , 45F
等我論文搞定我再來玩反編譯APK 跟JAVA吧...
09/15 23:43, 45F
‣ 更多 letni 的文章
文章代碼(AID): #1IDSi1vs (ToS)
討論串 (同標題文章)
本文引述了以下文章的的內容：
以下文章回應了本文：
完整討論串 (本文為第 3 之 5 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共5篇)
‣ 更多 letni 的文章
文章代碼(AID): #1IDSi1vs (ToS)