In a previous post (Custom Editors in Unity – C# Example), I demonstrated the use of properties and custom editors to ensure that scripts always receive valid values. Recent changes in Unity have rendered this approach ineffective in Unity 3.5, so I present here an updated approach that is almost as good. Thanks to Stefan for pointing out that this had stopped working.

As with the previous approach, this is based on the Unity Script Reference – info on making a custom editor but I will use C# instead of JavaScript. I will assume you’ve read the previous post, so check that out if you get lost.

The script for which a custom editor will be written is very similar to the script in the previous example, but with one important change:

// MyScript.cs
using UnityEngine;

public class MyScript : MonoBehaviour {

	private int myValue;

	// property is not used by custom editor,
	// but is used to ensure valid values from other scripts
	public int MyValue {
		get { return myValue; }
		set {
			// MyValue should be between 1 and 10
			myValue = Mathf.Clamp(MyValue, 1, 10);

	void Update () {
		// do something with MyValue

Note the addition of [SerializeField] on the private field. This makes the value of the private field available for the more advanced custom editor that will be used.

// MyScriptEditor.cs
using UnityEditor;
using UnityEngine;
using System.Collections;

public class MyScriptEditor : Editor {

	SerializedProperty valueProperty;

	void OnEnable() {
		// Setup serialized property
		valueProperty = serializedObject.FindProperty("myValue");

	public override void OnInspectorGUI() {
		// Update the serializedProperty
		// always do this at the start of OnInspectorGUI
		EditorGUILayout.IntSlider(valueProperty, 1, 10, new GUIContent("My Value"));


There are a few differences here from the previous editor script. First is the [CanEditMultipleObjects] annotation. This allows this editor to be used to modify the values of multiple selected objects at the same time.

The next addition is a SerializedProperty that will hold a reference to the value that we’re modifying. The reference is set up in OnEnable(), by looking up the property by name (in this case the name of the private field with the [SerializeField] annotation).

With the property reference set up, the property is then used in OnInspectorGUI to be set by a slider. Note that a different method is used here than in the previous example, a method which takes a SerializedProperty argument. Check out the script reference for methods with SerializedProperty arguments that can be used, for example they are found near the bottom of the page on the reference page on EditorGUILayout.intSlider.

Finally, note that since we are now referring to a serialized object, we need to ensure that it is properly synchronized, so we call Update() before making changes to the properties, and ApplyModifiedProperties() when the changes are made.

And that’s the best we can do without getting overly complicated. Strictly speaking it is still possible for an invalid value to be set in the field by deserializing a serialized object that has an invalid value, which could happen if we have an object that hasn’t been updated since we changed the valid range. Things start to get a bit complicated trying to eliminate this little validation gap so I’ll leave it un-filled, but I did suggest an idea of how to approach it in a comment on my previous example.

Note: I will be switching to Unity 4 tomorrow, so I’ll likely make another example shortly for that. I’ll keep my 3.5 install around so feel free to ask any questions and I’ll do my best to help out.

Happy coding 🙂

My game-in-a-week challenge was a great motivator to get something done in a short time. An extremely short time really, because in development time is always short no matter how much of it you have.

The ‘challenge’ approach (really just a re-branding of setting ambitious goals) worked well to keep me motivated despite the drain of my day job and other commitments, so I will stick with it. This time there will be a major difference. A week is enough time to make a simple prototype, but certainly not to make something complete or polished. My next challenge will be longer.

How much longer? This time I want it to be long enough to go through the full process and make something complete, including play-testing, polish and release. I’m giving myself a year.

Sounds pretty laid-back, right?
Think again!

There are plenty of reasons that game-in-a-year is a very tight schedule for me at the moment:

  • I’m only one hobbyist – I have full-time work that takes a lot of my time and energy. I can only really expect to get about 1-2 person-days worth of development done in a good week – the equivalent of about 10-20 development-weeks over the whole year.
  • I’m still learning the tools – I expect to find plenty of holes in my experience as I go through the full process of development up to release, and each of them will take extra time to get up to speed.
  • The play-testing and release process – I’m allocating 6 months to get through testing, bug-fixes and the release process. Why so long? I anticipate finding plenty of aspects I haven’t thought of or that are out of my control. I’ve heard plenty of stories of release delays so I’m allowing a large buffer to make sure I can release before the end of 2013, as well as to allow some leeway for making the release at an appropriate time. This halves my effective development time, bringing it down to the equivalent of 5-10 weeks. Not such a long time for a polished game, even a simple one.
  • I’m ambitious – you didn’t really think I’d just aim to do one thing in a whole year, did you? I’ll need something to do during the anticipated delays in the release process, and I intend to be well set-up for development in 2014, so I’m doing a lot of groundwork this year. I’ll be getting a second game (a networked multiplayer RTS) to beta standard before the year-end holidays (when I intend to recruit plenty of friends to do play-testing and get it balanced), as well as throwing together 5 prototypes in the second half of 2013 – these will form the basis of a pool from which I’ll choose future projects.

So that’s my new ridiculous challenge. Check back soon for details on the games – I’ll aim to keep a record of my progress fairly up-to-date here, add posts when interesting things happen, and let readers have some input into the direction things take.

Day 7 – Audio Antics

Development time: 20 minutes (running total: 1340 minutes).

Four simple audio samples make a big difference to the feel of the game.
Just a quick addition this morning to round things out. I used my chest, a role of tape and my own voice to sample a few sound effects. The audio isn’t very clean, but it’s certainly good enough for a last second addition before wrapping up the project. I attached the spark noise to the particle emitter prefab that does the spark effect, letting it play when instantiated; for the enemy I added two audio sources for when they’re hit and access them as an array, playing a more crackly sound when they die or if they’re already dead; for the scientists I have a single sound play when an enemy attaches to them.

Goal for the next week: deploy somewhere

With sound, I’m now happy enough to call the project complete, but there is still some work to be done. What good is jamming together a game in a very short space if I don’t share its hurried glory with the world? Stay tuned for a playable web version as soon as I can sort out some hosting, and a wrap-up post with some final thoughts on the project.