PinkBike used to be the go-to place for uploading media for further embedding in off-site forums (SouthernDownhill, SingletrackWorld, RideMonkey, NSMTB, VitalMTB) - for example, race reports, sales (when forums had limited storage capacity for users), etc.
Your media was watermarked and made available in different resolutions (a unique feature at the time on a bike specific website!)
I would bet a large chunk of those 5M visitors were hotlinks as I don’t remember their forums being too busy —- but I do remember them being very fragmented with too many subforums.
Unfortunately Facebook Groups has killed off the almost tribal online MTB communities now :(
It's amazing how close to the inspiration - Broforce - it actually feels, at least from the video.
I'd sacrifice floppy 41 out of 45 of Microsoft Office 97 Standard Edition to be able to play this.
It looks incredibly similar. It plays somewhat differently - the controls are quite sluggish for me, the jumping and climbing is a bit clumsier, and the grenades change the dynamic. But the influence is very clear!
It's great to see this sort of stuff still goes on.
In 2000 (I think), I put 2 Java Applets into the 5k competition. One a maze game with a thousand rooms (10x10x10), the other a spelling checker that checked the contents of an input field against a word list. Both were quite poor and I didn't do well.
The general standard was really impressive. I remember that there was pretty good chess game done in Javascript.
Neat game but why is it so slow? It runs smooth at the start but whenever I get near some enemies, as soon as 1 or 2 explosions happen it runs at like 10fps or less. I'm on an M1 Mac which can run some pretty high end games. I tried Safari, Firefox, and Chrome
I love the idea of tiny games as a constraint to keep scope sensible. But I worry this is actually a code golf competition. I wonder how many entries are just auto-minified.
In some way, it is; better minification does give you some additional margin. But it would then be a terrible code golf competition because 13 KiB here is the size after zip archiving so the actual limit is anywhere from 30--40 KiB for typical entries and would be very generous. The introduction of better compression tools may have lifted the upper limit a bit but not too much. (Disclaimer: I'm the author of one of such tools that got popular later.)
It should be noted that most assets are still too large in this limit, so almost everything should be made from a code and many stuffs have to be consciously chosen to be included. For this reason, I feel that the limit is rather a very interesting threshold that allows for ordinary developers without much size optimization experience to start with, but should be plenty enough for experienced people to make difference.
Kind of tangental since it doesn't apply here but I love the compression hack used in JS competitions where HTTP wire compression or zipping the files don't count towards the size limit, so the HTML has to decompress itself. The canonical way to do it is to craft a file which browsers will parse as either a PNG or HTML, with the HTML part carrying a stub of Javascript which reads the page as a PNG, draws it into a canvas, extracts the pixel data, reinterprets it as a string containing the main JS payload and evals() it.
AFAIK js13kGames is intentionally using ZIP as a compressed container in order to avoid requiring such relatively obscure hacks to be competitive (up to some degree). Also the hack itself is now being less relevant due to the introduction of DecompressionStream and non-DEFLATE compression algorithms.
The entire 8 bit era was full of games of this size. The game code and sprite data for Lode Runner is less than 16 KB. Machines with 48 or 64 KB of RAM don’t give mic( to work with but we still got Rescue Raiders, Bolo, Bilestoad, and so on.
Awesome, thanks. So while I might need to think about clever ways to generate/handle assets, I can generally not worry about "all the clever JavaScript hacks" and just write thoughtful TypeScript that I elide and minify.
Yeah, most microscopic JS hacks would be too cumbersome to use in this scale. But some conscious decisions to structure your code may make a big difference.
I've done 64kb intros since the 90s so I'm pretty familiar with sizecoding, my point was rather that non-generated audio is usually pretty much out of the picture whilst images in pixelart form is still feasible to a degree.
Actually noticed the compo in time this time (no idea good ideas for the theme though), got 2 or 3 interesting failed attempts to scrounge code from (but not sure of the approach to take yet).
https://endtimes.dev/why-your-website-should-be-under-14kb-i...