Live data from Hacker News

The 1987 game “The Last Ninja” was 40 kilobytes

twitter.com

91–100 of 199 posts

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#91
post #35

Oh man the tape loading time. I dreamed about being able to afford a disk drive.

The loading music is exceptional and I enjoyed listening to it while waiting. I still occasionally listen to it.

Well I got to listen to it a lot lol.

Since you enjoy SID music checkout this crazy hack someone did with 8 SID chips.

https://www.youtube.com/watch?v=nhz3vHYX0E0

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#92

A multi-level generative dungeon-crawler in 10 lines of code: https://bunsen.itch.io/the-snake-temple-by-rax We lost something in the bloat, folks. Its time to turn around and take another look at the past - or at least re-adjust the rearview mirror to actually look at the road and not ones makeup ..

Gluecode-First Engineering: the free-love utopia of sharing code resulted in engineers abandoning whole-design and defaulting to just creating mash-ups of pre-existing code.

Nobody designs whole-apps anymore, it’s all about minimizing the gluecode written for the 1200 dependencies that make your app buzzword-compliant.

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#94
post #66

Earlier quoted context omitted.

Your third example seems to generate 2G of data at runtime, so misleadingly minimalistic

All of them generates tons (up to tens of gigabytes or more) of data during runtime, but they all output it, and don't store them on disk or RAM. They are highly dynamic programs, and not very different from game engines on that regard. > misleadingly minimalistic. That's the magic of these programs or demoscene in general. No misleading. That's the goal.

I’m on my phone so cannot run it, but you cannot generate data and not store it somewhere. It’s going to consume either system resources (RAM/storage) or video resources (VRAM).

If your point is that it uses gigabytes of VRAM instead of system memory, then I think that is an extremely weak argument for how modern software doesn’t need much memory because all you’re doing is shifting that cost from one stack of silicon to a a different stack silicon. But the cost is still the same.

The only way around that is to dynamically generate those assets on the fly and streaming them to the video card. But then you’re sacrificing CPU efficiency for memory efficiency. So the cost is still there.

And I’ve already discussed how data compresses better as vectors than as bitmaps and PCM but is significantly harder to work with than bitmaps and waveforms. using vectors / trackers are another big trick for demos that aren’t really practical for a lot of day to day development because they take a little more effort and the savings in file sizes are negligible for people with multi-GB (not even TB!!!) disks.

As the saying goes: there’s no such thing as a free lunch.

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#95

Wow that search/interact mechanic is obnoxious, you can see the player fumbling it every time, despite knowing exactly where the item is they’re trying to collect.

This is sort of the defining mechanic of these games in my memory. The first thing that pops into my head when I think of Last Ninja is aligning and realigning myself, and squatting, awkwardly and repeatedly (just like a real ninja, lol), until that satisfying new item icon appears. Perhaps surprisingly, these are very fond memories. This mechanic is augmented by not even always knowing which graphics in the environm…

> LN2 had something in a bathroom?

Toilet flush chains. You entered two different park restrooms (both marked F) and combined them to a nunchuks.

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#96
post #16

Earlier quoted context omitted.

But for some reason, Firefox refuses to play back those kinds of files. And that reason is because x264 is a free and open source implementation of the H.264 codec, and you still need to pay a license to use the patented technology regardless of how you do that. Using a free implementation of the code doesn't get you a free license for the codec.

Haven't those patents expired by now?

Some have, but it depends on the profile used, and also on the country: https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_M...

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#97
A few years ago, I decompiled a good part of the PC version of Might & Magic 1 for fun. According to Wikipedia, it had been released in 1986, although I don't know whether that refers to the PC version or to the original Apple II version.

It is a quite big game: the main executable is 117KB, plus around 50 overlay files of 1.5 KB each for the different dungeons and cities, plus the graphics files. I guess it was even too big for the average PC hardware at that time, or it was a limitation inherited from the original Apple II version: When you want to cast a spell you have to enter the number of the spell from the manual, maybe because there was not enough memory to fit the names of the 94 spells into RAM. Apart from that and the limited graphics and the lack of sound, the internal ruleset is very complete. You have all kind of spells and objects, capabilities, an aging mechanism, shops, etc.. The usual stuff that you also see in today's RPGs.

The modern uninstall.exe that came with it (I bought the game on GOG) was 1.3MB big.

Re: The 1987 game “The Last Ninja” was 40 kilobytes

#99
Around the time DirectX came around and first games requiring it appeared, which in my memory coincided with hard drives getting way bigger and first games being delivered on a CD instead of floppies, I've been apalled at how I could see literal BMPs being written to disk during the installation. This was the same time when cracked games were being distributed via BBS at a fraction of the original size with custom installers which decompressed MP3s to their original WAV files. I've asked the same questions then: why WAV, why BMP, why the bloat? With time I've learned the answer: disk space is cheap, memory and CPU cycles are not, if you can afford to save yourself the decoding step, you just do it, your players will love it. You work with constraints you have and when there loosen up, your possibilities expand too.
Post reply on HN