ほげぐらまの別館 » Objective-C

iOSプッシュ通知でハマった事

st.lain — Sun, 08 Apr 2012 15:12:58 +0000

以前の記事、「プッシュ通知(APNs)の初期確認ダイアログについて」の続き。今になってはじめて気がついたというか、前々から変だと思っていたけど端末のせいにして自分は悪くない！と思っていた自分が一番馬鹿だった、というものです。

プッシュ通知の確認ダイアログ自体は書いたとおり一度しか表示されない、というのは変わらないのです。が、特定の再通知条件を満たさない間に再インストールするとデバイストークンが取得できないというものです。特殊なパターンなので具体的な例で言えば、

enabledRemoteNotificationTypesをコールして現在のプッシュ通知が有効かどうかを調べる
有効なtypeがない場合にregisterForRemoteNotificationTypesをコールして通知ダイアログを表示する
アプリケーションを再インストールする
enabledRemoteNotificationTypesの値は正常なのにデバイストークンの値が取れない

というパターン。確認する限りは、再インストールの場合は既に[設定]上にプッシュ通知が有効になっているものの再度enabledRemoteNotificationTypesをコールしないとdidRegisterForRemoteNotificationsWithDeviceTokenがコールされないようで、これがデバイストークンの値を取得できない要因となっていたようです。なので、解決策としては2.で既に有効になっていてもregisterForRemoteNotificationTypesをコールする、ってのが手っ取り早い模様。

何も考えずにそれをコールしていればこんなにハマることはなかったのでしょうが、何かを変えるということはそれだけリスクを伴う場合があるってことですね。いい勉強になりました。

プッシュ通知(APNs)の初期確認ダイアログについて

st.lain — Sat, 28 Jan 2012 08:53:02 +0000

iOS環境ではプッシュ通知が重要だよ、的な周り口で1セッションの通信において複数デバイスにプッシュ通知を行うという記事を投稿しました(因みに自分ではまだやってないのですけどね、同僚が私の作ったモジュールを使って動いているよ～って言ってるから動いているのでしょう)。

プッシュ通知は重要ながらもチュートリアル的な実装をそのままコピペで実装してしまうと優れた機能も非常に残念なことになります。というのも、例えばよくあるパターンではゲームに対してプッシュ通知が実装されている場合、タイトル画面といった起動した瞬間に「○○はプッシュ通知を送信します。よろしいですか？」と出現するパターン(画像はあくまでサンプル画面ですが、実際に私が指摘する最悪なパターンを再現してくれたものです)。

少しはユーザのことを考えればわかることですが、これって開発側からのエゴの何物でもないですよね。だって、リアルな環境に置き換えるならば、試供品を受け取った段階で

とりあえずDM(ダイレクトメール)送りたいんだけど受け取りますか？

と言われているに近しいものだと思うのです。

因みに私はこのパターンは絶対にプッシュ通知を許可しません。だってウザったいかもしれない通知が来るかもしれないのにそれを許可する理由なんてないですから。

ってことで、長々とウンチクを垂れましたが、端的に言えばプッシュ通知をすべき場所を今一度見直して、細かく制御しましょうよ、と。プッシュ通知はUIAPplicationのインスタンスメソッドとして定義されていて以下の3つがあります。

registerForRemoteNotificationTypes…プッシュ通知を有効にしようとします。ユーザにダイアログでプッシュ通知の確認が求められます
unregisterForRemoteNotifications…登録されたプッシュ通知を破棄します
enabledRemoteNotificationTypes…(どのような種類の)プッシュ通知が有効かどうかを取得します

なので、チュートリアル通りにapplication:didFinishLaunchingWithOptions:でregisterForRemoteNotificationTypesをコールするのではなくて、どのような目的でプッシュ通知を行いたいかを述べたうえで初めてregisterForRemoteNotificationTypesをコールしましょう、と。これをやっているのがGameloftの”レッツ！ゴルフ3”ですね。

・・・・、とここまでが前置き。そしてようやくタイトルの話になります。上述の通りにプッシュ通知のダイアログが出るタイミングというのは非常に貴重なもので、本当にこのタイミングでよいのかどうかを試験したい場合がありますが、一度この確認でどちらかを選択してしまうと開発中でも中々出てくれません。で、かるーくググってみると大好きなStackoverflowでこんな投稿がありました。

Reset push notification settings for app (Stackoverflow)

相変わらずの精度が低いほげ脳内翻訳によれば

アプリケーションが初回にプッシュ通知を有効にしようとするならば、iOSはユーザにアプリケーションから通知を受け取るか否かを確認します。一度でもその警告(プッシュ通知の同意ダイアログ)に応答した場合は、デバイスをリストアするか、若しくはアンインストールを行ったうえで少なくとも1日以上経過する必要があるでしょう。

もしあなたが初回のプッシュ通知をシミュレートしたいとするならばアンインストールを行ったうえで1日経過させる必要があります。但し、システムクロックを1日以上経過させたうえで一度デバイスをシャットダウンし、再度デバイスを起動することで後者(=アンインストール後に1日以上経過するという条件)を満たすことができるでしょう。

と書いた本人ですが、実際に試していないのであしからず。

今回の記事をまとめるとこんな感じ

プッシュ通知はアプリケーションが非アクティブ状態でもアプリ提供者側からユーザに情報通知が可能な数少ない手段です。
ダイアログを表示することでプッシュ通知の同意を求める貴重なアプローチは1回のみです。もし本当にプッシュ通知を利用して欲しいのであればこのアプローチを行う前にユーザにプッシュ通知を行う利便性を説くべきでしょう。
プッシュ通知は登録(登録要求)・解除・状態取得の3つのメソッドがあります。
プッシュ通知の初回のアプローチはstackoverflowに書かれているような方法で再度確認を行うことができる(はず)です。アプリの提出前に本当にユーザが望ましい形でそのアプローチが行われているか確認しましょう。

Objective-Cとブロック構文

st.lain — Thu, 24 Nov 2011 13:00:00 +0000

如何にもプログラマチックなタイトルですが、何のことは無い！　自分がほげグラムをする中でこれはブロック構文にしたほうが明らかに美しいと思われる部分を適当に選んだもの。

UIAlertView(alertView:didDismissWithButtonIndex:)…アラートビューのボタン押下が決定した瞬間に通知されるデリゲートイベント。UIAlertView-BlocksとかUIKitCategoryAdditionsが使えるらしい
SKPaymentKit(paymentQueue:updatedTransactions …マネタイズが必須なプロジェクトで使いまわしたいけど、ということでサンプル的に自分の過去ログ
UIView Animation (animateWithDuration:animations:)…iOS4.0以降で新規に追加されたプロトコル。多分、does animateWithDuration:animations: block main thread?あたりが有用かもしれない
NSURLConnection (connection:didReceiveResponse:, connection:didFailWithError:, connection:didReceiveData:, connectionDidFinishLoading:)…NSURLConnectionの非同期通信を使ったときに、非常に煩雑になる部分で有用だと思われるstackverflow投稿よりNSURLConnection and grand central dispatch

リンク先の記事の内容をすべて実践したわけではないので本当に使えるかどうか、については保証しかねますということと、私が関わったほんの一部であり、CoreAudioフレームワークのAudioBufferあたりはブロック構文にしても良いかもしれないかな、とか。

一方で、ブロック構文には気を付けるべきことが幾つかあるようなので(といっても有用なページが見つけられず案内できませんが)、使う前には予めその性質を理解しておくことも重要ですね。

Objective-Cのブロック構文

st.lain — Tue, 08 Nov 2011 14:51:55 +0000

iOS AppのInAppPurchaseの処理、となると大抵の場合はAppleから提供されているサンプルコードを利用すれば異なります。もちろん私もこのコードを使いながらも自分が使いやすいように購入部分のみをシングルトンクラスへ処理を移して、


Environment *environment = [Environment instance]
assert(environment);

BOOL request = [environment requestPurchase:@"MY_PRODUCT_ID"];
if (request == NO) { 
  UIAlertView *alert = [[[UIAlertView alloc] initWithTitle:....] autorelease];
  [alert show];
}


 
のようなコードを打てば好きなタイミングでプロダクトIDさえ渡せば処理は勝手にやってくれます。購入後にサーバ側で購入に対するデータ処理は行ってくれるので特にクライアントはそれ以上の処理が必要ないぢゃんと踏んでいたのですが・・・・。バカだったと反省した今日この頃です。となると、最終的にAppleサンプルでいうcompleteTransaction, failedTransactionの部分にデリゲートをコールするなんていう仕掛けを追加しなければならないのですが、結構デリゲート嫌いなんです。特に、今回のような1デリゲートに1プロトコルしか必要のない時は。
ここで思い出したのが、最近GameCenterで見かけたコール部分に関数定義を渡すような方法。この名前を知らずにググっていたらStackoverflowに引っかかりました。

How to perform Callbacks in Objective-C

How to simplify callback logic with a Block?

これを見ると単純に”blocks”としか書いてないですが、日本語の場合はブロック構文というみたいですね、多分。正直、このサンプルを見たときには意味不明な構文過ぎて理解しがたかったですが、それを除いても使う価値はあるものだな、と。ちなみに、私が書くとこんな感じになります。

Environment *environment = [Environment instance]
assert(environment);

BOOL request = [environment requestPurchase:@"MY_PRODUCT_ID" callback:^(BOOL result){
  // ここで購入後の適切な処理をする
}];

// ここのエラーブロックはリクエストそのものに失敗した場合
if (request == NO) { 
  UIAlertView *alert = [[[UIAlertView alloc] initWithTitle:....] autorelease];
  [alert show];
}

-------

@interface Environment

void (^_cbPurchaseHandler)(BOOL result);



@implements Environment

- (void)requestPurchase:(NSString *)product_id callback:(void(^)(BOOL))cbHandler {
  // 適切なproduct_idかどうかを調べたり、各種購入の前確認を行う
  ...(略)...
  
  if (invalid) {
    return NO;
  }

  // コールバックのハンドラーをコピーする
  _cbPurchaseHandler = [cbHandler];
  
  // 購入処理を走らせる
  [[SKPaymentQueue defaultQueue] addPayment:payment];
  
  return YES;
}

- (void) completeTransaction: (SKPaymentTransaction *)transaction
{
  // Your application should implement these two methods.
  [self recordTransaction: transaction];

  // コールバックを呼び出して購入処理に対する付与処理を行う
  _cbPurchaseHandler(YES);
  [_cbPurchaseHandler release];
  _cbPurchaseHandler = nil;
  
  // Remove the transaction from the payment queue.
  [[SKPaymentQueue defaultQueue] finishTransaction: transaction];
}

- (void) failedTransaction: (SKPaymentTransaction *)transaction
{
  // キャンセルも含めて購入が失敗したことをコールバックに通知する
  _cbPurchaseHandler(NO);
  [_cbPurchaseHandler release];
  _cbPurchaseHandler = nil;

  [[SKPaymentQueue defaultQueue] finishTransaction: transaction];
}


 
あ、所詮ほげったほげぐらまが書くコードなのであまり突っ込まないでね。いつもほげほげしていますが、今日はいつになく有意義なものを覚えました、とさ。なんでこんな回りくどい実装をしたかというと、プロダクトIDを渡して購入処理をする部分(恐らく大抵のアプリで共通)、とその結果を受けて付与する部分(アプリ固有の処理)で分けたかったから。
大層な処理ブロックでもないのでコピーすればいいぢゃん、なんですがそこは宗教が許さないのでしょう。だって宗教なんだもん・・・・

iOSのコントロールを即時で描画更新させる

st.lain — Sat, 01 Oct 2011 02:58:13 +0000

iOSのプログラムをしていたらひょんな事にハマりました。処理の例としては以下の感じ。

ユーザーに「DOWNLOAD」ボタンを押させる
NSURLConnection:sendAsynchronousRequest:queue:completionHandler:を使って非同期的に所定のNSURLRequestにリクエストを送信、NSDataを取得する (もちろん、NSDataで受信時はプログレスバーを更新する)
NSDataをGZipのストリームと判断し解凍する
2～3の操作を数回繰り返す

2. で受信プログレスを更新する際にはUIProgressView.progressにより随時更新の後、100%＝1.0の場合はそのまま解凍処理を走らせるのだから処理上では問題ないですが、以下のプログラムにすると恐らくプログレスバーが100%にならないです。

// TODO: 受信したデータを結合する
...(略)...

// プログレスバーを更新する
_progressView.progress = CLAMP([data length] / filesize, 0.0f, 1.0f);
if ([data length] < filesize) { return; }

// TODO: 100%ダウンロードできたので解凍処理をする
...(略)...

// 次のダウンローダをリクエストする
[self requestNextRequest];



処理が連続する場合にコントロールの再描画が必要となるプロパティ変更を行っても即時で再描画されない、言い換えれば、UIView:setNeedsDisplayが画面に対して即時処理されないということ、です。ここでWindowsの話を持ち出すのはナンセンスだとは思っていますが、あえて出させてもらうとInvalidateRect(HWND, LPRECT, BOOL)だけコールしてUpdateWindow(HWND)をコールしてない事になります。さて、ではどのようにiOSのコントロールを再描画させるか。あ、ちなみに間違ってもUIView:drawRect:を直接コールしないでねっ！
答えは簡単、NSRunLoop:runUntilDate:をコールして現在のRunLoopに対して処理のゆとり？を与えるということ。再描画フラグ自体は立っているのでその処理時間を与える、というイメージだと思われます(iOS専門ぢゃないから怪しいけど)。引数がNSDateなのでどこまでの時間を渡せばいいかということですが、かなり適当です。

// TODO: 受信したデータを結合する
...(略)...


// プログレスバーを更新する
_progressView.progress = CLAMP([data length] / filesize, 0.0f, 1.0f);
if ([data length] < filesize) {
    return;
}

// 解凍処理(しばらくの間の重い処理)に入る前に、再描画をさせる
[[NSRunLoop currentRunLoop] runUntilDate:[NSDate dateWithTimeIntervalSinceNow:0.05]];

// TODO: 100%ダウンロードできたので解凍処理をする
...(略)...


// 次のダウンローダをリクエストする
[self requestNextRequest];



という感じ。
0.05＝50ミリ秒ですが、これで十分だと思われます。10ミリ秒でもiPod Touch 4genでは正常に再描画されましたので、恐らくそれでも大丈夫だと思います。
あ、後、CLAMPマクロは独自定義なのであしから。やってることは #define CLAMP(v, x, y) MIN(MAX((v), (x)), (y)) なだけです。

本日のハマった一行

st.lain — Tue, 27 Sep 2011 16:14:49 +0000

プログラムをしているとたった一行だけのはずなのに何故か動かなかったりすることがあるかと思います。時々そんな一行をやらかすのですが、本日この一行で1時間ほどハマってました。

正常動作

[[Audio instance] play:[[AudioSource alloc] initWithPath:@"bgm.m4a"]];

異常動作

AudioSource *source = [[AudioSource alloc] initWithPath:@"bgm.m4a"];
[[Audio instance] play:source];

コードだけ見ると要はAudioSourceのインスタンス確保と初期化、そしてAudioクラスによる再生を行っています。Audioクラスはsingletonにより管理されていて常に唯一のインスタンスを返し、サウンド(ソース)の再生・停止を行います。

が、このAudioクラスが自分で作ったにも関わらずハマったという情けない話で、Audioクラスが最初にインスタンス化される際にはinitメソッドをコールするようになっています。つまりは、singletonクラスメソッドであるinstanceをコールした際にはご丁寧にもOpenALの初期化まで行っています。

ここまで書くと答えは明白で、異常動作のほうはOpenALの初期化前にALBufferを確保しようとして失敗していたと。たった一行や二行でも本気でわからないものです。

ちなみにこのオチに気がついたのが隣の同僚に「なんでだろ～」と聞いていた最中でふと思いつきました。その同僚はObjective-Cを知らないというのに無茶振り質問したわけなんですが・・・。いざ話してみると見落としがちな部分も気がつくものですね。

# 話す前に自分で気がつけって？、うん、自分でもそうしたいのですけどね。巧く行かないものなんです orz

Provisioningの注意事 @Xcode3系

st.lain — Tue, 20 Sep 2011 09:12:59 +0000

iOSの開発をしているとプログラム以外の割と煩わしいものにProvisioning(プロビジョニング)とCodeSigning(コードサイニング)なるものがあります。この2つは以下のことをコンパイルされたプログラムに情報提示するものです。

自分がAppleより認定された正規のiOSディベロッパである
プロダクトの署名が有効期限内に限って正しいものである (開発時のみ)
コンパイルされたコードは改ざんされてはいないコードである
デプロイ(インストール)先のデバイスが開発者から正式に認定されたデバイスである (開発時のみ)
InAppPurchase, Push Notification, Game Centerに関して有効 or 無効である情報をアプリケーションに与える

多分、思いつく限りでこんな感じ～のはず・・・・なんですが、適当です。なので、InAppPurchaseを使うにもInAppPurchaseが有効とされたAppIDに対して、その際に設定した適切なBundleIDをplistに設定して、更に適切なProvisiningを発行して、更の更にiTunesConnectでInAppPurchase用のアイテムを登録してようやく課金が行える・・・・なんて手間が必要なわけで。

とりあえず、InAppPurchase云々はさておき、未だ現役である可能性が非常に大きいXcode3系の、プロビジョニング／コードサイニングでハマる部分を以下に示します。適切なプロビジョニングを設定しているのにCodeSigningでWarningが出た場合は以下を確認してみてください(一部先日コメントしたInAppPurchaseにも関連します、多分)。

1. InAppPurchase、GameCenterが有効であることを確認する

iOS Provisioning Portal(iOS Dev Center内)のAppIDタブで一意なBundleID(ワイルドカードを含まないBundleID)ではない場合は図のようにInAppPurchase, GameCenterの部分にEnableが付きません。まずはここで適切なAppIDが登録されていることを確認しましょう。その上で、Provisioningタブからプロビジョニングを発行 or 再生成し、ダウンロードしてみましょう。

2. 適切なプロビジョニングを設定する

Xcode3系のバグなのか、プロジェクトツリーの[Project]→(右クリック)→[Get Info]からプロジェクトの設定を行っても適切に設定情報が反映されない場合があります。その場合は以下の手順で設定を行ってみましょう。

[Get Info]からではなくて、[Project]メニューの[Edit Active Target]から設定画面を出すのがコツです。私がコレにはまったときは2時間ほど困って1時間ほどググった挙句にようやく海外のとあるBlogerのホームページで対処を見つけました(が、原文はいずこかに消えました)。

書くまでもないですがこれは通常通りの操作、CodeSigningの際に使用するProvisiningを設定するだけです。

3. Xcode上でおまじないをする

今からほぼ2年前に私にiOSの開発を教えてくれたドイツ人のMさんが、非常に悩ましい顔をしながら「おまじないをするとコンパイルが通る場合があります」という事を言いました。もちろん、コンピュータ上で動くプログラムにそんな曖昧な要素などあるわけがないのですが、意外やこれが良く効くおまじないで。

[Build]メニューから[Clean All Target]を選択する
[Xcode]メニューから[Empty Caches]を選択する
Xcodeを終了する (ランチャーにランプが付いている場合は右クリックで[Quit]選択)
Finderからプロジェクト直下のBuildフォルダを削除する
Xcodeを起動してコンパイル開始

CodeSigningに使用するProvisioning(2.の操作)を変更してもどこかにキャッシュが残っているのか、おまじないが本気で有効な場合があります。慌てずにおまじないまでキッチリやった後にコンパイルすることをお勧めいたします。

って、情報を1年前に出しておけば救われた人が多かったかもしれませんね。まだ3ヶ月に満たないBlogですが、ハッハハハー、アーハッハハ＠オーマイオキー風。

※ Warningが出たときの詳細メッセージがただ今再現できないので、再現できた場合は検索にかかるように更新します。

iOS sandbox上での不具合と思われる現象

st.lain — Tue, 13 Sep 2011 16:46:54 +0000

iOS上で開発をする上で、特にゲームを開発する上で重要となる主機能では以下の2つは避けられないといっても過言ではない今日この頃だったりします。

InApp Purchase…アプリ内課金、アプリを先にダウンロードさせて機能を課金アンロックさせたり、オンラインゲームで仮想通貨を発行したり、新聞などの定期購読をサポートしたりと。
Game Center…SNSとしての機能をゲームに絞ったようなもの。リーダーボード(スコアランキング)や、アーチブメント(実績解除)を始めとして、ゲームの招待なども。

もちろん、その他多くの機能をiOSは含んでいるのですが、上記は開発環境としてiOS4.x上でサンドボックスが提供されている3機能の2機能だったりします(多分あっているはず)。で、この2つの機能をサンドボックスで利用するに当たってここ数日間不可解なエラーに見舞われたりして非常に時間を無駄にしたりと。

なので、ネットを調べたり自分の経験則上でこうしたら直った説(あくまで「説」です。Apple公式解決法ではありません)を書きたいと思います。

Case.1 InApp Purchaseで「iTunesStoreに接続できません」「Cannot connect to itunes store」のエラーが通知され、InApp Purchaseのトランザクションがコミットできない

よくある話でてっきりアカウントがsandboxアカウントから本番アカウントに移ったとか憶測していましたが、In-App-Purchaseにテストアカウントから接続できない(自堕落なぺぇじ)を参照して直りました。こちらにも同様、手順を記載します(自分は1, 2が逆でも大丈夫でした)。

開発アプリケーションを削除
設定→ストア→サインアウト、でテストアカウントを破棄
Xcodeよりデバッグを開始し、インストール & デバッガ実行
InApp Purchsaeで「既存のアカウントを利用」を選択し、iTunesConnectのテストアカウントを入力

Case.2 Game Centerで「このゲームはGame Centerにより認識されません」「this game is not recognized by game center」のエラーが通知され、Game Centerにログインできない

これも1日毎に1回起きる現象で、当初はiTunesConnectよりGameCenterのenable/disableを切り替えていました。が、もちろんアプリがリリースされた後にこんな操作はしたくないわけで。恐らくググるとBundleIDが異なるとか、プロビジョニング周りのアドバイスが多いようですが、それが原因でないのであれば以下の操作で解決するかもしれません。

アプリを終了し、ホーム画面に戻る
GameCenter(OS標準のアプリ)を起動する
GameCenterのログインアカウントをテストユーザ(sandboxアカウント)に切り替える
ゲームのタブを押して、登録されている開発アプリケーションを選択する
リーダーボード、アーチブメントなどを一通り表示してみる (表示されればOK)
GameCenterを終了し、開発アプリケーションを再度起動する

どちらも不可解な操作ですが恐らくこれで直るかと思われます。他プラットフォームでエラーが意味不明とかイラっとしますがその期間が少しでも短くなることを祈っております。

# でもね、Microsoftの製品で不可解なエラーがでたら速攻で問い合わせインシデントを使うんだっ！

uniqueIdentifierがdeprecation@iOS5

st.lain — Tue, 23 Aug 2011 15:05:04 +0000

割とiOS関係者ではホットな話題かな～と思う、UIDeviceクラスのuniqueIdentifierが非推奨(deprecated)に指定されました。どのような背景でこれが非推奨に指定されたのかわかりませんが、これに対しての対応を迫られるアプリケーションは多そうですね。ってか、私が今作っているアプリも(ry

私の場合は自業自得なんですけどね。JailBreakされた端末でAPIをフックされたら成りすましが可能だ、ということ知っていてそれを行っていたのですかｒ・・・（ごめんなさい、ごめんなさい

さておき、ゲーム的な側面で言うとちょっとイヤーンな状態は少なからずあるような。というのも、アカウント用途ではなくて純粋に機体識別を行いたい場合に何を使おうか、と。例えば無料ゲームを出しておいて誘われたユーザからインセンティブを与える、なんてのはソーシャルゲームでは割と普通なんですがこれに関してはユーザではなくて機体識別で行いたい、とか。

UIID(Unique Installation Identifier)を使った場合はユーザが複製可能であるので、インセンティブが何回も発生可能であると思われる
Appleが推奨する、ゲームのアカウントとしてはGameCenterのplayerIdを使うと良い、というのもAppleID毎なので複製は可能であると思われる
ぢゃあ・・・・、結果的にインセンティブが過剰に増やされないためにはどぉすればいいんだろう→機体制約なら物理以上に出回ることはない、かもしれない

とまぁ、こんな感じかな、と思ったり。さておき、個人的に怖いのが開発者なら割とMACアドレスは取得可能で、それも機体を一意に断定できる固有IDだよね！！！、とかいってMACアドレスを乱用するアプリが増えないかなとか。最初に言ったようにuniqueIdentifierが非推奨になった経緯はさっぱりわかりませんが、UDIDより推測可能なんです、多分。(上位6バイトがベンダID、下位6バイトが連番なので)

セキュリティにそこまで詳しいわけでもないし、非推奨となった経緯を改めて知った上で今後どうするべきかを判断するのも有りなのかな、と思いつつアプリを作るしかないですね。

Unreal engineとか

st.lain — Sun, 10 Jul 2011 15:51:52 +0000

つい先日PROPEなるゲームを購入しました。Unreal engineによるフル3Dの脱出ゲームです。正直、Infinity Bladeに続き改めてUnrealの凄さを痛感させられました。特に私は3Dが全くの無知なだけに本気ですごいなと。

一方で気になる部分を挙げると、なんで脱出なんだろう、、、。Unreal engine、確か特殊なライセンス形態なのですよね。
間違っているかもしれませんが、、、

誤り。。。。。。。
・初期リリース時に$5,000
・売り上げが$500,000を超えた段階でレベニューシェア25%

訂正
・売り上げが$50,000を超えた段階でレベニューシェア25%

桁間違えた上に条件も違っていた。。。。でもレベニューシェアなんですよね。

Appleに30%、Unrealに25%なんて取られたら儲けがないぢゃん。大ヒットならまだしも、それ意外なら赤字にならないかな、、、。その点私はやはりUnity3Dをオススメしますが。

うーん、なぜUnrealを選択したのか知りたいですね。