"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
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.