One really interesting thing about the Unity Editor is the way it integrates the items properties (Assets, Scripts,etc…) into the Editor interface automatically, improving readability and simplifying setting the values for those properties. After reading how the Inspector window works [1] and how to use Serialization on scripts [2] we decided that these were some very useful and powerful tools and that we should use them to improve the way our scripts interacted with the user in the Editor. One such use was the implementation of some components to simplify the definition of blueprints for the buildable items in the Elf Factory scene.

The factory activity allows the user to create toys, trying to reach the project main objective of collecting 100 presents to save Christmas. These items are created by combining 4 components out of the 16 available in the production line.

Figure 1. Aspect of Elf Factory activity.

Each item that can be created has a blueprint, or recipe, that lists the components it needs: for instance a little mouse warrior plush doll is built using wool, buttons, a zip and a wood plank. Each recipe was made with the intention of having some basic real world logic, but keeping them simple enough to be accessible to our project target audience: children between 5 and 13 years old.

To avoid having to define the blueprints by hand on code, and at the same time allowing us to explore and change them easily while developing the activity we used the auto serialization capabilities of the Unity Editor.

The main classes involved in this process are the ItemComponent class that allows us to mark a prefab as an item component and also set a sound to play when they collide with the machinery and with each other. A BuildableItem class that defines an item as buildable by our machine and which ItemComponents it needs. These classes interact with a MachineController class that provides the game loop for the scene.

The BuildableItem script was attached to a prefab that represent the finished product and defines the name of the item, the image that will be shown when the machine selects the next item to build and the list of components necessary to complete the build successfully.

The MachineController script manages the entire activity loop, defining the item to build, selecting randomly from the Buildable Items list, showing a preview, using the image defined in the item, lighting up the correspondent buttons to give the user a hint of the recipe, checking if the selected items are valid, by matching the instanced components with the components defined in the buidable item blueprint and activating the animations to make everything feel connected and proper to a production line.

The next table shows each class public property definitions and the rendered output in the inspector.

Class Inspector detail


public class ItemComponent : MonoBehaviour


    // Name of the sound event to trigger

    public string soundOnHit;



public class BuildableItem : MonoBehaviour


public string itemName;

public Texture itemTexture;

public List<GameObject> components;



public class MachineController : MonoBehaviour


public List<BuildableItem> buildableItems;

public GameObject buildableItemImage;

public List<ItemButton> buttons;

public BuilderMachine builderMachine;

public Vector3 launchPosition = new Vector3(0.007f, 1.2f, -2.4f);


They are not very complex classes but, by defining public properties that the editor will then render as controls in the Inspector interface, provided a very practical user experience during the scene development. The use of these custom classes allowed us to setup the entire machine production using drag and drop actions, without having to make changes to any script code after the logic was finalized.

Leave a comment