Not game but goodie: if I'm not mistaken ROTT (2013) has a 7GB single file editor

I love it when a developer gets a really good game down to a tiny size. I remember playing some games on the C64 that blew my mind. Might and Magic 2 was on 8 disks, I think. And I had some game disks with maybe 10 games on one disk, all great and fun. And a bunch of those were few KB or less.

I played what would be considered a Rogue-like. I poured through the code trying to figure out how they got the game so small. It must have been under a KB or so. It use a few lines of code to show all the different wall types, it mimicked some keyboard characters but changed their graphic. And then it randomized some dungeons and displayed them. It was a fascinating code to read b/c they put together a great game with almost nothing.

DarkBASIC used to (and maybe still do?) have a 20-lines-of-code competition. And you had to make a full game with 20 lines of code. Of course, with DarkBASIC, DirectX calls are significantly shortened and simplified, so 20 lines in DB could be a thousand in C++, but nonetheless, some amatuers made some great games with 20 lines of code.

i always thought they said size doesnt matter btw.

So we are obligated to mention .kkrieger , and I think IOCCC should also be mentioned, though they do allow a bit larger code lengths (4KB as I recall).

Nope, the Mac versions of big games just come in one big fat *.dmg file. For instance, The Witcher's is 9.1 GB.

The smallest modern game I've bought that is an entirely self-contained executable is Inescapable. It's 2MB, and contains so much content for its size that it reminds me of those hypercompressed 64K tech demos that folks make.

The TI-99/4A Extended BASIC community (yes, there is such a thing) has a competition where you write a 30 line game, with an option extra 10 lines for DATA statements that define the graphics. I wrote an entire RPG - including random level generation, character advancement, multiple enemy types, and a quest - for that one. :)

To be fair, .kkrieger requires DirectX 9, I believe (or at least one of the later DX8 versions). The compression techniques demonstrated by .kkrieger are still amazing but one should keep in mind that a lot of the eye candy you see in the game comes directly from the DirectX libraries, rather than being part of the game's code.

It doesn't really change the fact that it's a good-looking game squeezed into 96KB (especially back when it was released the visuals were just breathtaking) but when I first wanted to try it I suddenly had to get an updated DirectX version which meant another 30+ MB I had to download. Also it didn't run on one of the PCs I wanted to try it on because I didn't have enough RAM. :S

Really? That's insane, especially considering that you have to download the entire file if it gets corrupted and you can't have files that large on a typical DVD or FAT32 filesystem. Granted OSX doesn't use FAT32, but a lot of storage devices are formatted like that.

I don't disagree. It's inconvenient to have to download a single large file (without a download manager that can pause and resume the download at least) and you can't store it on a FAT32 file system.

Afraid I don't know enough about what is available on Macs though, to allow for a multi-part installer that the average user can run easily without having to get into the terminal / command-line. Maybe that is awkward on Macs?

I really ought to know - allegedly I am a certified Mac desktop support technician! But such things were not part of the course - I only did it in the last year, and Apple were already starting to push towards everything being downloaded from the App Store...

I'd suggest taking a look at GOG games with DLCs that work on Mac, since the DLCs are extra files. You could (in theory) do the same with regular games, requiring the data from parts 2 to # to be added to part 1, but you'd still end up with one huge file on your computer.

It is awkward. Unlike Windows, where every file is executable simply depending on the filename (the last dot and letters/digits thereafter, specifically), neither NextStep (which formed the basis of Mac OS X) nor Unix-likes (a group of which OS X is part) behave in the same way (neither did the original System/Mac OS, but that's a fourth way not relevant now). Actually, NextStep behaves similarly (to be expanded upon), but still too different to be useful in the case of transerred files.

Inherited from Unix-likes: A file is not executable by having a specific filename, but by the user having permission to run the file as executable, this metadata is not part of the file itself, and as such is not transferred over the network but has to be set locally.

Inherited from NextStep: What the user sees as an "application" is usually (I have seen exceptions, but do not know if this is still possible) not a single file as in Windows (where it's indicated by the filename extension ".exe"), instead it's a folder with a host of files. The folder has the extension ".app", which prompts the OS to treat it specially (other similar cases exist, ".pkg" is one, usually used for installers), making it slightly more difficult to enter the folder to get at the files within (unless you're using the terminal, which is part of the underlying Unix, not the NextStep-based graphical interface).

Do note that in both these cases (".app" and ".pkg") I'm talking about folders, not files named such - and as we (most of us, at least) know, folders are not transferable over the net, only files with content (actually, just the contents, and optionally other data which doesn't have to be honored such as timestamp and suggested filename, not the actual file). While there (obviously) are ways to build multipart installers for OS X, the actuall installer itself cannot be transported as-is, because it is an application (a folder, named .app or .pkg), it needs to be merged into a single file somehow - a zip file works, but the most common way by far is a disk image, specifically the .dmg format (.iso works just as well, actually). This file would need to be extracted before installation can begin and the user would have to put the installer "executable" and all the installer data files in the same folder (so they can find each other) or use several disk images and handle it as a multi-disc installer - both these are likely (sadly, in my opinion) more advanced file managing tasks than most users are willing to handle, they want to just double-click a single file (ie, not 10 of them to do one thing) and have the expected result happen, or be given a guide on what to do next.

Instead, GOG don't actually use installers on OS X, but a single disk image (large files can be split up and merged, but that'd require third-party software the user is unlikely to have, and - again - introduces advanced file managing) which opens on a simple double-click, with the whole application (game) in a single .app folder inside, to be dragged-and-dropped to the Applications folder (or elswhere, but that's where most users learn to put their applications).
In theory, yes, but that would require opening all the disc images (as if you had half a dozen or more optical disc readers) and run the installer (because simple drag-dropping the game .app isn't an option when split over several files, you need an installer) from the correct one when all are mounted. Quite common practice back when floppy discs were still used, especially for pirated software (though Stuffit ".sit" archives were more common for legal use, I'm quite sure - just about everyone had Stuffit (the WinZip of the Macintosh at the time), but far from everyone had a disc imaging application). Floppy disc images then were as the iso's and dmg's of today.