Being an indie is a tough job. Especially if you are going against the advice everyone keeps giving on the internet, about making something small. So you might be tempted to take the decision and use an asset created by someone else in your project, to save some time. In this blog post I'm going to give you a warning though, my personal advice that might save you time and frustration.
First of all let me tell you that I'm not against using ready made assets in general. In fact I do use a number of stuff made by others, and I'm happy about it. Secondly, this blog post is not going to touch the subject of "asset flipping" that people like the famous youtuber Jim Sterling is often commenting on. I'm not going to touch the subject of using art such as 3D graphics models made by others on this post, but using the code of others. Seeing how the use of publicly available graphics asset has gathered a bad reputation, you might think that because source code is not visible to players, that it will be OK to use someone else's code on your game. But there's a danger in doing this. Especially if you aren't one of those that know nothing about programming and use ready made "complete projects" for their games, and you actually do some original content yourself.
So one of the last things that you want to happen if you're a programmer and build your game yourself, is to not only have to care and test, and debug, your own code, but also someone else's code. Working on my game, I decided earlier on two times to use some assets that I discovered on the internet. Both were involved with the GUI somehow, because for me personally dealing with the GUI is one of the least enjoyable experiences of programming. The first asset that I decided to use, early on when I started working on this game, was one that would help me deal with the Inventory System of my game. At some point there were errors coming from the code of this asset, which was annoying because when I use someone's tools, I want to have the confidence that they work as documented, and that they always work. Anyway, I decided to have a look on the asset's code, and what I encountered scared me. The code was needlessly over-complicated, the parts of the system over-bloated. Seems the writer of this code never read Uncle Ben's "Clean Code". I started trying to decipher the code, and after a bunch of hours with no progress, I realized that I was spending too much time trying to fix someone else's code, and that it would be just easier and faster to create a similar sub-system of components myself from zero. So I said "screw this", and I started designing the code for my own inventory system. Once I got it working and tested, I felt so good, as if a weight I was carrying on my shoulders had been removed. In the end, doing all the work to understand how a system made by someone else works and then debug it, just doesn't worth it. Because the code you wrote yourself is always going to be easier to read (provided you follow and apply a coding style with specific rules) and thus debug, and even if a long time passes, it will be more intuitive for you to move around the scripts and find the part you have to change.
But I didn't learn my lesson the first time. I'm a slow learner you see. So some time after that, I decided to use another ready-made system made by someone else, this time a dialogue system. A system with which the player can have a conversation with other characters in the game. This system looked much more professional, it had its own website, video tutorials on Youtube... I gave it a chance and it looked fine early on. But later on problems came up. As I was getting rid of bugs one by one following the exceptions list, I eventually saw a null reference exception coming from the code of the dialogue system asset. I checked the objects related with the exceptions, and I found out that the objects representing individual dialogues had disappeared. They weren't anywhere in the scene, WTF ? I googled the problem and I landed on a page on the official support forum of the asset, where someone else had the same problem as I. The person responsible answered to the user that the user has to expect that if for any reason Unity hangs or crashes, all the prefab gameObjects coming from this asset are going to delete themselves without notice. Why is this happening ? Unity has crashed on me a few times, and none of the gameObjects running my code ever deleted themselves. What's worse is that the most frequently used objects of this asset holds data. Data you have to manually enter in each object, such as the actual texts that will be displayed on the screen for each dialogue the player has with a NPC. And thus whenever the objects delete themselves not only you will have to place new ones on the scene, but also to manually enter all the data again. Now, you can understand how much of a liability it is to use such an asset in a large RPG game, where you have to have several hundreds of thousands, if not millions lines of text, for all the different NPCs and the different dialogue choices, right ? The risk of using this asset in such a big game is so big that using this asset is just not worth it. Some might say "Hey, do some backups", but that doesn't solve the problem. I do commit to source control every day, but imagine this scenario: You are using the prefabs of the asset in one scene. Then you start working on another scene for an X amount of time. As long as you are working on a scene different than the one you have used the asset's prefabs, you are not going to know if the asset deleted the prefabs. You will only find out when you load the old scene again. And if you want to restore your project to a previous state where the gameobjects hadn't been deleted yet, you will lose the work you've done that X amount of time in the other scene. You might argue that the source control system allows you to only bring back certain files and not the whole project. But guess what, the files that hold the data you enter in this asset's objects is saved automatically on .meta files named with random strings, and the same format is also used by the game engine for a large number of other stuff, meaning that you would have to try out each randomly named .meta file one by one. But what if there are hundreds, thousands of such files in each commit ? With this happening to me, I gave up on using this asset, and I decided to create my own dialogue system from zero. The liability, the risk of using this asset is too high. At least with my code, I know that whenever Unity hangs or crashes, the gameobjects that use my code won't remove themselves without a notice in a way that just closing and reopening the project won't bring them back.
The lesson I've learned is this: Be extremely careful and conservative when you are about to decide to use someone else's code in your project, to minimize your dependencies as a programmer. Do so only if you absolutely have no other option, it's a core feature of your game, and can't create the functionality yourself. At least try to write your own code before considering using someone other's code. In most cases using someone else's publicly available / ready made code won't worth it, because it will be code harder to read, understand, and debug, bloated with features you probably won't ever need. In the end it will be much more efficient to create, use and debug your own code than someone other's.
P.S. So if you are wondering what I'm currently working on, is getting my own dialogue system up and running.
Δεν υπάρχουν σχόλια:
Δημοσίευση σχολίου