自己紹介

どうも、自分の中でゲームクライアントエンジニアからゲームクリエイターに転職した大学生です。
自分の好きなものを作るぞ！！という感じです。

経緯

といっても、技術開拓が好きな俺氏新作ゲーム制作にRuntime UI Toolkitを使いたいと思ったので、今回は公式サンプルのUI Toolkitの設計を読み解く記事です。
uGUIと比較しつつコードリーディングの手助けを出来ればと思います。

注意

あくまで、個人的な意見も含まれています。

１．MVPのPresenterはPureなC#

uGUIではPresenterはMonoBehaiourを継承することが一般的でした。
一方で、UI ToolkitではPureなC#を使うようです。

理由の考察

理由としては、Presenterに対応する~~UI DocumentコンポーネントからQueryしたUIを渡す~~Viewクラス（QuizUではScreen）を渡す必要があります。
uGUIではGameObjectとしてUIが存在したので、そこにアタッチする形でスクリプトとUIを紐づけることが出来ましたが
、それが難しいということですね。

加えて、PureなC#にすることでコンストラクタを利用でき、初期化漏れを回避することができます。

（追記）Viewについて

以下の２で説明するScreenというものがViewの役割をしているようでした。
そのため、理由の考察部分は間違えていましたね。

ViewにVisual Elementを渡し、そのViewをPresenterに渡す形が正解のようです。
その初期化のためにUIManagerクラスが使われているようでした。
（UIManagerクラスはCanvasGroupの役割を担っており、全体のオンオフも行えるようになっています。）

２．基底クラスの製作

uGUIでも、以下のような基底クラスを使うことはよくありました。

UIManagerBase.cs

using UnityEngine;

[RequireComponent(typeof(CanvasGroup))]
public class UIManagerBase : MonoBehaviour
{
    [SerializeField] private CanvasGroup _canvasGroup;
    
    public bool IsActiveSelf { get; private set; }

    public void SetViewActive(bool isActive)
    {
        _canvasGroup.alpha = isActive ? 1 : 0;
        _canvasGroup.blocksRaycasts = isActive;

        IsActiveSelf = isActive;
    }
    
    #if UNITY_EDITOR

    private void Reset()
    {
        _canvasGroup = GetComponent<CanvasGroup>();
    }

    #endif
}

そして、UI Toolkitでも同様の基底クラスを制作すると便利のようです。
「QuizU」ではUIScreenとして定義されています。

３．イベントの管理方法

『QuizU』では静的なクラスのActionに登録して、それをEventRegistryクラスのインスタンス化して登録するという手法を使っていました。
ほかのライブラリの話になりますが、やっていることはMessagePipeと近い形です（どこで渡されているか分かりにくい）

ただ、EventRegistryクラスはイベントを一気に解除することができとても良い方法だと思いました。

まとめ

事実ベースで短めにまとめました。
基本的にPureな環境でUIを表示・非表示することができて、Pure C#過激派からするととても嬉しいかもしれませんね。
『QuizU』凄く良かったので、まだまだコードリーディングしたいと思います！