2月17日に、レアガチャの調整あり、今回はその話です。
2月17日(金)15:00頃に機能の追加更新いたしました。
ブラウザのキャッシュをクリアしてからゲームにアクセスしてください。
Android版は最新バージョンにアップデートをお願いします。
[Android最新バージョン]
1.2.24
更新内容は以下となります。
[内容]
◆特レアガチャの追加
◆レアガチャの排出確率の変更
「レアガチャ」の排出確率を以下のように変更しました。
変更前 SSR:1.5% SR:10.0% HR:20.0% R:68.5%
↓
変更後 SSR:1.5% SR:10.0% HR:45.0% R:43.5%
告知には表記されてないようですが、ノーマルガチャの方も修正された感じです
最近どうにもSRキャラの出が悪いので
ノーマルガチャ１０連を２００回まわし、２０００個分の統計出してみました。
ガチャ回してSS撮って
キャラ枠だけトリミングし
画像分割ソフトで１０分割して
２０００枚の画像に細分して
各レア度別にフォルダー分けして
個数しらべてと、かなり時間かかってしまいました。
| 2000枚中 | 枚数 | 確率 |
| SRキャラ | 1 | 0.05% |
| HRキャラ | 35 | 1.75% |
| Rキャラ | 22 | 1.10% |
| HNキャラ | 338 | 16.90% |
| Nキャラ | 381 | 19.05% |
| SR戦術機 | 11 | 0.55% |
| HR戦術機 | 18 | 0.90% |
| R戦術機 | 77 | 3.85% |
| HN戦術機 | 385 | 19.25% |
| N戦術機 | 732 | 36.60% |
ノーマルガチャのN～SR戦術機自体が即売りのゴミしかないが
２０００枚中１２２３枚と、６１．２％が戦術機が占めています。
SR戦術機も１１機出はしたけど、これもゴミしかいないよ
まさか、SRキャラが２０００枚中、CP社一人だけとは・・・。
NとHNは、合わせて３６％
石は無いけど、バトルログ（中）の重要な供給源だし、まあいいか
最近出が悪いRキャラは
２０００枚中２２枚と１．１％しかない
調整されてから３バカとか出るようになったHRは
２０００枚中３５枚と１．８％
石の供給源として重要な位置だったRキャラより
親密度上げがきつい、HRキャラが出るように調整されましたが
ここで一つ問題が
マブラヴ ストライクフロンティア攻略速報
http://muvsf.blog.jp/archives/12612947.html
で、話が上がってましたが
どうやら親密度自体も修正がされてるようで
昔UPされていたのと、最近のを並べてみるとこうかな？
| 昔の親密度 | 1 | 2 | 3 | 4 | 5 | 合計 | 報酬 石 |
| SR | 1500 | 1000 | 4500 | 8000 | 9000 | 24000 | 3個 |
| HR | 1000 | 3360 | 1400 | 3000 | 4000 | 12760 | 1個 |
| R | 800 | 800 | 1600 | 2400 | 3200 | 8800 | 1個 |
| ＨＮ | 750 | 750 | 900 | 1500 | 2550 | 6450 | 0個 |
| Ｎ | 500 | 500 | 600 | 1000 | 1700 | 4300 | 0個 |
| 現在の親密度 | 1 | 2 | 3 | 4 | 5 | 合計 | 報酬 石 |
| HR サンタ水月 | 1000 | 1000 | 2000 | 3000 | 4000 | 11000 | 1個 |
| HR 旧Nガチャ産 | 1000 | 1000 | 3500 | 4000 | 7500 | 17000 | 1個 |
| HR 新Nガチャ産 | 1500 | 1000 | 4500 | 8000 | 9000 | 24000 | 1個 |
HRの石２個にすればいいのに、なんで親密度だけ上げるかな？
しかし、まあ
本当に下方修正に関しては、開いた口が塞がりませんね、毎週開きっぱなしですよ
これはもうオルタネイティブ５も近いかな
オルタネイティブ５計画概要
全人類で選抜された約10万人を地球から脱出させ、大量のG弾でBETAに最終決戦を挑む。
つまり、10万人に選ばれなかった人類は、G弾で重力異常起こした地球で
残存したBETAと残存兵力だけで戦わなければいかない、バッドエンド
ちまたで言われている
運営が夜逃げするパターンでの意味ではなく
G弾（運営に不利な発言）大量投下して
ココから、プレーヤーが新天地（別のゲーム）に向けて大移動のパターン
後者の方が早い気がする
オルタネイティブ５発動まで見届けるつもりでしたが
新天地見つけるまでは、まだ持ってほしいかな
ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー
現在やってるほかのゲーム
去年の９月から課金しなくなったが、１年以上続けてきたクロスオーバードは
今では殆どINして、自然回復分回る程度になり、こちらはそろそろかな
最近では「マジカルフォーゼ プリズム ガール」を齧ってますが
新キャラ毎回２名出てくるが、課金ガチャで今まで回しても出ませんでしたが
先日の修正で、いきなり手持ちに無かったキャラ５人も出たりと大盤振る舞い
中でも、補佐として出していると経験値＋１１０％UP、ドロップ率＋５０％UPの音無出たのはうれしい
まあ、どこでもそうですが、不満もないわけではないんです
一番は、スタミナ回復が１００回復とか、１００％ではないんですよ
現在のLVでは１４０超えてますが、１回では回復しきれないのが痛い
１００％回復アイテムがイベントなどでたまにある程度で、これを普通に販売してほしい
あとは、同じスタミナ回復アイテムの安い奴が１週間５個までとか個数制限も何とかしてほしいかな
無課金の人には特に意味ないところもあるが、課金組にしてみれば重要なんですよね
何でここで集金しようとしないのかが不思議
どこかの運営は、３０分間経験値２倍アイテムを石１個（１００円）で販売してますが
まじプリの方では
石４０個（４００円）で１週間ドロップ率３０％ＵＰアイテム販売してます。
１週間も持続するようなら、４００円は安いでしょう
なんだかんだ言っても
マブラヴＳＦは、運営は記憶に残るほどダメですが、ゲーム自体はそれなりに楽しんでるし
もう少し続けるつもりですけど
このまま、毎週下方修正するようなら本当にやばいことになりますよ
コメント返しの、昔撮った画像
右上の所持金カンストしているが、強化費用の方では１桁切れた形で、実際にはカンスト以上のお金持ってる
しかし、リログすると右上の表示にされ事があるようで、カンストしてたら数字減るまで何かに使うのが良い
お金溜める楽しみもあるので、カンストダメージ１桁増やしたように、所持金も上げてほしいですね
スポンサードリンク
いやー、見ごたえのある分析ですねぇ
ホント、いつもありがとうございます。
さて、公式コミュで書くと運営シュタージに粛清されるというか速攻修正されるので
ここでこっそりお話するんですけど、
お金って9999999が上限じゃないですか？
でも、内部的にはもっと桁を持ってるように思われるんですよね。
キャラ強化のときに気付いたんですけど、
強化前 お金9999999
↓
強化かかる費用 556000
↓
強化後のお金9999999(!)
スクショ取ってなかったので、今度改めて取ってみますね
今は所持金カンストではないので出せませんが
昔撮っていた、その画像引っ張り出します。
ＳＳはこっちに張れないので、本文にコメント返しとして追記します。
先に報告しました「Gが内部的には7桁以上保持されているかも？」っていう話ですが、
精査した結果、
「プログラムロジックがマヌケだった」
って結論に達しましたｗ
通常、Goldを保持している変数から一定数の値を減算するプログラムを書く場合、
① 現在保持している値をフェッチして、画面表示に用いる
② 一定の処理を行うことにより、保持している値の内容を書き換える
③ 書き換えた後の値を再フェッチして、画面書き換え時に用いる
というロジックが一般的ではないかと愚考しますが、②→③の処理でスカタンをぶっこいている模様です。
具体的には、
① 現在のGoldを保持している変数（変数Aとします。）からフェッチしたGoldの値を、強化実行時の画面下部に表示
② 強化する内容を指定した後、強化が実行されれば算出されたGold使用値を、変数Aから減算し、新しい値で変数Aの内容を更新
③ 強化のリザルト画面を表示
④ この後、再度強化を続けるか若しくはリスト画面へ戻るかを選択する
⑤ ①の画面に戻る
④→⑤の処理で、①の画面に元々表示されている現在のGoldを表示する部分に、②で更新された変数Aの値を再フェッチして画面を更新しないといけないのですが、どうもこの処理がされていない模様ですｗ
⑤の後、キャラ強化画面を閉じてHOME画面に戻ると、画面右上のGold保有値は
9999999－②で指定した処理による消費Gold値
になってましたｗ
普通、こういう表示誤りは各処理（トランザクション）の単体テストでチェックして、一番に修正すべき点なんですがねぇ…
自分の常識で「まさかこんな単純な処理誤りは修正してるでしょ」と先入観を持っていたのが敗因でしたねｗ
まさに予想の左斜め下でした
どうもお騒がせいたしましたm(_ _)m
コメント返しの件ですが、先の現象を精査する中で気づいてたんですが、
一旦何が原因なのかイマイチわかりません。
昔懐かしのCOBOLなら
[変数A] ８桁
[表示領域] ７桁
で、かつ表示領域がX型（文字型）である場合、
変数A 99999999
↓
表示領域 XXXXXXX
という転記（左詰めの転記）をやらかすと、一番右の桁がこぼれる（桁落ち）しちゃうんですが…
っていうか、特段の事情（表示スペースが足らない等）が無ければ、変数の桁数と表示領域の桁数は合わせるのが鉄則なんですがねｗ
仕様書の管理がいい加減だったりすると、こういう不具合はよくあるんですが、コンパイル時にWARNING出るから普通気付くので、製品版でこんな不具合出したら腕立て100回ものですｗ
今時の開発環境でわざわざ表示領域の桁数を指定するなんてことがあるのかなぁ？