I recently thought about how one can make big worlds for example for an open-world game. In general the game world is one giant level (scene) divided into several areas (chunks). But you can’t just have everything loaded at the same time due to memory and performance reasons.
That’s why I am interested in how to create such big worlds. In my opinion, I can’t just use the SDK or jMonkeyBuilder because I think it’s difficult to handle such big scenes (memory, performance). I used the SDK for my current game scene which is not that big and even that seemed to became difficult sometimes.
Would I have to create my own application for editing such huge worlds or does anybody know of some technique how this can be done? Sorry if this is a noob question but I am pretty new to this field.
I think a good start would be to just make it in-game using some sort of level editor system. Basically flycam and place/move stuff around.
The benefits would be that you can see if the scene is too intensive in real time and works in terms of physics and other game mechanics without having to exit some outside editor and load it up in the game itself.
There’s just the work of making a saving system that logs these objects in a way that you can then generate them from code.
The bonus is that you can then also easily include it into the final product as a modding tool.
Okay, I think this would be the most tricky part… (implementing all the level editor features like in the SDK for example)
Yeah, but this seems doable
What do you think about the terrain? Would there only be one huge terrain or several “smaller” ones? I don’t know how it is done in such games, I am sorry…
Hmm well depends on what kind of features you want. Something like spawn at cursor and move/rotate, set coordinate vector and such should be fairly straightforward. Stuff like copying entire areas less so I suppose.
Can’t say I know that myself, I’ve very limited experience with anything terrain wise, but I’d imagine two general ways it could work:
large terrain chunks like you mentioned
have the entire terrain data in some “database” and update the current terrain as you pass through it
I found the key to be not using physics myself. I went from loading just a hundred or so physics objects destroying fps to thousands with millions of vertices when not using it.
Am able to load 4 512x512 areas with no fps drop at all. Can path find over a thousand simultaneous long distance moving objects (at over 750m distances) and take a 50% fps hit (drops to 30fps). This is with a intel i3 with onboard graphics though so I hope to get more out of a headless server.
Just now implementing core game code so I hope things work as well afterwards.
My initial idea was to use noise function to generate procedural terrain and construct TerrainQuads using jme’s terrain system.
Following this tutorial
But it had several limitations and was not suitable for my game.
After seeing this island in Sketchfab
New idea bloomed in my mind !!
To use cubic chunks ( Terrain Blocks) which can be jointed together or can be connected using bridges.
This gives me the flexibility I need, can dynamically construct terrain, let players reconstruct it in game ( Crafting mechanics).
And terrain data can be handled with an Entity System and saved on server side database.
Also I can use TerrainLighting material to support texture splatting on terrain blocks.
I managed to create a large world out of many small scenes by making my own simplified version of the terrain grid. I could never figure out how to get the official Terrain Grid to work, so I wrote something similar that pages a grid of scenes based on a 2-dimensional array of asset key Strings that are used to load a scene when the player is close enough. It also smooths the terrain out on the edges where two scenes meet so you could never tell I’m using more than just one terrain. This solution obviously wouldn’t work if you want to generate random terrains on the go, but it’s been an effective solution in my case where I’m creating a large, static world that is always the same each time you play.
So in my case I’ve found using many small terrains to work well, but I guess I can’t say much about the rest of your question in regards to more advanced level design methods. I’m still just using JmonkeyBuilder and the SDK editor to design my scenes and terrains. When I want to make my level bigger, I usually do a quick sketch where I draw a grid and outline what I want the new areas to look like, and then I go into the editors and sculpt a few 512x512 scenes based on my sketch, and finally I stick them into their correct (x, z) location in the arrays of Strings that represents the scene grid.
My big project is designed for handling enormous multiplayer game worlds. (These are tricky without multiplayer - with multiplayer it’s downright nasty at times.) In order for your world to scale indefinitely large, you must chunk ALL data into separate, reasonably small pieces, including terrain. Terrain is tricky because it’s continuous across chunks. Most entities you can just stick in one chunk or another (depending on what side of the chunk boundary the center is on), but you don’t have that luxury with terrain. There’s a lot of good information on the web about how to handle terrain boundaries, but they pretty much all boil down to either (a) paging terrain chunks (TerrainQuads in jME) and joining all the meshes at the edges into one big mesh, or (b) paging the chunks and then dropping “skirts” down at the edges to hide any gaps caused by the seams. (b) is definitely simpler, and some projects have achieved quite good visual results with it, so I’d suggest you start there. If the skirt technique is too much of a pain to get looking good then you can deal with stitching terrain quads together.
