I'm hugely impressed by this and applaud the effort, I've played the top game a bit and it's very nice, especially if you've not played a game with rewind/replay mechanics before.
I was wondering exactly what had to be under 13K, so I looked in the repo (a staggering 2.4M zipped), where even just the /src/ directory is a bloated 108K. The answer is, when you build it, it creates a single index.html which is a rotund 35003 bytes, but which zips down to a svelte 11764 bytes.
If you want to see what a 1kb game looks like, here is the full writeup of the original 2010 JS1K winning entry: http://marijnhaverbeke.nl/js1k/ (use arrow keys to move and space to jump)
The smoothness in the graphics of the winning Js13k game blow me away. I love the way it "rolls back" after the timer ends, and would love to see a dev blog writeup from the authors.
Wow, that 1k game is insane. Not only you got a lot of details in the visuals (cloud, rainbow, trees), you also have multiple mechanics such as coins, falling terrain and flower obstacles. Amazing.
The mark of a great entry is a fully playable game. And "xx142-b2.exe" certainly succeeds on all fronts. The graphics details are amazing: infinite fog drop off, spotlight reflection, ambient floor animation, etc. I feel like they could have saved bytes with procedurally generated levels. But it wouldn't have been nearly as fun progressing ;)
Are there any examples of competitions that have themes that are more (for lack of a better term) constraining? I find the theme for most game jams is so vague you can shoehorn any entry you want in to it. Demake competitions are interesting.
If you can think of a constraint, there's a good chance a jam already exists for it. If not, hosting one is easy, and very fun / fulfilling. See https://itch.io/docs/creators/game-jams.
From my experience doing web development, that's not surprising. Safari is sorta the king of broken, half-implemented Javascript APIs that will advertise support but don't really work correctly.
It originates in the constraints of hardware, particularly 8 and 16-bit computers with typically 4K or 64K addressable memory. Starting with the modification of existing games, it became a challenge to push how impressive a program could be made (typically an audiovisual demonstration "demo"). Such hardware becoming obsolete added to the impressiveness.
Demo and game competitions without constraints exist, but naturally become a competition of art and design, where use of existing engines is rewarded, discouraging programmers. The constrained competitions can be more appealing to programmers, where programming creativity is better rewarded.
Just a bit of historical update - most 8-bit machines topped out at 64k of memory (8 bit data, 16 bit address space), but some could do more with extra hardware or "tricks" (paging a special 8k block using a custom MMU or similar); even then, memory tended to be limited just due to cost if nothing else.
16-bit machines usually had a larger address space; the Motorola 68000 had a 24-bit address bus, for instance. While that allowed for quite a bit of memory, again (at least for most consumer hardware) most people were limited to at first 512k to 1Mb, then as the early-90s wore on, up to about 8Mb - at which point 32-bit cpus became affordable.
So the only place you really saw larger amounts of memory (and this is more my understanding than experience, as I was just a kid then) with 16-bit machines was usually businesses and other "larger scale" computing that had the need and finances to afford it. As always, I suppose.
Constraints typically feed innovation; it also levels the competition playing field to some degree, and controls what kind of games gets produced, and what tooling is used/viable.
And thus changes the expected audience to the challenge -- ideally, everyone there is interested in the same goal, with varying experience; the kinds of goals that will appear depends on the constraints imposed
I was wondering exactly what had to be under 13K, so I looked in the repo (a staggering 2.4M zipped), where even just the /src/ directory is a bloated 108K. The answer is, when you build it, it creates a single index.html which is a rotund 35003 bytes, but which zips down to a svelte 11764 bytes.