Hey. I've made a few basic games, and I think I have a pretty solid grasp of how to make a game. For my next project, I want to make a simple rts with 3D graphics. A common problem I have is not planning things out, which results in me redoing a lot of code. To avoid this, I decided to plan everything out thoroughly before I actually start, and as I was doing this, a question came up:

So apparently rts generally use 2D game logic, even if they have 3d graphics. Is there any way to keep track of a unit's altitude using 2D logic only, and if not, how intensive would 3D game logic actually be? For example, when terrain differs sharply in altitude, how does the game make sure a unit walks over a mountain, as opposed to through it? (Not a pathing question)

Game logic generally excludes rendering. That is, the path finding sub-system might be able to treat the map as a two dimensional grid. A hill might be represented by a movement penalty on that tile, which you might already have to represent other terrain (e.g. fording a river).

When you go to render the unit, the height of the terrain does need to be taken into account as you have noted. If you accept certain minor limitations to your maps, such as not having multiple "levels" available at the same position, then you can compute the 3D position of a 2D point by having a "height map", a 2D grid of the height values of the terrain. The 2D position can be used to lookup the height in the height map, which can be used to calculate the position of a given object.

although a bit off-topic

A common problem I have is not planning things out, which results in me redoing a lot of code.

that's a common way to work. You cannot plan everything, it's better to have code that you can re-do (we actually call that 'refactoring').
There are not that many engineering tasks that are similar to software, but it's common in other areas (e.g. cooking or gardening) where things evolve and instead of planing everything 100%, you rather modify or replace parts of your code to improve the situation.

e.g. you could start by sticking all your units into a simple array and work on it e.g. find closest enemies, check whether bullets hit, find resources to mine etc. and if it works, it works. if it starts to become a problem (and there might be various kind of problems e.g. flexibility, performance, memory management, serializing etc.) you evolve the array to something that solves the problem.
as an example:
performance -> kd-tree
flexibility -> double linked list
memory management -> pre-allocate a big chunk instead of realloc
serialization -> use an STL container.

To avoid this, I decided to plan everything out thoroughly before I actually start

good planing is important, but don't aim for creating a perfect plan, rather put your efforts in creating easy to refactor code. Modularize it, have clean interfaces, re-use code, use well known pattern and algorithms instead of re-inventing the wheel.

So apparently rts generally use 2D game logic, even if they have 3d graphics. Is there any way to keep track of a unit's altitude using 2D logic only, and if not, how intensive would 3D game logic actually be? For example, when terrain differs sharply in altitude, how does the game make sure a unit walks over a mountain, as opposed to through it? (Not a pathing question)

for logic it's usually enough to have a heightmap as rip-off already said.
for rendering later on you can use a more detailed heightmap to pick the orientation, height etc. based on the coverage of terrain by the unit.

Game logic generally excludes rendering. That is, the path finding sub-system might be able to treat the map as a two dimensional grid. A hill might be represented by a movement penalty on that tile, which you might already have to represent other terrain (e.g. fording a river).

Would it be possible to draw up a quick map in paint with certain colors corresponding to terrain types, and then sort of render a more detailed 3d map with the same layout on top of it? For example, if I have a wall set to red, and when the player clicks on it to try to move their unit there, the program checks what color the area clicked on is, and seeing that it's red, passes, would this approach still work after a 3d map is drawn? Is there a way to get the program to sort of "see" through the map to the drawing?

Would it be possible to draw up a quick map in paint with certain colors corresponding to terrain types

Yes.

then sort of render a more detailed 3d map with the same layout on top of it?

Yes.

would this approach still work after a 3d map is drawn?

Yes, if you check the 2D map, rather than the overdrawn image. Convert the mouse coordinates where the user clicked to texture coordinates for the 2D map. Use those tex coords to make the checks of the 2D map as desired.

Is there a way to get the program to sort of "see" through the map to the drawing?

Yes, if you check the 2D map, rather than the overdrawn image.

As suggested, keep game logic separate from rendering logic.

One game I created uses texture maps to control the height map of the terrain and so forth. The units looked up what their Y-coordinate was supposed to be from the texture. The texture itself was never displayed, and the texture wasn't used in the rendering pipeline at all. (I could have had the terrain shader use it for displacement, but I went with a different method instead.)

This is part of what everyone means when they say to keep the game logic and the rendering logic separate. While you usually want the visuals to reflect what is going on under the hood, they don't need to have a one-to-one correspondence, and in many cases shouldn't. You can store all kinds of data in the game and render them in all sorts of different ways: 2d sprites, 3d models on a 3d terrain, etc.

You may want to look up model-view-controller architectures for some ideas. While you don't need to implement a full MVC architecture, the concept of having the data as its own thing with multiple ways to view and display it is pretty useful. You're probably already familiar with one common way this is used. Most RTS games use multiple views on the same data: you've got your main screen showing the battlefield in 3D or whatever, and then a minimap down in the corner showing it in 2d with some colored dots.