Well, I agree with you to a degree. The cliffhanger ending is pretty disappointing, and any given playthrough shouldn't take more than a few hours. But replayability is high thanks to the branching scenarios, and I liked the fact that there is usually no middle ground for your choices, meaning that you are forced to take sides and you will piss people off whether you like it or not. Kind of reminds me of a Telltale title in that regard.
So, all in all it's not the best game ever, but I've seen much worse.

You should sue the developers for making you an alcoholic!!!
...is what I might say if Looking Glass still existed. :P

Pretty sure that was all my fault. :P

Hmmm... Seeing it in the forefront makes me want to play it now and give it a try (since i already have it).

Weird.. owning a game for 2 years and never touching it... i almost feel like an abusive [s]father[/s] parent...

The correct term is 'parent' :p
Get with the times!!
Silly aside... I would say it's on the storefront for the Kickstarter as mentioned above. Probably to get some exposure, and pocket change.

I would consider this a dealbreaker, because sometimes I only feel like playing 15-20 minutes *total*.

Especially with modern OSes caching data into RAM and modern hard drives being far faster than floppy disks and CD-ROMs, there is really no excuse for noticeable load times these days, especially if it isn't the first time the game has been started since power on.

Yeah! Why doesn't anyone tell me this shit?

Agreed. Honestly i tend to copy the game into RAM, assuming the game is 3Gb or less; Which is to some degree less than efficient since the OS will likely cache chunks of the ramdrive along with using the ramdrive. But the runtime/loadtime seems to be much better when i do that, assuming the save doesn't go to the ramdrive too (and forget to copy it back, which would be a total pain!).

You need better friends. Foxworks pointed it out to me as the game is on my wishlist, otherwise I would have missed it too.

On Linux, tmpfs, which can be used as a ramdisk for almost all purposes, is basically a filesystem cache that never gets flushed to disk (but can be swapped out). Therefore, there is no double caching.

On the other hand, Linux's filesystem cache is so good that I find that tmpfs is really only useful when you don't need the data to be written to disk in the first place. (For example, on Gentoo systems it's a common trick to put portage's working directory (/var/tmp/portage) on tmpfs, which speeds up compiling as long as you have enough RAM.)

Hmmm i wonder if tmpfs plays nice with zram, i would think it should... With zram you could get double your ram's worth with very little performance hit.

The major difference i think between tmpfs and traditional ramdrives is tmpfs is dynamically allocating, where a ramdrive you format a block of memory and treat as a traditional harddrive.. Ahh how to love the openness of the API and programming in a way windows systems will probably never have...

Of course, you could create a big file on tmpfs and use the loop device to put a filesystem on it. This can actually be a good way to test filesystem code, or to use features of a filesystem that tmpfs doesn't have.

zram works best with compressible data. Many (most?) games store their assets as compressed files, so storing them in zram would not provide an improvement.

Of note, there is no way to compress arbitrary data. If there were, a single bit would have to be compressed down to zero size, and there is only one unique zero size file. How can you determine which of the two 1-bit files it should decompress into?

I was mostly referring to while you're compiling or working with probably temporary files, since source code and most stages of are generally compressible. I understand most games save their contents compressed, although i notice most of them aren't as well compressed as they could be; and you could optimize the images used to get 10% extra it seems usually.

Although for packaging during transfer over the internet there are some cases where uncompressed would be better since LZMA does a much better job, but extracting them they should be given compression during the output. Experiments have shown a 5:1 extra compression this way, ToME is a good example... as are adult Japanese dating games (heavy duplication between images noted outside file boundaries, or are larger than 64k so zlib wouldn't catch it); Although having ToME run totally on uncompressed PNG's has quite a performance hit since it expects to decompress the files and when it doesn't it probably has a lot of extra memory allocation it ends up wasting.

It also has a performance hit if the zip's ToME uses are compressed rather than stored, so double performance hit if PNGs are compressed inside the zip file.

For 1 bit, you can't (obviously). But for a larger sample, say a million bits, you could reduce almost any data down (a least a little), but assuming you could it would probably take quite a performance hit, be it from LZMA, PPMD, or something else, while ZLIB/LZOP have very little in comparison, and are better suited for faster random access.

Lots of interesting discussion, but it seems we will never know why it is on sale.