3 ms·

Wow, Nebula on HN. As the original author of the Nebula engines it's absolutely astonishing and heartwarming to me that the University of Luleå has picked up th

Wow, Nebula on HN. As the original author of the Nebula engines it's absolutely astonishing and heartwarming to me that the University of Luleå has picked up the (open source) pieces and developed it into something so much better and more feature complete than the "inhouse Nebula" ever was :) I still remember when I was visiting Skellefteå around March (? it was still deep winter up there though) 2010 to meet the students doing some pretty damn impressive game projects with Nebula even back then and on that same day I got the call from Berlin that our company (Radonlabs) had finally to file for bankruptcy. Massive props to Johannes (who moved on AFAIK) and Gustav (who just added D3D12^H^H^H (oops looking at the source it's Vulkan!) raytracing and meshlet support - how crazy is that!).

kaffeewolf 3y ago
[dead]
Gustaph 3y ago
Thanks Andre! Should also give some cred to Fredrik who's been working on the entity-component setup on the game side.
darek 3y ago
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 :)
- flohofwoe 3y ago
  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 ;)
  - kencausey 3y ago
    Thanks for confirming that Nebula originally used Tcl. I considered posting to ask but was not confident in my memory. Another hazy memory is that I contributed to an early reference manual for Nebula. I probably was using the name 'nikos' at the time.
  - HelloNurse 3y ago
    "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 3y ago
      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.

kaffeewolf 3y ago

[dead]

Gustaph 3y ago

Thanks Andre! Should also give some cred to Fredrik who's been working on the entity-component setup on the game side.

darek 3y ago

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

flohofwoe 3y ago
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 ;)
- kencausey 3y ago
  Thanks for confirming that Nebula originally used Tcl. I considered posting to ask but was not confident in my memory. Another hazy memory is that I contributed to an early reference manual for Nebula. I probably was using the name 'nikos' at the time.
- HelloNurse 3y ago
  "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 3y ago
    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.