Calin said:
Is there something missing?

You forgot the most important: Handling player input.
You always only worry about NPC and world simulation it seems, which is our technical challenge.
But we do this only for one reason: It should be fun to interact with, which is our design challenge and what makes the game good or bad for most.

Calin said:
A GameEntity base class with an Update function. I will have a loop in which every frame I will iterate through all GameEntities and run the Update function.

Sounds you want to adopt some generic software design concepts without knowing exactly why you should, or what's the advantage / disadvantage of said concept over others.
Personally i prefer to figure out what's needed and care just about that. It does not matter if we call it entities and components, OOP class hierarchies, or whatever else. The specific problem dictates the good solution, but we can't expect some generic concept to be the best solution for our problem. Nor can we expect such concept feels convenient and natural to use. It depends on personal favors and habits. In other words: Do what you want, in the way you like. Follow belly feeling, and if it turns out bad, change it - now that you know what's the problem with it.

A question: What is supposed to happen in your Update() function?

Update usually means to change state due to the advancement of time.
So what you need to think of is how to manage this state and the dependency graph so all information affecting this change of state is available when you do the update.
Assuming you still work on RTS, you have units. And a unit can have a lot of state. Position and velocity, health and armor, ammo, maybe a current target, maybe a path to the goal, etc.
You may also have different types of units, some of them way more complex than others. A unit may even produce smaller units and release them to the battlefield while moving to some goal. Eventually such unit keeps commanding its sub units, so it needs to keep track of them.

At this point, likely we can no longer use just one simple struct or class to represent every potential unit. Our class will have too much state which by most of them is never used, and out memory access patterns become random and inefficient.
To address this, intially OOP class hierarchies were often used. We have a NPC base class, then a knight and a pawn to derive from that, and also sword or bow fighters deriving from the knight. Etc.
But this has many problems, mainly because class hierarchies form a tree, not a graph. So we are not flexible. We may want that both sword and bow fighters can now also have some magic skills. But we can not derive our magican class from both the knight and the bow fighter. So we are forced to derive them from a magican instead, which my not work for other reasons.

The Entity component model addressed this problem. It replaces class hierarchies with components. We have a magican component, a knight component, and a bow fighter component.
And somehow we can couple them loosely, so a certain NPC can have all of those components. Great. Now we can form graphs and have no more tree limitations.
We also have multiple classes now to make some NPC. That's good for systems. E.g., a physics system just cares about rigid body components. It loops only over relevant data, so our memory patterns are much better. The physics system now also is modular, and we can use it and its rigid body class in other games. Great too.

However, the catch is that it is now no longer easy to find all components belonging to a certain NPC. There are many ways to do this, all with their pros and cons.
We could have a list of components per NPC, but this list has variable size.
We could use some ID per component, and find all components which have this ID. But then we need to do a lot of searching, which is slow.
We could form a linked list, so NPC points to rigid body, rigid body points to health stats, health stats point to weapon, etc. But now we need to traverse and chase pointers, hopping around in memory constantly still.

It's hopeless. We will never have a ‘right’ way to do it. So just do what you think should work, but be prepared to regret your decision later and improve.

Calin said:
A routine to run the build orders for AI players

Build orders, just like walking along a path, are actions which last over a duration of time. That's usually a challenge.

For example, you may start with just one NPC, successfully calculate a path to a goal, and than make the NPC walk along the path. Nice.
But then, when you move on to multiple units, each having it's own path and eventually changing goals at any moments, you may find it difficult to apply what you have already solved before.
That's a good example of why state management is important. You now no longer can just follow the path from start to finish in a single function. Instead your NPC must be able to do just one step (per Update), then eventually find a new path to a new objective, or eventually continue to follow the given path.
This means either your NPC or your pathfinding system needs to store this path, and on which segment on the path we currently are, and that the NPC is currently walking along a path, or it may do a break because some combat. We also need to delete the path and free memory once it's no longer needed, etc.

I would care about this first.
Make a map with multiple units, let the player select them and have them move to a goal they click on.
Even if the units are walking to their goals, the player must still be able to select them again and give them another goal.

That's what you need to do i think. And only after problems show up eventually, you have a good question to ask.

Calin said:
there is no player input in my program. AI player vs AI player is still a functional thing. I don’t find the player interface ( not the type where you make abstraction of who is playing the game but rather user interface) and buttons etc. challenging. I’ve done that before, I’m tired of it.

Oh, so you work only on things you find challenging, interesting, or fun to do?
Well, sadly this won't work. If you want to make a game you have to work on everything that's needed, including input and user interface.

Sooner or later. But better sooner, because:
You can use it to test your application. It helps to find things which do not always work. It reveals issues you did not think of, and will not spot if nobody does unexpected things to your game.
GUI and input is needed for debugging reasons, not just to make your game playable.

Calin said:
I think keeping everything in the same container is the easiest thing to do. Keeping a patch of crystals (resource) in one place and a unit in another and then trying to run them against each other if there is a relation between them seems like a lot of trouble.

You mean you will have a single god class, and it will handle everything? All kinds of units, all resources, all buildings?
The RTS games i have in mind are way too complex to make this work. The class would be huge, a waste of memory and spaghetti code hard to maintain.
But i think it's fine to try it and see how far you get. At some point you may feel a desire to split the class into multiple classes, but that's always possible.

Assuming the day will come, here are some options regarding your worries of processing multiple kinds of objects.

You can use OOP. Declare a common interface you need in the base class, and have derived classes each having specific implementations of said interface. Then you can call e.g. Update() on any derived class object. C++ cares about all the details under the hood. But you need to design your interface with foresight.

You can do the details yourself. E.g. using switch statements, processing different code depending on the kind of object. Because i do not like OOP so much, i still do this often. But often i regret it. It's more work and more error prone. If you add a new kind of object, you have to go through all your code manually to add it everywhere.

After bad experience with either, you may start to look up what other people do, and it will bring you to ECS and similar advanced topics. That's not something i would describe as 'interesting'.

If you want to postpone this as much as possible, i understand this. I also think it's better to do some mistakes first, like using the god class, then learning from those mistakes and ideally coming up with improvements.

Calin said:
In all seriousness skipping over doesn’t break anything

Umm, ‘skipping’ means ‘not doing at all’. So you mean you will NEVER make your game playable?
It remains a self running RTS demo?
No ‘adding playability' at least with day one patch on release?

Well, that's interesting. It's not a game then, and you may be on the wrong forum. But i admit it is something new.

Or, in case you have expressed yourself badly and i've got some things wrong…

Calin said:
Is there something missing?

Yes. Make it interactive from the start, and playable as soon as possible.

Calin said:
My goal was to build a game on my own, and then move on to a better RTS, I know there are guys that can do the work of building a RTS way better then me. I would like to work on verson 2 which is better ai.

So your argument is something like ‘I do not work on a game - i work on an AI system. Thus i do not need things like processing player input or a GUI.’ If i get you right.

But imo, that's still the wrong way of thinking, and you think this way because you do not know what you miss. You are unaware how much harder you make it for yourself, and how much you could increase your rate of progress, if you had a ‘proper dev environment’.

What do i mean with proper dev environment?
Let's think of game engines like Unity or Unreal. They have an editor, lots of GUI stuff, and the same things 3D modelling tools have. Gizmos to transform objects, users can move their camera anywhere to look up things in detail. They can enable debug visualizations e.g. to show control points of a spline, etc. Devs can and will also implement their own code just to visualize some thing currently giving them problems. They can output text in the 3D viewport, e.g. an error message, showing something went wrong. And due the visualization, the user sees where things went wrong, and how they look like. This might tell them more in an instant moment than using the debugger to step through the code, but lacking any spatial context.

That's not a luxury. It is a requirement. If i have to guess, here's how much i use various ways of debugging:
Visual / interactive debugging, requiring to write a lot of specific code: 90 %
Logging text to a file, e.g. error messages or warnings. Requires to write very little of code: 5%
Using the debugger, not requiring any code at all: 5%

As a beginner, i did not use anything of this. Not even the debugger. It took me some time to figure out why this is so useful, actually years. I assume you are at a similar level right now.
But now, knowing better and looking back, i do know how much time i have wasted by not investing into debugging skills. I was working blind folded and inefficiently, so even simple things took me a lot of time.

Different devs use different ways to debug their code. For example, i had never used the way to log text to a file, until i've worked with a web dev on a webpage. He could not use the debugger for technical reasons, so he had to use just logging. Working on webpages, options on visual / interactive debugging are pretty limited too, so logging was the only real option for him. So, being new to web dev, i have adopted the same method. And only then i realized it gives a lot of options that using the debugger do not give. For example, i can see the order of things happening. I can see which error appeared first, and i can speculate that maybe this error causes all the others after that. Using the debugger, you do not get such kind of information.
I'm pretty happy now to know this, and i still use it a lot in my own projects.

The kind of visual / interactive debugging i want to talk about is used rarely. Because it's almost exclusive to realtime / graphics application development. But for us, working on game related stuff, it's always available.
Here's what i currently have on my screen:

Basically all i have on my screen is debugging stuff. All those dots, lines, text, and all of the GUI is debugging stuff. I work this way 90% of the time.
That's because what i do is very difficult. Working with geometry is hard, because it's so easy to introduce degenerate cases. Often i need to work a whole day just to understand why exactly such a bad case happens, to see how it looks like, and what would be the proper way to fix it. I need those visualizations, and i need interaction so i can observe what a unique iteration of a loop is doing, for example. It's some work to make all those visuals and GUI stuff, but it is the only way. It would be much too hard otherwise.

Now you may think you don't need this, because you do not work on geometry.
But no. I do the exact same thing for everything else too. No matter if it's robot ragdolls, setting up a character skeleton, or a little game. It's always useful. For almost everything, all the time.

If i would work on an RTS AI system, i would use this heavily. I would click on a unit, and then i would see it's current path to follow, and the enemies it currently sees. An window would pop up, showing the current queue of orders it is processing. And i could click buttons on this window to add new orders to test how that works.
I would make a whole RPG game to test my AI. I would use boxes for the units, like you do. But my GUI and interaction would be much more than what later remains in the final game. 10 times more, maybe. So i can test all the things and see how they work.
I would spend more work on debugging, visualization and GUI than you do, but i would have a playable RTS in 3 months, i claim.

How long do you already work on your RTS? How many years? And it's still not playable.
Why could i do this so much quicker than you can? Because i'm a better programmer? Because i know all about C++, OOP or ECS, and because know ‘how RTS is made’?
No. I actually know very little about all those things.
But i do know what's needed to develop a graphical realtime application:
You need ability to draw stuff.
You need GUI.
You need a linear math library for vectors and matrices.

You need all that first. And only after you have all of this, you can start work on your application, whatever it is.
Using DirectX, you have a check on point 1 and 3. But you have no GUI, so you are extremely limited on what you can do.
I propose you add imGui to your project. Almost everybody uses this library. It's great. It's made for debugging reasons, and not really useful for a final GUI of a completed game.
Like character boxes, you can postpone work on a final GUI, and you should even. It's not yet important.
But for anything more complex than PacMan, you need some basic GUI to interact with your application, and to print information to your screen, not just to some file.

Integrating ImGui is some work, but it's worth the time. You'll work much more efficiently after that investment.
If you don't do it, every script kid using Unity will achieve more in less time. Your choice is to do everything yourself. Respect and congrats. But this means you have to care about some things which are not really interesting, but still absolutely required.

That's just my personal opinion and experience, ofc. But i'm sure many would agree.