はじめに

NPO法人IGDA日本では、公益財団法人中山隼雄科学技術文化財団から助成を受け、株式会社サードウェーブデジノスの機材協力を得て、ゲームエンジンによる、コンピュータに支援された協働の体験を提供する「デジタルからくり装置作りワークショップ」を日本全国で実施しています。

参考：
⻑久勝、後藤誠、⼩野憲史
「ゲームエンジンによる、コンピュータに⽀援された協働の体験」
⽇本デジタルゲーム学会 2017年夏季研究発表⼤会、2017年9月2日

本ワークショップでは、Unityで作られた10面構成のコンテンツを、参加者が1面ずつ改造を受け持ち、Unity Collaborateを使ってリアルタイムで同期します。本稿では、ワークショップのためのUnityプロジェクトを作る上で技術的に工夫した点などを書いてみたいと思います。

Unity Collaborate

本ワークショップは「協働」をテーマにしており、参加者各自のワークの成果物を簡単にマージする方法が必要です。

昨年度は準備が間に合わず、gitを使ってマージを行っていました。参加者各自の担当部分をそれぞれprefabとし、コンフリクトが起こらないようにはしていましたが、UnityとSourcetreeの2つのツールを使うことになり、短時間で入門者が行う作業としては複雑すぎ、マージの頻度を下げざるを得ませんでした。

今年度は事前に検証する時間が取れ、昨年度のワークショップ運用の経験に照らして、期待する改善効果が見込めたため、Unity Collaborateを実戦投入しました。

現場での実際の使い方としては、キリの良いところまで作業して成果物を配りたいと思ったら、とにかくUnity Collaborateのボタンを同期状態になるまで何回か押せば良い、という簡単な運用で、上手く回っていました。これは、各自の作業がコンフリクトしないようにプロジェクトが作られている前提があったからではあると思います。

ツールを使い分けずにUnityだけで作業が完結できるようになったため、参加者の混乱も減りました。

精査できていませんが、タイミングによって、一時的にエラーが出ること（メッセージからはサーバ側でロックされているようでした。upload中はロックがかかるのでしょう）がありましたが、少し待って再試行すれば大丈夫でした。また、回線状態が悪い場合、サーバとのセッションが切れることがありましたが、再接続を促されるので、大きな問題ではありませんでした。

「各自の作業がコンフリクトしないようにプロジェクトが作られている」必要はありますが、例えばGameJam後半の量産と調整のフェーズに使うと便利かも知れません。但し、Unity Teamsに統合されて、無料でプロジェクトを共有できるのが3アカウントまでになってしまうので、まあ、なんか、考えないとなあ、みたいな。

エディタ拡張

昨年度は、参加者が、担当した面の基盤部分（床とか）を誤って移動させてしまったり、弄っちゃダメなとこを弄ってしまう問題がありました。要は、基盤部分を操作できないようにロックしてしまえば良いのですが、当初は、オブジェクトのプロパティをUnityエディタ上で設定して実現できると思い込んでて、ないなーと悩んでいました。これを実現するには、エディタ拡張が必要だったとゆーのが結論です。

LayerLock.cs

using UnityEngine;
using UnityEditor;

[InitializeOnLoad]
public static class LayerLock
{
    private const int layer = 8; // base

    static LayerLock ()
    {
        EditorApplication.hierarchyWindowItemOnGUI += OnGUI;
    }

    private static void OnGUI( int instanceID, Rect selectionRect )
    {
        var go = EditorUtility.InstanceIDToObject(instanceID) as GameObject;
        if (go == null || go.layer != layer)
        {
            return;
        }
        go.hideFlags |= HideFlags.NotEditable;
    }
}

レイヤーを1つ作って（レイヤー番号8番、名前はbase）、弄られたくないものは全てこのレイヤーに所属させます。

Unityは、ワークフローに合わせて積極的にエディタを拡張していくのが正しい使い方のようですが、ワークショップのユースケースでは、なるべく標準状態のUnityを使わせたい（参加者が興味を持ってUnityの勉強を始めることを考慮すると、使い勝手にギャップがない方が良い）ので、どこまでやるかのさじ加減が難しいですね。

Materials

ワークショップの回数を重ね、そのフィードバックから教材を改良しているので、参加者の作業効率も改善されていきます。このため、参加者が希望する作業の範囲も広がっており、オブジェクトのマテリアルを変更したいという希望が出るようになってきました。

昨年度のプロジェクト構成では、各面で使っているマテリアルは共有にしていたのですが、この構成では面毎の作業でマテリアルを変更できない（影響が他の面に波及してしまう）ので、マテリアルを面毎に別の物を参照するように変更しました。

SEとテクスチャは参照するだけなので、今も共有リソースとしていますが、各面の作業者が変更したいと思うだろうマテリアルとprefab（その面を構成するオブジェクト群）は、面毎にフォルダを作って管理しています。

版権もの

本ワークショップでは、お絵描きのワークショップも含んでおり、自分の描いたキャラクタを直ぐに自分の面に登場させることができます。以前からの問題認識として、子供たちが版権もののキャラクタを描いてしまうことがありました。マテリアルのテクスチャに版権もののキャラクタを使ってしまうという問題も出てきました。

正論としては、ワークショップ参加者に、著作権についての認識を持ってもらう必要があるのですが、短い時間で背景知識を含め上手く伝える方法が今のところノーアイデアです。理由を伝えずに単純に禁止することもできますが、ワークショップとしては、正しくないアプローチに感じますし。

ここは、どこかで上手くやってる事例がないか調査ですね。

さいごに

本ワークショップのUnityプロジェクトは、

mnagaku/sig4ng-ws

で公開されていますので、興味がある方は、是非触ってみてください。

また、本ワークショップは、日本全国で無償で提供が可能（講師の派遣も含め助成金で賄われます）ですので、ワークショップの実施に興味がある方は、是非、@mnagakuまでコンタクト頂ければと思います。

子供向けワークショップの教材をUnityで作った話