Thanks, I think with this and the other RTS-specific thread I'm good.

There are advantages and disadvantages to different approaches. SpringRTS seems to be an easy pathway to RTS fun without spending the enormous time needed to implement the basic logic (including pathfinding), but somehow it is not very popular on this site. What I'll do is sit down with him and start tinkering with a few different things (Spring included) and see where it goes. This is the advice I got on the RTS thread, but I will also include the games mentioned here; MegaGlest, notably, seems to take a similar approach to scripting as SpringRTS but it might be more suitable as a start if he picks the "make a bot first" route.

I will certainly give him the option of starting with simple retro games, but I strongly doubt he will take it up. I suspect he will look for the shortest route to creating something with brag value (among his peers who can't really code). He would want to make a game that other kids his age, specifically those he knows personally, would find genuinely entertaining. This is certainly a lower bar than "marketable", but it is *a* bar. Taking a longer time to do it would probably be an acceptable trade-off.

At least, in woodworking (his other interest where I can help much less as he already can do much more than I ever could) he gravitates towards making whatever his classmates want to get, literally from a sword to a dollhouse part.

And in the modern software world, the easiest way to such a product is to stand on the shoulders of giants; learn to incorporate things that already exist and are freely available, not code everything on his own. This is one thing I am going to teach him, because it is quite true outside of the game world. And this is what might enable him even for RTS; I do realize the features I listed are complicated - more complicated than I thought at first - but they are all already implemented. So it will have to be a discussion of libraries and engines, followed by trials of same.

...and then he will watch a lot of videos. Because he always does that, whatever the subject. (That's where he gets his woodworking tricks...)

2 hours ago, Ramendik said:

learn to incorporate things that already exist and are freely available, not code everything on his own. This is one thing I am going to teach him, because it is quite true outside of the game world.

The game world is much more pushing against the limits of a computer system, high frame-rate (16ms to do "everything"), complicated algorithms, big worlds, believable realistic environment all push in that direction. At mobile systems, reduced computer power is added. The embedded systems world has the real-time requirements (a little harder, often), but often less complicated algorithms, or less massive (simulating 2000 enemy soldiers isn't needed ). Any user-interactive program responds in matters of whole seconds, which is eons in computer terms.

In the latter the cost of developing everything dedicated to that program is not worth the benefit, faster response time isn't needed enough. In the game world, optimizing stuff to death is required to stay ahead of the competition, since that one killer feature makes or breaks the game sales. To get that, you write a fully dedicated program carefully tuned against the processor strong and weak points, exploiting the L1, L2 caches, etc.