[HelloNurse]

"gameplay scripters which came up with hair-raising workarounds for missing features in the C++ code"

Why did you fall behind with the "missing features"? What complications slowed down gradual rewriting with improved C++ components and smaller, cleaner, higher level scripts with less workarounds? I suspect inertia (the sunken cost of extant scripts) and cumbersome tooling, knowing more would be interesting.

[flohofwoe]

All from memory, so take it with a grain of salt:

In part it was kind of a vicious cycle, the dynamically typed scripting interface made it impossible to do any real changes to the C++ code, so towards the end of the project we were stuck between a rock and a hard place.

The scripting interfaces were direct mirrors of essential low-level engine C++ classes. Doing any changes to the C++ interfaces which were called by scripts wouldn't result in compiler errors but crashes at runtime.

Tcl scripts were also impossible to properly debug, and even performance profiling was kinda hard (most problems were not crashes or game logic bugs, but performance problems, where a script spent too much time in the script part and too little in the C++ part).

The *actual* main problem in hindsight was that we failed to think about and provide a proper "gameplay vocabulary" right from the start, e.g. identify and split the gameplay elements into small logic blocks which would be implemented in C++ and only combined / glued together via scripting. In typical arrogant junior coder fashion we mostly spent time down in the guts of the engine, and only paid little attention to the gameplay logic problems, that was something for the gameplay scripters to worry about.

Also, for the few 'senior people' on the team this was our second game project, and the first C++ project. And everybody else had no game development experience at all. We still shipped the game somewhat in time, so there's that ;)

PS: I guess the *actual-actual* problem was that I was a fan of "big idea" designs at the time ;) E.g. stuff like "everything is a Tcl-scriptable object", yes it might look elegant, but conceptual elegance only helps so much in real-world scenarios. It's much more important that a code base is malleable, and an entire game codebase built around a single "big idea" is usually not.

[crq-yml]

This kind of pitfall has happened a lot to new game engine developers(myself included) - the scripting language shouldn't be the engine, but at the outset, exposing all the internals 1:1 so that "anything is possible" is the obvious thing to do.

I now advocate, when the topic comes up, for the scripting to be strictly used as a configuration language: it can be used to initialize and pass data structures back to the engine, but it shouldn't be controlling the main loop. If you want it to define any specific runtime behavior like an AI policy, it's still more robust to make a targeted micro-runtime and have the scripting language compile to that.