Meditations, experiences and visions of code

You’ve probably already seen plenty of articles, threads, snippets and Gists about this very topic, such as this one in particular. Therefore I won’t bore you with how these work or try recycling commonly-used methods posted elsewhere. I personally do not find a lot of them that useful, especially as optimizations, such as setting single X,Y,Z values; I find it just as readable to create a new Vector in my view logic.

Rather, I have decided to start a post including some that I have created, elaborated on, or rewrote for my personal use. This list will be kept up-to-date and hopefully someone will find one or more helpful to them as well.

GetChild[ren]WithTag

To start out, with my own workflow and scene organization, there is a need to grab a child of an object by a unique tag. The following are both single object and array forms:

I had some quick thoughts I figured I’d jot down here as I received my PlayStation 4, the first console I preordered since the Dreamcast on 9/9/99. (Still my reigning all-time favorite console, ever~!) When I got home from work, I swiftly unboxed, hooked up, and turned it on. I ooh‘ed and aah‘ed at the lovely new DualShock controller, which I have to say is the nicest controller I’ve ever used [read: to navigate around menus and use a virtual keyboard]. (Take note: Ouya, this is how to make a controller!)

However, after updating the system and trying to sign into PSN I was greeted with some extremely helpful errors:

The final piece of the camera system is comprised of the Unity-specific behavior, or all lifetime methods within the MonoBehaviour pipeline. The first part of the system described separating out concerns of our business logic from that which diverges the often chaotic View out on its own. In the end, we will end up with two uniquely functioning entities within timings of their own that Strange manages for us so we don’t have to worry about cluttering all spaces of our app into Unity scripts.

When the time comes that we need to adjust view related behavior, we have peace of mind that it already comes insulated for us so that any adverse effects do not pop up elsewhere and go unnoticed; so long as we are also properly unit testing, in the case that this does happen, it will be caught quickly as a regression.

While prototyping out a recent project, I found it quite easy to make an interesting, dynamic camera with StrangeIoC serving as the backbone. Once setting up the necessary bindings and creating unique Signals that will be dispatched throughout, certain stateful information and a View to perform Unity-specific Camera operations can be achieved with ease.

I’ve decided to split this up into several parts. The first being initial Strange setup and business logic, allowing time for proper unit test coverage; the second focusing on implementing the view in Unity; and perhaps eventually a follow-up on behavior testing the areas the unit tests don’t cover. Unfortunately, the only BDD libraries I’ve seen require an iOS/Android Pro license for .NET Sockets usage.

Unity scripting can become cumbersome at times without a clear-cut discipline, organization, or framework. Being a component-based design, attaching/detaching or enabling/disabling script “components” on a GameObject which must inherit from a MonoBehavior can get rather clunky with added complexity. Oftentimes we wish to introduce business logic or maintain state without caring about UnityEngine dependencies, and simply hope that it does not alter unrelated functionality, throw off timing, or produce unexpected oddities in other areas of the project.

Enter StrangeIoC. A marvelous, lightweight inversion-of-control framework that offers key features to protect us from inevitable annoyances witnessed in pure Unity architectures. As a classic MVCS, sequestering Unity-related behavior in a View is characterized with this virtue in mind:

“Insulate your app from the chaos often present in views. Mediation allows clean separation of Views from Controllers and Models with no loss of capability.”

The OUYA SDK (ODK) pre-alpha preview was released last week, and I’ve been very anxious to tinker with it, especially to see how well it works with Unity3D, ever since backing the Kickstarter. There is a *.unitypackage file included in the ODK samples that has all the library *.jar files; some sample scenes, assets and scripts; SDK wrappers for Unity; an Editor panel script to hook the necessary libraries up; and Android application specific sources. The ODK seems to be more of a wrapper at this point, though many of the helper functions interface especially well with Unity3D, such as Input. It is quite extensive already for such an early release, which should be a welcome sign to those who backed it.

All things aside, I recommend reading the ODK Developer Documentation, running through the Setup section as well as the GitHub Documentation @ouya/docs. Most of the initial setup of application toolchains require a bit of tinkering before being able to delve in and create and test.

While creating the gameplay for Prim, one of the major hurdles I faced was detecting if a block group had been completed (as a full, filled-in shape) or not. The starting state of a block group in Prim is an incomplete polygon that is rectangular or square in shape. For example, a 3×3 square that the top row is filled in, and one block on each side down the other 2 rows. All starting shapes must follow a couple logical stipulations such as the open spaces of the shape must be able to be filled in from bottom-to-top; in other words, all shapes must be able to be filled in somehow by firing new blocks onto them. The calculation of the block group “completed” flag needed to be done on various occasions:

When a block projectile collided with a group, attached itself, and grouped with this block group

When a block group reached the end of the playfield and a row of blocks fell off the edge

Animation tweening libraries are in full force on the Unity Store. The most popular of which, iTween, has plenty of niceties in it including Editor tools, but is far too clunky for mobile device usage. The main reason behind this is that each tween is created with Instantiate and finished with Destroy; extrapolate this X times on Y amount of objects in real-time and the amount of garbage collection mounts up, causing major slowdowns and chugs.

I stumbled upon a really nice, lightweight tweening library on Unify Community called AniMate a while back, written in Boo originally. At the time of using this library, iOS did not support Boo (Python) to be deployed to it, so I ended up converting it to C#. It works fundamentally different from iTween so if you need something fast and easy, that won’t require a ridiculous amount of GC, this is pretty handy for small projects that use assets that don’t require actual Animation components.