-Tile-based: as others have said, reusable art is always a plus for the developer. But, you also have to handle collisions for every entity that interacts with others and the environment. If you're developing your own framework/engine (been there for a while), you have to deal with this efficiently, especially if there's going to be numerous of them simultaneously.

-1st person grid-based: multiple times more work is required for the art. But, you are also restricting movement to predefined nodes, so no collision handling. For each of your entities, only their surrounding nodes should be checked to react to other entities or the environment.

So it boils down to: code heavy in entity/environment collision/reaction vs code heavy in handling artwork/animation.

(I'm deliberately leaving out details like game logic, audio, shading, timing, input, etc. as these will need much work one way or another)

Eeeeeeeh. There's what, only one version with an automap, right?

For the tile-based game, I think I would limit movement to tiles; the only time an entity won't be on a tile will be in the middle of the movement animation, and I might not even have a movement animation, at least not at first.

(The battle system would likely be non-tactical turn based, so there's no notion of positioning, and hence no collision issues there.)

You *can* learn how to navigate the dungeons without a map. I've reached the point where I don't need to refer to a map in Bard's Tale 1. (Do note that Kylearan's Tower is particularly nasty done this way; Phantasy Star doesn't even have anything even close to that.)

I recently played through a little game called Magic and Metal Zero, and that has a floor with no auto-map or compass, along with many teleporters and spinners, and I was able to navigate that floor.

(Also, I believe there exist 2 versions with an automap, a remake for the PS2 (JP-only, and changes the mechanics) and a version on the Switch.)

Ah, I see. In that case, it is up to your art skills then I guess.

A few sidenotes...

-I am not a RPG fan at all (sorry!) but in adventure games I prefer 1st person (Myst style) over 3rd person (Monkey Island style). It is more immersive. Tecnically, it is also a nice "cheat" for developers to avoid having to design multiple animations for each state of the main character (because, well, the character is never displayed).

-If you go with 1st person please try to avoid making the characters 2D billboards with pixelized graphics. Whenever I show such art to younger friends or relatives, their expressions are priceless :) (in case you're looking for a modern audience)

-If you go with 3rd person, and if your budget allows it of course, invest in a solid 2D sprite & animation software. It will make your life much easier.

I doubt a modern mainstream audience would be interested in an RPG without story that aims to mimic the old classics anyway. Knowing a little about dtgreene'spreference, I think it would be pretty niche. ;)

Nothing wrong with creating the game you would love to play yourself, in order to learn coding. She didn't even say she was aiming to share or even sell it, but there's *some* dedicated audience for almost everything and there are also enough other games for people who don't like it to just ignore it.

What's wrong with games being niche?

Especially since including a story requires extra work, and that's not really the part of the game I'm interested in, at least at the moment.

What I'm interested in is the gameplay mechanics, and in particular the growth system, which ain't going to be what most RPG players are used to.

What about a First Person Action RPG like The Elder Scrolls II: Daggerfall, where we had randomly generated dungeons and quests? Main quest dungeons (which were handmade) were better of course, but it's a cool idea if implemented well.

Wouldn't this be considered easier than making tiles manually in a 2D environment? I mean, you could make a table of 3D rooms and code in randomly generated maps, etc.

Warframe did this in a way, but since tiles are so big, normally there are no differences between each randomly generated map.

Action would make it not an RPG in my book.

In particular, I do not want this game to be any sort of action game, at all. I sometimes enjoy playing them, but that's not what I'm interested in making.

Also, Daggerfall isn't a good example for an indie game to follow. The game shipped with many bugs, many of which were never fixed, because they tried to maybe do too much, and for a smaller development team, the result would be a game that never gets to releasable state. Not a good idea.

My game, if it gets made, will not be anything like Daggerfall, and will not have anywhere near the same scope.

Edit: Worth noting that it's still worth it for a prospective game designer to play Daggerfall, but one shouldn't follow its example too closely.

See my post directly above yours. Short answer: Nothing's wrong with it.

Depends on your programming skills, I believe depending on what software you use it to program it with, either could be easier.

Eg. how so many people use RPGMaker to do those classic 16+ bit JRPGS, and then you've got people who as a one-man team (or a small team) do a first-person dungeon crawler (Paper Sorcerer, The Quest etc).

Ah I see. GL then.

If not doing detailed transitions, 2. Esp. since there's usually no "combat zoom".

My vote is for tile-based. I tinkered with making a first-person dungeon crawler using JavaFX when I was teaching myself Java. It was more an exercise for myself to see if I could take the Java I knew and make something from my own brain instead of a tutorial. Thus it might not be the "correct" way to do these sort of things but it did function. I got the movement setup so you could move forward, back, sidestep left, sidestep right, and rotate left or right. Loaded images using hashmaps and filepaths with flavor text in a textfile(I forget that part).While not exactly complicated the point here is tile based movement will be way easier especially if you use any of the tools others have suggested. Loading assets is probably easier for tile based as well, since first-person might require you to have images for 4 sides(assuming you aren't rendering objects). There are things with tile based that could be more complex of course but I think you'll have an easier time of it.

Last advice, use an engine if you don't know a programming language well or this is your first attempt at a project like this. They exist for good reason and writing a lot of boilerplate you don't fully understand probably isn't going to excite you. You want to make the "game" portion of the game and design that, so use an engine to do that part more easily and more quickly. If you want to pop the hood and rewrite code at a later point you can.