walk me through something on the Matchplay sample project?

[frozen obsidian]

Whats happening here is that startingGameInfo has some default settings that is passed in from the application controller. The Matchmaker will override those default settings if a match is found. If no match is found it will just continue on with those default values

[quick cypress]

how does that affect what happens when the application tries to create a ticket though? I might be misunderstanding Matchmaker, but ultimately that data is passed to Matchmake in this wrapper class (https://github.com/Unity-Technologies/com.unity.services.samples.matchplay/blob/0225d6c89a5f951350609921607457324d8f847c/Assets/Scripts/Matchplay/Client/Services/MatchplayMatchmaker.cs#L41)

my understanding was that this shouldn't work when running on a local server, since matchmaker requires a multiplay DBS

The project overview touches on this:
The server will attempt to find services for 5 seconds, and if it can’t, it starts the server with some default settings for local testing. The client can directly connect to this server using the local host ip
But I don't really see where this is done through the GameInfo object that gets passed around

[frozen obsidian]

if you are running locally(or matchmaker fails), in StartGameServerAsync, the matchpayload will return null. in that case it just starts the server with the local IP and port settings

[quick cypress]

Right so I get that that's what would happen when you spin up a local server. But for the client to connect to it (ie BeginConnection to be called), a successful result would have to come back from GetMatchAsync and Matchmaker.Matchmake in the ClientGameManager (https://github.com/Unity-Technologies/com.unity.services.samples.matchplay/blob/0225d6c89a5f951350609921607457324d8f847c/Assets/Scripts/Matchplay/Client/ClientGameManager.cs#L124). How can it be possible for Matchmaker.Matchmake to return a MatchFound result if the MatchmakerService has failed?

would help if there were any docs on the MatchmakerService methods 😦

[frozen obsidian]

Yea. the client side does not automatically fail over like the server does. The client has to explicitly select local mode. I hate how this project is setup so much.
The actual Matchmaking API is here. https://docs.unity.com/matchmaker/en/packages/com.unity.services.matchmaker/1.0/api/Unity.Services.Matchmaker.IMatchmakerService

[quick cypress]

hey, thanks for this, very useful link.

I'm using this project to try and wrap my head around how to implement Matchmaker in a way that still allows for local testing, and you're right, it seems so over-engineered. Less of a sample project and more like the engineers got carried away

do you have any recommendations for a good resource that walks through setting up Matchmaker? It's so hard to find any content for the newer packages, especially ones that don't rely on P2P.

[frozen obsidian]

the actual sample in the package manager isn't bad at all. also in the main docs its short and sweet.
https://docs.unity.com/matchmaker/en/manual/use-the-matchmaker

well damn. My video might be the only one on UGS matchmaking
https://www.youtube.com/watch?v=yUoxYOMzwx8&t=2s

[quick cypress]

I like the main docs, but obviously assumes you're running on prod with Multiplay setup, which is annoying

I hadn't thought to take a look at the package manager sample, that's a great shout, I'll work through that instead. The matchplay sample is doing my head in

[frozen obsidian]

also keep in mind the only way to use Matchmaking right now is through Multiplay

[quick cypress]

Yeah I'm set on using Multiplay, happy with the workflow - it's just more important to me to get setup locally first so I can start developing without building anything just yet

My plan is to get that setup and then work through your vid, had a quick skim now, just what I was looking for!!

Your pacing is great, big fan of the longer-form content

[frozen obsidian]

lol, thanks! Honestly been thinking about how to them shorter

even ones I try to make quick I end up rambling for an hour

[quick cypress]

more focus part-series might be the way to go for that. Like part #1 going through the Matchplay build, etc etc

You would defo get more engagement that way - although personally I always find the longer vids most helpful. There's an Unreal tutor with a 5-hour video that teaches you more about Unreal than every "Get started QUICK with Unity!!!" guide combined haha

you mention in the comments for the vid that you don't particularly like the bootStrap setup in the Matchplay project - could you elaborate? Do you have an idea of a more appropriately engineered way to automate routing to a local server, so that locally testing a project with a Matchmaker dependency isn't such a pain in the arse? 🥲

[frozen obsidian]

well, on the client side you just have to wait for the match ticket to fail then just connect locally.

or you could check the authentication service if the user is not logged in then connect locally

[quick cypress]

this makes sense, but wouldn't want production clients to try and connect locally in the event of a failing ticket. Part of me wants to just hash-if UNITY_EDITOR when a game is being searched for

[frozen obsidian]

I'll sometimes just use a DEBUG bool to bypass connecting through Relay/Lobby for testing in ParrelSync

[quick cypress]

I think this is what I'll do. Might not be the cleanest flow control but I just want to get something running first

Just so I can understand exactly what needs to be ignored for local testing: the only thing that requires a Matchplay build is Matchmaker, so I can still safely init UGS and Authentication, ie it would work the same locally? (I assume so based on the Matchmaker sample project)

[frozen obsidian]

Yea. that's all fine.

[quick cypress]

And for replicating what Matchmaker does locally, what would that look like? I would have to:

• Spin up a server instance
• Start 2 clients (assuming thats the max players for a ticket) - how should I handle queueing them up together? Immediately linking to the server as soon as a client presses "Start queue" feels like bad practice. How can I replicate the functionality of waiting for a "successful ticket" response before connecting both clients to the server?

[frozen obsidian]

for the client, all the match ticket gets you is the IP and port to connect to .

for the server, that depends on if you are using the match payload or not

You might be able to fake it with Lobby Data but thats a whole other thing to set up

[quick cypress]

Fuck that, lol

I just need to figure out exactly what it is the server needs from the matchmaker payload to start a game. If I can (locally) wait for any 2 clients to connect, then just mock-up that payload, I'll be sweet

for another day, it's almost 2AM here 😮‍💨

[quick cypress]

@frozen obsidian figured this out in the end