Nebula Device

The Nebula Device is an open source 3D game and visualisation engine written by the now defunct Radon Labs .

It has support for scripting languages (e.g. Tcl, Lua, Python).

It is available for download at SourceForge. The binary distribution comes with customized interpreters with built-in 3d capabilities, and some demos.

Try it out... it's impressive.

Nebula Device uses a special version of Tcl (MicroTcl). It is reduced to 36 commands for 160 Kbytes.

dbohdan 2014-12-26: The the original creator of Nebula Device has launched a new experimental cross-platform C++ game engine called Oryol . It has no support for Tcl or other scripting languages yet AFAICT.

m-nebula - medical graphic engine (also still be a game engine) used in therapeutic systems. Modification of Nebula1 game engine, originated by Radon Labs GmbH and continued and modified by InSightec Inc. Script support: Tcl and Python.

2024-01-12 : From Hacker News [L1 ]

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 ;)