Dark Wizard's Tower

My thought was after a while it would get annoying as you will probably die a lot.
Depending on how difficult you make the game of course.

Having different characters that do things differently is a good way to add variety, however this character would still suffer due to their movement speed. Consider if the player goes off in one direction to check if there is any loot, interesting things, etc, and they discover an empty corner of the room. At that point they have to wait just to return to the basic interaction of exploring. If that was just a one-off it wouldn't be so bad, but this game seems to be oriented around the common action of walking, and if a player feels the urge to backtrack because they feel they may have missed a side-room, then it will become tedious very fast.

One way to get around this would be to allow them to move faster, but with a matching penalty or risk factor. Perhaps something like being able to put your shield on your back, allowing you to enter a 'jogging' mode, but leaving you vulnerable if you get ambushed, and returning your shield to your hand taking a moment? If the increase of speed would break the meta of your combat mechanics, then you could simply make it so that sprinting is disallowed in combat (when something is aggro'ed), or that there is a stamina meter that attacking / blocking / etc uses a little of, and sprinting depletes it rapidly.

Game design is tough, especially as how once you're focused on the creation aspect, it's easy to lose sight of how the game presents itself from a purely gameplay perspective. It can be hard to blend those views together. When I managed to teach myself some GMscript and realised that I could in fact slowly make a game, I ended up choking myself out on the sheer depth of design considerations. Figuring out what is truly fun, what is tolerable, and what will get old, while also trying to stack the mechanics together so that it feels like a complete framework worth building towards AND that allows for interesting content that doesn't become samey after a little while? Yeah, that's rough.

You have a framework here and that's great, but don't be afraid to iterate! Finding the magic balance of gameplay elements is a real moving target, and things as small as movespeed / jump arcs / floor grip / motion-weight vs responsiveness / etc can be a real mess to tweak into place.

I suppose it's also worth noting, despite my spammish text here, that trying to make your first game something truly unique and amazing is also a losing battle. Practice, experience, and experimentation are needed. Sometimes the important part is getting the code in and finishing the thing, before you try to really buik up that skeleton with a little meat. The first ventures will often suck to varying degrees, and becoming disillusioned because your first passes aren't your personal masterwork is a surefire way to burn yourself out prematurely.
(like I did, haha)

Good luck, young dev. Its a long path, but if you can keep sight of what makes it fun for YOU as the creator, eventually you'll figure out how to also make it fun for the player too ;D

Interesting. I'm asking because I was curious about your prioritization of features. Wall/obstacle transparency is more of a 'QOL' feature and should be middle to late priority. The game can be finished with it never being implemented but it'll feel a bit different (for example, keeping the opacity and removing the map entirely is a valid solution, albeit it probably becomes a different genre, and so is simply coding monsters and traps to avoid/never spawn near doors). Character speed and animation variety is more an early to middle priority as it directly impacts player enjoyment and directly alters the flow of the game.

Divided into early, middle, and late priorities, I'd say:

*Early priorities include: animations (many actions lack weight or lead ups, including certain attack animations, which is really really bad for this sort of game), incentives and the positive player feedback loop (you are able to make a break for the stairs, and dying was much more likely to happen when clearing out a room so why should I or anyone clear out a room then?), pacing and flow (you're better off deciding as early as possible whether you want this game to be fast tempo or slow tempo because it's pretty slow rn)

*Middle priorities should be for when you have a decent groundwork to work with and are now adding/removing features to differentiate your game from the pack and give it flavor. These can include: important QOL issues, art direction, sound direction, plot, etc.

*Late priorities should be polish at this point. Still too early to add anything, aside from the basic QOL things

So far, you have a decent basic framework for a game. A bit slow-paced for my taste but completely workable if the combat is designed for such a pace. Also, for some reason I find how the pillars zip by as the camera pans over the room pretty charming, which might be why I'm against wall/door transparency. I surprisingly have no gripes about the camera work. Usually the cameras for these sorts of games are more finnicky.

Here's one suggestion based on another guy's criticism: instead of putting the spotlight on the player's corpse (the player of course knows they're dead, no need to clarify it), maybe put the spotlight on the monster that killed you instead? In more hectic situations it can be very good information for the player to know (especially if they were dogpiled or if it was a trap) and it fits with the current death message. It'd very well be new information the player can act on as well, assuming it's workable.