Scripting languages aren't dumbed down. They often aren't 'scripting' languages at all. They are full on languages that can do anything, and as I said in my post above, they are only called scripting languages in the context that they are being hosted in another program. They exist because they have different goals than C++. They let you model problems at their face value and ignore machine specific technical details that have nothing to do with the problem you are solving.
C++'s purpose is to be a portable language that targets system level programming. It's good at moving memory around and doing complex calculations really quickly. Other than ASM, it's the best too for that job. It can leave a lot to be desired in other areas though.
Other languages are better suited to different tasks, and to express different ideas. C++ is all about machine level details, but when the problems you are dealing with have nothing to do with those details, C++ can actually become a hindrance.
Sometimes you just want to process text and numbers at face value (instead of as char arrays, and numbers as objects with bit limits and sign issues). Sometimes you want 8 to just be 8, and not a representation of a 32-bit unsigned integer. Sometimes you want to deal with words and phrases, and not character arrays or strings. There are languages that can hand C++ it's own ass in these areas. That doesn't mean C++ is bad. It's just not what C++ was designed for out of the box, and it can't express those ideas as neatly and elegantly.
So it turns out that the best tool for the job is to use a C++ to solve the system level problems, and host a virtual machine to handle the actual game. The engine can then be small and fast and focus 100% on it's area of responsibility.
The scripts can be executed quickly, changed on the fly, without recompiling anything, and won't introduce bugs into the executable. The scripts also add almost infinite possibilities to what an engine can do. It's a win/win situation.
An engine will take 10,000 objects in a scene and do a quick collision detection pass on them. It will then generate a list of collision events, and hand them off to ->
The scripting engine, which will handle collision response. A script will fire and it will know which object it collided with, and have a data structure passed along with all the other relevant information. You object can now bounce, disappear, turn green, blow up, play a sound, trigger another event, generate code on the fly, or whatever else you come up with.
The engine does the detection because it's faster, it's technical, and it's standard behavior, not needing flexibility.
The script handles the response because it needs to be flexible and open ended. Most scripts will be dealing with event reactions, which are rules, and not technical details. These are not 'c++ / system level' problems.
Also, why do gameplay programming positions require expertise in C++?
It's an industry buzzword, and a C++ programmer can easily learn any other language. A C++ programmer will have experience dealing with systems on the low level, and can be switched around to different tasks with different amounts of required technical expertise. There are many different tasks in programming a game.
You may join as a scripter and only ever write lua/C#/java/python/etc scripts. However, when that task is complete, it's nice to be able to do other things, or you will become redundant when they don't need anymore of those scripts written.
C++ deals with the machine at a very low level. It's easy for a C++ programmer to jump into any higher level language and be somewhat productive immediately. Because it's all the same concepts, but you don't have to be as specific, and don't have to manage memory. It's harder for a someone without C++ knowledge to jump into C++ because you suddenly have to know how to think in terms of memory management and being specific.
I never said not to learn C++. I said it's not required to make a good, fast, game, and certainly not desirable to find a C++ only engine. You can use an engine and create tons of successful games without ever needing to write a single line of C++.
Yeah, that inventory stuff is all simple programming. It is just a list. Complex ideas do not mean complex programming. Everything you mentioned is just a few lines of code attached to different events that reference that list. The code will more or less look the same in any language.