We need the InitPalette and GetColour functions from last time, though the InitPalette function will now store the 216 colours as JavaScript objects (with r, g, and b components) rather than Notch's encoded version:

// Before:
colours.push(r1 << 16 | g1 << 8 | b1);

// After:
colours.push({
  r: r1,
  g: g1,
  b: b1
});

This saves us from having to decode the value before we use it - which is much more practical in JavaScript, because the canvas image data is stored as separate rgba values by default.

On with the new stuff. First up is to make sure we can draw pixels to our canvas element. The process goes like this...

1. Get the canvas's image data with the createImageData function.
2. Manipulate the bits of the data as we desire
3. Replace the canvas data using the putImageData function
4. Repeat from step 2

All the JavaScript you see is "inline" for simplicity. All functions are global (and for some reason I uppercased the function names - I sometimes go a bit weird when writing tutorials). A lot of arrays are passed by reference... It's for demonstration purposes only! Namespace things, mix'em in, plaster some classical OOP on them, make them into endo-functing monads... REMEMBER: This isn't production code, it was just me dissecting and porting Notch's Minicraft effort!

Drawing pixels with canvas

Right, first we grab the canvas context and keep a reference to the image data. We'll also populate our palette, ready for using.

<canvas id="board" width="160" height="120"></canvas>
...
var ctx = document.getElementById("board").getContext("2d"),
    output = ctx.createImageData(ctx.canvas.width, ctx.canvas.height),
    colours = [];

// Set up our palette
InitPalette(colours);

Then we run a loop where we pick a random colour index (from the 216 we generated) and put it in each pixel. The canvas data is stored 4 bytes per pixel (rgba) and we put 256 for alpha (opaque).

(function run() {
  for (var y = 0; y < ctx.canvas.height; y++) {
    for (var x = 0; x < ctx.canvas.width; x++) {

      // Pick a random palette colour
      var cc = ~~(Math.random() * 216),
          xo = x * 4,
          yo = y * ctx.canvas.width * 4,
          col = colours[cc];

      // Replace the canvas image pixel
      output.data[xo + yo] = col.r;
      output.data[xo + yo + 1] = col.g;
      output.data[xo + yo + 2] = col.b;
      output.data[xo + yo + 3] = 256;
    }
  }

  // Draw it
  ctx.putImageData(output, 0, 0);
  setTimeout(run, 50);
})();

Alright! We have some palatte-ized noise on the screen.

Loading an image

Next, we need to load in the grey-scale graphic file (which is the spritesheet from Minicraft). To load an image as canvas data, we'll create a regular ol' JavaScript image then "paint" it onto a canvas element. Then extract the data from the canvas element and discard the JavaScript image and the canvas element. We just want the datas.

function LoadSpriteSheet(filename, callback) {
  var img = new Image(),
      pixels = [];
  img.onload = function() {
    var can = document.createElement("canvas"),
        ctx = can.getContext("2d");
    can.setAttribute("width", img.width);
    can.setAttribute("height", img.height);
    ctx.drawImage(img, 0, 0);

    var data = ctx.getImageData(0, 0, img.width, img.height).data;

    // The important bit!
    for(var i = 0; i < data.length; i += 4) {
      pixels.push(~~(data[i] / 64));
    };

    // Send it back
    callback && callback({
      width: img.width,
      height: img.height,
      pixels: pixels
    });
  }
  img.src = filename;
}

If you're playing along at home, remember you need to have a web server running to load the image (you can't run this sample from a file:/// url) otherwise you'll get a cross-domain error when trying to manipulate the canvas data.

There's one weird bit in there that is specifically for our colourising code: first, because we only care about greyscale for now - we only look at every 4th byte in the data (because if it's greyscale then r=g=b). And second, every byte that we keep we first divide by 64.

WTF?! Ok, it's a Notch-ism... When he was creating the graphics in his graphics editor, he carefully chose 4 rgb colour values that when divided by 64 (and floored) would return either 0, 1, 2, or 3! That's a handy index for us to work with in code, but at the same time - a decent scale to work in in photoshop.

What we end up with then, is an array sized width * height of integers from 0 to 3. To actually load an image with this function we pass the path and a callback function (because the image load is asynchronous).

var spritesheet = null;
LoadSpriteSheet("sheet.png", function(sheet) {
  spritesheet = sheet;
  run();
});

We then call our run function. For this demo we will blit the spritesheet directly to the output canvas image - this code is almost identical to the "random static" code - except instead of a random colour index, we read the integers from the spritesheet. Because this will only give us a colour from 0 to 3 (which would be from black to very very dark someother colour) we multiply it by, say, 10 - and get the colour from the palette.

function run() {
  for (var y = 0; y < ctx.canvas.height; y++) {
    for (var x = 0; x < ctx.canvas.width; x++) {
      var cc = spritesheet.pixels[x + (y * spritesheet.width)],
          xo = x * 4,
          yo = y * ctx.canvas.width * 4,
          col = colours[cc * 10]; // make it brighter!

      output.data[xo + yo] = col.r;
      output.data[xo + yo + 1] = col.g;
      output.data[xo + yo + 2] = col.b;
      output.data[xo + yo + 3] = 256;
    }
  }
  ctx.putImageData(output, 0, 0);
  setTimeout(run, 50);
};

What you see now is a strangely colourised version of part of the spritesheet. We're getting closer!

A kind of double-buffer

Right, in the next step we'll create an extra array, the same size as the screen, that will represent... the screen. It will hold screen size, the spritesheet, and the pixels to eventually render. All the sprite rendering we will do to this array, and then at the end copy it to the output canvas element.

buffer = {
  width: ctx.canvas.width,
  height: ctx.canvas.height,
  sheet: null,
  pixels: []
},

When the spritesheet is loaded, it is stored in the buffer too (instead of the global variable we made last time). To render the buffer to the output canvas we do exactly the same as before - but pass in the arrays to copy from and too.

function render(buffer, pixels) {
  for (var y = 0; y < buffer.height; y++) {
    for (var x = 0; x < buffer.width; x++) {
      var cc = buffer.pixels[x + (y * buffer.width)],
          xo = x * 4,
          yo = y * buffer.width * 4,
          col = colours[cc];

      if(!col) continue; // Make sure it's defined
      pixels.data[xo + yo] = col.r;
      pixels.data[xo + yo + 1] = col.g;
      pixels.data[xo + yo + 2] = col.b;
      pixels.data[xo + yo + 3] = 256;
    }
  }
}

Now we can re-create our original static - but utilising the buffer:

for (var y = 0; y < buffer.height; y++) {
  for (var x = 0; x < buffer.width; x++) {
    buffer.pixels[x + y * buffer.width] = ~~(Math.random() * 216);
  }
}

// Transfer screen to output buffer
render(buffer, output);
ctx.putImageData(output, 0, 0);

A small step backwards - but now we're rendering noise with our back buffer.

Plotting some sprites

With our buffer in hand, we can now do some real work! Anything we put into the buffer will end up on the screen - so now we can copy pieces of the spritesheet data straight into the buffer array. We'll make a renderTile function that copies an 8 by 8 pixel rectangle from spritesheet to a given x and y location. This code is ported pretty much directly from Notch's screen.render function.

function renderTile(buffer, xp, yp, tile, colors) {
  var xTile = tile % 32,
      yTile = ~~(tile / 32),
      toffs = xTile * 8 + yTile * 8 * buffer.sheet.width;

  for(var y = 0; y < 8; y++) {
    if (y + yp < 0 || y + yp >= buffer.height) continue; // make sure the pixel is on screen.
    for(var x = 0; x < 8; x++) {
      if (x + xp < 0 || x + xp >= buffer.width) continue; // make sure the pixel is on screen.
      var col = (colors >> (buffer.sheet.pixels[x + y * buffer.sheet.width + toffs] * 8)) & 255;
      if (col < 255) buffer.pixels[(x + xp) + (y + yp) * buffer.width] = col;
    }
  }
}

To render a tile, we pass in the buffer, the position to render, the tile index, and the colour we want to tint the tile with. Most of the code just figures out the correct offset from the spritesheet (notice the magic number "32"? that's because the sheet is 32 x 32 tiles. The magic number 8? Our tiles are 8 x 8 pixels).

But the important line is this whole procedure is this: var col = (colors >> (buffer.sheet.pixels[x + y * buffer.sheet.width + toffs] * 8)) & 255;

This is where the colourising magic happens. The pixel value from 0 to 3 is found from the spritesheet. This is then multiplied by 8 to give either the value: 0, 8, 16, or 24. The colour number is then right shifted by that amount and anded by 255.

Does this sound kind of familiar? It's the inverse of what the ol' GetColour function did - which encoded 4 colour values into 1 integer. This is just doing the opposite: extracting one colour out of the integer and applying it to the correct pixel. The next line then checks that the value is not 255 - which will be our "invisible" colour for transparent areas.

We can call this function for each 8x8 sprite/tile we want to render. The tile number is the integer index into the spritesheet: 0 is the first tile in the first row, 1 is the second tile in the first row, 32 (1 * 32 + 0) is the first tile in the second row, 33 (1 * 32 + 1) is the second tile in the second row...

renderTile(buffer, 20, 20, (5 * 32) + 0, GetColour(-1, 100, 320, 222));
renderTile(buffer, 30, 20, (5 * 32) + 2, GetColour(-1, 100, 320, 222));
renderTile(buffer, 40, 20, (5 * 32) + 3, GetColour(-1, 100, 320, 222));

Ah, that's more like it - Three colourised Minicraft tools!

Messing around with it

With the ability to plot tiles and sprites at a given location - we have all we need to make some games! In each of your entity's render functionality you can call the renderTile as many times as you need. For example, to render a background over the whole screen:

for(var y = 0; y < buffer.height / 8; y++) {
    for(var x = 0; x < buffer.width / 8; x++) {
        renderTile(buffer, x * 8, y * 8, 1, GetColour(0, 130, 120, 0));
    }
}

You can plot individual tiles to make a font plotter, or stitch a few tiles together for bigger sprites... whatever you want. Here's the code for the weird demo from the beginning of the article. Notice that the Minicraft players are actually 4 tiles in a square:

var rnd = function(min, max){ if(!max){ max=min; min=0; }; return ~~(Math.random()*(max-min))+min;},
    rndCol = function(){ return parseInt(rnd(5) + "" + rnd(5) + "" + rnd(5), 10); };

// Render peoples
var midX = ~~(Math.sin(new Date().getTime() / 400) * 20) + 70,
    midY = ~~(buffer.height / 2) - 8,
    col1 = GetColour(-1, 1, rndCol(), rndCol()),
    col2 = GetColour(-1, 1, 23, 555);

// Man 1
renderTile(buffer, midX + 16, midY, (14 * 32) + 0, col1);
renderTile(buffer, midX + 24, midY, (14 * 32) + 1, col1);
renderTile(buffer, midX + 16, midY + 8, (15 * 32) + 0, col1);
renderTile(buffer, midX + 24, midY + 8, (15 * 32) + 1, col1);

// Man 2
renderTile(buffer, midX, midY, (16 * 32) + 0, col2);
renderTile(buffer, midX + 8, midY, (16 * 32) + 1, col2);
renderTile(buffer, midX, midY + 8, (17 * 32) + 0, col2);
renderTile(buffer, midX + 8, midY + 8, (17 * 32) + 1, col2);

Check out the Minicraft source (or here on GitHub) - especially the render functions of each entity (eg player.java) to see how Notch implements animation and rendering based on the player's direction, if they are attacking, etc.

Anyhow... that's it. I'd highly recommend not using any of the code above, but re-implement it yourself from your brain... this code is already ported from Java which was written in a 48 hour game competition, by a mad man - so do yourself a favour and make your own (more idiomatic) version!

It's worth it I think... dynamically colourising sprites like this is a great way to prototype the look and feel of your game, add in old-school colour-cycling effects, and easily add variety to your entities.

Up and down to scroll the page up and down. The top-most visible link on the page will be highlighted for your navigating pleasure. Left and right to move between links, FIRE to visit. It's just that simple!

The gamepad API is verrry experimental at the moment - it's only available in special builds of Firefox and Chrome (Chrome Canary)... but it's comin' to a browser near you soon!

I also map the "select" button to back, and "start" button to forward, just for fun. It's only for Firefox at the moment (thanks to some weirdness in the Chrome implementation) and it's hardcoded to the Retrolink controller - you need to tweak the IDs in the script to match yours... but hey, works on my machine!

Konami code not included.

Right, now, on to todays topic: "Colour like you're Notch" (Awright, punning on my own blog post titles!). While watching the livestream of Notch coding Minicraft, I was intrigued by his dynamic sprite colorising. After a little reverse engineering and experimentation I realised it was dang simple, and we could apply something similar to HTML5 games.

The idea is that you create your sprite sheet using only 4 colours. At runtime, you replace the 4 colours with any colours you like - so you can quickly modify the look and feel of the game, or have varied characters that differ only by colour - just like the ol' NES games.

While 95% of Notch's code is extremely straightforward and obvious, the colour system got a bit hairy due to the fact he faffed around with the implementation a few times to get the result he wanted. The end result seems more complex than it really is. The overview of the system goes like so:

1. Set up a limited (256 colour) indexed palette to be used in the game. The colour channels will be divided into 5 "shades".
2. Draw the sprites in 4 colours. When loading the image into the game, reduce the pixels to values from 0 to 3 to represent the colour.
3. When drawing a sprite to the screen, dynamically pass in the 4 colours to use.
4. For each pixel, find the index in the palette and replace the pixel with that colour.
5. Profit!

The trickiest part is realising that Notch just made up a custom colour selecting system. Throughout the Minicraft code you'll see lots of instances of a line like: Color.get(100, 232, -1, 555) - although it kind of looks like some kind of RGBA format, it's really defining 4 separate colours, each made up of 3 channels. The number 100 represents r = 1, g = 0, b = 0 and would be a very dark red. 555 represents r = 5, g = 5, b = 5 and would be white (full red, full green, and full blue). So let's see it in action...

In Game.java, the colour palette is set up. It uses 6 bits per channel to get our 256 colours in 5 shades. Here's the directly ported JavaScript version (well, except that I'm passing in the number of bits to use, so you can play with it):

function InitPalette(colours, bits) {
  // Set colours
  for (var r = 0; r < bits; r++) {
    for (var g = 0; g < bits; g++) {
      for (var b = 0; b < bits; b++) {
        var rr = r * 255 / (bits - 1),
            gg = g * 255 / (bits - 1),
	    bb = b * 255 / (bits - 1);

        // Set the mid tone
        var mid = (rr * 30 + gg * 59 + bb * 11) / 100;

        // Tint the palette
        var r1 = ~~(((rr + mid * 1) / 2) * 230 / 255 + 10),
            g1 = ~~(((gg + mid * 1) / 2) * 230 / 255 + 10),
            b1 = ~~(((bb + mid * 1) / 2) * 230 / 255 + 10);

        // Push RGB values into a single integer
        colours.push(r1 << 16 | g1 << 8 | b1);
      }
    }
  }
}

You can have a look at the palette that's generated by this function with this jsFiddle. One cool thing to notice is the tinting process. Try changing the final line to push the non-tinted values (rr instead of r1, gg instead of g1 etc). Without the tinting the game colours would look like this. Quite a nice way to give the game a "feel". Here they are side-by-side - the top one is tinted to be more "pastel-ly".

The final line colours.push(r1 << 16 | g1 << 8 | b1) converts the RGB values into a single integer (the shift-left operator moves the red bits up the top, the green bits in the middle, and leaves the blue bits at the end). If you want to use this in your HTML5 games, then it'd be better to skip this encoding and store each colour as a simple object - because we just need to decode it later (perhaps the shift version is faster in JavaScript too? Might need a bit of testing!).

Anyway - now we have an indexed palette of colours. To get the colours back at our will we need to use the accessor methods Notch created in Color.java. Here's a JS version:

function GetColour(a, b, c, d) {
  function getIndex(d) {
    if (d < 0) return 255;
    var r = ~~(d / 100) % 10; // First digit
    var g = ~~(d / 10) % 10; // Second digit
    var b = d % 10; // Third digit
    return r * 36 + g * 6 + b;
  }

  return (getIndex(d) << 24) + (getIndex(c) << 16) + (getIndex(b) << 8) + (getIndex(a));
}

Notch's version is the same code, but he uses an overloaded get method for fetching the indexes. The final line returns a single integer like in the palette generation - it pushes the first colour 24 bits up the integer, the second colour 16 bits up etc. The value that it pushes is the index in the palette. This is calculated by the getIndex function by turning the decimal number into 3 channels. The function will accept a number between 0 and 555 (5 x reds, 5 x greens, and 5 x blues). If you put a number higher than 555 into it, it'll die. So don't do that.

Now we can get a single number to represent our 4 colours. GetColour(500, 50, 5, 505) == -1190846796 (Be careful, it's tempting to put 500, 050, 005, 505 so it looks nice, but remember - a leading 0 mean the number is octal in JavaScript, so 050 will actually be 40 in decimal).

Colouring in

Now that we have a way to encode the colours, we need to be able to decode them. Which is just a matter of reversing the getColour method, really: pop out the values and find the palette index! To show it in action I'll just draw 4 rectangles in the four colours specified by GetColour:

function DrawColours(ctx, colourInt, palette) {
    for(var i = 0; i < 4; i++) {
        var colIndx = (colourInt >> i * 8) & 255,
            col = palette[colIndx],
            b1 = col & 255,
            g1 = (col >> 8) & 255,
            r1 = (col >> 16) & 255;
        ctx.fillStyle = "rgb(" + r1 + "," + g1 + "," + b1 + ")";
        ctx.fillRect(i * 10, 0, 10, 10);
    }
}

DrawColours(ctx, GetColour(510, 0, 555, 55), colours);

The result is a red-ish rectangle, a black, a "white", and an aqua blue rectangle. The decoding part can be found in the Minicraft source in Screen.java in the render function. The original code looked like this:
int col = (colors >> (sheet.pixels[xs + ys * sheet.width + toffs] * 8)) & 255;. First the pixel colour (for 0 to 3) is found in the sprite sheet that corresponds with the current tile. This is the "i" from our DrawColours function. The number is then multiplied by 8 to get the correct distance to shift by (0, 8, 16, or 24 bits). The result is the number we pushed in with the GetColour call - which was the index of the palette to use. The actual colour components can then be extracted and drawn.

Ok, that's it for this post - it's getting too long. As you can see, the system is very simple - it's just encoding and decoding palette indexes. In the next post I'll show you how to load in the sprite sheet, covert it to the correct 0 - 4 format we need, and plot the colourised tiles. Sounds exciting, hey?

With an average of around 5000 anonymous viewers, that's always going fun. Over the weekend the topics ebbed and flowed over 3 core themes: "What radio station is this?" (devolving into music flamewars), "When is the next Minecraft release?" (devolving into Minecraft flamewars), and "What program is he using?" (Devolving into programming language flamewars). Here were some of my favourite quotes from the informed and poignant programming language discussions:

• java wasnt really made for games
• C isn't a very good language, it doesnt have xml or objects
• tell me, why the *** would you write a game in an imperative language if you knew c++ just as well?

• You should start with c++ if you want to learn programming. All other languages are ***, except for the D language.

• how do i OOP?
• object oriented programming is a sad failed paradigm of the 80s
• Object C isn't very flexible ;-;
• i hear you need to learn html to get into C#, is this true?
• you're a good c++ coder if you don't use any pointers
• the part i hated most about notchs code was the bitwise shifting i hate that

• i learnt c++ from a book, its boring

• C++ isnt boring, just as fun as Java, but faster and more flexible
• c++ is a mess now
• java looks a lot like c++
• i just now realized how similar c++ and java really are
• C++ can be writtnel like C cause C++ has bacwardcompapility
• the C lineage has it's tendrils everywhere in modern programming, maybe not in c++ but certainly in later iterations
• c++ is like updated c#
• whats easier to learn c++ or java and what is better overall( like quality of programm)

• java is easiest. c++ is more useful and makes a better program

• C# is an improved Java. Java is an improved C++. C++ is far harder, more difficult and complex than java or c#. C# is also a better language than both.

• C++ is the most efficient programming language to date

• java takes too much ressoursses
• java is demanding in terms of RAM
• Java is similar to C++ with Objects and stuff and antway wasnt java writen in C++
• Visual is the standard programming language....doesn't mean its awful << haters
• C++ is a giant, ugy, monstrosity of a language. somewhere inside it, there is a much simpler and more elegant language. that language is called java.
• Chrome sucks because it has seperate processes for EVERY tab! And they say it's lightweight.. lol
• why are you people talking about c++? seriously, learn c# or sth. like that, but not c++... *** c++. so outdated nowadays and just terrible

• as long as someone is using a old programming language it's worth learning... look @ bank systems they're coded in old langs

No one was delving on the irony of spending an hour or so arguing about which language is better for games, without noticing that an actual game was unfolding before their eyes. If only games were flamewar powered!

It was obvious that most people liked the idea of making a game, but balked when confronted with the part where you actually had to put in a bit of effort. This attitude was entrenched firmly in what was perhaps my favourite quote for the weekend - directed towards Notch's wife (who at one point was moderating the madness):

EZ, any advice for women who want to marry men who are in game development?

Now that's just plain lazy.

If you're a fan of the game (a fan is someone who has played it) then you'll know that the music in Minecraft is "special". The game proceeds largely in silence... you'll be deep in the process of constructing a summer house out of glass, or building a railroad to your lava pit when it starts... ever-so-slowly drifting in, and filling your body with smiles. Then it washes away without you even noticing.

I decided I needed this for my daily grind, so I whipped up a dodgy python script that plays random ogg files out of the Minecraft resources directory. But first I needed to figure out which songs Minecraft plays, and at what times.

The algorithm

According to the Minecraft wiki on music "In-game music is cued by the time of day, with a random track being played at sunrise, sunset, noon and midnight". Which I thought sounded reasonable - at first. I asked on the IRC channel and received similar stories: Songs play in the early morning, evening and late at night. Not every morning though, and sometimes not at night. And only the twinkly song plays in the morning. And, and, and... Something seemed fishy, so I decided further investigation was necessary.

Minecraft is a standard Java program, and the Mojang team were nice enough not to do any crazy encrypting/obfuscating of the final product: so it can be relatively easily decompiled (and even re-compiled!). I consulted the source to learn the ways of the mystical music-playing algorithm. To my surprise, it goes a little something exactly like so:

When initialised, it does this complex algorithm to determine the optimum time to play the first morning song:

rand = new Random();
ticksBeforeMusic = rand.nextInt(12000);

There are 24000 ticks in a Minecraft day, so this just picks a random time between now, and half-a-day away. That's it. I guessed the algorithm for successive tracks would be far more complex than this gimmee. Following the code along I found it calls this function once every game tick:

public void playRandomMusicIfReady() {
	if(ticksBeforeMusic > 0) {
	    ticksBeforeMusic--;
	    return;
	}
	SoundPoolEntry soundpoolentry = soundPoolMusic.getRandomSound();
	ticksBeforeMusic = rand.nextInt(12000) + 12000;
	sndSystem.backgroundMusic("BgMusic", soundpoolentry.soundUrl, soundpoolentry.soundName, false);
	sndSystem.play("BgMusic");
}

When the counter is 0 it calls getRandomSound which simply returns a random song from the "music" or "newmusic" folders. It then resets the counter to another random number between half a day, and a full day away! It has absolutely no concept of morning, eventing, night, twinkly song, quiet song... it just plays a random track, at a random time! Damn you human brain for adding meaning where there is none!

Anyway, that's all I wanted to say. If you happen to have Minecraft, python, and pygame installed, and work with your volume up, but in silence: then this script is for you!

Curious as to the purpose of these wondrous new consumer devices, my grandmother asked for a demonstration of how it worked. She was a teacher, I think (as a kid you don't really probe the lives of those around you) and I felt like this was a mini test, so I was determined to impress. Naturally I fired up BASIC to give her a taste of why she herself might want such a machine, and I wrote a small program to plot a sprite on the screen.

RUN...

I could tell she hadn't quite grasped the awesomeness of it, so I proceeded to animate it. The animation code went something (but nothing) like this:

...
100 LET X = 0
110 PUT SPRITE 1, X, 100
120 LET X = X + 1
130 GOTO 110

I'd memorised the code from the user manual, or from another game, or something... so I was very unprepared for her sole question regarding the demonstration:

How can X possibly be X plus one?

I was confused.

Not about her question (I had no idea what she was talking about). I was confused because she wasn't in awe of the HUGE SMILEY FACE that I had just created and then made FLY RIGHT ACROSS THE SCREEN.

But she persisted with her interrogation of the single line of code, buried inside the very first program she had ever seen: how could "X" be "X plus one"? It just didn't make sense to her. If X is 0 then X is 0.

<End flashback> I don't remember much about my grandmother, but this morning I was writing a piece of functional JavaScript and I happend to need the let keyword. As I typed it, I was transported back in time to that strange moment - I don't even know why it was locked in my head.

At any rate, I'm now a bit miffed that it took me 20-odd years to get up to speed with functional programming, but my grandma - who had never touched a computer in her life - understood immutability instantly and intrinsically.

See also Conventional Interfaces: map/reduce and friends.
See also Reducing map: jQuery vs jQuery vs JavaScript

Play 2.0 gives a big hug to Scala (the core is all Scala now - though there are still Java APIs for everything if you haven't convinced your bosses to switch yet). One small-yet-nice feature of the new version is built-in CoffeeScript and Less CSS support. Here's how you use it...

After creating a new app, add a app/assets directory to the default structure. Files in here are contenders to be compiled and served as public resources. From here we'll go ahead and add javascripts and stylesheets folders as children.

Adding some CoffeeScript

Next, we'll add a new CoffeeScript file. Create a new file app/assets/javascripts/main.coffee and add some coffee magic (here we're alerting after a jQuery document.ready):

$ ->
    alert "Mmmmm... Coffee...."

To link this from your main template, add a link to where the compiled version should go:

<script type="text/javascript" src="@routes.Assets.at("javascripts/main.js")"></script>

Notice the path is javascripts/main.js (not .coffee). We're pretending that the JS file is a normal-ol' JS resource in the /public/javascripts/ directory (though, internally it's actually compiled to a separate target directory).

Refresh the page, and alerts abound! Anytime you refresh your browser, any changes will be automagically compiled and served. Neato.

And some Less

Adding Less CSS is almost exactly the same: add a file app/assets/stylesheets/main.less:

body {
    background: green;
    color: yellow;
}

And link it as a regular resource (and if you're trying this from a default project, don't forget to delete the main.css in the public stylesheets directory, and the @play20.welcome(message) from the index view - which brings it's own CSS to the party!):

<link rel="stylesheet" media="screen" href="@routes.Assets.at("stylesheets/main.css")">

There's one caveat though: if we have an import statement in our Less file - the compile command will merge the files, but it will also find the import and try to compile it standalone. To avoid this, you need to name the import file with a leading underscore.

Here's our import file, apps/assets/stylesheets/_theme.less:

@mainBackground:        green;
@mainColor:             yellow;
@defaultFont:           13px sans-serif;

And here's our main.less:

@import '_theme.less';

body {
    background: @mainBackground;
    color: @mainColor;
    font: @defaultFont;
}

You can add as many subdirectories as you need to give your project a nice structure (for example, adding all the imports in libs etc.)

And that's it! For the inquisitive of you who are wondering how this works under the hood, check out the code in framework/play/src/main/scala/play/core/coffeescript and less, and Mozilla's Rhino project!

Notch coded Prelude of the Chambered for the Lundum Dare #21 game competition over 48 hours of August 19th-22nd 2011. I think most of it is here - and I've started annotating some of the good bits. Started. I'll fill out this post as I go...

It's well worth a study if you've got a couple of days to spare!

Part 1: The setup (3h 15m)

And so the game begins - on Saturday the 20th of August, some time in the afternoon...

Part 1 direct link (on YouTube - text in fullscreen is readable, but only just!)

• Sketches out some possible ideas in notepad
• Sets up Eclipse and his paint program
• Creates blank Java project and Swing component
• Creates display frame and boiler plate stuff
• (0:27) Sets up main loop "tick" and game screen
• Draws some random pixels with clipping
• Pixels with perspective
• (1:14) Maps a roof and floor texture
• Adds up-down camera movement
• Adds a wall-as-some-pixels
• Spends ages getting wall to work properly
• Conquers the wall maths!
• (2:19) Adds wall texture
• Adds spinning camera
• Tweets progress...
• Adds input handler
• Creates player and binds camera to the keys
• Adds "z" movement
• Make random cube generation for testing
• (3:09)Adds player/wall collision detection
• Fix rendering direction: "Let's flip the Y. Y not?"
• Realises the video stream for 3 hours costs $4000. Changes vendors.

Part 2: Adding engine features (2h 00m)

Part 2 direct link

• Re-sets up video streaming crap
• Adds sprite class
• Sprite drawing and clipping
• Renders sprite textures
• (0:28) Adds dynamic colouring (greys coloured at render time)
• Dynamic colouring for floor and sprites
• Switches to 16x16 sprites (double res!)
• Messes around with walls and floors designs
• Tests screen sizes and scaling
• (1:00) Tests performance and lots-of-sprites
• Tweaks the shading a bit
• Added dithering
• Added a "post-process" step for rendering tweaks
• Added per-block colouring
• Added per-level floor and roof colouring
• (1:35) Drew a custom font
• Created a font renderer

Part 2b: "Getting so tired now" (2h 00)

Part 2b direct link

• Snack time!
• Created a "level" png file
• Added level loader from png
• Added cache for loaded levels
• Started crashing everything with texture bug
• (0:24) Spawn a player from a colour on png
• Fixed rendering directions (things were rendered mirrored)
• Tested adding sprites via pixels on png
• Started adding game design elements (iron bars)
• (0:44) Made blocking sprites: first room!
• Interactable blocks: push-button wall
• Fixed artwork manager
• Created "switch" block class
• Added particle-like smashing to block
• (1:20) Minecraft-esque smash-a-thon
• Bit of level design
• Add popup message system
• "Freedom is temporary and unsatisfying"
• Add "Click to focus" when screen unfocused

Part 2c: The end of day one (0h 40m)

Part 2c direct link

• Refactored/cleaned up "blocks with entities" handling
• Added boulder entity
• Added entity collision detection
• Added rolling boulders
• Added floor holes
• Off to bed

Part 3: Early the next day (1h 13m)

After a smashing first day of fierce programming, we now rejoin the action on Sunday morning, 8am.
Part 3a direct link

• Good morning!
• Added chest block
• Draw some pick up items
• Made game panel GUI (life and pickups)
• Rendered currently held item
• Added water texture
• (1:04) Added head bobbing when moving

{Footage missing: adding using pickup items}

Part 3b (0h 37m)

Part 3b direct link

Part 4: A plan comes together (2h 00m)

14 hours: 8 parts.
Part 4a direct link

• Adds a torch entity
• Creating a dynamic lighting system
• Bails on lighting system and removes added code

Part 4: The rest...

• Part 4b (2h 00m)
• Part 4c (2h 00m)
• Part 4d (2h 00m)
• Part 4e (2h 00m)
• Part 4f (2h 00m)
• Part 4g (2h 00m)

Part 4h: I will go to sleep now (0h 43m)

The final part... Part 4h direct link

The End

Well well well... what a rollercoaster ride that was... highs, lows, chicken, dub step: we had it all, and at the end of the day the game was the real winner. That's all from us here at Lundum Dare #21, until next time - happy coding.

I learnt some stuff too.

Six hundred games: invented, designed, and coded - in 2 days. That was the Lundum Dare game competition #21, held from the 19th to the 22nd of August. Hoards of game makers spent 48 hours creating lil' masterpieces based on the given theme: "Escape".

One of the superstar contestants was Notch of "creator of Minecraft" fame. He took the intrepid step of livestreaming his entire process (which now exists as a 5 minute timelapse video): every move, every mouse-click, every keypress he made for 2 days - streamed live to an average audience of 10,000 viewers.

Over the weekend of the competition I ingested around 30 hours of the action in full screen; surrendering my complete attention to a programmer writing Java. Java! Tens (if not hundreds) of thousands of people watched a guy code Java. It was incredible and inspiring. Here's what I learnt:

Not all programmers are created equal

Holy crap that guy knows his stuff. After spending 10 minutes talking through some ideas, he settled on making a dungeon crawler. Once decided he started a blank Java project (with no external libraries) and got a screen up displaying random pixels. Then he added some perspective, made a raycaster to render Wolf3D-style walls, implemented camera control, added entities and collision detection, allowed interaction with on-screen elements, created a level system, added pickups and bosses, tweaked all the level designs, added sound and title screens... and was done with a few hours to spare.

For the whole process he consulted the internets exactly 0 times for help. He wrote a raycaster from his brain in one go. He didn't copy-paste old code he'd written, he didn't use any SuperDuper Physics Library (tm)... he just coded to do what he needed - and he knew exactly how to do it.

What I learnt: Domain experience is very important. I've done a few of these "code X in a weekend" type things and I've always end up spending 6 hours reading about a subject I'm interested but unfamiliar with. It's still learning, of course, but it doesn't bring immediate results. For a time-based comp it's probably worth scaling back your ideas until you know exactly how you're going to do it.

The internet is, and distractions are, stupid

Along with the video stream was a chat session - where the 10,000 viewers could talk about Notch's programming and add their thoughts on game development. Of course, with those kinds of numbers it degenerated pretty quickly into trolls and metatrolls (thankfully the stream was hidden in fullscreen mode). When the trolls weren't shunning Notch for not working on Minecraft updates for them ON THE FUCKING WEEKEND, debate largely centered on the best programming languages for games.

Fights between C++ vs C#, C# vs Flash vs Python, Flash vs GameMaker... every comment explaining in angry details why their preferred language was superior. Notch, however, was never drawn into the fights, because he didn't read one line of the chat logs, because he was too busy creating a complete 2.5D retro dungeon crawler in 48 hours.

In the time it took each flamewar to flare up and subside he'd finished adding a new subsystem to the game. If only games were flamewar powered!

Notch was impervious to all this, and worked eerily distraction-free. He went to Twitter only once (and that was to post an update on his progress). He played Doom for 15 minutes while he ate lunch. He went to sleep for 8 hours on Saturday night. I think he snuck in a toilet break at one stage - I'm not sure. Apart from that, he coded and he drew and he play-tested and THAT'S ALL.

What I learnt: Nothing. I already knew I shouldn't be distracted by the intertubes, and that your choice of tool is of absolutely no consequence (and is very boring to read about) - it's only the result that matters. I knew it, but seeing it in practice was awe-inspiring.

Streamline your process

Notch used the Eclipse IDE with "hotswap something-something mode" that let him modify code as if he were sitting at a REPL: updating values would instantly and seamlessly update the running game, allowing him to tweak the game mechanics and overall feel very very quickly.

All graphics and level design was done with a simple paint program. At runtime, each game level is extracted from a plain old .png image with each pixel (and it's alpha values) representing the blocks, entities, and triggers in the game. I saw file dialogs maybe, a dozen times throughout the weekend. There was no export phase, no "are your sure?", no "save as interlaced?" - just one keyboard shortcut and the changes were ready to be loaded into the game.

What I learnt: Ok, your tools aren't important - but they have to let you work extremely fast. Don't do something with 2 clicks that could be done with 1. Favour simplicity.

Have a plan

I can't prove Notch had a plan (perhaps it was just a corollary of his experience), but his impeccable timing leads me to think he did. From the start his pacing was perfect: never rushing but never wasting time. When he finished one aspect of the game he moved straight on to the next. By the time the deadline arrived he was casually adding minor level tweaks.

It was not all sunshine and lollipops though: at one point Notch decided to add a dynamic lighting system to the game - so torches would cast shadows and some areas would be hidden in darkness. After about 40 minutes he had a basic system functioning - but the effect was not quite right, and there were some graphic glitches. He decided to scrap it.

At the time I was surprised: he seemed pretty close to nailing it... there were only a few issues left to hammer out and it would have been done. But I think he realised he could end up sinking a lot of time perfecting it (there were some parts of the map that were now plunged into total darkness, so more lights would be required) so he decided to scrap it and move on.

What I learnt: Timing is everything. Spending time on fancy effects like dynamic lighting reduces time for the truly important aspects of play testing and level design. If you're ahead of schedule you can add some bells and whistles, but the clock is always ticking.

tl;dr: code like you're Notch

When I was a kid, a friend and I spent about a million hours learning to ollie on a skateboard. One day after watching an epic skate vid we came up with the genius plan to just "skate like we are one of the guys on the video"... so, cargo-cult style, we just adopted the attitudes and style of the guys we were inspired by: and it worked! Only after truly emulating our heros did we "get it".

The Notch livestream was like an epic skate vid. Only with Java.

As kind of proof that I really did learn something - here's a peek at my cargo-cult-Notch-style game I'm working on: The Darkness. There's no real game there yet - I'm still experimenting with the mechanics but I'm confident I'll come up with something fun-ish (also, sorry Ross - I borrowed one of your mummies).

It's a HTML5 canvas effort that I plan to complete in under 48 hours (I'm up to about 24.5 so far, averaging 30 minutes to 2 hours a day). If you compare the structure of the app with Notch's source code you'll notice more than a few similarities - but hey, I gotta get my domain knowledge up to scratch somehow!

PS: Here's the whole thing for you to watch yourself.

What happened there, hey?!