If only I had the time. I do my best when initially writing the games to try to check for typos and other mistakes, but part of the problem is that RPGMaker's dialog text input doesn't let you see the whole chunk of text at a glance, you have to scroll (sometimes quite a bit), so it's easy for things like this to slip in. Normally players find the small things I miss pretty quickly on release though: that's why I was surprised this one had survived for so long.

RPG engines typically build maps out of "tiles", individual squares that can be terrain, floors, walls, clutter etc. These tiles are pulled from "tile sheets", large image files with a bunch of tiles laid out in a grid. In RPGMaker MV, you also define a number of properties for each tile in programming: how "high" the tile is (below player, same as, above). If the tile is set to "same as", you get a "collision" when attempting to walk through it: the engine won't let you. Thus, things like floors are usually set to "below", and things like walls and tables to "same as". This becomes complicated in MV however, because you can layer several tiles on top of each other, and the last to be laid down dictates the "height". This can break things:

1. You define a wall tile, and set it to "same as"

2. You define a semi-transparent crack tile, and set it to "beneath", because you want to use it on the floor and have the player walk over it.

3. Later, you forget about this and put the crack on a wall. Now, the player can walk over/through the wall, because the crack's height properties override the wall's. 

This is just one example. The point is there are a lot of sneaky edge cases in MV where something like this can happen. I've become much better at anticipating and correcting them, but like I said, this was my first attempt at an MV game.

1. Again, grammatically, it's a valid English sentence. The comma in this case is a judgement call/down to taste, and in this case I'm fine with things as they are.

2. Again, while the presentation of the sprites during battles may be a little rough in some ways in CS, a. I'm fine with that to a degree b. I don't see this particular positioning as an issue. It doesn't go fully off-screen, and it doesn't stay in its displaced position permanently. The movement helps convey that something is happening and gives it impact in the absence of actual animation frames.

In general, while I do still welcome feedback on CS and all my games, keep in mind that there is such a thing as "good enough" when it comes to creative and commercial works. Game-breaking bugs I will obviously fix (though there shouldn't be much of that left in CS at this point). Minor, obvious mistakes or oversights that are trivial to fix (like collision errors), I'm also happy to fix. But given the age of the game, I'm less likely to go into the weeds on details like the specifics of combat mechanics. Discussions can still happen, but they're going to be used more for consideration of what to do or not do going forward. Every bit of energy and time I put into revising old games is time I can't put into building new ones: this isn't to say I won't revise the old ones at ALL, but the fixes in question have to be low effort and at least reasonable reward (as fixing typos and small collisions are). 

3.  "If it is really important and / or necessary to know what statistics give different effects, then you need to make sure that the player finds out about it, add tutorials for decency, which talked about the control in the game, equipment, and so on-"

This has been discussed at length by me and other players since the game came out. Tutorialization and teaching the player are not simple things with one standard solution when it comes to games. The correct implementation depends on the nature and personality of the game, the audience it's made for, and so on. These games are largely inspired by a crop of Japanese adult RPG titles from the mid to late 2010s. A large part of the experience of playing those, as someone with only limited Japanese knowledge, was having to figure out items and mechanics by experience rather than explicit description. On the one hand, this has guided my design philosophy for the games towards trying to make them as self-evident for BASIC gameplay as possible: the games I enjoyed usually didn't need any translation to figure out what was going on or how to do what was needed, just for the story. In general, I think a well-designed game mechanic, at least a simple one, doesn't need explanation: it explains itself through basic experimentation by the player. The only "tutorial" needed is giving correct space and circumstances for this experimentation to happen.

On the other hand, I actually enjoy the mystery of having mechanics or items that do not immediately announce how they work. Subtle mechanics are better mechanics, because they allow a player space to figure things out on their own, and when they DO, it's more satisfying and enjoyable. Constantly explaining everything is like being a hovering parent that never leaves your child alone for more that five minutes. Children, and players, need space to explore on their own.

Of course the caveat to this is that I, as the game designer, have to actually make the mechanics discoverable. Being GIVEN the answer to a problem is no fun. Being given a problem that's too hard is ALSO no fun, and obviously this balance can be tricky, and is inherently somewhat subjective and varies by person. But I do my best to guess, and once each game is out, I gauge the quality of the balance from how many people complain about a given thing, or struggle with it. If a lot, I fucked up. If a few, and and they're able to get it with a small hint, it's fine. If zero, perfect. 

All of this to say, tutorialization is part of game balance, and game balance is a complicated thing, and one I DO put some effort and consideration into. The skill descriptions are an example of a compromise: they don't hit you over the head with how something works, but they're there if you REALLY want to know and dig a little. I should also say: Another reason I avoid overly explaining things, aside from the fun of mystery and the satisfaction of working it out yourself, is that explicit explanations tend to be immersion-breaking: they remind you that you're playing a game, and spoil the fun. They do appear OCCASIONALLY in GT, and will in 3, but I do everything I can to avoid them, and when I can't, to make them as unobtrusive as possible. I would NEVER put something like your screenshots in the game. Certain people in the modern day suffer from a disease of being not just kind, but overly nice, and this manifests in game design as this pathology of having to over-explain everything out of TERROR that a player might be confused for even a moment. Again, it's the smothering parent thing. Players NEED to be allowed to be a little confused. Players need to be given space to work things out on their own. Players need game designers to have SOME faith in them, some faith that they have a functional pre-frontal cortex and basic problem solving skills. Because that's what a game IS: a challenge. A set of problems that you have to figure out solutions to. If the game just gives you the answers, it's no fun, AND it's patronizing and insulting to your intelligence. 

So for this reason, I'm not going to tell my players how controls in an RPG work, for example. RPGMaker MV controls are standard across all the games made with it, and they're fairly intuitive. There are even TWO SETS of keyboard controls that are active at the same time, one for western audiences and one (which I prefer) for the Japanese crowd. I explain things when a. They're not standard or immediately obvious and/or b. When they might be overly time-consuming or frustrating to figure out, rather than a fun challenge. Again, this obviously varies based on intended audience. But the audience *I* am targeting knows how basic video game controls work.  

Again though, this is balanced by the reality check of overall feedback. If I put out a new game and get flooded by people saying they're one-shotted by a particular mechanic or have no idea what to do here or there, obviously something needs to be tweaked. But EVEN THEN, my first instinct is "oh, the mechanic is too hard to figure out, it must be badly designed. Let's make it more intuitive, lets drop a few more hints etc." It's NOT to simply explain things point-blank. That's always the last option, because it's the least fun one.

4. "Why is it that enemies can only have a sprite in one image, while characters SHOULD have an animation in three frames? Isn't it possible to do the same as with enemies?"

Nope, in the default engine, enemies are not animated, they get one picture. Just the way it was designed. Games like mine do all kinds of things to add more dynamic stuff back into the battles, but that's the default design. I can't recall the details on that Diezel sprite: I know one eye direction was needed for some reason, but I don't know if I just tweaked it to be looking a different way and left the old one, or if I use both in different versions of the battle. Regardless, it's not for an animation, and can't be swapped mid-battle like the player: all you can do with enemies is hide them, which is what happens in some of the games for some of the battle sex graphics.

And finally, as for Mezz's tail: hey, my art skills are what they are. That's what it comes down to. They have gradually improved as the games have gone on, but I am not the world's greatest artist. It's good enough to get the idea across.