Prototypes and practice vs. theory

People in Love gameFollowing my own preaching about the importance of prototypes, I’ve put together a quick and dirty prototype of People in Love, a game about urban design and quality of life. Or about love. The prototype is here and I got some interesting feedback.

Now what happens? Well, I throw away the prototype and build a new one. Based on user feedback? Well, not exactly.

This first prototype (actually n-th, first shared with more than 2 people) got me to find a way to include graphical narrative and hence give depth to play, which will be my next prototype. No tester asked for this in clear words, but it is what puts together the feedback I had.

This on the background of my testing many creative games and extensive readings on games and narrative. The critique of your prototype is non trivial and requires a background theory.

User will provide a refined usage feedback in action, but likely a rough and maybe misleading theory about it (Jeff Atwood wrote a beautiful post on this). You have to know the context and put the puzzle together.

So prototyping is a productive tool if in the context of an intense research; it lives by research, it is a form of research, not a replacement of it.

Feeling better now I said it clearly :-)

Follow me on Twitter where I post about game design, game development, Unity3d 2D, HTML5, serious games.

Social Share Toolbar

A note of the wild use of “if(object)” in Unity’s C# code

Looking at other people’s C# code for Unity, I kept seeing this bizarre usage of if:

if (object) { …}

where object was a real object, not a bool instance. This is a JavaScript kind of usage, where there is a big (perceived) mess about object and value types, so I wondered how did C# “automagically” cast to bool? You cannot do that in classical typed OOP languages like Java.

Turns out there is nothing about this in C# itself, its MonoBehaviour that implements implicit boolean casting

public static implicit operator bool($classname$ me){
return me != null;

Actually you will have to navigate the hierarchy up to Unity’s Object to find it. See also here.

But if you are learning C# with Unity, be careful as “This can be really confusing because that behavior doesn’t carry over when you start using standard .net libraries and other 3rd party code that is agnostic to Unity.” – here.

And neither it will when writing your classes, when not extending MonoBehaviour, so its not a healthy habit to catch.

Follow me on Twitter where I post about game design, game development, Unity3d 2D, HTML5, serious games.

Social Share Toolbar

A note on slimy static Unity3d gameObject instances

A quick note on the state of C# static variable instances in Unity3d.

So I just discovered that static properties of classes extending MonoBehaviour on level reload may get reloaded or not, depending on circumstances.

The problem is this: you may need in your game development to have a singleton manager class instance which is also a game object. [Read more…]

Social Share Toolbar