【技術雑談】Unity5.3リリース

お疲れ様です、プログラム担当の藤岡です

世間では Advent Calendar の季節ですね

参考になるものや面白いものまで、

非常に楽しく見て回っています

僕も何かやりたいと思っているんですけどね…

今はアカとブルーの開発が忙しいのでなかなか…

そういえば!

先日 Unity5.3 が正式リリースされましたね

Unity5.2からの更新内容については、

公式含め色んな方がまとめているので割愛するとして…

では実際に更新すると、

既存プロジェクトにどんな影響が出るのか?

今回は自分が実際に試してみて、

わかったことをご紹介していきたいと思います!

① なぜかiOSの入力精度が上がった(謎)

アカとブルーでは、

Input.touches[0].position の差分で

指の移動を検知しているのですが、

2フレームに1度、

同じ座標が送られてきて移動がガタつくことがありました

 

Unity5.2 まで私 のiPhone5/iOS9.1(※) と、

iPodTouch6G/iOS9.1 において、

その現象を確認しています

※iOS8.3だとUnityアプリはXcodeでのチェックが出来ず、
  アップデートを強いられるハメに・・・

iPadMiniRetina/iOS8.2 では、

この現象は確認できなかったので、

画面サイズなのか?

はたまた

Unity が iOS9 に対応していなかったのか?

実際のところわかりませんが…

いずれにせよ、

iPhone と iPodTouch でしか発生していない現象でしたので

こちら側で如何ともし難いところではありました

それがなんと!

Unity5.3 で完全に解消されてました!

3DTouch 対応の為に、

Input 周りがいじられたと考えられますので

副次的に改善したのかもしれませんが、

iPhone 環境下での操作性が劇的に改善され、

僕は喜び勇んでいたのです!

がっ!

喜び勇んでいたのも束の間、

ここで別の問題が浮上するのです…

② uGUIのTextでdynamic font以外は座標がズレる

Twitter で検索したところ、

海外の方にも同様の現象が発生しているようでして、

bitmap font が上にズレます

キャプチャ

全部ズレる

助けてください

仕方が無いので、

フォントをアトラスかした場合に正しく表示されるかどうか…

休日にでも検証してみようとは思ってますが、

フォントというか…

uGUIのTextの問題のような気がしてならないので、

対応できるかどうか・・・

Dynamic Font は今までどおり問題ないですが、

uGUI を酷使してるプロジェクトで、

上記のような現象が発生した場合は、

Unity5.3 への更新は見送った方が良い気がしてます

(パッチー!はやくきてくれー!)

 

③tvOS の BuildSettings はあるが PlayerSettings がない

Define Symbol をスクリプト側から一律設定してはいるのですが、


private void SetDefineSymbols(string symbol) {

foreach (BuildTargetGroup target in Enum.GetValues(typeof(BuildTargetGroup))) {

if (target == BuildTargetGroup.Unknown)

continue;

if (target == BuildTargetGroup.tvOS)

continue;

PlayerSettings.SetScriptingDefineSymbolsForGroup(target, symbol);

}

}

tvOS はPlayerSettings がないので設定しようとすると

怒られます

④SceneManager 実装によって ActiveScene のID取得が変わった

新しい namespace ができましたね

UnityEngine.SceneManagement.SceneManager

僕のところでは、

Scene は文字列でなく、

全て『定数』で管理しているので、

今まで Application.loadedLevel で

現在のシーンNoをとっていたところを、

SceneManager.GetActiveScene().buildIndex

に変更する必要がありました

しかしながら、

僕は namespace の using 宣言は極力減らしたい派なので、

一回しか使わないようなものは

namespace をしっかり書くのですが・・・

UnityEngine.SceneManagement.SceneManager.GetActiveScene().buildIndex

…うん…冗長…

その他、

Application.LoadLevel とかも、

SceneManager.LoadScene に修正しました

この辺は記述を変更するだけですね

ということで、

今のところ、

僕が実際に試してみて確認できた影響は上記4点となります

入力が直ったことは本当に嬉しかったですし、

ParticleSystem のローカルスケールも対応したらしいので、

uGUI の Text をカカッとパッチで対応してくれれば

もう言うことありませんね!(切実

次回は何を話そうか…

何か書きます!

おたのしみに!

 

 

2011/12/11/19:11 追記

AndroidでSpriteRendererのBatchingが5.2に比べて異常に重くなってる・・・?

Permalink | 2015/12/11 + フジオカ

【朗報など】いろいろ報告

みなさま!

お疲れ様です

木村です

朗報その①

先のエントリーで点火しなくなったストーブですが…

なんと!

見事に復活を果たしたのであります

ストーブ復活!

これで開発室も暖かくなり、

より一層がんばることができそうです

(焼き芋が作れるぞ!!)

朗報その②

先月11月25日に僕が出演しました

イケダミノロックのそんなカンじでおネガいします(仮)

20回目ですが、

アーカイブとしてYoutubeにUPされたようです

当日、お仕事などで見逃してしまった方々、

是非、ご覧いただければと思います

配信中の画像

見逃した方はこちらをチェケラ!!

朗報その③

さて、タノシマスメンバーが一丸となって

現在開発中のスマートフォン向け本格シューティング

アカブルー

ですが、

iOSとAndroid

両方に対応します!!

(Unityを採用してますからね)

同時に発売できるかわかりませんが、

既に弊社内では両方の端末で動作しております

Andorid版 アカとブルー

Andorid端末を利用しているユーザー様に

これまで大変申し訳ないことをしたと思っていたので、

今回ははじめから両方のOSに対応させることを

決めていました!

なので、

今度こそご期待くださるとうれしい限りです!

また、うちのメンバー達が

さらなるクオリティーアップを図っていますので、

来年の早い時期にはまた一味違ったものを

お見せできると思っています!

きっと…

きっと…

きっと…

そんなわけで、

乞うご期待!

Permalink | 2015/12/10 + KMR

アカとブルーの技術話その1【UnityでSTGを作るということ】

お疲れ様です、プログラム担当の藤岡です

今回は技術話ということでUnityでSTGを作る上での話をご紹介しようと思います

(※今回言っているSTGとはいわゆるiOS/Android環境下における2D弾幕系のSTGと定義します)

先に補足しておくと僕はSTGについてはド素人で何もわかってないですし、作ってみたのも今回が初めてです

(関わったことはありますがUIやiOS/Androidライブラリ担当だったので・・・Androidライブラリは日の目を見ませんでしたが)

なので、「コイツSTGをわかってない!」と思われることもあるかと思いますが、実際わかってないことをご理解ください

そして書いてるうちに盛り上がって、ちょっとくどくなってしまいました…

すみません…

さて、気を取り直して続きを…

STGというジャンルはゲームの進化系統図においてほぼ根幹に位置すると僕は考えていて

始祖は、皆さんがご存知のインベーダーになるんじゃないでしょうか

(ビデオゲームそのものとなるとPONGとかの話が出るんでしょうが・・・その辺は話が逸れるので)

そんな根源的であるジャンルにおいて、文字通り死ぬほど重要視されていると思われるのが、

「操作」「動作」ではないでしょうか?

「操作」における重要度

操作における重要度というと、

過去に、某案件で入力遅延が(僕の知らないところで)発生しまして、

取引先からちょいちょい電話で釘を刺され、

上司からドヤされストレスで血便が止まらなくなったぐらいトラウマでして…(実話)

スマホ(タッチパネル)における「操作」については、

未だ納得がいかない人もいるかと思いますが、同ジャンルのアプリを見ていると、

個人的な見解ではありますが、ある程度結論は出ていると思っています

ボタン入力の有無については、個々、人の好き嫌いかなと思ってますし、

3Dタッチが標準になればまた変わるかなとも考えています

入力遅延についてはハードウェアやOS依存の部分が大きいので、

アプリケーションレベルでは解消しきれないのが実情です

正直、操作感覚だけで入力遅延を感知出来ない鈍感な僕は、

コードレベルで遅延が発生しないようにすることしか出来ません

そして今回、

問題になるのが「動作」です

まずメモリ

iPhone3GS時代は100MB、iPhone4/4Sで150MB、iPhone5/5S/6は200MBが

単一のアプリが使える量のデッドラインと考えています

一般的なスマホユーザーは常に複数個のアプリを起動させますので

やはりiPhone6が1GBしかない現状で200MB以上メモリを使用するのは利便性がよろしくないと考えています

(Infinity Bladeのようなハイエンド端末のベンチマークアプリはまた例外と思いますが・・・)

とは言え数字だけ見る人達からすれば使用メモリ量は売り上げにならないことなので、

そこに予算や期間をなかなかさいてもらえないのも難しいところです

特に2DSTGでは、もっぱらコマアニメーションを多用しがちなので、

テクスチャサイズや枚数について何をどの程度使うか厳格に決めねばなりません

ちなみにAndroidは、Javaの仕様上物理メモリが多いほど、

端末全体の動作が安定するとかなんとか・・・(超適当

次に処理負荷

STGのようなアーケードライクなジャンルは、やたらと60FPSを要求されます

STGにおいてはやはり”物量”がものを言いますので、

ビックリするほど大量にオブジェクトを表示させることが一番の課題となります

今回はマルチプラットフォーム対応としてUnityを採用しています

(それだけが理由ではないのですが割愛)

処理負荷を考えるにあたって、Unityを採用することで起きる問題というと、

大きくは以下の2つに分類されます

1.Unity由来の問題

2.C#由来の問題

1については、Unityを正しく理解する学習コストがかかる、

またはUnity側のアップデート対応を待つしかないという問題が発生します

事実、Unity暦4年目ですが未だに全てを把握出来てません

2については、90%がGC(Garbage Collection)の問題です

今まで「UnityでSTGは作れない」とおっしゃるベテランの方が非常に多かった印象ですが、

基本的に、矩形ポリゴンが容易に出せないことが大半の原因を占めていたように思います

当初(Unity4.0時代)は、僕はNGUIで無理矢理2Dゲームを作っていましたが、

NGUIがそういう使い方を想定していないので処理が遅すぎてお話になりませんでした

既にUnityを使用して開発をしている皆さんはご存知かと思いますが、

Unity4.2においてSprieRendererとQuadが実装されました

もう正直これだけで、UnityでSTGが作れない理由の8割は解消しました

残り2割はUIの問題です

Unity4.6からuGUIが実装されましたが、

根本的なパフォーマンス問題はNGUIと大差なく

Unity5.2から大幅改修が入りましたが、

未だにデリケートな場面で採用するかの判断は迷うところです

(※メニュー画面では活躍すると思います)

そんなわけで、結局エネルギーゲージや体力ゲージのような部分は

自前でMeshRendererを作るのですが・・・(不毛な作業です

スプライトを反転させるにも、

マテリアルのカリング設定をOFFにして逆向きに回転する手段しかわかりません

(方法があれば教えてください)

Unity5.5までのロードマップでは、2D関連の更新が多く予定されているので、

その辺りはいずれSpriteRendererで全部対応できるんじゃないでしょうか

コードレベルでのUnityのパフォーマンスを引き出すTIPSについては、

また別途ご紹介したいと思います

C#、というよりは.NET Frameworkと言うべきなのか

いいところはたくさんあるのですが、GCだけはいただけない

他にもUnityC#で明示的なインラインコードの書き方を知っている人がいたら是非教えてください(切実

GCを止めるには、GCが許容出来ない場面でのヒープの確保をなくすことが必要になります

(※抑えるということではない)

GC発生時の処理負荷も確保した量ではなく、

確保した個数によってふくれるという話(検証したわけではない)なので

細かなヒープのつまみ食いこそが危険だと考えます

C#におけるヒープを食うありがちな要因はstringです

stringを使う場合は放射性物質を扱うがごとく、メモリをこぼさないようにしなければなりません

他にも、foreachは内部でヒープを食っている疑惑や、

そもそもforより遅いしでEditor拡張以外では実用的ではありません

delegateのインスタンスも必ずキャッシュするようにしています

(当初気づかずにラムダ式でコールバック設定して毎フレーム食い散らかすという失敗が・・・)

GC以外にも細かな処理速度には気を配っていたりはします

Collection系は参照速度が遅いので固定配列にします

Propertyの{get; set;}も、コール時のオーバーヘッドが気になるので、

極力メンバの宣言を省略せずにメンバの実体から参照するようにしています

そんな不毛な作業を繰り返せばパフォーマンスは上がりますし、

C++だとかC#だとかっていう垣根は言語宗教の域でしかないと思っています

いずれ、検証結果を交えたコードレベルでの

C#におけるパフォーマンスTIPSをご紹介したいと思います

長くなってしまったので実用的な紹介は次回以降の技術話でやっていきます

次回はまた、舞台裏のお話

敵配置のやり方をご紹介しようと思います!

お楽しみに!

Permalink | 2015/12/04 + フジオカ

【裏話】ストーブ壊れる

みなさま、お疲れ様です。

木村です。

開発の裏話をしていくということで、

これも立派な裏話であろう話題!

ここ最近、めっきり寒くなってきましたよね…。

実は、タノシマスの秘密基地内開発エリアの寒さは

ハンパじゃなかったりします!

それはもう足先がビリビリするほど寒い!

そんなこともありまして、

11月12日に対流型のストーブを導入したのであります。

一応会社という体裁がありますので、

非常時にも使えた方が良いだろうと対流型を選んだのですが、

これがまた非常に使える素晴らしい高性能機器で、

ときにヤカンでお湯を沸かしたり、

IMG_6083

さらには焼き芋を焼いたり、

IMG_6084

ジャガイモまで焼いたりと、

IMG_6163

いろんな活躍をしてくれたりしたのです!

もちろん!!開発エリアも暖かくなったのでした…

がっ

ストーブを導入して約2週間程しか経っていないのに、

ストーブが点火しなくなってしまいました…。

IMG_6183

ナンテコッタ

仕方がないので、

エアコンで暖をとっております…。

長いこと開発をしていると、

開発ではないところでも事件というのは発生します。

今回はそんなお話でした。

みんな!風邪ひくなよ!

Permalink | 2015/12/02 + KMR

アカとブルーの舞台裏その1【ステージ1背景レイアウト】

お疲れ様です、初めまして、プログラム担当の藤岡です

僕の方からは技術とは関係のない“こんな感じで作ってます”っていう“舞台裏”

技術的に“こうやって作ってます”っていう“技術談”を交互にご紹介していこうと考えています

ということで、今回は技術に関係のない舞台裏をご紹介します

 

今回ゲームエンジンとしてUnityを採用しています(採用までの経緯は後日に技術話として)

なのでステージ1の全体像はこんな感じ

キャプチャ

2Dシューティングではありますが3D空間で配置してます

ぶっちゃけると元々3Dシューティングで作ろうとしてた名残なんですが・・・有効活用してます

 

そして先日のイケダミノロック様のUSTを見てくださった方はご存知かと思いますがステージ1では旋廻するような背景演出が入ります

(2MB制限があるらしく解像度低くてすいません・・・)

Animation-1

今回背景を立体的に動かしたいという木村の意向があったのですが

①背景の3Dモデルを作る人がいない

②2Dデザイナーしかいない

という縛りプレイでぶん投げられなんかそれっぽく設計しました

Animation-2

 

なんかそれらしくなったのでそんな悪くないんじゃないかなぁと思っていますし、思ったより印象に残って頂けたみたいでなによりです

(逆にシューティング部分のインパクトがまだ印象残らないよねとも感じます)

技術的にはなんにも凄いことはしてないです、スプライト(板ポリゴン)を並べてるだけです

演劇の書き割りを並べてるイメージをして頂ければわかりやすいですかね

 

それでは今回はこの辺で

次回は技術談で”UnityでガチSTG”を書きます

スマホでUnity使ってちゃんとしたSTGは作れないよって結構言われてきたので・・・色々やれば出来ますってお話をさせてください

どうぞお楽しみに!

Permalink | 2015/11/29 + フジオカ