Unity 5 日記 6 ショットを発射

もう適当にさっさと書かないと飽きるので雑に書いていく. さっさとショット発射してみたい. 敵にあたるとかそんなんどうでもいい.

Unity 5 日記 2 スクリプトの作成 と Unity 5 日記 3 deltaTime の適用 で作成したオブジェクトにショットの発射機能を持たせる.

作成してあった移動処理をメソッド Move に分離し, メソッド Update を以下のように書き換える.

private void Update()
{
    Move();
}

変数 float shootFreeze と System.Collections.Generic.List<GameObject> shots を追加する.

private QuantizedTime shootFreeze;
private System.Collections.Generic.List<GameObject> shots;

ついでにメソッド Start に各々の初期化処理を追加しておく.

void Start()
{
    ...
    shootFreeze = 0;
    shots = new System.Collections.Generic.List<GameObject>();
}

はっきり言ってこの書き方は良くない. クソコードである. 関心の分離もへったくれもない. 本当なら別途ショットを管理するためのクラスを用意すべきだが, ここではとりあえず後回しにする.

Unity 5 日記 5 Prefab で書いたような感じで Prefab を作成し, Resouces フォルダに Shot という名前で適当にいれる.

そしてショットにスクリプトを追加する.

using System.Collections;
using System.Collections.Generic;
using UnityEngine;

public class ShotBehaviorScript : MonoBehaviour
{
    // Use this for initialization
    void Start()
    {
    }

    // Update is called once per frame
    void Update()
    {
        var x = transform.position.x;
        var y = transform.position.y;
        var z = transform.position.z;
        z += Time.deltaTime * 100;
        transform.position = new Vector3(x, y, z);
    }

    public bool IsOut()
    {
        return 32 < transform.position.z;
    }
}

メソッド Update で移動を行う. IsOut は消去判定を行うためのメソッドだ. Unity では画面外に出たことを判定するための関数があるが, ショットは画面外に出た時に消えてしまうのは困るので自分で色々判定する. ここでは本当に適当な値の比較にした.

そして自機側のスクリプトにメソッド Shoot を追加する. この名前もかなり悪い.

private void Shoot()
{
    if (0 < shootFreeze.Value)
    {
        var deltaTime = Time.deltaTime;
        shootFreeze -= deltaTime.Value;
        return;
    }

    var fire = UnityEngine.Input.GetButton("Fire1");
    if (fire)
    {
        GameObject shotPrefab = (GameObject)Resources.Load("Shot");
        var shot = Instantiate(shotPrefab, new Vector3(0,(float)_position.Y, (float)_position.X), Quaternion.identity);
        shots.Add(shot);
        shootFreeze.Value = 128;
    }
}

手元のスクリプトとブログに書いてあるスクリプトが一致していないので座標周りがおかしかったり変数名があっていなかったりするが心の目で読んで欲しい. Resouces ディレクトリに入れた Prefab は上記のような感じでインスタンス化することが出来る. 生成したショットは shots に追加する.

最後に画面外に出たショットを削除するためのメソッド RemoveShots を追加する.

void RemoveShots()
{
    for (int i = 0; i < shots.Count;)
    {
        var shot = shots[i];
        var script = shot.GetComponent<ShotBehaviorScript>();
        if (script.IsOut())
        {
            Destroy(shot);
            shots.Remove(shot);
            continue;
        }
        ++i;
    }
}

GetComponent でアタッチしたコンポーネントを取得し, メソッド IsOut で判定を行い, Destroy 関数で GameObject を削除する.

ShotBehaviorScript の中で Destroy(this) するとオブジェクト全体ではなくコンポーネント単体を削除してしまうらしい.

なんかもう記事書くのも面倒になってきた. この雑さ極まるコードを GitHub に丸上げして, コミットログにリンク張って日記にする程度でいいんじゃなかろうか.

Unity 5 日記 5 Prefab

Hierarchy 内に生成したオブジェクトを Project にドラッグ & ドロップするとなんか青くなる. 以後は Project 側からドラッグ & ドロップすると簡単にオブジェクトを複製出来る. Inspector からオブジェクトのパラメータを変更すると一括で変更出来る. オブジェクトのどの要素が個別に扱われ, どの要素が一括で変更されるのかはよく分からない. ぐぐって.

参考文献

• #11 Prefabを使ってみよう | Unity入門 - プログラミングならドットインストール

Unity 5 日記 4 InputManager の調整 キーボードの入力で慣性がつく問題の修正

デフォルトの設定だと UnityEngine.Input.GetAxis("Horizontal") や UnityEngine.Input.GetAxis("Vertical") で入力をいい感じに受け取れるが, ジョイパッドで操作する分には問題ないものの, キーボードで操作する場合に妙な慣性がついてしまう. 今回は入力系の設定変更でこのあたりの調整を行う.

Edit->Project Settings->Input から Unity の通常の入力系の設定を行うことが出来る. Inspector に Horizontal とかかれた項目が 2 つあると思うので, それを開く. 片方はキーボードの, 片方はジョイパッドの設定だ. Gravity はボタンを離した時の加速度, Sensityvity はボタンを押した時の減速度である.

大体 64 程度にしておけば FPS 60 の環境で 1 フレームで最大値になる. 高フレームレートでも同様になってくれる事を期待するのであれば 255 等にしておけば良いだろう.

欲を言えば 0 にした場合は必ず 1 フレームで最大値になる等の設定が欲しかった所だが残念ながらそういった機能はない. それどころか負数の指定すら出来てしまい, 入力方向に対して明後日の方向に加速していってしまう. それでよかったのか, Unity......

Unity 5 日記 3 deltaTime の適用

なんだか 前回 まで大真面目に記事を書いてたせいで新しく記事を書くのが億劫になってきてしまっていたので, 今回からもっと雑に書いていくことにする.

UnityEngine.MonoBehaviour を継承したクラスのメンバ関数 Update は毎フレーム呼ばれるが, 毎フレーム呼ばれるということはフレームレートの高い環境ではそのままではゲームの動作まで早くなってしまう. そこで, Time.deltaTime を乗算する事でこの問題を解決する.

void Update()
{
    var x_axis = Input.GetAxis("Horizontal");
    var y_axis = Input.GetAxis("Vertical");
    var vx     = x_axis * 60 * Time.deltaTime;
    var vy     = y_axis * 60 * Time.deltaTime;
    var v      = new Vector3(vx, vy, 0);
    this.transform.position += v;
}

Time.deltaTime には前回のフレームから今回のフレームまでに経過した時間が秒単位で保持されている. 型は float である.

FPS が 60 の環境である事を前提にフレームカウンタを回して任意の動作を実行するようなアルゴリズムを実行した場合は, Time.time の差分を取るか, Time.deltaTime を毎フレーム加算して, 大小の比較演算によって実行する必用がああるだろう. 浮動小数点であるから, 同値比較を行うと危険である事に注意.

Unity 5 日記 2 スクリプトの作成

前回は GameObject の追加とギズモを使った操作までを行った。 Unity入門 (全26回) - プログラミングならドットインストール ではこの後 Transform 、 Material の操作、 Rigitbody 、 Directional Light 、 GameObject の階層化、 Prefab が紹介されているが、それらを全てすっ飛ばして Script の追加に入っていく。 Visual Studio がインストールされている前提で話を進める。

プログラマ諸氏におかれては、さっさとプログラムに入って一先ず入力を受け取ってオブジェクトを動かしたくて仕方ないと思われるので、まずは Hierarchy ペインの Create ボタン 3D Object -> Cube で適当に GameObject を追加する。

次に、作成した GameObject を Hierarchy ペインから選択し、 Inspector ペインの最下部の Add Component をクリックしてコンポーネントを追加する。上部メニューの Component から追加してもよい。今回は New Script を選択し、名前を設定、 C Sharp のスクリプトを追加する。

スクリプトを追加すると Project ペインの Assets の中にファイルが追加される。ファイルをダブルクリックすると自動的に Visual Studio が立ち上がり、プロジェクトが生成され、ファイルが開かれる。自動生成したクラスは MonoBehaviour を継承しており、メンバ関数 Start と Update 関数が最初から定義されている。

不思議な事に、ファイル名とクラス名は一致していなければ Unity 側でうまく動かない一方で、クラスを名前空間に入れる分には特に問題なく動く。謎である。関数 Start はオブジェクトの生成時に一度だけ呼ばれる。一方 Update は毎フレーム呼ばれる関数である。

この時、すでに存在するクラス名を指定しようとすると、新しくファイルを追加出来ない場合がある。 Assets 内を適当に右クリックして新規ファイルを作成し、ドラッグ & ドロップで GameObject に Attach した方が良いのかも知れない。 そもそも名前空間で区切りながら同じ名前の複数のクラスを作成したいと考えていないが出来ないらしい。無念。

以下のように記述する事で、入力に応じてオブジェクトを移動する事が出来る。

public class NewBehaviourScript : MonoBehaviour
{
    // Use this for initialization
    void Start() {}

    // Update is called once per frame
    void Update()
    {
        var x_axis = Input.GetAxis("Horizontal");
        var y_axis = Input.GetAxis("Vertical");
        var velocity = new Vector3(x_axis, y_axis, 0);
        this.transform.position += velocity;
    }
}

Input は UnityEngine.Input クラスである。このクラスは静的メンバ関数 GetAxis を持っており、引数 axisName によって識別される Unity 側で仮想的に定義された軸の入力値を取得する事が出来る。

取得した値をベクトルに変換し、 MonoBehaviour クラスのデータメンバである transform を操作して実際の移動を行う。丁度、このデータメンバは Inspector ペインに表示される Transform の内容そのものである。

あとは画面上部の再生ボタンを押せば、ゲームが動作を開始する。ちなみに Visual Studio 側から Unity にアタッチすれば、簡単にデバッガも動いてしまう。

これで晴れて C# を使用して、スクリプトによるオブジェクトの操作が出来た事になる。カメラやライトの制御をきちんとしないと Game 内での実際の見え方は奇妙になるが、そこは適宜調整してやればよいだろう。あとは、オブジェクト間で互いに情報を取得するための手段と、オブジェクトの生成と破棄を行う仕組みがあれば最低限のゲームを作成する事が出来る。

Unity 5 日記 1 インストール - GameObject の操作

はじめに

超々久しぶりに Unity に触った。もうどの位久しぶりかというと、起動しようとしたら別ドライブに僅かに残骸だけが残っていてUnity自体がインストールされていなかった。

折角なので、自分自身の備忘録兼足跡として、日記をつけていく事にする。プログラムは書けるが Unity は初めてで右も左も分からない、という人の一助になれば幸いだ。

インストール

前回まで使っていたのが 4 系だったので 公式ウェブサイト から Personal 版をダウンロードしてインストール。インストーラ ( Unity Download Assistant ) に同時にインストールコンポーネントをどうするか聞かれるが、ざっと見た感じデフォルトで OK 。強いて言えば、 マニュアル に色々書かれていて参考になるかも。 Visual Studio 2015 との連携はあって損は無さそうだった。

新規プロジェクトの作成

新規プロジェクトの作成の際に、プロジェクトを 2D にするか 3D にするかを聞かれるが、 マニュアル によればゲームにより向き不向きがあるが、あとで切り替えられるらしいのでこのマニュアルを読みながら適当に決めれば良い。

真っさらな状態になった。うーんこの何もない荒野にほっぽり出された感。 UI が英語だし、そもそもどこからどう手を付けていいか分からない。もちろん 1 マス左に移動すると見えない村があるなどという事もない。

画面のレイアウト

#03 画面の見方を覚えよう | Unity入門 - プログラミングならドットインストール を見ながら色々と確認。

ウィンドウ内の各種タブはドラッグ & ドロップで移動する事が出来る。ウィンドウ外にドラッグ & ドロップする事で別ウィンドウに切り離す事も可能だ。また、レイアウトには各種プリセットが用意されており、右上のボタンから選ぶことが出来る。

動画でも Tall がオススメされていたので自分も Tall を選び、 Scene と Game が縦に並ぶようにした。

基本的に Scene の中に各種 GameObject を配置していく事になる。 Scene 内に配置された GameObject は Hierarchy タブ内に表示される。 Hierarchy 内の各種オブジェクトを選択すると、 Inspector タブにその GameObject の内容が表示される。 GameObject に Component を付加していく事で、オブジェクトに対する肉付けを行っていく。

操作モードとシーンビューの操作

Unity - マニュアル: シーンビューの操作

ウィンドウ左上に並んでいる各種アイコンが操作モードを決定する各種ツールだ。手のアイコン、十字アイコン、その他諸々のツールはパン、移動、回転、拡大/縮小、 Rect Tool に対応する。パンはハンドツールとも呼ばれる。尚、各種操作モードにはデフォルトで Q W E R T キーが対応している。

ハンドツールを選択しる時、左クリックでドラッグする事で視点を移動する事が出来る。移動を選択している場合は GameObject を移動させる事が出来る。

ただ、ハンドツールを選択していてもミドルクリック ( ホイールクリック ) でドラッグすればどちらのモードでも視点の移動が出来るので、そちらが使える人はそれでいいかもしれない。

右ドラッグで視点をその場で回転させる事が出来る。また、 Alt+左ドラッグでクリックした地点を中心に視点を回転、 Alt+右ドラッグで視点の拡大縮小を行う。その他詳細はマニュアルを参照。

また Scene 右上に表示されているアイコン ( ギズモ ) の操作でも視点の操作が出来る。

#05 GameObjectの操作をしてみよう | Unity入門 - プログラミングならドットインストール

GameObject の操作

GameObject を選択すると、中央にギズモが表示される。このギズモを操作する事で、操作モードに応じてオブジェクトの各種操作を行う事が出来る。

Asset

File -> Save Scenes Ctrl+S で Scene を保存すると、 Assets に保存したシーンが表示される。 Asset の概念はまだ理解出来ていないが、たぶん Project に紐付いたファイル全般を Asset と呼ぶのだと思う。 Scene も Asset 、その他色々な物も Asset なのだろう、たぶん。

参考文献

• Unity - マニュアル: Unity マニュアル
• Unity入門 (全26回) - プログラミングならドットインストール

Windows の解像度に思うこと

画素の密度

Apple が iPhone 4 向けに Retina ディスプレイを発表して以降、スマートフォン向けのディスプレイは高密度化し続け、その傾向はラップトップ PC やテレビにおいても同様である。しかし macOS のスケーリングは比較的綺麗に見える一方 Windows では従来のアプリケーションは UI がガタついたり、表示がボケボケになってしまう。

最新の MacBook Pro がフルサイズの USB ポートを廃止した事からも分かるように Apple は古い物を切り捨てる事に躊躇が無い。一方で Microsoft は ( サティア・ナデラの就任以降その傾向は変わりつつ有るものの ) 比較的後方互換性を重視する傾向にある。そのため、新しい高解像度環境において Windows では古いアプリケーションの表示に問題が発生してしまうのである。勿論、新しい開発環境で作成されたアプリケーションではスケーリングがほぼ上手く行われる。 Windows 10 では 25% 刻み 4 の倍数単位でスケーリングが行われるため Windows アプリ UX デザイン ガイドライン においても 4x4 のピクセルグリッドにデザインをスナップするようにと書かれている。

Windows でのアプリケーション側での対応については以下の記事に詳しい。

• 【4K修行僧】Windowsの4Kスケーリング環境を検証する ～文字表示は美麗。ただし、非対応アプリも多数存在 - PC Watch
• アプリの高DPI(High DPI)対応について 第2回 ～ アプリケーションの高DPIへの対応レベル ～ – 田中達彦のブログ
• WPF での高 DPI 対応 | grabacr.nét
• Windows 8.1 で加わった Per-Monitor DPI と WPF での対応方法 | grabacr.nét

しかしながら、結局の所 Windows では従来型の古いアプリケーションに有用な物が多く、その多くはバグフィックス等のメンテナンスは行われているものの UI を完全に刷新する程の対応が行われている物は殆ど無い。そのため、従来型のアプリケーションをピクセルパーフェクトにスケーリングするため 200% 表示に最適化されたディスプレイを搭載する事のアドバンテージが極めて大きい。

Microsoft もその問題を認識しているのか Surface Pro 4 や Surface Book の解像度は 200% スケーリングに最適な解像度になっている。

機種	size	x	y	DPI
Surface Pro 4	12.3	2736	1824	267
Surface Book with Performance Base	13.5	3000	2000	267
MacBook Pro (2016)	15.4	2880	1800	220
EV2116W-A	21.5	1920	1080	102
EV2451	23.8	1920	1080	92

古式ゆかしいコンピュータ用ディスプレイにおいては 72DPI または 96DPI がデファクトスタンダードとされてきた 。これはデスクトップ環境での利用を想定した数値であるから、より目に近い距離で使用されるラップトップ PC やタブレットにおいてはより高密度が好適である。現行の Surface デバイスの DPI は 267 であるから、 200% スケーリング環境では実質的なコンテンツの表示領域は 133.5DPI 相当となる。 Surface デバイスはラップトップ PC とタブレットを兼ねる 2-in-1 デバイスとしてのセグメントに属するので、その DPI もラップトップ PC とタブレットの中間であると考えられる。

現行のデスクトップ環境向けのディスプレイの解像度は 96DPI 前後が主流である事から、以下のようなディスプレイが望ましいと考える。

セグメント	DPI
デスクトップ	192
ラップトップ	240
タブレット	288

アスペクト比

PC のディスプレイのアスペクト比は時代と共に 4:3 、 5:4 、16:10 、 16:9 とそのメインストリームの軸足を移してきた。一方で Surface シリーズはアスペクト比 3:2 を採用している。

x	y	アスペクト比
640	480	4:3
800	600	4:3
1024	768	4:3
1280	1024	5:4
1280	720	16:9
1366	768	約16:9
2736	1824	3:2
3000	2000	3:2

PC 向けのディスプレイにおいて 16:9 が一期に普及した背景には、動画コンテンツの多くが視界全体の大きさを意識してそのサイズを採用した事にある。そのため PC で画面一杯に動画コンテンツを表示出来るようにするため、 PC においてワイドディスプレイが普及してきた初期に多かった 16:10 のアスペクト比が一気に駆逐されていった、という歴史的経緯がある。

一方で、縦に長いコンテンツを消費する事の多い PC においては縦の解像度のアドバンテージを支持する声も多く、 Surface シリーズのアスペクト比が 3:2 である事は、それらの揺り戻しであるとも言える。

デスクトップ PC においては、非常にワイドなコンテンツを表示したり、あるいはコンテンツを並べて表示する事に適した 21:9 の解像度を推す声もある。

私は、 3:2 の解像度は好ましいと考えるし、より小さなアスペクト比を採用し、また縦の値を共通化するという意味で、デスクトップ環境において 5:2 のアスペクト比もありなのではないか、と思う。

以下の表の x 及び y は既存の解像度と比較しやすくするため、半分の値にしている。

x	y	DPI	size	アスペクト比
1260	840	240	12.6	3:2
1260	840	264	11.4	3:2
1260	840	288	10.5	3:2
1344	896	240	13.5	3:2
1344	896	264	12.2	3:2
1344	896	288	11.2	3:2
1440	960	240	14.4	3:2
1440	960	264	13.1	3:2
1440	960	288	12.0	3:2
1536	1024	240	15.4	3:2
1536	1024	264	14.0	3:2
1536	1024	288	12.8	3:2

x	y	DPI	size	アスペクト比
2560	1024	192	28.7	5:2
2560	1024	216	25.5	5:2
2560	1024	240	23.0	5:2
1920	1280	192	24.0	3:2
1920	1280	216	21.4	3:2
1920	1280	240	19.2	3:2
3200	1280	192	35.9	5:2
3200	1280	216	31.9	5:2
3200	1280	240	28.7	5:2
2160	1440	192	27.0	3:2
2160	1440	216	24.0	3:2
2160	1440	240	21.6	3:2
3600	1440	192	40.4	5:2
3600	1440	216	35.9	5:2
3600	1440	240	32.3	5:2

5:2 のアスペクト比は昔の 5:4 のディスプレイを 2 枚並べた比率に相当する。意外とありなのではなかろうか？