[HN Gopher] Nebula is an open-source and free-to-use modern C++ ...
___________________________________________________________________
Nebula is an open-source and free-to-use modern C++ game engine
Author : ibobev
Score : 139 points
Date : 2024-01-09 13:29 UTC (9 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| shortrounddev2 wrote:
| This looks cool, but I always wonder why we see so many game
| engines and not a ton of open source rendering engines. People
| could do so much more with 3D indie game dev with just a
| rendering engine and maybe PhysX, then they could define the game
| logic any way they want without having to use the specific entity
| component system or whatever paradigm of an entire engine
| TillE wrote:
| You can do this with nearly any game engine. Ignore whichever
| pieces you want and use the lower-level APIs.
|
| I used to use Unity with a third-party 2D framework that
| bypassed all its game object stuff.
| JKCalhoun wrote:
| When I was looking about last year I eventually settled on
| SDL2. It had everything I needed (for a sprite-based game)
| and was low-level enough that I didn't feel like the game
| mechanics were baked in.
|
| Still happy with it.
| novagameco wrote:
| Yeah I think there are tons of graphics frameworks for 2D
| with no built-in entity management system (SDL2, Monogame,
| SFML), but it seems like when people work in 3D, they tend
| to make an entire engine. I think people would be less
| mystified by 3D if they could just plug in a 3D PBR
| rendering engine and then implement game logic any way they
| want, in any language they want (e.g: have bindings to a
| rendering engine coded in C++ but the game logic is all
| python, lua, C#, whatever). I think Three.js actually is
| kind of like this, but idk how useful it is for updating
| real time games. There's also always Ogre, but I just
| wonder why there aren't more rendering engines out there
| AHTERIX5000 wrote:
| Neat list of features but what about asset pipeline? How can I
| take stuff from material editor or Maya into Nebula? There are
| lots of engines with interesting features but with very thin
| content pipeline. Having worked on engines and games it's often
| the pipeline and tooling in general which makes engines great
| even when there are others more capable in terms of renderer
| features.
| flohofwoe wrote:
| Wow, Nebula on HN. As the original author of the Nebula engines
| it's absolutely astonishing and heartwarming to me that the
| University of Lulea 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 Skelleftea 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!).
| darek wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| "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 wrote:
| 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 wrote:
| 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.
| ecshafer wrote:
| 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.
| dualogy wrote:
| Nice, another candidate for my current still-ongoing engine
| checking-out journey!
|
| Looked around the space recently with a focus on "Linux-usable,
| C++-able, Vulkan-able non-abandoned/non-rather-too-outdated
| engines today" (license unimportant in _my_ search) and came away
| with: Unreal 5, Flax Engine, Godot (C++ story shaky / WIP, C++
| is not a first-class game-dev scenario here AFAICT), Wicked
| Engine. (There's more out there that I ruled out for this or that
| reason and thus forgot about by now.)
|
| Top candidates for me ended up being UE and Wicked, the latter
| currently preferred due to my actual (somewhat foggy/fuzzy =)
| code-first & code-mostly use-case idea. UE5 has way more
| batteries-included but it feels heavy and presses your C++ coding
| into a cage of its various de-facto-required macros, the whole
| setup seems to throw off both major VSCode extensions for C++,
| and its hit-or-miss hot reload thingie. Everything very geared to
| its authoring environment, understandably. But I really just want
| "engine as a linked .so library" here for my stuff..
|
| (By Linuxable I don't mean Proton/Wine, but actual compiled-
| for/compileable-under-and-for Linux.)
| _shantaram wrote:
| Holy crap the example footage on Wicked's site looks so good!
| I'm blown away.
| Capricorn2481 wrote:
| It does? I'm not sure what it is about that footage that
| seems mind blowing
|
| https://wickedengine.net/
| dualogy wrote:
| Mindblowing might be an overloaded, underdefined term
| but... the homepage top is a series of vids and if one
| bears through the anime stuff, one comes to rather fine
| terrain/foliage, weather, sky / volumetric-cloud
| renditions. Maybe that was meant above. It's all not
| readily myFavoriteAaaGameClone.Run() but at least it's
| quite wildly capable as far as the whole rendering-
| capabilities landscape nowadays goes.
| klaussilveira wrote:
| Wicked is amazing and the author is such a great lad. Consider
| donating: https://www.patreon.com/wickedengine/posts
| bellgrove wrote:
| Have you considered not using an engine at all, in favor of
| libraries? There are many amazing libraries I've used for game
| development - all in C/C++ - that you can piece together:
|
| General: stb https://github.com/nothings/stb
|
| 2D Phys: box2d https://box2d.org/
|
| UI / Editor: imgui https://github.com/ocornut/imgui
|
| Platform: SDL https://www.libsdl.org/
|
| Engine: Quake https://github.com/id-Software/Quake
|
| Ok, Quake is more of an engine than a library - but it is well
| documented & widely used. Even many current day AAA engines are
| still originally based on the Q1 engine (though, of course,
| heavily modified over the years to stay modern).
|
| I don't mean to bring down anyone but I feel like game engine
| announcements are a dime a dozen these days. As someone who has
| worked in the industry I'd favor putting together my own simple
| engine based on libraries for smaller scoped projects. Most
| open-source engines, I presume, are not really going to be
| battle tested, well-supported, well-funded etc. There are some
| exceptions of course (like Godot). If your goal is too complex;
| why not just use UE5 or Unity? Epic has been in the industry
| for a long time, Tim Sweeney is a really smart guy, and the
| engine has been widely used in AAA and indie games.
| ensignavenger wrote:
| Check out O3DE too.
| gumballindie wrote:
| > Godot (C++ story shaky / WIP, C++ is not a first-class game-
| dev scenario here AFAICT)
|
| Godot C++ here - works fine so far. I use C++ for the heavy
| lifting and GDScript for gluing things together. Pretty stable,
| and the engine compiles in minutes (needed double precision).
| C++ game logic compiles rather fast. Since the engine is
| written in C++, that language is right at home.
| hotdogscout wrote:
| How do you use c++ in Godot?
|
| GDExtention?
| gumballindie wrote:
| Indeed:
|
| https://docs.godotengine.org/en/stable/tutorials/scripting/
| g...
|
| You only need to make sure your extension API file is in
| sync with any "main" engine version upgrades. And for major
| upgrades godot-cpp.
|
| Everything compiles really fast in both Linux and Windows
| and dependencies are easy to set-up.
|
| However, there is little C++ documentation but that is
| because once you get the gist of using their Ref<T> wrapper
| everything is intuitive (functions and methods map one to
| one from GDScript). Just download their example and have a
| look around.
|
| Also the engine's code is _very_ easy to follow if you get
| stuck and can itself be used as samples.
|
| I am really rusty (even rust can be used btw) with C++ and
| was able to pick things up quite fast.
|
| Let me know if you have any questions. But really all I
| needed to start was their example above.
| hotdogscout wrote:
| I've been using SDL 2.0 + GLAD because I thought Godot
| was iffy with c++, I'll try following their example.
| Thank you so much.
| TillE wrote:
| > Also the engine's code is _very_ easy to follow
|
| This is one of the best parts of Godot, it's small enough
| to compile pretty quickly, and simple enough that you can
| jump in and understand the code and debug any problems
| with minimal friction.
|
| The maintainers are also good about quickly accepting
| small bug fix PRs.
|
| And yeah, the development experience with GDExtension is
| now really nice, though it's best to do a little work to
| set up a CMake project rather than relying on scons.
| justin66 wrote:
| What games using Godot have you released?
| jncfhnb wrote:
| Hot reload basically just doesn't work. Prototype in blueprints
| and do hard calculation, replication relevant stuff, and
| algorithms in cpp.
|
| But the batteries included are almost always useful. If you
| don't really know what you're doing, you're likely to make
| something that sort of works but fails to consider edge cases
| the engine designers have dealt with other time through trial
| and error.
| capl wrote:
| It has a 90's Pixar look to it, which is cool
| bastard_op wrote:
| That's not at all confusing with Slack's Nebula.
| https://github.com/slackhq/nebula
| flohofwoe wrote:
| Development of the first Nebula engine started around 1999 (as
| 'Nebula Device', later shortened to Nebula2 and Nebula3). I
| doubt that Slack was around at the time ;) (IIRC the only name
| collision we were aware of was some American rock band)
| yazaddaruvala wrote:
| Clearly great work by the Nebula team, thanks!
|
| That aside, looking at the whole game engine "market", I'm
| surprised that more game engines in 2024 don't talk about or
| differentiate on their net-code.
|
| Syncing the physics sim between multiple clients and the server
| is one of the hardest problems in gaming today.
|
| Are there any game engines or state management frameworks for
| game engines that really stand out?
___________________________________________________________________
(page generated 2024-01-09 23:01 UTC)