So, I decided on a whim to ‘enter’ Ludum Dare 22 (48?). I didn’t really do it “right”, only putting in a few hours work here and there, but I did finish off a simple game “alone”. Its based off my experiences as a kid (and adult, I guess). Upon reflection on the idea of being alone, I recalled when I was younger and felt very isolated. I wasn’t exactly anti-social (just happened to not have invested time into interaction, instead preferring to read books and play videogames). I was often informed that people actually liked me (I found that hard to believe), and that if I wanted friends, all I had to do was talk to them. Yes, talking, one of the easiest things in the world to do (spoiler alert: I didn’t do a lot of talking back then … still don’t). Even then, people would try to talk to me and I really had to work to keep myself alone.

So that’s what this game is about. The process of keeping yourself alone by putting up walls to keep potential friends away.

I made the game using “HTML5″ and easel.js. Javascript is interesting, as I seem to sometimes fall into a different scope without realizing it. In addition, the keyboard events leave a little bit to be desired (keyup events are sometimes lost, presumably when too many keys are down). I hope that gets sorted out (especially considering there is already a gamepad api in the dev builds of Chrome and Firefox). Easel.js was wonderful in providing some nice helper functions to the canvas, though it leaves a bit to be desired. Notably lacking is a width & height attribute on the DisplayObject or Bitmap level (it looks like you CAN get to it through the image reference on the bitmap… a bit ugly looking).

Approximately a year ago I finally left school. After spending years improving my mind (and being rather good at the Game of School), I was finally in the workforce. I found myself quite depressed for a number of months, hit with the classic “search for the meaning of life”. I undertook a long search for something that was “valuable enough for my time”.

What I eventually found was a love of creative coding that I had thrown away years earlier. You know, those things made by awesome guys like Mr. Doob, Soulwire, and Neave. “Oh,” I used to say, ” those are just toys.” I saw no value in them.

During my search for that something, I began to immerse myself in a developer culture. With that culture came the realization that, if I were to improve myself in any way, I would need to be working on side projects that truly stretched my knowledge and kept me interested in what can quickly become a very boring method of employment. It was then that I began to program little games. I never completed a single one, but each taught me a great amount.

It was then that I switched to programming other things that drew my interest. Things like random terrain generation, tree growth algorithms, or cloud generators. I began to make things that were interesting simply because I thought that it would be cool. As I did, I found that I really wanted to share what I had created. Inevitably, it would also get me talking about that process it takes to actually accomplish what I did.

Upon reflection, I realized that “fun cool shit” is quite far from frivolous. It is essential in storing our culture and passing it on. A ‘frivolous coding exercise’ can create interest in our craft for the same reason that many children want to become firefighters, pilots, or sports stars. An outside viewer can see it, understand it, and want to be as awesome as what they have seen. Allright, so we don’t get as much respect as the aforementioned careers. Maybe one day.

I suppose, what I am getting at, is that I encourage anyone to build that cool little thing they’ve always wanted to try. Its not as worthless in reality as it may be in your brain (or on paper). And, if you’re lucky enough, someone will express interest in learning how you did it. That is when you can have the joy of saying, “Well, its not hard. Let me show you the first steps … “

Leaving aside Flash Player performance (which alternatively either leaves a lot to be desired, or works suprisingly well), the major argument between developers is “What is Flash good for?”. Those who have not had a chance to play with the system will never know its strengths versus its weaknesses. If Flash developers wish to cast it in a good light, it would be wise to let people know what makes Flash so awesome. I would say it would be best to give them a chance to play around with it in as easily-approachable way.

I’ve spent the past few months exploring programming languages and different texts on programming in my best effort to shore up any deficiencies I have when it comes to busting out code. During that time, I have found a number of awesome sites that let me get straight to the fun parts of learning: typing in some code and seeing it run. I’ve gone through the tutorials on tryruby.org & tryhaskell.org. I have a few projects up on jsfiddle.net that were great for lunchtime coding experiments. And, perhaps best for the Flash community, there exists wonder.fl, which takes AS3 and compiles it for you without the need to download anything else.

In my mind, the best way to show the strengths of Flash to a developer audience would be to take the tech behind wonder.fl, and combine it with a detailed walkthrough similar to tryruby.org. Including a number of powerful libraries for the user to build with would show them how awesome our community is, and the giant shoulders they could stand upon should the need arise. Getting a decent dev to create a site with this tech in half an hour wouldn’t be too bad, and would let them understand just why AS3 is a great tool when you need to write once, run in a lot of places, and look cool.

These earlier worlds had a number of fascinating revelations take place for both the inhabitants and researchers of the worlds that we take for granted today. Both
A Rape in Cyberspace and A Story About a Tree exemplify people being amazed at the incredible power of the virtual worlds to affect those who inhabit them. Today it is no surprise when we hear about a couple first meeting through World of Warcraft, or a teen girl being bullied through the ‘Virtual World’ of Facebook.

I gather that what we have seen in the past decades years is a gradual merging of the virtual and real, such that events are no longer separate. Thus, a report on a virtual world is never about the virtual world anymore, but about the the real world and its virtual component. The characters within the virtual world are no longer seen as separate, but one-and-the-same as the players playing them. Years ago, I would have found this idea incredibly exciting. “Yes”, I would think, “finally the real and the fictional have combined together into a whole.” But now I feel a bit nostalgic for the day when virtual worlds were viewed as separate entities. Almost as uncharted lands to explore.

Its mostly just a particle system. The only addition is that it accepts a bit of input looking for collisions within a radius of the mouse pointer, and then adds the pointer’s velocity to the particle.

Next time I think I will explore some blob physics to make those clouds clump together. Until then, I hope you have some fun with it.

For the full (highly mathematical (and incredibly difficult for me to grok)) breakdown, I would direct you to The Algorithmic Beauty of Plants, which is about a decade and a half old, but still appears to be a great introduction to the subject. Here I will present my own work with l-systems in Actionscript 3 and Flash.

The (extremely) basic concept of an l-system is to generate progressively more complex strings given a start point and a set of transformations (called ‘productions’ or ‘production rules’). Anytime a rule is matched, the character is replaced with the characters from the rule. If no rule is matched, the character is copied into the new string unchanged. For example, an l-system may have a starting string of “A”, and a production rule of “A => BAB”. The first iteration of l-system will be “A”, the second “BAB”, the third “BBABB”, and so on.

(A quick note on the replacement: don’t do what I did and just run a quick stringReplace on each rule & iteration. It has to be done per character, especially as the rules get more complex. That isn’t to say the string replace produces some interesting results…)

In order to create something graphical, the production rules are linked up to a ‘turtle’ with each character affecting the movement of the drawing pointer. The ‘vocabulary’ of the rules is slightly extended in order to allow more complex actions. A basic 2D turtle uses the set of characters ‘F[]+-’.

• F: move forward by a set amount
• [: save turtle state (position, line size, heaving, etc)
• ]: Pop the last turtle state off the stack, and reset turtle to that state
• +/-: Rotate the turtle left or right by a set amount

Other letters may also be added into the vocabulary to be replaced by production rules later on. The first letter typically used is ‘X’.

So, taking a cue from the generative art wiki, a simple system may be defined by these rules:
w: X
p1: X → F[+X]F[-X]+X
p2: F → FF

and would result in

n = 0; X
n = 1; F[+X]F[-X]+X
n = 2; FF[+F[+X]F[-X]+X]FF[-F[+X]F[-X]+X]+F[+X]F[-X]+X

with a graphical representation similar to:

This should be enough to get going. For more information, I highly reccommend “The Algorithmic Beauty of Plants” mentioned earlier.

In addition, I made a little Flash example that randomizes some of the production rules. It creates some interesting results, though not as full-bodied as I would like.

First there are these that I have recently run across:
Matthew Cooley’s HTML5 tree. Love the colors.
Daniel Brown’s BBC Bloom Flower. Amazing 3D.
Daniel Brown’s On growth and form. Love it, perhaps my ultimate goal.

Perhaps most important to my work is Grant Skinner’s Sakura, Tree, Elm. These are the experiments that lead me to try my own hand at tree generation. Luckily, Grant explains his approach here.

I have decided to make things a bit more difficult on myself, and have approached the foliage generation with an L-system implementation.

As I progressed through the book, I couldn’t help reflect upon Raph Koster’s work, A Theory of Fun for Game Design. It has been some time since I last read it, and I am guilty of having paraphrased it incorrectly before, but the (very) general message of the book boils down to “fun is using a skill to accomplish some task”. Its a bit more complex than that, but that should do for comparison.

What made Don’t Shoot the Dog so interesting was that Karen Pryor wrote of the training being ‘fun’ for the animal as it accomplished the goals set out for it by the trainer. The animal was, in effect, playing a game and having the exact same type of fun that Koster refers to in his book: using or developing a skill in order to achieve a goal. There are other points in the book that are similar to key concepts in game design, such as reward spacing. Pryor emphasizes that rewards should be given quite liberally early on during training, should be linked as closely to the desired action as possible, and rewards should be decreased or given for more complex actions as time progresses. This type of reward structure is very similar to how a good game works. For an example, go to kongregate.com (or any other casual flash games site) and play through a few games. Even better, load up a level-based MMO. You’ll find early rewards & tips throughout many of the games, with decreased payout as the game gets tougher.

I’m sure this is not really anything new to game designers (though if it is, perhaps its time to start training dogs). Perhaps most interesting to me is just how similar our minds are to animals, and how easily ‘hacked’ they can be when one uses a reward system that is strongly linked to a desired action. I think this is what gets people when they listen to Jesse Schell’s talk on games invading real life. When one listens to his speech, it can quickly become disgusting as he plays that Mario coin noise for every ‘good’ action someone takes in his world of the future. One thinks to themselves “There is no way I could be so easily taken in by a few ‘points’ “. But just as Karen Pryor can get ‘untrainable’ professionals to do the most ridiculous tasks with just a few words pointing in them in the right direction, companies and other individuals can control our actions with just the right encouragement.

This concept shouldn’t create fear in an individual. Instead, it should just serve as a reminder for one to live an ‘examined life’, and think about why are they doing what they are doing. Knowing that rewards are a huge incentive for one’s actions should allow an introspective individual to analyze more deeply the causes of their actions, and perhaps even tweaks those rewards to influence their life in the direction they wish to progress.

My final point of this analogy is that this whole concept of ‘gamification’, the buzzword du jour, could be considered stale and well-researched. I argue that anyone seeking a gamification expert should find the best animal trainer they can find, and put them to work ‘shaping’ their target audience to their desired action. Trainers, get out your clickers…