Third-Party Development

{Editor’s note: Eric will be occasionally writing technology pieces for the blog here. He also maintains a piece of software that third party developers can modify via plugins.}

 

Sometimes, being a third party developer is an interesting position to be in. Without these devs, the only software or features available either comes from the source itself or a directly licensed source very close to the original company. While I certainly wouldn’t call myself an amazing innovator, it’s hard not to see the great things that can come from this openness. For example, take a look at the early phone systems before and after they had to share and allow “unofficial” devices on the lines. We had rented answering machines (which were slow to appear at all), rented phones of only a couple of designs, etc. The phone companies had no real interest or incentive for seriously moving ahead in development. Third parties, however, did – they were all competing in the same space and so keeping things cheap(er) and adding new features that hopefully nobody else had just yet. Microsoft doesn’t provide more than a fraction of the amazing array of software (both good and bad) available for Windows… And this is a good thing, allowing many different new ideas and new takes on old ones to grow. Recently, a project I maintain broke down and quit providing good data. This project provides a searchable database of user created space on a long-running MMO. This is achieved by running a data-scraping bot around the various maps and collecting all the required information. This is something that could be provided by the owners of the game far easier than I because of their direct connection to the database, but as of yet hasn’t been. This leaves opportunities open for other developers to step in – the search service I maintain or addon applications that hook into the process space of their target app to expand its functionality well beyond what the original programmer had envisioned, for example.

Because the protocol the game uses is a mostly ASCII-based stream with all the characters in printable ranges, the easiest way to pull data out of the system is through general regular expressions built to parse and split out each line of information going through. To avoid problems, this usually means that each expression is set up to conform to the protocol standard as tightly as possible to avoid any accidents. Random unannounced changes tend to break things, unfortunately!

In this case, the game company added a new (which is still as yet unexplained) parameter next to the end of a standard player-space related protocol line. Their own client’s parsing rules are far more lax – which is handy for them, as it allows them to add extra things that haven’t been fully implemented yet without breaking everything else, but that makes dealing with it from the outside quite a bit harder. Most likely it also makes it harder for them to maintain when they do add things, but I don’t have any real proof of that, just personal experience.

In this particular example, the required modification turned out to be simple – add the extra space-delimited parameter to the regular expression and make sure that the application continued to pull the correct matching groups. After that was done, the data-gathering system was able to continue without a problem or further modification. It hasn’t always been that easy, though! Sometimes it’s required completely re-reverse-engineering the required protocol lines, though luckily this sort only actually happens along with the release of a full new client version. The real problem being a third-party developer is in communication, especially related to keeping up with developments on the service’s side. If a service provides a known and documented API, development can be easy… if at the whims of the service. For example, Twitter can be extremely arbitrary in regards to their API access keys and more than a few alternate clients have suddenly found themselves shut out as Twitter decided it wanted to move into the niche previously held by that particular client or service. In this case, although the small company in question occasionally makes a lot of enthusiastic sounds about supporting third party developers, any actual releases of information are few and far between – especially when it might relate to upcoming features. About the only outside devs who get documentation at all tend to be what might be best termed as second party. As there are no real official protocol documents to speak of – though there have been a few excellent efforts by other third party devs to document the thing – everything has to be reverse engineered. Finally, there certainly isn’t any sort of blog or other central place warning developers about impending change. This is hardly unusual in the modding scene, but a lot of those are simply tolerated by the original developer more than anything else, and no claims are made about working with third parties to encourage them.

Minecraft is a great example of this, actually. They intend to support third party devs more than they currently do (the near-mythical modding API, for example) but at this point mostly turn a blind eye to all the major modifications made to the server and client by editing them directly. Without all that external support, Minecraft probably wouldn’t have turned into quite the behemoth it is now – or at least, not half as fast. A large percentage of online players either mod their clients or play on modded servers. (Sometimes both!)

In short, there are definitely pros and cons to being a third party developer, especially when you’re not working with a stable, well documented platform. But I’d never give it up, because it opens up so many possibilities.

spacer

Leave a reply