I’m an experienced programmer in a variety of languages including C#, but I’m green as a seasick kermit when it comes to unity, and I need some help wrapping my head around what I’m trying to do.
My game involves a lot of entities that don’t have a visual representation except in menus. So imagine a game that’s all menus, and you might have a list of Ideas, say. The Ideas have properties, and you can view the properties by selecting the Idea from a list of all your Ideas.
The ideas are generated at certain times, like when you press the “New Idea” button. So I have a stub of an Idea script that has the relevant public fields, but I’m conceptually stuck. What actually goes in the Editor window?
I guess I need some kind of global IdeaCollection or List? Where is that stored? Do I create a GameObject in the 2D world and assign it the IdeaCollection script, or…?
All the tutorials I’ve looked at so far are for more concrete cases like there’s a character object you have on the screen and so you attach controller and a render components, for example. That I get, but I’m having trouble making the leap to something more abstract. I could use a little hand holding.
The class you can use for a game object component has to be derived from MonoBehaviour but apart from that you can just use normal c# classes for things like list items etc…
In your scene you might have a gameobject called ‘MyMenu’ which has a list of items in it. These items are a list of a normal class but have the [System.Serializable] flag set so you can edit them in the unity ‘Inspector’ window if you like.
e.g.
[System.Serializable]
public class MenuItem
{
public int Count;
public string Name;
}
public class GameMenu : MonoBehaviour
{
public MenuItem[] m_Items;
}
Just create an empty gameobject in the scene then drag the ‘GameMenu’ class into the object as a new component.
GameObjects don’t need a physical representation in the scene. Empty GameObjects are often used to hold abstract data or act as “folders” to organize groups of GameObjects.
Technically you don’t need a GameObject to hold your Idea list, but MonoBehaviours (the scripts that run on GameObjects) are nicely integrated with Unity’s game loop, with hooks for GameObject startup, frame updates, destruction, etc. What’s more, Unity serializes the public values of GameObjects and ScriptableObjects, and you can view them in Unity’s Inspector view. (Not to get too much into the weeds, but you can also tell Unity to skip serialization for some publics and serialize some privates, and there are some exceptions such as Dictionary that require additional steps to serialize.) As long as you make List public in your IdeaCollection script, it’ll be serialized and you can inspect/modify it.
If your “New Idea” button is available to the player at runtime, you can use the Unity UI system. Add a UI Button, and direct the OnClick handler to a method in your IdeaCollection script that adds another element to the list.
If your “New Idea” button is only available at design time (i.e., in the Unity editor), you can write a custom inspector or editor window.
You might be tempted to define your Idea list as a static variable, but then it won’t show in the inspector. Similarly, you might consider implementing it as a Unity Singleton, but what if you end up needing more than one IdeaCollection?
Thanks a lot! I think I have my head on straight now, I’m going to experiment with things and see if I can get them to cooperate. Learning curve, here I come!
Ok, I’ve a followup question here… (Unity newbie here too )
My background is formerly libgdx and there I’ve created my own ECS system for backend (model) objects. Would you advise me to use Unity’s ECS/Game object system for that ? I think the pros are I could use the inspector (cool) and the cons a penalty concerning performance. Is that assumption correct?
For backend stuff you probably want ScriptableObjects. They are serialized, instanceable, great for dumb data, and exist as Asset files in the project folder.
@hawkeye_unity - If you are familiar with full ECS concepts, you may want to look at EgoCS or Entitas-CSharp, as they both extend Unity’s Entity-Component framework to a full Entity-Component-System framework, either by modifying the normal workflow (as EgoCS works) or running a bit separately from Unity’s GameObjects/MonoBehaviours and updating them based on the current simulation state (like Entitas does).
@TonyLi 's post covered a lot of ground, but I can also recommend you look at the general old immediate mode GUI, the GL functions for visualization, Gizmo drawing for debug visualization, etc. There are lots of options.
)