Choosing a Web Service for Game Information
Navigating the API Landscape
Choosing an information provider
For a media library to be useful, it needs to have accurate and comprehensive information, but getting that information isn’t always easy. The search for a good resource went through several rounds, ranging from search engines to specialized API repositories and blog posts. It quickly became clear that there are two online sources that were broad enough in what games they list and the information they track: IGDB(Internet Game DataBase) and RAWG.
My goal was to make a library similar to Letterboxd - with basic facts about the game and contextual information on aesthetics and narrative. While at least the main “shelf” view is visually attractive by focusing on cover images. To get a more complete idea what might be helpful in picking a game to play, I asked for feedback from some potential users. They highlighted: age ratings, difficulty ratings, and listing high-profile game designers as being of interest. From this I realized I needed to emphasize the age ratings, and would need to research a way to get difficulty ratings.
Taking that feedback into account, I made a list of fields that I felt I needed to have along with some general areas which would be nice to include. This would soon expand to become the foundation for my database setup, and would be in a back and forth conversation with what I was learning about the API(s).
| Feature | IGDB | RAWG |
|---|---|---|
| Basic Information (e.g. Developer, Genres, Age Ratings, etc.) | Excellent coverage | Excellent coverage |
| Ease of Use | Excellent documentation, one endpoint with nested requests | OK documentation, multiple endpoints required |
| Additional information (e.g. times) | Limited time information, popularity metrics, several “tag” style fields | Limited time information, has one tag endpoint |
| Difficulty Rating? | No | No |
| Lists specific developers? | No | Yes |
Looking at the two APIs, we can see that both cover the basics very well. The deciding factor was ease of use, primarily the documentation. I’m not very experienced with APIs, so being able to quickly and easily understand what I’m working with and get functioning code meant I didn’t need to struggle with what for me was a less interesting aspect. While this meant losing specific developer information, the trade-off was well worth it for the time saved.
Getting IGDB working
After choosing IGDB I got an API key and started digging into the specifics of the documentation. Postman and a Collection of endpoints, meant it was easy to narrow down what I wanted to request and how. But that was just half of the battle, the other half was saving it in a format that I could use across the app.
While I won’t cover the details here, the process of cross-walking API responses to formatted database columns taught me about Abstract Base Classes. These are a valuable tool for organizing code and reducing redundancy, making the project more manageable and flexible for the inevitable tweaks to how an API is handled over time.
Downloading test listings also showed a couple of weaknesses the information IGDB had. The time a game might take is a critical factor in deciding if it’s workable but IGDB’s times were not very robust, especially compared to HowLongToBeat.com (HLTB). Also, while they have Tags there seemed to be a low-to-moderate signal to noise ratio.
Pulling in other APIs to flesh things out
Having good time information was critical, so I needed to find a way to get better information. There’s been an open request for HLTB to add a public API from over 9 years ago, but it doesn’t seem to be coming. Luckily for me an enterprising person put together a Python package which can work around this limitation, so I at least have a chance to get robust times. Because it’s unofficial results aren’t guaranteed, so I get IGDB’s times and only overwrite them if I get results from HLTB too.
To address the sometimes lower quality of tags, I could use information that tied the IGDB entry to a Steam store listing. Steam has user submitted tags which I’ve found to be useful in describing some of the aesthetics and thematic elements for games. By cross-referencing the IGDB result to a third party Steam API (SteamSpy), I could pull those tags into the listing as it was being saved.
This is a simple flow chart showing how requests were working at this point:
Lessons Learned
- Documentation is vital! IGDB did an excellent job by providing superb detail and related information all in one place-that really helped ease the learning curve, and cut down on development time.
- Spend the time up front to think through what information you need, what format it would take, and how you’ll use it. You will make changes, but careful planning can be the difference between small tweaks and completely rewriting a core functionality.
- Using several APIs had pluses and minuses. While it was more complex than I originally hoped, the quality and breadth of information that resulted was well worth working through coordinating several requests.
What’s Next?
Authentication to use the IGDB API was a challenge, next time I’ll go over transitioning from the test setup of just using my API Key through “device authorization” and finally using a saved set of listings as the default.
Photo by Jens Lelie on Unsplash