Dirty Prototypes

Do things quickly, do things cheaply. Get answers fast!

Originally this post was supposed to be about prototypes in general, but with the popularity of scrum and agile these days I think everyone knows what prototyping is about.  What I want to emphasize dirty prototypes.  What I mean by this is creating extremely low fidelity prototypes.  I think a lot of time is wasted when people get carried away and start paying attention to adding in details, me included.  If I took this lesson to heart earlier in my career, I think I would have been able to catch many more mistakes earlier.

Why I advocate for developing tests quickly is to get results as soon as possible.  You ask a question, you want those answers now in order to stay ahead of the curve.  These answers may even tell you that the direction you’re going in is also just wrong.  And because you’ve spent so little time invested in a wrong idea, you’re more likely to set it aside and revisit it later while moving on to something else.

I think the practice and habits are obvious.  Scribble things on paper.  Only spend a couple of hours coding something, hacking, in a separate Unity project.  Get those cubes dancing.  Get it out to your peers and coworkers and get their opinions.  As a game designer, you must be ruthless and always follow a crumb trail of where tests lead you.  Create a dirty prototype with your gut instincts (don’t spend hours looking for damn metrics, that can also waste your time) and test.  That test is your metric.  It will tell you if your idea is good or bad or needs some more work.

Relentless.  Ruthless.  Ever-producing.

Building a better UI workflow in Unity

A lot of people ask us about our thoughts on Unity as an environment, and I thought I’d share a bit of one system I’ve been working on recently.

Typically, we have only good things to say about Unity – however, our common complaints relate to the UI system(s).  The 2.0 immediate mode OnGUI is quite configurable, but it gobbles performance – and isn’t artist friendly.  It can be very powerful, but layouts are complicated and unintuitive – and did I mention it eats performance?  While we use it heavily for editor GUI development, we consider it unusable in a game runtime environment.

Unity 1.0 GUITexture and GUIText on the other hand are simple to layout and use, and performant, but not nearly feature complete.  I’ve worked with sprite based solutions as well, but hate the frequent pixel imperfect rendering and aliasing issues – along with the inability to display Unity’s super-cool dynamic fonts – essential for the display of asian character sets.  Sidenote to devs at Unity – Feature requests here: Please expose the UVs of dynamic fonts for consumption by alternate UI display libraries.

What we really needed, was the simplicity of 1.0 GUI layouts – with the power of Unity GUI 2.0.

Enter my most recent custom GUI layout solution, built entirely on top of 1.0 GUITexture and GUIText.  This system could easily support alternative rendering methods, such as a sprite system, however, I’ve chosen to use 1.0 GUI.  Without further ado:

Unity GUI UITransform
Unity UI, herpa derp!

 

Continue reading “Building a better UI workflow in Unity”