Re: [情報] 昨天生放送提到的的那些活動

看板PuzzleDragon作者 (緹)時間10年前 (2014/07/16 18:26), 編輯推噓15(15推 0噓 85→)
留言100則, 17人參與, 最新討論串3/3 (看更多)
: 台港區所謂的閹割問題吵很久了 : 不過並只要想辦合作活動就可以 日方跟台灣代理商談版權 : 這又要跑一段流程 : PADW台港區本來就沒有說要同步更新阿 : 更何況台港區負責發佈活動消息的FB官方 根本還沒放消息說台港區沒PADW : 預期到可能會爆炸的流量問題 先給日版的玩家玩 臭了嗎? : 韓版 美版假如都同步更新 獨留台港區那沒話說 可是現在沒消息美韓兩版同步吧? 只有我覺得先集中火力在推出自家版本更新後，再去搞其他版本比較「安全」嗎？ 這樣的大改版根本是把一個入口放兩個遊戲，金幣和石頭還要能互通， 一發生BUG可不得了了，說不定會發生早期回溯慘劇(???)， 雖然港台版日版是同一個伺服器上，但對口玩家不同，活動也不盡相同， 其實我是覺得還好啦...如果日版不幸發生大錯誤要維修個2~3天， 至少我們還可以切到港台版玩XD！(可以嗎? 另一個不同步的猜想是，7月底要開PADW，但G社又希望今年底前推出「中文化」 在中文部搞中文化的時候加一個PADW，系統還沒實際公開遊玩過的那種， 感覺會增加相關負責人員不少負擔吧？ 我是這麼猜想的，TvT -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 36.224.17.229 ※ 文章網址: http://www.ptt.cc/bbs/PuzzleDragon/M.1405506370.A.C0E.html
→
07/16 18:27, , 1F
同一伺服器，會日板運轉出問題，台港板還能玩嗎@@
07/16 18:27, 1F
推
07/16 18:27, , 2F
我覺得台版沒PADW可能還不是重點，重點是日版PADW延期
07/16 18:27, 2F
→
07/16 18:27, , 3F
有超豐富的補償，台版卻沒有這點（換帳號先不提了
07/16 18:27, 3F
→
07/16 18:28, , 4F
我是覺得的確該先專心做日本版本
07/16 18:28, 4F
→
07/16 18:28, , 5F
台版伺服器維修時 日版正常 很難想像是完全同伺服器
07/16 18:28, 5F
→
07/16 18:28, , 6F
另外日帳不能玩，台帳肯定也不能啊
07/16 18:28, 6F
→
07/16 18:28, , 7F
但是台版目前沒有任何關於這的相對應措施怪怪的
07/16 18:28, 7F
→
07/16 18:29, , 8F
蛤?台板沒那些問卷活動喔?
07/16 18:29, 8F
推
07/16 18:29, , 9F
在開之前 一切都是臆測 會不會打臉之後就知道了
07/16 18:29, 9F
→
07/16 18:29, , 10F
加上前面就有不對等案例(活動送石),會讓人覺得閹割正常
07/16 18:29, 10F
→
07/16 18:29, , 11F
但是bug問題真的需要重視一下
07/16 18:29, 11F
→
07/16 18:29, , 12F
應該說 他對日伺服器開了空頭支票 補三蛋龍是沒錯
07/16 18:29, 12F
→
07/16 18:29, , 13F
從頭到尾沒有提到台版阿 台版沒蛋龍很合理
07/16 18:29, 13F
推
07/16 18:30, , 14F
時光機有參考價值 但是不一定準
07/16 18:30, 14F
→
07/16 18:30, , 15F
日版伺服器異常 只補償日版 台版異常 也只補償台版阿
07/16 18:30, 15F
→
07/16 18:30, , 16F
當初台版剛上GOOGLEPLAY出事時不就是這樣
07/16 18:30, 16F
→
07/16 18:31, , 17F
之前問卷地城復刻的時候 時光機也沒講最後一天會加倍
07/16 18:31, 17F
推
07/16 18:31, , 18F
到底有沒有台日版啊 前面有板友說只是分台日登入口
07/16 18:31, 18F
→
07/16 18:31, , 19F
伺服器相同 但是 客戶端不同...
07/16 18:31, 19F
→
07/16 18:32, , 20F
既然如此 又何必補償"台灣登入口"呢?
07/16 18:32, 20F
→
07/16 18:33, , 21F
像IOS跟安卓 就是不同客戶端啊
07/16 18:33, 21F
推
07/16 18:33, , 22F
問題1:感謝祭PADW第一次宣佈延期送3石的時候日台版都有
07/16 18:33, 22F
推
07/16 18:33, , 23F
想成不同伺服器,但可以隨時移民比較好XD
07/16 18:33, 23F
→
07/16 18:33, , 24F
問題2:台版需要花更多時間準備PADW的話不也是延期的一種?
07/16 18:33, 24F
→
07/16 18:33, , 25F
記得之前有次安卓出錯 也是只有改安卓變成版號多一?
07/16 18:33, 25F
推
07/16 18:34, , 26F
sh 當初的三石 是一天一天送 還是一次送
07/16 18:34, 26F
→
07/16 18:34, , 27F
不過我沒想到回朔問題,如果日版回朔,那台日互玩的帳號會??
07/16 18:34, 27F
→
07/16 18:34, , 28F
再來 除了每天排好的送禮 如果是額外多出來的 就是單獨
07/16 18:34, 28F
→
07/16 18:34, , 29F
例如這次蛋龍就是除了石頭外 又有三顆蛋龍 是加送的
07/16 18:34, 29F
→
07/16 18:35, , 30F
加送的通常都有台日版區別
07/16 18:35, 30F
→
07/16 18:35, , 31F
像之前完CC幹他碼的IOS就爽領一堆石阿.安卓哭哭
07/16 18:35, 31F
→
07/16 18:35, , 32F
再來 登入口肯定兩個 伺服器維修應該不太可能只關閉
07/16 18:35, 32F
→
07/16 18:35, , 33F
某方登入口 (以我之前架設RO伺服器來看
07/16 18:35, 33F
→
07/16 18:35, , 34F
然後可以肯定的是 帳號數據庫是同一個就是了
07/16 18:35, 34F
→
07/16 18:36, , 35F
所以伺服器應該也是兩個 (沒有人維修伺服器只維修登入
07/16 18:36, 35F
推
07/16 18:36, , 36F
我個人認為是伺服器不同,但都從相同的帳號庫抽資料~
07/16 18:36, 36F
→
07/16 18:37, , 37F
口的 而我記得有次維修台日版是錯開的(? 希望沒記錯
07/16 18:37, 37F
→
07/16 18:37, , 38F
所以日版中槍台灣的大概也中槍?
07/16 18:37, 38F
→
07/16 18:37, , 39F
應該這樣說 整個遊戲流程有四個區塊
07/16 18:37, 39F
還有 21 則推文
→
07/16 18:43, , 61F
再精簡的數據都是靠SQL那些數據庫在處理的
07/16 18:43, 61F
→
07/16 18:43, , 62F
負擔的意味。小型app的登入動作不會這麼複雜(離題)
07/16 18:43, 62F
推
07/16 18:43, , 63F
台泥你講那個是用MySQL+客戶端模擬架的方法吧 原場應該是
07/16 18:43, 63F
→
07/16 18:44, , 64F
我同意很危險 尤其是兩個伺服器不同時運行
07/16 18:44, 64F
→
07/16 18:44, , 65F
Aegis 不是用MySQL這種架構
07/16 18:44, 65F
→
07/16 18:44, , 66F
觸控BUG那麼久GH在裝死就很幹
07/16 18:44, 66F
→
07/16 18:45, , 67F
RO本身的特性就很妙 史上第一個只要送封包 不用裝遊戲就
07/16 18:45, 67F
→
07/16 18:45, , 68F
能BOT的線上遊戲
07/16 18:45, 68F
→
07/16 18:45, , 69F
Aegis 我沒有接觸過 差異會很大嗎@@?
07/16 18:45, 69F
→
07/16 18:46, , 70F
因為我跑過石器 RO 天堂 雖然內部東西不同
07/16 18:46, 70F
→
07/16 18:46, , 71F
但目前架設的東西大同小異
07/16 18:46, 71F
→
07/16 18:46, , 72F
Aegis那套印象中是原廠開發專用的 當時流出版本到工會戰
07/16 18:46, 72F
→
07/16 18:46, , 73F
最古老的時候 用txt記錄帳號資料 要修改會看到眼花XD
07/16 18:46, 73F
→
07/16 18:46, , 74F
之後好像整個架構就不知道被哪個神人還團隊想出來用MySQL
07/16 18:46, 74F
→
07/16 18:47, , 75F
+客戶端模擬這種神方法
07/16 18:47, 75F
→
07/16 18:47, , 76F
Aegis 是一本藍色的那個書嗎?
07/16 18:47, 76F
→
07/16 18:47, , 77F
txt那個我也經歷過 XD
07/16 18:47, 77F
→
07/16 18:47, , 79F
忘了 很久沒碰 應該還是google的到吧
07/16 18:47, 79F
→
07/16 18:48, , 80F
藍色書是我國中的時候的東西 +255還會當機勒= =
07/16 18:48, 80F
推
07/16 18:48, , 81F
用sql來直接稱呼資料庫看起來說不出的怪...這是語法的名
07/16 18:48, 81F
→
07/16 18:48, , 82F
稱，而且不是所有資料庫都用sql=ω=
07/16 18:48, 82F
→
07/16 18:48, , 83F
哦@_@a 這個描述和athena+SQL模擬的架構一樣耶 A_A
07/16 18:48, 83F
→
07/16 18:49, , 84F
只能+10 哭哭 反正呢 如果遊戲公司要帳號回溯
07/16 18:49, 84F
→
07/16 18:49, , 85F
依照現在的技術 不會整體回溯 而是採取個別的 別擔心
07/16 18:49, 85F
→
07/16 18:50, , 86F
因為我最常用的就是Mysql 所以直接用SQL叫 抱歉XD
07/16 18:50, 86F
→
07/16 18:50, , 87F
雖然好像很專業 不過後面好像挺離題了XD
07/16 18:50, 87F
→
07/16 18:50, , 88F
因為資料庫三個字看不習慣....啊 應該用DB
07/16 18:50, 88F
推
07/16 18:51, , 89F
習慣叫SQL+1XD,學過MSSQL及MYSQL,回溯問題在於,我在日版打
07/16 18:51, 89F
→
07/16 18:51, , 90F
我看到登入要四個流程直覺就覺得有冗餘動作，又或者account
07/16 18:51, 90F
→
07/16 18:52, , 91F
到A,之後又去台版打到B,但因為A有問題需要回朔,台版的B消失
07/16 18:52, 91F
→
07/16 18:52, , 92F
map其實也是DB或DB mirror，又或者account和map為何不合併?
07/16 18:52, 92F
推
07/16 18:52, , 93F
哦 因為我是用RO的角度來講 後來想想 好像會少一兩個
07/16 18:52, 93F
→
07/16 18:52, , 94F
讓人會覺得很不爽~
07/16 18:52, 94F
→
07/16 18:53, , 95F
帳號登入login-> 角色讀取char->進入遊戲讀取map
07/16 18:53, 95F
→
07/16 18:53, , 96F
再說login本身只是auth的動作，後續要怎麼取資料是另一回事
07/16 18:53, 96F
→
07/16 18:53, , 97F
龍拼沒有選取角色的這個步驟
07/16 18:53, 97F
→
07/16 18:55, , 98F
就到這邊吧 離題好多 抱歉XDD
07/16 18:55, 98F
→
07/16 18:56, , 99F
噢 這樣的話，應該 map(item) ⊆ account(chr) ⊆ 帳號
07/16 18:56, 99F
→
07/16 18:56, , 100F
好吧，就到這邊好了 XD
07/16 18:56, 100F
‣ 更多 kiki41052 的文章
文章代碼(AID): #1JnbD2mE (PuzzleDragon)
‣ 更多 kiki41052 的文章
文章代碼(AID): #1JnbD2mE (PuzzleDragon)