Tile based RPG

Which language you use is entirely up to you. You seem like you're more comfortable with C++, so why do you want to switch?

I think this site has some pretty good tips on tile-based game development. You can get started on a text-version of your tiles now and "upgrade" to graphics later when you know how to do so.

Other people will probably be able to give you better ideas than I can for audio, AI, and graphics libraries (or tutorials), but it can't hurt to look at things like OpenGL or DirectX to see if that's the kind of programming you want to do.

Another entirely viable option is to use RPGMaker (not sure which version is the latest). It's pretty simple to play around with and make simple RPGs, but can also be expanded to do (as far as I can tell) anything you want through its scripting language.

Hope this helps.

If you are going to use c++ (which I would suggest if you are familiar with it) then there are three different libraries I would suggest for sound, input, etc.

SDL is my favorite and there is a lot of material online regarding this. SFML is a bit newer and there are not quite as many tutorials as for some other libraries. Allegro is another major library and is typically known for getting games up and running fairly quickly. I'm not going to go into detail as there are many posts about this on the forum.

My favorite library is SDL just since I've been using it for a long time, but that's just my opinion. If you decide to go with SDL then LazyFoo has the best tutorials for that over at www.lazyfoo.net.

I just made a tile based game using allegro and c++. Feel free to ask me for any help if you decide to go that route.

Just use plain C. Can't go wrong. You can draw on the experience you already have with C++ without having to worry about writing generic code, code generation, templates or classes and private and public stuff. More often than not, libraries that are out for C++ probably have vanilla C bindings (I know for sure SFML has this -- CSFML -- and SFML seems to be very good for writing games with).

In other words, try out plain C before trying to write a full game in C++. I feel like there's less obfuscation involved in C, and you can just get down to the meat of the code more easily than in C++. While C++ is by no means unreadable or unusable in my eyes, it feels... less so than C for projects that take advantage of the features C++ has to offer.

Just use plain C. Can't go wrong. You can draw on the experience you already have with C++ without having to worry about writing generic code, code generation, templates or classes and private and public stuff. More often than not, libraries that are out for C++ probably have vanilla C bindings (I know for sure SFML has this -- CSFML -- and SFML seems to be very good for writing games with).

In other words, try out plain C before trying to write a full game in C++. I feel like there's less obfuscation involved in C, and you can just get down to the meat of the code more easily than in C++. While C++ is by no means unreadable or unusable in my eyes, it feels... less so than C for projects that take advantage of the features C++ has to offer.

He didn't mention having experience with plain C, so why would you suggest it? C implies a very different design style than C++, not to mention the fact that many constructs he's used to from C++ would not be available. From my point of view, he certainly could go wrong by making that choice. (I'm not saying that C is always the wrong choice, just that it could be the wrong choice for someone with no C-specific experience.)

Now, if you mean the OP should just go straight for the game code without worrying too much about writing reusable code, then I completely agree if it's his first project. But that can apply to any language, not just C++.

I acknowledge that I'm getting way too pushy on this subject. Carry on.

Just use plain C. Can't go wrong. You can draw on the experience you already have with C++ without having to worry about writing generic code, code generation, templates or classes and private and public stuff.

Yep, that's pretty much what I do when working on personal game projects. C++ is usually better for application programming (my map editor is C++) and when working with a team (data hiding, plus more flexible to design changes), but I just like the freedom and to-the-point code you end up with in C. C++ tends toward a certain style of very thorough object-orientedness, whereas in C you just use OO techniques where they work best, and procedural techniques elsewhere, and whatever else you can think of.

But it definitely is less flexible in terms of code reuse and major design overhauls, and is better if you have experience using C++ concepts. So probably stick with C++ for now.

Now if you really want to be awesome, code it in 65816 assembly (that's the SNES CPU) like the real FF4/5/6
I actually tried doing some SNES programming once, and the folks who made those games must have had truly legendary skill. ARM assembly (GBA and DS) is much more straightforward and powerful, and even that would be a major challenge for me to code a whole game in. And I even like assembly programming.

Oh, and libraries... SDL is my fave. I just use it to get access to the frame buffer. I malloc an array to be my back buffer, and write all my own blitting code and such (it's fun and easy, if you don't go too speed crazy), and then just copy that to SDL's actual displayed screen at the end of the frame. Software rendering low-res games like those is plenty fast on modern computers, and platform-independent, and easier for me than figuring out a bunch of library functions and then either having them strewn all throughout my game or having to code a wrapper for them.

SDL is also great for sound and input. Write a simple sound mixer for sound effects, ogg vorbis for music (SDL tells you how many samples you need, you tell a vorbis decoder library to decode that many samples, add those into your mix, and done). Input, all you need is a way to poll the controller every frame to see what buttons are pressed. Everything else is just logic based on if a button is currently pressed and whether it was pressed last frame.

I'm working on a project like this myself. I'm a few months in and I'm writing most of it in C++. I use the Tiled Map Editor to load my maps, and I'm using the tinyXML2 library with my TMX loader to read the content. I display everything with OpenGL ES since this is for iOS.

Btw, if you want some code examples, I can give you some stuff like a sprite library and TMX loader. You need OpenGL added to your project, but you shouldn't need to know those APIs to work with my code (it uses it in the background).