To be pedantic, 2 integer are sufficient to write every code in existence (0 and 1).

Damn, I thought it was literally written in 16 bytes of assembler.

it should/might/could be possible to write a snake game in something like, 30 bytes of x86 asm.

boot up real mode old school bios environment. 0xa000 is your screen, width/height with int 10.

Coule use zero if you sleep() just the right amount of time so that when the process wakes up, the current time contains the next frame's game state. That would reduce framerate a bit though.

I came expecting epic-tier fractran golf, was sorely disappointed.

The actual claim is that you can keep the game state for a rather minimal 8x4 game board in two uint32_t, one uint64_t, and one uint_8t.

That's not the entirety of program state - stack aside, there are some loop counters that the author isn't including in the total, along with some implicit variables e.g., for keypress data.

It's a nice optimization exercise, but the result is not particularly mind-blowing to me. You could probably make it significantly more compact at the expense of readability. For one, the shape of the snake on the game board is not random: there's plenty of combinations, such as an alternating checkerboard pattern, that are physically impossible. So the shape is likely compressible.

"Four 32-bit data structures are enough to write a Snake Game in a field of 32 cells" might have been a more accurate title.

In this way, "One integer is enough to write a Snake Game" (but you play in a 2x2 field).