Making a Unity Plugin for the Asset Store
My first attempt at making a Unity plugin – was a plugin that showed your current selected scene in the project view, which was useful when you needed to go through all the scenes to change something and I thought I could share it for free via asset store, although i would do this via code now, nether the less – it was declined for being too simple, so it doesn’t count 😊
There are a bunch of frustrations with mobile development and one of the biggest ones for me has to do with Android Manifests. Unity has some crazy functionality for adding permissions into manifest for you depending on the code that may or may not be actually used, but nothing to actually manage the things in the manifests, there isn’t a place to add or remove permissions. After android 6 – things became even worse because now you had to request permissions from native java code and unity didn’t provide the API, even though they do request permissions for you at the start (without any explanation to the user and no way for you to change this without your own native code)
I’ve spent two evening searching what was causing automatic permission requesting on the game start, searching through all of the plugins we used, just to learn that it was Unity itself, without any checkbox in the Build Settings.
And so I thought I could make a plugin to make it as simple as unity should already have. “How difficult can it be?”
Making the UI
I’ve made a few desktop applications using Qt and WPF and I expected something similar from Unity editor UI, but Unity editor UI API really reminds me of low-level calls like OpenGL, where you draw lines in an update loop, instead of something like a game engine built on top of OpenGL where you create an image, set the coordinates and the engine handles the drawing, you just manipulate the object, changing it scale, position, etc.
Instead of getting an event when the button is pressed – you get a method that you call in each update, which you need to draw the button in the first place, and then you need to check the return value of this method to know if it was pressed.
To draw a checkbox – you need to save the state of it in a local variable and pass it in on each update, instead of just creating the checkbox and having an option to ask it what is its current state + an event when the state has changed.
So I’ve started wrapping Unity UI into objects one by one, as I’ve needed them to make the code more Object-Oriented and easily reuse things like Alternating Color List or an EditLine with autocomplete. I go more in depth on how the library is structured in this article.
Scope
During development I was also frustrated with long iteration times when permissions were involved, you need to request it, build it, install to find out that you forgot to add it to manifest. Then fix this, wait for it to build again, and see that dialog isn’t showing correctly after permission was rejected.
Thinking about this I thought I could fake permission requesting in editor using a Behaviour pattern so that the same code would allow to test in editor and request on the actual device. Without this functionality the plugin would have taken a lot less time but would have been a lot less useful, so I decided to include this. (Plus it was fun to implement)
Documentation
I haven’t written documentation at that scope before, so I had no idea how in detail it should have been for it to not take a ton of my time to write but also be useful. It turned out to be an over 20 page PDF, which I think is a bit too much detail and I would spend less time on documentation next time, improving it with things asked on the forum.
For the writing I’ve used Ulysses on Mac, which I got on a discount before it was a subscription-only app, plus Editorial on the iPhone which can edit the text inside .textbundle files created with Ulysses, syncing files back and forth with Dropbox.
Submission
Before submission I have to remove some files I use for testing, removing them by hand for each release would be too tedious and there would be a high probability to forget something, so I made a script that removes specified folders and files and after that I upload the asset. But still, I have to do this for each Unity version I want to publish by hand. It would be much simpler if there was some tool that would open specified Unity versions, run custom scripts (to remove extra files for example), and try building – reporting any errors that happened and then upload on its own. Maybe someday I will get around to it, please comment if you would be interested.
Then I’ve written a short description, uploaded screenshots, submitted and started waiting…
Approval Process
Even though Unity says that approval process takes two weeks my asset was in a limbo state for over 3 weeks. Knowing I will have at least two weeks, I’ve spent this time improving the documentation & fixing some rare bugs, which I’ve resubmitted after the asset got approved. After the asset store team got a first look at the asset – the next version takes a few days max, even if it was rejected due to some small issue.
Making the GIFs & Quick Setup video
I first looked at ScreenFlow app for the purpose of making a short setup video but I found that it can also create gifs and it is very useful to first record the screen, crop the part you want, speed it up, etc, and only then export as a gif. I’ve only used GifCam before that and it even isn’t available for Mac.
Making gifs allowed me to get a hang of it and I’ve made the video as well.
I think ScreenFlow was really helpful to make something quickly for someone with no prior editing skills.
Final thoughts
Overall the plugin took over four months in development time (weekends and evening), and even though it didn’t sell a ton, I still think it was worth it, I’ve learned a lot and when I decide to make another plugin – I will already have my UI library that should speed things up.
Links:
If you liked this article and would like to see more like this one – subscribe to Let’s Make a Game newsletter.
