Skip to main content
GameDev.net gamedev.net
🔒 Locked

MatchKit is up. Here's what it is, and what it isn't.

Feedback networking multiplayer
Started by kopritis404 Jul 14 at 9:33 PM 7 replies 500+ views
Original Post
kopritis404
kopritis404

MatchKit started as my BSc thesis and then my MSc thesis. When I finished, it went into a repo and sat there.

What it does

It's a service. Players join a queue, MatchKit forms the teams, and you send the result back when the match ends. Ratings update, match history is written, and the next match the queue forms is a better one. Three calls. REST and Server-Sent Events, so any engine talks to it.

What makes it different

Most matchmakers balance two teams by comparing their mean rating. That works until it doesn't. MatchKit treats team formation as an assignment problem and hands it to an LP solver, which evaluates the combinations instead of walking a sorted list and pairing as it goes. It looks for the best team combination, not the least bad one. That's the whole idea, and it's the part that came out of the thesis.

Who's building this

One person. I have a day job, and MatchKit gets my evenings. There's no company behind it, no team, no investors. Support is best-effort and it comes from the person who wrote the code, which is the good news and the bad news at once

So here's the deal I'm offering instead

I think if you pay for something, you should own it. I grew up buying games on discs, and a disc you own is a disc that still works. Plenty of those discs don't work now, because a server somewhere got switched off. I'm not going to build the thing I object to.

So MatchKit can be self-hosted. Docker Compose, on your hardware. The license is a signed file that the service checks locally — it doesn't phone home, because there's no endpoint for it to call. I can't revoke it, I can't meter it, and I can't see your usage. Neither could anyone who bought this from me.

And to say the obvious thing out loud: this is one person's spare-time project, so it might stop. If it does, the hosted service will eventually go away, because servers cost money. Your install won't. Anyone running MatchKit on their own hardware keeps running it, and I'll help you move over if you'd rather not wait and see how that goes.

As of today you can't do much, check the project, join the waitlist and wehn the pre-alpha launches (soon™) you can freely try it and tell me your opinion. (in the pre-alpha everything will be free)

Have a look: matchkit.dev

khawk

Looks interesting.

Have you created any samples or mini-games demonstrating how matchkit would be used? Throw them on a github repo or something? This may help both with visibility (github) and understanding the value, especially for indie devs. Also how would you compare benefits vs using Steam matchmaking?

I can relate to this part with GameDev.net and understand if things like samples and such are lagging in readiness:

One person. I have a day job, and MatchKit gets my evenings. There's no company behind it, no team, no investors. Support is best-effort and it comes from the person who wrote the code, which is the good news and the bad news at once

Admin for GameDev.net.
kopritis404
kopritis404

Have you created any samples or mini-games demonstrating how matchkit would be used?

I am currently doing exactly that. Because the goal is fro it to be a engine/framework agnostic tool, right now im making a unity sdk alongside with a demo using Photon, Fish-Networking and Mirror. I am hoping end of week to have some samples available

Also how would you compare benefits vs using Steam matchmaking?

The thing im creating isn't in the same scope exactly as Steam matchkmaking.
Steamworks offers lobies, friend invites, network stuff and actual multiplayer and network things. From what i have gathered the steam matchmaking is filter matching, you pick lobbies by region, mode, and a couple of extra fields.

I am creating Matchkit to help with the step before that. To find which players should be together based on ratings.
Also its not tied up to Steamworks, so it can work with every kind of server (since I don't touch the networking side). What it comes down to is: its just REST calls, presented in SDKs form (WIP).

khawk

kopritis404 wrote:

I am creating Matchkit to help with the step before that. To find which players should be together based on ratings. Also its not tied up to Steamworks, so it can work with every kind of server (since I don't touch the networking side). What it comes down to is: its just REST calls, presented in SDKs form (WIP).

A recommendation on this - in your docs show what a Steamworks (or other server) integration might look like. Help anyone interested understand where Matchkit fits in their solutions or as part of a broader multiplayer architecture. A short use case example type section with a flow diagram to illustrate is probably enough.

I'm a big fan of these types of homegrown, niche solutions, especially after watching the games industry gobble itself over the last 3 decades. I hope you see adoption and success.

Admin for GameDev.net.
frob
frob

As my own personal rule, I tend to prefer 3 times of reuse before I consider anything 'generalized' like that.

Build it once to work for a specific solution. The second time pull out all the things you used the first time, make constants into variables, parameters, and configuration, and make it work the second time. The third time again strip out all the stuff that was unique to the instance and further push changed items into variables, parameters, and configurations.

After it has been used 3 different times, with different settings and meanings and use scenarios, then it's ready to be expanded to even more use-cases. After that broader release there will be all kinds of new requirements and important options, variables, and scenarios that weren't considered before and need to get incorporated, but those first three uses are critical in identifying what is core and what isn't.

When I see products that are built and have never been used in finished projects, I have zero trust that they can do the job robustly. When I see they've only been used once or twice, I see them as a starting point but very likely to have serious, potentially fatal flaws.

kopritis404
kopritis404

Been thinking about doing co-op matchmaking next. it's a different problem than pvp, one team against the game, so there's nothing to balance against. What I feel matters instead is role coverage, a power band separate from skill, and whether someone actually finishes the run.

That last one isn't skill at all, its a separate metric. curious if that's something you'd want, or if its just me..

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.