Re: rules (FWIW)
Generally speaking, you can always obfuscate code by making a lot of unnecessary complexity.  I don't think this is the kind of obfuscation that is best grasped and appreciated by others though.  For example, you could put together a 6-deep nested case structure that, in the end, performs only a simple Boolean logic function.  Or you could simply route your wires in a pattern that's hard to trace visually.  Sure it's obfuscation, but not the kind I'd want to encourage.
That's why I liked JP's "Hello World" example so much.  It was simple and concise, but still capable of confounding.  I think it's exactly 
because the code was simple enough to understand that the result was 
able to confound.  It's more a matter of misdirection than complexity -- kinda like magic.
Anyhow, if there are to be rules, I think we should expect entries to practice reasonable wiring style.  Messy wiring is like removing whitespace in C -- too trivial to reward.  And we shouldn't use stacked sequences or nested cases solely to prevent anyone from viewing all the code at once.  The C analogy might be so much excess whitespace that a single line of code extends over several sheets of the printout -- again, not really worthy of reward.  And stacking functions on one another to hide the actual function is too much like overuse of #define to redefine C.
Just some thoughts.
One category of obfuscation I think could be neat to play with is calculation or algorithm obfuscation.  Like, implement a vi for integer division where only the addition operation is allowed.  (I don't know if it's actually possible).  Hmmm, maybe that's more of a mini code challenge than an obfuscated multiplication.  Oh well, gotta go now.
-Kevin P.
					
				
			
			
				
	ALERT!    LabVIEW's subscription-only policy came to an end (finally!).  Unfortunately, pricing favors the captured and committed over new adopters -- so tread carefully.