Can I create instances of types outside of code? (like ScriptableObjects)

Hi. So I basically want to create a type outside of code like I would a ScriptableObject, but since types are far more flexible and have more features than ScriptableObjects, I’m using types instead. I tried making a list of Items in my game public, but I had no luck creating any new Item elements in the inspector. I could also always just make a new line in the code for every new object I want to add to the game, but obviously, there must be a better way. Thanks.

If like JVene said by types you just mean classes otherwise I don’t know what you mean by types.

If what you want is a class you can create multiple varieties of in the inspector then ScriptableObjects is what you want. Just use subclasses instead to get “types”.

Or constructors which are instances of classes.

Example of what I think you mean by types

public class Gender : ScriptableObject
	//This is a parent class and will not appear in the editor

[CreateAssetMenu(menuName = "Gender/Male")]
public class Male : Gender
	//This is a subclass that will appear in the editor

[CreateAssetMenu(menuName = "Gender/Female")]
public class Female : Gender
	//This is also a subclass that will appear in the editor

I have to make a few somewhat reasonable assumptions about your meaning here. The generation of data from the inspector is actually the result of serialization hidden within the Unity framework. As such, the potential concept you’re really thinking of is serialization of data.

Ultimately, no instantiation of a class, or any time including floats and ints, is the result of some line of code declaring that instantiation. The storage for the instance is central to that step. For built in types, like floats and ints, instantiation can be as part of the membership of a class, or of local variables in a method, formed on the stack (temporary local variables). For class instantiations in C# (a common theme to similar languages, but quite different from C++), there must be a ‘new’ allocation, as you see when using Vector3. If there isn’t a ‘new’ keyword involved, it must be either that the variable declaring the class is null (there’s no storage, the instance is not formed and the reference of that type is null), or the instance is actually copied from some other reference holding that instance.

That means that while you don’t see it in code yourself, there are ‘new’ keywords used to instantiate class types when generated by the framework and initialized in the inspector. Indeed, the inspector is merely storing the values to be used to initialize the instantiation in code, though it is hidden below the visibility of user code.

So, one either will have to instantiate ‘new’ objects at runtime in code, or perform serialization (which, of course, requires one to write out the initialization data somehow). That creates, if you think about it, a bit of a dichotomy. How does one create a file that can be read in during serialization unless there’s code that generates that file? The answer, while filled with lots of options, can be to write a C# program outside of Unity that creates the file, create one within Unity that creates the file or use a format you can create in text, like XML.

If, for example, you viewed an XML file of parameters as if they were fields in the inspector, you could create a file suitable for streaming in to instantiate a large population of C# classes.

I’m an old hand at a wide range of programming languages and topics, but I’m fairly new to Unity. There are ways of serializing classes in Unity, but the default inspector automates that process only for MonoBehaviour scripts initialized by the editor. Researching the documentation of serialization may yield some Unity specific means of getting the inspector to work on other classes, but I haven’t researched that. I would personally not favor a Unity editor specific approach in my own work, even if it were reasonably well supported, as I would favor XML or some JSON format I can edit with a text editor, but then I’m old school and that’s familiar. Put another way, I’d caution against focusing on the Unity editor’s features for serialization of general C# classes, favoring methods for doing that which are universal to C# (which could even include some form of SQL database).