I was wondering what the “C” button was for. I suspected ‘Copy’ but I couldn’t figure out how to paste it (and didn’t see the ‘Paste’ button). Thanks!
WorldBuilder wish list:
- Be able to ctrl-click (or somesuch) and return an attribute value to it’s default
- Support for a few different lighting models in visualizations (direct overhead, low on the horizon, etc.) - or maybe a slider to move the light source across the “sky” (maybe just in the “final world” viz.?)
- “Undo” functionality (mentioned above)
- More obvious water coloring in “final world” visualization
- When deleting an element in the designer, a pop-up dialog giving the user the option to deleted sub-elements
- Weather configuration
- Noise function to randomize substrate and decoration “minY” and “maxY” attributes (to create randomized edges)
- The ability to “fly” around the world when locally play testing in order to survey the world more easily.
1 Like
Ctrl-clicking does this I think (or some modifier)
1 Like
Great to know, I’ll give this a try. Thanks!
Most of these are new and some have been mentioned above. I just wanted to capture these in a single place and expound upon some of them.
Common Biome Configuration Elements
The ability to attach a Substrate, Strata, Decoration, Plantations, Ores and Lakes elements to multiple biomes (currently have to copy/paste and keep these synchronized if you want multiple biomes to share element configuration).
Cave Visualization
The ability to visualize caves with a translucent substrate overlay (i.e. - a “Deposited World” visualization with solid cave voids and translucent everything else).
Cave Configuration Element
The introduction of a Cave element (like Substrate, Strata, etc.) to which you can apply a 3D noise map and fiddle with attributes to join the solid parts of the 3D noise map with thin tendrils. The idea here is to generate a 3D noise map with solid blobs “floating” and disconnected and then arbitrarily join these to make a more conjoined case system. I’m not sure if this would be possible or how difficult it would be, just an idea. Other attributes would be 3D noise maps to apply to the joining tendrils to make them more natural and introduce some distortion, etc. For example, here’s a 3D noise map with decent cave sizes but a lot of them are “disconnected” and, therefore, not easily discoverable:
There may be techniques in designing 3D noise maps that would result in what I’m looking for, but the above seems a little more user-friendly maybe?
Designer UX Enhancements
- The ability to provide an attribute numeric value by typing the value in (to be more exact).
- Support for multiple designer windows (tabs) that would simply allow the user to focus on a different area of the world configuration. I think this may make moving from biome to biome easier.
- Be able to ctrl-click (or somesuch) and return an attribute value to it’s default (mentioned above)
- “Undo” functionality (mentioned above)
Visualisation Enhancements
- The ability to choose one of a few lighting models; direct overhead, horizon light, movable light source, etc. (mentioned above)
- The ability to reset the camera position (both in regular and “Fly” mode).
- Block collision in “Fly Mode.” This would be especially useful when trying to navigate cave systems. Maybe be able to turn collision on and off? (the need for this may go away once we are able to play test worlds)
- The ability to define a custom color for any block being rendered.
- Only list blocks that are currently being utilized in the world.
Mac OSX Stability and Bug Fixes
The WorldBuilder tends to crash a lot on the Mac OSX platform. Also, copy/paste does not currently work.
3 Likes
Great feedback, thanks!
You can currently do this by leveraging the sum function to merge multiple noise functions. (But agree; this could definitely use some UI love!)
It’s a bit fiddly, however. Remember: noise functions have an initial range of -1 to 1, so you typically want to remap your inputs to 0…1 (or -1…0, depending), sum them, and then remap back to the desired range.
For an example of this (albeit with 2d noise), take a look at the heightmap I used for Kovah’s desert biome in order to get those basalt pillars. The rivers in the jungle biome use a similar technique, too
1 Like
I assumed all noise functions generated values from 0 to 1. I didn’t know this, thanks! That helps my understanding and expectations a ton.
I’ve played with products and summing but only a little. I can see how this would achieve the results I’m looking for. I need to play around with a 3D noise that looks like worms.
Love Kovah by the way. One of my favoritee worlds - the forests are beautiful and those channel rivers, awesome. Great work!t
1 Like
Yeah, it’s thoroughly confusing until that tidbit of info surfaces 
Take a look at the cave noise for Kovah too (global noise) 
Thanks!
1 Like
WorldBuilder Resource Utilization and Visualisation Size
While using the WorldBuilder on Linux, with a relatively large world (large for me anyway - 5 biomes with heightmaps, substrate, strata, plantations, and ores for most), the application only uses 1.7GB of RAM. I mean, that’s a lot of memory, but with 16GB of RAM available it doesn’t seem like a lot.
After generating a “Final World” visualisation (and increasing the generation size to “64”) the memory increates to 2GB:
So, in short, it doesn’t seem like these types of visualisations take a lot of memory. The CPUs peak, but that’s expected:
I was thinking it might be good to have the option of rendering a much larger area for visualization. Just to be able to easily sample the variability (or repeatability) of the world. Looking at a generation size of 64 may look great, but in-game it begins to look like the “Land of Lakes”, etc.
Maybe there could be an option to render a world up to 1,024 in size which would take roughly 2 minutes and use about 5GB of RAM.
TL;DR
If possible, I’d like an option for something around the 256 or 512-chunk(?) generation size.
1 Like
@james, @lucadeltodecso, @ben (et al):
I’ve been using the WorldBuilder a lot today and here are a few things that I run into a lot and I would consider high on my list of enhancements to the tool.
- alphabetize blocks in lists (everywhere)
- be able to configure a climate and be able to see this while play testing (I’m not even sure if the server hosting the test world supports this)
- provide an option for increased visualisation as mentioned above (with the caveat that it is resource and time intensive)
Thanks guys, I’m loving the tool and I have a few worlds I’d like to submit to you guys for some feedback if you have some time.
The World Builder comes in 3 parts:
-
The Editor - allows a user to construct the “shader” used when generating worlds.
-
The Generator - knows how to execute the “shader” to generate a world in chunks.
-
The Pre-Generator - this tool knows how to orchestrate the generation of an entire world (via the generator) including all chunks at different LODs.
The World Builder we’ve released only includes #1 and #2. The Pregenerator is an app (script) that runs around everything.
Whilst we can increase the generation scale in the World Builder, it doesn’t include the additional logic for creating the LODs. Ideally, the tool would easily handle everything.
Should be trivial.
Eventually all world parameters will be exposed into the WB: weather, creature spawn stuff, sky + lighting, audio sfx, etc.
Possible - also considering the LOD issue above.
1 Like
Idea:
The WorldBuilder is great at defining a single type of world. Different climatic and geographic regions make up an entire planet (world). The “problem” I find (and it definitely a “first-world” problem - pun intended - as this tool is already AWESOME) is this: when I try to cram many types of geographic features into the world, things start repeating too much. It would be nice if several different worlds could be stitched together somehow.
What if the Pre-Generator was altered to work with several different world configurations (each the same size in chunks) and was provided world distribution criteria in the form of a noise map and numeric criteria (much like a single world’s biome distribution system using ‘altitude’, ‘temperature’, etc.) and was able to blend these worlds together as the player moved from one world configuration-sized area to the next?
That way you could define a mountainous world (“A” below), a watery world (“B” below), and an arid desert world (“C” below), making sure these three worlds had the same substrates, ores, strata, etc. (or maybe not) so that they would blend together nicely.
That way a single world could have radically varying areas, each lovingly designed in detail in the WorldBuilder. This would make for greatly varied game play within a single world. I’m not even sure this would be a ton of development work (LOL, what do I know?), except for the world blending piece, but you could seriously go to school on the biome blending logic already in-place in the WB.
This was just a thought I had when realizing that sometimes, building features into a world made for unwanted repeatability. For example, this repeats very nicely: the ice planet of Hoth (or some such):
When this repeats, it looks good, natural. You have some planes, a few hills, etc.
However, when I add a cool mountain feature, again this looks good:
But when this repeats I get too many mountains (at least for what I’m trying to achieve in my world - I mean, mountains tend to clump together as a geographic feature):
This was just an idea I had while playing with the tool.
1 Like
For some reason, when defining layered substrates, I can never put clay on top of dirt. No matter what order I define them in the “Substrate” element, dirt is always on top of clay. Is this by design?
Also, just to clarify, the substrates are in reverse order top-down, meaning the top-most substrate should be on the bottom, right?
I’ve thought about this slightly differently - but I’m wondering now if I’m overlooking something.
Biome Creation Project
I’ve been planning to propose + host a biome library creation project for months - but wanted to wait until we’d released in the in-engine visualisation. Where everyone is invited to build, iterate, and tweak a large library of different biomes. We’ll also update the World Builder to accept configs from the library. We can then distribute the biome library with the game + world builder.
This means that new users can simply create new Worlds from a diverse library of biomes. Whereas power users can use the library as a starting point, before further customising them or creating additional unique biomes. [I have a standard list of 50+ biomes, before we even start getting creative.]
Biome Granularity + Control
However, this proposal was based on the granularity being the biome itself, and each new world would mix them together via the global Biome Distribution noises. But I’m beginning to think that to create an interesting “Biome” it is really achieved by mixing a collection of sub-biomes via a specially prepared biome distribution noise. (What you appear to be proposing.)
As a result, you’re asking for an additional layer on top of this biome distribution for selecting between your Biome Collections.
To clarify, the current model supports:
- The Standard global Biome Distribution selects between Biomes.
However, you’re asking for:
- The Global Biome Distribution selecting between a selection of Collection Biome Distributions. (Where each Collection Biome Distribution is a carefully crafted blend of biomes.)
Comment
I would have to discuss this with @lucadeltodecso to decide what is the best approach - given my ambition for a library feature whilst also achieving interesting sculpted / crafted worlds.
@lucadeltodecso is on holiday this week - so don’t expect any significant responses from him.
4 Likes
This is a question for @lucadeltodecso - it might be built into the tool - potentially because we put grass on dirt(?).
1 Like
Woop Subiomes have been on my wishlist since the second time I used the world builder.
As I Understand It
Today the WorldBuilder creates a world configuration which is comprised of many biomes. That is where the granularity stops. The PreGenerator then takes the configured world, loads it into the game and displays the world for the player. When the edge of the configured world is reached, the PreGenerator can simply “wrap” the player around to the opposite side of the configured world. Alternatively, the PreGenerator could generate a new instance from the world configuration and seamlessly joins the existing world with it (ad infinitum).
How I Understand Your Proposal
What I hear you proposing (which is very similar to what I am proposing above) is that the WorldBuilder would create a map of a world comprised of multiple biomes (newly-termed, meaning something different from what it does today). A biome is comprised of sub-biomes (which are what we think of as biomes today). This world configuration map could be predetermined ("put biome “A” here, put biome “B” there, etc. in a grid fashion) or it could be provided with biome distribution noise to select biomes based on distribution criteria.
I think some of the strengths in the right architecture include:
- the configuration stays in the “world” configuration file and the PreGenerator can be coded to simply react to what is configured (limited world size with edge wrapping, or infinite size)
- introduction of the “sub-biome” creates a “biome” layer that is complete enough to represent diverse geographical regions which can be productized in the library you talk about above
- “worlds” generated by the PreGenerator can be regionally diverse and would feel more like a real world
I can see creating a library of hundreds of these new biomes (“Arid Canyons”, “Wetland Hills”, “Wetland Flatlands”, “Snowy Mountains”, etc.) and aggregating those to create a map of a world that the PreGenerator can use to generate the game world. Can you share the names of some of the biomes on your list so I can get an idea of how you are thinking about those?
Is there any concern that resulting worlds would be anywhere from 20 - 80KM in a single dimension instead of the existing 4 - 8 KM as today? With players strewn across the world, a server may need to hold many parts of this large world in-memory at one time. The “world” would also be sufficiently large that a player would need some sort of transportation to successfully circumnavigate.
4 Likes
Not quite…
The PreGenerator is a script that knows how to execute the Generator with a world config to pre-generate (build) a region of (or all of) a world. The Generator always does the generation. The Generator is a standalone lib + tool built into the Editor. The client app and server app both don’t know how to generate worlds. The server can be configured to call the Generator if some of the world is missing - but we by default only allow the generation of a flat world for memory / stability reasons on the live worlds. The PreGenerator knows how to orchestrate generation (by the Generator) of all the LODs and run everything across many cores. For example we normally build worlds on a 32 or 64 core machine.
Also it’s the Generator (again) that knows how to wrap the generation of worlds. The game server knows how to wrap the simulation of the world.
To be honest - we’re talking about a few different modules that we could just consider as features (or components) of the World Builder in general. The architecture (whilst interesting) is a little irrelevant to the user.
Yeah - (again we’re discussing all this in @lucadeltodecso absences but) - as you suggest the New Biomes (eg. Arid Canyons) are built out of a collection of “Land Formations” / “Biome Parts” / “Old Style Biomes” / whatever. This is simply because you’ve / we’ve learnt that to achieve interesting biome generation you need to mix + composite a few different biomes.
It’s possible that @lucadeltodecso will agree that we need this higher level to craft what we really want. Or alternatively, we might want something at a lower level where it’s easier to control the definition of the height field. Ultimately this will come down to - do we need an extra level of control for just the height map - or all the different biome features.
Again your text is miss using the PreGenerator - sorry for being misleading in my initial explanation of it.
This isn’t a concern. Yes generation is expensive. But the server only holds in memory a circle of chunks + entities surrounding the active players. The main limiter is the # of concurrent players on the server. If the world is too large then there will be a question about how sparse players are populated. Also would we prefer players to explore a single world? Or explore other worlds? We can do both…
But ultimately the tech for a 4km world is identical to a 400km world.
Your biomes are more descriptive - my current list is taken from geological sources, ie. real biomes in the real world. But what I’m most interesting in are the creative biomes that we make, for example: Floating Island Lava Falls, Crater Field with Forests at the bottom, etc. Things that don’t exist in the real world, but would be amazing if they did.
3 Likes
Please, train the World Builder to use unicode characters.
1 Like