The game is a Zelda-inspired, first person, 2.5D dungeon crawler written in Java.

__Modus operandi:__

1) He first built a robust engine, very powerful from a game developing standpoint. Building the various types of blocks (walls/grounds/objects) and entities (player/ennemies/bullets/boulders) needed remarkably little code afterwards.

2) He used Paint.NET as a level editor, and color-coded the blocks and entities. He used the alpha channel to identify the switches, the doors, the ladders and the ennemies (from 255 downwards). Doors and switches are automatically linked by id. This allows to put all the level design logic on the map.

3) The most important: short iterations. He spent more time play testing the game than writing it, systematically retesting the old stuff when he introduced a new feature, or even after changing a detail.

4) He's sharp, knows his tools, edits the code very fast and makes few mistakes. He also has a lot of experience, which allowed him to make good initial decisions that facilitated the development process.

__The platform:__

Java+Eclipse turns out to be an excellent platform for writing games.

While it doesn't have a REPL, its debugger allows to patch the code while it is running, offering a very dynamic environment, especially to tweak the gameplay. It felt very lightweight. I wonder if the other JVM languages have similar debugging facilities.

The simplicity of the language makes the code easy to read and modify (provided you have a sound initial code base). Once you get used to it, the boilerplate becomes transparent (like the parentheses in Lisp).

The refactoring abilities of Eclipse are excellent.

The speed of the JVM allows to write fast low level code, and its object system make it straightforward to organise the high level logic.

__Some tricks/hacks:__

All textures are drawn in 4 shades of gray, then colored when they are loaded. It allows to reuse the wall textures for all levels, and to differentiate the bosses from the normal ennemies, at no cost, etc.

His playsound function creates a new thread every time it is run.

If I counted properly, there is at most one level of inheritance, even where more would have made sense from an orthodox OO design standpoint. There's some code duplication, but he only duplicated robust, well tested code.

The low resolution and limited palette allows the rudimentary graphics to look good (old school). The animations have only two frames.

.

.

On a side note: Did someone save fist few hours of the stream, when he wrote the 3D engine? I couldn't watch the process, and his Livestream account has been deleted.

Easy to source-control and merge, easy to find stuff.

I can't help but think that someone, somewhere has a bloated XML-based API for doing this, probably requiring a server running a couple hundred megabytes worth of Java-based back-end. I'm old fashioned.

I don't anticipate a vanilla text file going out of fashion any time in the next hundred years or so.