テラシュールブログ

旧テラシュールウェアブログUnity記事。主にUnityのTipsやAR・VR、ニコニコ動画についてのメモを残します。

【Unity】Calling Animator.MatchTarget while in transition does not have any effect. という警告

f:id:tsubaki_t1:20170506000418g:plain

ちょっとハマったので一応メモ。
時間がないので簡単に。

ノードの遷移中にMatchTarget は使えない

Match Targetを使ってデモを作ってる最中、このエラーが出てきました。

Calling Animator.MatchTarget while in transition does not have any effect.

f:id:tsubaki_t1:20170506000517j:plain

書いてある通りで、MatchTargetはノードの遷移中には効果がないとの事です。

別にワーニングですし欲しい挙動は動いては居るので問題が無いといえば無いですが、ワーニングのパフォーマンスと精神衛生上消した方が良さそうなので、消します。

遷移中の処理をスキップする

面倒なので、animator.IsInTransition(layerIndex)でサクっと消します。

f:id:tsubaki_t1:20170506000821j:plain

関連

tsubakit1.hateblo.jp

【Unity】Unity 2017の新しいスプライトをパッキングする仕組み、”SpriteAtlas”について

f:id:tsubaki_t1:20170504233638j:plain

Unity 2017でSpritepackerの仕組みが新しくなったみたいです。

新しいパッキングの仕組み、SpriteAtlas

Unity 2017でSpriteをパッキングする仕組みが新しくなりました。

機能はSprite Atlasという名前で、ファイルベースで参照アセットを準備し、運用するタイプになるみたいです。

f:id:tsubaki_t1:20170505002218j:plain

パッキングの単位はフォルダ・テクスチャ・スプライト

以前のSpritePackerはテクスチャにPacking Tagを指定してパッキングする方法でした。

新しいパッキングのシステムでは、Object for packingの項目に登録したい項目を指定する事で、その項目をまとめてパッキングしてくれるみたいです。

パックできる単位は以下の項目。

  • フォルダ
  • テクスチャ(に含まれてるSprite)
  • Sprite単体

例えば下のアニメーションでは、2Dフォルダを指定することで、2Dフォルダ以下の全てのスプライトがパッキングされます。

f:id:tsubaki_t1:20170504233739g:plain

ちなみに、複数のSpriteAtlasから単一のSpriteを指定する事も出来ます。この場合、自動でSpriteをロードした場合、どのAtlasから参照されるのかは微妙です。

圧縮フォーマットはSpriteAtlasで一括指定

この機能では、圧縮する設定はAtlas単位で行います。
要するに、圧縮フォーマットが異なっていても再圧縮されます。

f:id:tsubaki_t1:20170504234257j:plain

SpritePackerはLegacy扱い

Legacyの項目を設定すると旧SpritePackerが使用されます。

Legacyではない項目を使用すると、Packing Tagはガン無視されます。

f:id:tsubaki_t1:20170505001109j:plain

パッキングしたAtlasの運用

以前はパッキングしても特に意識なく使用出来ましたが、SpriteAtlasは意識してコントロール出来るようになったみたいです。

Atlasはファイルとして見える

作成したAtlasはファイルとして確認出来ます。

このプレビューに見えている項目は1ページ目らしく、が必ずしも含まれる全てではない点に注意が必要かもしれません。

f:id:tsubaki_t1:20170504234703j:plain

アセットなので、Resourcesに配置して動的にロードも出来ます。但しSpriteAtlas=テクスチャという訳ではないので、そこんとこ注意が必要です。

AssetBundle等にAtlasを含める場合、コチラのほうが運用が楽そうです。

AtlasからSprite名を指定して直接Spriteを取得出来る

アセットとしてSpriteAtlasが指定出来る事は、SpriteAtlasからアセットを取り出せる事も意味します。例えば下のように、GetSpriteを指定すると、Atlasに含まれるスプライトが取得出来ます。

namespaceはUnityEngine.U2D。何だこの「U」は…unity…?

f:id:tsubaki_t1:20170504235042j:plain

Include in buildはAtlasを含めない設定

少し面白い挙動なのが、Include in buildです。

この項目のチェックを外すと、Atlasが参照しているSpriteが表示されなくなりました。

f:id:tsubaki_t1:20170505000730j:plain

これは「どのSpriteAtlasからも参照されない」場合で、どれか一つでも参照されていれば表示されるみたいです。Compress設定やプラットフォームで使わないスプライトがある場合等に便利かもしれません。

 

個人的には、SpriteAtlasから参照されないなら通常のSpriteから参照されるかなと思いましたが、そんなことは無かったという感じで(ベータなので変わるかもしれませんが)

感想

特に使い勝手が良さそうなのが、フォルダ・Sprite単位のAtlas化と、SpriteAtlasから直接Spriteを引っ張り出せる機能です。

それと、Spriteのテクスチャインポート設定を一括で設定出来るのは、悪くないような気がします。

関連

tsubakit1.hateblo.jp

【Unity】生成した瞬間は勢いがあるが、すぐにゆっくりになるパーティクル

f:id:tsubaki_t1:20170503202413g:plain

生成した瞬間は勢いがあるが、すぐに速度が落ちてゆっくりになるパーティクルについてです。

作り方をど忘れしたので、ココにメモしておきます。

パーティクルの速度は生成時に決まる

パーティクルの移動速度は、パーティクル毎にEmit時にStartSpeedで指定されていた値が使用されます。
例えば下の設定の場合、パーティクルが生成時に15~30の速度が設定され、その速度は消えるまで固定です。

正確には、そこからVelocity Over LifetimeやLimitVelocityOverLifetimeで減加速が入ります。

f:id:tsubaki_t1:20170503203730j:plain

あとNoise等で動きに変化が加えられたり、ColliderやGravity Modifilerで重力や物理っぽい挙動が加わったりしますが、速度で言えば大体Start Speedです。

速度をLimit Velocity Over Lifetimeで制限する

粒子…というか、質量が低い物は少ない力で吹っ飛ぶ割に空気抵抗等で即座に減速するという挙動が脳内でマッチします。

ので、速度が固定で動いてもらっては困ります。

f:id:tsubaki_t1:20170503203423g:plain

すべきことは単純で、Limit Velocity Over Lifetimeを使用するだけです。

Speedが減速する速度の設定なので、StartSpeedがこの値以上設定されている場合は、この値になるまで減速されます。

Dampenは減速速度です。1の場合は一瞬で減速しますが、0の場合は一切減速しません。0.5あたりの場合は、ユックリ減速します。

f:id:tsubaki_t1:20170503210419g:plain

カーブでパーティクルの速度を制限

Speedを0にしてDampenを0.5辺りにすることでも起動時から減速開始ししばらくすると停止は再現出来ますが、もう少し綺麗に動かしたい場合はカーブを使用します。

f:id:tsubaki_t1:20170503211053g:plain

カーブで、Lifetime内での速度をカーブ指定出来ます。例えば下のカーブでは、

Lifetimeが1秒くらいと仮定した場合、

  • 0.15秒くらいまで30で移動
  • 0.2秒から減速開始
  • 0.6秒に速度が0になる
  • 1秒まで速度0
  • 1秒で(Lifetime設定により)パーティクル消滅

という挙動になります。

f:id:tsubaki_t1:20170503211329j:plain

なお一度減速すると加速はしないっぽいです。

関連

docs.unity3d.com

tsubakit1.hateblo.jp

unity3d-study.seesaa.net

【Unity】1週間ゲームジャムに参加しました。メイキング・オブ・超速ブロック崩し(仮)

一週間ゲームジャム(#unity1week)が面白そうなので、参加してみました。

作ったゲームはこんな感じのゲームです。

超速のブロック崩し(仮) | ゲーム投稿サイト unityroom - Unityのゲームをアップロードして公開しよう

f:id:tsubaki_t1:20170501210819g:plain

 

一週間ゲームジャム

f:id:tsubaki_t1:20170501210445j:plain

大体1週間でゲームを一本作ろうというイベント企画です。
お題に沿って開発し、最終的にUnity RoomにWebGLで公開…というのが大雑把なレギュレーションです。

 

最初は時間無くて見てるだけの予定でしたが、ハッシュタグ#unity1week)を見ているとやっぱ楽しそう…

 

いやいやしかし、時既に時間切れ、もう勝負ついてるから…

 

 よし、やるか!

 作るものを決めよう

まずは作るものを決めます。実は「跳ねる」と聞いた時に頭に浮かんだキーワードがあるのです。「首をはねる」というもの

f:id:tsubaki_t1:20170501212602j:plain

昔やった超名作ゲームの一つで、ボタン一つで左右に移動、敵を打倒するというゲームです。少しゲームをプレイさせてもらっただけなので最早うろ覚えですが、凄い楽しかった事は覚えています。

それをもう一度プレイしたい…よし作ってしまおう

 

 

サクっとプロトタイプを軽く作ると単なる連打ゲーに成り下がりました。おかしい…こんなハズでは…

Y軸を増やして忍者ゲーにする

何度かプレイしていて思ったのですが、ふと

忍者が壁蹴りで近づいて敵を一掃する

の方が面白いのではと魔が差します。 丁度少し前に読んでたWeb小説で、壁蹴りで視界に入らず近づいて抹殺するシーンが…これは面白くなるのでは…

 

f:id:tsubaki_t1:20170501213426j:plain

スタート地点から開始、

時間を停止して、ルートを指定し(5回くらいまで着地とジャンプする方角を事前に設定)、一気に移動…その途中にいた敵は最後のジャンプ後にズババンと一掃。
(スパパっと切った後に鞘に収めると敵が一気に死ぬアレ)

…いや、面白いんじゃないか。いや、面白いに違いない多分

よし、

仕様を一部変更する!

 

サクッとプロトタイプを作ってみた所、キャラクターの移動ルート毎に向きを設定するのが面倒という感想…どうしてこうなった。

もう操作を単純にしてブロック崩しで良いんじゃないかな

敵を複数置いて一掃するのは楽しい。凄く楽しい。ココを伸ばすべきだ。

…もういっそ移動先は簡単な反射で…あれ、これブロック崩しか?

もういいや、ソレで行こう。

f:id:tsubaki_t1:20170501221501j:plain

ブロック崩しの面白い所(ポケットに入ってゴリゴリ削る)だけ抽出して、つまらないブロック移動時間を限りなくゼロにする…いや、これは面白くなるんじゃないか…?

 

よし、

仕様を一部変更する!!

 

スピードに物を言わせて大量のブロックをゴリゴリ削るブロック崩し。楽しそうじゃないか。ずっと速度が早いのはきついので、何らかの条件で速度を抑える感じで。

プロトタイプを作っていこう

時間も余り無いので、サクっと作ります。

周囲の壁はEdge Coliderで作成。元々はCompositeColliderでしたが、別にエッジで良いかな…という。まぁ、大した問題ではあるまい。

弾の移動は、Vector2のReflectionがあるので、ソレでサクっと計算してしまいます。壁の隅に当たると無限反射するかもしれませんが、まぁ仕様という事で。嫌なら角取りすれば良いかな(その為のEdgeColliderでしたが、面倒でやってないという話も)

弾は最初の企画通り、1フレームで目標地点まで到達するタイプ。

f:id:tsubaki_t1:20170501214823j:plain

サクッとブロックと地面の板を配置。スピードに物を言わせて飛ばすことは出来るには出来るが、一瞬で元の位置に帰ってきて面白くない。

 

あとゆっくりにするタイミングが難しい。

  • 「衝突確定コース時」にゆっくりにすると待ち時間が面倒だし、「距離に応じて」だと角度によって超待つ事になる。そもブロック崩しの一番つまらない所は待ち時間なので、これは避けたい。
  • 「落下確定したら3秒で落下するように」みたいな物はゲームが忙しすぎてゴリゴリ削る部分が楽しめない。

そも、板反射では思った所に飛んでくれない。ぐぬぬ

このアイディアも駄目なのか…?

f:id:tsubaki_t1:20170501215339j:plain

そういえばハッシュタグで面白い挙動があったような…

 これだ!コレで行こう!

これなら何処にでも板が置けるから、地面衝突コース時に即座に超ゆっくりに出来て、落下時の待ち時間を殆ど0に出来て、

プレイヤーはゴリゴリ削る所だけ楽しめる! 結果が即反映されるトライ&エラーだ。

さあやろう、すぐやろう!

 

ちなみに当たり判定はEdgeColliderでスタートとエンドを指定するだけです。長さが無限だとつまらなかったので、3mとします(適当

後付ですが、EventSystemを使ってモバイルWebGLでも動作するようにします。

f:id:tsubaki_t1:20170501224623g:plain

エフェクトをつけよう

大体挙動が出来たのでエフェクトを付けます。

とりあえず破壊時のパーティクルと弾の向きを表現するトレイルは確定として、後は何を付けるか。そして、何色を使うか。

このゲーム、やってみると弾がゴリゴリと壁を削っていく所が楽しいので、それ以外の要素ノイズです。

一応、操作はターンベースなゲーム(準備フェイズと効果測定フェイズ)に近いので、効果測定フェイズ時には何を積んでも良いといえば良いのですが、画面内に色を足してトレイルやパーティクルの出す「効果」をボカしたくない…ぐぬぬ、どうすれば

f:id:tsubaki_t1:20170501222100j:plain

よし、見なかったことにしよう

 

絵面だけ見ると、赤いパーティクルとトレイルが十分に画面を埋めてます。

でも今思えば、コンボ数に応じて文字を大きく派手にする的なものは付けてもよかったかもしれない

 

ルールを決めよう

振る舞いが出来たのでゲームオーバーのルールを決めます。

このゲーム、時間がほぼ停止する以上「弾の落下に依るゲームオーバー」は想定外です(リリース時弾が下に行ってもゲームオーバーしなかったのはこのせい)。

なので、もっと別のアイディアが必要になります。例えばこんな感じ。

  • ゲームのプレイ時間
  • 線を引ける回数(プレイヤー操作回数)
  • n%破壊までに引いた線の数
  • 反射回数
  • 指定したターゲットブロックの撃破
  • ブロックを補充しての破壊回数
  • ゲームオーバーなんて無い、心ゆくまで砕いてもらう

という事で色々と考えましたが、線を引ける回数がそれなりに面白かったのでそのまま採用。

 

完成

しばらく寝かせた後、少しパラメータを調整してUnity Roomにアップロードして完成です。ということで完成したゲームがコチラ。

超速のブロック崩し(仮) | ゲーム投稿サイト unityroom - Unityのゲームをアップロードして公開しよう

 

プレイに必要そうな所だけ作って後は演出という言い訳の下オミットしまくった結果、偶然中々に悪くない感じのゲームが出来上がりました。

 

一応モバイルでも動かしたかったので、コードは大体300行、使用素材は背景絵1枚という可能な限りシンプルな構造に設定しています。AndroidFirefoxの組み合わせならサクサク動きます。Chromeは若干カクカク。iOSはお察しください。

感想

面白いかどうかは兎も角として、脳汁が出るゲームを目指して作ってみました。しかし予想以上にプレイしてくれる人が居てビビってます。

やはりWebGL…インストール不要な環境はゲームがプレイしやすいのか。

 

また暫くしたら開催するみたいなので、面白いアイディアが来たら参加してみようと思います。 今回は初期アイディアから離れまくりでしたが。

 

しかし、今回投稿されたゲームを幾つかプレイしましたが、結構ハイクォリティで面白いゲームが結構あってビックリです。明日は幾つかプレイしたゲームを紹介したい

関連

Unity 1週間ゲームジャム | ゲーム投稿サイト unityroom - Unityのゲームをアップロードして公開しよう

www.urablog.xyz

mirai-no.hatenablog.com

w-shunn.hatenablog.com

kyuuko.s7.valueserver.jp