(please close) best approach to very large world?

Hello, I’m planning to make an online RPG, and the world will probably be quite large.



There will be one central server to which all clients connect. The world will be stored on the server (to prevent hacking) and the clients then download from it what they need.



Should I use a “chunk” system similar to the one Minecraft uses?



What would be the best approach to this?



PS: Some basic explanation will be enough, I’m not even sure if the game will ever be published.

@werner291 said:
Dynamic, sorry.


Yeah, I was just clarifying.

For dynamic terrain you really have your work cut out for you since you will potentially have to swap out terrain "chunks" where the player is standing. It makes things a little trickier.

Is your terrain dynamic or static?

Static Dynamic



EDIT: Didn’t realise up to what point it would be dynamic.

Is your game going to be a downloadable package or web based?

There will be one central server to which all clients connect. The world is stored on the server (to prevent hacking) and the clients then download from it what they need.



The client is an application located directly on the user’s computer.

When its static the client has its own copy of the terrain the server too. Collision and stuff is computed with the servers version on the server… Entities which are dynamic are sent only when the player is in a specific range of it and stuff.



Thats the usual way i know.

@KuroSei: Thanks for the tip, but I apparently got a server-client terrain dowloading system to work (far from finished), and I actually like it that way. (No tampering, copying, hacking, with the local world files, etc…).



However, my original question was about if I should use a chunk-based system or not . (Like Minecraft) Should I?

That won’t prevent hacking but you are welcome to do it that way. You will just spend a lot of time transferring terrain data. The only way to prevent hacking is to have the server be authoritative for all things important. The only thing keeping the data on the server gets you is that clients won’t know terrain that they don’t have.



If you already have a terrain downloading system then surely you are partitioning the world somehow. If not, then yes, you will want to download the world in pieces. Whether you call them chunks or not is up to you. Unless you mean something more specific.

Btw: Even if the client doesnt have the terrain as a file… The user can still manipulate the information it gets. I dont c the advantage to send the static terrain to the client and not let the client store it.

Even if you make sure the client cant manipulate your software or the processing (which you cant if you ask my inproper opinion :D) … the client can still manipulate the visualization due to DLL injections and stuff. (Saw a very nice DirectX hack once where one could add Blur effects and stuff to very old games by injections. Dont know how it worked, though… )



If the terrain is dynamix i agree that the server should send the stuff (and even here i would use some buffering/caching for performance sake… but with static terrain? Why?

I’m also wondering about this. I’m about to start working on a singleplayer game that will probably have a large static terrain. Will the Level of Detail-technology allow my to have really large terrains without worrying about performance?

@WASD said:
I'm also wondering about this. I'm about to start working on a singleplayer game that will probably have a large static terrain. Will the Level of Detail-technology allow my to have really large terrains without worrying about performance?

Yes, TerraMonkey (in particular the TerrainGrid class) will load in terrain tiles as they are needed and apply LOD techniques to them to improve performance.

I said that my terrain was static, but I’m suddenly quite sure that it’s going to be quite dynamic, now that I correctly realize what that means.



Ok, so let’s say I’m going to divide the world into chunks and that the server will load/unload them when they are needed/not needed.

In my current system, every chunk is a Node that contains a TerrainQuad with a single TerrainPatch. How should I modify it?



My current system looks like this: (I guess it’s quite ugly right now, I’m not experienced with working with terrain)



rootNode

mainScene (Node)

Chunk-0-0 (Node)

Terrain (TerrainQuad)

TerrainPatch

Chunk-0-1 (Node)

Terrain (TerrainQuad)

TerrainPatch

Chunk-1-0 (Node)

Terrain (TerrainQuad)

TerrainPatch

Chunk-0-2 (Node)

Terrain (TerrainQuad)

TerrainPatch

(etc…)

Static = the mountain that is there today will be there tomorrow and the next day and so on.



Dynamic = the mountain is there today but may be a pile of rubble tomorrow.



Most games = static terrain



Minecraft/Mythruna = dynamic terrain

Dynamic, sorry.

Is it possible to create an empty TerrainQuad and add TerrainPatches to it manually?



Or does this require a custom terrain class? Or can multiple TerrainQuads be used in one scene?

Use TerrainGrid, and assetLinkNodes to attach data to each tile.



You never want, nor can you have, a terrain quad with a single TerrainPatch. If you are modifying that code you are doing something wrong.

I’ve been looking at http://code.google.com/p/jmonkeyengine/source/browse/trunk/engine/src/test/jme3test/terrain/TerrainGridTest.java



But it apparently can’t find this package: “com.jme3.terrain.geomipmap.grid”.



If I try “Fix Imports”, my computer just gives me an impolite “PING!”.



Does TerrainGrid require any external packages?



EDIT: I just read through the source code of TerrainGrid. It looks remarkably similar to my own system.

Don’t need anything fancy for terrain grid, it comes with jme3.

Maybe try checking out the latest trunk version from SVN. It is the most stable and up-to-date.