Constant Force コンポーネント
Constant Force コンポーネントについて。
子供と作ってるゲームのために武器のアセットを買ってみたのですが、
デモの挙動を見ていると、
Constant Forceという慣れないコンポーネントがついていました。
Rigidbodyに一定の力を与えるためのコンポーネントのようです。
ドキュメントによるとforce/relative force, torgue/relative torqueというパラメータがあります。
relativeはオブジェクトのローカル座標系におけるベクトルで、
そうでないほうはワールドで処理されます。
ミサイルのように前に前にと飛んでいくオブジェクトはrelative forceを設定します。
また、例えば外からの力で飛ばされるような場合はワールドのほうを使うと良いのかと思います。
どうも検索すると3,4年前の動画も出てくるので、
ずっと前から存在していたコンポーネントのようです。
でも知らなかった…か、忘れてたか…。
覚えておくと手早く使えて便利そうです。
飛んでく弾がConstant Forceによるものです。
着弾時にStandard assetsのparticle demoで使われているexplosionを生成すると
rigidbodyを持つオブジェクトが飛ばせて良い感じ:)
この作品はユニティちゃんライセンス条項の元に提供されています
Unity アプリのバージョンを知る
スマートフォンアプリを開発していて、複数のデバイスを使っていたりすると、
「あれ、このデバイスに入っているこのアプリはいつのバージョンのもの？」
みたいなことに立ち会うことがたまにあります。
開発用のビルドでは、そのアプリがいつのアプリなのか分かると助かります。
そのためバージョンナンバーをアプリアイコンにオーバーレイで書き込むアセットを作って
ストアに公開しました。
AppVersionIcon
https://www.assetstore.unity3d.com/jp/#!/content/65849
こんな感じのエディタウィンドウでバージョン番号を設定してapplyすると
アプリのアイコンにナンバーが書かれます。
こんな感じ。
これは割とマイルストーンごとに手動で使ってもらうことを想定しているので、
自動でビルド毎にナンバーが書かれるようなものにはなっていません。
もう１つのやり方として、
自身のアセンブリからバージョン情報を取得し実行中にどこかで表示するという方法があります。
using UnityEngine;
using System.Collections;
using System.Reflection;
using System;
[assembly: AssemblyVersion("1.0.*")]
public class BuildDate : MonoBehaviour
{
string dateText;
GUIStyle style = new GUIStyle();
Rect rect = new Rect(0, 0, 640, 30);
const int defaultFontSize = 12;
void Start()
{
var asm = System.Reflection.Assembly.GetExecutingAssembly();
var version = asm.GetName().Version;
int days = version.Build;
int seconds = version.Revision * 2;
DateTime baseDate = new DateTime(2000, 1, 1);
DateTime buildDate = baseDate.AddDays(days);
DateTime buildDateTime = buildDate.AddSeconds(seconds);
dateText = "Build date :" + buildDateTime.ToString();
style.fontSize = (int)(defaultFontSize * Mathf.Max(1.0f, ((float)Screen.width / rect.width)));
}
void OnGUI()
{
GUI.Label(rect, dateText, style);
}
}
<||
こちらはスクリプトをコンポーネントとしてアプリのメイン画面に存在するオブジェクトなどに追加しておけば、
ビルド毎の時間を時間を表示してくれるので便利です。
アプリを起動する必要はありますが、自動にビルドごとに更新されていくので情報は確実です。
例えば、相互に通信するアプリを作っていた場合バージョン違いで送受信するデータに不整合が起こるようなことは
まま起こりえます。
Electronに入門してみる
WinでもMacでも使えるGUI環境を持つツールなどのために、
ゲーム開発でも、
Electronが使える、使われるようになっていくかもしれないので
とりあえず環境の導入を試みてみました。
Windows 7 環境でのインストールのメモ。
基本的にはコチラに書いてある通りに行いました。
ダウンロードしたNode.jsのインストーラは
https://nodejs.org/download/release/latest/
node-v5.7.0-x64.msi
electronのバージョンは
v0.36.8
でした。
package.jsに書かれているmainのjavascript名が
index.jsになっていたので、そのままindex.jsを作成しました。
あとはQiita記事にある通りに進めて
electron-packagerで実行ファイルが作れてしまいました。
超簡単でした。
問題はこの先進めるにあたり、僕がnode.jsに詳しくない、
それどころかJavaScript自体に馴染みが無いってことかな。
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の遊びに耐えるものでないと、
ちょっと不安っていうのはある。
ただ、やっぱり触ったときに面白そうとかいう感覚は入れておいたほうが良いのかな。
上位にはそういうものが多いように思う。
と思って３０位までのペラを見直してみたが、
全てではないけど、ほぼちゃんと操作とかアクションの提案をしてる。
こうして見返してみてみると、
自分のは確かに内容が無いようにも感じるなー。
面白い。
※順位悪かったので言い訳っぽさが滲み出ていたら申し訳ない。
言い訳っぽくなりたくなかったから、高い順位取りたかったのにー。
