Mr Speaker

Code like that

"Bit of advice: if you want a role model, pick an old guy. By the time you grow up, they're dead" - Bob's Burgers

Freedom is temporary and unsatisfying

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 contestants was a one-time gamedev superstar. 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 the code stream 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 him 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. The coder, 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!

But impervious to, he worked eerily distraction-free. Consulting 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

He 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 there was a plan (perhaps it was just a corollary of 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 he 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 there was 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 that

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 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-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). [edit from the future: this game never progressed... but many more other games since!]

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 other'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.


  1. Awesome writeup, Mr. Speaker! And thanks for linking back to my site.

    Interesting how we were both so fascinated by watching him, as were so many others..

    Thursday, September 15, 2011 at 3:21 am | Permalink
  2. >For the whole process he consulted the internets exactly 0 times for help. He wrote a raycaster from his brain in one go.
    I’ve never felt more inadequate in my life. Hopefully this is a rare level of aptitude amongst programmers? Because I’m certain I’ll never be that smart.

    Thursday, September 15, 2011 at 2:42 pm | Permalink
  3. Read the title and assumed this was on bug testing (or lack thereof).

    Thursday, September 15, 2011 at 3:22 pm | Permalink
  4. @scott – I’m guessing that’s a dig at minecraft (no pun intended). I’d suggest you give up playing games and have a go and creating something. It’s way more fun. If you do, then instead of just reading the title, the content might be useful too.

    Thursday, September 15, 2011 at 4:18 pm | Permalink
  5. You mean he didn’t Google anything from the PC he was developing on, or there was a camera on Notch and his PC the whole time? I’m curious, as there is a difference…

    Friday, September 16, 2011 at 12:20 am | Permalink
  6. I watched the whole stream live and have watched it again since (As I said, it was very inspiring!)… He was too busy writing code, drawing the game art and play testing bother going to Google. Googling for information would have slowed him down.

    Now, going all David Blane on the case, he had two monitors and you only saw one – but seriously – watch him: HE HAD NO USE FOR THE INTERNET. He was working actively the whole time. It’s not a magic trick – he just knew what he was doing.

    (Gunna hunt for the streams and post them here when I get a chance… I think it most of it was on – but the first part was on youtube somewhere)

    Friday, September 16, 2011 at 12:40 am | Permalink
  7. Saying that, a raycaster isn’t particularly tricky software to write. I’m pretty sure I could code one up in a couple of hours. Load 2D map into memory, cast rays from current location based on position and FOV, draw vertical slices based on length of rays (smaller slices for longer rays). Collision detection is easy too, since you’re really in a 2D grid, sprites are 2D… with a little trig knowledge most programmers should be able to know this out in a similar timeframe!

    Friday, September 16, 2011 at 12:53 am | Permalink
  8. I agree – I’ve written raycasters in Pascal (Pascal!), C, and JavaScript… they’re not difficult. But the raycasting + camera control only took him 3 hours and he didn’t have to go and revisit/bug fix any of that code later on. He just nailed it the first go.

    The amazing thing wasn’t his game (it’s not an amazing game), or the code he wrote (it’s very easy to read and modify though)… the amazingness was all the stuff I wrote above. Anyone can _talk_ about how easy it would be to do (in fact, that’s all the internet is for is talking about how easy stuff is). But he has a crazy ability to have an idea and output a product. Finishing stuff his fucking hard, but he can do it with consummate ease. Consummate!

    Friday, September 16, 2011 at 1:10 am | Permalink
  9. Taking nothing away from his obvious abilities, bear in mind that Notch is a professional game designer/developer who basically lives and breaths this stuff every day.

    When one practices something as much as he does, you literally become a rock star at it. And that definitely reinforces your assertion that the internet is generally a waste of time, you’re not becoming better at anything by wandering aimlessly through the interwebs.

    I think a lot of us don’t do things because we feel we aren’t good enough at it, or don’t have a good enough idea to go with. The masters, through either hubris, obliviousness or simple stubbornness refuse to let these notions stop them from doing something anyway.

    Friday, September 16, 2011 at 1:43 am | Permalink
  10. Notch can finish things with consummate ease? I hope that was supposed to be ironic, because Minecraft is STILL in beta 2 years after release! :)

    Friday, September 16, 2011 at 2:56 am | Permalink
  11. Here is a part of the screencast ;)

    [EDIT from Mr Speaker: Thank’s ocarina_coffin! I collected them all together for our viewing pleasure…]

    Saturday, September 17, 2011 at 12:46 pm | Permalink
  12. Nice article. Indeed, Notch is a professional gamedesigner and good at it. It was interesting to see how fast he worked out the raycaster algorithms, but I’m wondering if he’s still that fast when he has to think of new algorithms from scratch a la Ken Silverman style.

    Sunday, September 25, 2011 at 1:16 am | Permalink
  13. It’s worth noting he didn’t actually write a ray caster, what he wrote was just 2D sprites projected into 3D space. True Raycasters draw pixels column by column based on when the ray for that column hit the wall

    Friday, December 27, 2013 at 7:33 pm | Permalink
Captcha! Please type 'radical' here: *
How did you find this thingo? *