Hetare King

Early Persona 5 is pretty rich in set pieces as it slowly introduces its many systems, but it does open up quite a lot after a while. It’s a content-rich 100+ hour long game, it kind of has to. It still has a lot of cutscenes even after that, but they’re mostly of the gamey yapping portraits kind, with cinematic cutscenes and anime FMVs left for climactic moments.

Persona 3 and 4 are similar in style, though not quite as cinematic, and you get to the meat of the games faster.

Persona 1 and 2 are completely different beasts, and what you dislike about Persona 5 so far will have no bearing on whether you’ll like those. The most modern versions are on PSP, however.

As for other JRPGs on Switch, from the same developer there’s Shin Megami Tensei V and the remaster of III. Even though they’re also from Atlus, they very much go in the opposite direction of Persona and are very stoic games where it’s mostly just you, the environment and the systems, and cutscenes are far and between.

Someone else mentioned the Trails games and I’ll second that. Like the Persona, they’re very story-rich, but not as budget-rich as Persona 5, which puts constraints on how that story is told. Also, if you like action RPGs, from the same developer (Falcom) there’s the Ys games. Ys: The Oath in Felghana is pretty much the pinnacle of the genre and is pretty short, so it’s a good snack between bigger games.

I have no dog in this race as far as Claude is concerned, but this is pushing a false dichotomy. Not using, say, WinForms or something, because it’s too limiting or because you don’t want to make a unique UI for every platform, doesn’t have to mean strapping an entire web browser to your frontend, there are plenty of other options.

The reason frameworks like Electron are popular is that we’ve spent a long time hammering a square peg into a round hole and there are now a whole bunch of tools for designing on top of web technologies and a lot of designers with experience with those tools. And of course, the fact that code can be reused between the web app and the desktop app helps too. But it does have a performance cost. The fact that you can have poorly performing and bloated native UIs too doesn’t change that no matter how well-optimised your HTML+CSS+JS is, you can create something of the same complexity that is faster and leaner using native widgets. And when people opt for the desktop app instead of web app, they typically want something that performs better than the web app.

I’m not sure that analogy works. The machines used for making clothes are reliable and produce repeatable results that are good enough. I recently had to throw away a 15 year old T-shirt because it was getting a bit too ratty, but it still technically functioned as a T-shirt. Also, mass produced clothing in standardised sizes didn’t actually replace the bulk of tailor-mode clothing, that was always something for the rich, but that’s getting too deep into it.

In comparison, LLM-based code generators are inherently unreliable and by their very nature incapable of ever becoming able of producing good enough results, at least with the current dominant paradigm. Many execs may not feel that way, but that’s very much a FAFO situation, because unlike clothing, where poor quality may cause it to degrade faster, but that still takes time, the effects of degradation of quality in software are immediate. Of course, it’s very difficult to dislodge a dominant software product from its place in the market, because people are willing to tolerate a lot of quality degradation if the cost of switching to something else is high, but there is an upper limit of what people are willing to take, while there is no limit to how bad their software can get if companies keep riding the LLM bandwagon.

I’ll say this much: people don’t have to work for a big, publicly traded corporation. There are still smaller software houses out there where the executives aren’t little more than the shareholders’ fluffer and trust devs to know how to do their jobs, though you may need to look outside of mainstream applications. Whether they have the collective capacity to absorb everyone who wants to be a professional programmer, I don’t know. But in a world of slop, being able to provide even somewhat reliable software may be a gap in the market that could be exploited and allow for that capacity to grow.

I don’t, and probably never will. A whole bunch of reasons:

• The current state of affairs isn’t going to last forever; at some point the fact that nobody’s making money with this is going to catch up, a lot of companies providing these services are going to disappear and what remains will become prohibitively expensive, so it’s foolish to risk becoming dependent on them.
• If I had to explain things in natural language all the time, I would become useless for the day before lunch. I’m a programmer, not a consultant.
• I think even the IntelliSense in recent versions of Visual Studio is sometimes too smart for its own good, making careless mistakes more likely. AI would turn that up to 11.
• I have little confidence that people, including myself, would actually review the generated code as thoroughly as they should.
• Maintaining other people’s code takes a lot more effort than code you wrote yourself. It’s inevitable that you end up having to maintain something someone else wrote, but why would you want all the code you maintain to be that?
• The use-cases that people generally agree upon AI is good at, like boilerplate and setting up projects, are all things that can be done quickly without relying on an inherently unreliable system.
• Programming is entirely too fun to leave to computers. To begin with, most of your time isn’t even spent on writing code, I don’t really get the psychology of denying yourself the catharsis of writing the code yourself after coming up with a solution.

The standard type aliases like uint64_t weren’t in the C standard library until C99 and in C++ until C++11, so there are plenty of older code bases that would have had to define their own.

The use of #define to make type aliases never made sense to me. The earliest versions of C didn’t have typedef, I guess, but that’s like, the 1970s. Anyway, you wouldn’t do it that way in modern C/C++.

If you’re directly interacting with any sort of binary protocol, i.e. file formats, network protocols etc., you definitely want your variable types to be unambiguous. For future-proofing, yes, but also because because I don’t want to go confirm whether I remember correctly that long is the same size as int.

There’s also clarity of meaning; unsigned long long is a noisy monstrosity, uint64_t conveys what it is much more cleanly. char is great if it’s representing text characters, but if you have a byte array of binary data, using a type alias helps convey that.

And then there are type aliases that are useful because they have different sizes on different platforms like size_t.

I’d say that generally speaking, if it’s not an int or a char, that probably means the exact size of the type is important, in which case it makes sense to convey that using a type alias. It conveys your intentions more clearly and tersely (in a good way), it makes your code more robust when compiled for different platforms, and it’s not actually more work; that extra #include <cstdint> you may need to add pays for itself pretty quickly.

According to the website, it does not. But it also doesn’t support GPU passthrough yet, so it’s not yet really an option for most games anyway.