I'm happy to see him using Paint.NET to edit the graphics. I've yet to see a free image editor that remotely compares in usability and power; I just wish it were available for Mac and/or Linux.
I tried it on Ubuntu a while ago, and it was the most inhumanly difficult program I've ever used. It always seemed none of the tools looked anything like what I wanted to do. It probably exceeds Paint.NET in its capabilities but would take far longer to learn.
Something about 9000 people watching a guy write code amazes me. I understand reading the source and all that, but is this something commonly done now? Watching others code live? I am somewhat amazed by how fast he seems to be moving, I find I have to sit and think about things a lot more most of the time.
This is a perfect example of how to attain 'flow'. He's done the same (or very similar) thing before, so there is no distress or despair. The 48 hour window provides the necessary, low-key stress stimulus necessary.
MCN (an unusual motorcycle magazine) had a series on this. To attain flow, you need some stress, but too much stress will stop flow. This is probably why we find many parts of coding to be fun, but debugging and navigating poorly documented APIs to be painful.
At one point, I saw a huge switch statement comparing the value of "col" to a list of twenty or thirty long hexadecimal numbers and returning objects like "LockedDoor". Is that kind of thing common in game development? It looks like a nightmare to maintain, but maybe that doesn't matter in a 48 hour competition?
Also, what is the engine that's rendering the maze for him? Is it a publically available library?
The huge switch statement is probably because that's the easiest thing to do with a simple 48 hour game. There is no point in wasting time writing clean maintainable systems with a lot of glue code when you're writing a simple game in 48 hours that you are the only developer of and will probably never look at again after the compo. Even in a larger commercial game it wouldn't be too hard to maintain that stuff (maybe clean it up by defining constants). I've written similar code for LD48 map loaders.
There is a good chance that the "engine" that's rendering the maze for him is something he wrote during the competition. Its not too hard to write a simple maze renderer using OpenGL or even an oldschool raycast software renderer like wolfenstein's pretty quickly. All final LD48 entries must submit source as well, so once Notch is done you could take a look at what he's doing. Probably not anything you can easily turn into a library or reuse :).
One thing I've noticed is that he tends to put a little extra energy into the quality of everything - say 20% more than the minimum. And I mean Everything - from consistent naming and semantics to the visual touches (like the color of the cloud over the moon). This fractional boost to the quality of so many components really adds up.
Also, the switch statement is easy to add incrementally and change. Every so often, he'll go back to it and add some new values and a couple of lines of code.
I think that's the map loader. Rather than writing a special map format, it reads the map from a standard image, with each colour defining a different type of block.
This makes it easier to make a map in a short space of time (great for contests), although as you said it makes it's not really maintainable in the long run.
I don't know if this is part of the rules, but it appears he's using a minimum of existing libraries. For example, he hand drew the font earlier, and spent a great deal of time at the beginning getting the basic 3d system to work.
Hexadecimal numbers are a common way to represent colours, he can probably copy paste the colour numbers back and forth between code and an image editor. Using an existing image editor as a level editor must save time. It would get more complicated when you want to reference a specific thing on the map, eg particular behaviour for this locked door.
There's a pretty big difference between making something playable and making something scale-able. When you've got 48 hours to make something playable scaling gets thrown out the window.
It's for Ludum Dare (http://www.ludumdare.com/), a 48-hour game competition. It's quite common for entrants to record their development sessions and release a video at the end, so I'm sure Notch will do something similar.
Sadly because he had to switch streaming providers, the actual recording is split between livestream and justin.tv/twitch.tv. However, you can definitely go back and replay it all if you know where to look. Markus is also taking screenshots ever x seconds (sorry, no idea how big x is) which he'll use to make a video for his entry. That should give you a 10,000ft view of the process he went through to develop his game.
I believe that he permanently deleted his livestream account due to huge charges that were racked up due to the high traffic of the broadcast (something along the lines of $4,000 I want to say?), so the recorded video is no longer available at livestream last time I checked.
I recall seeing stop-motion videos from either previous Ludum Dare competitions or something similar, compiled from a whole bunch of screenshots like you say.
I'd be more interested in seeing how the actual code evolves - maybe setting something to check it into a VCS every time you save would work.
Figuring out a decent visualisation would be hard though.
if your basic/permitted libraries don't include a way to render orthographic text, I suppose. I didn't see the beginning, but in comments in the previous threads, he's written the whole of the 3D FPS system to a fairly low level as well.
"Ludum Dare Events are held every 4 months; Every April, August, and December. Dates are announced 1-2 months before the start time. The best way to stay informed is via the mailing list. Alternatively, you can follow ludumdare on twitter."
Not affiliated with it or anything.