13 ms·

The 1987 game “The Last Ninja” was 40 kilobytes

309 points by keepamovin 7mo ago

xvxvx 7mo ago
I remember this game, the way it drew itself on each screen, the nice graphics. Growing up with games on Atari, Commodore, Amstrad, and Spectrum, was a lot of fun. By comparison, COD Modern Warfare 3 is 6,000,000 times larger at 240GB. Imagine telling that to someone in 1987.
- nine_k 7mo ago
  The Last Ninja ran at resolution 160x200, with effectively 2-bit color for graphic assets. It had amazing animations for that level of detail, but all the variety of the graphics could not take too much RAM even if it wanted to. The quest for photorealistic "movie-like" rendering which requires colossal amounts of RAM and compute feels like a dead end to me. I much appreciate the expressly unrealistic graphics of titles like Monument Valley.
  - Anamon 7mo ago
    160x200x2 still comes to 8 kB for a full-screen bitmap. So those 40 kB would allow for just five full screens worth of graphics/frames if stored naively. I'd say that still required some very clever programming to get that amount of scenery and animation in there, along with all the music and code. There's a reason why only few games of that time felt as mind-blowing as The Last Ninja. Even getting a basic text adventure or Pac-Man clone in those machines took some skill, but with a game like The Last Ninja, I think a lot of devs wouldn't even have known where to start to make something like it possible.
- regularfry 7mo ago
  Hardware sprite accelerators, the first GPUs. I swear there's something visceral you learn by programming that sort of system where you can literally see what it's doing, in the order it's doing it, which you just can't get any other way.
YasuoTanaka 7mo ago
It's kind of amazing how much of those old games was actual logic instead of data. Feels like they were closer to programs, while modern games are closer to datasets.
- hcs 7mo ago
  Chris Crawford called this "process intensity", he noted it at least back to 1983 with Dragon's Lair, discussed in this 1987 article https://www.erasmatazz.com/library/the-journal-of-computer/jcgd-volume-1/process-intensity.html https://www.erasmatazz.com/library/the-journal-of-computer/j...
  - makapuf 7mo ago
    Funny because I rewrote a bad port of dragons lair for a custom console with a tiny engine and huge dataset relatively, each frame having one "if press X goto frame Y" instruction.
    - hcs 7mo ago
      I phrased that badly, Dragon's Lair was the example of low process intensity.
reedycat 7mo ago
Masterpieces like these are a perfect demonstration that performance relies not only on fast processors, but on understanding how your data and code compete for resources. Truly admirable. Thanks for the trip down memory lane.
chmod775 7mo ago
That short video of the game on twitter is 11.5MB, or about 300x larger than the game itself.
- latch 7mo ago
  I'm not sure this is particularly telling. You can write a tiny program that generates a 4K image, and the image could be 1000x larger. Or, if I write a short description "A couple walks hand-in-hand through a park at sunset. The wind rustles the orange leaves.", I don't think it would be surprising to anyone that an image or video of this would be relatively huge.
- Dwedit 7mo ago
  X264 supports a lossless mode without chroma subsampling, which produces very good compression for raw emulator captures of retro game footage. It is much better than other codecs like HuffYuv, etc. But for some reason, Firefox refuses to play back those kinds of files.
  - onion2k 7mo ago
    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.
    - anthk 7mo ago
      Just in the US. Not in Europe. At least for decoding.
    - Narishma 7mo ago
      Haven't those patents expired by now?
      - layer8 7mo ago
YZF 7mo ago
I was looking at a production service we run that was using a few GBs of memory. When I add up all the actual data needed in a naive compact representation I end up with a few MBs. So much waste. That's before thinking of clever ways to compress, or de-duplicate or rearrange that data. Back in the day getting the 16KB expansion pack for my 1KB RAM ZX81 was a big deal. And I also wrote code for PIC microcontrollers that have 768 bytes of program memory [and 25 bytes of RAM]. It's just so easy to not think about efficiency today, you write one line of code in a high level language and you blow away more bytes than these platforms had without doing anything useful.
- hnlmorg 7mo ago
  Sure, if you don’t count safety features like memory management, crash handling, automatic bounds checks and encryption cyphers; as anything useful. I do completely agree that there is a lot of waste in modern software. But equally there is also a lot more that has to be included in modern software that wasn’t ever a concern in the 80s. Networking stacks, safety checks, encryption stacks, etc all contribute massively to software “bloat”. You can see how this quickly adds up if you write a “hello world” CLI in assembly and compare that to the equivalent in any modern language that imports all these features into its runtime. And this is all before you take into account that modern graphics and audio is bitmap / PCM and running at resolutions literally orders of magnitude greater than anything supported by 80s micro computers.
  - bayindirh 7mo ago
    Yes, but this doesn't prevent you from being mindful and selecting the right tools with smaller memory footprint while providing the features you need. Go's "GC disadvantage" is turned on its head by developing "Zero Allocation" libraries which run blazingly fast with fixed memory footprints. Similarly, rolling your own high performance/efficient code where it matters can save tremendous amounts of memory where it matters. Of course more features and safety nets will consume memory, but we don't have to waste it like there are no other things running on the system, no? > And this is all before you take into account that modern graphics and audio is bitmap / PCM and running at resolutions literally orders of magnitude greater than anything supported by 80s micro computers. This demo [0] is a 4kB executable. 4096 bytes. A single file. All assets, graphics, music and whatnot, and can run at high resolutions with real time rendering. This is [1] 64kB and this [2] is 177kB. This game from the same group is 96kB with full 3D graphics [3]. [0]: https://www.pouet.net/prod.php?which=52938 https://www.pouet.net/prod.php?which=52938 [1]: https://www.pouet.net/prod.php?which=1221 https://www.pouet.net/prod.php?which=1221 [2]: https://www.pouet.net/prod.php?which=30244 https://www.pouet.net/prod.php?which=30244 [3]: https://en.wikipedia.org/wiki/.kkrieger https://en.wikipedia.org/wiki/.kkrieger
le-mark 7mo ago
Apparently this person is referring to the available ram on a Commodore 64. The media (data) on disk or tape was much more than that.
- classichasclass 7mo ago
  Not much more. It all fits on a single side of a 1541 floppy. Even considering compression it couldn't be more than a couple hundred kilobytes. https://csdb.dk/release/?id=99145 https://csdb.dk/release/?id=99145
  - boomlinde 7mo ago
    It's not much, but relatively speaking it's much more.
  - dspillett 7mo ago
    I'd say up to a couple of hundred is much more than 40. Not a full decimal order of magnitude, but even without compression the 170KB on one side is up to 4½×.
  - cubefox 7mo ago
    > Not much more. It all fits on a single side of a 1541 floppy. It could still be much more depending on how much data fits on a single side of a 1541 floppy.
- chorlton2080 7mo ago
  You can access nearly 64kb of RAM on the C64, if you don't need the BASIC or Kernal (sic) ROMs. They can be software toggled in or out. Agreed that even the tape had more game data than that, but not much more.
- pjc50 7mo ago
  However, very few tapeloader games ever tried to load more assets from tape. Generally it would just load a memory image and that would be that for the entire game.
- eleveriven 7mo ago
userbinator 7mo ago
The same size as Super Mario Bros. (NES, 1985)
Morpheus_Matrix 7mo ago
[flagged]
vinkelhake 7mo ago
I grew up with and absolutely adore The Last Ninja series. I'm not going to comment on the size thing because it's so trite. Instead - here's [0] Ben Daglish (on flute) performing "Wastelands" together with the Norwegian C64/Amiga tribute band FastLoaders. He unfortunately passed away in 2018, just 52 years old. If that tickled your fancy, here's [1] a full concert with them where they perform all songs from The Last Ninja. [0] https://www.youtube.com/watch?v=ovFgdcapUYI https://www.youtube.com/watch?v=ovFgdcapUYI [1] https://www.youtube.com/watch?v=PTZ1O1LJg-k https://www.youtube.com/watch?v=PTZ1O1LJg-k
- kbenson 7mo ago
  The first time I ever heard The Glitch Mob I had such a clear memory of this games soundtrack come to mind that I mentioned it to my brother soon after (as it was his commodore and his copy of the game I was playing when I was young). I'm not even sure if the song I heard even sounds like the game soundtrack particularly closely, but the connection in my mind was very strong.
  - antisol 7mo ago
    I know exactly how you feel - The Way Out Is In (https://youtu.be/kqFqG-h3Vgk https://youtu.be/kqFqG-h3Vgk) heavily evokes video games for me
- uxcolumbo 7mo ago
  R.I.P Ben. He was such a positive human being and encouraging you to do great things, even if you doubted yourself. Here is a little clip of him from Bedroom to Billions: https://www.youtube.com/watch?v=aRsLOUYL3mk https://www.youtube.com/watch?v=aRsLOUYL3mk
- emil-lp 7mo ago
  Here's more from FastLoaders: https://c64audio.com/pages/fastloaders https://c64audio.com/pages/fastloaders
- dwd 7mo ago
  Reyn Ouwahand who composed The Last Ninja 3 with Fastloaders. https://www.youtube.com/watch?v=0bobBcV4HcY https://www.youtube.com/watch?v=0bobBcV4HcY He also has a few nostalgia triggering covers of some Galway tracks. https://www.youtube.com/watch?v=n7niD6i4020 https://www.youtube.com/watch?v=n7niD6i4020 https://www.youtube.com/watch?v=PTSUR3RHh9M https://www.youtube.com/watch?v=PTSUR3RHh9M
mock-possum 7mo ago
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.
- beautron 7mo ago
  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 environment can be picked up, or by invisible items that are inside boxes or otherwise out of sight (I think LN2 had something in a bathroom? You have to position yourself in the doorway and do a squat of faith). The other core memory is the spots that require a similarly awkward precision while jumping. These are worse, because each failure loses you one of your limited lives. The combat is also finicky. I remember if you come into a fight misaligned, your opponent might quickly drain your energy while you fail to get a hit in. At the time, it seemed appropriate to me that it required such a difficult precision to be a ninja. I was also a kid, who approached every game non-critically, assuming each game was exactly as it was meant to be. Thus I absolutely loved it, lol.
  - medwards666 7mo ago
    > LN2 had something in a bathroom? You have to position yourself in the doorway and do a squat of faith) Sounds like every time I go to the bathroom ... :D
  - bni 7mo ago
    > LN2 had something in a bathroom? Toilet flush chains. You entered two different park restrooms (both marked F) and combined them to a nunchuks.
- nekooooo 7mo ago
  joysticks only had one fire button.
cubefox 7mo ago
A game which was actually 40 kilobytes: Super Mario Bros. It had 32 side-scrolling levels.
- benchloftbrunch 7mo ago
  27 unique levels. 40KB minus a handful of spare bytes and some unused code. The max the NES can support without mappers. Modern NES homebrew and demoscene can do fancier stuff with this budget given the extra decades of learned tricks, but for the state of console gaming in 1985, SMB1 is damn impressive. Also remember all of that was ROM, the NES had a mere 2 kilobytes of RAM for all your variables and buffers.
aaa_aaa 7mo ago
I played the game. Music was exceptional.
- a96 7mo ago
  It really was. I was just wondering if Last Ninja 2 (Amiga) was the first game I actually liked playing. I mostly hated old games and I still don't like most games. Particularly ones with twitchy controls or platforming. LN wasn't that easy and it was very linear, but it was still somehow incredibly fun. And the music and even the graphics were great.
ychompinator 7mo ago
[dead]
socalgal2 7mo ago
Most games back then where small. An C64 only had 64k and most game didn't use all of it. An Atari 800 had max 48k. It wasn't until the 1200 that it went up. Both systems are cartridge based games, many of which were 8k. Honestly though, I don't read much into the sizes. Sure they were small games and had lots of game play for some defintion of game play. I enjoyed them immensely. But it's hard to go back to just a few colors, low-res graphics, often no way to save, etc... for me at least, the modern affordances mean something. Of course I don't need every game to look like Horizon Zero Dawn. A Short Hike was great. It's also 400meg (according to steam)
- boptom 7mo ago
  The modern classic, Animal Well, is only 35mb in size! https://store.steampowered.com/app/813230/ANIMAL_WELL/ https://store.steampowered.com/app/813230/ANIMAL_WELL/
  - a96 7mo ago
    Wow, you could fit tens of those in one bit! (sorry)
  - msephton 7mo ago
    That's multiple factors larger than my game YOYOZO which is only 39 KB
- shiroiuma 7mo ago
  >But it's hard to go back to just a few colors, low-res graphics, often no way to save, etc... for me at least, the modern affordances mean something. All those old games have a way to save now, if you run them in an emulator as is commonly done these days. That's how I played through Metroid and finally beat the mother brain in just a day or two during the pandemic.
- the_af 7mo ago
  > Sure they were small games and had lots of game play for some defintion of game play. I enjoyed them immensely. But it's hard to go back to just a few colors, low-res graphics, often no way to save, etc... for me at least, the modern affordances mean something. On one hand, you're of course right. It is hard to go back, except for the nostalgia. On the other, do you know there is a scene of people still making brand new games for the Commodore 64 (and other home computers)? And selling them, too, these are not just free games. Of course the target audience is themselves, they make, sell and buy games within the community, but the point is it still exists. Also there are artists making art in C64 graphics resolutions and color modes, and even PETSCII art enthusiasts (PETSCII is C64's text mode, which had some interesting symbols which facilitate creativity).
christkv 7mo ago
Oh man the tape loading time. I dreamed about being able to afford a disk drive.
- boptom 7mo ago
  The loading music is exceptional and I enjoyed listening to it while waiting. I still occasionally listen to it.
  - christkv 7mo ago
    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 https://www.youtube.com/watch?v=nhz3vHYX0E0
  - the_af 7mo ago
    Last Ninja has my favorite music from the C64 era. Have you listened to the live versions by the Fastloaders? They had Ben Daglish before he passed away.
    - christkv 7mo ago
      I will now :D
abrookewood 7mo ago
God I loved that game. Don't think I ever managed to finish and now I'm tempted to try again!
zoenolan 7mo ago
See also Elite in 22KB https://youtu.be/lC4YLMLar5I https://youtu.be/lC4YLMLar5I Previously: https://news.ycombinator.com/item?id=38707095 https://news.ycombinator.com/item?id=38707095
anthk 7mo ago
Some Pokémon Crystal ROMs pack a huge amount of gaming in very few MB. Z80-ish ASM, KB's of RAM. The ZMachine games, ditto. A few kb's and an impressive simulated environment will run even under 8bit machines running a virtual machine. Of course z3 machine games will have less features for parsing/obj interaction than z8 machine games, but from a 16 bit machine and up (nothing today, a DOS PC would count) will run z8 games and get pretty complex text adventures. Compare Tristam Island or the first Zork I-III to Spiritwrak, where a subway it's simulated, or Anchorhead. And you can code the games with Inform6 and Inform6lib with maybe a 286 with DOS or 386 and any text editor. Check Inform Beginner's Guide and DM4.pdf And not just DOS, Windows, Linux, BSD, Macs... even Android under Termux. And the games will run either Frotz for Termux or Lectrote, or Fabularium. Under iOS, too. Nethack/lashem weights MB's and has tons of replayability. Written in C. It will even run under a 68020 System 7 based Mac... emulated under 9front with an 720 CPU as the host. It will fly from a 486 CPU and up. Meanwhile, Cataclysm DDA uses C++ and it needs a huge chunk of RAM and a fastly CPU to compile it today. Some high end Pentium4 with 512MB of RAM will run it well enough, but you need to cross compile it. If I had the skills I would rewrite (no AI/LLM's please) CDDA:BN into Golang. The compiling times would plummet down and the CPU usage would be nearly the same. OFC the GC would shine here prunning tons of unused code and data from generated worlds.
jml7c5 7mo ago
Is this even correct? It was a two-sided disk, and each side was 174 KB.
Steve16384 7mo ago
Pretty much every 8-bit computer game of 1987 or earlier (before the 128kB machines became popular) were < 40Kb? The Spectrum and Commodore combined probably had a library in excess of 50,000 games.
- forinti 7mo ago
  I love how you can put all the games ever made for a given 8 bit platform on a single flash drive.
DrBazza 7mo ago
If we're talking about fitting a quart into a pint pot, it would be remiss not to mention Elite fitting into a BBC Model B, 32kb, and the excellent code archaeology of it, and variants by Mark Moxon here: https://www.bbcelite.com/ https://www.bbcelite.com/
krisgenre 7mo ago
.. and Claude Code for Linux, the CLI binary is 200+ mb :(
rigonkulous 7mo ago
A multi-level generative dungeon-crawler in 10 lines of code: https://bunsen.itch.io/the-snake-temple-by-rax 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 ..
- nacozarina 7mo ago
  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.
alex_john_m 7mo ago
Some comments here sound like the ones I hear from car "enthusiasts" praising old engines for being simple to run and easy to fix, then complaining about modern engines being too complicated and how we should return to the "good old days", all that without taking into account the decades of progress since then. Want to prove a point? Give me Skyrim in 64k of ram. Go ahead! I dare you!
- Anamon 7mo ago
  It's an interesting comparison. There's a lot of objective truth to it on both sides, though. Having a car as a project, maintaining and fixing and learning stuff yourself, is pretty much impossible with modern cars. Even before you get to the online crap, they're more services than products, with proprietary ICs and stuff that make everything "non-user-servicable". I'm not a car guy but I can understand that something major was lost. I can also see some parallels to games there, with all the encryptions, DRMs, kernel anti-cheats, online ties... it usually invites a lot less tinkering and modding than the games of old.
dspillett 7mo ago
> isometric on the C64 with such an amazing level of detail - simply gorgeous Or a convincing representation of that. A lot of old tricks mean that the games are doing less than you think that they are, and are better understood when you stop thinking “how do they do that” and “how are they convincing my brain that is what they are doing”. Look at how little RAM the original Elite ran in on a BBC Model B, with some swapping of code on disk⁰. 32KB, less the 7.75KB taken by the game's custom screen mode² and a little more reserved for other things¹. I saw breathy reviews at the time and have seen similar nostalgic reviews more recently talking about “8 whole galaxies!” when the game could easily have had far more than that and was at one point going to. They cut it down not for technical reasons but because having more didn't feel usefully more fun and might actually put people off. The galaxies were created by a clever little procedural generator so adding more would have only added a couple of bytes (to hold the seed and maybe other params for the generator) each. Another great example of not quite doing what it looks like the game is doing is the apparently live-drawn 3D view in the game Sentinel on a number of 8-bit platforms. -------- [0] There were two blocks of code that were swapped in as you entered or self a space station: one for while docked and one for while in-flight. Also the ship blueprints were not all in memory at the same time, and a different set was loaded as you jumped from one system to another. [1] the CPU call stack (technically up to a quarter K tough the game code only needed less than half of that), scratch-space on page-zero mostly used for game variables but some of which was used by things like the disk controller ROM and sound generator, etc. [2] Normal screen modes close to that consumed 10KB. Screen memory consumption on the BBC Master Enhanced version was doubled as it was tweaked to use double the bit depths (4ppb for the control panel and 2bbp for the exterior, instead of 2bbp and 1ppb respectively).
choam2426 7mo ago
We live in an age of abundant memory — until you check RAM prices.
xg15 7mo ago
The consequence of "space is cheap" / "If I didn't use that RAM, it would just sit there unused anyway" etc.
axegon_ 7mo ago
Despite being a mid-late-millennial, I can see how this played out. Even compared to the second family computer my parents got in the late 90's, which was an absolute monster at the time, I do realize how many corners and shortcuts developers had to make to get a game going in a few hundred megabytes, seeing mobile games today easily exceeding 10 times that, and not just now but even 10 years ago when I was working at a company that made mobile games. These days, developers are automatically assuming everyone has what are effectively unlimited resources by 90's standards(granted they haven't transitioned to slop-coding, which makes it substantially worse). Personally, I have a very strange but useful habit: when I find myself with some spare time at work, I spin up a very under-powered VM and start running what is in production and try to find optimizations. One of the data pipelines I have is pretty much insanity in terms of scale and running it took over 48 hours. Last time(a few weeks ago actually), I did the VM thing and started looking for optimizations and I found a few, which were completely counter-intuitive at first and everyone was like "na, that makes no sense". But now the pipeline runs in just over 10 hours. It's insane how much shortcuts you force yourself to find when you put a tight fence around you.
- keepamovin 7mo ago
  Yes this is a great methodology. I found developing BrowserBox (which is real time interactive streaming for remote browsers), using slow links, and a variety of different OS, really stresses parts of the system and causes improvements to be necessary that strengthen the whole.
Findecanor 7mo ago
> “The Last Ninja” was 40 kilobytes I have got 1.1 GB of MP3s with just remixes of the music from the three games, some of which are from a Kickstarter from the composer for the second.
khaledh 7mo ago
Constraints breed creativity.
andai 7mo ago
I shipped a browser game that was 8KB. Okay, plus 30 million lines of Chromium ;) Most of my games are roughly in that range though. I think my MMO was 32KB, and it had a sound effects generator and speech synth in it. (Jsfxr and SAM) I built it in a few days for a game jam. I'm not trying to brag, I'm trying to say this stuff is easy if you actually care. Just look at JS13K. Every game there is 13KB or below, and there's some real masterpieces there. (My game was just squares, but I've seen games with whole custom animation systems in them.) Once you learn how, it's pretty easy. But you'll never learn if you don't care. You have to care because there's nothing forcing you. Arguably The Last Ninja would have been a lot more than 40KB if there weren't the hardware limitations of the time. They weren't trying to make it 40KB, they were just trying to make a game. In my case, I enjoy the challenge! (Also I like it when things load instantly :) I think I'll make a PS1 game next. I was inspired by this guy who made a Minecraft clone for Playstation: https://youtu.be/aXoI3CdlNQc?is=sDNnrGbQGJt_qnV6 https://youtu.be/aXoI3CdlNQc?is=sDNnrGbQGJt_qnV6 P.S. most Flash games were only a few kilobytes, if you remove the music!
emsign 7mo ago
And it was one of the best games ever made. Back in the day equivalent to a AAA tier game of today.
tralarpa 7mo ago
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.
- Pannoniae 7mo ago
  >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 Probably not ;) "Enter things from a manual" was a tried old copy protection technique. If you used the warez version you presumably did not have a manual so you got stuck. This didn't run on the 8008 or whatever, I'm sure the game could have known the names of spells fairly easily.
  - tralarpa 7mo ago
    Ah, that makes more sense than my theory. It's a weak copy protection method, though, as you can just try and see what happens, and I think they dropped it in M&M3.
    - Anamon 7mo ago
      Yes, and it was pretty easily photo-copied since it had to be printed all in one place anyway. That's probably why even print-based protections tried to get cleverer. Like the code wheels, although I remember those didn't take that much more effort. Disassemble the original, copy all layers, cut out the right holes, put back on a spindle. I remember one game I had that tried to protect against it by having a manual of about 100 pages, with the passcodes being spread across all of them. I believe it was Gunship 2000.
midzer 7mo ago
My website https://midzer.de/ https://midzer.de/ is themed like "The Last Ninja II" which is the first game I've encountered when I was young.
pronik 7mo ago
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.
- Anamon 7mo ago
  However, in the early days of the CD-ROM games, the trade-off wasn't simple. It was cheap for manufacturers to fill the entire 650 MB of the disc, but for the players, HDD storage by GB wasn't. And just keeping the stuff on the disc was often no option either because of seek times. You usually don't want to wait the half second it takes for the drive to move the laser to where the next sound effect is stored. I also fondly remember those scene re-packs! Some of them had such clever and extreme compression that it took several hours to re-inflate the game. Remember Uharc? =)
frereubu 7mo ago
So you can read replies etc. without having to be logged in to X: https://xcancel.com/exQUIZitely/status/2040777977521398151 https://xcancel.com/exQUIZitely/status/2040777977521398151
guerrilla 7mo ago
That's just incredible. People used to be so much better at programming, or at least great programmers had it easier to get funded. Most of what I see today is exceptionally low quality and just getting worse with time.
pronik 7mo ago
Speaking of the size: my first PC, built by a family friend, had a 80MB disk, split into two partitions. The second 40MB partition had Windows 3.1 and about two Norton Commander columns full of games on it, largest of which were Wolfenstein 3D and Lost Vikings with about 1.4MB each. Truly a different era.
forinti 7mo ago
I was comparing games prices last week and I found that prices from the 80s aren't too different from modern game prices. Elite was £20 in 1984 and that would be £66 today, which is not very different from what a good game for the PS5 costs today. Except that games then were made by one or two people and nowadays games are made by teams with coders, musicians, artists, etc.
- matthewkayin 7mo ago
  Yeah, the games industry is in a pretty big crisis right now, and I think change needs to happen both ways: Consumers need to understand that keeping games at the same price for decades despite rising costs and inflation is not realistic. If they want the industry to thrive, they need to be ok with games being more expensive. Meanwhile, developers need to stop making games so expensive. This is an entertainment industry / corpo problem, really. Companies have seen the big profits and decided that only the big profits will do, which means you need to make a big open world cinematic experience, which is expensive, and because it's expensive, they won't take risks on making anything actually interesting. The only way gaming moves forward is if we make riskier games that cost less to produce, which is why indies are the ones making the good games these days.
cineticdaffodil 7mo ago
I wonder could you make a fame that small by using svgs?
1970-01-01 7mo ago
[flagged]
- y-curious 7mo ago
  The LLM-use witch hunt accusations are rampant on every single article. That snippet doesn’t sound like an LLM to me. Have your coffee and consider that this person was just complimenting coders from back in the day.
  - 1970-01-01 7mo ago
    [flagged]
    - zahlman 7mo ago
      The text you quoted is not an example of the trope you highlighted. It genuinely comes across like you're calling it LLM generated purely because of the "em-dash", except it isn't even an em-dash.
      - 1970-01-01 7mo ago
        And I genuinely admire the actual effort to get it right. You looked just enough to catch the error but not enough to prove it was human. Keep going, the tell is in there.
        zahlman 7mo ago
        I genuinely have no idea what you're trying to claim. If you have a point, you should express it clearly. If you believe something to be the case, you should present evidence straightforwardly and make an explicit logical argument.
neurworlds 7mo ago
40kb and it felt like a full world... I'm burning through tokens to get AI to decide whether to go to the tavern or the market. Something went wrong somewhere
bjt12345 7mo ago
I never figured out how they did the turtle graphics in this game. The C64 didn't have whole screen bitmaps, you could either use sprites or user defined character sets, neither of which made this straightforward. And the loading screens were also amazing, particularly for tape loading.
- EvanAnderson 7mo ago
  You might be thinking of another system (like the NES, perhaps), because the C64 has 160x100 and 320x200 bitmap modes.
  - hcs 7mo ago
    Even on NES a lot of games use CHR-RAM so arbitrary bitmaps are at least possible, though only a small part of the screen is unique without some rarely used mapper hardware. Zelda and Metroid mostly just use this to compress the graphics in ROM, Qix is a simple example with line drawing, Elite is an extreme one. I made a demo of the Mystify screensaver using the typical 8KB CHR-RAM. Even with a lot of compromises it has pretty large borders to avoid running out of unique tiles. https://youtube.com/watch?v=1_MymcLeew8 https://youtube.com/watch?v=1_MymcLeew8
    - EvanAnderson 7mo ago
      Elite is my go-to example for madness in a tile-based grapgics system. Watching the CHR-RAM in an emulator while Elite is running is mesmerizing.
- steve_taylor 7mo ago
  The C64 does have a couple of bitmap modes. The Last Ninja uses mode 3, which is multicolor bitmap mode. It occupies 9000 bytes including pixels (8000 bytes) and color RAM (1000 bytes).
- smcameron 7mo ago
  The TI99/4a version of the Logo language which has turtle graphics used user defined characters to implement them. There were only (I think) 128 user definable characters, and when the turtle graphics had redefined all of them to create its output, it gave the user a message, "out of ink".
tiku 7mo ago
A lot of trial and error. I've built graphical tools with GD in PHP, the difficult part for me what that the coordinates where inverted.. I only knew how to draw lines and pixels, but I got the job done.
oweiler 7mo ago
That game felt like a graphics demo though. Almost unplayable.
nobodyandproud 7mo ago
The music and atmosphere was gorgeous. Fond memories of wasted youth I never finished the game, sadly.
eleveriven 7mo ago
It really puts into perspective how different the constraints were
lutusp 7mo ago
> ... 40 kilobytes. How times have changed. My best-selling program "Apple Writer", for the Apple II, ran in eight kilobytes. It was written entirely in 6502 assembly language.
commandlinefan 7mo ago
Amazing what you can accomplish when you have more than "a sprint" to deliver something and no project manager asking "are you done yet?"
- sonzohan 7mo ago
  Recovering game dev here The publisher for this game was Activision. They absolutely had deadlines, lots of (1987) money invested in this, outsourced to a third party company in Hungary, had the outsource team fail, moved development platforms a few times, wrote a programming language and a game engine, and then became the best selling C64 game. Very much development hell.
praptak 7mo ago
I remember playing a version of this game on ZX Spectrum but I cannot find it on the internet. I remember it had bees that you had to avoid and a boat which you were able to untie so that it floats down a stream. Anybody remember this one?
drob518 7mo ago
We made the most of limited resources back then. Back in 1980, I was living large with my 64KB Apple II with dual 140KB floppy drives and a 10 inch (9 inch? I can’t quite remember) amber monochrome monitor. Most had less.
derefr 7mo ago
> I still struggle to comprehend, even in the slightest, how programmers back then did what they did - and the worlds they created with the limitations they had to work with. Highly related: two videos covering exactly how they fit... - Super Mario Bros 1 into 40KiB (https://www.youtube.com/watch?v=1ysdUajrhL8 https://www.youtube.com/watch?v=1ysdUajrhL8) - and Super Mario Bros 2 into 256KiB (https://www.youtube.com/watch?v=UdD26eFVzHQ https://www.youtube.com/watch?v=UdD26eFVzHQ) I highly advise watching the actual videos to best understand, since all the techniques used were very likely devised from a game-dev perspective, rather than by invoking any abstract CS textbook learning. But if I did want to summarize the main "tricks" used, in terms of such abstract CS concepts: 1. These old games can be understood as essentially having much of their data (level data, music data, etc) "compressed" using various highly-domain-specific streaming compressors. (I say "understood as" because, while the decompression logic literally exists in the game, there was likely no separate "compression" logic; rather, the data "file formats" were likely just designed to represent everything in this highly-space-efficient encoding. There were no "source files" using a more raw representation; both tooling and hand-edits were likely operating directly against data stored in this encoding.) 2. These streaming compressors act similar to modern multimedia codecs, in the sense that they don't compress sequences-of-structures (which would give low sequence correlation), but instead first decompose the data into distinct, de-correlated sub-streams / channels / planes (i.e. structures-of-sequences), which then "compress" much better. 3. Rather than attempting to decompose a single lossless description of the data into several sub-streams that are themselves lossless descriptions of some hyperplane through the data, a different approach is used: that of each sub-channel storing an imperative "painting" logic against a conceptual mutable canvas or buffer shared with other sub-channels. The data stream for any given sub-channel may actually be lossy (i.e. might "paint" something into the buffer that shouldn't appear in the final output), but such "slop"/"bleed" gets overwritten — either by another sub-channel's output, or by something the same sub-channel emits later on in the same "pass". The decompressor essentially "paints over" any mistakes it makes, to arrive at a final flattened canvas state that is a lossless reproduction of the intended state. 4. Decompression isn't something done in its entirety into a big in-memory buffer on asset load. (There isn't the RAM to do that!) But nor is decompression a pure streaming operation, cleanly producing sequential outputs. Instead, decompression is incremental: it operates on / writes to one narrow + moving slice of an in-memory data "window buffer" at a time. Which can somewhat be thought of as a ring buffer, because the decompressor coroutine owns whichever slice it's writing to, which is expected to not be read from while it owns it, so it can freely give that slice to its sub-channel "painters" to fill up. (Note that this is a distinct concept from how any long, larger-than-memory data [tilemaps, music] will get spooled out into VRAM/ARAM as it's being scrolled/played. That process is actually done just using boring old blits; but it consumes the same ring-buffer slices the decompressor is producing.) 5. Different sub-channels may be driven at different granularities and feed into more or fewer windowing/buffering pipeline stages before landing as active state. For example, tilemap data is decompressed into its "window buffer" one page at a time, each time the scroll position crosses a page boundary; but object data is decompressed / "scheduled" into Object Attribute Memory one column at a time (or row at a time, in SMB2, sometimes) every time the scroll position advances by a (meta)tile width. 6. Speaking of metatiles — sub-channels, rather than allowing full flexibility of "write primitive T to offset Y in the buffer", may instead only permit encodings of references to static data tables of design-time pre-composed patterns of primitives. For tilemaps, these patterns are often called "meta-tiles" or "macro-blocks". (This is one reason sub-channels are "lossy" reconstructors: if you can only encode macro-blocks, then you'll often find yourself wanting only some part of a macro-block — which means drawing it and then overdrawing the non-desired parts of it.) 7. Sub-channels may also operate as fixed-function retained-mode procedural synthesis engines, where rather than specifying specific data to write, you only specify for each timestep how the synthesis parameters should change. This is essentially how modular audio synthesis encoding works; but more interestingly, it's also true of the level data "base terrain" sub-channel, which essentially takes "ceiling" and "ground" brush parameters, and paints these in per column according to some pattern-ID parameter referencing a table of [ceiling width][floor height] combinations. (And the retained-mode part means that for as long as everything stays the same, this sub-channel compresses to nothing!) 8. Sub-channels may also contain certain encoded values that branch off into their own special logic, essentially triggering the use of paint-program-like "brushes" to paint arbitrarily within the "canvas." For example, in SMB1, a "pipe tile" is really a pipe brush invocation, that paints a pipe into the window, starting from the tile's encoded position as its top-left corner, painting right two meta-tiles, and downward however-many meta-tiles are required to extend the pipe to the current "base terrain" floor height. 9. Sub-channels may encode values ("event objects") that do not decode to any drawing operation to the target slice buffer, but which instead either immediately upon being encountered ("decompression-time event objects") or when they would be "placed" or "scheduled" if they were regular objects ("placement-time event objects"), just execute some code, usually updating some variable being used during the decompression process or at game runtime. (The thing that prevents you from scrolling the screen past the end of map data, is a screen-scroll-lock event object dropped at just the right position that it comes into effect right before the map would run out of tiles to draw. The thing that determines where a "warp-enabled pipe" will take you, is a warp-pipe-targeting event object that applies to all warp-enabled pipes will take you after it runs, until the next warp-pipe-targeting event object is encountered.) If at least some of these sub-channels are starting to sound like essentially a bytecode ISA for some kind of abstract machine — yes, exactly. Things like "event objects" and "brush invocations" can be more easily understood as opcodes (sometimes with immediates!); and the "modal variables" as the registers of these instruction streams' abstract machines. [continued...]
tombert 7mo ago
Not as small as The Last Ninja, but when I was a teenager first getting into emulation, I genuinely thought there was a mistake or my download got interrupted when I downloaded Super Mario Bros. 3, because it was only like 500kb [1], and I didn't think it was possible for a game that huge to be less than a megabyte. It is still impressive to me how much game they could squeeze out of the NES ROM chips. [1] Or something like that, I don't remember the exact number.
atlanta90210 7mo ago
The original arcade version of Pac-Man is 24 kilobytes
TitaRusell 7mo ago
Death Stranding 2 was 140 gigabyte. Ofcourse luckily our SSDs got bigger too.
lykahb 7mo ago
Many mobile J2ME games in the 2005-2015 had a similar size and were impressive too. Sometimes a time window appears and creates the economic incentives for optimization ingenuity.
msephton 7mo ago
My game YOYOZO is 39 KB and was listed as one of the "Best Games of 2023" alongside Mario & Zelda & Baldur's Gate 3. So it's still possible to do this sort of thing if you care enough and have the right constraints! If you don't have those constraints, simply impose some on yourself. https://news.ycombinator.com/item?id=38372936 https://news.ycombinator.com/item?id=38372936
kazinator 7mo ago
It's not just that programs had small images. The noteworthy thing is that they weren't small due to externalizing their dependencies. They relied on no third party code other than a few meagre services of the operating system. They did their own sound and graphics down to the pixel level. We can't compare 40 KB image today to a 40 KB image from 1980 something, if the contemporary one relies on 100 MB of external cruft, like a rich programming language runtime (fetched and install separately) and packages.
CyborgUndefined 7mo ago
how about RE2 for nintendo 64? PS1 version was 1.2GB, compressed down to 64MB. that's 19x compression. insane.
ChrisRR 7mo ago
Well I would guess that all games on the C64 were under 64KB

309 points by keepamovin 7mo ago

xvxvx 7mo ago

I remember this game, the way it drew itself on each screen, the nice graphics. Growing up with games on Atari, Commodore, Amstrad, and Spectrum, was a lot of fun. By comparison, COD Modern Warfare 3 is 6,000,000 times larger at 240GB. Imagine telling that to someone in 1987.

nine_k 7mo ago
The Last Ninja ran at resolution 160x200, with effectively 2-bit color for graphic assets. It had amazing animations for that level of detail, but all the variety of the graphics could not take too much RAM even if it wanted to. The quest for photorealistic "movie-like" rendering which requires colossal amounts of RAM and compute feels like a dead end to me. I much appreciate the expressly unrealistic graphics of titles like Monument Valley.
- Anamon 7mo ago
  160x200x2 still comes to 8 kB for a full-screen bitmap. So those 40 kB would allow for just five full screens worth of graphics/frames if stored naively. I'd say that still required some very clever programming to get that amount of scenery and animation in there, along with all the music and code. There's a reason why only few games of that time felt as mind-blowing as The Last Ninja. Even getting a basic text adventure or Pac-Man clone in those machines took some skill, but with a game like The Last Ninja, I think a lot of devs wouldn't even have known where to start to make something like it possible.
regularfry 7mo ago
Hardware sprite accelerators, the first GPUs. I swear there's something visceral you learn by programming that sort of system where you can literally see what it's doing, in the order it's doing it, which you just can't get any other way.

YasuoTanaka 7mo ago

It's kind of amazing how much of those old games was actual logic instead of data. Feels like they were closer to programs, while modern games are closer to datasets.

hcs 7mo ago
Chris Crawford called this "process intensity", he noted it at least back to 1983 with Dragon's Lair, discussed in this 1987 article https://www.erasmatazz.com/library/the-journal-of-computer/jcgd-volume-1/process-intensity.html https://www.erasmatazz.com/library/the-journal-of-computer/j...
- makapuf 7mo ago
  Funny because I rewrote a bad port of dragons lair for a custom console with a tiny engine and huge dataset relatively, each frame having one "if press X goto frame Y" instruction.
  - hcs 7mo ago
    I phrased that badly, Dragon's Lair was the example of low process intensity.

reedycat 7mo ago

Masterpieces like these are a perfect demonstration that performance relies not only on fast processors, but on understanding how your data and code compete for resources. Truly admirable. Thanks for the trip down memory lane.

chmod775 7mo ago

That short video of the game on twitter is 11.5MB, or about 300x larger than the game itself.

latch 7mo ago
I'm not sure this is particularly telling. You can write a tiny program that generates a 4K image, and the image could be 1000x larger. Or, if I write a short description "A couple walks hand-in-hand through a park at sunset. The wind rustles the orange leaves.", I don't think it would be surprising to anyone that an image or video of this would be relatively huge.
Dwedit 7mo ago
X264 supports a lossless mode without chroma subsampling, which produces very good compression for raw emulator captures of retro game footage. It is much better than other codecs like HuffYuv, etc. But for some reason, Firefox refuses to play back those kinds of files.
- onion2k 7mo ago
  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.
  - anthk 7mo ago
    Just in the US. Not in Europe. At least for decoding.
  - Narishma 7mo ago
    Haven't those patents expired by now?
    - layer8 7mo ago

YZF 7mo ago

I was looking at a production service we run that was using a few GBs of memory. When I add up all the actual data needed in a naive compact representation I end up with a few MBs. So much waste. That's before thinking of clever ways to compress, or de-duplicate or rearrange that data. Back in the day getting the 16KB expansion pack for my 1KB RAM ZX81 was a big deal. And I also wrote code for PIC microcontrollers that have 768 bytes of program memory [and 25 bytes of RAM]. It's just so easy to not think about efficiency today, you write one line of code in a high level language and you blow away more bytes than these platforms had without doing anything useful.

hnlmorg 7mo ago
Sure, if you don’t count safety features like memory management, crash handling, automatic bounds checks and encryption cyphers; as anything useful. I do completely agree that there is a lot of waste in modern software. But equally there is also a lot more that has to be included in modern software that wasn’t ever a concern in the 80s. Networking stacks, safety checks, encryption stacks, etc all contribute massively to software “bloat”. You can see how this quickly adds up if you write a “hello world” CLI in assembly and compare that to the equivalent in any modern language that imports all these features into its runtime. And this is all before you take into account that modern graphics and audio is bitmap / PCM and running at resolutions literally orders of magnitude greater than anything supported by 80s micro computers.
- bayindirh 7mo ago
  Yes, but this doesn't prevent you from being mindful and selecting the right tools with smaller memory footprint while providing the features you need. Go's "GC disadvantage" is turned on its head by developing "Zero Allocation" libraries which run blazingly fast with fixed memory footprints. Similarly, rolling your own high performance/efficient code where it matters can save tremendous amounts of memory where it matters. Of course more features and safety nets will consume memory, but we don't have to waste it like there are no other things running on the system, no? > And this is all before you take into account that modern graphics and audio is bitmap / PCM and running at resolutions literally orders of magnitude greater than anything supported by 80s micro computers. This demo [0] is a 4kB executable. 4096 bytes. A single file. All assets, graphics, music and whatnot, and can run at high resolutions with real time rendering. This is [1] 64kB and this [2] is 177kB. This game from the same group is 96kB with full 3D graphics [3]. [0]: https://www.pouet.net/prod.php?which=52938 https://www.pouet.net/prod.php?which=52938 [1]: https://www.pouet.net/prod.php?which=1221 https://www.pouet.net/prod.php?which=1221 [2]: https://www.pouet.net/prod.php?which=30244 https://www.pouet.net/prod.php?which=30244 [3]: https://en.wikipedia.org/wiki/.kkrieger https://en.wikipedia.org/wiki/.kkrieger

le-mark 7mo ago

Apparently this person is referring to the available ram on a Commodore 64. The media (data) on disk or tape was much more than that.

classichasclass 7mo ago
Not much more. It all fits on a single side of a 1541 floppy. Even considering compression it couldn't be more than a couple hundred kilobytes. https://csdb.dk/release/?id=99145 https://csdb.dk/release/?id=99145
- boomlinde 7mo ago
  It's not much, but relatively speaking it's much more.
- dspillett 7mo ago
  I'd say up to a couple of hundred is much more than 40. Not a full decimal order of magnitude, but even without compression the 170KB on one side is up to 4½×.
- cubefox 7mo ago
  > Not much more. It all fits on a single side of a 1541 floppy. It could still be much more depending on how much data fits on a single side of a 1541 floppy.
chorlton2080 7mo ago
You can access nearly 64kb of RAM on the C64, if you don't need the BASIC or Kernal (sic) ROMs. They can be software toggled in or out. Agreed that even the tape had more game data than that, but not much more.
pjc50 7mo ago
However, very few tapeloader games ever tried to load more assets from tape. Generally it would just load a memory image and that would be that for the entire game.
eleveriven 7mo ago

userbinator 7mo ago

The same size as Super Mario Bros. (NES, 1985)

Morpheus_Matrix 7mo ago

[flagged]

vinkelhake 7mo ago

I grew up with and absolutely adore The Last Ninja series. I'm not going to comment on the size thing because it's so trite. Instead - here's [0] Ben Daglish (on flute) performing "Wastelands" together with the Norwegian C64/Amiga tribute band FastLoaders. He unfortunately passed away in 2018, just 52 years old. If that tickled your fancy, here's [1] a full concert with them where they perform all songs from The Last Ninja. [0] https://www.youtube.com/watch?v=ovFgdcapUYI https://www.youtube.com/watch?v=ovFgdcapUYI [1] https://www.youtube.com/watch?v=PTZ1O1LJg-k https://www.youtube.com/watch?v=PTZ1O1LJg-k

kbenson 7mo ago
The first time I ever heard The Glitch Mob I had such a clear memory of this games soundtrack come to mind that I mentioned it to my brother soon after (as it was his commodore and his copy of the game I was playing when I was young). I'm not even sure if the song I heard even sounds like the game soundtrack particularly closely, but the connection in my mind was very strong.
- antisol 7mo ago
  I know exactly how you feel - The Way Out Is In (https://youtu.be/kqFqG-h3Vgk https://youtu.be/kqFqG-h3Vgk) heavily evokes video games for me
uxcolumbo 7mo ago
R.I.P Ben. He was such a positive human being and encouraging you to do great things, even if you doubted yourself. Here is a little clip of him from Bedroom to Billions: https://www.youtube.com/watch?v=aRsLOUYL3mk https://www.youtube.com/watch?v=aRsLOUYL3mk
emil-lp 7mo ago
Here's more from FastLoaders: https://c64audio.com/pages/fastloaders https://c64audio.com/pages/fastloaders
dwd 7mo ago
Reyn Ouwahand who composed The Last Ninja 3 with Fastloaders. https://www.youtube.com/watch?v=0bobBcV4HcY https://www.youtube.com/watch?v=0bobBcV4HcY He also has a few nostalgia triggering covers of some Galway tracks. https://www.youtube.com/watch?v=n7niD6i4020 https://www.youtube.com/watch?v=n7niD6i4020 https://www.youtube.com/watch?v=PTSUR3RHh9M https://www.youtube.com/watch?v=PTSUR3RHh9M

mock-possum 7mo ago

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.

beautron 7mo ago
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 environment can be picked up, or by invisible items that are inside boxes or otherwise out of sight (I think LN2 had something in a bathroom? You have to position yourself in the doorway and do a squat of faith). The other core memory is the spots that require a similarly awkward precision while jumping. These are worse, because each failure loses you one of your limited lives. The combat is also finicky. I remember if you come into a fight misaligned, your opponent might quickly drain your energy while you fail to get a hit in. At the time, it seemed appropriate to me that it required such a difficult precision to be a ninja. I was also a kid, who approached every game non-critically, assuming each game was exactly as it was meant to be. Thus I absolutely loved it, lol.
- medwards666 7mo ago
  > LN2 had something in a bathroom? You have to position yourself in the doorway and do a squat of faith) Sounds like every time I go to the bathroom ... :D
- bni 7mo ago
  > LN2 had something in a bathroom? Toilet flush chains. You entered two different park restrooms (both marked F) and combined them to a nunchuks.
nekooooo 7mo ago
joysticks only had one fire button.

cubefox 7mo ago

A game which was actually 40 kilobytes: Super Mario Bros. It had 32 side-scrolling levels.

benchloftbrunch 7mo ago
27 unique levels. 40KB minus a handful of spare bytes and some unused code. The max the NES can support without mappers. Modern NES homebrew and demoscene can do fancier stuff with this budget given the extra decades of learned tricks, but for the state of console gaming in 1985, SMB1 is damn impressive. Also remember all of that was ROM, the NES had a mere 2 kilobytes of RAM for all your variables and buffers.

aaa_aaa 7mo ago

I played the game. Music was exceptional.

a96 7mo ago
It really was. I was just wondering if Last Ninja 2 (Amiga) was the first game I actually liked playing. I mostly hated old games and I still don't like most games. Particularly ones with twitchy controls or platforming. LN wasn't that easy and it was very linear, but it was still somehow incredibly fun. And the music and even the graphics were great.

ychompinator 7mo ago

[dead]

socalgal2 7mo ago

Most games back then where small. An C64 only had 64k and most game didn't use all of it. An Atari 800 had max 48k. It wasn't until the 1200 that it went up. Both systems are cartridge based games, many of which were 8k. Honestly though, I don't read much into the sizes. Sure they were small games and had lots of game play for some defintion of game play. I enjoyed them immensely. But it's hard to go back to just a few colors, low-res graphics, often no way to save, etc... for me at least, the modern affordances mean something. Of course I don't need every game to look like Horizon Zero Dawn. A Short Hike was great. It's also 400meg (according to steam)

boptom 7mo ago
The modern classic, Animal Well, is only 35mb in size! https://store.steampowered.com/app/813230/ANIMAL_WELL/ https://store.steampowered.com/app/813230/ANIMAL_WELL/
- a96 7mo ago
  Wow, you could fit tens of those in one bit! (sorry)
- msephton 7mo ago
  That's multiple factors larger than my game YOYOZO which is only 39 KB
shiroiuma 7mo ago
>But it's hard to go back to just a few colors, low-res graphics, often no way to save, etc... for me at least, the modern affordances mean something. All those old games have a way to save now, if you run them in an emulator as is commonly done these days. That's how I played through Metroid and finally beat the mother brain in just a day or two during the pandemic.
the_af 7mo ago
> Sure they were small games and had lots of game play for some defintion of game play. I enjoyed them immensely. But it's hard to go back to just a few colors, low-res graphics, often no way to save, etc... for me at least, the modern affordances mean something. On one hand, you're of course right. It is hard to go back, except for the nostalgia. On the other, do you know there is a scene of people still making brand new games for the Commodore 64 (and other home computers)? And selling them, too, these are not just free games. Of course the target audience is themselves, they make, sell and buy games within the community, but the point is it still exists. Also there are artists making art in C64 graphics resolutions and color modes, and even PETSCII art enthusiasts (PETSCII is C64's text mode, which had some interesting symbols which facilitate creativity).

christkv 7mo ago

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

boptom 7mo ago
The loading music is exceptional and I enjoyed listening to it while waiting. I still occasionally listen to it.
- christkv 7mo ago
  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 https://www.youtube.com/watch?v=nhz3vHYX0E0
- the_af 7mo ago
  Last Ninja has my favorite music from the C64 era. Have you listened to the live versions by the Fastloaders? They had Ben Daglish before he passed away.
  - christkv 7mo ago
    I will now :D

abrookewood 7mo ago

God I loved that game. Don't think I ever managed to finish and now I'm tempted to try again!

zoenolan 7mo ago

See also Elite in 22KB https://youtu.be/lC4YLMLar5I https://youtu.be/lC4YLMLar5I Previously: https://news.ycombinator.com/item?id=38707095 https://news.ycombinator.com/item?id=38707095

anthk 7mo ago

Some Pokémon Crystal ROMs pack a huge amount of gaming in very few MB. Z80-ish ASM, KB's of RAM. The ZMachine games, ditto. A few kb's and an impressive simulated environment will run even under 8bit machines running a virtual machine. Of course z3 machine games will have less features for parsing/obj interaction than z8 machine games, but from a 16 bit machine and up (nothing today, a DOS PC would count) will run z8 games and get pretty complex text adventures. Compare Tristam Island or the first Zork I-III to Spiritwrak, where a subway it's simulated, or Anchorhead. And you can code the games with Inform6 and Inform6lib with maybe a 286 with DOS or 386 and any text editor. Check Inform Beginner's Guide and DM4.pdf And not just DOS, Windows, Linux, BSD, Macs... even Android under Termux. And the games will run either Frotz for Termux or Lectrote, or Fabularium. Under iOS, too. Nethack/lashem weights MB's and has tons of replayability. Written in C. It will even run under a 68020 System 7 based Mac... emulated under 9front with an 720 CPU as the host. It will fly from a 486 CPU and up. Meanwhile, Cataclysm DDA uses C++ and it needs a huge chunk of RAM and a fastly CPU to compile it today. Some high end Pentium4 with 512MB of RAM will run it well enough, but you need to cross compile it. If I had the skills I would rewrite (no AI/LLM's please) CDDA:BN into Golang. The compiling times would plummet down and the CPU usage would be nearly the same. OFC the GC would shine here prunning tons of unused code and data from generated worlds.

jml7c5 7mo ago

Is this even correct? It was a two-sided disk, and each side was 174 KB.

Steve16384 7mo ago

Pretty much every 8-bit computer game of 1987 or earlier (before the 128kB machines became popular) were < 40Kb? The Spectrum and Commodore combined probably had a library in excess of 50,000 games.

forinti 7mo ago
I love how you can put all the games ever made for a given 8 bit platform on a single flash drive.

DrBazza 7mo ago

If we're talking about fitting a quart into a pint pot, it would be remiss not to mention Elite fitting into a BBC Model B, 32kb, and the excellent code archaeology of it, and variants by Mark Moxon here: https://www.bbcelite.com/ https://www.bbcelite.com/

krisgenre 7mo ago

.. and Claude Code for Linux, the CLI binary is 200+ mb :(

rigonkulous 7mo ago

A multi-level generative dungeon-crawler in 10 lines of code: https://bunsen.itch.io/the-snake-temple-by-rax 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 ..

nacozarina 7mo ago
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.

alex_john_m 7mo ago

Some comments here sound like the ones I hear from car "enthusiasts" praising old engines for being simple to run and easy to fix, then complaining about modern engines being too complicated and how we should return to the "good old days", all that without taking into account the decades of progress since then. Want to prove a point? Give me Skyrim in 64k of ram. Go ahead! I dare you!

Anamon 7mo ago
It's an interesting comparison. There's a lot of objective truth to it on both sides, though. Having a car as a project, maintaining and fixing and learning stuff yourself, is pretty much impossible with modern cars. Even before you get to the online crap, they're more services than products, with proprietary ICs and stuff that make everything "non-user-servicable". I'm not a car guy but I can understand that something major was lost. I can also see some parallels to games there, with all the encryptions, DRMs, kernel anti-cheats, online ties... it usually invites a lot less tinkering and modding than the games of old.

dspillett 7mo ago

> isometric on the C64 with such an amazing level of detail - simply gorgeous Or a convincing representation of that. A lot of old tricks mean that the games are doing less than you think that they are, and are better understood when you stop thinking “how do they do that” and “how are they convincing my brain that is what they are doing”. Look at how little RAM the original Elite ran in on a BBC Model B, with some swapping of code on disk⁰. 32KB, less the 7.75KB taken by the game's custom screen mode² and a little more reserved for other things¹. I saw breathy reviews at the time and have seen similar nostalgic reviews more recently talking about “8 whole galaxies!” when the game could easily have had far more than that and was at one point going to. They cut it down not for technical reasons but because having more didn't feel usefully more fun and might actually put people off. The galaxies were created by a clever little procedural generator so adding more would have only added a couple of bytes (to hold the seed and maybe other params for the generator) each. Another great example of not quite doing what it looks like the game is doing is the apparently live-drawn 3D view in the game Sentinel on a number of 8-bit platforms. -------- [0] There were two blocks of code that were swapped in as you entered or self a space station: one for while docked and one for while in-flight. Also the ship blueprints were not all in memory at the same time, and a different set was loaded as you jumped from one system to another. [1] the CPU call stack (technically up to a quarter K tough the game code only needed less than half of that), scratch-space on page-zero mostly used for game variables but some of which was used by things like the disk controller ROM and sound generator, etc. [2] Normal screen modes close to that consumed 10KB. Screen memory consumption on the BBC Master Enhanced version was doubled as it was tweaked to use double the bit depths (4ppb for the control panel and 2bbp for the exterior, instead of 2bbp and 1ppb respectively).

choam2426 7mo ago

We live in an age of abundant memory — until you check RAM prices.

xg15 7mo ago

The consequence of "space is cheap" / "If I didn't use that RAM, it would just sit there unused anyway" etc.

axegon_ 7mo ago

Despite being a mid-late-millennial, I can see how this played out. Even compared to the second family computer my parents got in the late 90's, which was an absolute monster at the time, I do realize how many corners and shortcuts developers had to make to get a game going in a few hundred megabytes, seeing mobile games today easily exceeding 10 times that, and not just now but even 10 years ago when I was working at a company that made mobile games. These days, developers are automatically assuming everyone has what are effectively unlimited resources by 90's standards(granted they haven't transitioned to slop-coding, which makes it substantially worse). Personally, I have a very strange but useful habit: when I find myself with some spare time at work, I spin up a very under-powered VM and start running what is in production and try to find optimizations. One of the data pipelines I have is pretty much insanity in terms of scale and running it took over 48 hours. Last time(a few weeks ago actually), I did the VM thing and started looking for optimizations and I found a few, which were completely counter-intuitive at first and everyone was like "na, that makes no sense". But now the pipeline runs in just over 10 hours. It's insane how much shortcuts you force yourself to find when you put a tight fence around you.

keepamovin 7mo ago
Yes this is a great methodology. I found developing BrowserBox (which is real time interactive streaming for remote browsers), using slow links, and a variety of different OS, really stresses parts of the system and causes improvements to be necessary that strengthen the whole.

Findecanor 7mo ago

> “The Last Ninja” was 40 kilobytes I have got 1.1 GB of MP3s with just remixes of the music from the three games, some of which are from a Kickstarter from the composer for the second.

khaledh 7mo ago

Constraints breed creativity.

andai 7mo ago

I shipped a browser game that was 8KB. Okay, plus 30 million lines of Chromium ;) Most of my games are roughly in that range though. I think my MMO was 32KB, and it had a sound effects generator and speech synth in it. (Jsfxr and SAM) I built it in a few days for a game jam. I'm not trying to brag, I'm trying to say this stuff is easy if you actually care. Just look at JS13K. Every game there is 13KB or below, and there's some real masterpieces there. (My game was just squares, but I've seen games with whole custom animation systems in them.) Once you learn how, it's pretty easy. But you'll never learn if you don't care. You have to care because there's nothing forcing you. Arguably The Last Ninja would have been a lot more than 40KB if there weren't the hardware limitations of the time. They weren't trying to make it 40KB, they were just trying to make a game. In my case, I enjoy the challenge! (Also I like it when things load instantly :) I think I'll make a PS1 game next. I was inspired by this guy who made a Minecraft clone for Playstation: https://youtu.be/aXoI3CdlNQc?is=sDNnrGbQGJt_qnV6 https://youtu.be/aXoI3CdlNQc?is=sDNnrGbQGJt_qnV6 P.S. most Flash games were only a few kilobytes, if you remove the music!

emsign 7mo ago

And it was one of the best games ever made. Back in the day equivalent to a AAA tier game of today.

tralarpa 7mo ago

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.

Pannoniae 7mo ago
>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 Probably not ;) "Enter things from a manual" was a tried old copy protection technique. If you used the warez version you presumably did not have a manual so you got stuck. This didn't run on the 8008 or whatever, I'm sure the game could have known the names of spells fairly easily.
- tralarpa 7mo ago
  Ah, that makes more sense than my theory. It's a weak copy protection method, though, as you can just try and see what happens, and I think they dropped it in M&M3.
  - Anamon 7mo ago
    Yes, and it was pretty easily photo-copied since it had to be printed all in one place anyway. That's probably why even print-based protections tried to get cleverer. Like the code wheels, although I remember those didn't take that much more effort. Disassemble the original, copy all layers, cut out the right holes, put back on a spindle. I remember one game I had that tried to protect against it by having a manual of about 100 pages, with the passcodes being spread across all of them. I believe it was Gunship 2000.

midzer 7mo ago

My website https://midzer.de/ https://midzer.de/ is themed like "The Last Ninja II" which is the first game I've encountered when I was young.

pronik 7mo ago

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.

Anamon 7mo ago
However, in the early days of the CD-ROM games, the trade-off wasn't simple. It was cheap for manufacturers to fill the entire 650 MB of the disc, but for the players, HDD storage by GB wasn't. And just keeping the stuff on the disc was often no option either because of seek times. You usually don't want to wait the half second it takes for the drive to move the laser to where the next sound effect is stored. I also fondly remember those scene re-packs! Some of them had such clever and extreme compression that it took several hours to re-inflate the game. Remember Uharc? =)

frereubu 7mo ago

So you can read replies etc. without having to be logged in to X: https://xcancel.com/exQUIZitely/status/2040777977521398151 https://xcancel.com/exQUIZitely/status/2040777977521398151

guerrilla 7mo ago

That's just incredible. People used to be so much better at programming, or at least great programmers had it easier to get funded. Most of what I see today is exceptionally low quality and just getting worse with time.

pronik 7mo ago

Speaking of the size: my first PC, built by a family friend, had a 80MB disk, split into two partitions. The second 40MB partition had Windows 3.1 and about two Norton Commander columns full of games on it, largest of which were Wolfenstein 3D and Lost Vikings with about 1.4MB each. Truly a different era.

forinti 7mo ago

I was comparing games prices last week and I found that prices from the 80s aren't too different from modern game prices. Elite was £20 in 1984 and that would be £66 today, which is not very different from what a good game for the PS5 costs today. Except that games then were made by one or two people and nowadays games are made by teams with coders, musicians, artists, etc.

matthewkayin 7mo ago
Yeah, the games industry is in a pretty big crisis right now, and I think change needs to happen both ways: Consumers need to understand that keeping games at the same price for decades despite rising costs and inflation is not realistic. If they want the industry to thrive, they need to be ok with games being more expensive. Meanwhile, developers need to stop making games so expensive. This is an entertainment industry / corpo problem, really. Companies have seen the big profits and decided that only the big profits will do, which means you need to make a big open world cinematic experience, which is expensive, and because it's expensive, they won't take risks on making anything actually interesting. The only way gaming moves forward is if we make riskier games that cost less to produce, which is why indies are the ones making the good games these days.

cineticdaffodil 7mo ago

I wonder could you make a fame that small by using svgs?

1970-01-01 7mo ago

[flagged]

y-curious 7mo ago
The LLM-use witch hunt accusations are rampant on every single article. That snippet doesn’t sound like an LLM to me. Have your coffee and consider that this person was just complimenting coders from back in the day.
- 1970-01-01 7mo ago
  [flagged]
  - zahlman 7mo ago
    The text you quoted is not an example of the trope you highlighted. It genuinely comes across like you're calling it LLM generated purely because of the "em-dash", except it isn't even an em-dash.
    - 1970-01-01 7mo ago
      And I genuinely admire the actual effort to get it right. You looked just enough to catch the error but not enough to prove it was human. Keep going, the tell is in there.
      - zahlman 7mo ago
        I genuinely have no idea what you're trying to claim. If you have a point, you should express it clearly. If you believe something to be the case, you should present evidence straightforwardly and make an explicit logical argument.

neurworlds 7mo ago

40kb and it felt like a full world... I'm burning through tokens to get AI to decide whether to go to the tavern or the market. Something went wrong somewhere

bjt12345 7mo ago

I never figured out how they did the turtle graphics in this game. The C64 didn't have whole screen bitmaps, you could either use sprites or user defined character sets, neither of which made this straightforward. And the loading screens were also amazing, particularly for tape loading.

EvanAnderson 7mo ago
You might be thinking of another system (like the NES, perhaps), because the C64 has 160x100 and 320x200 bitmap modes.
- hcs 7mo ago
  Even on NES a lot of games use CHR-RAM so arbitrary bitmaps are at least possible, though only a small part of the screen is unique without some rarely used mapper hardware. Zelda and Metroid mostly just use this to compress the graphics in ROM, Qix is a simple example with line drawing, Elite is an extreme one. I made a demo of the Mystify screensaver using the typical 8KB CHR-RAM. Even with a lot of compromises it has pretty large borders to avoid running out of unique tiles. https://youtube.com/watch?v=1_MymcLeew8 https://youtube.com/watch?v=1_MymcLeew8
  - EvanAnderson 7mo ago
    Elite is my go-to example for madness in a tile-based grapgics system. Watching the CHR-RAM in an emulator while Elite is running is mesmerizing.
steve_taylor 7mo ago
The C64 does have a couple of bitmap modes. The Last Ninja uses mode 3, which is multicolor bitmap mode. It occupies 9000 bytes including pixels (8000 bytes) and color RAM (1000 bytes).
smcameron 7mo ago
The TI99/4a version of the Logo language which has turtle graphics used user defined characters to implement them. There were only (I think) 128 user definable characters, and when the turtle graphics had redefined all of them to create its output, it gave the user a message, "out of ink".

tiku 7mo ago

A lot of trial and error. I've built graphical tools with GD in PHP, the difficult part for me what that the coordinates where inverted.. I only knew how to draw lines and pixels, but I got the job done.

oweiler 7mo ago

That game felt like a graphics demo though. Almost unplayable.

nobodyandproud 7mo ago

The music and atmosphere was gorgeous. Fond memories of wasted youth I never finished the game, sadly.

eleveriven 7mo ago

It really puts into perspective how different the constraints were

lutusp 7mo ago

> ... 40 kilobytes. How times have changed. My best-selling program "Apple Writer", for the Apple II, ran in eight kilobytes. It was written entirely in 6502 assembly language.

commandlinefan 7mo ago

Amazing what you can accomplish when you have more than "a sprint" to deliver something and no project manager asking "are you done yet?"

sonzohan 7mo ago
Recovering game dev here The publisher for this game was Activision. They absolutely had deadlines, lots of (1987) money invested in this, outsourced to a third party company in Hungary, had the outsource team fail, moved development platforms a few times, wrote a programming language and a game engine, and then became the best selling C64 game. Very much development hell.

praptak 7mo ago

I remember playing a version of this game on ZX Spectrum but I cannot find it on the internet. I remember it had bees that you had to avoid and a boat which you were able to untie so that it floats down a stream. Anybody remember this one?

drob518 7mo ago

We made the most of limited resources back then. Back in 1980, I was living large with my 64KB Apple II with dual 140KB floppy drives and a 10 inch (9 inch? I can’t quite remember) amber monochrome monitor. Most had less.

derefr 7mo ago

> I still struggle to comprehend, even in the slightest, how programmers back then did what they did - and the worlds they created with the limitations they had to work with. Highly related: two videos covering exactly how they fit... - Super Mario Bros 1 into 40KiB (https://www.youtube.com/watch?v=1ysdUajrhL8 https://www.youtube.com/watch?v=1ysdUajrhL8) - and Super Mario Bros 2 into 256KiB (https://www.youtube.com/watch?v=UdD26eFVzHQ https://www.youtube.com/watch?v=UdD26eFVzHQ) I highly advise watching the actual videos to best understand, since all the techniques used were very likely devised from a game-dev perspective, rather than by invoking any abstract CS textbook learning. But if I did want to summarize the main "tricks" used, in terms of such abstract CS concepts: 1. These old games can be understood as essentially having much of their data (level data, music data, etc) "compressed" using various highly-domain-specific streaming compressors. (I say "understood as" because, while the decompression logic literally exists in the game, there was likely no separate "compression" logic; rather, the data "file formats" were likely just designed to represent everything in this highly-space-efficient encoding. There were no "source files" using a more raw representation; both tooling and hand-edits were likely operating directly against data stored in this encoding.) 2. These streaming compressors act similar to modern multimedia codecs, in the sense that they don't compress sequences-of-structures (which would give low sequence correlation), but instead first decompose the data into distinct, de-correlated sub-streams / channels / planes (i.e. structures-of-sequences), which then "compress" much better. 3. Rather than attempting to decompose a single lossless description of the data into several sub-streams that are themselves lossless descriptions of some hyperplane through the data, a different approach is used: that of each sub-channel storing an imperative "painting" logic against a conceptual mutable canvas or buffer shared with other sub-channels. The data stream for any given sub-channel may actually be lossy (i.e. might "paint" something into the buffer that shouldn't appear in the final output), but such "slop"/"bleed" gets overwritten — either by another sub-channel's output, or by something the same sub-channel emits later on in the same "pass". The decompressor essentially "paints over" any mistakes it makes, to arrive at a final flattened canvas state that is a lossless reproduction of the intended state. 4. Decompression isn't something done in its entirety into a big in-memory buffer on asset load. (There isn't the RAM to do that!) But nor is decompression a pure streaming operation, cleanly producing sequential outputs. Instead, decompression is incremental: it operates on / writes to one narrow + moving slice of an in-memory data "window buffer" at a time. Which can somewhat be thought of as a ring buffer, because the decompressor coroutine owns whichever slice it's writing to, which is expected to not be read from while it owns it, so it can freely give that slice to its sub-channel "painters" to fill up. (Note that this is a distinct concept from how any long, larger-than-memory data [tilemaps, music] will get spooled out into VRAM/ARAM as it's being scrolled/played. That process is actually done just using boring old blits; but it consumes the same ring-buffer slices the decompressor is producing.) 5. Different sub-channels may be driven at different granularities and feed into more or fewer windowing/buffering pipeline stages before landing as active state. For example, tilemap data is decompressed into its "window buffer" one page at a time, each time the scroll position crosses a page boundary; but object data is decompressed / "scheduled" into Object Attribute Memory one column at a time (or row at a time, in SMB2, sometimes) every time the scroll position advances by a (meta)tile width. 6. Speaking of metatiles — sub-channels, rather than allowing full flexibility of "write primitive T to offset Y in the buffer", may instead only permit encodings of references to static data tables of design-time pre-composed patterns of primitives. For tilemaps, these patterns are often called "meta-tiles" or "macro-blocks". (This is one reason sub-channels are "lossy" reconstructors: if you can only encode macro-blocks, then you'll often find yourself wanting only some part of a macro-block — which means drawing it and then overdrawing the non-desired parts of it.) 7. Sub-channels may also operate as fixed-function retained-mode procedural synthesis engines, where rather than specifying specific data to write, you only specify for each timestep how the synthesis parameters should change. This is essentially how modular audio synthesis encoding works; but more interestingly, it's also true of the level data "base terrain" sub-channel, which essentially takes "ceiling" and "ground" brush parameters, and paints these in per column according to some pattern-ID parameter referencing a table of [ceiling width][floor height] combinations. (And the retained-mode part means that for as long as everything stays the same, this sub-channel compresses to nothing!) 8. Sub-channels may also contain certain encoded values that branch off into their own special logic, essentially triggering the use of paint-program-like "brushes" to paint arbitrarily within the "canvas." For example, in SMB1, a "pipe tile" is really a pipe brush invocation, that paints a pipe into the window, starting from the tile's encoded position as its top-left corner, painting right two meta-tiles, and downward however-many meta-tiles are required to extend the pipe to the current "base terrain" floor height. 9. Sub-channels may encode values ("event objects") that do not decode to any drawing operation to the target slice buffer, but which instead either immediately upon being encountered ("decompression-time event objects") or when they would be "placed" or "scheduled" if they were regular objects ("placement-time event objects"), just execute some code, usually updating some variable being used during the decompression process or at game runtime. (The thing that prevents you from scrolling the screen past the end of map data, is a screen-scroll-lock event object dropped at just the right position that it comes into effect right before the map would run out of tiles to draw. The thing that determines where a "warp-enabled pipe" will take you, is a warp-pipe-targeting event object that applies to all warp-enabled pipes will take you after it runs, until the next warp-pipe-targeting event object is encountered.) If at least some of these sub-channels are starting to sound like essentially a bytecode ISA for some kind of abstract machine — yes, exactly. Things like "event objects" and "brush invocations" can be more easily understood as opcodes (sometimes with immediates!); and the "modal variables" as the registers of these instruction streams' abstract machines. [continued...]

tombert 7mo ago

Not as small as The Last Ninja, but when I was a teenager first getting into emulation, I genuinely thought there was a mistake or my download got interrupted when I downloaded Super Mario Bros. 3, because it was only like 500kb [1], and I didn't think it was possible for a game that huge to be less than a megabyte. It is still impressive to me how much game they could squeeze out of the NES ROM chips. [1] Or something like that, I don't remember the exact number.

atlanta90210 7mo ago

The original arcade version of Pac-Man is 24 kilobytes

TitaRusell 7mo ago

Death Stranding 2 was 140 gigabyte. Ofcourse luckily our SSDs got bigger too.

lykahb 7mo ago

Many mobile J2ME games in the 2005-2015 had a similar size and were impressive too. Sometimes a time window appears and creates the economic incentives for optimization ingenuity.

msephton 7mo ago

My game YOYOZO is 39 KB and was listed as one of the "Best Games of 2023" alongside Mario & Zelda & Baldur's Gate 3. So it's still possible to do this sort of thing if you care enough and have the right constraints! If you don't have those constraints, simply impose some on yourself. https://news.ycombinator.com/item?id=38372936 https://news.ycombinator.com/item?id=38372936

kazinator 7mo ago

It's not just that programs had small images. The noteworthy thing is that they weren't small due to externalizing their dependencies. They relied on no third party code other than a few meagre services of the operating system. They did their own sound and graphics down to the pixel level. We can't compare 40 KB image today to a 40 KB image from 1980 something, if the contemporary one relies on 100 MB of external cruft, like a rich programming language runtime (fetched and install separately) and packages.

CyborgUndefined 7mo ago

how about RE2 for nintendo 64? PS1 version was 1.2GB, compressed down to 64MB. that's 19x compression. insane.

ChrisRR 7mo ago

Well I would guess that all games on the C64 were under 64KB