our rambling
Want to be notified of new blog posts?

Elwin Verploegen

Introduction to Game Design: You can absolutely start with a story March 3, 2015

By Elwin

This article is in response to Chad Carter’s article, “Don’t start with a story“.

Introduction to Game Design Header

If you want to make a game, you can absolutely start with the story.

You read that right, you absolutely can.

While it’s true that if you’re about to make the next procedurally generated dungeon crawler with exploding skeletonstm, a great story probably isn’t your 1st priority. In that case, your first priority is getting a proper gameplay loop going. If your gameplay loop is fun, that’s when you will start adding content. The story is just 1 of those pieces of content. I do urge you to think about the story early on, as adding one later just to say “there’s a story” generally ends up with something that just doesn’t make sense.

If you want to write a great story, write a book, graphic novel, movie, short story, or something else. Like a game. The last couple of  years we’ve seen a huge increase in games where narrative is suddenly more important than gameplay. Games like Dear Esther, Gone Home and the Telltale games like The Walking Dead. I don’t think anyone playing Gone Home has ever said “Man, those mechanics were the best thing I’ve seen in years!”.

You can design your game around a story, we’ve done it succesfully (you can read more on how we made the Fragments of Him prototype here). We started with the idea of a game where you follow the story of someone who just lost someone. I will quote Dr. Mata Haggis from the above link on the first steps of the design:

The theme was minimalism, and I wanted to do a game with a very prominent story in it. I worked on several ideas in my head, but the one that stuck was investigating why a person would choose to live in a minimalist style in their house. The result of this was the idea that the lead character had lost their partner and couldn’t stand to be reminded of the loss.

The story was pitched to myself and my colleague, this is  we started brainstorming on how we would turn this into a game. We brainstormed for a bit and settled for the simple mechanic where the player clicks away memories that remind him of his partner. This makes sense within the narrative and it was actually possible to do within the very limited time scope of a game jam.

No matter what your game is, story is important

I think there aren’t enough designers (or developers) who ask themselves a very simple question.

Why?

Call of Batman: Duty Ops

Call of Batman: Duty Ops

Why is my character doing this, why would the player be interested in following this person around for the next 10 hours of his life? Taking a game like Batman: Arkham City, a game with amazing fighting mechanics. Would that game be the same if it didn’t start from a story? Batman started out in a comic book and eventually made his way over to games, and its mechanics are based around how Batman fights, moves, talks and interacts. While I’m sure they didn’t write the entire story of the game on day 1, these are extremely important things to think about when designing a game.

Think of it this way, what if they decided to put the Call of Duty mechanics in the next Batman game. The story will remain the same and you’re still the mysterious guy in a bat suit fighting crime. But now you’re going from cover to cover with a sniper or assault rifle. Would this make sense or even be fun? It might actually be fun, but you’ll probably wonder why this is a Batman game in the first place.

Even AAA games need to have (at the very least) a global overview of what they story will be like before they start building things. Modifying the ending of a game because you didn’t like what you wrote last week will cost millions, changing the location of an event is also something that you can’t just do. These things need to be planned well ahead of time. The fleshing out and details can be done as you go along.

Building Fragments of Him

Fragments of Him is an interactive narrative experience, and we’re building it in the exact opposite way that Chad is suggesting. We wrote a story first, and are building the game and mechanics around that story. This is something that works great for our type of game, and will probably not work for other types. If you’re building a game that focuses on great gameplay and a fun experience, I definitely wouldn’t recommend starting with writing a fully fleshed out story.

I don’t think you can flat out say “Don’t start with a story”, because you can. There’s just so many different types of games and so many variables that come into play when making a game that there’s no best way of doing things.

Completely disagree with me? Got a game that focuses on narrative that I probably don’t know about? Send me a tweet @elwinverploegen!

Elwin Verploegen

Snippet: Swapping Rendering Mode in Unity 5.0 on Run Time March 2, 2015

By Elwin

If you’ve ever tried to switch the rendering mode of a material in Unity 5.0 on run time, you might have run into some issues with it not updating properly. This is what I thought would do the trick just fine (sidenote: 0 = Opaque, 1 = Cutout, 2 = Fade, 3 = Transparent), but it doesn’t actually update anything (in my case, I wanted to fade out an object).

mat.SetFloat("_Mode", 3);

If you look in the GUI code for the shader (Editor/StandardShaderGUI.cs) you can find the following code that handles the changing of rendering modes, and will show everything you need to solve this.

public static void SetupMaterialWithBlendMode(Material material, BlendMode blendMode)
{
	switch (blendMode)
	{
		case BlendMode.Opaque:
			material.SetInt("_SrcBlend", (int)UnityEngine.Rendering.BlendMode.One);
			material.SetInt("_DstBlend", (int)UnityEngine.Rendering.BlendMode.Zero);
			material.SetInt("_ZWrite", 1);
			material.DisableKeyword("_ALPHATEST_ON");
			material.DisableKeyword("_ALPHABLEND_ON");
			material.DisableKeyword("_ALPHAPREMULTIPLY_ON");
			material.renderQueue = -1;
			break;
		case BlendMode.Cutout:
			material.SetInt("_SrcBlend", (int)UnityEngine.Rendering.BlendMode.One);
			material.SetInt("_DstBlend", (int)UnityEngine.Rendering.BlendMode.Zero);
			material.SetInt("_ZWrite", 1);
			material.EnableKeyword("_ALPHATEST_ON");
			material.DisableKeyword("_ALPHABLEND_ON");
			material.DisableKeyword("_ALPHAPREMULTIPLY_ON");
			material.renderQueue = 2450;
			break;
		case BlendMode.Fade:
			material.SetInt("_SrcBlend", (int)UnityEngine.Rendering.BlendMode.SrcAlpha);
			material.SetInt("_DstBlend", (int)UnityEngine.Rendering.BlendMode.OneMinusSrcAlpha);
			material.SetInt("_ZWrite", 0);
			material.DisableKeyword("_ALPHATEST_ON");
			material.EnableKeyword("_ALPHABLEND_ON");
			material.DisableKeyword("_ALPHAPREMULTIPLY_ON");
			material.renderQueue = 3000;
			break;
		case BlendMode.Transparent:
			material.SetInt("_SrcBlend", (int)UnityEngine.Rendering.BlendMode.One);
			material.SetInt("_DstBlend", (int)UnityEngine.Rendering.BlendMode.OneMinusSrcAlpha);
			material.SetInt("_ZWrite", 0);
			material.DisableKeyword("_ALPHATEST_ON");
			material.DisableKeyword("_ALPHABLEND_ON");
			material.EnableKeyword("_ALPHAPREMULTIPLY_ON");
			material.renderQueue = 3000;
			break;
	}
}

As you can see, you need to set more variables in order to swap the rendering mode in real-time, so to switch an object from Opaque to Transparent you will have to do the following:

mat.SetFloat("_Mode", 3);
mat.SetInt("_SrcBlend", (int)UnityEngine.Rendering.BlendMode.One);
mat.SetInt("_DstBlend", (int)UnityEngine.Rendering.BlendMode.OneMinusSrcAlpha);
mat.SetInt("_ZWrite", 0);
mat.DisableKeyword("_ALPHATEST_ON");
mat.DisableKeyword("_ALPHABLEND_ON");
mat.EnableKeyword("_ALPHAPREMULTIPLY_ON");
mat.renderQueue = 3000;
Elwin Verploegen

Goodbye Maik. Hello Chris. There’s also a new office. February 12, 2015

By Elwin

January 22nd was the last day of Maik’s internship, we really enjoyed having him around and we’re looking forward to seeing what he will be able to do in the future, we’re sure it’ll be awesome! You already saw some of his modeling work in the Christmas banner.Fragments of Him ChristmasKaylee decided to stick around and work on her graduation project at SassyBot, more about that in the future (it’ll be really awesome, that we can say).

From left to right: Kaylee, Elwin, Maik & Tino

From left to right: Kaylee, Elwin, Maik & Tino

Meet Chris

Chris BrunneChris normally studies at the HKU in Hilversum but will be working on Fragments of Him for the next couple of months as part of his internship. If you played the prototype you might remember the restaurant scene, which is the first scene that Chris will tackle. Welcome to the team Chris!

The new office

Our current office is pretty sweet, but we got an opportunity to move into the newest location of the Dutch Game Garden (which happens to be near our current office). We’ll be moving there somewhere next week, assuming everything goes according to plan. We’ll be sure to post some pictures once we’re all settled down. We’ll be staying there for the foreseeable future and hopefully this location will become an amazing place for new game development studios. We’ll update you with the exact location once we’ve actually moved in.

New office

Sneak peek into the new office.

What we’ll be showing next time is a mystery

 

 

Tino van der Kraan

Dear Stranger Post-Mortem, Augmented Reality and an MDA Perspective January 16, 2015

By Tino

In the course of last year we, SassyBot Studio and Mattia Traverso, created an application called Dear Stranger. I have written a little bit about this before on our blog but the experience and lessons gained were otherwise largely left undocumented. What you read in this blog is my perspective on how we approached making Dear Stranger. Dear Stranger was the result of a 72 hour hackathon/game jam. Even though it has been quite a long time since we created this application, I have not yet taken the time to explain exactly what Dear Stranger is and how it was made. In order to make sense of it all, I will explain the event that motivated us to create Dear Stranger, the thought process behind creating it, and how it exactly works.

Hack the Park!

In June 2014 an event called Visual Design Week XS was organised to promote visual culture in Breda, The Netherlands. As part of this week a hackathon/game jam called ‘Hack the Park!’ was organised. This event was a competitive challenge with several constraints as well as a reward for the winning team. Some of the constraints were:

  • 72 hours to create either an application or a game based on the theme ‘Hidden Garden’
  • Up to 3 people per team
  • The use of augmented reality using Vuforia is mandatory and will need to use a provided target image
  • Needs to run on a smartphone

Design constraints are great for coming up with unique concepts and can help narrow the focus for new and refreshing concepts. It can also reveal possibilities that were otherwise not considered feasible.

The thoughts behind Dear Stranger

When you get to work with technology that is different from what you are used to it is often the challenge to imagine what the technology enables you to do which would otherwise not be possible. Of course you can use an existing game concept and make that work with new technology but is that really exploring the possibilities of that technology?

Some of the new possibilities that we arrived at included making use of the connectivity and mobility of the smartphones. Additionally, some phones have very cool tech such as gyroscopes, advanced cameras and powerful hardware. However, we knew that if we decided on using too much exotic tech that we could exclude certain users from using the app. Furthermore, in the case of gyroscopes we have noticed that this is not yet that reliable on different devices.

Keeping all of these things in mind we started brainstorming all kinds of crazy ideas. Eventually we landed on the idea of letting people leave hidden messages in plain sight. Considering the time and tech constraints we felt that this concept was simple in mechanics, could be executed nicely in terms of aesthetics, and would allow some interesting dynamics to emerge for its users. Furthermore, after getting the minimum viable experience up and running during the jam we were able to quite easily expand and polish onto this core concept. The concept finally evolved into the simple notion of having a public, but hidden, message board with a unique and fitting presentation. We called it, Dear Stranger.

Dear Stranger from an MDA framework perspective

Allow me to pitch to you the application that we created. “Dear Stranger is an augmented reality application for smartphones that lets the user leave a single message per day in the form of a flower. Users can read messages left by other strangers and tweet those you think are great. Explore a garden of thoughts and conversations as you see it grow over time.”

While we developed this application with user experience in mind I can’t help but notice that Dear Stranger lends itself nicely for an analysis using the Mechanics-Dynamics-Aesthetics (MDA) framework (R. Hunicke, M. LeBlanc, R. Zubek – 2001). To explain this framework briefly,

  • Mechanics: The rules
  • Dynamics: The player’s response and interactions being constrained by these rules
  • Aesthetics: The player’s sensory experience such as the look and feel

In the case of Dear Stranger this would look a little similar to this.

  • Mechanics: The application starts working if the software recognizes the trigger image required by the augmented reality system. When recognized, the user is prompted with instructions on first use. After having confirmed reading these instructions, the user can post a single message of 126 characters per day. The user can read and tweet messages. The time slider indicates what messages are shown based on the date and time of initial posting per message. When the software loses track of the trigger image it stops working, indicating that the system requires the image target to function.
  • Dynamics: The user response was to share personal experiences, greet others via Twitter, or set up little stories by responding to other messages. Using the time slider, the user would get interested by the appearing and disappearing of flowers. This possibly led to the reading of messages and inspired the user to respond. When exploring the limits of this application we found that users would sometimes carefully abuse the limitations to leave messages in strange places, such as up in the sky, behind the image target or behind the assumed starting location of the user. Another way the application was used is to make a picture of the image target and fool the system by having it recognise the target image on a display device rather than in the intended real environment.

  • Aesthetics: The application informs the user by using a minimalistic font that it requires an image target. When acquired, a stylized wooden sign is fitted over the image target formed out of tree trunks and leaves. Using text and images, the sign explains the concept, how to use the app, and where the presumed limitations of the app lie. The application then shows stylistically designed flowers, containing messages, on the screen with the camera’s real-time result as background. When tapping on a flower it opens a fitting general user interface (GUI) allowing the message to be read, tweeted, and closed. Each flower indicates, with colored and animated feedback, which flowers have been read or tweeted. An also minimalistically designed GUI in the bottom of the screen informs the player of the ability to scroll through the messages in time ranging from ‘Day 1′ to ‘Today’. When scrolling this time slider, flowers will pop out of the ground or sink back in depending on when the message was posted or planted. The flowers and sign are enhanced by illusions of shadows and particles are used to simulate fireflies. Soothing music plays throughout the application and sound effects are prompted when the player interacts with the flowers or buttons on the interface.

Behind the Scenes

This application was developed using Unity3D 4.3.x and made use of a plugin from Qualcomm called Vuforia. The models were created in 3Ds Max and the textures were hand painted in Photoshop CS6 using a Wacom Bamboo drawing tablet. The interface assets were also designed using Photoshop CS6. The flowers are coloured using vertex paint in 3ds Max. We used a custom shader in Unity3D, limiting us to 300 vertices per flower. The reason for staying below that specific vertex count is so that we can make use of dynamic batching which is a blessing for performance on mobile devices.

Flowers

Flowers – Click to enlarge

Batching

Draw call batching – Click to enlarge

Textures were, for the most part, placed on a couple of texture atlases before implementation in Unity in order to save memory and processing power. Player feedback on the flowers consisted of an animated sprite, aimed at the camera, that changed animation behaviour or colour depending on whether it was read or tweeted. Extra attention to detail was spent on animating the GUI by scaling when prompted, sliding text in from the side, and briefly highlighting a button to indicate it was pressed. An orthographic Unity camera was used to render the interface on top of the augmented reality layer. More about layering cameras can be read in our Elimu post-mortem.

InterfaceAssets

GUI atlas – Click to enlarge

We limited the user to 126 characters so that we had 14 characters left to add ” #DearStranger” allowing us to comply with Twitter’s character limit. To store and pull user messages we used a database that would keep track of what the message contained and when it was posted. Using these dates we could set up a normalized slider that ranges from first posted message to the last posted message. To make the placement of custom text easy we used a small script that allows for word wrapping. When typing a message the application will use the keyboard provided by the smartphone’s OS.

Hopefully this article has given you sufficient insight in how Dear Stranger was created and some of the though processes behind it. If anything is unclear then I am happy to elaborate. Please get in touch via @tinovdk with any questions and I’ll help to the best of my ability.

[Update] Added credits and a disclaimer

Elwin Verploegen

Tutorial: Extending The Unity3D Editor December 22, 2014

By Elwin

Extending the Unity3D editor is one of the best features of the engine. If you want to see how this is useful in an actual project, you can read our blog post on our Dialogue Editor or Interaction Tool. In this tutorial I will teach you the basics on how to create your own editor scripts, which will hopefully get you going in creating amazing tools for your project. I’ll be doing this in Unity 5.0.0b17, but anything here should work just fine in Unity 4.6 (and probably below that as well). Whenever I add or change code to a script I will highlight it in a dark green.

I’ll be going through all the steps with you to get your first editor script going, this will include creating the window and modifying variables of a script on an object in the scene. If anything is unclear please send me a tweet and I’ll try to help you out.

Getting started

Start by creating a new project and adding a folder named Editor in the Assets directory, this is where we’ll be working from most of the time. Let’s create a file named ObjectSetter in the Editor folder, open that and drop in the following code:

using UnityEditor;
using System.Collections;

public class ObjectSetter : EditorWindow {

}

The above code is the start of any editor window script. A difference with a regular script is that instead of using UnityEngine; we are using UnityEditor;. This allows us to use the UnityEditor namespace. Another point to remember is that instead of extending MonoBehaviour (like a regular script would do), we’re extending EditorWindow. Before we continue make sure that your Project panel looks like this:

Unity3D Project Panel

Current project panel.

 Adding a menu button

Next up is adding a button in the toolbar at the top of the window. We’ll be adding a button under the Tools button, so that you’ll have to click on Tools first, followed by ObjectSetter. This is how that will look:

Toolbar

Toolbar

using UnityEditor;
using System.Collections;

public class ObjectSetter : EditorWindow {

    [MenuItem ("Tools/ObjectSetter")] //Add a menu item to the toolbar
    static void OpenWindow(){
    }
}

The first line of code that was added creates a new menu item in the tool bar, which is fairly dynamic. You can add pretty much type any path there and Unity will generate the button for you. You can even add a shortcut for the button. You can read how to do that in the Unity documentation over here.

Create a custom window

Now that we have a button in the toolbar, we can create a window and add a button in it. Let’s start with creating a window.

using UnityEditor;
using System.Collections;

public class ObjectSetter : EditorWindow {

    public static ObjectSetter window;

    [MenuItem ("Tools/ObjectSetter")]
    public static void OpenWindow(){
        window = (ObjectSetter)EditorWindow.GetWindow(typeof(ObjectSetter)); //create a window
        window.title = "Object Setter"; //set a window title
    }
}

First we create a new variable called window, this will (as the name suggests) hold the window. In the OpenWindow function we added 2 lines of the code. The first line calls EditorWindow.GetWindow(), this function returns the first EditorWindow of type ObjectSetter. If it doesn’t exist it will create one and return that instance. We then save that in our window variable. Try changing the title of the window to something else and see what happens.

If you just changed the code and nothing happened, you are absolutely correct. The OpenWindow function is only called when you press the button in the toolbar. This means that whenever you make a change you will have to press the button to make sure you can see the change. This is obviously very annoying when trying to debug, so let’s start with adding some code to fix that.

using UnityEditor;
using System.Collections;

public class ObjectSetter : EditorWindow {

    public static ObjectSetter window;

    [MenuItem ("Tools/ObjectSetter")]
    public static void OpenWindow(){
        window = (ObjectSetter)EditorWindow.GetWindow(typeof(ObjectSetter)); //create a window
        window.title = "Object Setter"; //set a window title
    }

    void OnGUI(){
        if(window == null)
            OpenWindow();
    }
}

Here we added the OnGUI function (you’re probably familiar with this function, as it can also be used in regular scripts). We’ll add a little trick where we check if the window variable is set to null, if it’s null we call OpenWindow again, setting the default variables again. Every time Unity compiles script, it will reset static variables. Whenever you change some code all you have to do is click on the editor window to focus it to reload the code.

Now that we have the OnGUI function, we can add a button to it. To create a button we have to use the normal GUI.Button function. To do so we have to include the UnityEngine namespace. You can use all of the regular GUI functions, but you also have access to the EditorGUI functions, which we’ll use a bit later. This is how it will look for now:

Editor Window button

Editor Window button

using UnityEditor;
using UnityEngine;
using System.Collections;

public class ObjectSetter : EditorWindow {

    public static ObjectSetter window;

    [MenuItem ("Tools/ObjectSetter")]
    public static void OpenWindow(){
        window = (ObjectSetter)EditorWindow.GetWindow(typeof(ObjectSetter)); //create a window
        window.title = "Object Setter"; //set a window title
    }

    void OnGUI(){
        if(window == null)
            OpenWindow();

        if(GUI.Button(new Rect(0, 0, position.width, position.height), "Press me")){
            Debug.Log("hodor");
        }
    }
}

With those lines added you should now see a button that fills up the window, and when you press it you should see hodor printed in your console. To get the size of the window, we use position.width & position.height, these are both properties of EditorWindow.position.

Create placeholder scripts & objects

Before we continue with actually modifying variables of an object through our script, let’s start by adding a cube to the scene and applying a script to it named DataHolder, this is just a script where we can modify some things to show that it all works. DataHolder looks like this:

using UnityEngine;
using System.Collections;

public class DataHolder : MonoBehaviour {

    public GameObject cam;
    public int health;
    public string username;

}

This is now how my scene hierarchy & project panel looks. Don’t forget to add the DataHolder script to the Cube!

Hierarchy & Project Panels

Hierarchy & Project Panels

Modifying the DataHolder variables

Here is where it gets a bit more complex, as we need to write a bit more code to get things working. Let’s start by grabbing the currently selected object so that we can manipulate it.

using UnityEditor;
using UnityEngine;
using System.Collections;

public class ObjectSetter : EditorWindow {

    public static ObjectSetter window;
    private static GameObject obj;

    [MenuItem ("Tools/ObjectSetter")]
    public static void OpenWindow(){
        window = (ObjectSetter)EditorWindow.GetWindow(typeof(ObjectSetter)); //create a window
        window.title = "Object Setter"; //set a window title
}

    void OnGUI(){
        if(window == null)
            OpenWindow();

        if(Selection.activeGameObject != null){
            //gets the object you currently have selected in the scene view
            obj = Selection.activeGameObject;
            GUI.Label(new Rect(0, 0, position.width, 25), "Current selected object: " + obj.name);
        }
    }

    void Update(){
        Repaint();
    }
}

I took out the button, because we won’t be needing that anymore. At the top I’ve added a variable called obj, I like to have this for easy access throughout this script (I usually have to refer to this quite often, so doing less typing is favourable to me). In the OnGUI function we then make use of the very handy Selection.activeGameObject. This variable holds the GameObject that you have currently selected in the scene.

Next, we check if you actually have something selected and then set obj to that object. After that we simply print the name of that object in the window using the regular GUI.Label.

We also added an Update function, this functions the same as in a regular script and will be called every frame. The Repaint function in there makes sure that our custom window is redrawn every frame. Click on different objects in the scene and watch the text in the window change. If you try commenting out the repaint function you will notice that the text only changes when you focus back on the window.

Now that we have the object we can move on and start modifying the variables in DataHolder. This is how it should look after applying the modifications below:

Editor Window with variable fields

Editor Window with variable fields

using UnityEditor;
using UnityEngine;
using System.Collections;

public class ObjectSetter : EditorWindow {

    public static ObjectSetter window;
    private static GameObject obj;

    [MenuItem ("Tools/ObjectSetter")]
    public static void OpenWindow(){
        window = (ObjectSetter)EditorWindow.GetWindow(typeof(ObjectSetter)); //create a window
        window.title = "Object Setter"; //set a window title
    }

    void OnGUI(){
        if(window == null)
            OpenWindow();

        if(Selection.activeGameObject != null){
            //gets the object you currently have selected in the scene view
            obj = Selection.activeGameObject;
            GUI.Label(new Rect(5, 0, position.width-10, 25), "Current selected object: " + obj.name);

            //make sure to only show the interface
            DataHolder comp = obj.GetComponent<DataHolder>();
            if(comp != null){
                comp.health = EditorGUI.IntField(
                    new Rect(5, 30, position.width-10, 16), 
                    "Health", 
                    comp.health
                );
                comp.username = EditorGUI.TextField(
                    new Rect(5, 50, position.width-10, 16), 
                    "User Name", 
                    comp.username
                );
                comp.cam = (GameObject) EditorGUI.ObjectField(
                    new Rect(5, 70, position.width-10, 16), 
                    "Camera GameObject", 
                    comp.cam, 
                    typeof(GameObject)
                );
            }
        }
    }

    void Update(){
        Repaint();
    }
}

We first try to get the DataHolder component from the selected object. If it has one, we show 3 EditorGUI fields. These generally have the same layout and will become familiar pretty fast, a list of all possibilities can be found over at the EditorGUI documentation. The 3rd variable field requires most work, but is very useful. You can essentially put any object type in there, this allows you to grab components from GameObjects (e.g. scripts, colliders, renderers, etc.).

To see this working, just select any object with the DataHolder script attached to it. Now change some of the variables or drag in a GameObject into the “Camera GameObject” field. Keep an eye on the inspector and you should see those variables change in real-time. Congratulations, you just created your first Editor script and are now ready to conquer the world! Let’s add some more small features though.

Create DataHolder

When the user selects a cube that doesn’t have a script we don’t want to manually drag in the script on the GameObject. Instead, we’ll add a button to add the component to the GameObject.

using UnityEditor;
using UnityEngine;
using System.Collections;

public class ObjectSetter : EditorWindow {

    public static ObjectSetter window;
    private static GameObject obj;

    [MenuItem ("Tools/ObjectSetter")]
    public static void OpenWindow(){
        window = (ObjectSetter)EditorWindow.GetWindow(typeof(ObjectSetter)); //create a window
        window.title = "Object Setter"; //set a window title
    }

    void OnGUI(){
        if(window == null)
            OpenWindow();

        if(Selection.activeGameObject != null){
            //gets the object you currently have selected in the scene view
            obj = Selection.activeGameObject;
            GUI.Label(new Rect(5, 5, position.width-10, 25), "Current selected object: " + obj.name);

            //make sure to only show the interface
            DataHolder comp = obj.GetComponent<DataHolder>();
            if(comp != null){
                comp.health = EditorGUI.IntField(
                    new Rect(5, 30, position.width-10, 16), 
                    "Health", 
                    comp.health
                );
                comp.username = EditorGUI.TextField(
                    new Rect(5, 50, position.width-10, 16), 
                    "User Name", 
                    comp.username
                );
                comp.cam = (GameObject) EditorGUI.ObjectField(
                    new Rect(5, 70, position.width-10, 16), 
                    "Camera GameObject", 
                    comp.cam, 
                    typeof(GameObject)
                );
            }
            else{
                if(GUI.Button(new Rect(5, 30, position.width-10, position.height-40), 
                "Add DataHolder")){
                    obj.AddComponent<DataHolder>();
                }
            }
        }
    }

    void Update(){
        Repaint();
    }
}

Now try creating a new cube and select that. The window should now show 1 big button that says “Add DataHolder”. Pressing that will add a component to the selected object, namely DataHolder. Once you press the button, it will disappear and the regular interface will show up again, this is because every frame it will check if the current object has the DataHolder component selected.

Conclusion

If you did everything as instructed, you should now have 1 window that looks like the left one when you have a normal GameObject selected. When you select an object with a DataHolder you will see the screen on the right.

The final result

The final result

That’s it for this blog. This knowledge should be enough to create very powerful editor scripts (you can probably recreate 90% of my Interaction Editor with just the above knowledge). Next time I’ll show you some useful functions to make everything a bit prettier and easier to work with from a user perspective.

If you have any questions or remarks, don’t hesitate to get in touch with me via Twitter.

Let’s add some more features in the next part in this tutorial.