I love programming videogames. It has always been my dream, my passion and now that I have fulfilled my dream, I want to spend as much time as possible doing so. I describe myself as a gameplay programmer and I love programming the game “itself”, so maybe that is why I do not like writing my own plugins for accomplishing low-level tasks.
For example, managing InApp purchases. It has little to do with the gameplay of our games, and it is a task I always try to avoid. In our Unity games we have the usual set of InApps available, we do nothing fancy, nothing special… Why should I lose too much time implementing InApps in the way that Android and iOS want, if I can find good and reliable plugins in the Unity Store that do this for me?
I do not deny it is necessary to understand (to some extend) the technology that plugins allow you to use. Obviously, you need certain knowledge of what you are doing, but you really should not be aware if google renames some of his Google Play Services API, or if the current version of InApps is 3.0 or 2.0.
Look at this from the economic point of view. Let’s hire a video game programmer who earns 2000$ a month. We want him to integrate InApp purchases from the scratch into our game. He works 40 hours a week, so his salary per hour is 12.5$. There are some plugins in the Unity Store that cost 50$ per platform and integrate inApps in a very easy way. So, will our programmer be able to program a whole new system from the scratch in 8 hours? Obviously no, and not by a long shot.
Everytime I discuss this with someone who likes to have full control of everything, and does not use any plugins, the discussion always reaches the same point. The point where the sentence “but if I write it myself I will make a system more suited to our needs” comes into play. My answer then is always the same: “I absolutely agree with you”. I am sure that a homemade system will adapt better and do exactly what you want, and nothing else, but what about the cost? Is it really worth it?
In addition, we are not taking into account that normally those plugins are made by people who are more skilled than us in that specific field. For example, NGUI. I always use NGUI in my Unity projects because I don’t like how Unity’s native GUI system works. If you have worked with it, you probably know how skilled NGUI’s creator is (he was hired to work at Unity to replace the whole gui system for a completely new one). It is very naive to believe that we can do a better system than him, when I mean better, I mean draw call efficient, memory efficient, easy to use, multiplatform, etc.
We also have to add the “testing factor” into the equation. Those mass-used plugins are tested by a lot of people daily, and they are virtually bug-free. Our little-but-cute system has to be tested thoroughly and can fail any time.
On the other hand, there are always drawbacks of using a plugin. Some parts may be difficult to integrate in your code, maybe they do more things than you need or less, but in general, I am very keen to use one if it can save me time and work, even if I have to adapt to some limitations, specifications that external plugins may have.
Quim Garrigós, lead developer (+QuimGarrigos): Create plugins from scratch
I have been working as a developer for more than 16 years and I have faced this problem many many times. When I decided to use an external library for some task most of the times it has resulted in a bad decision. After so many headaches now I usually tend to develop my own plugins even before trying other libraries for the same purpose.
Of course, I do not like doing tedious tasks such as implementing the in-app payment system for every store where we publish the game, but I have learned I can finish it before if I do it by myself. Back in 2011, when we first published a mobile game, Google had just released the IAP for Android Market, we tried an external plugin that was not cheap. It was poorly documented and after taking a lot of time to learn how it worked and how to integrate it, we discovered it crashed in a closed part of the code. The original developer never responded our queries and we gave up using that plugin. In the end it was all a waste of time and money.
Usually plugins, specially big plugins, have a lot of features and flexibility to be suitable for all different use cases. That means two things: bigger size for the final build and compromised performance due to some features you will never use.
No matter how big is your plugin you will always find that it lacks that unique feature you need for your project. You may be close to the end of the development but you may be forced to rollback using that plugin because it is impossible to do that simple thing you need with it. In some cases, if you have the source code, with luck you can try to dive into hundreds of lines of code to change it. If you do not have the source code, you can ask the developer to help you, but that will surely add some delay to your project.
Plugins may be so complex that integration time may last more than implementing the feature by yourself. Most of the times an amateurish documentation does not help, or there is not a community built around the plugin to answer your doubts.
You can easily have a higher cost in development time by using a plugin than implementing it. That is the case of wrapper plugins like IAP. Why learn how to implement a plugin when doing it using the API takes exactly the same time?
Imagine you have a really big project done with NGUI and for some reason you have to change it to another system. In that case the cost of change may be very very high like almost starting the project from scratch. If you used “standard” methods instead, you may be lucky and you will not have to change a line.
Using game engines itself is an extremely clear example of this. You can develop a game with Unity, you will be fast doing it for sure, you will have support for a lot of platforms and a lot of features. But your game will have some extra Mb in size and a poorer performance than other native languages. And maybe you need to publish your game for a platform Unity does not support and you will have to start the development again.
How many times you had to drop a feature in your game because it is impossible with Unity? In most cases Unity will do the work well, but be sure you will have anything you will need in it before starting.
Of course, this is an extreme example, you will be safe using Unity in most of your projects and you need to be insane or have a very good reason to choose C++ instead.
There are a lot of good developers out there willing to help you. Your best choice will be always trying what is already done, but you should never discard doing it by yourself, you can always improve what is done in some way.