Posted on Leave a comment

A diary on working with third party code

There comes a time for every developer when they must work with code written by somebody else. Some times it’s voluntary. Say for instance there is a useful library the developer wants to use instead of writing all the code themselves. Other times, it’s not. Like when a new developer joins a project already in progress. The example in this post is of the former.

I was recently working with a Unity plugin which enables easy development of 2D environments. Given that Unity is a 3D engine having a framework for 2D scenes is useful and speeds development. The team unanimously decided to use an existing plugin instead of building one in-house. We immediately started building the game around this framework. However we did have to pay a small fee.

A couple of days later came a surprise. The developer of the library released a major update. Version 2.0! Given that we had purchased the library less than a week before, we tried contacting the developer to find out if we could get the upgrade for free. We were a little concerned with the response, or lack thereof. We didn’t receive any response at all. Not a yes, not a no, nothing. Not a big deal, we still had version one to use.

Fast forward a few weeks, and then comes an issue. It turns out there was a bug in the library affecting sprites inside a scaled parent. I was able to fix the bug, but only by introducing another issue. Any sprite not in another object moved. I then found out the new version of the plugin fixes the bug among other new features. However, since we had not heard back from the developers it would be a paid upgrade for us.

In the end we bought version 2 of the library only to find out it introduced the same issue my fix did.

Anyway, there is no real lesson to learn from all this. It’s just one of the many issues we dealt with during development.