I spent some time on a tool that could import basic excel formulas for a project that ended up getting cancelled.

Yeah... I considered Lua, but I didn't see the advantage of Turing-completeness for RPG scripting. I've done that with Javascript, in JS games where everything's exposed, and I ended up systematizing everything for consistency's sake. Not using all that power. Stuck with JS syntax oddities.

So I went with a fixed-function DSL. It's just data. You could definitely use a spreadsheet.. CSV would be convenient. One reason not to: spreadsheets tend to mangle your data. For example, a new version has different defaults for unicode. At least I can trust my text editors.

• PS2 dev kits were expensive and only core engine devs had them. Scripting could be done without dev kits.
• Build times for C++ on any reasonable sized project will add up in lost time.
• It's easier to hire someone with lua experience and for people to find resources to learn.
• A lua script was a way to reduce memory instead of having all the C++ loaded. It's easy to forget that that C++ code is always loaded and taking memory. Sure you could use dlls if you wanted but who really wants that?

On the programmer productivity point, you're assuming a situation where the game programmers spend a lot of time in both languages and hence have to interop a lot. This may often be the case, but in the Lua-based console games that I've shipped, Lua has been the primary language for the game codebase, and C++ the primary language for the Engine code-base. A gameplay programmer could go an entire project without writing any C++ code at all (and vice versa for a tech programmer) -- so the dual language + interop penalties only applied to a small number of the staff, for the small periods of time where they were working on the game/engine API boundary... Or when optimizing gameplay code by porting it to SPU jobs - but such work already requires the type of programmer who can juggle 6 abstractions at once while trying to strip them all bare

If your project requires knowledge of both languages then you likely have a design problem. The interop/glue layer is usually solved by one guy and never talked about again. You think it's bad when a someone comes and asks you questions about lua, wait until they ask about your DSL.

Since that project I haven't done anything without lua. The biggest downfall is that the tools for debugging lua aren't at the same level as C++. Nothing is perfect but I think you under estimate the work involved in a DSL and the amount of work it will continue to demand.

Really you take lua and make it domain specific. The idea of creating a whole language is ridiculous. The fact that you have deployed several successful games using a DSL needs to be taken with a grain of salt also. I bet if you asked different members of the team you will get different answers. GTA3 was pretty successful from what I heard and the scripting for it was god awful. This is in no way a dig against the people that wrote it as I highly respect what they did but the DSL didn't contribute to it's success in any way.

Also putting effort into something like lua gives you the ability to use it on the next project with a new domain. I use it for my build system, batching operations on assets, basically anything not C++. For me lua gives variables, flow control, maps and the ability to call into C. Just the right amount of glue anyone would want. Why write a parser and then all the docs on how your DSL magic layer works. I have already shipped while you make your DSL.

On a hobbiest note, I've made some totally different experiences with scripting languages (mostly visual scripting with c++).

First off, our graduation project for university was programmed in 3-4 months with 4 programmers. We were using Unreal 4, which uses both C++ and their visual blueprint system. I could probably write a separate article about this, but even though we had a lot of interop (base classes in C++, specific abilities/behaviour/UI in blueprint), we had almost no issues with it and I can say that we would have never been as productive if we had eigther only C++ (I just imagine how painfull it would have been to implement the UI purely in C++ with like 100 minor changes per day with 1 min+ compile/start time; plus doing things like selecting assets in the script code per drop down was a real time-saver), or only Blueprints (having C++ for base functionality like a base player class with overridable methods is very important too). So the mixture of both (visual) scripting and C++ was an enormous advantage here, even though to be fair that might also be accountable to how phenomenal Unreals C++ script bindings are (you can inherit from C++-classes in script, and pretty much use all your C++ methods in script without handling the script binding yourself).

The other case is my own, where I have developed my own visual scripting system similar to Unreals'. I'm using it currently for porting a game that was written with Rpg-Maker which had kind of a DSL with their "event system", for stuff like cutscenes, NPCs etc... Now apart from that my new scripting system allows me to be more productive in comparison, I also cannot imagine how it would be doing this in C++ (a new class for every NPC that does something special in a scene? Yuk). Now I have too little experience with modern DSLs that I can pass any judgment on whether or not I would be more productive for specializing behaviour and cutscenes in comparison to my visual scripting system, but I can't imagine that it would be much better for my cases. I hope I'm not too biased towards my own work, at least in direct comparison to the Rpg-Maker it fairs way better...

So yeah, take it with a grain of salt, I obviously lack much professional experience and am therefore only talking about limited-scale projects in type of manpower (the game I'm porting is an 10 hours+ 2D action Rpg, so I would at least consider it medium-scale). Just thought I'd leave that there anyways.

I think the DSL approach has a great deal of merit, and gets far less consideration than it should. Part of this may be that C++ isn't a great language for implementing DSLs, at least not embedded ones (BTW, are we talking about embedded or external DSLs?)

I don't think using something widespread as a scripting language (say, Lua or C# or even Ecmascript) is all that bad if done well, but its definately a larger liability than I think people realize. I might go one further and say that the apps that use scripting most-successfully fall into two categories -- one where the API surface of what's essentially a DSL anyways happens to be expressed in/through teh scripting language, and a second like has been said where its really only the inner-most core of the engine and the scripting interface are written in the host language, with all gameplay logic implemented therein (even some of the lighter-weight traditional engine components, perhaps). In the case where its really just the expression language of the DSL, the extra expressiveness afforded by the scripting language itself really is a liability, useful as it may be at times to expedite solutions to unanticipated needs.

I do tend to agree though that for small teams, scripting probably is not the best solution. The people likely to be wearing the scripter hat are also likely to be wearing the coder hat as well. I think most "designers" on indie-scale teams are probably either competent coders, or would be better served by tools that have no need for Turing completeness. Full-blown scripting langauges seem to me to only be a defensible proposition when it enables teams to scale up, and when people have more-discreet roles.