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の処理をコメントアウトする以外は
コーディングを全くしないでここまで作れています。
Behavior Designerを試してみる
Unityにおけるビヘイビアツリー作成アセット、Behaviour Designer.
Opsive.com :: Behavior Designer
https://www.assetstore.unity3d.com/jp/#!/content/15277
$75ドルで購入可能。
Overviewで説明しているActionはMovement packに含まれています。
https://www.assetstore.unity3d.com/jp/#!/content/16853
これは別途$10のアセットなのですが、
The Movement Pack is free for new Behavior Designer purchases - just send us your Behavior Designer invoice number.
とあり、Behavior Desinerを購入してすぐにコンタクトとると無料で手に入るみたいです。(2015/07/23現在）
僕はぼんやりしていて間があいたので別途購入しました。
こちらのOverviewを見たり、
ドキュメントを読んだりしつつ簡単なツリーを作ってみました。
Videoだと省略されている前準備として、使っているSeek actionはNavMeshを使うので、
NavMeshがBakeされた地形と、
seekerとなるオブジェクトにNavigation agentがアタッチされている必要があります。
こんな感じでシーンを用意しました。
赤いキューブがターゲットとなるオブジェクトで、
アニメーションをつけて左右に反復移動をしています。
緑のキューブが追跡する側のオブジェクトとなり、
このオブジェクトにbehavior treeを持たせます。
緑のオブジェクトを選択した状態で、
[Tools] > [Behavior Designer] > [Editor] でエディタが開きます。
これは完成した状態のツリーです。
完全なエディタで編集が出来るので素晴らしいです。
基本的にはOverviewで作っているものと同じものです。
このツリーでは末端のアクション以外の制御ノードとしての
Compositesが２つあり、
それがSelectorとSequenceです。
SelectorはORとして動作するもので、子のノードいずれかがtrueの場合そちらを実行します。
Sequence はANDとして動作するもので、
子のノードをTrueのうちは順番に実行します。
優先度は左側が高くなります。
このツリーは、ターゲットが一度視界に入ったら、そのあとはそのターゲットを追跡(seek)し、
ターゲットが視界に入るまえは右側のseek（指定のポジションまでの移動）を行う、という動作をします。
CompositesはAbort typeがあり、none, low priority, self, bothがあります。
ここが少し分かりにくかったのですが、
http://www.opsive.com/assets/BehaviorDesigner/documentation.php?id=89
こちらに詳しく書いてあります。
通常は最適化のために他のノードが実行中であれば、なにもしないようになっているので、
この例のツリーでSequenceのabort typeをnoneのままにしていると、
初期状態でターゲットが視界に入っていないと
Falseを返し、そのまま右側のSeekのみ、その後は実行されることになります。
なのでSequenceのabort typeはlow priorityを指定します。
これは、そのノードが一度FalseになってもTrueになる条件が成立すれば、よりlow priorityのものを中止し、
自分の実行を行うようになります。
Selfは自分の子を実行中でもFalseとなる条件では自身の実行を中止するようになります。
Both は low priorityとselfの両方となります。
実行すると、最初は緑のキューブが奥方向に進み、
赤のキューブが視界に入った時点で、そのキューブの追跡をするようになります。
Sequenceのabort typeをbothにすると、
ターゲットの追跡をしているときに、再度視界の範囲からターゲットが抜けると、
追跡をやめて、
指定位置への移動へ戻るという挙動をするようになります。
Behavior designerはかなり優れたアセットなので、
もっと使ってみたいと思います。
