The Evolution of Aiming in Voyager

Voyager is a game is about science. Not just in the “you’re launching a space probe” sense, but in that the core loop is about experimentation. Make a hypothesis (I need to launch at about 45°), perform the test (3, 2, 1… LIFTOFF), observe the result (missed wide right!), refine the hypothesis (let’s try 30° next time). It took a long time to figure out how to make this process feel natural and intuitive.

In order for it to work, the game needed three things:

  • Feedback: I need to be able to tell how my current aim differs from my last aim.
  • Determinability: If I do the same thing two different times, I should get the same result both times.
  • Precision: I should be able to execute the move as I intended. If I try to launch at an angle of 19°, I should not accidentally launch at 20° or 18° instead.

Solving feedback was the easiest part. The aiming mechanism is very explicit, with an arrow showing the direction and relative power the probe will launch in. Previous launches are shown as dimmer arrows, so the player can easily line up a similar shot and tell how their new one differs. It also straight up tells the user the angle and power of their shot in text, so the values can be written down and reused later. And finally, in-flight probes leave a trail of breadcrumbs, so it’s easy to tell when and how a trajectory diverges from an older one.

Aiming Launch

So much feedback

Continue reading

Dependency Provider

NOTE: I no longer use, or recommend, the DependencyProvider. There are a number of reasons why this is the case, not the least of which because it didn’t work on certain platforms. But by not using it, I found myself missing its ability to cache found references to speed up lookup time, and didn’t need the object instantiation and lifetime management stuff so much. So I kept what I liked, ditched what I didn’t, and ended up with the much simpler DependencyLocator I now use in lieu of FindObjectOfType.

// --------------------------------
// <copyright file="DependencyLocator.cs" company="Rumor Games">
//     Copyright (C) Rumor Games, LLC.  All rights reserved.
// </copyright>
// --------------------------------

using System;
using System.Collections.Generic;
using UnityEngine;

/// <summary>
/// DependencyLocator class.
/// </summary>
public class DependencyLocator : MonoBehaviour
{
    /// <summary>
    /// Cached DependencyLocator instance.
    /// </summary>
    private static DependencyLocator dependencyLocator;

    /// <summary>
    /// Cache references to component instances.
    /// </summary>
    private readonly IDictionary<Type, Component> instances = new Dictionary<Type, Component>();

    /// <summary>
    /// Locate an instance of the given component type.
    /// </summary>
    /// <typeparam name="T">Type of component to locate.</typeparam>
    /// <returns>Instance of the desired component.</returns>
    public static T Find<T>() where T : Component
    {
        // check whether we have a dependency locator instance
        if (dependencyLocator == null)
        {
            // create a new game object and attach our component
            var gameObject = new GameObject(typeof(DependencyLocator).ToString());
            dependencyLocator = gameObject.AddComponent<DependencyLocator>(); 
        }

        // ask scene dependency locator for a scene instance
        return dependencyLocator.Get<T>();
    }

    /// <summary>
    /// Provide an instance of the given component type by retrieving it from the cache or finding one in the scene.
    /// </summary>
    /// <typeparam name="T">Type of component to provide.</typeparam>
    /// <returns>Instance of the desired component.</returns>
    public T Get<T>() where T : Component
    {
        var type = typeof(T);
        if (!this.instances.ContainsKey(type))
        {
            this.instances.Add(type, FindObjectOfType<T>());
        }

        return (T)this.instances[type];
    }
}

Original post:

Previously, I wrote about the process of locating dependencies in Unity. I enumerated some of the reasons the singleton pattern leads to bad practice, and how good process lead to better, more maintainable code.

And fine, I’ll admit it. I think singletons are ugly and I don’t like them:

TypicalSingleton.Instance.DoSomething(); // gross

Instead, I’d like to offer an alternative, one that doesn’t require a bunch of boilerplate code in every class I want to make globally and performantly accessible. Continue reading

Locating Dependencies

Most components don’t exist in isolation. Sooner or later, they’re going to need to talk to each other, which raises the question of how they should acquire references to one another. In Unity, this is easily accomplished in the editor: expose the type you’re looking for as a public field, then wire it up in the inspector by dragging an instance of the dependency onto the field. I actually really like this approach! It’s essentially a form of dependency injection. This works well for objects in a scene, or relationships between different scripts in a prefab, but it isn’t well suited for items instantiated at runtime. It’s also brittle, since changing the type expected or provided will break the association. These situations call for a different approach to locating dependencies.

Continue reading