Plastic SCM+Unity入門 -Plastic SCM概要と導入とUnity用プラグイン-

はじめに

文中で説明、および検証しているツールやパッケージのバージョンは以下の通りです。バージョンによっては説明に差異がある場合もありますのでご注意ください。

• Plastic SCM 10.0.16.5397
• Unity2021.1.0f1
• Plastic SCM Plugin for Unity (beta) 1.4.1

Plastic SCMとUnity

Plasctic SCMはCodice Softwareが提供するバージョン管理ツールです。

www.plasticscm.com

2020年にUnityがこのCodice Softwareの買収およびUnityとPlastic SCMの連携を公式のブログで発表しました。

blogs.unity3d.com

バージョン管理ツールといえばGitやSVNといった有名なものがありますが、他の著名なツールとの比較は公式サイトで公開されています。Plastic SCMが最強そうな比較になっていますが、特徴の雰囲気は掴めると思います。

Plastic SCM - Comparisons

公式の比較の中でも言及されていますが、Plastic SCMの特徴には大きく以下のようなものが挙げられます。

• 集中型か分散型か選択可能
• 巨大なバイナリを扱える
• ゲームクリエイターをターゲットにしたサポート

集中型か分散型か選択可能

バージョン管理ツールにはSVNのように使用者が単一のリポジトリに対して操作を行う集中型と、Gitのように使用者それぞれのローカル環境にリポジトリのクローンを用意して操作を行う分散型が存在します。Plastic SCMは両方に対応し、用途に合わせて切り替えが可能になっています。

巨大なバイナリを扱える

巨大なバイナリというのは100MBを超えるようなファイルを指します。ゲーム開発でいえば2Dおよび3Dのクリエイティブコンテンツが大きくなりがちですが、それを取り扱えるのはゲーム開発にとって都合のいいポイントのひとつです。また、データの送受信が高速だったり、処理が高速だったりするのもPlastic SCMは売りとして掲げています。こちらは自分は検証していないのでゲーム開発のケースでどれほど効率化が見込めるかは言い切れませんが、公式で説明があるので興味のある方は参照してみてください。

Plastic SCM - Performance - Optimized network channel for high latency Plastic SCM - Performance - Performance results of Plastic SCM

ゲームクリエイターをターゲットにしたサポート

Plastic SCMはゲーム開発のサポートを大きく意識しており、公式サイトでもゲーム開発者に向けた案内が存在します。

Plastic SCM - The version control for game developers

たとえば現状であれば次のようなサポートが提供されています。

• クリエイター向けのGUIツール
• UnityおよびUnreal Engine用のプラグインの提供

クリエイター向けのGUIツールは「Gluon」という名前でエンジニア用のGUIツールとは別に用意されています。クリエイターには不要だったり過度に高度だったりする機能を排除してシンプルな操作性を実現し、クリエイティブのプレビュー確認を可能にしてくれます。ゲーム開発ではクリエイターがバージョン管理ツールを触ることも多く技術的なハードルが課題に上がりがちですが、そこをしっかりフォローしてくれているのはありがたいです。公式のドキュメントはこちらになります。

Plastic SCM version control · Plastic Gluon guide

Unity用のプラグインについては後述しますので、詳しくはそちらを参照してください。Unity上でPlastic SCMの操作を行うためのプラグインとなっています。

Plastic SCMの導入

Plastic SCMにはCloudとEnterpriseの2つのプランが存在します。基本的に有償ですが、Cloudは使用形態やストレージの使用量によって無料になります。

本記事ではこのCloudの導入について説明します。Cloudの申し込みは公式サイトより可能です。

Plastic SCM - Licensing and pricing options

フォームに必要な情報を入力し、正常に完了するとメールが届きます。

次にツールをインストールします。公式サイトからインストーラーをダウンロードし、実行します。 必要な設定を入力してインストールしてください。（特別な設定などもないため詳細な説明は省略します。）

Plastic SCM - Download Plastic SCM

インストールが完了するとGUIツールおよびCLIが使えるようになります。CLIは「cm」コマンドで確認できます。

>cm version
10.0.16.5397

詳しいコマンドの説明は「cm help」と叩くか、公式のドキュメントを参考にしてください。

Plastic SCM version control · CLI guide

次にGUIツールのセットアップを行います。 インストールしてPlastic SCMを立ち上げるとサインインの画面になるので、登録したメールアドレスを入力します。サインインが完了すると集中型か分散型か最初の設定として聞かれるので、使用する方を選択してください。

以上の手順でGUIツールのセットアップが完了となります。

Plastic SCMの基本的な機能

バージョン管理ツールということで、大元のリポジトリとのやりとりが存在します。他のバージョン管理ツール同様にブランチで変更を管理します。変更を統合する際にはマージして、とこの辺は特段変わった点はありません。

リポジトリおよびブランチに関する基礎的なコマンドをざっくりと紹介します。

• checkin: ブランチへの変更の反映 (Gitでいうcommit)
• update: ブランチの変更の取り込み (Gitでいうcheckout)
• push: ローカルリポジトリのブランチをリモートリポジトリに反映 (Gitでいうpush) ※分散型でやる場合
• pull: リモートリポジトリのブランチをローカルリポジトリに反映 (Gitでいうpull) ※分散型でやる場合

基本的には他のバージョン管理ツールでも見かけるような操作です。集中型と分散型が選択できるということで、分散型の時のみローカルのリポジトリをリモートのリポジトリに反映するためにpush/pullを活用します。

そしてGUIツールではワークスペースや手元の変更が確認できたり、上記の処理をGUI操作だけで行うことが可能です。

ブランチの確認やマージなどもGUI操作で完結します。ブランチエクスプローラーではブランチのダイアグラムを可視化します。

UnityのPlastic SCMプラグイン

Unity用のプラグインは現状Asset Storeで公開されています。（今後はPackage Managerへの移行を検討してそう？）

assetstore.unity.com

自分のアセットとして追加したら、Package Managerからプロジェクトへインポートします。

導入したらWindowメニューからPlastic SCMを選択します。ワークスペースの作成を促されるので、プロジェクト用のワークスペースを作成します。

ワークスペースの作成が完了するとEditor Windowが開きます。checkinなどの操作がUnity上でさくっとできるのは便利です。 現在のブランチの履歴もUnity上で確認することが可能です。

このようにGUIのレイアウトもある程度整っていて使いやすいです。しかし、本当に基礎的な操作と確認ぐらいしか現状できないのと、読み込みが遅い感触があるので、現状はPlastic SCM側のツールやCLIを使った方が便利かなというのが個人的な感想です。ただ、まだベータ版なので今後に期待したいです。

おわりに

Plastic SCMは日本ではそんなに使用事例がなく、日本語の情報も少ないです。自分はUnityが連携するという発表をして初めて知り、調べた次第です。 ゲーム開発にフォーカスしており、Unityと連携しているということで、今後も注目していきたいツールです。

参考資料

詳しいPlastic SCMに関する説明は公式が提供しているPlastic SCM Bookを参考にしてください。英語ですが、詳しい機能やその思想や用途について説明されています。

www.plasticscm.com

【Unity】アプリケーションの検証を自動化しQAを効率化する新機能「Unity Automated QA」の紹介

はじめに

つい先日、Unity公式が開発中であるAutomated QAという機能が紹介されました。

blogs.unity3d.com

QA効率化のためにUI操作を記録し、それを再生できるという機能っぽいです。この記事では機能の概要と使い方の説明、および触ってみての所感について話していきます。

※ 本記事で使用するUnityおよびAuromated QAのバージョンは以下の通りです。バージョンによっては挙動および機能が異なる場合がございますので、ご了承ください。特にAutomated　QAはかなりpreviewの機能なので、大きく内容が変わる可能性もあります。

• Unity 2021.1.0f1
• Automated QA 0.2.0-preview.3 - April 08, 2021

Automated QAとは

公式でAutomated QAについて機能の概要がこう書かれています。

The Automated QA package enables users to record and playback touch or drag interactions with the UI of a Unity Project and optionally use recordings to drive Unity Tests – in the editor, on an iOS or Android device.

ユーザーのUI操作を記録し、リプレイとして実行できるという機能です。どのように活用できるかというと、

• QAが検証でルーチン化できる部分を記録し、自動で検証
• QA側が確認した問題の発生手順を記録し、エンジニア側で再現（逆も然り）

といったように、アプリケーションの検証、いわばQAのフローを効率化できる機能になっています。実際に簡単なUIを配置して、使ってみた動画がこちらになります。ボタンの押下を記録し、再生しています。

この機能はタップとドラッグの2つの操作を記録できるのですが、特徴的なのが対象のGameObjectの名前とタグも記録されるというところです。たとえば「Button」という名前のUIのGameObjectをタップした場合はその「Button」という名前とそのタグも一緒に記録されます。たとえばリプレイした時にちゃんと想定する画面になっているかといったように、一連の操作に対するオブジェクトの有無の検証に活用できる機能です。

Automated QAの導入

Automated QAはPackage ManagerのAdd package from git URLから追加します。「com.unity.automated-testing」と入力してください。

正常に導入が完了するとWindowのメニューに表示されるようになります。

Recorded Playback

UIの操作の記録と再生はRecorded PlaybackのWindowから実行します。メニューで選択するとWindowが開きます。

Recordを押すとWindowが閉じ、シーンがPlayされます。Play中のUI操作は記録され、終了すると記録した情報がjson形式で保存されます。保存される場所はWindow上で指定できるRecording assets pathになり、デフォルトだとAssets/Recordingsに指定されています。jsonの中身は主にUI操作の位置や対応するGameObjectの情報の配列になっています。

保存されたデータはRecorded PlaybackのWindowに表示されています。Playを押すとシーンのPlayと共に記録されているUI操作が順に実行されます。

実行中に前述した操作の対象となるGameObjectがなかった場合（記録では「Button」を押しているはずがなかった場合）はとりあえず座標に基づいて操作の実行はしながらもwarningを出すというのが現状っぽいです。

この辺は何か別の結果レポートだったり、独自のログを含むエラーだったり、検証結果として出力する仕組みが欲しいところです。ただ、自動で操作して意図したヒエラルキーになっているかどうか検証するには十分便利かなと思います。

Composite Recordings

ゲームをPlayして終了するまでの一連の操作の記録だけではなく、部分的な記録だったり、記録同士の組み合わせるComposite Recordingsという機能も用意されています。メニューからAutomated QA→Advanced→Composite Recordingsを選択するとWindowが開きます。

前述したRecorded Playbackと同様に記録の開始と停止、実行ができます。違う点としては部分的な記録であるSegment Recordingが記録できることです。SAVE SEGMENTを押すとその時点までの操作を断片的に出力してくれます。

生成したSegment Recordingは好きに組み合わせて一連の操作にするComposite Recordingの生成が可能です。CREATE COMPOSITE RECORDINGを押すとComposite Recordingを生成する画面になります。

+と-で追加と削除をして、SAVE COMPOSITE RECORDINGを押すとひとつの記録となったデータが生成されます。ちなみに組み合わせるのは前述したRecording Playbackでも可能です。
この機能は似たような操作の自動化を量産するのに役立ちます。たとえばあるUIの遷移フローの検証をしたいと考えてみます。画面の種類をアルファベットとして、A-B-C、A-D-B-Cといった部分的に一致しつつも分岐するフロー全てを自動で操作したいと考えた時に、何回も同じ部分を記録するのはやや手間です。そこでComposite Recordingsを活用することでそれぞれのA-B、B-Cといった単体の遷移操作を記録し、組み合わせで実現することが可能になります。網羅的な検証を自動化する際に活躍する機能ですね。

Automated QAの展望

手元で操作のリプレイ検証ができるだけでも一定の効率化は達成できますが、さらなる機能改善として公式のブログでは次の2つが書かれています。

Coming Soon: Composite Agents

We are adding support for the creation of game playing agents composed of recordings, C# scripts, and ML-Agents.

リプレイだけではなく、C#スクリプトおよびML-Agentsを用いたAIでも自動操作を可能にする予定っぽいですね。UI操作をスクリプトで書けるようになるのは必要になりそうだなと思います。たとえば適当にUIを押すようなモンキーテストだったり、条件によって分岐するようなちょっと複雑なテストだったりと、ある程度ロジックを挟み込みたいケースは需要があり、それを普段の実装と同じC#で実現できるのは便利そうです。そして、ML-AgentsによるAI操作ですが、これはかなり期待したい内容ですね。やはり自動テストの理想型はリプレイのテストやエンジニアが実装するテストではなく「自動でよしなにチェックするテスト」です。Unityの提供するML-Agentsによってテストを学習し、検証が必要な部分を自動で判定して処理する仕組みができたら最強だなと思っています。また、これはComposite Recordingsの機能の一環として実装されるそうなので、ここまではリプレイでここからはAIで最後はC#、みたいな合わせ技も可能そうです。

Coming Soon: Run tests on real devices in the cloud from the Unity Editor or CI

We’ll handle the infrastructure so that cloud on-device testing is even easier than local on-device testing. And we’ll make the resulting pass/fail status, logs, and screenshots available directly from both the Unity Editor and via API.

クラウド上の端末で動くような仕組みも検討しているっぽいです。エディタ上および手元の端末で動くだけでも有用ですが、クラウド上で動く仕組みができると自動化できる規模感が大きく変わります。物理的な制約を外れてスケールできるため、それこそ1000台の端末で全てのインゲームのステージをテストするなんてことも可能になるわけです。まぁお値段もそれなりにかかってしまうことが想定されるので法人向けかなと思いますが、個人的には注目したい機能です。公式ドキュメントではAWS Device Farmとの連携が可能になるという感じでした。

[Early Access] Running Recorded Tests on a Cloud Device Farm This package includes support for running Recorded Tests (and other Unity Tests) on Android Phones hosted on AWS Device Farm - no AWS account needed.

Through June 2021, we’re offering 100 hours of cloud testing free to every organization with a Unity Pro license. After the free trial, cloud testing will cost $10 per device hour. Please email us at a >AutomatedQA@unity3d.com for access!

おわりに

Automated QA、熱いですね。特に昨今のモバイルのゲームのクオリティや規模感はどんどん上がっており、それに伴うQAのコストもどんどん上がっています。いろいろな企業がCEDECなどのカンファレンスで自動テストのノウハウでこういった課題を解決するという発表も最近はよく見る気がしていますが、そういった中で公式からQAの効率化機能を提供してくれるのはありがたいなと思います。まだ開発も始まったばかりっぽい機能で今後どうなるかは未知数ですが、引き続きチェックしていきたいですね。

参考資料

この記事を書くにあたって、公式のマニュアルを大きく参考にさせていただきました。ここでは紹介できなかった機能もあるので参考にしてみてください。

docs.unity3d.com

【Unity】Device Simulatorで複数の端末でのプレビューを爆速で検証する

はじめに

Unityでモバイル向けのアプリケーションを開発している時、どうしてもぶち当たる問題の一つがさまざまなデバイスの解像度に合わせたレイアウトの問題です。 各種解像度やセーフエリア対応など、UIをただ配置するだけでも気を使うことが多く開発者が頭を抱えている問題の一つでしょう。該当の端末にインストールして確認して、という繰り返しはつらいものがあります。
そこで活躍するのがUnityのDevice Simulatorという機能です。Device Simulatorを使うことで端末ごとのレイアウトをエディタ上で再現して確認を爆速で行うことが可能です。 今回はそのDevice Simulatorの導入やその一連の機能について紹介します。

※ 本記事で使用するUnityおよびDevice Simulatorのバージョンは以下の通りです。バージョンによっては挙動および機能が異なる場合がございますので、ご了承ください。

• Unity 2021.1.0f1
• Device Simulator 2.2.4-preview - November 30, 2020

Device Simulatorとは

Device SimulatorはUnity公式が提供している機能です。Gameビューのサイズをさまざまな端末に対応して変更し、描画のレイアウトを確認することができる便利機能です。

Unity2020まではPackage Managerでの提供でしたが、Unity2021からは標準機能として導入されています。標準機能として活用できるということで、今後もアップデートされていきそうだなーと期待しています。

Device Simulatorの導入

Device SimulatorはUnity2021以降であれば標準で入っていますが、パッケージを更新したかったり、Unity2020以前を使用されている方はPackage Managerを参照する必要があります。 本記事を執筆している時点ではまだpreviewのパッケージですので、Project Setting -> Package Managerの画面にあるEnable Preview Packageを有効にしてください。

設定してPackage ManagerのUnity Registryで検索すると出てきます。

インストールするとGameビューにDevice Simulatorに切り替えるメニューが出てきます。これでSimulatorを選択したら導入は完了です。

Device Simulatorの機能

導入するとGameビューが端末に表示されているような見た目になります。iPhoneの上部のノッチも反映されています。GameビューなのでもちろんこのままゲームをPlayすればこの画面上に表示されますし、入力も同様に行うことができます。

そしてDevice Simulatorの大きな特徴がセーフエリアやノッチを加味したエリアの可視化です。右上にある「Safe Area」ボタン押すと有効になります。デフォルトでは緑色の枠で表示されており、UIを安全に配置できる領域を確認することが可能です。

画面のレイアウト作りで複数端末での見栄えを検証する時にはおすすめしたい機能です。

見た目の設定

見た目の解像度やセーフエリアの設定は左上のタブから切り替えることができます。iPhone、iPad、Pixel、Nexus、Galaxy、Galaxy Noteなどさまざまな端末の解像度が用意されています。

PortraitやLandscapeといった画面の向きの設定は左のパネルから調整できます。

画面の回転やズームなどは先述の「Safe Area」の有効化ボタンと同じく右上のメニューから調整可能です。

また、ApplicationクラスのAPIについて一部の値をGUI上から設定することができます。GUIで設定する情報だけでなく他にも色々な値が端末情報に合わせて変更されるのですが、これについては次に詳しく説明します。

Screenクラスなど値の上書きとSimulation Scope

Device Simulatorの特徴は単純な描画のプレビューだけでなく、Screenクラス、SystemInfo、Applicationクラスで参照できる情報も上書きします。たとえばScreen.widthやheight、safeAreaといった端末依存の情報を活用して独自の処理を行いたい時の検証を行うことが可能です。少し多いですが、上書きされるAPIを網羅して紹介します。

Screen

• autorotateToLandscapeLeft
• autorotateToLandscapeRight
• autorotateToPortrait
• autorotateToPortraitUpsideDown
• currentResolution
• cutouts
• dpi
• fullScreen
• fullScreenMode
• height
• orientation
• safeArea

SystemInfo

• copyTextureSupport
• deviceModel
• deviceType
• graphicsDeviceID
• graphicsDeviceName
• graphicsDeviceType
• graphicsDeviceVendor
• graphicsDeviceVendorID
• graphicsDeviceVersion
• graphicsMemorySize
• graphicsMultiThreaded
• graphicsShaderLevel
• graphicsUVStartsAtTop
• hasDynamicUniformArrayIndexingInFragmentShaders
• hasHiddenSurfaceRemovalOnGPU
• hasMipMaxLevel
• hdrDisplaySupportFlags
• maxComputeBufferInputsCompute
• maxComputeBufferInputsDomain
• maxComputeBufferInputsFragment
• maxComputeBufferInputsGeometry
• maxComputeBufferInputsHull
• maxComputeBufferInputsVertex
• maxComputeWorkGroupSize
• maxComputeWorkGroupSizeX
• maxComputeWorkGroupSizeY
• maxComputeWorkGroupSizeZ
• maxCubemapSize
• maxTextureSize
• minConstantBufferOffsetAlignment
• npotSupport
• operatingSystem
• operatingSystemFamily
• processorCount
• processorFrequency
• processorType
• renderingThreadingMode
• supportedRandomWriteTargetCount
• supportedRenderTargetCount
• supports2DArrayTextures
• supports32bitsIndexBuffer
• supports3DRenderTextures
• supports3DTextures
• supportsAccelerometer
• supportsAsyncCompute
• supportsAsyncGPUReadback
• supportsAudio
• supportsComputeShaders
• supportsCubemapArrayTextures
• supportsGeometryShaders
• supportsGpuRecorder
• supportsGraphicsFence
• supportsGyroscope
• supportsHardwareQuadTopology
• supportsInstancing
• supportsLocationService
• supportsMipStreaming
• supportsMotionVectors
• supportsMultisampleAutoResolve
• supportsMultisampledTextures
• supportsRawShadowDepthSampling
• supportsRayTracing
• supportsSeparatedRenderTargetsBlend
• supportsSetConstantBuffer
• supportsShadows
• supportsSparseTextures
• supportsTessellationShaders
• supportsTextureWrapMirrorOnce
• supportsVibration
• systemMemorySize
• unsupportedIdentifier
• usesLoadStoreActions
• usesReversedZBuffer

Application

• internetReachability
• isConsolePlatform
• isEditor
• isMobilePlatform
• platform
• systemLanguage
• LowMemoryCallback

SystemInfoとApplicationクラスのAPIまで上書きしてくれる便利な機能ですが、逆にエディタ拡張などで都合が悪い場合もあるかと思います。その場合に役立つのがSimulation Scopeという設定です。Project Settings -> Device Simulatorの所で設定が可能になっています。

標準ではdefault assemblyにチェックが入っており、全ての実装箇所でAPIが上書きされます。これを外すと下のCustom Assembliesに設定した名前のasmdef配下でのみ上書きが有効となります。（ちなみに、ScreenクラスだけはこのSimulation Scopeの設定の影響を受けず、常に反映されるっぽいです。）

独自で定義した端末情報の追加

PreferencesにDevice Simulatorの設定があり、そこでセーフエリアのハイライト表示設定などの細かな設定が可能です。

そして一番上の項目ですが、独自で定義した端末情報を使う際のファイルの読み込み先の指定になります。Unityの管理外のディレクトリでも可能です。端末情報はjson形式で定義されており、必要な値を設定します。

{
    "friendlyName": "Sample Device",
    "version": 1,
    "Screens": [
        {
            "width": 1080,
            "height": 1920,
            "dpi": 450.0
        }
    ],
    "SystemInfo": {
        "operatingSystem": "Android"
    }
}

このjsonは.device.jsonという拡張子をつけて保存します。正しく設定されればDevice Simulatorの起動時にロードされ、選択肢に追加されます。

詳細なデータ構造は公式ドキュメントを参照してください。先述のScreenやSystemInfo、ApplicationクラスのAPIについて書き換える値も設定できます。 iPhoneやGalaxyといった公式側で定義されている端末以外の画面サイズやセーフエリアの検証を行いたい時に活用しましょう。

Adding Custom Devices | Device Simulator | 2.2.4-preview

おわりに

Device Simulatorを活用することで、実機で画面を見たり値を検証しないといけない場面の開発コストを削減することが可能です。このUIはセーフエリアに対応して、背景はフルスクリーンにして、といった実機ならではの検証も迅速にUnity Editor上で確認できるのは便利ですね。まだpreviewの機能ということで機能が最低限だったり、たまに挙動が怪しい場合もありますが個人的には期待している機能の一つです。

参考文献

この記事を書くにあたって参考にさせていただいた公式ドキュメントです。

Introduction | Device Simulator | 2.2.4-preview

【C#】開発を加速させる便利な定義済みRiderライブテンプレートの紹介【Unity】

Riderのライブテンプレート機能、みなさんは使っていますでしょうか？
自分はUnityの開発においてかなり活用していて、これなしでは生きていけない体になっているのですが、職場で思ったより活用されてなかったので紹介記事を書きました。
本記事はライブテンプレートの中でも予めRiderが用意してくれている定義済みのライブテンプレートを紹介します。

ライブテンプレートとは

ライブテンプレートはいわゆるコードスニペットのようなコードの定型を生成する機能になります。
ifやforといったおなじみの定型構文やプロパティの定義などの同じようなコードを量産する上でそれらを事前に定義したテンプレートにしたがって生成してくれます。 ライブテンプレートが強力なのが、テンプレート内の変数の扱いです。テンプレートの一部を変数にして定義することができるのですが、その変数について生成するタイミングでコードの文脈から任意の値を挿入したり、入力カーソルの位置をよしなに合わせたりすることができます。どういうことかよくわからないという方はこの後紹介しているライブテンプレートの挙動を見てもらうとわかりやすいです。

ライブテンプレートの定義はPreferencesのEditor -> Live Templatesで確認できます。

ここでテンプレートの追加や削除、編集が行えます。テンプレートごとにDescriptionが設定されており、ライブテンプレートを使ってコードを挿入したい時にはそのDescriptionを入力するとRider側から提示されます。

そして、ライブテンプレートには汎用的に使えるものとしてあらかじめRider側に標準で定義されているものがあります。今回はその一部で筆者が使っているものを紹介します。

C#の定義済みライブテンプレート

まずはUnity問わず使えるC#のライブテンプレートについて紹介します。基本文法に関するものが多いです。

for

シンプルながらも便利度が高いのがfor文のライブテンプレートです。

for文のスコープがささっと生成され、中身もいい感じに定義しちゃえます。

forr

逆順のforループが必要なことがあったりしますが、その時にはrを一つ多くつけると逆順のfor文を生成してくれます。

foreach

foreachでループを書きたい場合はこちらです。

prop

プロパティをささっと作れるのがpropというライブテンプレートです。getterとsetterを含めた定義部分を生成してくれます。

prppg

プロパティの定義でsetterだけprivateにしたいというのもよくあるパターンです。その際にはpropの後ろにgをつけてあげます。

個人的にはこっちの方がよく使うかなという印象です。

if

コード内の任意の要素を用いてif文を書くというのは何回でもあるケースですが、そんな時の実装の手間を少し抑えてくれるのがifのライブテンプレートです。

Unity用の定義済みライブテンプレート

Riderの強みと言えばUnityの開発に対する手厚いサポートです。ライブテンプレートについてもUnity用のものがいくつか存在します。

sfield

SerializeFieldでインスペクターから依存メンバをアタッチしたい！というのはよくあるケースです。sfieldは[SerializeField]のアトリビュート付きのprivateメンバを量産するのに活躍します。

log

Unityのデバッグ出力でおなじみ、Debug.Logを生成してくれます。Debug.Logで何かを囲みたいあなたにうってつけのライブテンプレートです。

logerr

Debug.LogErrorで囲みたい時はこちら

おわりに

いかがでしたでしょうか。普段繰り返しで書いているようなコードをパパッと生成できるので、積み重ねていくとそこそこの時間短縮になります。Riderを使っててライブテンプレートに触れたことない人はぜひとも触って欲しい機能です。この記事で紹介は定義済みのものの中でも一部しか抜粋していないので、全部確認したい方はPreferencesの設定か、この公式のリンクを参考にしてください。

pleiades.io

ちなみに今回はライブテンプレートについてRider側で定義済みのものを紹介しましたが、当然自分で定義することもできます。自分もUnityの開発およびプロジェクトの開発に便利なライブテンプレートをいくつか作成して活用しています。時間があった時にはこのオリジナルのライブテンプレートの作成についても記事を書きたいです。

【Unity】新しいInputSystemのEnhancedTouchで端末のタッチ入力を処理する

Unityの新しいInputSystemの機能であるEnhancedTouchという機能を使って手軽に端末のタッチ入力が処理できたのでメモです。

はじめに

本記事では新しいInputSystemの機能の説明や、導入手順などは省略します。
以下のリンク先が大変参考になりましたので、確認していただけると幸いです。（一番下のリンク先が公式ドキュメントになりますので、情報が多いです。）

【Unity】新しいInput System入門 - 従来のUnityEngine.Inputに代わる高機能な入力管理システム - LIGHT11

Unityの新しい入力システムInputSystemを使ってみる | Unityを使った３Dゲームの作り方（かめくめ）

Namespace UnityEngine.InputSystem | Input System | 1.0.2

検証しているツールとパッケージのバージョンは以下の通りです。

• Unity 2021.1.0b1
• Input System 1.0.2

バージョンによっては挙動が違うことがありますので、ご注意ください。

EnhancedTouch

EnhancedTouchは新しいInputSystemで端末のタッチ入力周りの情報の参照やイベント処理を行うための機能です。
EnhancedTouch.Touchを使うにはEnhancedTouchSupportを有効にする必要があります。

// UnityEngine.Touchではないので注意
using UnityEngine.InputSystem.EnhancedTouch;

// EnhancedTouchの有効化
EnhancedTouchSupport.Enable();
// いろいろな機能を持つEnhancedTouch.Touch
var touch = Touch;

一点注意なのですが、EnhancedTouchはInputSystemで入力のイベント処理を実装するための機能であるInputActionと併用ができないそうです。
本記事では紹介していない機能ですが、こちらを使う場合も多いと思いますのでお気をつけください。

さて、Touchはタッチ情報を格納しているstructで、タッチ入力について管理されている情報を参照できます。

void DebugTouch(Touch touch)
{
    // タッチの状況（BeganとかMoveとか）
    TouchPhase phase = touch.phase;
    // タッチの座標
    Vector2 screenPosition = touch.screenPosition;
    // タッチを始めた座標
    Vector2 startScreenPosition = touch.startScreenPosition;
}

ゲーム内のタッチ入力はTouchのstaticなメンバとして管理されています。こちらは読み取り用のpublicなプロパティが用意されています。

// 端末の処理できる長さのタッチ入力情報の配列
// 過去のタッチ入力の座標などがキャッシュされている
ReadOnlyArray<Finger> fingerList = Touch.fingers;
// 現在のタッチ入力情報
ReadOnlyArray<Finger> activeFingerList = Touch.activeFingers;


// イベント処理
// 指を離した時
Touch.onFingerUp += OnFingerUp;
// 指が触れた時
Touch.onFingerDown += OnFingerDown;
// 指を動かした（ドラッグ）時
Touch.onFingerMove += OnFingerMove;

void OnFingerUp(Finger finger)
{
   Debug.Log(finger.screenPosition);
}
        
void OnFingerDown(Finger finger)
{
    Debug.Log(finger.screenPosition);
}
        
void OnFingerMove(Finger finger)
{
    Debug.Log(finger.screenPosition);
}

ここで出てきたFingerはTouchの情報をまとめているclassです。座標や状態などの情報を保持しており、更新処理もよしなにやってくれます。

// 一番最後に触れたタッチ入力の情報を保持するFingerインスタンス
Finger finger = Touch.activeFingers.Last();

// 現在のタッチ入力の中での順番
int index = finger.index;
// タッチ入力の座標
Vector2 screenPosition = finger.screenPosition;
// 現在タッチされているかどうか
bool isActive = finger.isActive;
// 現在のタッチ入力情報（座標や状態は更新される）
Touch currentTouch = finger.currentTouch;
// タッチ入力の履歴(IReadOnlyList<Touch>)
TouchHistory touchHistory = finger.touchHistory;

タッチした座標や入力の数などに基づいて処理を行いたい時にFingerを通して情報を参照します。EnhancedTouchだとこういった情報をまとめて管理してくれるのでお手軽です。
入力情報の履歴の参照など、他にもいくつか機能があるので使う方は最初に紹介した公式のドキュメントを参考にしてみてください。

終わりに

とりあえずシンプルに画面をタップしたときの挙動を定義したい時にEnhancedTouchを使うとさくっと実装ができそうです。
まだまだ情報の浅い新しいInputSystemですが、いろいろな機能を探っていきたいです。

UI Builderを活用したUnityのUI構築

Unityでは最近UI Toolkitと呼ばれる新しいUIシステムの開発が進んでいます。
今日はそのUI Toolkitの一つであるUI Builderの説明とその使い方について紹介します。

UI Toolkitの構成要素

UI ToolkitではUIの要素を分解したいくつかのファイルによって構成します。見た目をUSS、レイアウト構造をUXML、ロジックをUQueryとC#、といった形で責務を分解して実装を行うのが特徴です。 名前からもそれとなくわかるのですが、USSがCSS、UXMLがXMLやHTML、UQueryがJQueryから着想を得ており、Webライクな設計となっています。 責務が分かれていることによって、従来のエディタ拡張で使われていたIMGUIの難点だったロジックとUI構成が一つのC#に入り混じって煩雑になってしまうという点が解決されました。 現在はエディタ上のUI実装でのみ正式リリースとなっていますが、将来的にはランタイムのUIの実装にもUI Toolkitを使うことが公式の展望として発表されています。

UI Builderによる要素の構成

UI Toolkitの要素の中でもUSSとUXMLは見た目の部分であり、C#とは別に実装を行います。もちろん自前でコードを書いてもいいのですが、そこで便利なのがUI Builderです。 UI BuilderはUI Toolkitにおける見た目の部分をGUI操作で作成することができるオーサリングツールになります。 Unity2020まではpreviewの機能でPackage Managerで提供されていましたが、Unity2021からは標準で使えるようになっています。 Package Managerから導入する場合はpreviewのpackageを有効にして以下の画像のpackageを入れてください。

導入するとメニューのWindow -> UI Toolkit -> UI BuilderからUI Builderの画面が開きます。

UI Builder

左のメニューでUIの要素の追加や選択をGUI操作で行い、右のインスペクターで選択したUIの編集を行います。 中央のプレビューは即座に更新が反映されるようになっており、Prefabの編集のような感覚で扱うことが可能です。 順にUI Builderの使い方について説明します。

UIの要素と階層構造（UXML）の作成

まずは要素の追加です。使うのは左下のLibraryです。

Libraryから追加したい要素を選んでクリック、または任意の追加したい場所にドラッグを行います。 試しにButtonを追加します。選択してクリックします。

真ん中のプレビューを確認すると画像のようにButtonの要素が追加されます。

そして左のHierarchyにも追加した要素が反映されます。 Hierarchyはその名の通りでUXML上で定義される階層構造を調整できます。

基本的にはLibraryからContainerに分類されている親となる要素を敷いて、その子にControlsと分類されている要素を追加していくのがよくある工程かなと思います。 また、Libraryには自分の作成したUIもひとつのパーツとして扱うことが可能です。LibraryのタブをProjectにするとAssets配下にあるUXMLを参照することができます。

似たようなUIや派生系のUIを量産したい時に、パーツごとにUXMLを制作してLibraryから参照することで制作の手間を省くことができるのはかなり嬉しい機能です。 また、UIを選択すると右のInspectorで名前といったパラメータや使うUSSの編集を行うこともできます。インラインで埋め込む装飾もここで編集してプレビューで確認できるのでとても便利な機能です。

こうして制作したUIの階層構造はUXMLに変換されます。下のプレビュー表示で確認が可能です。

後はUXMLとして作ったUIを保存します。上部にあるFileメニューのsaveからもできますし、ctrl + sやcmd + sといったショートカットキーでも可能です。 UXMLの名前と保存場所を入力して保存しましょう。以上でUIの要素および階層構造の定義となるUXMLが作成できます。

UIの見た目（USS）の作成

次にUIの装飾となるUSSの作り方を説明します。基本的には参照するUSSの設定と、Inspectorによる要素ごとの見た目の操作になります。 使用するUSSの設定は左上のStyleSheetsのメニューで行います。

左上の+ボタンから新しくUSSを作成したり、Assets配下にあるUSSを読み込むことができます。 USSの記述として装飾の効果の対象を表すセレクタの追加もGUIで行えます。 対象のUSSを選択して右のInspectorからセレクタの名前を入力してボタン一つで追加されます。

追加したセレクタはStyleSheetのメニューに反映されます。それぞれのUSSの下に表示されるので分かりやすいです。 セレクタごとの効果はInspectorで設定します。プレビューに即座に反映されるので見た目の試行錯誤はかなり捗ります。

そして、UXMLと同様に設定に合わせてUSSに変換されます。下のプレビュー表示で確認が可能です。

後はUXMLの時と同様に保存を行うとUSSが保存されます。 以上がUI BuilderでUI構築を行う手順になります。

最後に

UI ToolkitによってUIの見た目とロジックの実装を分離できるようになり、UI Builderを活用することでその見た目をGUIベースで構築できるようになりました。 まだまだUI Builderは発展途上なところもありますが、中規模な開発でUIの再利用や量産が必要な時には活躍する時もくるツールじゃないかなーと感じています。 UI ToolkitはUnityは力を入れて開発を進めている部分の一つでもあるので、今後の動きにも注目していきたいですね。

2020年の振り返りと2021年の抱負

あけましておめでとうございます。2020年は仕事にリアルにいろいろなことがありました。 2020年にやったことを振り返りつつ、2021年頑張ることを書いていきます。

2020年やったこと

Qiita投稿 1本

Unity Game SimulationによるUnityアプリケーションの高速シミュレーション - Qiita

Qiita投稿はこの１本のみでした。ちょっと怠けてしまったなー、という感じです。 ただ、この記事自体は結構自信があった内容で、記事を投稿した後にUnity公式の方からメールでお話をいただいたりしました。 Unity Game Simulationは結構可能性を感じる機能なので今後も注目していきたいと思います。

会社ブログ 2本

creator.game.cyberagent.co.jp

creator.game.cyberagent.co.jp

SGE(CyberAgentのゲーム・エンタメ系の子会社のグループ)の公式ブログにて2本記事を書かせていただきました。 今年はこの社内ブログの寄稿を結構頑張っていて、所属する子会社の技術ブログがなかったのを立ち上げたりしてました。 2本とも記事としてはなかなかガッツリとしたものが書けたのではないかなと思っております。

技術書典への執筆 2回

技術書典で「UniTips」というUnityの技術書を定期的に会社で出しているのですが、2020年も2冊執筆に参加しました。

creator.game.cyberagent.co.jp

creator.game.cyberagent.co.jp

Airtestによる自動テスト、UPRによるプロファイリングといったちょっとニッチな内容について執筆しました。 技術書典には「UniTips」立ち上げから本を出させてもらっており、昔に比べて技術を文章化する速度や精度も上がっているのを感じています。 今後も「UniTips」の執筆は続けていく予定です。後述していますが、個人的な本の執筆も予定しています。

CEDEC公募に挑戦

業務で色々と技術的に挑戦していることがあって、せっかくならこれを元に公募チャレンジしたい！と思って頑張ってました。 結果的には通らなかったのですが、公募の感触や社内で登壇経験がある人のヒアリングなど、得るものは多かったです。 もちろん全然諦めていないので、挑戦し続けていきたいです。

Rustを始める

色々と技術的に手広くなりたいなと思って、前々から興味のあったRustを始めました。 公式のチュートリアルから始めて、bitFlyerのcliを実装してみたり、簡単なAPIサーバーを実装してみたり、ゲームを実装してみたり、と実際に物を作りながら学んでいます。 特にゲーム作りで今は勉強を進めており、AmethystというRust製のゲームエンジンをよく触っています。

amethyst.rs

まだまだ初心者ですが、GitHubにもこっそり成果物を上げています。

github.com

2021年の抱負

アウトプット強化

これまでもQiita投稿、技術書典参加、会社ブログの執筆など色々とアウトプットを続けてきましたが、以下の点を2021年は頑張ろうと思います。

• 技術書典への「UniTips」の執筆継続
• 技術書典で個人的にRustの本を出す
• 個人ブログ蘇生、技術記事のアウトプットを2020年よりも増やす

大きいのは個人的に本を出したいという点です。「UniTips」の執筆を通じて得たノウハウを個人的な研鑽にもつなげたいと思ってRustの本を出してみよう！となりました。 技術書を出すことで知識精度をより高めたり、技術的な名刺になったりなどのさまざまなメリットがあるため、個人的にはおすすめなアウトプットの一つです。

また、この2018年から2年ほど更新が止まっていた技術ブログを蘇生したのも思い切った点です。 2020年色々な方のアウトプットを見たり、社内で活発にアウトプットされている方と話す機会があったりして、自分のアウトプットが定点的で見直さないとなと感じることが多かったです。 そこで、今年から技術ブログを蘇生して自分の名刺としてもアウトプットを積み重ねていくことにしました。記事も増やしつつ、より有益な情報をお届けできるよう頑張ります。

技術領域を広げる

自分は学生の頃から2019年までずっとUnity中心の勉強と業務を続けていました。 2020年になって社会人3年目ともなると仕事の幅も広くなり、Jenkinsおじさんになったり、自動のUIテスト環境を構築したりなど、Unity以外の知識を多く使うようになりました。 結果として自分の技術領域が狭く、もっといろいろな技術に触れた方がいいなーと感じる機会がかなり増えました。そこで、2021年には技術でやれることを増やす、という意識をしっかり持っていきたいです。 直近ではAirtestでの自動テストだったり、Rustの習得だったり黙々と勉強中です。アウトプットと絡めていきたいですね。

最後に

2020年は業務の幅も広がり、色々なエンジニアの方のアウトプットを目にしたりするようになって、色々と自分の活動を見直すいい年でした。 まだまだひよっこエンジニアですが、少しでも技術で世の中に貢献できるよう頑張っていきます。 今年もよろしくお願いいたします！