MY REASONS FOR A SCRIPTING LANGUAGE
In my attempts at making the most professional products I could, I knew performance and ease of development was important, especially with just myself doing all the work. To achieve this for myself, I needed complete control over what I created. I moved away from pre built game engines and built my own. I also came to the realization I needed to develop tools and editors. I moved into this area of programming by building a collision detection editor (similar to a level editor), which gave me a taste of how tools and editors enhance develop - both in reducing time, complexity, and increasing quality. After having this editor for collision, I then was determined to make getting actions into my game simpler. What did this mean? Well, actions are just instructions done on data. Changes in data. So, I needed a way to simplify and speed this process up. Another benefit in setting something like this up would be for playtesting my games. If I ever wanted to make changes, or add abilities to anything in my game, I'd have to spend much time implenting it in C++, not to mention making sure what I added didn't break something else.
CONVICTION AND DETERMINATION ARE IMPORTANT
So my reasons were clear enough to me that I could see the benefits of doing this work of creating something that would streamline coding, and I could see that it was essential and well worth my time to do it, based on my goals of proffessionalism that I was shooting for. This "importance" placed on my endevour was important in knowing and feeling, especially when you're spending time on something that could, at some times, feel like you're never going to see the end of - like not seeing the light at the end of a long tunnel. Or going down a rabbit hole you didn't dig (although in actuality it didn't take that long).
ENOUGH BACKSTORY...
Before moving on to how I implemented scripting into my engine, I'll just say that, only after I had made the basics of this system did I realize, by definition, I'd made a scripting language. It seems my language would be categorized under "Byte Code", as I parse text and turn it into a strip of bytes that trigger something in my engine. That's the barebones, simplicity of it. It is also possible, by some definition I don't know, that what I'm doing here isn't scripting. So whether or not you personally think this is or isn't scripting is alright with me, but I'll refer to it as such in what I describe.
...AND A DISCLAIMER
Personally I enjoy creating stuff not in a guideline (although I'm doing something of that sort with this writing - ironic), and if I'm told or given specifics of what to do, I often get bored and uninterested. So if you are like me, you probably don't care to read this. But, in attempts of not ruining all the fun if you are like me, the point of this writing is not to give details, but to suggest to you (the reader) more research and one possible way that something like what I've done can be implemented. If anything, proof that the basics of it really isn't much. Basically, there is a light at the end of the tunnel, and it's not that far off from the entrance.
The last of the disclaimer is that I'm self taught (albiet, scavaging data on the internet when needed), so if what I suggest or express is obvious or "off" based on the "world's" terminology of something similar, please overlook it (it just so happens this reason is what has prevented me from writing much of anything before).
Thank you for your understanding.
THE PROCESS IN A NUTSHELL
Already touched on, the overall concept is for the engine to read in an external file (something that was easier for you, the developer, to write/create - it could be text or whatever you wish to help ease or visualize your intent) and then for the engine to interpret that data into something the engine understands and can do in its own way.
Ideally, what you are providing/writing/creating would in some way be simpler in comparison to what the engine does. You very well could, if you wish, make what you provide more complex, but it would defeat the purpose and point of creating a scripting language. You may not start with such a horrible intention as this, but it could very well develop. So I suggest knowing what exactly you want to speed up, or could speed up, or make easy, in your development of a game, and then craft your language to suit that need. As an example, for me, one thing I needed to be able to do to help production was to be able to add and remove variables with absolute ease. And doing something like this was not suitable in my engine's language (in my case, C++), so it was a prime target for me to simplify in my scripting language.