I don't need to go 3D; I just thought it could be cooler without any cool ideas. I mean, 2D chess is 0% tongue.png Something 'old' like a walking character with a GUI, a character selection screen, are old but still better than Snake (not for the game itself, but because it's nothing new and cool).
I know what you mean, but make sure your excitment for something "fun" does not let you loose sight of your goal. Which is to finish your work, and get good marks.
Now, programming the game logic for 2D or 3D games is not that different. 2D games today tend to be much simpler than most 3D ones, but that is more because 2D graphics are mostly chosen for the sake of simplicity and fitting into a tight budget.
Graphics programming between 3D and 2D differs a lot of course, though many 2D games nowadays are built on a "3D foundation"... like 2D games built with the Unity engine.
Generally, your choice of graphics will not affect your coding too much. You could build a 3D game with simple boxes and spheres as characters, and a level built of simple grey boxes, and code a complex physics simulation and AI agents to go with it. You could do almost the same with even simpler 2D graphics.
Ogre3D could work out. As above, I can use Unity, but then what's left to me? Low level programming may get tons of trouble and waste of time, you're right.
I even thought about C#, but I see only XNA / Unity books that use it.
I think you make the usual newbie mistake in overestimating what a game engine does.
What a game engine usually does is free you from the hassle of doing low level plumbing to get DirectX or OpenGL to do your bidding. It will also deliver some helpers like pre written shaders and stuff like that, as well as tools to ease the content creation / importing and a ton of tutorials and samples.
What an engine does not is allow you to click your game together in the editor and just hit play... what happens then is you have a static view of your assembled level without any interactivity. If you want interactivity, you need to write code. There are many options nowadays (third party assets, visual scripting tools, and so on) that ease that task further. Generally speaking though, the game logic, AI code and Physics engine glue code still is left for you to write. You can copy it from some example, but you don't have to.
You can dive deeper, write your own shaders if you want to, or even alter the engines low level code in some cases.
You might not NEED to do as much coding as when going the DIY route. But you CAN do almost as much coding, if you have the time and need for it.
Unity and Unreal Engine 4 are the usual choices for Indie / Hobbysts interested in 3D development. Both do have a learning curve, steep with Unity and even steeper with Unreal. But that is true of every 3D engine. The upside is both engine are "free" (totally free in your case), come with lots and lots of tutorials and a large community to rely on.
Languages of choices are C++ for Unreal and C# for Unity. I can tell you that the C# API for Unity is fantastic, had a very easy time getting into it as a longtime Java dev... I am currently struggling a bit with Unreals C++, but that has more to do with me not having had enough time to really sit down and dig into it than it being really that hard to learn.
I saw them in the source codes of "Introduction to 3D Game Programming with DirectX 11" (downloaded from his website).
Make sure that if you continue to use this book as a reference, you understand that the file formats they use are not really the generally accepted standart. There is a good possibility that at least some of your model import problems would be gone if you use .obj or .fbx file formats, and common tools like Blender to create and transfer your 3D models
As a possible route for you to go, find an idea that interests you, lay out what makes it special / where it needs special code, research it thouroughly to make sure you don't overcommit and understand possible solutions, then you try to find a way to solve the problem in the most efficient way that still leaves enough room for you to show your coding skills.
If your plans are modest, stay DIY... use something like SDL or Mono, maybe even try to implement directly with DirectX or OpenGL. Just make sure you now cut back the game logic / physics interaction / AI to a minimum so you have enough time to create and test your low level stuff and shader code.
If you want to achieve a little bit more in the time that you have left, look into an engine. PLAN IN SOME TIME TO LEARN TO USE THE ENGINE! Its not a plug and play affair. If you are able to get up and running in a short enough time, you might leave the low level stuff to the engine and now concentrate on more elaborate game logic or AI code.
Like implementing your own A* path search. A complex shooting and hit locations system, or whatever you want to do.
Make sure you have a CLEAR chunk of the project layed out for you to implement, that sounds about right in complexity both for satisfying your schools rules, and for you to implement in the time left. And then concentrate on that, and make sure you don't get distracted by other coding, 3D modelling or whatnot above the absolute minimum required.
You can always make something cooler, more exciting later on in your free time. Better to take risks then, when nothing else than your time left for other hobbies is at stake.
Something 'old' like a walking character with a GUI, a character selection screen, are old but still better than Snake (not for the game itself, but because it's nothing new and cool).
