This week marks six months since we set out on this adventure of ours. In that time, we’ve lived in six different countries – Thailand, Malaysia, Portugal, Spain, Croatia, and now Romania. We’ve flown more than 30000km, or about 3/4 of a lap around the world. We celebrated New Year’s Eve with paper lanterns in Chiang Mai, Thaipusam in Georgetown, Easter in Barcelona, and the new season of Game of Thrones in King’s Landing Dubrovnik. We ate some of the best street food of our lives: khao soi, char koay teow, mee goreng, hokkien mee, mee sotong, pastéis de nata, pintxos, ćevapi, and so much more. And we visited a ridiculous number of castles.

So many castles

I say this not to brag – well, not just to brag – but to attempt to put into perspective the intangibles that make this trip so worthwhile to us. The tangibles, namely that we’re still on track to spend less than we would in a typical year of modest living in Seattle, are the real reason we can pull this off.

On that note, I’d like to talk a little more about how we manage our lives on this unusual trip.

As much as I love BindableValues, there are still some features that are frustratingly out of reach. First and foremost, I wish we lived in a world where enumerations in C# implemented IEquatable, so they could be made bindable. Despite throwing a couple of workarounds their way, nothing was ever good enough to stick, and my enumerated values continued to loll about, unbound. I couldn’t take it anymore! I settled on a solution that was disappointingly duplicative, but practical: clone the functionality of BindableValues to create a new wrapper specifically for enumerations.

Global Game Jam 2014. It’s late Saturday night, on the eve of our home stretch. My team was well ahead of schedule. We’d gone with an unusual project, a card game, so we’d been playtesting in no time, working well together all weekend and making great progress. Many hands make light work, and with ten people on our team, work was plenty light.

But with everything going so smoothly, it was almost as if I was missing out on the real jam experience. Looking around at the other teams struggling to finish, I almost felt… guilty. So, I decided to up the challenge for myself a bit. As the clock rolled over midnight – less than a day to go – I popped open Unity and started working on a second game, this time on my own.

The next step up from simple events is the complete decoupling of the event publisher and event receiver through an event aggregator. Consider the case of a game over message. The game is decided to end by a rule manager class. Lots of things want to subscribe to this event: the game over UI, the input manager, any systems that spawn players or items or track score. But aside from the game over state, none of those systems have any reason to take a dependency on the rule manager. Instead, we’d like to abstract the publishing of events and receiving of them through an intermediary: the event aggregator.

I’ve seen several event dispatching solutions for sale on the Asset Store, but I decided to roll my own. I based my approach on the EventAggregator from Microsoft’s wonderful Prism library.

A while back I had an idea for a game about launching rockets. Way out of my comfort zone, right? Basically it would be a blend of the engineering and rocket building of Kerbal Space Program, but with a greater emphasis on moment-to-moment skill instead of meticulous planning. I took about a day to prototype the idea, and while I’m not sure if I’m going to do something with it in the future, I did find myself spending a lot more time playing with it than I did building it!

[unfortunately, the Unity Webplayer has been sunsetted, so this demo is no longer available]

Directions: Hold mouse button down to thrust, release to separate stage. Hold down A or D to steer left or right. Reset with Esc.

While the implementation was extremely basic, it was effective at proving the idea and teaching me some interesting things that might be useful later.

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.

The Singleton pattern is often usedoverused abused in Unity to take advantage of its global access properties. I find it is usually better practice to address those requirements through other means. However, that still leaves the common and legitimate need for enforced singularity.

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.

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

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.