The (sort of) hidden world of indie game-tools development
Publishing tools is an interesting and sort of hidden world that can potentially interest other developers making games. If this doesn’t spark much curiosity in my fellow indie-dev reader yet, yes, it can help you with some extra cash while you’re making your game!
My experience is rather fresh at the time of writing this, it’s also a rather exciting moment as I’ve just released my first commercial tool! It’s called Clayxels. It’s a tool to make interactive models very quickly and without ever having to leave Unity. Publishing my own tool turned out to be a rather interesting journey, so I’ve decided to collect some info here for other people who might have already done a nice tool worth sharing without even realizing it.
Clayxels sparked to life from previous attempts at making a game-designer friendly asset creation tool. More about this journey here, spoiler, a big mention to Alex Evans and Media Molecule’s PS4 Dreams right at the top of the post ❤.
Fast forward almost one year and it is now up on the Unity Asset Store and has been featured on the front page (to my surprise and joy!). So, maybe you’re also making a game and you’re already developing some interesting solutions, then why not sharing these goodies with other devs?!?
Game developers and tool developers
The way I personally see it, a game is a tool to narrate a story. If you have made one or more games already, then it’s very likely that you ended up with a story-telling toolbox made of lots of tiny tools. You probably addressed several unique problems encountered during development. Without even realizing it, you’ve been the best user of some cool software you’ve made yourself, for yourself. If that’s the case then you are in fact a tool developer without even knowing it, and maybe, sharing these tools might not be such a bad idea. I can’t really tell you if publishing a tool will make a big difference on your wallet, it probably depends on too many things. But I can tell you that getting a tool out there for others to use can be very rewarding, it can also be an effective way to expand your professional network, get contracts on something that is within your confort zone, and fill gaps between the games you’re working on. These are pretty much all things I did not see coming when I initially decided to share Clayxels with the rest of the world. As an independent game developer, these are very good things that greatly help me pushing things forward with my games.
Some pro-tips from other developers
Of course if you decide to charge money for something you made, then expect feedback, reviews, emails and all that. Since my experience with all that is still rather limited, I thought I would ask for some pro-tips to other developers that have made some very cool tools and are already well known for them!
Freya Holmér,
who happens to be the amazing developer behind Shader Forge, who also just recently released Shapes on the Asset Store, shares some tips on what it was like to develop these amazing tools while also shipping the VR game Budget Cuts!
Freya:
1. Set boundaries clearly for what you support and what you don’t. I struggled a lot with this with the release of Shader Forge, where I would get pulled into being everyone’s personal technical artist, which doesn’t scale whatsoever, and it’s not really your job or responsibility to help people creatively using your tool! You should focus on making your tool better and enable people to do cool things, not do cool things for them.
2. Scope your asset properly. Anything you add partial support for will get you people asking for full support. if you support one extra render pipeline, people will want support for all of them. if you support a file format import feature, people will also want the export feature, and, all the other popular formats. Currently with Shapes, one of the scopes I’ve set is that Shapes is not an asset management tool — it’s for real-time vector graphics only, so I’ve never set out add svg import/export, even though people might expect that. same thing with stuff like colliders! I don’t have collider support, Shapes is strictly for rendering at the moment. That’s not to say that it’s bad to increase the scope, just, know what you’re getting into, and keep in mind that the more stuff you have, the more you need to maintain.
3. Balance work/life carefully. Being an indie dev and at the same time work on an indie too can be really stressful. I ran into this to the point of burnout near the release of Budget Cuts while working on Shader Forge, with all support messages and requests to fix the thing that broke in the most recent version of Unity. I can’t recommended to go all in and do everything at the same time to 112%. please take care of yourself ❤
Daniele “Demigiant” Giardini,
doesn’t matter weather you recall Demigiant’s nick name from one of his tools, a game he worked on or some of his fantastic art (yes, he can actually do all of that). Chances are that you do own a copy of his DOTween already and that you are using it in your game. If not, wait, what??
Daniele:
Freya already wrote the best tips so I’ll just leave some secondary ones.
1. You will be asked the same questions many, many, times. Try to create a FAQ somewhere so that nobody wastes time on known stuff.
2. Mark a clear support path. Where should users write you? What data should they include?
3. The first year will be the hardest so be prepared to spend lots of time on support: the asset that you thought was so cool and bug-free will now be used in ways you never thought of and broken repeatedly.
An anecdote I like: DOTween is a tween/animation engine, but some people used it to create sequences of events that included no animation whatsoever, which sometimes didn’t work. I initially opposed this by repeatedly stating that it was an animation engine, so really not supposed to do non-animation stuff, but in the end I relented and implemented a full no-animations functionality and I’m glad I did that. This is to say that, while scope is important, also listening to feedback about unexpected features is. The right amount of flexibility is a difficult thing to achieve.
4. Take great care of the UI/UX side of your tool. A well documented API (even if just via IntelliSense-enabled XML comments) will help users a lot when coding, and a simple, clear, Inspector/Editor UI (if your asset has any) will help them when not coding. Both of these will help you during the support phase because good understanding lightens the support burden: it’s one of those nice things that helps others while also helping yourself.
5. As I always like to stress out, Unity is an ecosystem so don’t forget to take care of possible conflicts with other tools aaand use namespaces ffs, because otherwise you risk breaking all the other tools that correctly use them :P
Amplify Creations
Amplify Creations is a company that is fully committed on giving game-devs some truly useful tools that are very polished, powerful and yet very easy to use. Amplify Shader Editor is quite possibly one of the best examples of all of that combined in a single asset.
Ricardo from Amplify Creations:
Great suggestions by our fellow developers.
1. We also feel that the support load can be detrimental as you’d probably gladly help everyone if you could, do set rules as soon as possible. We strongly recommend creating a space where your users can discuss and share their work, Discord seems to be a great choice these days. Insist on having a record of bug reports via the official Asset Store publisher support email, or properly reported by other means(Unity and Product version, etc), and use a ticket system to keep track of everything(Trello works well in the beginning if you don’t already use something like GitHub). From experience, I feel that you can get extremely overloaded if you try to handle everything as it comes in. Schedule your support time, most users won’t mind waiting a week or two and are actually understanding of your limited resources as a solo developer. That said, the Unity community is a vibrant and active place that’s going to help you to improve your tools. Take in feedback and spot recurring issues, there’s likely always something you can improve on your side in order to lessen or completely correct reported problems.
2. Most user contacts will be straightforward but you will definitely get some unclear questions or non-english speaking users; don’t hesitate to ask for additional information, it can get a bit trickier to decipher in some situations. Disregard “unpleasant remarks”, you do see some strange things every now or then, we’ve learned that it’s best to disregard this type of things and simply get to the actual problem, if any.
3. Be sure to offer a couple of narrated video tutorials with the very basics(~5m to 10m, or shorter), there are quite a few artists out there just now starting to use a 3d engine like Unity, it’s best to cover the absolute usability basics. Written tutorials are also quite welcome for some users. Keep publishing awesome stuff!
Closing Words
These folks have been incredibly approachable, just like the game-devs that my tool has put me in touch with so far. Developing your tool can be a good source of good energies, and hopefully some bucks too. If you are looking for one more way to make game development sustainable, share that cool tool you’ve made!