Are you trying to build a game or are you trying to build a game engine?
Game, primarily. Though there's going to be a lot of overlap either way in terms of what I want to achieve e.g. make a game but hopefully learn a lot of new stuff on the way too by not necessarily doing things the absolute easiest way all the time but mostly I'd just like to get a game project finished for the first time in a long time and feel more confident afterwards about game development and 3D in particular.
So either way is good, I guess.
No.. either way is not good. Take it from me, I wrote my own game engine and it took over a year to do. I learned a lot about engines, but didn't make a game. I finally changed gears and decided I wanted to build a game and building an engine was a waste of my time because it was never going to be commercial grade quality. I'm just one engineer. Professional quality engines are built with large teams of engineers, so the quality and breadth of their engine is always going to be superior to whatever I build. If I wanted to add a new feature/functionality to my engine, I'd have to code it myself and I could expect to take many more months, and the QA just wasn't going to be there.
I don't know your game dev history or skill set, so I recommend starting really simple for starters and nail down the fundamentals. Make those atari games, then move up as your skill set increases. Use a game engine. Don't write your own.
Is there a particular reason you've decided to use C++ instead of something else, such as C#?
Mostly because it's what I'm most used to, what I've made some 2D games with, and what I've been using to (not as much or often as I should) study the workings of OpenGL.
Okay, you should definitely check out Unreal Engine 4. It's free and the backend is written in C++, and is still quite accessible to novices.
You need to start by building terrain. And to draw terrain, you start by drawing a single triangle in 3D space.
Already gone over that in some tutorials and think I have that down fairly reasonably.
It's whether or not making a very basic vehicle drive around a 3D terrain in an acceptable way is straightforward enough without getting into time-consuming physics for someone to even bother doing it themselves rather than just go get a library that concerns me most...
i.e. It's nice to delve in and try to learn new things, but when it's something I really have no clue about beyond the purely speculative ideas I've come up with and some basic ideas about how vector mathematics works, I'm afraid I'd wind up spinning my wheels for weeks and lose my motivation. Meanwhile it seems a typical enough thing that there must be plenty of standard solutions around, but finding them is the hard part.
TBH, I'd probably just go with Unity if my current computer wasn't very unfortunately one of the few still running Vista, though in the long-run maybe I should just bite the bullet and get a new computer right now..
Still, the idea of doing things a little more manually and getting something basic up and running that way appeals to somewhat in and of itself. It's annoying when you keep wondering how certain things are done and you're not sure if perhaps it's easier than it looks, or actually even much harder than it looks...
In my experience, everything *looks* easy, especially after you see how someone solved a problem. What you *don't* see are the hundreds of different attempts someone went through on their way towards finding that elegant solution. Getting terrain into a 'from scratch' game isn't easy. It's going to take a lot of engineering effort. You'll have to decide how you're going to draw the terrain. Then you have to figure out how to reduce triangle counts by using an adaptive LOD system. Then you have to figure out how you want to let people edit the terrain. Then you've got foliage placement. And you have to be able to find where a ray intersects with any point in the terrain. And how to apply textures. And how to make sure things don't fall through it. You'll probably want to break your terrain into "chunks" as well and figure out some way to stream in various chunks. Maybe you'll want to do occlusion testing as well. And lighting and shadows. Ugh. Eventually, you'll say, 'this isn't what I signed up for!' as you realize you aren't making games.
In my opinion by gameplay RTS is the second hardest genre
Yes, that's a concern. The idea was to hopefully get by with as little AI, for example, as possible. Probably make it mostly about resource collection. There's a lot that can be done before combat is even introduced.
Something like notch's "Breaking the Tower" from Ludum Dare a few years ago even comes to mind; essentially a simplified version of The Settlers with a very definite and short-term goal.
Just an experiment to see where it leads and what I can come up with.
Even Mega Lo Mania is an example of an RTS that doesn't necessarily fit into the typical Dune II model, where combat is simplistic and it's really more about resource gathering and the choices that are made strategically. It's 2D, granted, but then 3D would just add the matter of collision detection between the landscape and units/buildings which wouldn't change much.
Indeed I've read that during development they originally got the entire gameplay working with just the interface visible alone because the graphics weren't actually important beyond illustrating the action.
Maybe Unity is really my best bet... but I just find myself feeling lost and as though beyond the very beginner stage, it's hard to find many particularly structured resources for advancing your practical knowledge of game development.
Granted, it needs to be expected for something like this to be a very hit-and-miss experimental hobby/career, but when you're new to a particular concept it's easy to feel overwhelmed if you have nothing to draw from.
It's like even if I could always put 12 hours a day in game development, I often have no idea how best to use my time to get a good grasp on the more practical aspects of more intermediate subjects. The likes of gpwiki.org don't seem to have anything on the terrain collision problem and I haven't yet found anywhere that seems to maintain a large collection of solutions/tutorials for a wide array of common problems beyond the very basic.
Whatever you do, take careful stock of your available resources and scope your game accordingly. The objective is to built a game and actually complete it. If you're one person and can only work on it in the evenings after work and on weekends, then you don't want to build the next GTA or Need for Speed game. A simple, yet polished game is orders of magnitude superior to a complex but unfinished game.