I understand why it's like that, but still, "real" rotating and moving in the voxel world wouldn't involve rotation of voxels themselves (just like how pixels don't rotate and move on a 2D screen when 2D objects are rotated and moved).
I absolutely love the per-voxel lighting. I can’t explain it but the specular highlights and sharp shadows give a really nostalgic feel. The GI adds just enough realism 😇
Simulating soft body voxels i think is usually hardware intensive. Minute papers had a video about a paper where people trained AI to handle the physics and made it an order of magnitude faster while being a very convincing fake simulation.
I'm working on building a modding system for Bevy. It's tough getting all the different parts working together, especially between wasm and the engine but very rewarding when it finally does. Great work!
nice webassembly hijacked the wasm name, from a native assembly compiler, lol. also your engine works like unreal engine visual coding with the mods. kinda. yep the mods are like visual coding system. xbox controllers are used often on pc games too. how about party animals, gang beasts or human fall flat style of physics game. also 3d worms style landscape pixel destruction game. or just 3d destructive landscape shooter.
Are you planning on allowing mods to add arbitary features to voxels? I'd really like to make a factory building game with only in-world crafting using this engine, so adding material properties like hardness and coatings is important to me. Dynamic properties like temperature, lifespan (for plants / animals), and electric charge would be a big plus too!
Did you have to build Nuke from scratch or did you read a map file and automatically transformed it into a voxel destructible one? Could be cool to see a completely destructible map CS experience
Right now, that model is taken from a Teardown mod. The mod creator made it by hand. That said, it is possible to voxelize 3D models/maps so that's something I might explore in the future!
Excellent video! I'm one of the developers working on the Bevy engine (also written in Rust) and I just love seeing other ways of tackling these problems. You've got something really well polished here that you should be proud of
Haha, I'm working on building a modding system for bevy in the same sort of vein. Had to rebuild the entire ecs from the ground up to do it properly from within wasm haha.
The calling convention for WASM methods uses the C ABI (with custom serialization logic that I've added, so any serde type can be passed across the boundary)
For my own game, I'm also thinking of going with WASM. I really like the idea of letting modders use whatever language they like, as long as it can be run on WASM. So C, C++, Zig. Rust, even GC languages like Python and C# could theoretically work. The only issue I can think of is how separate mods will link together - if mod A wants to call a function in mod B, how would that happen? I'm curious about how doable that is, although it could be really obvious since I haven't actually implemented anything yet.
you could have an interface that lets mods tell the game about functions they want to make available, and then other mods can query for them (disclaimer, I have no idea how wasm sandboxs actually work, so this may not be nearly so simple in practice, espcially to still keep them secure)
That's a neat idea! It was an approach that I wanted to try, too, but allowing mods in multiple languages turned out to be really complex. You end up needing to define a custom calling convention and type system so that mods written in different languages can call each other. There's a project called the "WASM component model" for this, but it turned out to be too complex for my use case. It's a very difficult problem to solve :)
@@DouglasDwyer I thought WASM had a defined standard calling convention. Since that's apparently not the case, I would probably just make a C api (traditional header files), and leave it to the community to make bindings for other languages. Most languages already have a mechanism to interact with C - Zig can even directly import C headers.
Okay but will a GUI covering the entire screen increase or reduce performance? If it affects the actual game and how it does stuff would conflicts occur, or would every mod having a GUI start to get real messy without a unified front for GUI handling (such as the crosshair getting added by lets say 7 mods) in which case I imagine GUI toggles for the GUI so you can have less GUI for all that GUI ... would be a good practice? Would a mod be possible to force all isolated GUI environments to replicate to itself and cull the original mods in order to organize? my brain hurted.
Great video as always. Are there any drawbacks to WASM’s usage of a separate address space? Just wondering why Minecraft mods use main memory if there’s a safer alternative.
Great question. There is a big drawback: it's much, much harder to share data between the engine and WASM mods. With WASM, if a mod wants to call an engine function (or vice versa) the only data that can be passed as arguments is binary arrays. You can't pass structured data (such as a tree of objects); it has to be serialized to a binary array first, and then deserialized on the other side. The "Rust macro magic" that I mentioned handles this for mod developers, so it's not a huge deal, but it comes with limitations. Basically, you can't persistently share structured data between engine/mods - it has to be copied back and forth. Like anything, it's a tradeoff. For what it's worth, Minecraft mods use main memory because: - Minecraft mods aren't officially supported, they basically hack the official game in order to run. So of course mods are going to access engine internals directly, as there's no other API exposed. - It's a lot easier for Minecraft to support modding in main memory since Minecraft is written in Java. Java is a JIT'd language whereas Rust is compiled in advance. Because Java uses JIT compilation, loading additional mod code at runtime and linking it with the main Minecraft code is much simpler.
In theory, yes, but that would require having an API that's compatible across languages. For now, I'm focusing on developing Rust-specific tooling (for example, the GUI library egui is Rust-specific) so that the development experience is as robust and streamlined as possible.
@@DouglasDwyerOh ok. I must admit my own raycasters engine uses a much much simpler scripting system (I made a custom assembly-style language interpreter in a program agnostic way that could be fed functions to use as "sysCalls") so I don't really know how it works with your system at that deeper level although I will definitely go and have a look at the code on your gitHub at some point. Either way, the entire modding system for your voxel engine seems amazing.
I'm reminded of a thing in minetest, where placing a large amount of voxels (called "nodes" in minetest) from a mod is often really slow. Not sure how much faster WASM is than Lua (and whether there's any JIT going on), but this might be something to look out for when designing more of the mod API.
There is JIT when the game is running on desktop platforms. But ideally, the API is designed in such a way that mods aren't placing voxel-by-voxel. Mods should be able to call a method like "copy voxels" and then the engine (optimized native code) should do the work.
Smart to integrate mod support early. You've mentioned that the end goal for your engine is a platform for game creation/sharing. Do you plan to allow users to create their own games primarily through this modding method? Or do you plan to have some sort of library or some other method.
@@frozein right now, my primary focus is to support game creation through the modding library! But, as always, this is a prototype. I've been thinking about a couple of other concepts for modding too (like using C#) and I might try exploring them eventually :)
@@DouglasDwyer Very nice. I'm curious though as to why you don't just release this project as a library, as this is the approach I plan to take with my engine. Is there an advantage to releasing it as a "game" with no gameplay that must be modded?
You raise a very good point! There are two reasons why it's not a library: 1. When I originally conceived of my engine, I wanted to build a "platform" (sort of like Roblox) where users could create their own games. For example, a user might connect to a server or open a world file which use mods. The user's game client automatically loads the mods (without any installation process) and they are able to play. This setup works differently than having the user download a separate game executable for every game built in the engine. It also facilitates monetization, since it's easier to charge end-users for buying a modpack than it is to charge developers for using my library. 2. Designing a generalized voxel engine is very difficult! My project isn't currently set up to be consumed as a library. I commend you for pursuing that route - but a rewrite would take a lot of time for me, and I don't know if I have the knowledge/vision to create such a library yet. At the end of the day, I think it comes down to having a "vision" for the project. I had a certain vision (originally) regarding creating a Roblox-style platform, although I fear the scope of that may be too big. I'm going back to school for the fall now, so I'll be taking a break from engine dev for a bit. Who knows? Maybe I'll change my approach - I would also be interested in a C#-based modding system because that has a lot of advantages over WASM. But I probably should try to finish one iteration of this project before starting another :) Thanks for commenting and good luck with your own engine!
@@DouglasDwyer That makes a lot of sense, the hot reloading feature especially is very useful for users making their own games. Sounds like a very interesting vision! And yes, trying to set up an engine as a library is very difficult, I've probably spent >50% of the development time on my engine just working on a solid API 🙃 Best of luck in school this semester! My classes start soon as well haha
