However, I think the goal is for products that use the API to promote diversity in games. 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. We're thinking about it and we want to, but we have reservations about how it might impact the game. 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).ĮDIT: To specifically answer your question maybe. 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. The closer those policies are followed the more we become comfortable with exposing data that could have good and bad effects on gameplay. The policies are in place to preserve a positive player experience. I keep telling all the API devs, help us help you. At the end of the day we want to expose as much data as possible, but never at the cost of the game itself.
There's a reasonable concern that adding more granularity to match history will lead to negative effects on the gameplay. Your question was asked in the Developer Discord and I responded there as well, but I'll paraphrase here. 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. At a high level, in the article, we discuss reducing diversity, giving competitive advantages, and making decisions for players. 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. If you read the article, we dive into some of the policy we're creating for community sites making tools for TFT. 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. Then we can work to resolve the issue while hopefully keeping player impact to a minimum. This hopefully means players in game are impacted the least while third party sites are impacted the most. When there are live issues, the first part to get shaved off is API traffic. The API should have more data than the client because we want sites using the API and not scraping the client itself. 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. Back in the day, community sites would create league accounts that logged in and looked up players. The API was born to alleviate scraping of the game client. For us the goal is to ensure the API has a superset of what is in the client. We use the API as a proxy and protect the services with features like rate limiting, policies, blacklisting. By and large, the APIs we expose through the Riot Games API are the same services we use in the game itself. Now for what we're doing with the Riot Games API. In general it greatly increases the maintenance cost but you do get complete separation/isolation from the live service. 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. If you do take a different approach like ETL'ing the data.
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. 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). It all kind of depends on your requirements. You might make two separate APIs if you need to. You might ETL all this data into a separate data store for the API if isolation is a concern.
TFT ACCOUNT TRACKER SOFTWARE
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. Oh there's a lot to this question, I'll try and his the high level parts.
0 kommentar(er)
