2014年3月20日木曜日

iOSアプリ「確率計算機」をリリースしました


iOSアプリ「確率計算機 (YourLuck)」をリリースしました。
ガチャのドロップ率と試行回数からドロップ期待値を計算するアプリです。
無料です。
https://itunes.apple.com/jp/app/que-lu-ji-suan-ji-gachano/id838156105?mt=8 (JP store)
https://itunes.apple.com/app/id838156105?mt=8 (Universal)

機能

シンプルイズベストなので、以下の2つだけです。

  • 確率計算・・・何回ガチャを回したら、最低でも1個はドロップするか、確率を計算します。
  • 期待値計算(v1.1.0以降)・・・ガチャを指定された回数だけ回すと、一体何個ぐらいはドロップするのか、ドロップする数を計算します。


使い方

特別なことはなにもないのですが、以下のように操作します。



期待値計算モード(v1.1.0以降)

画面左下のこのアイコンを押すと、期待値計算モードに切り替わります。通常の確率計算モードでは「指定された試行回数分だけガチャを回したら最低でも1個はドロップする確率」を表示しますが、期待値計算モードでは「指定された試行回数分だけガチャを回したらだいたい何個ぐらいドロップするか」を瞬時に計算する事ができます。同じモンスターを複数体狙っている時などに便利です。


FAQ

Q: 用語が難しくてよくわからんのだが
A: めっちゃバッサリ言うと以下のとおりです。
  • ドロップ率・・・ガチャのドロップ率です。そのまんまですね。
  • 試行回数・・・何回ガチャを回すかです。
  • 中央にでっかく出る%・・・指定したドロップ率で、指定した回数だけガチャを回したら、100人いるうちここに出ている数字の人が最低1回は指定したドロップ率の何かが出る、という意味です。30%だったら100人のうち30人が最低1回出ます。運がいい人であれば2回以上出るかもしれません。

Q: 絶対確実って表示されてるのに表示されてる試行回数分だけ回しても出なかった!詐欺だ!!!
A: 申し訳ありません(´・_・`) これには幾つか理由があります。
  • 確率は確率なので、例えば98.7%で絶対確実と表示されても1.3%の人、1000人に13人の人は外れてしまいます。これは年末ジャンボ宝くじを1枚だけ買ったら5等3000円が当たった、ぐらいの確率です。すごいのかすごくないのかイマイチわからんですね。
  • 試行回数が多いと誤差が出る可能性があります。具体的には試行回数100回以上はより高速な計算を使っているのですが、そのため精度1~2%程度ですが落ちている可能性があります。

Q: 期待値モードで「最低でも」とか「ほとんどの人は」とか出るけどあれ具体的には何%なの?
A: 以下のとおりです。
  • 最低でも・・・100人中98人がこの数字以上の個数を獲得できます。
  • ほとんどの人は・・・100人中85人がこの数字以上の個数を獲得できます。
  • 半数の人は・・・100人中50人がこの数字以上の個数を獲得できます。

Q: ガチャの確率ってどこで調べればええの?
A: 以下の様な方法をオススメします。
  • ゲーム内に表示されている場合があります。最近のゲームでは特に確率を表示しているものが増えているので、ガチャの画面で注意して探してみてください。
  • グーグルとかヤフーで「ゲーム名 ガチャ 確率」と入力して検索する。
  • 知ってそうな人に聞く。ただしゲームを作ってる中の人とか関係者にTwitterで聞いても絶対に教えてくれないのでそういう人以外に聞いてください。

サポートとか

もし何かございましたら、以下の私の連絡先にまでご連絡ください。
mail: akisutesamaあっとまーくgmail.com
twitter: @akisutesama

2014年3月12日水曜日

iOS SDK 7.1 / Xcode 5.1にアップグレードした時に踏んだ地雷まとめ

本日iOS SDK 7.1 / Xcode 5.1にアップグレードを行った際にぶつかった所々の問題とTipsをまとめておきたいと思います。

arm64対応とCocoaPods

Xcode 5.1からデフォルトのビルド設定$(ARCHS_STANDARD_32_BIT)がarm64、要するに64bit対応を含むようになり、arm64 armv7 armv7sの3つのアーキテクチャに対してビルドを行うようになりました。ソースコードからビルドを行っている場合は大抵問題ないと思うのですが、以下の様なケースでarm64対応を切りたい場合があります。

  • プロジェクト内にarm64アーキテクチャに対応していないstaticライブラリが含まれている場合。
  • 64bitになると危険なバグが発生するおそれがあるコードが含まれている場合、例えばCGFloatやNSIntegerのサイズが変化したり、各種ポインタのサイズが4byteから8byteに増えていたりすると面倒な事が起きるような計算をしている場合。

このような場合、一番簡単な対応策はBuild SettingsのArchitectures(ARCH)をarmv7 armv7sに書き換えることなのですが、こうすると実はCocoaPodsを使用しているプロジェクトの場合リンカエラーが発生してビルドができなくなるという問題があります。
https://github.com/CocoaPods/CocoaPods/issues/1787

そこでBuild SettingsのArchitectures(ARCH)を$(ARCHS_STANDARD_32_BIT)という値に設定すると内部的にarmv7 armv7sとして扱ってくれ、かつCocoaPodsが問題を起こさないようです。この方法をオススメします。この件については以下のページが詳しかったです。
http://stackoverflow.com/questions/8323343/archs-standard-32-bit-vs-armv6-armv7-armv7s-vs-i386

JSONKit対応とCocoaPods

Xcode 5.1からisaポインタへの直接アクセスが完全に禁止になりました。これまでは警告を出さないようにする事が可能でしたが、Xcode 5.1からはそのオプションもなくなり問答無用でビルドエラーにされてしまいます。この問題が最も深刻に出るのはJSONKitライブラリです。
https://github.com/johnezang/JSONKit/issues/79#issuecomment-6322919

対策として一番簡単で確実な方法はJSONKitを使うのを今すぐやめてNSJSONSerializationに乗り換えることです。NSJSONSerializationはiOS 5から使用できるので、あなたが余程のパフォーマンス厨か、またはあなたのプロジェクトが数千万人以上のユーザを抱える巨大プロジェクトで、万一iOS 4系のサポートを止めると何故かあなたの会社ではなく携帯電話会社に「使えないんでなんとかしてください」と苦情が寄せられるような社会的インフラとなったアプリでもなければこの方法を取ることを強くオススメします。

それでも何らかの理由か大人の事情で万一JSONKitをサポートしなければならない場合は、もはやソースコードを書き換えるしか手がありません。幸いにしてXcodeがエラー箇所の修正提案を自動的に全て行ってくれるため、それに従ってコードをホイホイ書き換えれば簡単にビルドが通って使えるようになります。また、すでにそのようなパッチやプルリクエストが山ほどgithub上に用意されています。例えば以下の様なプロジェクトをオススメします。
https://github.com/ignazioc/JSONKit-NoWarning (JSONKit 1.5.2pre, 要するに最新版相当)
http://cocoapods.org/?q=jsonkit-nowarning (CocoaPodsでも使用可能です)

まとめ

CocoaPods爆発しろ

2014年2月25日火曜日

アプリのクラッシュ検知・クラッシュレポート系ライブラリを調べてみた

アプリのクラッシュを検知したり、クラッシュレポートを作成したりするライブラリやサービスを試してみたくなったので色々調べてます。まだ実際に検証できていないので主に自分用メモです。

■なぜクラッシュ検知なのか?

以下の様なメリットが考えられます。
  • アプリのクラッシュを100%絶対完全に阻止する方法は無い。どんなアプリでもクラッシュする可能性がある。
  • 開発者のメリットとして、クラッシュ時に詳細なクラッシュレポートやクラッシュログを数多く収集することができれば、迅速確実な修正が可能になり、結果としてユーザーのメリットに繋がる。
  • ユーザーのメリットとして、クラッシュを検知して即座に編集中データが失われないよう退避したり、次の起動時に同じクラッシュが発生しないようセーフモード起動するなどの措置を開発者が取ることができるかもしれないので、利便性向上につながる。
  • アプリを通じたサービス提供者のメリットとして、カスタマーサポートに飛んでくる何の付加価値もない「動きません」「落ちます」といった苦情を具体的に解決しやすくなり、カスタマーサポート品質を高めたり要員コストを削減したりすることが可能になるかもしれない。
  • ゲームなどでは、例えばクラッシュが発生したら、次の起動時に1つのバージョンに付き1回だけ自動的に詫び石が配られる仕組みなどを作ることができるかもしれない。ゲームのキャラクターにごめんなさい><と謝らせるとなおグッドかもしれない。
逆にデメリットもあって、例えば
  • クラッシュ検知の仕組みが入ることで動作がかえって不安定になるおそれがある。SDK自体が問題を起こすなど。
  • クラッシュ検知の際に対応して行う処理がかえって致命的な問題を起こすリスクもある。exception handlerやsignal handlerを捕まえて検知する仕組みのため、それらを利用している他のSDKなどと競合するおそれがある。
  • 当然それらの機能の分だけ実装とQAと保守のためのコストが上がる。
  • 特にプロプライエタリなサービスのものに関しては会社の方針で導入ができないことがある。
メリデメをよく考えて導入する必要がありそうです。

■サービスとして提供されているもの

以下のページのまとめが詳しいです。
http://www.raywenderlich.com/33669/overview-of-ios-crash-reporting-tools-part-1

Crashlytics
http://try.crashlytics.com

Crittercism
https://www.crittercism.com

Bugsense
https://www.bugsense.com

TestFlight (クラッシュ検知以外の方が有名)
https://www.testflightapp.com

HockeyApp (クラッシュ検知以外の仕組みもある)
http://hockeyapp.net

■オープンソースなもの

KSCrash (iOS)
https://github.com/kstenerud/KSCrash

ACRA (Android)
https://github.com/ACRA/acra

実際に使ってみてまたレポートなど書いてみようと思います。