AndroidでビルドはもういいRunしたいってとき
このポストは
Unity 2 Advent Calendar 2015 - Qiita
の７日目の記事です。
UnityでAndroidアプリ開発をしていて、apkをビルドはしないで、インストール＆実行だけしたいときの解決っという小ネタです。
UnityのメニューやBuild settingsから行えるのは
Build -> apkの作成
Build & Run -> apkの作成、デバイスへのインストール、実行
の２つ。
すでに一度apkを作成しており、デバイスにインストール＆実行したいっていう場合には対応したメニューはありません。
そういった場合にUnity上だけの作業でどうにかしようとするのであれば、
もう一度Build& Runを実行する。
でも、これだともう一回ビルドしてapkを作成してしまうので、
その分、ビルドをする分時間がもったいないです。
まあ、そもそも、
この欲求を感じるケースが、
そんなに良くあるケースかというと、
どうだろうという話でもあるのではありますが、
同じビルドを配布したいようなケースではUnity Cloud buildを使えばいいし。
どういう場合にあるかというと、例えば、
オンライン要素のあるゲームで、
ローカル作業の変更をビルドして２つのデバイスにインストールして確認したい、とか。
まあ、たまにあったり、
ゲームのある部分の開発をしているときだけ良くあったりする、という感じでしょうか。
自分では、最近しばしば、どうにかしたいときがあったので、
対処を考えてみました。
解決方法として、
apkはandroidSdkに含まれるadbコマンドでインストールや起動ができるので、
それらを行うエディタ拡張をメニューに追加してやります。
外部プロセスの実行はProcessを使用して行います。
これを使ってadbコマンドを呼び出します。
最初にEditorUtility.OpenFilePanel()を使って、apkを選択します。
そのあと最初のプロセスでデバイスへのインストール(adb install)を行います。
WaitForExit()で終了をまち、その次にActivityを指定して起動を行うプロセスを実行します。
Windowsではアプリの起動までできることを確認しています。
Macでも一応試したのですが、僕の環境では起動には失敗しているみたいで、
ちょっと問題がある？かもしれません。インストールはできていますが、
完璧でなくて申し訳ないです。
Unity cloud buildのFailedメールをデスクトップ通知
Unity cloud build のビルド結果はメールで送られてくるが、
Failedの場合のメールも簡潔なので、
もう少し注意を引くようにしたい。
チーム開発している場合、
メインリポジトリのビルドの失敗はすぐ修正しなくてはいけない最優先事項。
コードの問題にはもちろん各人注意するとして、
コミット漏れなどで
たまにビルドに失敗するということはしばしばある。
以前の職場ではCIにはJenkinsを使っていたが、
ビルドステータスをCCTrayで表示しておくようにしていた。
Download Files List - CruiseControl.NET - OSDN
独自のchrome拡張で表示するようにしたかったが、
gmail関係の処理の扱いが分からなかったので、
既存の拡張機能を使ってデスクトップ通知を表示するようにする。
使ったchrome拡張は
まず、Unity Cloud Build からのメールでかつ、Faildがsubjectに入る場合に特定のラベルに仕分けをするようにgmailで設定。
from:(cloudbuild@unity3d.com) subject:Failed
というフィルタになる。
Checker plus for gmailは特定のラベルだけを通知するようにできるので、
オプションで、新しく追加したラベルだけ通知するように
オプションのAccounts/Labelsで受信トレイのチェックを外し、
新しいラベルだけにチェックを入れる。
通知が消えてしまうのは困るので、
オプションの「通知」、「テキスト通知ウィンドウ」を「後に閉じる」を「決してしない」に変更。
ひとまず以上でデスクトップ通知が行われるようになる。
もとからChecker plus for gmailを使っている場合は少々困るかもでけど、
gmail標準のデスクトップ通知とは共存できることを確認した。
本当は、chrome拡張を用意して、ユニティちゃんの絵で通知を表示するようにしたかった。
誰かこのあたりに精通している人が作ってくれないものだろうか。
PERACON2015 出したので振り返り
振り返りブログをポストするまでがペラコン。みたいな投稿。
今週CEDECが開催されていて、自分は忙しく・・はなかったんだけど、転職したばかりで有給もなく、
会社としても参加パスを用意していたりしていなかったので不参加。
もうちょっと入社が早かったら手回ししていたかも。
だけど、例年によってペラコンが開催されるようだったので、
去年に続いてペラを出してみた。
今年からオープン化ってことらしかったのだけど、
オープン化が具体的になにっていうのがサイトを見ても分からず。
なのでエキスポパスを事前購入期限のうちに購入しておいた。
ペラコンは最終日のセッションで順位が発表されるのだけど、今年はライブ中継が無かったので、すぐには結果が分からず。
遠藤さんが暫定順位発表をしたので本日順位を知った。
PERACON2015 暫定順位表｜遠藤雅伸公式blog「ゲームの神様」
提出ペラとその結果は・・
第１０５位！
う、うおー・・低い・・
ちなみにweb投票時点では６５位？かな。
これも高くは、ないんけど、
まあ審査員による審査だと、より順位が低いというのは、
なおのこと良くないですねー。
逆にweb投票で低い順位で、実際の審査であがるというケースなら、
しっかり審査する目のある人の審査で評価されるというわけで良かったんだけどなぁ。
これはしんどい。
しんどいけど、まーいいんです（よくないけど。ほんとよくないけど）
私がペラコンに投稿する目的はいくつかあって
- 普段やらない企画書つくりをして刺激をうける
- 資料つくりの経験値あげ
- 普段やらない絵素材つくり経験
- GDの気持ちを理解する手掛かりになればよい
- 提出物を評価されるせっかくの機会
- 自分の今のポジションに安心したり、偉ぶったりしないように
などなど。
要は、ペラを作成する過程で得られるものも多いし、
ケチョンケチョンな結果だとしても、それはそれで気持ちのいいものなのである。
今年のペラは去年の審査コメントを参考にして、意識して書いた部分が多い。
といっても１２４位→１０５位だから、まあまだまだだけれども。
今年の審査コメントを早くみたいな。
昨年の反省から意識したところは
- 書くないようを絞る
- PC上で用意した絵があんまりだったので、今年は手書きキャプチャして色付け（でも、まあそんなだけど）
今年も反省を生かして、来年もまたチャレンジしたいな。
現時点での反省としては、
この２回ではmiddle-termからlong-termのゲーム性に重きを置いた内容になったけど、
受けって意味ではshort-termのゲーム性や、アクションでの面白さっていうのは入れておくほうが良いのかなとは思う。
というかそういうものを思いつけないのが良くないのか。
それは個人の志向なのか。
こういう図でいうと、1hとか10hとか、そのlong-termの遊びに耐えるものでないと、
ちょっと不安っていうのはある。
ただ、やっぱり触ったときに面白そうとかいう感覚は入れておいたほうが良いのかな。
上位にはそういうものが多いように思う。
と思って３０位までのペラを見直してみたが、
全てではないけど、ほぼちゃんと操作とかアクションの提案をしてる。
こうして見返してみてみると、
自分のは確かに内容が無いようにも感じるなー。
面白い。
※順位悪かったので言い訳っぽさが滲み出ていたら申し訳ない。
言い訳っぽくなりたくなかったから、高い順位取りたかったのにー。
AoS/SoA
Array of structures(AOS)
Structure of Arrays(SOA)
先日、Android Developer blog にデータ指向プログラミングという記事が掲載され、その翻訳記事もポストされていた。
データ構造により演算時間の計測結果の差とアーキテクチャの説明に触れてて分かりやすい記事だと思う。
思う、のだけど、ちょっと片手落ちというか、
これだけ読んで、SOAが正義と思われるとそれは困るものであり、
オブジェクト指向プログラミングとの折衷について触れてくれないと片手落ちという気がします。
効果的なケースにおいて、適切に用いるべきで、
更にはオブジェクトとして使うような場合にも混乱が無いようにしておくのも大事。
もし、この記事を受けて、全ての個別要素を配列で持つように設計してしまい、
議論の際に、盲目的に「こっちのほうが高速なので」という主張をされることがあっては辛い。
少し検索してみると、こういう記事も出てきており、
折衷案についても触れられている。
最初のブログもサンプルに書かれているのは物理のコンポーネントであるので、
内部では配列で保持しているケースだけど、
おそらく更にそれを使用しているオブジェクト側は、
そのコンポーネントの参照を保持するなど、
AoSな作りになるってことを想定しているのではないかな。
おはじきゲーム
子供が親の職業を把握していて、 なんかゲーム作ってよ、みたいなことを気軽に言ってくれることもあり、 日曜の午後は一緒に作ろう的な感じでUnityいじってた。
インゲームの遊びとしては、オハジキゲームというか、 スリングショットというとちょっと違うのかな？ まあ、モンストみたいな感じ。 コインみたいのを、引っ張って離すと、 飛んで行って、他のオブジェクトを弾いたりするっていう。
公開する予定もないものなので、デザインは躊躇なく拝借。 ここらへん気軽なところ。 子供のために作るゲームって色々気軽で良いっていう気づき。 公開しないでいいので、マネタイズなんて考えないでいいし、 ゲームデザインを拝借してもいいし、 粗があってもいいし、 子供なので喜びのハードルが高くない。 子供駆動開発。
以下、ざっくりやったことのメモ。
プロジェクト生成
2Dで作成。
自キャラのコイン
- 円形の画像を作りSpriteに。今回は子供の写真を使ってやった。
- Circle Coolider2D設定
- Rigidbody2Dを設定。gravityは必要ないのでgravity Scaleを0
- Collision DetectionはContinuous。コリジョン抜け防止。
BG
- 背景画像をSpriteで配置
壁
- Cubeを作成
- BoxCollider2Dを追加
- Physics2DMaterialを作成し、Bouncinessを0.8に。Colliderに設定。
- 複製し、transformを調整して四方に配置。
入力操作
public class Coin : MonoBehaviour {
[SerializeField]
float m_speedScale = 800.0f;
Vector3 m_dragBeginPos;
Vector3 m_dragEndPos;
void Update () {
if( Input.GetMouseButtonDown(0) )
{
m_dragBeginPos = Camera.main.ScreenToWorldPoint(Input.mousePosition);
}
if( Input.GetMouseButtonUp(0) )
{
m_dragEndPos = Camera.main.ScreenToWorldPoint(Input.mousePosition);
var d = m_dragBeginPos - m_dragEndPos;
GetComponent<Rigidbody2D>().AddForce(d * m_speedScale);
}
結局、自キャラの操作までだけど、 結構受けがいい感じ。 もうちょっとオブジェクトとか足してみるかも。
Behavior Designerでユニティちゃんを動かしてみる
先日Behavior Designerを試してみた続き。
Behavior Designerを試してみる - kurihara-nの日記
SDユニティちゃんをインポートして、
シーンに配置、そのオブジェクトに対してBehavior treeを作っていく。
基本的には前回と同じく、Can see object になったらそのターゲットオブジェクトを追跡するというもの。
ただ、追跡中にアニメーションが走りモーションになるように
Play(Animator)タスクをSeekとparalelに配置しています。
見る場合はChrome以外のブラウザで見てください。
https://dl.dropboxusercontent.com/u/91649958/Unity/BehaviorDesignerUnityChan/WebPlayer.html
ユニティちゃんのアセットについていたOnGUIの処理をコメントアウトする以外は
コーディングを全くしないでここまで作れています。
