Ooh something I'm working on is on reddit. My day has come. Lmk if you have any questions related to the Riot Games API.
Ooh something I'm working on is on reddit. My day has come. Lmk if you have any questions related to the Riot Games API.
Ah, you made a mistake by revealing yourself my man, let's hope it doesn't bug out so we don't have to roast you... Good work, so happy this is coming out.
There are a couple teams involved in making TFT match history a thing. My team focuses on making this data available through the API so that community sites can make tools that are useful to players while still remaining conscience of the gameplay (hence some of the policy in the announcement).
We're aiming to have this data in the API soon, so we're sharing the schema but the priority will be making sure it's stable in the client before it gets added to the API. I'm happy we're finally getting match history as well, the TFT team is moving at an incredible pace from what I've seen. They got a lot of plates spinning and I'm just happy to help where I can to get the value to you all, the players.
I always wondered what big companies' APIs tend to look like. Is it like simply that you take the initial big dump of data, then ETL it into a separate database and format to process for stuff like match history, then ETL it further onto a different server for API purposes?
Do you instead just have 2 different APIs, one publicly available, and the other private, and both use the same kind of access points, and the same dataset, but with less security enforced onto your own client?
Oh there's a lot to this question, I'll try and his the high level parts. All good questions though.
I don't necessarily think there's one right way to do things, as in most of software engineering there are tradeoffs to everything so it really just depends on your circumstances/constraints to determine which path you take to creating an API. You might ETL all this data into a separate data store for the API if isolation is a concern. You might make two separate APIs if you need to. It all kind of depends on your requirements.
Theory first. I personally like it when the client or primary product uses the same APIs as as made available to the public and the only difference is the permission set (in something like OAuth this means scopes). In general, creating a product that is API first ensures that the API is never an after thought and the product is designed in way for the data to be sharable while still meeting the product needs. If you do take a different approach like ETL'ing the data. Not only do you have to maintain a separate system, you might not always have all the data you want in the format you want it. In general it greatly increases the maintenance cost but you do get complete separation/isolation from the live service.
Now for what we're doing with the Riot Games API. By and large, the APIs we expose through the Riot Games API are the same services we use in the game itself. We use the API as a proxy and protect the services with features like rate limiting, policies, blacklisting. For us the goal is to ensure the API has a superset of what is in the client. The API was born to alleviate scraping of the game client. Back in the day, community sites would create league accounts that logged in and looked up players. This was not only inefficient but also meant that it was taking up a spot on the game server that should be for an actual player. The API should have more data than the client because we want sites using the API and not scraping the client itself. When there are live issues, the first part to get shaved off is API traffic. This hopefully means players in game are impacted the least while third party sites are impacted the most. Then we can work to resolve the issue while hopefully keeping player impact to a minimum.
I kind of went in a couple different directions, but hopefully I gave you an idea of how we think of the API and data here at Riot Games.
hey rito tupedo why my match history always show im 8th
im gold 4 ffs
Hmm are you finishing in 8th?
Do you expect to add matchups/units/items/placement etc for each round- sort of like the timeline for SR- to the API?
Good question. If you read the article, we dive into some of the policy we're creating for community sites making tools for TFT. You'll notice a lot of what we talk about is how tools can start to change the way the game is designed to be played. At a high level, in the article, we discuss reducing diversity, giving competitive advantages, and making decisions for players. All these things are bad from a gameplay perspective so we want to make sure we're exposing data so that community sites can make cool things for players while also ensuring these policies are being adhered to.
Your question was asked in the Developer Discord and I responded there as well, but I'll paraphrase here. There's a reasonable concern that adding more granularity to match history will lead to negative effects on the gameplay. At the end of the day we want to expose as much data as possible, but never at the cost of the game itself. I keep telling all the API devs, help us help you. The policies are in place to preserve a positive player experience. The closer those policies are followed the more we become comfortable with exposing data that could have good and bad effects on gameplay. In a world where the player experience comes first, developers get access to all the data they need and they have discussions with our team to ensure the tool they're making doesn't create negative experiences for a player. And when we mean negative experiences for players, that ranges from experiences that make a single player less likely to enjoy the game to features that make the game less enjoyable over all (think everyone's only playing one comp).
EDIT: To specifically answer your question; maybe. We're thinking about it and we want to, but we have reservations about how it might impact the game.
I mean... doesn't obscuring the data just slow the problem at best? People will still do guides based on gut feeling, and their anecdotal evidence, even if they don't have 26000 games to back it up.
For instance, if starting with Noble 3, level 4, and a 2* unit, by the time you hit the first PvP round, leads to 78% of placing 4th and higher; I feel like at that point the issue isn't that people know going Noble first is better, it's that going Noble first is oppressive.
From my point of view, it'd be like hiding the upgraded items' effects until you complete them, since that way people build more diverse items. It creates a more diverse meta, but only until people figure out the hidden numbers.
We're kind of wandering out of my area of expertise here, you're asking game designer questions and I'm not the best person to ask about this. However, I think the goal is for products that use the API to promote diversity in games. There's a lot of area where we think community products can go a long way toward improving the player experience and that's where we'd like to see effort focused. There are some examples of this already; composition builders, the overlays with the rules of the game, apps that highlight the matches won, apps that show your ranked journey. These are the kinds of apps that extend the experience and make TFT more enjoyable.
EDIT: I want to clarify a bit after re-reading your question. I think players will always form an opinion of what's good and bad and likely stick to those decisions. There's nothing wrong with that. But if an app is sending a message to player that anything but Nobles is a mistake, that's an issue for us. We'd like to see the healthier version of this:
We see that you like starting Nobles, there are some other starting compositions that we'd suggest trying out.
*displays some alternative builds*
We see that you like running Nobles, did you know there are some compositions that counter Nobles?
*displays comps*
[deleted]
Same caveat as the other response I put here. We're kind of wandering out of my area of expertise here, you're asking game designer questions and I'm not the best person to ask about this. That being said the goal isn't to obscure this data, in an ideal world I'd like to see Riot be even more transparent about this. From my perspective, this isn't something I think we're trying to hide, a lot of the game designers are on Twitter talking about their thoughts on the current state of the meta. I think in an ideal world there's complete transparency about what's too strong and too weak, it's constantly updated, and there's an ongoing narrative about what the current state of the meta is and what's being done to balance the game. I think the team already does this but I'd personally like to see it done even more so. Like I mentioned before, the devs constantly talk about the balance and in the patch notes there's rational for what's changing (whether or not we as player agree is another discussion altogether). I think your concern, which aligns with my own, is that it's not done often enough. Which is fair but if we're being honest, a clear ongoing narrative of the state of the game is not an easy task to deliver on. I think the community tries to fill this gap, but it's not perfect. Most of the time it lacks context or it's based on an incomplete data set. As an example of context, I see sites that talk about the best 9 unit build. You might lose more games than win if you always try and force the best 9 unit build. As for incomplete data sets, sites might aggregate win rates from one region where one comp has a strong performance, but it'll often exclude another region where the same comp might be under performing (this happens all the time in League). I think it makes total sense that the community would like to have a sense of checks and balances on game design, but I think a lot of the time community stats actually muddy the waters when it comes to discussions about balance. I think that's kind of on us, because we don't provide a better alternative (but we should imo). It is in Riot's best interest to make a well balanced game. If there's an imbalance and we're hiding or avoiding it that only hurts the longevity of the game because it frustrates players. Being transparent about what work is being done to make the game more sustainable feels good. Knowing that the devs are aware of problems or imbalances is reassuring.
In short, I don't disagree that it may feel like we're trying to obscure imbalances. That's not the goal. The goal is always to have the best player experience. Trying to hide imperfections in the game would only hurt Riot. I don't think community stats are the best way to start a discussion on game balance. I think Riot should set that stage so the discussion is started with everyone looking at the same set of data with the appropriate context so that Rioters can have constructive conversations with the players. I see the devs trying to have these kinds of honest and open conversation almost every day.
https://twitter.com/Mortdog/status/1175074384337235968
Tentative patch changes
https://twitter.com/Mortdog/status/1174829014122319872
TFT - Looking at all the data again and seeing trends from a week ago to today. Pretty interesting we are seeing some dramatic shifts.
Here are some fun takeaways (all from high MMR games):
*Poppy's the current hot champ, more than doubling how often she's in winning comps
*Volibear is now the champ least likely to win
*Rangers are on the decline, but Kindred is on the rise.
*Leona is the biggest loser, appearing in winning comps 40% less often than a week ago. Pantheon also hit hard.
Will we have a match timeline kind of API for each round? Something like the status of each player on each round, like items on the ground, champions on the ground, champions on the table etc... This would open up a lot of possibilities for post-match guidance. With both automated and manual inspection.
Kinda answered this here, but tl;dr is maybe.