アプリ無事公開、そしてデベロッパーセレクト

無事バイオリズムアプリをアマゾンストアに公開して２日。

なぜかアプリがカテゴリ３位になっています。

「そんなに売れてるのか？」とか、「売れてんだろう？ｗ」とか言われつつも実のところさっぱりです。
（ホントに四捨五入で0個になるくらい売れてませんｗ）

ちょっと珍しいカテゴリ？に配置したので、そのせいかもしれない？という予感です。
よくわかりませんが上位なのは良いことです、少しは目立ちますし( ﾟ∀ﾟ)

アマゾンデベロッパーセレクト

検索すればでてくるので詳細は割愛。

アプリは２つストアに登録済み、双方ともデベロッパーセレクトの認可が通ったようです。

ということで、

• アマゾンモバイル広告５０万インプレッションが無料っ！
  ※期間設定はアマゾン側で自動設定なようです。Adはアマゾンネットワーク内限定。
• アマゾン コイン リワード～云々。アマゾンゲーム内通貨が初期購入時に250枚無料おまけ。
• アマゾンのサービスAWSが最大500USD範囲で25%オフ。

の特典がゲットできたようです。


広告は嬉しいですね無料で宣伝してもらえるわけですよ。早速ポチっと広告設定。

一応ターゲットマシンはKindle Fire想定で開発しているので、アマゾン内広告は嬉しい。なにせ見る人は全員課金登録済みなのでGooglePlayよりも購入率が上がる可能性が高そうです。

AWSはクラウドゲーム配信SDKも提供開始しているので、あわよくばそこで２５％オフできるかもしれないです。

ということで、なんとなく気分良くスタートですよヽ(´ｰ｀)ﾉ

アプリ完成＆アマゾンストア登録完了！

完成後、EIN待ちで長らく放置(?)されていたAndroid用バイオリズムアプリのアマゾンストア登録が完了しました！



製作期間は1月半弱でしたが、その後アマゾンストア登録に必要な準備でさらに1月程かかってしまいました。

登録までの工程としては、

• １ヶ月半 ：Unity学習、アプリ制作
• １ヶ月：EINコード申請取得（約４週間）
• １ヶ月：新生銀行口座開設手続き（約４週間）

EIN申請と新生銀行手続きは並行して行ったので実質２ヶ月半程です。

EIN取得、口座開設の為１ヶ月ずれこんでいるので当初からも並行して進めておくべきでした・・・事前調査が甘かったですね；。


登録したてだと検索にでてこないのか、自分のアプリが発見できませんけど！（笑

とりあえず制作は終了で一区切りつきました(´∀｀)。

※追記：
登録完了ステータスとなってから、ほぼ丸１日程度でアプリストアに反映されるようです。
Sell数もDEVELOPER CONSOLEにはリアルタイム反映しないようですね。

#11.進捗

自分用的にも進捗メモ。

開発開始から約２５日経過で基本動作可能な状態（β１）。
計算精度確認済み。
Kindle Fire HD8.9実機動作で56～60fps動作確認済み。


工数割合はざっと、
C#コード実装＞＞＞＞モデリング＞テクスチャ＞＞＞＞＞＞＞サウンド（半日位）。

Unity学習も込みなのである程度の工数増はしょうがない。
Unity経験済み後なら２週間以内リリースを目指したいところ（白目。


一ヶ月でリリース予定だったがちょっと厳しい。
実装完了＝終了ではない＞アマゾン用AD追加、アマゾンストア用リリースガイドラインの確認等が必ずある。
C#実装工程で時間を使いすぎてる＝一部の機能実装の評価に時間をかけすぎ（笑。これらを早期割り切りしていれば１週間は確保できていたハズ。

■おおむね実装完了

• モデリング（Blenderでゼロベースから作成）誕生日入力ダイアル 、計測日入力ダイアル（００００～９９９９年）
  メモリセレクタ(１～５）
  ボリュームセレクタ（Full/High/Mid/Low/Mute）
  モデリングはVertex数、CastRayを考慮して２回程再調整。
• テクスチャ
  Photoshop5.5でゼロから作成。
  テクスチャのアトラス化はしていない（今回はしない予定）。
• サウンド作成
  商用フリー素材より加工（Soundit3.0LE使用）。Wav形式。
• コード実装　　※そもそもC#は去年仕方がなくちょっと使った程度。
  各パーツの連動制御を実装。基本動作可能。
  ユリウス関連相互演算クラス。その他西暦関連補正演算含む。
  キー入力クラス（低層、キーリピート等フィーチャ層）。
  サウンド管理クラス。
  画面動的遷移制御クラス（iTween使用）。
  バイオリズムグラフ線描画。OpenGL2.0ESの関数で3D空間に描画。
  バイオリズムグラフに付記する日数文字。メッシュテキストで実装ゴリ押し。
• その他
  ＯＳ識別によりAndroid時「戻る」キー対応。
  Android用証明書同梱ビルド。
  アプリアイコン暫定付与。

■割り切り項目

• 加速度センサによる論理画面の縦横変更対応
  横にすると拡大倍率がデバイス側で縮小される。これは画面比率10:16の縦16が10に縮小される為。
  → 画面は縦Portrait固定で割り切る。
  　　次回まじめにやるならカメラ倍率を動的に制御すればできる。
• 論理画面を自動回転に任せると180度回転時５～６秒かかる。
  → 右画面は縦Portrait固定で割り切る。
  　　次回用いる場合でもUnityの自動回転関数を用いる方が無難。90度回転は早いので割り切り項目。
• 論理画面回転による動的UI
  → 画面は縦Portrait固定で割り切る。
  　次回これをやる場合はデザイン段階で充分に詰めておくべき。
• テクスチャのアトラス化
  速度が50～60fps、DrawCallも50そこそこなので今回は放置。

■残作業項目

• 操作性改善を再検討。キー入力クラスの見直し。
  タッチスクリーンのスワイプ的な入力I/Fに対応作業中。工数的に割り切りたかったが低機能なら簡単にできそうなので実装してみる。→追記：完了。
  AssetStoreのものは高機能すぎるので今回は見送り。
  セレクタの操作がしにくい件の改善対策も含む。→追記：完了(2/6)
• グラフの意味の付記
  メッシュテキストで表示を行う。→追記：完了(2/6)
• アマゾンADの追加
  追加方法調査要。難航を極めそうな予感。Unityスタンドアロンでは無理くさい気配。
• 動的カメラ移動機能を残すか再検討。現状Disable。
• 日付入力のリセットボタンが必要かどうか再検討。
• KindleOS認識方法確認。たしかアマゾンのどっかに情報がある。

■要確認項目

• 画面Ratio補正実装 -> 動作未確認。要各種異Ratioデバイス。
• アプリ内状態の保存方法。
  ResumeというかPreference保存という辺り。
  アプリを終了してもダイアル状態はできれば保持したい。
  Unityに機能があるか？Activityを介する必要があるか（AndroidOSのAPI利用か）、要確認。
  ※これができないとセレクタ機能の存在価値がなくなるので割り切りにくい。
  →PlayerPrefであっさり解決（2/5）。

■その他

アプリ起動時のスプラッシュ画面カスタマイズはPro版のみ可。
Unity文字は消せない。
IOSはXcode併用(?)で強引に回避してる例あり。

#10.実機チューニング

キーのOFFイベントがタイミングにより稀にこないことを発見。
ちょっと挙動観察と再実装思案で時間を食った（この手の挙動は処理系によっては良くある



ダイアル、キー入力等がおおむね実装完了（当のバイオリズム描画はまだｗ）。

とりあえず調整後は、現在こんな感じ。動画にしてみた。

パフォーマンステスト


で、本題。
調整前は実機（Kindle Fire HD 8.9）で動作させると定常状態で fpsが14に！？
ダイアルのみの時は60fpsでていたので劇的に落ちている。


ということで原因調査とfpsを改善する方法を検討。

■ライト

 現在シーンにライトは１つしかないが、ライトに関する影響がかなり大きい。
※コードの実行負荷はライト負荷に比べると現状誤差レベルぽい。 結構クラス化してガンガン動かしてるがおもったよりコードの負荷は軽そうなのが意外。

【対象オブジェクトの面積が増えた】

ライト設定はPointライト。
ダイアルのみの場合に対して、現在は本体ケース全体にもライトが当たる。どうやらこれがfpsに影響している。つまり光源処理が重い。

全オブジェクトの Cast Shadows, Receive Shadowsをオフすると１～２fps程度軽減されるがあまり効果はない。
とはいえ、オブジェクト面積は減らしようもない。
※Unityの場合光源は何か当てないと真っ黒になってしまう様子。完全にオフにはできないのかも？

【ライトの種類】

Unityの公式マニュアルにも明記があった。Point、Spotライトが高負荷らしい。最も軽いのはDirectionalライト。
実機実測で以下の通り。

Spotライト： 14fps（コレだった
Pointライト：18fps
Directionalライト：42～45fps

と、いうことでDirectionalライトに変更。
ダイアルだけのときはSpotライトで60fpsでていたので、増えたオブジェクトの光源処理で劇的に落ちたと思われる。

【Light Probes（ライトプローブ）】

Pro版のみ対応なので試せない(´Д⊂。しかしこれはかなり強力そう。

Unity上の光源シーンからテクスチャにベイクするとのこと。
環境光的な光源は10や20個置いてもこれでベイクしてテクスチャにしてしまうという機能。

【カリング】

私的にはクリッピング(?)とつい思ってしまうが、見えない部分のレンダリングをしない設定。
これもPro版のみなので試せない。
※しかし今回の当方のモデリング状況では効果は薄そう。

■DrawCall

説明はネットのあちこちにあるので割愛。

Statでみたところ現在DrawCall数48。スマホ用途も考慮すると40程度に抑えるくらいが良いらしい。

見た目のモデルのわりに48はちょっと多すぎか？

■総頂点数確認

Blender上でモデリングの総頂点数を確認 ->19824頂点。なんか多いｗ。

原因は数字ダイアル。
そもそもただのシリンダなので１つで20頂点しかない。はずだが、ちょっと形状に曲面を持たせる為ModifierでSubsurf、SimpleDeformで962頂点に膨れ上がってる（※ええ、制作上の手抜きですｗ）。

ダイアル年ｘ４、月ｘ２、日ｘ２で８個ｘ上下２パーツで１６個。
９６２ｘ１６＝１５３９２頂点。

つまり全体の7割以上を占めている。ここを詰めれば多分もっと軽くできる。
が、とりあえずDrawCallも40台でfpsも30以上でているので、このまま放置でいきます（ぁ。
※テクスチャに陰影を書き込んでいるので、20頂点のシリンダでも大丈夫そうですけどね・・・まぁ負荷テストにもなるので。C#のコード実装を優先で|-`)

■なんとなくまとめ

まじめにゲーム製作で動くユニットが多くなると多分2万頂点でも多いかも？ということがなんとなく予想できる。ここらを指標にモデリングしていくと調整しやすいかもしれない。
やはり陰影のテクスチャベイクはUnityでも有効手段。必須かもしれない。法線マップはきつそうかな？。
そしてやっぱりモデルの頂点数を減らすのは王道ですね・・・。

３D fpsゲーム等で光源効果を使う演出（Spotライト等）は効果範囲をかなり限定的に（対象オブジェクト、レイヤ）うまく使わないと簡単に重くなりそうである。

Unity Pro版の機能がすごい良さそうですねぇ。ガチで３Dゲームだとすごく欲しくなりそう。
静的バッチングとか使いたくなりそうな機能がことごとくPro版のみになっている（アタリマエか


ちなみにお値段は、
Unity Pro本体：157500円
Android Pro：157500円

計 315000円。


ガチすぎます。仕事でこないとちょっと手だしにくいですねこれは；（苦笑

#09.モデリング進行中

本体のモデリング進行中。

結局色調は全く変わりましたｗ。

光源は当ててますが、シャドウ以外は結果的に全く利いていない。と、いうか利いてくれないｗ。
光沢、影も基本的にフョトショ、2Dエフェクタツールでテクスチャに描き込みです。

BlenderでBakeを使ったのはシャドウのみ。これも本体上にのっているオブジェクトの位置をフォトショ上で知るためだけにテンポラリ的に出力。
シャドウBakeの結果からオブジェクトの位置を推察して、実際の影はフョトショで描き込む。

ちなみに中央の金色枠は一応別オブジェクトで作ってますが、その下の本体にも実は描き込んであります。なので枠が無くても実はUnityで真上から見れば同じように見える。

（BlenderでプロジェクションUV生成すると区別が付かない位同じにできる）

 あえて枠オブジェクトを残すのはUnityならでは(?)の表現手法として、実行時に動的にカメラビューを動かすことを当初から考えています。

西暦入力時はダイアル部へ動的にズームアップとかできるはずなんですよ。
なんせ３Ｄですからヽ(´ー｀)ノ

これを目論んでいたのでボタン類も多少小さくてもデザイン重視で描いていた（にしても、小さすぎたけど！）

このGUIで７インチ以下の端末でもあまり操作性が酷いことにはなりにくい？という作戦です。

で、ＸＹＺ角度変化無しでもいいんですがＵｎｉｔｙのカメラビューは遠近投影もできるので。
そうなると３Ｄなモデルの存在が生きてくる！

ちょっとそれもそのうち試してみたい感じです。
（単にtweenの移動パス?をちょっと使ってみたいだけともｗ）



あとは、中央のブラウン管(?)部分のモデリングと、バイオリズムのサイン波形をどう表現するか。

今月中にアマゾンのストアにリリースしたいなぁ～。間に合うんだろうか・・・。

#08.実機で動かす～Kindle Fire HD8.9でパフォーマンスチェック

まだダイアルしかできていないが、一度実機で動かしてみることにする。
（実機ならではの問題は必ずあるので）


ターゲットデバイスは Kindle Fire HD8.9。2012モデルだがそれなりに高性能な方はなず。
（むしろ本当はやや非力な７インチ位のデバイスの方が評価には良いのだが・・・）



当初EclipseでAndroidアプリ開発をするつもりでいたのでADB等は設定済み。UnityとKindleとの接続はUSBケーブルをつなぎUnity側のターゲットをAndroidにすればあっさりKindleで動く。

※一応アマゾン公式サイトにはデベロッパー向けの情報があります。
意外と親切(?)に書かれている感じですが、まぁ・・・英語です；一応主要部分は和訳してhtmlにまとめ済み。さすがにBlogには上げられないのでいずれ別なHPにでもアップするかも・・・。
ちなみにアマゾン独自のゲーム内通貨とかあるんですよ、知ってました？＜私的にビックリしたｗ
勿論その辺の開発者向けの諸々情報も。
課金システムはあれやこれや整ってる感じで、さすがアマゾンです！

【UnityでKindleへBuild&RUN】

1. ビルドターゲットをAndroidに変更する
   CTRL+SHIFT+Bを押して Build Settings を開く。
   Platform欄でAndroidをクリックして選択状態にする。
   Switch Platformを押して変更を確定する。
2. Bundle identifierの設定。
   続いて同じ画面から、Player Settingsを 押す。
   メインウィンドウの Inspector欄にAndroid向けの設定が出る。
   ※メインウィンドウ側に表示がでるので気付きにくいので注意。
   Bundle Identifier欄を変更する。
   
   　　例： com.unity3d.hoge
   
   これを変更しないとビルドが通らない。デフォルト以外ならなんでも良さそうな気配。
3. Kindle側の準備確認
   念の為以下の設定確認しておく。
   画面上部をスワイプして「設定」を出す。
   その中の「セキュリティ」に進む。
   「ADBを有効にする」がオンになっていることを確認。
4. Build＆RUN
   ビルドする前に Kindle をUSBでPCにつなぎ電源をオンしておく。
   Unity上でCTRL+Bを押す。
   ビルド、Kindleへの転送が行われて、Kindleで開発中のアプリが自動起動する。

【タッチの反応がおかしい】

６つ配置したボタンのうち、右上/右下（日）のボタンだけ反応が渋い。
年月はそれなりに反応が良い。なぜだ？

その１：そもそもボタンが小さいのでデバッグしにくいぞ

なんとなく気づいてはいた・・・実機で指で押すにはボタンのサイズが小さすぎたｗ。
が、デザインはもういじりたくない＜先に進まなくなるのでｗ。

ということでモデルの下の方に「板」を6枚置いた＝６ボタン。これをRayCastで捕らえるようにする。
上部の丸いボタンは「飾り」とする。
こんなんでも人ってのは違和感ないもんです。

当初スワイプ＝板上をスライドも考慮していたので、これでいいやと設置。
タッチ面積が大きくなった分操作性が向上。

ちなみにMesh Coliderを6枚の板のみにしか設定しない為、ほかのオブジェクトはRayCastの対象から除外される。なのでこういう配置でも大丈夫。
（一応ボタン判定順などのコード処理も確認）

その２：負荷を微減らしてみた（ほとんど気のせいレベル

多分ほぼ関係ないとは思うが、Cast Shadow, Receive Shadowをオフにしておいた。
気がついたのでまぁ設定。

その３：掃除＆ケース（ぇｗ ＞解決

タッチパネルを掃除したら症状が少し改善（マテｗ ＜どんだけ汚れていたのかと
実は掃除も効果は少しあったが、キャリングケースのフチ部分が悪さをしていたようでこっちが本命。少しズレていてタッチ面の隅に干渉していたようだ。

これに気づくにあたり、Unity上でダイアルパーツを180度平面回転＝逆さまにしてBuild&Run、Kindleで動作させたところ不調のボタンに変化があった。つまりKindleの特定の物理面のみが不調ぽいことをこれで確認。

改善策４：パフォーマンスチェック！

やっと本題ｗ
FPSとかチェックしたいな～と、思ったらありました。

http://wiki.unity3d.com/index.php/AllocationStats


ここのC#ソースをコピペして空のGameObjectにでも放り込んでRunすると、FPSやらメモリアロケート状況が画面上部に表示される。勿論Kindle上でも見れる。

Kindle FireHD8.9では定常状態で60fps。ボタンを連打しまくりで、59fps以上。ほとんど影響が無い。
しかし1fpsとはいえ下がったのが地味に気になる。（PCでは常時60fpsに張り付く）
極論、このダイアルを60個同時に動かしたら1Fps？とも言えなくも無い。

昨今のタブレットデバイスは高性能とはいえ油断するとすぐ重くなるかも。

#07.サウンド再生

サウンド再生ができた。

ボタンを押すとダイアルが回り、サウンド音を再生するところまで実装。
動画をアップしました。

ダイアルテスト動画


設計の仕方をかいつまむと、各種サウンド音色の再生を１つのクラスに集めて実装する感じ。

Unityのサウンド再生の手順は、、
　　AudioClipクラスにWavファイル名を紐つける。
　　AudioSourceクラスで再生チャンネルを用意する。このクラスには音量、Loop等設定可能。
　　AudioSourceクラスのclipにWavファイル（AudioClip）を紐付ける。
　　AudioSourceクラスのplayで再生。

注意点は AudioSource１つで単音＝１つのWav再生になる。よって多重発生させたい場合は、AudioSourceでチャンネル（インスタンス）をその数だけ用意してWavファイル（AudioClip）を紐付ける。

今回スクリプト起動時に AudioSourceクラスをインスタンス化してロードしているが、その際にそもそもAudioClipのインスタンスにWavファイルのロードでnullが返されて少しハマった。
つまり目的のWavファイルがAssets内で見つからない。

ロードに用いる関数は Resources.Load() なのだが、これがなんと、

　　Assets/Resources

配下にターゲットのリソース(Wavファイル)が置いてある前提ぽい。 Assets直下とか、Assets/SoundとかだとNG。必ずAssets/Resources配下に「置け」ということらしい。なんという決め打ちな・・・ｗ。
しかも Assets/Resources は最初は存在しない。「自分で作れ」である。

なので、Assets/Resources/Sound とかはできる。

まさかフォルダ名固定とは予想外だった・・・。


ということで、これも SoundManegerクラスにしてとりあえずボタンを押すと音が出るところまで完了。

#06.ユリウス暦 ～ UnityのJavascript

ユリウス通日関連クラスの実装が概ね完了。 
結論からいうと、C#でゼロから書き直しますた。

（ユリウス通日とは？等はWki等にあるので割愛）

今回は、
　　ユリウス通日(JD/AJD)
　　ユリウス通日(CJD) ※現代ではこれが最も扱いやすそうではある
　　修正ユリウス通日(MJD)
　　グレゴリオ暦(西暦 YYMMDD hhmmss形式)　　
の相互変換ができるようにした。



昔書いたユリウス変換関連のActionScript3.0（以降AS3）のソースは発掘はしたが、ネットでもっと効率的な変換方法を見つけてしまい結局書き直した。
（昔のソースは妙にまじめに演算しすぎていた。）

また、やはり(?)というか、UnityのJavaScriptの記述構文もAS3とは若干異なる様相で意外と書き直しが多そうだったのも要因となった。





以下、ちょっとメモ。


【UnityのJavaScript】
従来のJavaScriptともちょっと違う「似た」ものと考えておいたほうが良さそう（Javaとも違う）。
JavaScriptはNetscapeOne（古）の頃にちょっと使っていたが、もはや「JavaScript」といいつつも各処理系で微妙な差異が多いようでなんともいえない様相な気もする。多分「JavaScriptのようなモノ」という緩い認識が妥当かも？。


【気づいた点】：AS3 → Unity JavaScript移植

Package{ ～ } の記載が不要な様子。むしろあるとエラーになる。そもそもこれはJava由来(?)

public class JuliusTime extends MonoBehaviour {　～ } 等の宣言がデフォルトで省略されており、いきなり functionの記述ができる。このclass宣言文は書いてもエラーにはならず通る。

public function func( year:Number = 2014){ ～ } 等といった引数デフォルト値の記述がエラーになる。AS3のオーバロードはC++より緩い(?)のでこういう芸当ができるが、これもUnityでははじかれた。※そもそもC++ならコンストラクタ等でできるが、AS3もC#もコンストラクタが基本的に無い処理系なので。

Math.floor関数がMathf.Floor関数になっている等、ライブラリ群に微妙に違いがある。

var a:Number, b:Number, c:Number といったカンマ区切りの構文が通らない。ちょっと信じられないがコレすらもダメなのか？

var d:Vector.<Number> = new <Number>[31,28,31,30,31,30,31,31,30,31,30,31]; にてnewが使えない様子？
var d:Number[] = [31,28,31,30,31,30,31,31,30,31,30,31]; でも通らない。
　　→Numberを使うのがそもそも良くない？Number自体が結構緩い型宣言だった気がする。ただそれがAS3だと便利とも思っていたのに～。


ここらまで見てC#を使うことに決定。C#もC++とはいろいろ異なるが（ある意味不便？）、まだマシな感じ。

一応C#では.netのほにゃららなんとか(?)を継承してるとかどうとかで、DateTimeクラス等はMSDNの仕様説明と互換性がある感じ。

#05.西暦入力パーツを動かす

とりあえず西暦入力パーツを動かしてみた。


６つのボタンの上列が増加、下列が減少。年、月、日ごとにボタンがあり、１つづ加算/減算する操作。
（静止画なので、なにも変わり映えないないケドｗ）

ちょっとだけ凝ってみたのは、実際のダイアルの回転時は実時間を要するような動作もできるように実装してみた。

例えば、００００ ００ ００ から画面のような１９８４ ０６ ２８に進める時、普通は瞬間的に６つの数字は目的のダイアル数字位置に回転できる。

これを１目盛りずつ（３６０度÷１０＝３６度ずつ）回してゆき、目的の数字に到達して停止するという処理。サウンド効果とあわせればちょっとそれっぽい演出もできそうかも・・・と。


角度をもっと滑らかに動かすのも面白そうだし、停止時のギアのバッククラッシュのブレ等の挙動もやろうとしたが・・・あぶないあぶない；また横道にそれそうなのでこれくらいで；
※ダイアル的に車などのメータは上方向に０，１，２，３・・・と増加配置となっているが、今回は逆順に配置してる。

まぁ・・・あまり最初から凝ると先が続かないので。



それよりも西暦のインクリメント/デクリメントの動作ですね。つまり月末が３０か３１日か、インクリメントで次は１日にするとか。例えば2014/1/1からデクリメントすれば前年の2013/12/31とするような処理。
つまり指定年月の月日数をきちんと把握する必要がある。


この辺は以前ActionScript3にてバイオリズムを作る際に検討した結果、ユリウス暦を使うべしという結論に達した。
Unix timeは1970/1/1より昔は表現できないし、非常に長いスケールの時間空間を表すにはユリウス暦が比較的扱いやすそうであったので。
ということで、西暦入力パーツの最低限の動作は確保したので、西暦演算関係のクラスをActiveScriptのソースから掘り出さないと～。




ところで、 Unityもご他聞に洩れず、結構不安定。
例えば、

終了操作をしてもUnityが終わらない
　　→　手動でタスクを強制終了。
MonoDevelopエディタは特定のタイミングで漢字FEPをオンすると全ての文字入力不可に陥り復帰不能になる
　　→　メニューバーは生きてるので保存して終了、再起動で直る。
Assetがたまにおかしい。エラーになるはずがないスクリプトのエラーが消えない
　　→ 当該スクリプトをコピーして別ファイルに保存、当該スクリプトをAssetから削除し、再度新規で作り直してコピペすると直る。


等々挙動が怪しい動きは結構ある。この手のアプリでは「よくあるコト」なのでしょうがない。比較的マシな方かもしれない。

こまめな保存は重要かもですね。

リビジョンも管理しておいたほうが、何かの際に戻せるしね。

#04.C#実装検討～Unity故の特殊性調査

C#での実装の検討をしはじめました。以下にいろいろ雑感＆メモなど。


■C#での文字列定数
.net系(?)の継承が無いせいかネームスペースの問題なのか、UnityではReadonly等を用いた文字列の固定定数がうまくいかなかった。そもそも。これらはあまり好きではないので、以下の方法で華麗にかわしますっ。

public const string LABEL = "文字列定数";


とってもシンプルｗ。

Unity上ではヘッダファイルを作るメニューが見当たらないので、#defineにてヘッダをincludeするのもちょっとどうなのかな？とも思った。
プリプロはもはや過去の遺物なのかもしれない・・・。文字列がマッチングすると置換されるのでわかりにくいバグも埋め込むし。

※まじめな話enumやdefine定義を使いまわすにはヘッダファイルに記述すると楽なのだが、C#だとどうにも使いにくく、それ用にクラスを書くようなことにもなりかねない。そもそもこれらの手法は今日においてはオブジェクト指向的ではない・・・ということですかね。



■オブジェクトとスクリプト
Unityはオブジェクト内に複数のスクリプトを放り込める。
同オブジェクト内の別スクリプトへのアクセスならばそのメンバがpublicであればアクセスは簡単で、

ScriptName.MemberName

でアクセスできてしまう。これは従来のC++、C#と大差ない。

Unity故の特殊ケースは別のオブジェクトにあるスクリプトのメンバへのアクセス。
それにはまず、対象オブジェクトのインスタンスへのポインタ(というか某所風味で言うとUUIDか?)を取得する必要がある。
オブジェクトはすべて GameObject型となっているので、

GameObject ptr =  GameObject.Find("対象オブジェクト名");

にてインスタンスのポインタを取得する。ここでの GameObject.Findはインスタンス検索関数、対象オブジェクト名はHierarchy上に存在している名前。よって名前はユニークになるように自分で管理しておく方が良い。

 これで ptr には対象オブジェクトのインスタンスのポインタが格納されるが、まだ終わらない。
なぜならば、そのオブジェクト内のスクリプト～クラスが複数ある可能性があるので。

ClassName ptr2 =  ptr.GetComponent<ClassName>();

にて、そのオブジェクト内でインスタンス化されているクラス名を指定して、そのクラスのポインタを得る。と、いう二段構えで目的のクラスを絞り込む。これで、

ptr2.Func()
 
などと、目的クラスのpublicメンバへアクセスが可能になる。
ただしポインタの取得は検索を行う為非常に重いらしい。常時使用するとfpsがとんでもないことになるとのこと。
よって、Awake()かStart() で先んじてポインタだけ拾っておけば良い。


■Awake()やStart()
先の流れでAwake()がでてくるがこれも把握しておかないと危ない。コンストラクタのようではあるがそうでもない。Unityではコンストラクタの使用は推奨されていないらしい（そもそもC#がコンストラクタを基本的に扱わないし）。

【Awake()が呼ばれるタイミング】
オブジェクトがインスタンス化した時＝オブジェクト内のスクリプト（クラス）がインスタンス化完了時。
ただしこの時全てのインスタンス化されたクラスのAwake()が呼び出されている保証はないとのこと（マルチスレッドの初期化時みたいなものか？）。
よって、各クラスのAwake()内処理はまだ完了していない点に注意。つまりできることはインスタンスのポインタを拾うくらい。（か、ハード由来の処理か？ハードは常に実在しているので）

【Start()が呼ばれるタイミング】
初回のUpdate()がStart()である。と、説明されている。
よって全てのインスタンスのAwake()の呼び出し済みは保証される。
他のオブジェクトとの連携が絡まない初期化はココで良い感じ。絡む場合はAwake()を利用することも視野に入れる。



■オブジェクトに無関係なクラスはどうするか？
オブジェクトを制御するスクリプトはそのオブジェクトに放り込むわけだが、純粋に演算だけを行うクラス等はオブジェクトを特に必要とはしない。
が、Unityでは「器」はやっぱり必要なので適当に空のGameObjectを作ってしまいそこに放りこめば良さそうだ。



と、いうことで、別オブジェクト内の任意のスクリプト＞クラスへのアクセス方法もわかったので、なんとかなりそう。ネットの情報が多いのは助かりますね～。本家マニュアルも一部和訳されているし。

本当はAstahあたりで、きちんと設計過程を通しておきたいとこでもあるが、ま～ココは勢いでサクサク進む（進みたい）予定。

どうもUnityはコンポーネントという概念が導入されているのが良いらしい。コードの実装的にも余計な面倒さを感じさせないのが良い感じです。（MFCより全然わかりやすいっ！ ）




補足：
某SL向けな言い回しをすると、GameObjectはプリムと言える。もうそれだけで作れそうな気になったよね？ｗ
RayCast,Colission等も、まんまそっくりなので、製作概念～スキルはほぼそのままいけそうです。

#03.西暦入力パーツのモデリング

とりあえず西暦入力部分のパーツをモデリング。

ちょっと工業機器を設計しているような気分に。

BlenderがB-Mesh対応したし、Booleanモディファイアで全てこなそうとしたが甘かった。 やはり手動でモデリング。
テクスチャの質感がどうにもオモチャぽいように見えてしまう。ここらはまた調整するかもしれない。
（実はUnityでは真上からみせるのでその角度だともう少しマシなのだが・・・）


以下はBlender画面。 レンダリング無し。光源効果は全てフォトショ上にて２Ｄで行っている。
なんやかんやで1日消費してしまったトホホ。

Blender上で3DレンダリングによりテクスチャをBakeする手は別件では使っていたが、なにせ重いし光源調整が面倒。

あと、２Ｄで描いた方が人間の脳に効果的(?)な絵にしやすい感。
3DレンダリングはあまりにRLに忠実になりやすいのでメリハリがどうもだしにくいので（私の技量では；

だれも「日常」みたいなレンダリング結果は見たくないんですよっ、映画みたいな虚構だけどメリハリのある絵に人間の脳は「慣らされてきている」のでっ！
（と、逃げておく。いやBlenderでもそういうのできるんですけどね・・・そこまで到達デキテナイデス


これをUnityに持ち込んで、ボタンを押すとダイアルがぐるぐる回って西暦を入力するしくみ。
 これをクラス化して、誕生日、計算日と両方でコードを兼用する予定。絵テクス1枚差し替えでいけるので。

追記：以下はUnityに持ち込んだ画像。Blender上の複数ObjectをUnity内で手動配置、結局そうなるのか・・・うーん。

#02.機能検討

機能を簡単にまとめておく。

バイオリズムに他に機能なんかあるのか？と思うが馬鹿にはできない。
一応ユーザビリティも考慮すべきである（というか、一応は検討はした

でも、今回は画面デザイン優先でいくことにするので、いろいろ考えた便利そうなGUIはバッサリ捨てた（ユーザビリティはどこへいったｗ

Simple is the best!

が、最強ですよ。

・・・・


手抜きです・・・。まぁ、まじめにGUI実装しはじめると、またとんでもないことになりそうなので・・・。


機能としては、


バイオリズムが表示できる。

な、わけですが、もうちょっと詳細に以下まとめ。


■バイオリズムのグラフ表示
　　横軸は３０日程度にする。
　　計算日の横軸表示位置
　　　　デフォルト中心。スライダで左右移動できるようにする。
　　身体、感情、知性のグラフの表示を選択表示できる。色分けもする。

■誕生日/計算日を西暦で入力
　　上下ボタン式で数字をインクリメント/デクリメント式。長押しで加速対応。
　　※この操作はあまり使いやすくないかもしれないが今回はこれで我慢する。
　　※入力時はちょっとUnityならではの試したいGUI表現があったりする、いずれ書くかも。

■補助機能
　　誕生日の西暦はメモリできるようにする。メモリ数は５箇所とする。
　　メモリのクリアをできるようにする。（クリア用ボタンの配置などを検討）

■サウンド
　　各種操作においてそれっぽいサウンド音を鳴らす（音はフリー素材を元に合成、エフェクト
　　ボリューム調整をできるようにする。

ざっとこれくらいだろうか。

これでもまじめに作ると結構面倒そうでしょ？。

#01.デザイン検討

とりあえず、紙のノートに画面デザインをイメージ、イメージ、イメージ・・・これがいつも大変なわけですよ、ウン。

いくつかの案から今回はアナログオシロぽいような昔風味(?)な機械のデザインにしてみることに決定。


 ～余談～
最近ドクター・フーをHuluで観てる。SFだけどあまり近未来的なサイバーではないテイストがイイかもしれない。
作中で主人公が作るガラクタぽいモノが実は超絶ハイテク機器だったり。でもどうみてもガラクタなのだが・・・それが微スチームパンク風味かも？みたいなでなかなか良い。ストーリーもかなり奥が深いことをテーマにしてる回もあったり
やるなBBC・・・、さすがサンダーバードの国！

などど、いろいろデザインを思案しつつネットを見ていると、すごいサイトを発見した。

スチームパンク大百科S

尊敬できるレベルのサイト。すごいです。イギリス人なら「Incredible!」とでもいう感じだろうか。

モノを作るには、そのモノのしくみ、生まれた背景、なぜそうなっているのか？、等々の「歴史」をまず知る必要がある・・・という点をいつも気に留めているのですが、まさにココのサイトの製作物はソレです。

しかもトコトン突き進んでる感が素晴らしい！




と、いうことで、私的センスでは到底すごいデザインはできないわけですが、モチベは上がって参りました（アリガトウ！

ということで、全体デザインの手書き絵完了～

あ、一応折角Unityなので３Ｄでいきますよっ。

#00.Unityで何かつくる

2014年もあけましておめでとうなわけですが（今頃

今年はUnityで何か作ってみることに決めた！決めたんですよ！決めたことにしておきたい・・・！

で、何を作るか？


年末は３Ｄシューティングゲームぽいものを作ろうかと地形からいじってたら、いつできるかわからない様相な予感がしたわけですよ（イツモノコト。

戦闘機は一応オリジナルのブツが既にあるのですが（某インワールドでほぼ完成してるのに未発売な奴）凝りだすともうキリがないヽ(｀Д´)ﾉ （コレマタ、イツモノコト


まずの目的はUnityを使って何かを作るまでの一連の作業をやってみることにあるわけで、もっと簡単なものにしないとですよ。

と、いうことで題材はバイオリズムに決定（イツモノコトｗｗ

昔ActionScript3で作ったコードがあるので、演算コアはこいつを使えば楽ができる。
けど、Javaはあんまり好きじゃないので、多分C#で書くかもしれない（楽できないじゃないか！？

一応３Ｄで行くので、各部パーツはBlenderで３Ｄでモデリングする。

と、いうことで私的経過メモ、というか進行状態を自分で見直す目的も兼ねて書いていこうと思う。