Hello there! Jaide, I'm not the progammer kind neither. But I have a long time experience with both videogames and tabletop rpgs. I can also gladly lend you my voice for a character if needed. So far, my main metod of contributing is playtesting, since you said the plot is already made. I really hope to see more people engaged with this project, we need more rpg titles in the audiogames comunity.
Best regards, Haramir.

I would also like to play test the game. Although I know Python, I'm not sure how how to code everything you would need for your game.

Coding nightmare? Maybe, depends whose programming.  Most spells and skills are just restrings and changing numbers in a data file, so it depends how good the coder is at pushing complexity out of the code and into the data (in some sense, there's not a word for it and I'm trying not to go way off topic).  In all honesty, I haven't seen too much of that sort of thing in this community.
The problem I see here is that the number of abilities and combinations in question is going to call for an above average to incredibly large set of art resources, and a huge amount of content creation.  I normally say that getting resources is a small part of the project, but you appear to be setting yourself up to prove me very wrong.  Very.  The amount of content you are setting up for means you can probably drop some of it without too much loss, and you can always add more later or even make a second game with the same engine.
As for mechanics, don't force level for anything.  If you feel like you need to force the level, maybe consider the mechanics again.  If I am a skilled player, I should be allowed and able to advance indefinitely; people even find this fun.  If the thing in question here is "either I force the level or the character isn't strong enough", it sounds to me like the combat system relies way too much on random numbers and stats and way too little on me actually figuring out how to do awesome things.  There are a number of directions you can go in to fix it: add elements of timing to  provide bonuses, add elements of planning like elemental affinities that change with casting spells, add elements of working together where if you can set it up so that 2 or 3 characters all do one thing within a turn of each other then something special happens.  Some sighted games with turn based combat put everyone on a small grid, devoting half exclusively to you and half exclusively to the enemy; these games then add range and delay to attacks and allow characters to move during their turns.  There are enough mechanics you can add that you should be able to remove the so-called level gates and/or make it such that the gates are more of a flimsy cardboard wall for a hyper competent player (with most players falling somewhere between).  But if you're just going to force the level, remove grinding all together and make it based off quest completion or something instead.

be warned that you are probably underestimating the level of code reuse here.  The only games that are likely to be made with the engine you end up with are games exactly like yours.  This is why I actually think that releasing engines to this community would be a really bad idea: unless the engine is general beyond belief, the engine isn't actually an engine, it's some preset game mechanics in a can.  You then end up with 50 games that are the same save for the sounds.  There are some more advanced techniques that make the engine more general, one of which I am applying to my current project, but the benefits therein remain to be seen and they don't work so well for turn-based stuff.
Before I go on, I must confess that i came to audiogames through sighted gaming; my vision used to be good enough that I could do it effectively by sending the computer and the console through the same headphones, using the keyboard below the desk with the TV to read walkthroughs on the internet, among other things.  As a consequence, I've played maybe 1% of audiogames, and think that most of the remaining 99% are very, very, very lacking-my measuring stick is the sighted games I've played and beaten (ocarina of time, Castlevania: Symphony of the Night, couple others fall into the beaten category).  So anything I say on game mechanics may be...uniquely flavored.
That disclaimer out of the way, however, I don't actually think I've ever found a game with turn-based combat where grinding is actually fun, at least not to me.  All of the games nowadays with turn-based combat and for which people say "play this for the combat system" add gimmicks and play more like an RTS: turn-based combat was very definitely a product of the hardware as far as I can tell.  That's not necessarily a problem, but you'll either have to spice it up with something or you'll have to carry the entire game on the story.  I mentioned limited movement because that seems to be one of the common ways to do it now-we're talking something like a 9-by-3 grid or maybe a 9-by-5 where each party gets a3-by-3 square.  This is not hard in terms of programming; there is basically 0 math involved.  But unless you do something we're back in the era of Final Fantasy VI; unless it's a boss, you pound attack over and over and level strategies include rubber bands to hold buttons down overnight (really, you could do that in Final Fantasy VI).  You absolutely have to do *something*.
My advice for grinding in a turn-based system is to make combat fun somehow.  Then kill the grinding.  Make character bonuses not based on level; make them rewards from doing quests.  This moves the focus from your combat system.  I don't care how good it is-6 hours with it will make it a horrible, horrible thing, and you don't have any online social interaction going on.  You can turn character advancement into equipment, too: it's not about your level, it's about your sword and your ring of power.  You can then move the entire thing over to puzzle solving and world exploration which is better for a single-player RPG, at least in my opinion.  You can get some leeway out of realtime combat--Dark Souls is a good example of this in the sighted world--but even then, you've got to carry it on something else (Dark Souls used, well, a super dark and depressing world and a huge dose of ambiguity and god how I wish I could actually play that game past the first boss to actually experience the story myself).
So maybe the ice spell isn't level 15, it's helping an ice elemental get rid of a fire spirit inside a volcanic dungeon that threatens its habitat, and maybe the fire spell that you wanted to put at level 15 is helping the fire elemental get rid of the same ice spirit that you helped for the ice spell by going into the plane of ice and destroying the portal through which it pulls power-and you can only get one.  And then you add in some plot that makes one obviously good and obviously evil, but when you start reading between the lines or find some other piece of lore or happen to know something specific about how ecosystems or something works in the real world (which you put in that piece of lore for the players who don't) it's suddenly ambiguous who you should side with.  Doesn't this sound way more fun than 5 hours of turn-based combat?
this is where I have to knock my own idea down some-it's also much harder to code an engine that can cope with story and one-off puzzles.  It's also the kind of thing I'd not particularly want to try in BGT-you probably want a level editor that includes scripting, so you're probably going to need lua or something, and I don't believe you can even talk to such things from BGT.  Otherwise, you'll always be at the mercy of the programmer, and hard-coding these one-off quests into your engine instead of into your maps on the scale I am suggesting will just give everyone a headache (was it in quest_behavior_51, quest_behavior_512, or quest_behavior_5218? O no).
Maybe I'm wrong and there's a significant number of people who find vanilla-flavored turn-based combat to be super fun and exciting, but it's certainly a dying breed in the sighted world at least.

Final Fantasy VI was one of the first video games I played, back when I had the vision to (admittedly by literally leaving noseprints on the monitor) read the menus in it.  I do not consider Final Fantasy VI's combat to be good.  I had someone helping with reading the story, and it was for the story (I was like 14) that I actually kept playing.  I can't comment on Chrono Trigger, as I've never played it, but strongly suspect that my reactions to it would be identical-it's not for the combat, it's for the story.
If you look at it from the programming perspective, though, something interesting actually shows up.  Back then, you got to pick one of two things: realtime combat or impressive (for the era) visual effects.  You couldn't really have both.  Even as far forward as early PS2, the turn-based games basically went into incredibly cinematic territory.  But then we reached a point where playing a video game is basically like being in a movie no matter what you do, and even the traditionally turn-based series are warping it and dropping it and adding movement and if you showed it to someone from the era of Final Fantasy VI it would be horrible blasphemy and also awesome at the same time.  I don't think anyone did turn-based combat because they thought it would be a great gameplay style, I think they did turn-based combat because you're trying to run in a couple megs of ram at most and want to have some more impressive graphics.  And then they realized that this was easy to code and it could be all about the story.  But admittedly this is just a pet theory based off my experience with no real evidence.
You probably won't break the right angle passage rule.  This is kind of a hard and fast thing.  If you're on a tile-based grid, you're not going to get rid of the "jagged" edges; this may cause problems.  But really it's that environments have to be simple enough to reason about.
I played Entombed for 5 minutes and touched Paladin of the Sky not at all; this particular type of game isn't for me.  The only way you'd win me is with story.  I can live without voice acting, but the experience shouldn't be grinding in any way.  If I had to make a suggestion, aim for 10 hours of content-anything more really needs a very, very engaging combat system or is going to be a whole lot of story.  It's also funny that you should mention WoW; my current projects (admittedly all useful on their own) are early steps in my long-term plan to get there and do an MMORPG for the blind.
The unfortunate thing is that you're almost certainly going to want the things required for my point about questing in your engine, and this is almost certainly not a game coding task.  Of the coders around here who are of the caliber to give one an engine as opposed to a game, the only one I can't immediately assign a project to is CAE_Jones.  I'm preaching to the choir when I say that this is your immediate obstacle.  Unfortunately this probably isn't a BGT project, not if you want to be able to do simple scripting.  You're going to need the full pipeline: a programmer who handles engine bugs and develops tools, a builder who makes game content including scripts, a story/content/mechanics designer (who is probably you), and a tester.  The less these areas overlap, the better.  My go-to tool is Python, but it doesn't matter-you want Lua or V8/another Javascript engine but V8 is the best bindings, however.

Hello,
@jade: I'd be happy for a long game and I really like your setup, as long as there's quite a few quests and things to do along the way, which it sounds like there might be from the way you're setting this up.

Yeah, BGT is easier to get going.  Not easiest, but easier.  The amount of code that you have to write to get the window open as compared to the total size of the project being proposed here is a spec of dust in comparison, though.  You can technically write a scripting language in BGT.  But you're going to have to do everything without tools that are pretty standard; no one hand writes parsers anymore for example.
if you go to basically anything mainstream, though, you get Lua, Javascript, Python and a billion other scripting options for free, and all you have to do is add them to your project.  This saves 1000 lines easily, and gives you a ton more stuff than you'd get if you rolled your own.  BGT specifically can't bind function pointers, which means that BGT scripting needs a scripting engine written in Angelscript itself.
And this game wants scripts, it really does.  RPGs are games of special cases, not games of general mechanics.  Shades of doom doesn't need them because the point is that you're shooting monsters, not solving complex puzzles and triggering quests.  But look at Swamp-even something with the complexity of Swamp needs them.  And in terms of levels, this is more complicated still.  Characters need to have motivations and conversation trees, doors need to unlock if you're carrying the magical artifact, walls may need to disappear.  You can't just put this in the engine; that's why I'm being so big on the difference here.  There is a huge difference between a game coder and a game engine coder, and that is that the latter isn't really even writing the game itself.  Without scripting, whoever is writing levels will need to work with the coder at all times.
OpenAL is a horrible thing that I'd not wish on anyone, leaving BGT doesn't lose you that much sound quality at all, and this game isn't about detailed aiming.  In fact, I'd not be surprised if most of the files end up being stereo recordings--why code all that panning stuff in code when the attack itself can just be pre-edited into the final mix?  Nothing is really moving in a game like this, not at all.  I doubt you even need much pitch bending, and if you do you can just make a second file.  This game is not navigationally complex, and it is not platforming.  If really high quality sound becomes a major problem, we can talk about Libaudioverse as I'm probably going to need testers for it in the next month or two.  But I doubt that it will.
@keyIsFull:
The amount of work needed to open the window is constant.  The amount of work needed to write your game is variable.  The amount of work needed to write your game is huge in comparison with the setup code, which you write once and then reuse in all your projects (or just get it from someone--Pyglet gives you an entire main loop, for example, and there's a ton of frameworks that sighted people use that do the same thing).  The mainstream languages make anything complex take half the time because I can just go get code for stuff, say raycasting and 3D math and collision detection.  And the code I get is general enough to work in all my projects, not just one.
As for Python itself, I'm not sure what the difference in its classes is that's giving you so much trouble.  They're basically the same as what BGT is giving you.  We can talk if you want.  Nevertheless, indentation is a very, very good idea for a great number of reasons, up to and including being the easiest way to make sure you stop having those pesky brace mismatches that plagued me for years.

I'll try and address your concerns, though not necessarily in order.

1. I'm willing to give exp for dungeon completion, but probably only if you collect all items/chests from that dungeon. Else, you could speedrun it, get next to nothing and get reward atop reward for doing almost nothing out of the ordinary. That said, I'd be happy to give rewards for that sort of thing...and yes, quest/bestiary/alchemy experience would be given to everyone. Probably wouldn't be astronomical (so you wouldn't get ten levels for an exploration bonus in one dungeon), but yes, it would give more incentive to exploring.

Regarding inventory limit, I figure it is probably easier to not force players to micromanage; the party is together, so it would be easy and not really worth mentioning if they sort of juggled the items between them as needed.

Regarding level gates, I don't want to use them if I can avoid it, and I think I can. I'm going to force the player to make choices where they get one of multiple paths, and in that sense they might miss skills or spells, but other than that...no. Going to your next class early shouldn't make you lose skills or spells. If it can be done, I'd like to have it set up where most of your later skills/spells in the class you're going to leave behind are quest-related, oor will be learned by the class you evolve into at the appropriate level. Example: if you're a spiritualist and spiritualists learn Focus at level 26, but you turn into a monk at level 24, it won't matter because a monk will still learn focus at level 26. Conversely, if you wait to become a monk till level 35 and monks learn Choke at level 29, you'd learn it instantly upon promotion.

Hi,
Interesting.
Jade, I'd be quite happy to throw my coding knowledge out there. I've not programmed anything this complex in a while, and as several people have stated, its going to take a lot of prior thought and I probably wouldn't code something like this in BGT. I do have a couple questions.
1. Are you planning to make this cross platform? If so, then we'll want to think about writing an engine in a language such as c++.
2. Do you have any project deadlines? I obviously have other life commitments such as college and the like.
As for game playability, I really love this idea. the most I've seen in an audio game to this effect was paladin, and that didn't stretch to the length of playtime you're talking about.
If you want to contact me privately, my skype is kylecunningham32. Yes, how dangerous, putting it on the forum. As long as you make your intent clear, I won't deny your request.
Thanks,
Kyle.

Hi,
I'm willing to give this a shot. As I said, I think it has good potential. I was also thinking windows at first, cross platform support requires a little more work and a lot more planning from the coding point of view. PM me or some such with contact details if you want to talk more privately about it.

Yeah. Um. For this, Python brings basically 0 limitations to the table.  Most interpreted languages bring zero limitations to the table.  This is not a performance intensive project, and god help you if you do this in C++.

Hi Jayde.
Sorry for bringing back an old topic but I just wanted to let you know that if you need help I can write storylines help with game mechanics things like that just let me know if you need help.