In communities for the Murderbot Diaries series of books, I sometimes see this game mentioned as a good fit for the feel of that universe. What I've seen in clips of playthroughs bears that out; I bought the game a while ago but haven't gotten around to actually installing it yet.
Anyway, I just wanted to shout out the Murderbot series as something that folks may be interested in if they enjoyed this game's world and are looking for something to read.
If you or anyone else is interested in playing more, I recommend:
I played a little of Silent Hill: Homecoming but got tired of it about 1/3 of the way through (I guess). I also bought Silent Hill: Downpour but gave up on that even more quickly. I don't recommend either of them. Things introduced in the earlier games for specific psychological reasons related to the plot - especially sexy monster nurses and Pyramid Head - tend to be regurgitated in the later games for no real reason other than "Silent Hill", which removes their impact completely.
I think I was kinda in the same boat as you.
In theory, I loved the fact that if you wanted to check, the game would tell you when you theoretically had enough information to identify one of the crew or passengers, so you knew where to focus your thinking. But I got stuck on some characters who seemed to me to be implied or hinted, but for whom I didn't think I had positive proof.
I eventually got tired of continuously reviewing the same scenes over and over, looking for some detail that I had overlooked, and read a walkthrough to find out what I was missing. It seems that I hadn't missed anything, and "an educated guess" was the standard expected by the game, not "definitive proof". But I was burnt out with the game by that point and stopped playing.
Despite this, I still bet that they post "nvm fixed it" an hour or two later.
The way I see it, there are two separate issues for discussion here.
The first is permanently altering a classic console. That's an issue of historical preservation, and I'm not going to get into that.
The second issue is whether or not, being prepared to go as far as having removed the original optical drive, one might not just as well drop the console entirely and go the emulation route. To me, suggesting this shows a lack of understanding about how emulation works.
A real console consists of IC semiconductors and discrete components that propagate electrical fields and shuffle the occasional electron around. A software emulator is a bag of rules and tricks that tries to replicate the overall output of a console. Even FPGA-based emulators aren't 100% perfect, because their gates and connections aren't configured identically to the original hardware.
Game consoles are very complex systems that operate via the interplay of dozens of intricate subsystems. That's why emulators start off supporting only a handful of games, and rarely reach 100% compatibility. Emulator developers are forever picking the next emulation inconsistency from the bug report list, tracking down what their emulator is doing differently to the original hardware, and then adding a new rule for dealing with that particular case. If they're lucky, a couple of other games will also start working better. If they're unlucky, a couple of other games will start working worse.
(For the interested, the author of BSNES wrote a detailed article about these issues for Ars Technica)
Take the Atari 2600. It's a very old console that was very popular. The community has full schematics not just for the mainboard, but even the CPU and custom video chip. More patient people than me have sat for hours with oscilloscopes and test ROMs to probe the console inside and out. There are emulators that can play every game that was released back in the day without fault. Heck, the emulator I use is so advanced that you can set it to emulate specific revisions of the console with specific CRT TV parameters, and it will glitch in the same way that the game would glitch on that combination of hardware in real life. But it's still not a "perfect" emulation! Homebrew developers are still finding quirks in the real 2600 hardware that the emulators don't replicate, at least until the next update.
I have a PS2 which plays my games from an internal hard drive, and which has its output fed through an HDMI converter. Why don't I just emulate it? Well, if you want to play FFX, or MGS2, or Ratchet & Clank, that'll work great. Those are popular games, and emulator developers have put a lot of effort into making sure that the rules of their emulation work for those games. But I have dozens of more obscure games that have game-breaking glitches or don't launch at all under emulation. And I also still have hundreds of discs that I don't want to paw through, and are slowly degrading until one day they'll no longer work, as well as an optical drive that gets a little closer to wearing out for good every time I use it, and a big, modern TV that hates analog inputs (not to mention no room for a bulky CRT). Getting the data into the console, and getting the final video and audio out, are both fairly well-understood and usually can be reimplemented reliably. But the heart of the console, where the data is turned into executing code, mixed with player input, and transformed into the output? That's where the actual magic happens.
In my opinion, saying that if you're going to replace an optical drive then you may as well just emulate the whole thing is a bit like saying that if you're going to talk to Angela over the phone instead of in person, then you may as well just replace her with a well-trained AI chatbot.
Why bother? Because feeding data into the console and getting audio-visual signals out of it are both very well understood and can actually be replicated with essentially total accuracy. But the complex operations and subtle interactions of CPU, VDUs, RAM, and other support chips can't. That's the important part of the console, not the optical drive or the analog video output.
Software emulators and FPGA-based systems give it a good try, and can often run the majority of software for a console at an acceptable fidelity for most users, but they're a long, long way from being 1:1 perfect, and the more recent the console, the more games either don't run properly or don't run at all.
Oh my goodness, replacing the optical drive with a modern solution isn't close to halfway to complete software emulation. It's not even 20% of the way there.
LSD: Dream Emulator must also rank up there, surely? :)
Gorogoa has been on my "pile of shame" for several years now. Perhaps today's the day.
The morality system was a huge disappointment for me. You said most of what I wanted to say, so I'll be brief.
Right near the start of the game, an NPC outlines the Way of the Open Palm vs. the Way of the Closed Fist, more or less the same way you described them. And I was so excited to see a morality system in which both sides were morally defensible positions. But from the very first Closed Fist follower you meet (just minutes later), they may as well all be monacle-wearing moustache-twirlers who punctuate every sentence with "mwah-ha-ha!"
The worst example that I remember is a bootlegger who's essentially holding a town hostage. Far from following either philosophy as described, he's just plain evil, and in fact I easily came up with (IMO solid) arguments for actually swapping the game's morality labels on the player's options. But no, one option is clearly "evil", so that's Closed Palm, while the other is obviously "good", hence Open Palm.
I bought it when it came out and played it a little. My Japanese wasn't great then (it's not all that much better now TBH) but I think I understood enough of it to give it a try.
The game itself is split between a dungeon crawler and a management sim. You go dungeon crawling to capture staff to work on games, and the combat system includes timed multiple-choice options, some of which are related to Sega and Japanese gaming trivia. Then once you leave the dungeon, you create game projects from menus, and assign your captured staff to work on them. Your ultimate goal is to claw back Sega's market share from the Dogma Corporation (standard sentai villains and thinly-veiled Sony stand-ins).
There are tons of Sega and Japanese gaming culture references of course, but a lot of these are either just "Hey, remember this?" (and as a non-Japanese gamer, you might not), or in-jokes that can't really be translated. For example, if you're familiar with the "All your base" meme, imagine trying to translate that into Japanese; it's just not going to work because its enjoyment largely hinges on having "lived through it", and the idea itself resists translation anyway.
I didn't get very far due to a combination of language barrier, lack of trivia knowledge, and the unfortunate fact that after the intro section I just didn't find it all that amusing. I live in Japan now and as far as I can tell, these days people still occasionally talk about it fondly but it's not really considered to be a cult classic here.
According to the author, the giveaway is in support of World Suicide Prevention Day. Also, at least for me, it looks like it actually runs until the 12th, even though the author just said the 10th.
I hadn't heard of Kate before, so I can't offer much hands-on advice. I dug around and found a "handbook" here: https://docs.kde.org/stable5/en/kate/kate/index.html
Unfortunately it does look like you need to define a project to compile/run anything, which appears to require manually creating a
.kateprojectfile in the directory as outlined here: https://docs.kde.org/stable5/en/kate/kate/kate-application-plugin-projects.html#project-createI had exactly the same problem when I moved from languages that were interpreted or combined the IDE and runtime environment into one, and starting to use languages which had their own external compiler. Unfortunately, open source project user documentation is often terrible for beginners (what I found above for Kate seems to be no exception), and IDEs often seem to be written by people who don't really expect anyone to actually use the included build options (to be fair, most folks seem to like using their own separate build utilities, so probably this is often the case)
If you can tell us which compiler or interpreter you're using (e.g. gcc, clang, Python), someone can probably tell you how to compile and/or run a single-file program from the terminal with a fairly simple command.