2017年11月8日水曜日

Multi Life Counter 2.1.0 アップデート


・トレーディングカードゲーム用ライフカウンター
・2桁から5桁までの表示/入力に対応し、
 様々なTCGで使用可能
・カウンター履歴の参照と保存が可能

[詳細はこちら]

まずはお礼と謝罪を。
最初期のリリースから現在までで合計30,000を超えるダウンロードを頂いており、また、国内外含めて好意的なレビューまで頂戴しており、本当に有難うございます。
こんなにダウンロードして頂けるとは当初全く予期しておりませんでした。
長らく放置してしまい本当にすみません。

以下の修正を行いました

[問題の修正]
- iOS11対応
- カウンター及び設定画面でダイアログの向きが画面の向きと異なってしまう問題を修正
- 設定画面で特定の操作をすると初期値や桁数の変更が反映されない場合がある問題を修正
- 一部画面でステータスバーが表示されない場合があった問題を修正
- 一部画面でステータスバー分の表示領域の計算が反映されなくなっていた問題を修正
- 各画面で複数のボタンを同時に押せてしまう問題を修正
- カウンター画面や保存ログ画面などでテーブルの罫線の太さが表示位置により一定しなくなっていた問題を修正
- いくつかの画面でダイスの画像が低解像度で表示されていた問題を修正

[挙動変更]
- 設定画面で桁数を選択した際に各初期値の設定が桁数を超えてしまっていた場合、各桁の最大値(999等)ではなく「0(ゼロ)」で更新されるように変更
- 各桁毎に、初期値フィールドを空で設定した際に自動入力される値を変更
 (2/3桁 : 20, 4/5桁 : 8000)
- カウンター画面でログボタンを押した際、履歴のテーブルを最新の一まで自動でするロールするように変更

[デザイン変更]
- カウンター画面でサブカウンターの表示をテキストでの説明からアイコン表示に変更
- カウンター画面で数値の変更を確定する際、当該の数字ではなく新たに設けた「確定」「キャンセル」ボタンを使用するよう変更
- 上記と併せてカウンター画面でサブカウンターの値の変更を行う際、当該の数値表示が画面中央まで移動して表示されるよう変更
- ゲーム内ログ画面及び保存ログ画面で値の増減値を表示するよう変更

〜 ver. 2.0.2    /    ver. 2.1.0 〜

 ->   
    ->    
 ->    

今回の更新では主にiOS11対応のためのビルドし直しと同時に新しいiOS及びデバイスに対応するための修正、及び一部画面デザインの変更を行いました。
ver. 2.0.2リリース当時32bitのみのビルド設定になっていたようでiOS11以降だとストアの検索に引っかからなくなっていた期間があったようです。64bitビルド、一回確認したんだけどなぁ・・・。
どちらにしても非推奨になってしまったコードなども多々あったため、アプリの見た目はあまり変わりませんが、内部的には結構手を入れました。
レイアウト構造の変更やUIKit側の機能更新による処理の変更などなど、手を入れ始めたらきりがなくなってしまいました。
もっと早くアップデートするつもりだったのですが、遅くなってしまいすみません。

また、現在までにレビューにて以下のご要望を頂戴しております。

・設定画面まで戻らなくてもカウンター画面でプレイヤー名をタップすると編集できる
ようにして欲しい
・コインフリップの機能が欲しい
(ほかに見逃しているご要望があればすみません。)

プレイヤー名の編集に関しては近く実装するつもりです。
コインフリップ(コイントス)は、実装すべきか検討中です。既存の1D6ダイス機能の偶数/奇数で代用できるため(リアルでもけっこうやりますよね。)、あえてコインとして別に用意するべきかどうか。
実装自体は別にすぐできるのですが、画面や操作が煩雑になっても本末転倒なので。
その他に追加の便利機能などがあれば真ん中のダイスボタンを「ツールボタン」とかしてもう一段階メニューを用意してもいいのですが。

今後は機能拡張や既存機能の調整など、もう少しこまめに対応をしていく予定です。
何卒宜しくお願い致します。

2014年7月18日金曜日

10秒フリック for iOS 1.0.0 リリース!

SpriteKitの練習がてら簡単なゲームを作ってみました。

・10秒間、画面に現れる矢印をひたすらフリック!
・より早く!より正確に!
・あなたの限界は何フリック?

へっぽこアプリですが、遊んでみていただけると嬉しいです。
お時間はとらせません。
なにせ10秒なので。
良い記録が出たらツイートしてみてください。
そして私に広告収n(ry

因みに、現状で私の最高記録は 22フリック です。
べ、別に反射神経が絶望的なんじゃないんだから!
手加減してあげてるだけなんだからねっ・・・!///


作ってみた感想など。

今回はSpriteKitに喜び、SpriteKitに泣かされた感じでした。
慣れてしまえば随分楽に2Dゲームを作成することが出来る強力なフレームワークであることは実感。
SKAction万能説とか。

一方で、枯れていないと言うかなんというか。
まだまだ新しいフレームワークでかつCocos2Dなどの既存かつ代替フレームワークもあるため、「使ってみた」という導入記事やサンプルコードは多々あれど、トラブル事例と対処法が調べてもなかなか出てこない。
コードが悪いのかフレームワーク依存の問題なのかがなかなか判別できない。
それでいてSpriteKit自体がどうやら不具合を内包しているらしいという。
特にメモリ周の 不可解なBADACDESS やらなんやらが幾つかあるようで。
サウンド周りの割り込みによる不具合 なんかにも当たりました。
製作期間の半分以上、謎トラブルと戦ってた気がする・・・。
練習がてらサクッと作れると思ったんだけどなぁ。
このご時世、ゲームは特にマルチプラットフォーム全盛なのでSpriteKitがちゃんと枯れていくかどうかは分かりませんが、折角の純正フレームワークですし、活用したいものです。

今回作ってみて多少勘所はわかった気がするので、他にもSpriteKitで色々作ってみたいなー。

2014年7月17日木曜日

iOS Developer Programの更新メール本文からのアクティベートってなくなったのね、的な備忘録。

iOS Developer Programの期限が切れそうだったので更新をした時の話。
どうやら今年から微妙な手順変更があったようなので備忘録。
手順まとめではありませんので悪しからず。

変更点 :
2014/01 以降は更新確認メールの本文中リンクからのアクティベートが必要無くなり、購入処理後に自動でアクティベートされる。

この更新作業、年に1回しかやらないから、作業を全く覚えない。
今年も
こちらとか
http://blog.livedoor.jp/tattyamm/archives/3548487.html
こちらとか
http://do-gugan.com/~furuta/archives/2012/06/ios_developer_p.html
あとこちらとか
http://qiita.com/stakei1/items/976069a8bad21d237bca
有難いことにまとめて頂いている方の記事を参考に、作業に抜かりが無いか確認をしながら更新。

と、3つ目のサイト様の記事に気になる文面が。

-リンク先サイト様より引用-
http://qiita.com/stakei1/items/976069a8bad21d237bca
8.アクティベーションコードメール(2014/01以降はメールは来ない)

Apple Developer Supportから「 Apple Developer Program Activation Code」
という件名で、アクティベーションコードが送られてきます。
メール本文にあるアクティベーションコード「 XXXX-XXXX-XXXX-XXXX 」をクリック。

2014/01以降自動でアクティベートされるようになったため、このメールは来なくなった。
ほほ〜ぅ。
事前に調べてなければ「メールが来ねー!」と取り乱していたところだ。
実際に更新してみると「Thanks for renewing your membership.」とのメールが先に届いた。
それから少し遅れて「ご注文ありがとうございます」のメールが届く。
確かに「Thanks for renewing〜」の方のメールにはサポートページへのリンクくらいしか無い。
念のため確認。
Apple Developerサイト > 右上のMember Center > 上部の黒いバーの「Program & Add-ons」
(2014/07/16時点。最近頻繁にサイトデザイン変わるんだもん。)
ちゃんと1年伸びている。特に何もしなくていいのか。楽だ。
リンクからのアクティベートはうまくいかない例もあったようだし、トラブルも減りそうでいいですね。

2014年6月12日木曜日

AVAudioPlayerでハマった話。システム音も聞こえなくなった話など。

環境:iOS 7.1.1, XCode 5.1.1
状況:AVAudioPlayerがシステム音量ごと沈黙

AVAudioPlayerでBGMを鳴らそうとしていたところ、ある時からBGMの鳴るはずのタイミングで鳴らなくなってしまった。
しかもどうやらiOSの他の音声ごと無音になってしまっており、ボリュームボタンを押せどもサイレントスイッチを弄れども音は出ず。(画面上の表示は反応しています。)
実機だとイヤホンを抜き差しなどしてオーディオのルートを変更すると復帰する模様。
シミュレータだとアプリを落とすと復帰するけど、それまではMacのシステム音声も巻き込んで消える。
なにこれこわい。

結論から言うと AVAudioPlayer の volume プロパティの値が不正だったというオチ。

原因 :
AVAudioPlayer の volume プロパティにゼロ除算の結果の+INFを入れてしまった

直前にSpriteKitのバグ回避のためにオーディオセッションの設定を実装していたのでそのせいかと思い、新しく呼ぶようにした関数を全部潰しても治らない。
念のため既に実装を終わらせていたオーディオの再生部分を確認したら原因判明。
BGMのフェードインの実装の中、引数で与えられたdurationからフレーム毎の音量の増加値を計算している部分でゼロ除算してました。
その計算で引数が 0 の場合に +INF になった値をそのまま AVAudioPlayer の volume にイン。
結果、音量が振り切れてシステム音声ごとオーディオが落ちる状態に。
確かに同時期に「フェードイン無しの再生って duration が 0 のフェードインと同じだから云々・・・」とか自分で弄ってたの忘れてた・・・。
まぁともかく、原因が分かってよかったよかっt・・・。
よくない。

公式ドキュメントに「このプロパティは 0.0 から 1.0 までよ」って書いてあったけど。
今回の件、volume プロパティは inf だったから異常値として代入できてしまったのか、そもそもアクセサとかで検証はしてくれていないのか。
試しに値に「2.0」を入れてみる。
音が大きくなる。

・・・。(ゴクリ。)
よーし、ちょっと思い切って大きい値入れちゃおうかなー。具体的には INT32_MAX とか。

結果:音が割れる。

・・・おいィ?
認識できる数値だったらスケールの範囲に関係なく再生しちゃうのか。
例えば音量制限の延長で極端な値だとシステムがフェールセーフで落とすとかではない模様。
なにそれこわい。
MPVolumeView の volume プロパティは非推奨にしてるくせに、このおざなり感。

結論:バリデーションは自前で。

SKActionを使ったサウンドの再生でハマった話。割り込み後に再生しなくなるなど。

環境:iOS 7.1.1, XCode 5.1.1
状況:SKActionを使用した音声がシステム割り込みからの復帰後に再生しなくなる

SpriteKitを使ったアプリでSEの再生をSKActionのサウンド機能を使って再生していました。
音量調節が出来ないのが難点だけど実装が楽で実に有難い。
と思っていたら思わぬ罠が。
着信などのシステム割り込みからの復帰後にSEが再生しなくなる。
調べたら出てきました。

症状
http://stackoverflow.com/questions/22978547/handling-interruptions-in-sprite-kit-cant-get-sound-effects-via-skaction-pla
対処
http://iknowsomething.com/ios-sdk-spritekit-sound/

ま た バ グ か 。

なんか遭遇しすぎて逆に本当にSpriteKit自体のバグなのか、自分が何か見落としてるだけじゃないかと不安です。
(もう一個、別の件で詰まって調べたら「SpriteKitのバグっぽい」と言われてた事があったんですが失念。思い出したら書きます。)

ともかく動いてくれなきゃ困るので上記の対策を参考にさせて頂くことに。
SKActionがBlocksを実行できることを利用した実装なので、末端のコードを書きなおさなくていいのが嬉しい。
有り難や有り難や。
というか、コレがアリならもうSKActionはなんでもありですね。

ひとまず盲目的に実装したところ、アプリ起動中にコントロールセンターを引っ張りだすと deactivateAudioSession でエラーの際に再帰呼び出しをかけてるところでエラーがいつまでも解消せず、再帰が止まらなくなりタイムアウトで落ちる。
Audio Session Programming Guide には「割り込み発生時にはシステム側で AudioSession を停止する」って書いてあるし、特定のアプリ以外は明示的に停止する必要はないらしい。 今回は特に必要でもないので soptAudio 以外では deactivateAudioSession を呼ばないように変更。
とりあえず期待通りの挙動になりました。

Appleさん、新言語のついでに bug fixも早急にお願いします。 せっかくのフレームワークも結局既存の複雑なコードを呼び出すんじゃ意味ないっス(泣)

2014年5月8日木曜日

SpriteKitでハマった話。 iOS7.1, SpriteKit, SKShapeNode, EXC_BAD_ACCESS的な。

次に何かリリースしようとSpriteKitを使って簡単なゲームを作っていたところハマりました。
先に書いておくと未解決です。ボスケテ。

環境:iOS 7.1.1, XCode 5.1.1
状況:SKShapeNodeを子に持ったSKSceneがメモリから解放される時にEXC_BAD_ACCESSで落ちる場合がある

SKShapeNodeを子に持ったSKSceneをビューで保持していない状態で別のシーンに遷移したり、意図的に開放してやったりすると
SKCSprite::removeSubSprite(SKCSprite*)
の呼び出しでEXC_BAD_ACCESSで落ちる。

こうなって
こうなる

試しにXCodeのSpriteKitのテンプレートに丸いSKShapeNodeを1つ追加してサイズと背景色だけ設定したSceneに遷移しても再現しました。

自分の使い方が間違っているのかと思い、ググってみると何やらiOS7.1固有のSpriteKitのバグかもとか言われてる・・・?
http://stackoverflow.com/questions/22399278/sprite-kit-ios-7-1-crash-on-removefromparent

確かに7.1の実機,シミュレーターだと再現し、7.0のシュミレーターだと再現しない様子。

試しに別クラスからShapeNodeを保持するようにして、上記フォーラムのやり方で先に開放するようにしても改善せず。
メモリ位置の関係なのか、ShapeNodeの生成を
・呼び出し箇所で直書き
・同一クラス内で関数化して呼び出し
・サブクラス経由で生成
と変えてみると、再現率が変わったりと不安定。
Zombiesにも引っかからないし。
いっそ全てのシーンをビューから保持したままにしてやろうかとか、頭を抱えてしまいました。

SKShapeNodeのサブクラスや該当のSKSceneのサブクラスで
- (void)dealloc
{
    if(self.children.count > 0){

        [self removeAllChildren];
    }
}

とかやっても結局スーパークラスで
SKCSprite::removeSubSprite(SKCSprite*)
が呼ばれてしまい駄目っぽい。
SKShapeNode本体にクラス拡張をしてみるとやっぱりこいつのdeallocで落ちている。
一応、他のSKNodeの純正サブクラスでも試しましたが、ShapeNode以外は問題ない様子。
試行回数がそれほど多くないので断言は出来ませんが。
つまり

・SKSceneがAutoReleaseで解放される際に
・開放されるSceneに含まれるSKShapeNodeにdeallocが呼ばれる
と、
・メモリの状態によりEXC_BAD_ACCESS が起きる場合がある

という状況らしい。
・・・らしい。むむむ。

海外のフォーラムでも話題になっていましたが、SKScene自体がメモリ周りが不明瞭な部分があるようで、その関連なのでしょうか?

どうにも先に進まないのでひとまず諦めて

1.CAShapeLayerでオフスクリーンに描画
2.オフスクリーンの内容をCGImageに変換
3.できたCGImageを使ってSKTexture作成
4.SKTexture使ってSKSpriteNodeを作成

とかなんとかしてSKShapeNodeは使わずにSKSpriteNodeで代替することに。
あまりに悩みすぎて「Shape」と名の付くクラスを使うのに戦々恐々としましたが、CALayerは問題ない様子。そりゃそうだ。

結局解決していない上に確定情報がなにもないというグダグダな記事ですみません。

「俺、原因知ってるZE!」
「それはお前が悪いだけだ」
「調べ方が足りないだけで解決策が既出」
など、ご指摘あればコメントいただけると幸いです。

2014年1月7日火曜日

Multi Life Counter 2.0.2 アップデート


・トレーディングカードゲーム用ライフカウンター
・2桁から5桁までの表示/入力に対応し、
 様々なTCGで使用可能
・カウンター履歴の参照と保存が可能

[詳細はこちら]




以下の修正を行いました

・設定画面で一部コンポーネントのアニメーションが不自然だった問題を修正しました

以上

ダウンロードして頂いた方、本当に有難うございます。

割りと小さな内容のため、本来であれば前回のアップデート内容と同時に申請したかったのですが、今回はコードの修正と同時にiAdの設定変更も行ったため、審査が長引いた場合に誤字が表示され続けるのがあまりに恥ずかしかったため前回のアップデートを緊急で先出ししました。

今までだとアップデートを申請した場合、状態が In Reviewになってから大体数時間程度でReady for saleになることが多かったのですが、案の定、今回はIn Reviewから3日程度かかっていました。
有難いことに ver 2.0.0 のアプデート以降ダウンロード数が増加しており、思ったより多くの方々に醜態を晒すことになっていたようで、分けて正解でした(汗)

しかもver 1.xの頃よりアップデート数の割合も大幅に増えており、実際に使って頂いている方が増えたのかな?と妄想してみたり。偶然かもしれませんが。
重ね重ね、ありがとうございます。