It sounds like a lot of interesting ideas. One thing I've always had trouble with is the availablitly of lots and lots of different libraries, scripts, languages, etc.
What I mean is this and this was actually also mentioned by Grasmann: it is of course possible to expand the capabilities of a project or a language by introducing libraries of function calls or scripts with a series of commands with the intent of making things easier, but often one ends up with thousands of additional commands to learn and to try and use and remember and a lot of bloat in their program that they may not need.
For example, let's say I knew there was a library that had a function call that made a matrix deform in real time based on some kind of impact. "Alright!" I think. But in order to get this one function up and running, I need to create a series of globals to pass to the function, the function is embedded into some kind of physics system that I have to make sure I initialize which may mean setting up a world for the physics system, passing the vertices and or faces of the matrix to the system, adjusting the gravity, etc. and etc. In the end, I almost have to learn an entirely new language or at least a whole new set of commands just to use that one function I thought I could deform my matrix with in real time easily.
So, this is what I caution against: try to avoid adding additional commands and methods that require a whole other series of commands, methods and or libraries. You may find that in the end, you only need one or two functions that you could have coded yourself without the extra complications and baggage.
You'll also find that the tools you may need are project based. It's very hard to try to make all encompassing tools that account for every scenario or game development type. Something mentioned above was the use of editors. I think this is a great way to go. If you can have editors for specific tasks that write the code you need that can just be plugged into a project, things may be easier. And the closer you can stick to native code with limited reliance on external non native libraries/plugins, the more adaptable your code can be.
And why write a new scripting language? Unless you are designing a specific engine and you want to be able to make simple calls to your engine, why not just stick to native DBPro code or use a seasoned scripting language like LUA or Python? In the end, isn't the goal to make a working game and not spend years trying to figure and test out the possible
ways of making a game?
Enjoy your day.
