Information Is Beautiful


Take a look at this. You don’t need to understand it, for my point to come across, but for now, please just look at it.

In preparation for an upcoming video I’m putting together, the code you see above is all that is required for a fully functional game of Tetris. I wrote it in a way that was readable by an average human (the intention of the video is to introduce some fundamentals), then reduced it until I had to go to bed. There is still scope to reduce it further, but something about it struck me. This handful of characters and digits contains enough information to play a fully functioning game of Tetris. This to me is no different from looking at a strand of DNA knowing that within is encoded all the necessary information to construct people. The characters above contain the definitions for the pieces (Tetronimos), the layout of the board, the rules of the game, animations for lines that disappear, rules for detecting collisions, increasing levels of difficulty, score keeping, user input and control and ultimately displaying it on a computer screen.

Some may argue “Sure, but it needs all the libraries and stuff and an OS to work, which means there’s millions more characters”. I can’t refute this but I propose it does not matter. This humble block of bytes above, is all the information needed within an existing ecosystem to present a fully functioning game of Tetris. DNA on its own doesn’t form life, it still needs an ecosystem to operate within. Likewise, that existing programming ecosystem will not on its own present a game of Tetris, it needs just this extra “blip” of information to make that happen.

At the risk of sounding like a pretentious git, there is a beauty to this. It’s not often that your eyes can perceive the whole of something in programming, but here we are, staring at an imposing rectangle of just about readable C++ code. There is nothing more, nothing hidden; and a programmer can see it is legitimate code, but this arrangement of symbols and characters is all that is required to form a complex, fun and interactive puzzle game, known to quite literally billions of people around the world.

I’ll be uploading the source soon enough, when the video gets finished, but for now, just staring at the image makes me really appreciate information in a new way.


Over Engineering Source Code


OK, so this video’s a bit cheeky, but it does deliver a salient point. Some programs and code I have had to work with were written by people who clearly did not know when to stop. I’d like to think that really this is the fault of the inexperienced, but it is probably also due to programming arrogance. Some people just cannot stop gilding the lily. On the rare occasion anyone else is looking at your code, make sure they can work with it!

  1. Don’t comment it to death, I’m a programmer, it’s my job to be able to read and understand code. If you must comment then write about the objective the code is trying to achieve, or if there are any particularly cryptic sequences, explain them. DO NOT comment things that are obvious.
  2. Keep the code clear. Showing you know how to use every tool in the toolbox does not lead to clear or particularly clever code. Make every effort to keep your source code as compact and minimal as possible. Don’t be afraid of using constants in your code. Sometimes 3.14159 is clearer than M_PI.
  3. Dont assume that auto-documenting your code is sufficient, in fact tools like doxygen can often make code harder to read and write, and in reality provide little benefit if you’re not fully committed to it. If your code base is spanning many files, then sure, a tree can help understand it.
  4. The best documentation ever is a little additional program that shows how your code should be used. Focus on that rather than trying to write examples and usage syntax in header files.
  5. Write good code! Well duh… but if your code works, and is obvious to use, and you provide an example, then I’ll never need to examine it will I?

Anyway – behold the acting!

Happy Coding,


Command Line First Person Shooter Engine


Ahh NesMania, you may remember this project from an earlier post. Well it’s over now, and one of the things I’ll miss is the execellent background noise it added to my programming sessions. I liked the beep-boops and swearing, and frequent no mames. The project came to become a bit of a muse, perhaps watching The Mexican Runner grind relentlessly through one terrible and difficult game after another yet never giving up, was inspiring enough (to me at least) to go on and do programming videos.

Anyway, my latest video recreates the a navigable 3D maze in the terminal. No polygons here, but it is inspired by the Wolfenstein 3D game engine. I think the result is quite pleasing, but it makes me ask the question why this was not the norm back in the day when computer graphics where considered a luxury. It is not a computationally challenging algorithm by any means, and surely those machines back then would have been more than capable at updating the screen fast enough. I’m unaware of any games that operated in this way, and thus it makes me think that simply, nobody had had the idea to do a game engine in this way. That demonstrates just how influential and radical early first person shooters were.

So here is a video demonstrating the engine and discussing how it works.

And here is a link to the code on Github:

And here is the code itself! Have fun!


Code-It-Yourself: Sound Synthesizer #2 – Oscillators & Envelopes



Part 2 of my “From Scratch” Audio Synthesizer is now ready to be viewed!

Specifically, this video covers more advanced oscillators, and envelopes to control the amplitude of the sound.

All the code is on Github:

And also here!

Make some NOISE!!!!