Unityでライブラリを使うには

本チュートリアルは今までと少し異なる用途を想定したものです。本チュートリアルではWindowsのみをターゲットとした.NETアプリケーションではなく、ゲームエンジンであるUnityEngine上でBaku.LibqiDotNetを利用する方法を紹介します。



1. Unityが利用できる環境

Windowsで32bitのUnity Editorを用いるか、MacのUnity Editorを用いてBaku.LibqiDotNetと連携した開発が可能です。

本記事以外の話題は基本的にWindowsに焦点を絞ってきましたが、Unityの場合はターゲットとするプラットフォームが広く取れるため、原理的にはラップ元であるlibqiがサポートされる全てのプラットフォームでBaku.LibqiDotNetとUnityを連携させたアプリケーションを動作させられます。

とはいうものの、パッケージの体裁として現状ではWindowsとMacのみがサポートされています。これら以外のOS(デスクトップのLinuxやAndroidなど)上でBaku.LibqiDotNetを用いたUnityアプリケーションを動かしたい場合でも、マネージライブラリであるBaku.LibqiDotNet.dllはそのまま利用できます。ただし、動作させたいOSに対応したlibqiのネイティブライブラリをUnityプロジェクトのAssetへ正しく配置する必要があることに注意してください。例えばUnityでビルドしたプログラムをLinux(Ubuntu)上で動作させたい場合、libqic.soやlibqi.soをはじめとするshared objectライブラリを配布されたNAOqi SDKなどからコピーしてくる必要があります。



2. Unity用ライブラリの利用

Unity用のパッケージファイル(.unitypackage)はNuGetでは提供していません。筆者がUnity向けにビルドしたパッケージをGoogle Driveに公開しているので、こちらからパッケージを取得してください。なるべく新しいバージョンを利用することを推奨しています。

Unitypackageの利用上のポイントは以下の3点です。

  • Windowsの場合32bitのUnity Editorを使わないとデバッグ実行が出来ません。
  • パッケージの導入方法についてはzipファイル内のreadme.txtに記載しています。
  • ライブラリの内容は基本的にNuGetパッケージとほぼ同一ですが、Macに対応するためにNuGetパッケージに含まれないフォルダを追加で持っています。


.NETアプリケーションと同様のライブラリを移植しているため、Unityに特有な機能は一切提供していません。


Unity向けパッケージに含まれるBaku.LibqiDotNet.dllはNuGetパッケージに含まれるBaku.LibqiDotNet.dllとほぼ一致していますが、下記の2点のみが異なります。

  • NuGetパッケージ版ではターゲットアーキテクチャがx86とされているのに対し、Unity向けパッケージではAnyCPUがターゲット
  • NuGetパッケージ版ではDllImportで指定するアンマネージライブラリ名がqic.dllであるのに対し、Unity向けパッケージでは拡張子のないqicという名前指定が使われている


とくにDllImportに関する設定の差により、NuGetパッケージのライブラリをUnityに持ち込んだり、逆にUnity用のライブラリを.NETアプリケーション用に使おうとしても失敗します。ご注意ください。


上記の差異が存在する理由も簡単に補足しておきます。

第一にUnity向けパッケージでターゲットアーキテクチャがAnyCPUとなっている理由ですが、これはWindows/Macの両方に対応するためです。Baku.LibqiDotNetがラップしているアンマネージライブラリがWindowsでは32bit、Mac版では64bitのみのサポートとなっているため、マネージドライブラリはAnyCPUターゲットであることが必須となっています。これに対してNuGetパッケージ版はWindowsでの利用のみを想定しているため、動作しないx64での実行を防ぐ目的でx86がターゲットとなっています。

第二にDllImportの参照先が変わっている理由ですが、これについてはUnityマニュアルにUnityに特有なDllImportの利用法が記載されているので、それに従っているだけです。



3. 把握済みの問題

Windows以外のOSでBaku.LibqiDotNetとUnityを連携させたアプリケーションを作成する場合、バイナリデータの送受信は(多分)できません。この制約は、Baku.LibqiDotNetがラップしている元のアンマネージライブラリであるlibqi-capiの機能が部分的に実装されていないことに由来します。

ただしWindowsに関してはソースからビルドし直して対策を行っているので同様の問題はありません。対策の大まかな指針についてはGitHubのissueに掲載しているので、他のOSでどうにかバイナリデータを扱いたい場合は参考にしてください。



補足: GitHubの最新ソースをUnity用にビルドする

上で書いたようにUnity向けのパッケージはビルドして配布されていますが、アンマネージライブラリ群をUnityパッケージから取得し、ライブラリ本体であるBaku.LibqiDotNet.dllについてだけ最新のソースを反映することも可能です。手順は次のようになります。

  1. Baku.LibqiDotNetのソースを取得する。あるいは手元でソースコードを適宜書き換える。
  2. ターゲットアーキテクチャをAnyCPUにし、構成をReleaseにする(※Debug構成でもいいですが動作速度などの理由からオススメできません)
  3. Baku.LibqiDotNetプロジェクトのプロパティでコンパイルシンボルとしてUNITYを定義
  4. ビルドする
  5. ビルド結果のうちBaku.LibqiDotNet.dllおよびBaku.LibqiDotNet.xmlをUnityのAssetに含まれる既存のファイルから置き換える


UNITYというシンボルを定義する理由ですが、これはソース中のDllImportSetting.csでコンパイルシンボルに応じてDllImport属性に渡すファイル名を切り替えているためです。推奨はしませんが、シンボルによる分岐を用いずソースファイル自体を手作業で書き換えることによって、参照先ファイル名を切り替えても問題ありません。