>I work on an AI system

Call it that if you like. Thinking what is needed to get a RTS ai player working is enough to build the whole game. The only other thing that’s needed is playing a RTS game and paying attention at what an ai player does.
> you need the ability to draw stuff

You mean graphical artist skills? What are lame programmer art placeholders for?

>Let’s think of game engines like Unity or Unreal

Everything these commercial engines have, debugging tools included is oriented towards producing a commercial game that is up to date with the requirements of the year. It’s all about next gen, I have no such worries.

offtopic, I‘m lost when it comes to what I’m going to use to draw stuff. Graphical engines and API’s in c++ are so tough to use. Currently I’m using DirectX 10. I heard DirectX 10 and 11 are deprecated in the new version of Windows. I will try Ogre maybe I’ll manage to bind it to my current engine.

I like your screenshot btw.

Calin said:
You mean graphical artist skills? What are lame programmer art placeholders for?

No, i don't mean art, or anything visible in the final game.
I mean temporary debug visualizations. Temporary code we write only to visualize a certain problem which we can't understand using the traditional debugging methods.
A typical example is intersection or closest distance calculation between two geometric primitives. Box - box, sphere - box, sphere - triangle, etc. You may need this e.g. to plan obstacle avoidance for your units.
Such tests often have many special cases. It's a difference if the sphere is closest to vertex, an edge, or a face of our box. Each case requires its own code to handle it.
Thus, if you develop such test within your game, it's likely some special cases just do not happen at the moment. But it seems working, so you move on.
Three weeks later, when you have already forgotten everything about how your test works, bugs show up. So you have to work on it again, building up the forgotten knowledge again, taking a lot of time, to finally fix it.
A month later, another problem shows up, which went undetected before. Again you have to work on that damn intersection function…

Equipped with visual / interactive debugging superpowers, we can do much better:
We develop our function in isolation, independent of the game.
We make a GUI so we can move the box and sphere with sliders, editing numbers, or ideally transforming them with a gizmo. This allows us to test all special cases in seconds. It's even likely we stumble over failure cases we did not think of, while moving those sliders.
We also visualize the results in real time. A point on the sphere, a point on the box, and a line connecting them. We also have ability to rotate camera around our test model. And observing it from many perspectives, we quickly feel sure about our result to be the correct closest distance, and no shorter line should be possible.
Then we use our function in the game, and much more likely we never need to go back to it.

I hope this example makes sense.
Another one would be to visualize all the paths your path finder explores, not just the path which makes the final result. This way you can just ‘see’ how efficient or inefficient your algorithm is and how much work it does.
If we observe this visualization for each iteration of the path finder, we can also just ‘see’ HOW our algorithm works. We may have never heard about Dijkstra or A-Star, but we may understand how it works just by looking at our visualization of said algorithm. I grant you, this really is a low effort but powerful way to grasp some concepts quickly.

Also, application is not limited to geometrical problems. I often visualize data structures, e.g. graphs or trees. I may visualize pointers with an arrow. It can help to spot data errors visually very quickly, which would be impossible to find from looking just at raw numbers of the data itself, or stepping through the code with the debugger. There are many ways to make programming easier, but this one maybe is the most important. To me at least.

To visualize stuff, i can draw only 3 things: Points, lines, and triangles. I can color them, but i have no texturing or lighting. I do however have helper functions to draw arrows, circles, spheres, boxes.

Calin said:
>Let’s think of game engines like Unity or Unreal

offtopic, I have no idea what I’m going to use to draw stuff. Graphical engines in c++ are so tough to use.

Like you, i don't care about final assets or advanced rendering either. It's fine to use placeholders and boxes.

Again - i do not talk about graphics or even games. I talk about making programming easier and more efficient using visualizations and GUI to interact with the application.
Even if we have written this application ourselves, at some point we no longer know how it will behave in any situation. It may be much too complex to know all about it.
So all we can do is observing the application, to verify it behaves as intended. And to observe it, we need an interface of interaction.

Ofc. we could also write specific testing code, which verifies our app. We could create random test cases, run them 1000 times, and then we might be sure it works.
But both those options have their pros and cons, and they are not mutually exclusive. Work spend on one often enables to use the other as well.

It's offtopic, agreed. But imo it makes little sense to talk about higher level game dev concepts at this point, and i'm not the right one to talk about ‘Entities’ anyway.
Remembering your code you've showed me years ago, the code was pretty fine.
But you need to work an ability to manage a larger, growing project.
You need to split your single source file into multiple files, so you learn how to compile code from multiple files. (Maybe you already know.)
After that you're ready to include 3rd party code as well, e.g, the GUI i have proposed. There really is no reason to write this yourself - it's only for debugging.
There are many free and good open source libraries. You may use a rendering library one day. Or a physics engine, audio, network, etc.

In other words: No matter if you aim for an amateur or professional level, you need to care about some other things too, beside the actual programming problem you may currently work on.
This includes managing larger projects with many code files and eventual 3rd party libraries, and this includes general properties an application or game has, like processing input and having some GUI.
You should not postpone this, because not doing it holds you back in many ways.

>I mean temporary debug visualizations

I never thought you could debug using other methods than just plain text. You are creating visual models of various problems, how interesting.

Speaking of the case when you build a GUI of your own, one of the problems I’ve had is that I wasn’t even sure if the numbers the GUI was showing were real numbers or a bug in the interface. It’s like you’re building something but you have no idea what you’re doing.

>ofc. we could also write specific testing code

Is that what a test unit is? People were talking about it on code project forums and I kept asking my self what that is.

Calin said:

I never thought you could debug using other methods than just plain text. You are creating visual models of various problems, how interesting.

Other programmers are often surprised about this. So i spread the word, because i think it's really powerful.

Calin said:
Speaking of the case when you build a GUI of your own, one of the problems I’ve had is that I wasn’t even sure if the numbers the GUI was showing were real numbers or a bug in the interface. It’s like you’re building something but you have no idea what you’re doing.

GUI is something annoying and frustrating to me. I remember, for very early tools i did i have used Win32 GUI. But this really sucked. It feels like Windows is not designed for realtime applications.

Then i did my own GUI in OpenGL. With menus, drop downs and all the stuff. 3 weeks of work. I've used it for 10 years and was pretty happy with it. But it still was cumbersome to use. I had to setup the controls of a window in advance in some Create() function. My GUI took pointers to my variables and changed them directly, so i did not have the problem of invalidated duplicates, as you describe. But this was risky. If a pointer becomes invalid, the GUI could crash my app.

Then imGui came up, and i was switching over to Vulkan, so i gave it a try instead porting my old stuff.
imGui is an ‘immideate mode’ gui, which means there is no more need to setup things in advance. That's a game changer, making it totally effortless to use. It works like this:

void RenderMyFrame()
{
static float sharpness = 0.7f; // Some variable i want to tweak at runtime
ImGui::DragFloat("sharpness", &sharpness); // Now i can. A gui element is created in the current window. But i do not need to care about windows if i don't want to.
RenderImage(myImage, sharpness); // doing stuff using the tweaked variable
}

It is that simple, and works for any gui elements. They just appear in the order you created them during processing one frame. It stores a pointer to my variable, but because the gui is recreated each frame, some object which has been deleted simply won't no longer create it's gui elements. You don't need to manage anything, and all you need is to include ‘imGui.h’ in your code file.

But it is some work to set it up. You need to give it a rendering backend, but it comes with examples for any gfx API. Basically callbacks to render triangles.
And you need to give it info about kb+mouse input, usually at the place where you process input for the game as well.
However, after spending some hour to make this work, you can interact with anything in your application. No more need to express all and everything with source code.

Calin said:
Is that what a test unit is? People were talking about it on code project forums and I kept asking my self what that is.

Hehe, i'm thinking the exact same. I wonder too what ‘unit test’ really means.
I assume it is like keeping and maintaining all the various tests we implement during development, and then running them every day so you get a warning if something breaks again.

If so, that's a debugging superpower i'm personally not capable of, til yet…