Weird question I guess… I released my first asset on the store a while ago, and let’s just say the popularity is quite underwhelming.
So my guess is, I didn’t make what people want.
I’m wondering on what I should focus next, since I’m not into wasting time in something people wouldn’t use. I have numerous things that I use daily in producing video game, but while I do use it doesn’t mean other would be interested in them, and while they are stable in production, releasing them as asset is an whole different level of complexity, documentation and support.
I came across two threads today discussing gameplay tutorials. I bet you’d find customers for a purpose-built, easy-to-setup state-based framework for making in-game tutorials.
I’m not entirely sure about that. You might want to pay attention to marketing and messaging…after reading the description a couple of times, I’m still not really sure what exactly your asset does or what problem it solves. It’s probably obvious to you, but I think it would help to communicate it more clearly. It’s possible people might want it, if they knew what it did.
I have to agree. I don’t understand what it does. But even that’s not really important. What’s most important: As a customer, I would want to know how it would benefit me, personally, and my needs. Don’t tell us what it does; tell us how it makes our lives better. Toolbox Creator might be exactly what everyone needs. (I feel that way about uTomate, for instance.)
A video demonstration would be nice, too, but no one’s going to watch it unless they first have an idea that the product will benefit them directly.
BTW, I think I might steal back that tutorial idea. It grew on me. So here’s another one: People would bang down your virtual door for a way at runtime to determine what states and parameters are on an Animator Controller. I feel like I see this question half a dozen times a week.
I guess I cannot not disagree with this… I agree the description is lacking. Not that I know how to fix it…
Well, there’s a video demo in the description.
Toolbox is a generic modal popup that lists choices and allow to search in them. It can be used in your Editor, EditorWindow or tools. It’s very useful when you need to give a long list of choices to the user. I should probably make another video of another of our implementation.
Creator is a Scene View tool that uses the Toolbox to quickly create GameObject, instantiate Prefabs or add components to a selection.
As for some reflection off the Animator… I’m really not sure if it’s possible. The notion of State and StateMachine are part of UnityEditor, not UnityEngine
Sorry for high jacking your thread again, but I have retrieved all states and parameters I need in my GAC asset. GAC needed to have all the states so that’s what I coded it to do…
Sorry, I’m not sure how I missed the video link. I guess I was searching around trying to understand the text. Without thinking about it too much (as I’m trying to maintain the perspective of someone who’s newly come across it on the Asset Store), it’s not immediately apparent what problem it fixes for me. You describe what it does, but perhaps you can also hint at some concrete examples of how it would actually solve a problem or challenge I might have.
For the Animator, maybe it could be an editor-time tool that uses UnityEngineInternal to store some information in a ScriptableObject or MonoBehaviour that’s attached to the same object as the Animator. Customers wouldn’t be able to directly pull the info from the Animator, but if they knew that there was, say, an “AnimatorInfo” component on the same object, they could query it for a list of parameters, states, layers, etc.
You released Toolbox Creator a week ago, right? I keep my eye on all new releases and I sincerely thought you releases a model of a toolbox. I’ve only just now seen the introductory video (loved the music!), and it looks really handy. But I had no idea that’s what it was. I think you should change the picture to something more meaningful, don’t show a picture of a toolbox as the focal point. Look at how it looks in the asset store: the description obscures the actual Toolbox window. But that’s your most important visual cue!
Furthermore if you can summarise the Toolbox in an analogy: “It’s like Alfred/Launchbar/Launchy for Unity!”, I’m sure people will catch on sooner. People won’t buy anything they don’t understand. Be more descriptive. “The Toolbox is a modal popup that gives user choices, any choices!” still says nothing about how it works, because how it works is: “With one keyboard shortcut open up a search box that puts all of Unity’s menu options at your fingertips. Simply start typing (for example “gam”) and select “Create Empty GameObject” to create an empty GameObject without using the mouse! Supercharge your productivity and stop unnecessary looking through menu’s trying to find what you’re looking for; simply find it with a couple of keystrokes!”
Etc.
In the meantime, I’m going to put this in my wish list and take a good look at it later.
I think you have a point with the visual clues. However, I have no idea what “Alfred/Launchbar/Launchy” means. But I understand writing examples is a good idea.
Yeah, it is. It’s a whole class of product with versions for every operating system. But what they all have in common is that they use keywords for additional behaviour. I looked at your asset and I would buy it except for the toolbox.dll that prevents me from extending it with extra functionality on my own.
I would urge you to take a good look at any launchbar-like application, and install one to play around with it. The strength is in the keyword-system. I can easily see Toolbox be super-useful if you could add keywords to define behaviour (instead of a separate creator version). That way the default behaviour is the list of “choices”, but if you start typing “add gam”, it would list all options under the Create menu, and pre-select the “Create GameObject”. One press of the return would create a new GameObject.
That way you can easily expand functionality just by adding keywords and a keyword handler. If you’d add the source, people could expand Toolbox themselves, and perhaps you could add a GitHub repo so we could add our own behaviours. Then Toolbox could pull them from GitHub, or something?
I really think you’re on to something with this asset, I hope I’ve given you some good ideas.
The “toolbox” is only the modal window. It’s a basic window that you feed it a list of item, and it returns the items that was selected. It is just a list of generic item with a search box. It has no real behaviour on itself. I always thought it was something missing in Unity… A popup with choices. I use it in many of my Editor and EditorWindow.
As for the “Creator” part - which in this case is the “launchbar” behaviour - it is also fully extensible too. It parses all the current assembly to find any class deriving from “UniTools.Creator”. This abstract class has methods for building lists of items. All the “Creator” coming with the package are not within the .DLL, but in plain .CS. For example, one of them is the PrefabCreator which returns a list of all the prefabs that are in specifically named folders, those items shows up as “Prefab: NameOfPrefab”… So if you search “Prefab”, you get all the prefabs.
Right now, it works in 2 mode;
CTRL+E; Create a new GameObject with the selected component on it.
CTRL+SHIFT+E; Add the selected components to the current selection.
In other word, anybody can add behaviour items to the popup with ease.
Since CTRL+SHIFT+E works on the current selection, someone could easily add an item named “Align”, as example:
public class AlignCreator : UniTools.Creator
{
public override GameObject Create(Vector3 position)
{
return null;
}
public override void Add(GameObject[] selection)
{
if (selection.Length < 2)
return;
Vector3 position = selection[0].transform.position;
foreach (GameObject go in selection)
go.transform.position = position;
}
public override DescriptorPair[] GetAdditions()
{
return new DescriptorPair[] { new DescriptorPair(new AlignCreator(), new DescriptorAttribute("Align Selection", "")) };
}
public override DescriptorPair[] GetCreators()
{
return new DescriptorPair[0];
}
}
Most of the code is within a DLL because it’s a rather huge collection of classes and interface that are not fully commented or useful outside this context. In other things, there’s a full TreeView in there that is not fully debugged for behaviour outside the Toolbox context.
I’m using that TreeView to build my own hierarchy panel with real directories (not gameobjects), among other things;
Just a quick note on this, I know a lot of people (including myself) who will not buy assets which are binary only. Simply because there is no easy way to change them around when you need to. All my assets have come with source code, for a very good reason. Even my upcomming ~15k LOC networking engine ships with full source code to the user.
The norm in the community is to ship with source, and you really should consider doing that.
