Convert this to use resources instead of scripts.

[Shadowblitz16]

This would be nice if it used custom resources to define blocks, biomes, and terrain. Right now it looks like it hard codes logic in gdscript.

[Zylann]

Maybe. It's not how I designed it though. It was a lot less work to do it the current way. I have no plan to make the blocky game demo a perfect template for making all kinds of block games, it's more like a basic testbed where I experimented a few things, which I open-sourced because why not.

[Shadowblitz16]

@Zylann can you at least implement a resource style generator following something like this? https://www.redblobgames.com/maps/terrain-from-noise/

I am still trying to implement it but I can't figure it out.

[Zylann]

I understand how useful you think that could be for a quick basic terrain ready to use, but I have other plans at the moment. Really you should either find someone doing it or learn how to do it yourself. It's not particularly difficult if you mostly stick to height-based/2D combinations of noise, and very often having your own system you get the best control. I didnt know about that linked tutorial, but it looks quite detailed. Terrain generation is also widely covered elsewhere like YouTube.

[Shadowblitz16]

ok maybe I can ask someone else

[Poikilos]

@Zylann I'm curious, what are the plans you have (if not terrain from noise loaded as resources)?

[Zylann]

@Poikilos just other things I'm doing on my free time, not particular plans regarding this demo specifically.

[Poikilos]

Ok, so if someone made a different game (other than voxelgame) using godot_voxel, they could probably manage to implement the feature without change to godot_voxel, or would this require changing godot_voxel?

[Zylann]

Depends on what "feature" you mean considering that this is very broad, but one can totally create some kind of framework on top of the voxel module, which would expose high-level stuff to make a game similar to this demo. This is kind of what this repo did, although it is done in code, and now it mostly serves as a testbed than a framework.

[Poikilos]

I am very new to the engine but I was considering something similar to the OP, just to see how far I could get, and have been following both repos. You seem to indicate in your reply that someone could do pretty much anything with godot_voxel they want, but for clarity I'll try to explain what I (and probably Shadowblitz16, correct me if I'm wrong) would like to do:

• "terrain" generating additional chunks using noise: Maybe even reading Luanti (formerly Minetest) chunk data from sqlite or at least resources for now. The main point, though, is persistent worlds with discreet chunks that could potentially be zipped & transferred over a network for multiplayer.

And using one of the Lua implementations for using Luanti mod scripts (I assume as "resources"):

• "biomes" defined by Lua (define terrain generation callbacks)
• "blocks" defined by Lua (Node definition says what texture to use, what level of what tool breaks it, & callbacks)

Of course, barring something fully moddable with callbacks, JSON resources (rather than Lua) would be a minimal example (but terrain chunks are larger, so a binary format like Luanti's seems efficient, especially zipped).

The above features would be a somewhat familiar way (as in, the well-trodden path of Luanti API) for "terrain", "biomes" and "blocks" to be changed without changing the compiled game executable. That would provide an API for modding, similar to what is desired by users of Minecraft (which is tethered to Sisyphus-like re-hacking of every new release), of Luanti (which is tethered to C++ and ill-maintained Irrlicht, and which doesn't do much better than Minecraft at providing a stable API except minetest.org and MultiCraft, both which have worlds that seem to be consistently more popular than minetest.net's servers especially U.S. ones).

So the feature (multiple features, really) is that not only the persistent world data but also the block & biome definitions are all separate from the binary. I appreciate your responses and don't expect you to make such large features especially if it is to test godot_voxel. Hopefully if I can accomplish any of this in a different voxel game/fork I can help contribute improvements to godot_voxel. I just need to understand godot_voxel better to know whether code contributions to facilitate a different voxel game like that would be welcome, and to know whether any changes are even necessary on the godot_voxel side. Do you think so?

[Poikilos]

Hi, I edited my comment to make clear that there is a question at the end. This issue may need to move to godot_voxel if it is not planned here, if any changes are necessary there to facilitate such features.

[Zylann]

I don't know what to answer tbh. This is broad/high level stuff, and the question is broad too (or just assuming too much?). The module is not a Minecraft engine, it does not implement high-level stuff, and isn't even dedicated to block games (it is not a Luanti-like, it's lower level than that). It is just a base toolkit that contains whatever I experimented with so far, which may or may not help you. I implement things in such a way they can be configured, I usually don't hardcode things. Separating block and biome definition from the binary (do you mean the game's executable?) is up to you when you make your game. For example nothing prevents you from reading this from a file instead of a GDScript. This demo hardcodes in a script because doing otherwise was more work and out of scope, though if your concern is the ability to change config files, you can see anyways how data-driven it is. It is not really the job of the module I'm making to dictate how elements of your game are specified. And this demo is just a demo amongst others, not a foundation upon which everything must be built from. There are of course technical constraints depending on what you use, but data isn't hardcoded, what you can change in the editor can still change after export. If you want to use JSON files to define everything in your game, then write scripts that parse them and use the voxel module to setup some features you need, and other features of Godot for other things eventually.

[Poikilos]

Yes, by separating metadata from the binary I mean the game executable (or build environment in general), so that the game can be defined/modded without recompiling/changing gdscript.

I think you have answered the question better than you think, since that file contains the desired behaviors, and you say replacing it with metadata is possible.

Therefore, using "custom resources to define blocks, biomes, and terrain" is possible, and so are block definitions I've mentioned as the file also contains those. Since godot_voxel is low-level enough it seems clear then there is also no issue on the godot_voxel side. It these are features which someone could make using godot_voxel, so it sounds like this is resolved at least for me (unplanned in voxelgame, but possible to make with godot_voxel). Thanks.

[Poikilos]

@Shadowblitz16 show me what you have so far and maybe I can help. Fork it?

[Shadowblitz16]

@Shadowblitz16 show me what you have so far and maybe I can help. Fork it?

I deleted the project, but it was really simple as I didn't know what I was doing really. The idea though was that I could export graphs as resources and edit properties from there in the inspector. I was also wanting to be able to use other resource types in the graph.