As a member of the Tech Team / Testing Team, I have access to future versions on internal servers. Since the rework of the message page was announced and then installed on the internal test servers, I have emphasized the importance of accessibility for third-party tools. Specifically, I advocated for a way to allow third-party tool developers to parse the data displayed in messages independently of localization, by implementing some kind of inline API through data attributes.
Previously, tool developers had to parse message text to identify the data within the messages. For example, to determine if an Expedition result is small, medium, or large, a tool would need to parse the text. Each result size has a set number of possible phrasings, so a tool could look for those and identify the size. The problem is that the tool needed to recognize every possible phrasing in every possible language, which was a tedious and complex task.
With the message page update, the inline API we requested was added to each message. Of course, it wasn't perfect or bug-free from the start. Since the update hit the internal servers, I have reviewed all possible messages and compiled a list of bugs and necessary changes. Gameforge did not include changes to this API (or any API) in the changelog (which should ideally help tool developers see if they need to adapt to changes), so I had to repeatedly go through this extensive list every time a new patch was installed on the internal test server. I did this to ensure that tool developers could easily adapt to the changes. My free time was devoted to testing the new inline API, updating the list of issues, and staying in touch with other tool developers to ensure nothing was missed. This effort left me with little time to work on my own tool, AntiGameReborn.
Things were progressing well, and the issues were being addressed one by one. I was optimistic that we would have a working inline API that met our requirements before the update hit live servers. However, someone at Gameforge decided the inline API was "good enough" and pushed the version with the unfinished API to live servers. As a result, much of the data was available in the inline API, but not all. For example, expedition results still need to be parsed through the text because the size isn't included in the inline API. Therefore, tools like OGame Tracker need to parse the results both through the inline API and the localization, which is why we still don't have a fix for the OGame Tracker.
After this debacle, and following some very firm feedback from players and tool developers, Product Manager WeTeHa posted a statement apologizing for the issues and promising that fixing the existing issues was a top priority. Upon reading this, I compiled an updated list of things that needed fixing, changing, or adding.
However, as it turns out, WeTeHa lied to us. It has been a month since this statement, and the issues still persist. We receive patch after patch, but none address the issues with the inline API.
Third party tool accessbility is not a priority and it has never been a priority. I remind you of the debacle of missing lifeforms in the spy report and combat report APIs. We got these added over a year after lifeforms release. This. needs. to. change.
As a third party tool dev, I request the following:
- Third party tool accessbility needs to be a priority. New features and every change needs to made with accessibility in mind. We really don't want to be required to burn the house every time new things are added so we get at least some sort of accessibility (mostly in an unfinished state).
- We need the APIs finished and ready on the PTS. And we need it to stay on the PTS for long enough so that we have ample time to adapt our tools. Currently, new features and APIs are added to the PTS in an alpha state. And once they reach a state that you could call "beta", they are pushed to live rounds. This is horrible for tool development because it means everything keeps changing while it's on the PTS (so you can't start adapting your tool), and then it hits the live rounds and you're under pressure to fix your tool as soon as possible because players keep complaining.
- We need changes to data structures, endpoints and APIs to be visible in the change log. Tools depend on these and we need to be able to see in the change log if we need to adapt our code.