The making of Confetti

I’m impressed, really impressed…

About my JS1K entry? Ah no… not at all! That’s not what I mean. I’m just impressed that someone managed to spell JS1K with it, let alone take a screenshot afterwards! (Maybe they have a very slow computer. Sorry if that’s true).

I’m so glad because I needed a thumbnail, so I just put some random lines, but I never managed to make it pretty. Well I’m really glad someone at JS1K replaced my thumbnail. It looks quite pretty.

I thought I’d write a post-mortem, for the only reason that there’s a place to put a link to it on my entry, so might as well.

What is JS1K?

To first give a bit of context, JS1K is a contest where you make a JavaScript demo in less than 1024k, without using external resources. That’s quite a challenge, you can’t do much with it, but it’s fun to try! You also have a chance to win $50 in the contest (but I try not to think about it because I find that almost irrelevant for me, given how good the other demos are…)

My first idea, that didn’t make it in

So this began a week ago, as I was browsing other entries, I realized a lot of people managed to use emoticons to add nice graphics to their entries. I thought I’d outsmart them, (and cheat a little), because I will allow people to upload their own image into the entry!

I was just getting started with the basic, then I decided to check on the size of my entry, just to make sure it was less than 1024 bytes, according to the rules. The whole thing was taking 10k, and even minified it was 7k. At that point, I gave up on the Jam and just used what I had to make an entry for Jupiter Hadley’s Birthday jam. That one was quite a success if I say so myself.

Started over, the night before

Round 2 occurred the night before the deadline of JS1K. I had been working on the other jam, and sort of forgot about JS1K, when I suddenly… got spammed with received an email from JS1K about some more JS1K demos. Damn they looked good… I’m pretty sure I could never win the contest, but I still thought it’d be nice to come up with something. I had a few hours I could spare, so perhaps do something along the lines of cellular automata, like Game of Life, or Rock Paper Scissor. For some reason, I had been watching a lot of those videos around that time. This made me want to create my own cellular automata. I told myself I shouldn’t copy someone else’s formula though, I should try to come up with my own.

Struggling with making random code do something cool

Well the basic of Cellular Automata is to make a cell interact somehow with all its neighbors. My first iterations did nothing, I didn’t even understand why I couldn’t change the canvas color to black, until I realized that pixels are not just RGB, but RGBA. With A=0, the canvas is transparent and thus looks all white!

Then I was struggling with getting my canvas to transform continuously. The fact that I was dealing with 3 different colors made it difficult to come up with something simple. Anything I came up with just made the canvas turn gray, then static with a bunch of colored pixels getting stuck between the cracks. It was interesting in the sense that I didn’t know why it was doing that, but it was so boring to look at. Yet I keep staring at it trying to figure out if it was still transforming or if it just got stuck. It’s exactly like watching paint dry!

Ok, so I thought that having to deal with all neighbors made it too complex and not flexible.I could just make one pixel interact with a random neighbor instead. In fact, interacting with all neighbors it’s kinda the same, except repeated 8 times. I eventually changed to make it reach 2 cells away to make it more dynamic.

Eventually, I came up with a function that did something interesting:

function M(data, a, b) {
    if(data[b]>data[a]) {
        data[a] = data[b];
        data[b] >>=1;
    }
}

I’m going to try to explain it despite having no idea how I came up with it. Basically, it’s ordering all the higher value cells (more colorful cells) to attack the less colorful cell. If the neighbor is less colorful, move there, and leave a trace behind by dividing yourself by two.

So that looked like it could be interesting, and the result is Confetti!

Why does it move up?
Why is there black stuff falling down?
And where does the shading come from?
No idea, but this will do. Hey, when I don’t know what it does, it’s magic!

Next, I just thought it’d be interesting to make it interact with the mouse, so I just draw thick white lines as you move the mouse through, and voilà!

Trimming the fat

Almost there, but the problem is that it’s still larger than 1024k, even minimified… minified… uglified….. Ok I dont’ know how to say it.

Anyway, no problem. I just refactor all the variables to 1 or 2 letters. canvas is now cA, moveTo is now mT, attack is just M, just because… At the end, it was unreadable and around 0.9k. I had room for more, but I was really done.

My brain said: Let’s just get over with it!

Looking back

I looked further at other entries… Oh my… those looked so beautiful and impressive. 3D Tunnels, flying simulator, hypno-toad simulator, actual games … I really shouldn’t expect much from my puny entry, but still nothing to be shameful about.

I wonder if others came up with their entries the same way I came up with mine, with no plan, just half haphazardly by moving code around. I’d be damned….

Code as an object – NAPL (Not Another Programming Language)

Let’s get started with the first concern of our new programming language: portability.

In this day and age, portability becomes increasingly important as several types of device are created. You need a language for computers, tablets, phones, but not just that. Soon you will need a language for all the Internet of Things considered.

By that, I mean your microwave might be talking to you, or your purse, your car… Here are some classic examples

– Your fridge could be telling you that you need more vegetables in your diet
– Mirror can give you suggestions on how to put your hair today
– A painting you just bought could give you information about its artist
– And wouldn’t it be nice if your dog’s leash could try to tell you what the dog is thinking?

It would be nice if you could talk back to the device as well with spoken words, but that’ll be for another blog post. In this one, we focus on the idea that you can deploy your NAPL code to all devices.

How you deploy is also important. Frameworks nowadays let you deploy to web and mobile using JavaScript, C# or even Flash, but how many of you (programmers) know how to do that? And those of you who know, what do you think about the process? Pretty clunky isn’t it?

To come up with an easier way, let’s look back at how humans communicate:
To give instructions to a worker, you can write down a letter, you can talk to them, you can talk to someone who will talk to them, even have a translator translate let’s say sign languages to words… Whether it’s through email, text message, phone, or direct conversation, the information passed is quite flexible.

To enforce an easy deployment, let’s introduce the first attribute of the language: Code as Object

The idea is that the code’s format will be similar to data that can be serializable. The closest thing to this at the moment would be the fact that you can turn a string into code in JavaScript:

var function = new Function(code);

For NAPL, given that the code can be serialized, it will be possible to write code using JSON. The code will look something like this:

{
   "NAPL": {
         "code":[
                {
                       "type":"data-binding",
                       "expression": [
                                "a = x+y",
                                "return a"
                       ]
                }
         ]
   },
   "javascript": {
        "code": [ "return 'hello world';" ]
   }
}

Note that this is just globally what the language will look like (a JSON object). I haven’t decided the content yet, so I just made up something but the actual code probably won’t look like this.

The advantages of making objects as Code:

• Code can be transported from machine to machine via the network very easily. As a result, we can create travelling code.
  For example, the code goes to a machine in Vancouver and extract some information, then it travels itself to another machine in Paris and extract another piece of information, does some calculation, and gets sent to New York to provide the final response. To achieve this right now, it will most likely be a machine in New York requesting data from both Vancouver and Paris.
• Code can change on the fly: The fact that the code is simple data, allows it to be changed very easily on the fly, and perhaps by the user. This gives room for user-generated content to be added very easily into a program.
• Once a new interpreter is created for a particular device, code can flow into it through any medium. Basically you could deploy code into a device without complication, by writing the code perhaps on a web page, submitting it, then the code gets sent directly into a device, even as the program is running.

With such powers also comes some drawbacks. Here are some the danger of making objects as Code that we’ll need to solve:

• If code can be modified so easily, it also means a program can be hacked very easily.
• Since code is data, it’s likely that people can look at a program like an open book, and know exactly how it is built.
• The code itself will not be very compact, which could affect performance.

 

This first attribute of the language, Code as Object, favors portability and flexibility. Some drawbacks will be vulnerability to hacking and performance, so those are problems that we might need to address as the language gets developed.

 

PS: Thanks for some of the comments I’ve gotten so far on LinkedIn about the idea. I’ve got some great suggestions from introducing FUZZY elements into the language, to teach the machine new keywords. Check them out here: https://www.linkedin.com/grp/post/1787637-6013573424499212292