The Renegade Coder – Code First. Ask Questions Later.

As the days grow closer to my first step on campus, I've decided to continue exploring different research topics that I find interesting. Today, I want to focus on matchmaking systems. Core Idea Often times in video games, a system needs to be developed to organize teams of players for competitive and/or cooperative play. We call this matchmaking. Matchmaking can make or break a player's experience with a game. Of course, these issues are only magnified in ranked play and in games which are more team-oriented. As a result, it is very important that these types of games have an excellent matchmaking system. My goal with this research would be to create a more comprehensive matchmaking system which could properly create balanced teams in a reasonable amount of time. Currently, I find that matchmaking systems do a great job of creating teams of similar skill level, but there are plenty of issue to still be solved. Inspiration I first became interested in matchmaking systems sometime in May after becoming frustrated with Overwatch's matchmaking system. In general, I feel that Overwatch's matchmaking system is good, but it has a couple critical issues: Player Responsibility Let's say that I get into a game with someone who is either a thrower or is easily tilted. If I report that player, I would expect to not play with them again. However, I've found that if I queue up immediately after the loss, there's a solid chance that I'll be on the same team as that player in the next game. In fact, I've been paired with the same thrower three games in a row on multiple occasions. As a result, it seems that players are then responsible for controlling their own destiny. In other words, since the matchmaking system fails to separate you from the thrower, you're stuck waiting some time before queuing up again. In my opinion, this is a major drawback because I'm more likely to just stop playing than wait 10 minutes to queue up again. I have to imagine Blizzard likes to retain their players, so matchmaking could definitely use some improvement. Unbalanced Compositions Another Overwatch matchmaking topic I take issue with is the system's blatant disability to form balanced team compositions. In Overwatch, you can play one of three roles: tank, DPS, or support. In general, you want to keep a balanced team composition of 2 tanks, 2 DPS, and 2 supports. Of course, every so often the meta allows for a different distribution of roles, but generally two of each is ideal. Unfortunately, Overwatch's matchmaking system doesn't seem to take in player history when creating teams. As a result, it's common to be on a team where more than three players want to play DPS. In many cases, this results in a tilted team and a guaranteed loss. In general, I find that unbalanced compositions make for a much worse matchmaking experience. If teams were more balanced, I would imagine the mid-tier games would be much less painful. Existing Research Unlike Augmented Reality Music Education, there appears to be a ton of research and patents in the realm of matchmaking systems. Of course, I suppose that makes sense because matchmaking is an important component of many popular videos games. At any rate, here's what I could dig up related to matchmaking: Multiplayer video game matchmaking optimizationMultiplayer video game matchmaking system and methodsImproving matchmaking with game dataVideo game with matchmaking based upon denial of communicationsEOMM: An Engagement Optimized Matchmaking FrameworkDeveloping Game-Structure Sensitive Matchmaking System for Massive-Multiplayer Online GamesEngagement effects of player rating system-based matchmaking for level ordering in human computation gamesAdaptive matchmaking for games As you can see, there's plenty to read in the realm of matchmaking systems. Risk Assessment In order to evaluate risk, I'll be using the SMART framework: Specific, Measurable, Achievable, Relevant, and Time-Oriented. For each section, I'll give the project a rating out of ten before averaging the score for an overall assessment. Ultimately, I'd like for my ideas to have scores as close to ten as possible. Of course, I won't sweat it if they don't. I'll just scrap the idea or refine it later. At any rate, let's check out the breakdown: Specific (7) Currently, I believe the area of interest is very specific, but the project is open to interpretation. After all, what exactly do I plan to do to improve matchmaking systems? Until I read up on the area, I may not be able to answer that question exactly. That said, I do have concrete issues with current matchmaking systems that I believe can be improved. As for the solution, that requires a bit more reading and planning. Measurable (9) Because matchmaking deals with people, data would have to be people-oriented. In other words, a large portion of this project would go into tracking user satisfaction. In terms of user satisfaction, measurements could either be taken directly by asking users or indirectly by tracking usage. Of course, I'm sure there are other variables that will need to be monitored. Perhaps I'll update my risk assessment as I get more comfortable with the subject. Achievable (7) Unlike the Augmented Reality Music Education project, I think there's a lot of technical depth to cover in the matchmaking subject. As a result, I could probably benefit from a single specialized adviser—rather than a pair of co-advisers. That said, collecting matchmaking data would be much more difficult. While I could simulate players, the data wouldn't be organic. As a result, I'd have to somehow test the matchmaking algorithm using an existing framework with thousands of real people. That could be a major challenge. Relevant (10) Personally, I think the topic is relevant because matchmaking impacts me directly. Of course, I don't see online gaming going anywhere soon, so I suspect matchmaking will matter for awhile. Time-Oriented (5) To be completely honest, I'm not entirely sure what the typical scope is for a PhD research project as I've never conducted research. This is a knowledge gap that I plan to cover early on in my studies. That said, this type of research would increment on an existing design, so I suspect that it would be well within the scope of a typical PhD research project. Overall Assessment (7.6) If we take the average of all the scores, we get a healthy 7.6 out of 10. All things considered, I'm quite comfortable with that rating. As I fill my knowledge gaps, I imagine I'll be able to close in on that 10. Well, that's it for this project. If you like the idea, let me know in the comments. In addition, feel free to critique my ratings if you have a better feel for the area than me.

Welcome to The Renegade Coder, a site for people interested in Python programming and college teaching! Join me on Patreon for even more content.

Latest Articles