Well,you won't be stuck, but your project might be. If you write a project for, say, Ogre3D, then decide to switch to Irrlicht, you'll be able to port concepts and non-rendering stuff over with some work, but the parts that actually touch Ogre3D will probably have to be redone. But that holds true with just about any code written against an API. Unless the API is some sort of open standard (something like OpenGL, say, where the standard is set by the ARB, but the actual implementation can be done by any number of vendors) then it's unlikely that you'll be able to move it without heavy changes.

You can mitigate the damage by interfacing with the API through an abstraction layer. This does add code and complexity, but it also means that if you do have to switch APIs, you probably only have to rewrite the abstraction layer, rather than the entire game.

I've run the gamut of 3D apis: OpenSceneGraph, Ogre3D, Panda3D, Irrlicht, Crystal Space, etc... before finally settling on Urho3D. Each time, I've ended up massively rewriting lots of code, so yes, switching things is a timesink. And there really is no "best". Put that out of your mind. There is only "sufficient for my purposes". Sometimes, you have to just take something and make it work the best you are able.

Switching libraries is quite common as you have to work with an api to find out if it fits your needs or not. Once you realize it doesn't then you have to move on.

I'm going to layout two of the best paths I know of. The first one is the more popular easier path the second is a bit harder however most who successfully hike that path say it's more rewarding. Since you were kind of vague in describing your skill level I will pretend you are a complete beginner.

Path 1. C# and Unity

Unity is a 2d/3d game engine. C# is one of the languages you can script that engine with. There is a free version of unity to get your feet wet.

Here is a pretty good book on programing c# and Unity. This book is for beginning programming.

http://www.amazon.com/Learning-Developing-Games-Unity-Beginners/dp/1849696586/ref=sr_1_1?ie=UTF8&qid=1393792222&sr=8-1&keywords=c%23+unity

Use either MonoDevelop or Visual studio for IDE.

Path 2. C++ and one of the following apis.

2D SFML 2.1 http://www.amazon.com/SFML-Game-Development-Jan-Haller/dp/1849696845/ref=sr_1_1?s=books&ie=UTF8&qid=1393792361&sr=1-1&keywords=sfml

Ogre3D http://www.amazon.com/OGRE-1-7-Application-Development-Cookbook/dp/1849514569/ref=sr_1_2?ie=UTF8&qid=1393792307&sr=8-2&keywords=ogre3d

irrlicht http://www.amazon.com/Irrlicht-Realtime-Engine-Beginners-Guide/dp/1849513988/ref=sr_1_4?ie=UTF8&qid=1393792323&sr=8-4&keywords=irrlicht

I would suggest VS or QtCreator for IDE.

In both paths I would suggest Blender(3d modeling and animation) and gimp(texture editing) since they are both free and open source. However substituting them for a paid product like Photoshop is common.

you should probably use the same approach for games as for apps:

1. determine your target user.

2. determine what platform(s) that target user has.

3. determine what tools available for that platform and the type of app you want to make (a particular type of game) are likely to make you the most productive.

4. start with those.

5. adjust as necessary.

In these respects, the platform and tool selection process for building apps and games is very similar.