Multiplayer Use cases - Unity 6 update

[RikuTheFuffs]

Description

• Updated Multiplayer Use Cases sample to Unity 6
• Added TextMeshPro essentials
• Updated materials to most recent URP
• Removed obsolete packages
• Replace ParrelSync with Multiplayer Play Mode

NOTE: this PR is targeting main but it should target develop. However develop is currently behind main because of merge conflicts with the Distributed Authority sample, so we'll need to fix that first, then switch the target branch in this PR.

Issue Number(s)

• https://jira.unity3d.com/browse/MTT-7917
• https://jira.unity3d.com/browse/MTT-7918
• https://jira.unity3d.com/browse/MTT-8384
• https://jira.unity3d.com/browse/MTT-8707

Contribution checklist

• Tests have been added for the project and/or any internal package
• Release notes have been added to the project changelog file
• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• JIRA ticket ID is in the PR title or at least one commit message
• Include the ticket ID number within the body message of the PR to create a hyperlink

How to validate

1. Clone this branch
2. Open the project with Unity 6000.0.17f1
3. Check that no errors originate from the project's scripts
4. Open the tutorials window from Tutorials > Show tutorials
5. Go through all tutorials and check that they can be completed

[Elfi0Kuhndorf]

I discovered an issue within all the tutorials second step.
I cannot press Play as expected in this step unless I double-click the Game window to maximize it. :/ As you can see in the default view the play-mode Icon is grayed out.

Also using maximizing brings you out of the tutorial, so it is not possible to finish the tutorial because of that.

[Elfi0Kuhndorf]

Also I noticed that when maximizing the game window the UI on the right side is too small now ... that is something which should be changed (maybe I can do that after Unite and when I am back). It confused me because I thought I set it up in a way that it would scale with the size of the window, but maybe it does not work on Unity 6 for some reason :/

[Elfi0Kuhndorf]

Otherwise it looks good the functionality of all scenes works with MPPM as well.

[RikuTheFuffs]

I cannot press Play as expected in this step unless I double-click the Game window to maximize it. :/ As you can see in the default view the play-mode Icon is grayed out.

Nice catch, Elfi! Unfortunately, it seems that the issue is caused by the "Play mode scenarios" feature which "steals" the visual element class name of the Play Mode button (unity-editor-toolbar__button-strip-element--left , making the play mode button unity-editor-toolbar__button-strip-element--middle).

This causes the tutorial framework to no longer recognize it.

The problem here is that this means that any project with an IET that asks to enter play mode will break the moment a user installs the package that makes that play mode scenarios feature to appear (which is Multiplayer Play [email protected]. The issue is not there with 1.2.2). (cc @[email protected] , @johann-r-unity )

In fact, you can see that the Small Scale template doesn't suffer from this problem as it uses version 1.2.2 of MPPM.

I think we can solve this issue in 2 ways:

1. Manually change all tutorials so that they use unity-editor-toolbar__button-strip-element--middle too (together with the existing left), and tell users to do the same for their own tutorials before upgrading to Unity 6. The result would be this one when MPPM is NOT installed, if users used only middle:

and like this when it is installed:

2. Make a fix in the next version of MPPM, so that it doesn't add play mode scenarios in that place of the UI. (@johann-r-unity ?)

While (2) seems the most straightforward option here, it brings up the issue of "what if another package places something there too?" Should this be solved at an IET level? (@[email protected] )

cc @MorwennaG for awareness.

[RikuTheFuffs]

^ I tagged the wrong Guillaume, the correct one is @UnityGuillaume

[UnityGuillaume]

Unsure what is the most generic way to handle this, or even if the IET package should handle it, as this is in effect outside of the IET control (an external package modify the UI that was used to author the IET).

I think it should more be a general design rule to not modify existing UI element no matter what, as this could be a problem for other tool than IET? (automated tools that try to find the play button, or want to observe it for interaction etc.)

On the IET side, the only path I see is by relaxing the matching process to fallback on the "best guess" if a perfect match isn't found? The screenshot show that it does also look for the name Play, but as the class doesn't match too, it cannot find a perfect match. But since 2 out of 3 parameters match (name & type) consider it the best candidate?

We could offer a special case to select the Play button, but that seems like opening a can of worms (why only the play button and not other common element of the UI) so the "good enough match" system may be the way to go

[RikuTheFuffs]

@Elfi0Kuhndorf for the purpose of unblocking this PR, I made it so that both the "--left" and "--middle" classes are used to find the Play button. Could you re-review?

[RikuTheFuffs]

@hammerlerobi made me realize that we can solve this by using just the name of the play button (which is always "Play") and removing the classes entirely.

Side topic for @UnityGuillaume: in the red circle there are the "-+" buttons that allow you to add/remove elements from the Unmasked Controls list, but they're not correctly rendered in the inspector: they're rendered below the next control "Selector Type". That's an IET authoring tools bug, is it on your radar?

[UnityGuillaume]

@RikuTheFuffs looks like it wasn't reported in our bug list, added an issue for it, thanks.

[Elfi0Kuhndorf]

It works now!