Nebula was the tech that I watched very closely and it inspired me a lot. It was back in the ancient year of 2000, if I remember correctly, when our game was being published by CDV and I just learned about Project Nomads, based on Nebula. Beautiful engine and I loved the clean, simple and extensible architecture.
I would love to have such tech nowadays, but focused on 2D/light-3D mobile games :)
The most interesting design detail in Nebula1 (the close connection between C++ classes and Tcl) was also its biggest problem in Project Nomads.
A lot of Project Nomads consisted of Tcl scripts which directly called into C++ class interfaces exposed to Tcl. This was extremely flexible, but also put too much power into the hands of gameplay scripters which came up with hair-raising workarounds for missing features in the C++ code heh.
Another design wart was that we also closely integrated Tcl into the asset pipeline (e.g. you could attach small Tcl 'scriptlets' directly to Maya 3D objects which then would be evaluated during the asset export). This means we had to carry a small Tcl interpreter in the Maya plugin all the way to the end even though the actual engine long had dropped any support for Tcl scripting.
Project Nomads scripting left such a deep scar that I removed all scripting features in Nebula3 (which the gscept/nebula version is based off, although I see there is some Python support under addons/scripting), and I remain a big sceptic when it comes to integrating 'scripting languages' into game engines. A probably too extremist pov.
TL;DR: don't expose your low level engine APIs to scripting, and don't use the same scripting API for persistency and/or asset pipeline file formats, it will inevitably end in tears ;)
"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.
Oh god. On the one hand this idea of carrying scripts on maya objects to be run on asset pipeline sounds really cool from a technical standpoint. BUT this also sounds like a project maintenance nightmare.
I probably share many of your extremist pov on no extension scripts because I have seen weird build time, and pre-run time scripts cause a lot of issues in projects.
flohofwoe|2 years ago
A lot of Project Nomads consisted of Tcl scripts which directly called into C++ class interfaces exposed to Tcl. This was extremely flexible, but also put too much power into the hands of gameplay scripters which came up with hair-raising workarounds for missing features in the C++ code heh.
Another design wart was that we also closely integrated Tcl into the asset pipeline (e.g. you could attach small Tcl 'scriptlets' directly to Maya 3D objects which then would be evaluated during the asset export). This means we had to carry a small Tcl interpreter in the Maya plugin all the way to the end even though the actual engine long had dropped any support for Tcl scripting.
Project Nomads scripting left such a deep scar that I removed all scripting features in Nebula3 (which the gscept/nebula version is based off, although I see there is some Python support under addons/scripting), and I remain a big sceptic when it comes to integrating 'scripting languages' into game engines. A probably too extremist pov.
TL;DR: don't expose your low level engine APIs to scripting, and don't use the same scripting API for persistency and/or asset pipeline file formats, it will inevitably end in tears ;)
HelloNurse|2 years ago
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.
kencausey|2 years ago
Another hazy memory is that I contributed to an early reference manual for Nebula. I probably was using the name 'nikos' at the time.
ecshafer|2 years ago
I probably share many of your extremist pov on no extension scripts because I have seen weird build time, and pre-run time scripts cause a lot of issues in projects.