2013/09/26

最近のケイフィールド in September 2013

後藤です。雑記です。

iOS7が公開されてもう1週間経ったんですね。Windows8の前から、というより流行るよりずっと前から元々シンプルなフラットデザインが好きだったので、iOS7私は嬉しい派です。6月にiPhoneに変えたばかりなのでさすがにまだ変えないですが、5Sの指紋認証も5Cのチープっぽさも魅力的でいいなほしいなと思ってしまう、新しいもの好きの典型です。
私は先週にお盆休みを頂いていたためXcode5へのアップデートなども今週に入ってから行ったのですが、色々変わったりしている点があって、以前のもようやく慣れてきたところだったのに、とまだあわあわしております。もう少し前からBeta版を使って慣れておいた方が良かったんでしょうか。。
でも、それで色々調べたので、まだ日本語であまり資料がないようなことも、ちゃんとメモしてあります!来週くらいにはきっと技術的な記事を書くことでしょう。

今週の記事を雑記にしたのには(自分がそれが一番書きやすいからという以外に)理由が、あります!

インターンシップで大学生の皆さんに制作して頂いた作品について、先週「今週中にはAppStoreに…」というようなことを書いてしまっていたため、一応現状を報告したかったのです。もしかしたらインターン生の方が、ここを見ながら いつAppStoreで公開されるのかとわくわくしているのではないかと思って…。書きたいことはもう1点あるのですが、とりあえずそちらについてです。
結論から申しますと、前期・後期分ともまだ申請は行っていません(ごめんなさい)。 以前の記事にも書きましたが、今回のインターンシップではUnityさんから今回のための特別なTrialのライセンスを頂いていたので、そのお礼として 今回のインターンシップでの学生さんたちの様子や アンケートで頂いたUnityに関する意見などをまとめて報告させて頂いたりしました。それを行っていたのが先週、今週で、そろそろ社長がProのライセンスを入手して下さるということなので、きっと、来週には! 申請できるはずです…。 忘れているわけではありませんので、楽しみにお待ちください。

そして雑記の内容その2なのですが、今週土曜のJAWS FESTAに、なんとケイフィールド社員全員で参加して参ります。 お世話になっているコンサルさんと一緒に前日入りで大阪に行ってきます。大阪は何度か行ったことがありますが、大阪らしいものを食べれたことがないので そういう意味でもすごく楽しみです。
が、JAWS-UGを通して今までも色んな方とお近づきになれたりしていますし、 今までなんとなくしか分かっていなかったCDPについての初心者向けハンズオンに申し込みできたので、今回も色々学んだりしてそっちも大いに楽しみ、学びたいなと思っております。来週の記事はきっとその報告になることでしょう。

以上、後藤でした。

2013/09/25

議事録を書いていて気づく、メモの取り方のポイント


山田です。

最近は開発だけでなく、営業活動も行っています。営業活動をすれば当然議事録を書くわけですが、これが結構難しいですよね。いきなり清書ができるわけではないので、とりあえずメモを取るわけですが、これがなかなか役に立たなかったり、後で内容を思い出せないといったことが起こった経験はありませんか?

結局メモを議事録のフォーマットに清書するために何時間もかかるはめにならないために、やった方がいいこと。それは以下の3つ。


1.箇条書きで書くな、複雑なことは図解で書け

2.営業の目的と議題を先に書いておけ

3.決定事項と次のアクションは書く場所を意識して確保しておけ



1.箇条書きで書くな、複雑なことは図解で書け

箇条書きだと物事の関連性がわからなくなりがちです。
例えば商品の受発注のシステムの議論をしている時、図解で書けば、発注から受注、商品番号の発行や、それらの承認フローなどが簡単に表現できますが、箇条書きだとそうはいきません。

膨大な量の文章を一生懸命メモしたあげく、後で読み返すと何の議論のメモなのか、ある作業の流れのどの部分の話だったのか、わからなくなってしまいます。

普段パソコンでタイプしていて、よくこの失敗を繰り返す人は、是非図解でメモをとりましょう。



2.営業の目的と議題を先に書いておけ

議事録を取ることに夢中で、「何の目的で議論をしているのか」見失っていませんか?もしあなたが大切な議論、決定事項を記録ミスすることがあるなら、是非やりましょう。目的、議題をあらかじめ記入しておくことで、議論の中で「どんな課題を解決するために話し合いをしているのか」忘れにくく、大事なことを聞き逃したり、メモをし損ねるといったミスがなくなるはずです。



3.決定事項と次のアクションは書く場所を意識して確保しておけ

誰がどんな発言をしたか記録することは大切です。しかし最も大切なことは「何が決定して、次にどんな行動をしなければいけないのか」わかるようにすることです。

したがって意識的に「決定事項」と「次のアクション」を書くスペースを確保しておくことで、議事録で最も大切なことをしっかりと押さえることができます。

また次のアクションでは、「どこの誰が、どんなアクションをするのか」まで具体的に書くことがポイント。



以上です。

2013/09/18

Mac上のWindows仮想PCからPDFに印刷するには

しばらくブログ書くのサボってた今井です。
今回のお題はThriftは一休みして

Windows仮想PC上のアプリからPDFを作成したい

です。

ケイフィールドでは全員Macを使っているのですが、開発案件では必要に応じてWindows仮想PCを使います。

Windowsアプリで編集した文書をPDFにしたい事もよくあるのですが、Macと違ってWindowsは標準でPDFを作成する機能がありません。

そこでPDFプリンタアプリが必要になるわけですが、個々の仮想PCにインストールするとインストールやアップデートなどが面倒なのでMacにインストールして共有することにしました。
Macは標準でPDFを作成できるのに余計なものをインストールするのは抵抗ありますが…

以下の環境で動作確認しました。
ホストPC : Mac OS X 10.8.4
仮想化アプリ : Parallels 9
ゲストPC : Windows XP
PDFプリンタ : CUPS-PDF 2.6.1
昔から使っているので Mac OS X や Parallels は過去のバージョンでも動くと思います。


CUPS-PDF のインストール

CUPS-PDF は MacPorts でインストールしました。
ターミナルから次のように行います。

$ sudo port selfupdate
$ sudo port install cups-pdf


Windows仮想PCのプリンタ設定

特に設定不要というのを狙っていたのですが、そのまま使うと文字化けする場合があるので設定を変える必要がありました。個々にアプリをインストールするよりマシですが、この手間は残念ですね。
  1. Windows上のプリンタとファックスから『CUPS-PDF のプロパティ』を開く
  2. 『詳細設定』タブを開き『標準の設定...』を開く
  3. 『レイアウト』タブの『詳細設定...』を開く
  4. 『PostScript 出力オプション』を『エラーが軽減するように最適化』に変更する
  5. 『OK』を選んで設定画面を閉じる
以上の設定で文字化けが治りました。


CUPS-PDF の PDF ファイル出力先

CUPS-PDF プリンタで印刷するとファイルは /opt/local/etc/cups/cups-pdf.conf で設定された場所に出力されます。
MacPortsでインストールした場合、デフォルト出力先は /opt/local/var/spool/ユーザ名 です。
CUPS-PDFプリンタと出力先を共有しておけば便利かもしれません。



Windows からプリンタ経由で PDF に出力できると、PDF作成だけでなく正確な印刷プレビューとしても使えますので便利ではないでしょうか?

2013/09/17

大学生のインターンシップ(後期)がありました

後藤です。

先々週、先週の平日10日間で、大学生インターンシップの後期分が行われました。
概要は前期と同じですが、今回はチーム名を考えてもらったりしたなど少し内容を変えた部分もありました。
大学生の皆さんに制作してもらったアプリは、前期の分もあわせて今週中にAppStoreへ申請する予定でいます。どちらも色々考えてもらって、それぞれの特性をもったアプリが出来上がりました。
AppStoreにアプリを登録するのは私は初めてなので(自分の制作したものではないですが)、DL数がどうなっていくのかなど私も楽しみです。

大学生のインターンシップ参加者の皆さんには、Unityのことだけでなく、作品を作っていく上でどういったものを作っていくか案を出すための方法、ブレインストーミングなどについても学んでもらっています。そういったお話をするからには、もちろん自分たちもそれなりにその手法についてあらかじめ知っているのですが、それでも案出しをしている段階で つい実装方法や自分たちのスキルなどを考え否定をしてしまいがちです(これも山田さんが前に記事で書いていました)。
ちょうどそのあたりの話を学生さんたちにしていたあたりで、今井さんと新製品についての案出しをしているとき 自分が否定の意見ばかり出していることに気付きました。説得力のかけらもない事態でした。気をつけたいです。
今回参加した子たちも全員がプログラミングを経験している子達だったから特になのか、最初の案出しの段階で それは自分たちに実現不可能じゃないかという話が何度か出ているのが聞こえました。彼らの製作期間は5日弱なので、最初から実現可能な案を出していかないと“納期”に間に合わせるのが難しいのかもしれません。が、自分たちが実現できる範囲でと案を出していると、やはり斬新なアイデアには発展しにくいです。彼らはそれでもクオリティの高いものを作り上げてくれましたが…。10日間という期間、どうしようもないのですが難しいですね。

今回で、ケイフィールドの2013年夏期のインターンシップは終了になります。
インターンのことを任されたときは、入社1年目の分際で学生の子たちに偉そうにものを教えられるんだろうかと思ったものですが、資料を作っていたりする中で、大学を卒業しケイフィールドへ入社してからの4ヶ月で多くのことを学んでいたことに気付きました。私はまだまだ社会人らしい振る舞いについて未熟ではありますが、入社1年目だからこその 学生から社会人になって気付いたことなどを教えられたんじゃないかな、と思っています。反省も多いので、それは次の機会に忘れず生かしたいです。

最後に。今回のインターンシップに参加してくれた、チームTNKT(とんこつ)の皆さんです。余談ですが、彼らは歌志軒を勧めたらとても気に入ってくれたようで、後半5日間の昼に毎日食べに行っていました。チームとんこつなのに、油そば…。
10日間お疲れ様でした。


2013/09/06

EclipseでAndroid開発環境を整える

山田です。
普段iosの開発が中心の僕ですが、Androidの開発にも携わることになったので、開発環境の整備を行っています。やったことがある人はよくわかると思いますが、環境の準備って大変です。辛かったです。

K.fieldでは道具の使い方や環境を整える際に、一緒に作業手順書を残します。
そうすれば、次に同じ作業をする人達が、僕みたいに道具に振り回されて貴重な時間を使わないようにすることが可能です。後輩にわざわざ同じ苦しみを味合わせる必要はありません(笑

今回はEclipseでAndroidの環境を準備し、シミュレータで動かす所までの手順を紹介します。
2013/09/06時点での手順書になります。

Eclipseのバージョンは「Juno」
Androidの環境は「4.2.2(API17)」





*1 ADT(android developer tools)のインストール手順

・Eclipseを起動して、メニューからヘルプを選択
・Installing New Softwareを選択
・Work withのAddを選択して、リポジトリを追加する
・名前とロケーションはそれぞれ、「https://developer.android.com/sdk/index.html」と入力する
・開発ツールとNDK Pluginsを選択し、使用条件に同意するかどうか聞かれるので、全て同意する
・インストール完了





*2 Android SDKのインストール手順

・EclipseメニューのWindowを選択し、Customize Perspectiveを選択する
・Android SDK & AVD Managerの項目にチェックを入れる(これでメニューからAVDが選択できるようになる)

・EclipseメニューのWIndowから、Android SDK Managerを選択
・パッケージのToolsと、Android4.2.2(API17)を全て選択し、インストールすれば完了





*3 Androidシュミレーターの起動

・EclipseメニューのWindowから、AVD Manegerを起動する
・「NEW」の項目からAndroid仮想でバイスの作成をする

・名前「Android4.2.2」 
・デバイス「Nexus4」
・ターゲット「Android4.2.2(API17)
・CPU「ARM」

今回は以上の設定で起動実験、シミュレータが重たいので5分くらい時間がかかります。

ここまでセットアップできれば、あとはプロジェクトをビルドすることで、設定したシミュレータを選択して実行することが可能になります。


以上です。



ゲーミフィケーションを取り入れる(その1.5)

後藤です。

以前私もゲーミフィケーションについて色々と本を読んで学んだので、(山田さんが前に書いたきり2回目を更新されていないのをいいことに)自分用メモを見て思い出しがてら、ビジネスに取り入れられるゲーミフィケーションの要素について簡単にまとめてみようと思います。

前の記事:ビジネスにゲーミフィケーションを取り入れる(その1)


■ ソーシャル

自分だけでなく他のユーザとの交流があること。他のユーザと競争や協力をさせることなどで、サービスから抜け出しにくくなる。

実際に自分がとあるソーシャルゲームにものすごくハマってしまっているのですが、前よりもどっぷりハマってしまった原因は、カードのトレードをするために仲間になった人たちがものすごくヘビーユーザー(いわゆる廃課金)で色々とプレゼントしてくれたりと良くしてもらえるので、お返ししたいなと思ったり、その人たちが持っているレア度の高いカードが羨ましくなったりしたせいだな、と思います。ソーシャルでなければきっとこんなに貢ぎませんでした。
色んなソーシャルゲームに手をつけましたが、どのゲームも挨拶のような機能があり(1日1回目はポイントがもらえたりする)、メッセージが送るとさらにポイントがもらえます。それだけだとあんまり毎日やったりしないのですが、ヘビーユーザの方はゲーム内容やキャラクターについてなどの返事したくなるメッセージを送ってくれることが多く、お返しのメッセージをすると更に返事がきたりして…。段々仲間の人と仲良くなっていったりすると、あいさつを見るために頻繁にログインしてしまうようになりました。


ゲーム以外でソーシャル的な要素をもつとして紹介されていたのが、ハーレーです。私はバイクなどは詳しくないのですが、ハーレーは自分でカスタマイズできる要素が多く(カスタマイズもゲーミフィケーション的要素の一つです)、そんなハーレーのユーザ同士で互いの自慢の機体を見せ合ったりするような場が公式で用意されているそうです。同じもののファン同士での交流は、やっぱり楽しいものですよね。


■ カスタマイズ

ハーレーのところで少し出しましたが、これもゲーミフィケーションの要素のひとつです。サービスやコンテンツについて、何かそのユーザだけのオリジナルのカスタマイズができる要素があると、ユーザはそのサービスについて愛着を持ちやすいんだそうです。

ソーシャルゲームでいうと、自分のカードのデッキなどがそれにあたるんでしょうか。デッキは好きなキャラで揃えたいものですが、カードは良いものは無課金のままではほとんど巡り会えず、有料のガチャを引いて自引きするか、そのガチャで出た自分は要らない(けど他のユーザにとっては価値のある)カードを他のユーザとトレードして揃えていくほかありません。
あとSNSに必ずといっていいほど用意されているアバターは、まさにカスタマイズ要素ですね。私はアバターはけっこうどうでもいい派ですが、そんなにお金はかけないとはいえ 自分の好む感じのものにしておきたいものです。初期アバターだとトレードのときに信用を得がたい風潮があるのもあるんですが。モバゲーにもGREEにもアバターのコンテストとかがあって、毎回テーマに沿ってアバターを変えたりして入賞を競うアバター廃人の人もたくさんいるみたいです。

また、有名どころだと、iGoogle(まだ存在するんでしたっけ)とかMyYahooとかも、そういったカスタマイズ要素を用いることで、自分のサービスをデフォルトで使ってもらおうとしているのではないでしょうか。


■ カムバック

特定の時間が経ったらまた戻ってきてサービスを利用してもらうための仕組みです。

これまたソーシャルゲームでいうと、たいていどのゲームも1日1回ログインボーナスのようなものがあって、ログインするだけで何かプレゼントがもらえたりします。また、「最近プレイしていない人をログインさせたらプレゼント」とか逆に「久しぶりにログインしたらプレゼント」みたいな褒賞の仕組みがあるものもあります。 もう興味がなくなったゲームをまたプレイしないかという連絡がくるのはうっとうしかったりもしますが、プレゼントがあるなら久しぶりにプレイしてみるかと思うこともきっとあるでしょう。

私が行っている美容院は、トリートメントをして 45日以内にまたしに来ると50%OFF、60日以内に来ると40%OFFになります。50%OFFはかなり大きいですし、また定期的に利用しようと思ってしまいます。


■ レベルアップ・ランクアップ

自分の現在の状況が数値等で記録されそれが可視化されていて、目標設定ができたりすると続けやすいものだそうです。レベル・ランクが上がるごとに報酬があるとより効果的で、普通では続けにくいものに対して利用します。記録するだけダイエットみたいなものもありますよね(私はやせませんでしたが)。

レベルアップというと、ほとんどの一般的なゲームはそういうシステムがあります。経験値がたまって、レベルが上がって、強くなってさらに上を目指していったり。オンラインだと、ランキングがあってレベル上位者がみんなに見えるようになっており、ちょっと優越感を感じられたりなど。

これもブログのどこかで誰かが書いていたかもしれませんが、私たちケイフィールドの社員達が皆ハマっている油そばのお店の、スタンプカードがこの要素を用いています。最初に油人というランクのスタンプカードから始まり、スタンプがたまるたびに玄人→将軍→極とランクが上がっていき、ランクアップするごとにもらえる特典も豪華になっていきます。社長や今井さんは将軍になっていましたが、油そばがおいしいからというよりそのランクアップが目当てで通っている節があり(もちろんおいしかったり他にも魅力を感じるからそこまで通いつめるんだと思いますが)、見事にゲーミフィケーションにはめられているようです。
他にも、読んだ本ではディズニーランドのキャスト(スタッフ)に対してこの要素が使われていることが書かれていました。キャストが良い仕事をしていたところを上司に見てもらえると、ファイブスターカードというものがもらえます。これを集めると何か記念品がもらえたり、これの所持者しか参加できないパーティに参加できたりするそうです。ディズニーランドで働くようなディズニーファンからすると、すごくたまらないものなんでしょう。


■ オンボーディング

初めてサービスを利用する人をサービスに定着させるための仕組みのことです。よっぽど魅力があることがあらかじめ分かっていない限り、最初に使い方・進め方がわからないサービスは サービスの初心者にすぐ見捨てられてしまいます。

ソーシャルゲームだと、たいてい最初にチュートリアルがありゲームの基本的な利用法がナビゲーションされるようになっていて、最後までこなすとなにかレアカードなどがプレゼントされるようになっています。ソーシャルだけでなくて最近のゲームはほとんどが、進めていきながらプレイ方法を少しずつ学んでいける仕組みになっています。説明書はほとんどの人が読まず、説明書を読まないと進められないゲームは投げ出されがちです。

ゲーム以外の(WEBを含めた)アプリケーションなども、初めに利用する機能はガイドが表示されたりするものが多くなったように感じます。
本で読んだ中には、「多機能すぎて何をどうすればいいのか分からない」電子レンジなどの例もありました。食べ物を温めたいだけなのに、ボタンが同じようにいくつも並び文字がいっぱい書いてあってどう操作したらいいか分からない、など。オンボーディングができていない例です。
また、(入社一年目の私が言うのも何ですが)新入社員教育にもオンボーディングは重要だと聞きます。仕事/サービスに慣れさせ軌道に乗せるまでの手助けをする。 多すぎるとうっとうしがられるし、少なくても仕事/サービスへの意欲が薄れてしまう。ものを教える・伝える技術は永遠の課題で、一概にどれが良いと言えるものではないですが、その場その場で求められているものは何なのか 相手の行動を考え、空気を読んで必要な情報を差し出せる努力をしなければならない、のだと思います。


といった感じです。他にも色々まとめてあるのですが、すでに長くなっているのでこのあたりにしておきます。
後藤でした。

2013/09/02

【Unity】DetonatorをiOSで動かしたとき発生するエラーについての検証

後藤です。先週分のブログです。

インターンシップ中、UnityのDetonator Explosion Frameworkという、爆発を簡単に表現できるアセットを利用していましたが、このアセットを利用するに際して 何故かMacOSX上ではちゃんと爆発するのにiOS上へ移すと爆発しない という謎の症状を2度経験したので、今回はそれについて検証してみたいと思います。

※ そもそもDetonatorはiOSでの動作をサポートしていないということではありますが、今回はやむを得ないのでそれを踏まえた上で原因追求しています。


■ エラーが出た環境と仕様


環境は、MacOSX10.8.4。Unityは4.2、Xcodeは4.6.3。Unityのライセンスは、現在はUnityさんにインターンシップ用で頂いたイベント用ライセンスを使わせて頂いています。実機のほうはiPhone4SとiPodTouch第5世代で試しておりどちらもiOS6(同じ症状が出るので実機の違いは症状には関係ないと思われる)。

実例1)シーン上に配置されているCylinderのオブジェクトにボールが衝突(OnCollisionEnter)したときにInsitantiateでDetonatorに用意されているプレハブが生成され爆発が発生する。はずだが、Mac OSX上では爆発が確認できるのにiOSで動かそうとすると爆発しない。
実例2)上とほとんど同じ。元々はCubeをTriggerにしてOnTriggerEnterしたときにInstantiateするような書き方だった、がiOSでは爆発せず。ただDetonator-Baseのプレハブをシーン上へ置いただけというふうに変更してみたり、他のアセットやオブジェクトを全部なくしてみたりと色々と試したが治らなかった。

実例1の時には結局Detonator自体を削除してもう一度インポートすれば解決したが、実例2の際にその方法を試したときは解決しなかった。


■ とりあえず表面上の原因




XcodeのDebug Areaを見ていると、Explosion2スクリプトのOnCollisionEnter → Instantiateでインスタンスを作ったときの FillDefaultMaterials → DefaultFireballAMaterial → MaterialのShaderうんぬんのところでNullReferenceExceptionが出ていることが分かる。
おそらくマテリアルとかが存在しないというようなエラーだと思われる。Shaderがどうのとあるので、new Material()ができていないのか、Shader.Findが失敗しているのか?
今回はDetonatorのプレハブを設定等をいじらず使っていたので(ただ今回はインターンに参加された学生さんたちの作るゲームで発生したものなので、いじっていないのかどうかは定かではない)、FireballAMaterialをはじめとしたマテリアルのところには何も設定をしておらず、そのためこのDefaultFireballAMaterial()、FireballBMaterial()、SmokeAMaterial()…(以下略)はSystemのデフォルトのマテリアルが使われることになっていた。ここがダメらしい。


■ とりあえずの解決策


Default〜がダメだったら、プレハブにマテリアルを直接指定してDefault〜の中でマテリアルを作らせなければいいのではないかと思ったら、それで良かったらしく、一応iOSでも爆発するようになった。
マテリアルは初め一々自分で作ってDetonatorの中にあるTexturesを指定しShaderの設定とかも行っていたのだが、そんなことをしなくてもSample Supporting Emitters→Materialsフォルダの中にマテリアルが用意されていた。ので、それをプレハブのInspectorのところで設定した(図2)。HeatwaveはProのみの機能だそうなので設定していない。



しかしなぜPCでは動くのに実機ではそれが反映されないのか…。


■ 原因の追及


他人が作ったものではどうしてこのバグが発生するようになったのかがはっきりと分からないので、自分でその状況を作るべく色々試してみることにする。

(手順)

【1】プロジェクトを作成し、シーンをAssetsフォルダ直下へ保存しておく。
【2】DetonatorをAssetStoreからインポート。場所はAssetsフォルダ直下。Test Sceneは最初からインポートに含まずチェックを外しておく。NormalMap SettingはIgnoreにしている。
【3】プレハブDetonator-Baseをそのままシーンにオブジェクトとして追加し、MainCameraに映るところへ配置


【4】Mac上のUnityでちゃんと爆発しているか確認
【5】Build SettingsでプラットフォームをiOSに変更、Add Currentで現在のシーンを追加してiOS向けにビルド

さっそく例のエラーが出た。

【6】オブジェクトに適用させたスクリプトでInstantiateさせるようにしてみる
インターンのカリキュラムではCubeオブジェクトにスクリプトを当ててそのスクリプト中でInstantiateし爆発させる方法をとっていたので、一応そちらでも試す。
書いたスクリプトは以下のとおり(Explosion.cs)。

using UnityEngine;
using System.Collections;

public class Explosion : MonoBehaviour {

     public GameObject bombType;
     private float INTERVAL = 5.0f;
     private float timer;
    
     void Start () {
          timer = 0.0f;
     }

     void Update () {
          timer -= Time.deltaTime;
          if(timer < 0.0f){
               Instantiate(bombType, this.transform.position, this.transform.rotation);
               timer = INTERVAL;
          }
     }
}
そのままHierarchyへ放り込んであったDetonator-Baseのプレハブを削除。CubeにExplosion.csを適用させ、InspectorでBomb TypeにはDetonator-Baseを設定しておく。
Explosion.csを適用させたオブジェクトが(というかその位置で)爆発するといった感じの書き方になっている。Startの時だけInstantiateしても良かったが、最初の1回だけだとiOSへビルドしたときに爆発したかどうかよく見忘れてしまうので5秒おきに爆発するようにしてある。
が、しかしやっぱりエラーが出るままだった。

【7】他のDetonatorのプレハブを試す
BombTypeを他のものに変えて試してみた。ら、これがちゃんとiOSでも爆発するものとしないものがあることに気づいた。
ちなみにうまくいかないものは以下のプレハブ。どれもMacOSX上では動作することを確認している。
  • Base
  • Crazysparks
  • MultiExample
  • MushroomCloud
  • Sounds(これに至ってはXcodeでアセンブリのが出て起動前に止まってしまった…)
  • Spray
  • Tiny
  • Wide
※ Heatwaveは試していない。

【8】各プレハブに関連付けられているスクリプトを比べる

このスクリプトの何かがいけないのではないかと見てみたが、特にそういうわけではなさそうだった。強いていえば大丈夫だったほうはSimple以外Sprayがついており、ダメだった方はSpray以外Sprayがついていないというのはあったけれど…。
というよりBaseとSimpleは同じDetonator.csの基本のファイルしかついてないみたいなので、この設定内容の違いなのではないだろうか、と。

【9】BaseとSimpleのDetonatorの設定内容を比べる
 

Simpleの方にはDirectionの中で全てSparksが設定されている(左)。Baseの方は全てNone(右)。
他のものも見てみたが、Detonatorスクリプトの中でマテリアルが指定してあるものは他にない。

【10】Simpleのコピーを作ってみて設定をBaseに近づけて動かなくなるか試す
ちゃんと動いていたDetonator-Simpleプレハブを複製してDetonator-Simple_copyとし、それをCubeのExplosionスクリプトのBombTypeに適用させることで実験してみる。
とりあえず一番大きな違いである、Derectionのところに設定してあるSparksマテリアルを全て外してみる。
ダメだった。やっぱり原因はこれのよう。

OKだったプレハブの共通点は、
  • Chunks:SprayスクリプトのSpray ObjectにChunkがついてる
  • Ignitor:ForceスクリプトのFire ObjectにBurninatingがついてる
  • Insanity:SprayスクリプトのSpray ObjectにChunk/ExplosionArmsがついてる
  • Simple:Detonatorスクリプトにマテリアルがついてる
  • Upwards:SprayスクリプトのSpray ObjectにChunk/ExplosionArmsがついてる
と、マテリアルが設定されているか、〜〜Objectという名前のところにプレハブが設定されているよう。逆にNGだったプレハブの共通点はオブジェクト・マテリアルを設定する箇所が全てNoneになっているという点だった。
(SprayプレハブはExplosionArmsがついていたが、おそらくこれはマテリアルとかが設定してあるオブジェクトではないということだと思われる。)(上記OKだったものはExplosionArmsがついてたSprayスクリプトの他にChunkオブジェクトがついているSprayスクリプトも持っていたので、これのおかげで動いていたのだろう。)

ForceスクリプトにはFire Objectを設定する箇所があり、このスクリプトがつけられているMashroomCloudとTinyのプレハブに、Ignitorについていたのと同じBurninatingオブジェクトを設定してみたら、この2つに関してはiOSでも爆発するようになった。(何かちょっと違う感じだけど…)

Burninatingプレハブを見てみると、これにはFireballA・Bとその下のSmokeプレハブにもSmokeA・Bが設定してあり、同じようにChunkの方もSmokeTrailに色々設定されていたので、そういうことなんだろう。


ということで、どこが原因だったのかは分かってきたので、次に同じエラーが出たら対処はできるはず。けれど、そもそもなぜMacだと良くてiOSだとダメなのか(他のプラットフォームではどうなのか)とか、そもそも前に他のプロジェクトでやったときはBaseとかのNGだったプレハブも普通にiOSで動いていたような気がするけど何の条件でできなくなるのか とか、そのあたりが未だ不明なので追及していく必要がある。

また、今までDetonatorの仕組みがよく分かっていなかったので(インターンシップの)資料の通りにPrefab Examplesを利用していたが、そもそもプレハブではなくてオブジェクトにCompornent→Detonatorで自分で設定を作りプレハブを作った方が安心安全なのかもしれない(しかもそうすれば最初からマテリアルがついてるし…)。
ちなみにCreateEmptyで作った空のオブジェクトにCompornent→Detonatorで基本のDetonatorスクリプトとDetonatorForceスクリプトをつけて何も設定は変更しないでビルドしてみたら、(ForceのFireObjectがNoneのままでも)ちゃんとiOSでも爆発した。ので、今のところ爆発の色だとか煙のマテリアルを変更したいとかそういう予定はないし、このエラーが発生したときはとりあえずDetonatorスクリプトにデフォルトのマテリアルをつけておくのが一番楽な対処法かな、という結論に至った。


それでもって、Xcodeを見ていてDetonatorをiOSで動かすとフレームレートが下がりまくりでとてもよろしくなさそうなことにも気づいたので、そもそもやっぱりiOSのゲームでDetonatorは利用しないべきなんだろう、ということがよくわかりました。


13/09/06補足:今きているインターンシップの子たちに試してもらったところ、(今までの子たちはDetonator(Base)を入れた後すぐにiOSで動くか確認するという作業をしていなかったため気付かなかったが)全員実機では爆発しなかった。ので、UnityからXcodeだか、C#からObjective-Cだかに変換するときに何か起こっているのですね。。Detonatorが持っているバグ(サポートしてないのでそう言っては語弊があるかもですが)なのか、言語の違いによるものなのか…は今の私には分からないので機会があったら調べたいと思います。