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.
Unless you race the beam the shape will be there in graphics memory which you could read out.
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.
There's a version of snake written in C# that runs in UEFI. That said its at least 8kb in compiled form on windows (not sure size of uefi build) [0]
[0] https://codevision.medium.com/running-c-snake-inside-uefi-df...
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.
- [deleted]
To be pedantic, 2 integer are sufficient to write every code in existence (0 and 1).
"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).
I came expecting epic-tier fractran golf, was sorely disappointed.