Tuesday, 31 March 2015

Unity 3D: Using curves in inspectors

Today I took a quick jab at using curves in edit mode.
Chances are you already know these since they are commonly used to configure particle effects.

While primarily intended for animation, all you need is declare a parameter of type AnimationCurve and this gives you a nifty interface for parameter mapping. For example you could use it to relating the strength of an attack to resulting damage:

The built-in curve editor. Numbers are grey-on-grey and it 
doesn't seem possible to snap or input numerical values.

Although it isn't immediately obvious, it is possible to edit curves beyond the default [0,0] [1,1] range  (2-fingers gesture or wheel-scroll to zoom in/out).

Tips for working with curves

  • Don't use these where you don't need them. The curve editor isn't good enough to encourage abuse.
  • Bootstrap keyframes with meaningful values to help your designer.

Either/And/Or - How we find bugs

While I was chasing a bug this morning it occurred to me that I was caught in the usual trace/run/redo cycle, a cycle that's time-consuming though not nearly as using breakpoints.

How do programmers find and fix bugs? Setting breakpoints and tracing ultimately do the same thing, and seem to have roughly the same cost:

  • Set a breakpoint (or trace) to find out whether code is traversed or not.
  • Set a breakpoint (or trace) to find the value of something.
As to bugs, they tend to fall in 3 categories:
  1. Something happens, that shouldn't.
  2. Something doesn't happen, but should.
  3. Something happens in the wrong way.
#1, #3 are probably easier since we only need to map the symptom (bug report) to its immediate cause (code fragment) and get a stack trace for it. Finding this kind of bug becomes more time consuming when the target code is traversed very often, since we then have endless false positives.

#2 is often a lot trickier. It is solved by finding out how close we are to executing the desired code fragment so we have to use static analysis and potentially trace / break into all ancestors of a given target.

It seems to me that we could avoid spending so much time into the run/rerun/break/trace cycle.

Accessing local files using Unity 3D

On desktop platforms, you can access the local file system.

Sunday, 22 March 2015

Using Hash values to detect whether the parameters associated with a script have changed

As I am doing work involving procedural content generation, I often want to know whether the parameters associated with a given script have changed.

Although Unity may call Update() or Validate() to indicate that a script may have changed, this causes redundant updates, slowing down interactive updates.

In order to detect whether a variable has changed, a simple pattern can be used:

class X

public var foo
private var _foo

function fooChanged
--- return foo!=_foo

function validate
--- _foo = foo

Often, however, it is expedient to update everything whenever a parameter changes; in this case we do not need to track each variable separately. Instead, a simple checksum can be used:

class Y

public var foo
public var bar

private var _checksum

function hasChanged
--- return checksum() != _checksum

function checksum()
--- return 

function validate
--- _checksum = checksum()

Hash values strings, enums and references

When evaluating a checksum, we need hash values for all parameters. For numbers and vectors, this is straightforward. For strings, enums and references, the following can be used:
  • parseInt(enumVar) => convert an enum value to an int
  • anObject.GetInstanceID() => suitable hash value for any object.
  • anObject.GetHashCode() => suitable hash values for most objects, including strings


Monday, 16 March 2015

I am currently working on an interactive clone tool.

All elements except the water are created using spheres.


Array distributions