It was magic and... shit. And skills plus commitment, of course: nowadays any single lazy fuck could make a (boring, stupid, mobile, money-grabbing shitty) "game".

And modern projects are too damn complex because reasons. There's also that.

I love how, nowadays, no one cares about space or speed when coding, but you stil find those challenges "simulated" as games of their own : Human Resource Machine, Spacechem, TIS-100, etc... where your score depends on minimizing the number of cycles or the number of code lines.

The art and value of minimalistic coding is preserved, outside of their need, in puzzles where they become their own sake.

I'm not sure if that affects storage size? The again I'm not a game dev. Certainly on most projects I've worked on, no matter how lazy you are with your code, it's tiny when compiled.

I'll tell you how I do it:
UU DD LR LR B A START

One other thing:

The bigger the game (size-wise), the worse performance, everything else being equal. More data needed by the game means more of a need to access the disk (hence leading to worse load times), and also means that the game's working set does not easily fit into the CPU cache. (A google search reveals that certain modern i7 Intel CPUs (the high end) have 8MB of cache, large enough to fit a game like Super Metroid, for example.)

Also, I think the tooling for game development (and software development in general) is just not meant for small, space-efficient games. As a simple example, I just compiled a simple hello world program, statically linked to musl libc (so we're counting the size of everything needed for the program to run, and the executable is 80.8 kilobytes, more than what could fit in the address space of the MSX or Commodore 64 (or other 8-bit systems with 16-bit address spaces, which was typical at the time). (A dynamically linked version is still 10.4K, which is still much bigger than the assembly code that would do the same on an old microcomputer.)


I wouldn't necessarily call 10K "tiny" in some contexts (particularly for something like a "Hello World" program), and that's the size of the dynamically linked (to musl libc) Hello World program I mentioned.

And it works on Linux through WINE. I just tried it and played until I got stuck in a wall. Has the Quake 3 wibe.

Reminds me of these gems:

https://www.youtube.com/watch?v=bmuHF06oJ6k (Driller)

https://www.youtube.com/watch?v=rPHnEEOpV5g (Total Eclipse)

There was a thing, called data compression. It was used by game developers along with performance optimization (another outdated concept) before Internet became commonplace and games were distributed via disks or other physical medium, so development team had only one attempt to make build of the game actually working and fitting space on the disk.

Well, other than obvious reasons of hving much reduced texture sprites 2 work with compared 2 those generating current huge 3D maps, the secret is being innovative 2 get ard the limit constraints of that time, either thru code optimisations &/or reusing much of the data stored.

Personally, i think it's pretty interesting 2 read up on all these past challenges & i'm not exactly of fan of games with dozens of GB (which is basically almost every top AAA out there). Not only r they a pain 2 dl, they take up wayyy too much space when installed & unless u hv a drive with BIG capacity, sooner or later 1 will run out of space which in my case is pretty quickly.

So i think it might be abt time games developers start going b 2 the drawing board rethink abt optimising the game codes more effectively rather than churning out GB aft GB of super high-resolution maps & other data files w/o a care 4 limits even though there dun really seem 2 b 1 now.

Just my humble opinion.

A lot of it was, instead of using several megabytes worth of "standard library" just because you need one function out of it, you wrote all your damn code yourself.

There is a lot of bloat in modern games. In between lazy programming practices (which is kind of excused in that why waste development time on making something performing better if it's just a few more processing cycles from dumping cookie-cutter solution in it... though it accumulates), increased code complexity (or simply the sheer amount of code things like AAA titles require), through use of third-party solutions even though they aren't as optimized as custom (but cheaper - see point no. 1)...

Also, it's big business nowadays. Last time I was exposed to big-studio development environment, there was nowhere near the level of professional pride in your work as I remember from days long gone.

The average underpaid code monkey nowadays might still be passionate about gaming in general, but they certainly are neither interested, required, not empowered by the employer enough to try to squeeze some extra performance out of their code.

It's just a job, you're better off focusing on meeting the insane deadlines than trying to make your code as efficient as possible. Most large studios (if not all, for all I know) run on constant "crunch" mode, because it's cheaper to burn out your employees than budget for a "less aggressive" - read, even remotely reasonable - production cycle.

They used to code in in languages much closer to Machine Code like Assembly.
That way you can have complex software that weighs in at a handful of KB, back then a few KB could make the difference.

Even with assembly in mind, knowing that many games were coded in BASIC and still accomplished what they did, is another feat of itself.