Sign in to follow this  
xlad

Game terrain

Recommended Posts

I have thought about this for a while but i haven't found any good solution.

Let's say this is an RPG game (medieval, medium/high fantasy) in a client-server model (All game data is held on the server, and clients download only the necesarry things, like GUI, some textures,etc, and parts of the game map where the player is standing). The players' purpose inside the game is not only to increase it's skills/stats as much as possible or get better items/spells, but also to form guilds, build castles (or even cities) and become as wealthy as possible (through mining, crafting, trading etc). The problem is how the terrain is handled.

The player can dig the soil, flaten it, move it to another place, or he can dig through stone to make caverns, gather construction materials and so on. (Something like wurm/minecraft/dwarf fortress).
However, in these games, the terrain si simply made out of cubes (DF,MC) or it is only a height map but which also allows tunnels with a fixed height/width(Wurm). Is there a way to make it so it doesn't look made out of lots of cubes, but efficient enough to store large amounts of terrain without wasting too much memory (when using very large maps)? Or should i use the easiest way, using cubes like in minecraft ?(this means making a minecraft clone, and i do not want this) I am looking for a solution which allows me to procedurally generate the terrain on the server, and also which allows me to easily implement liquids (water,lava) and rivers (at surface and underground) and which is also good for player made constructions (houses, castles, walls, tunnels, dungeons, etc //not using some predefined building layouts).

Also, even if there is a solution with "cubes", the client can transform the data sent from the server and make it look more smooth based on the material of the terrain (the sand can be very smooth, while the stone can be quite "rough", like in minecraft, and dirt somewhere between).

I have looked abit on voxels, but i don't know what to say about it, if these are what i am looking for.

Share this post


Link to post
Share on other sites
However you want to do it, this problem requires volumetric data of some sort, and volumetric data very quickly grows as the scale of the world grows. Dwarf Fortress and Minecraft use cubes because this simplifies a number of things.

1) Amount of data. If you consider that one cube is 1x1x1 foot in size, then a chunk of world that is 32x32x32 in size is equal to 32768 cubes. Now, if you shrink the size of the cubes so that each is 0.5x0.5x0.5 then that same area of ground is now represented by 262144 cubes. Halving the cube size resulted in an 8-fold increase in the number of cubes required to represent it. Say you want each cube to be sized 1.5 inches (ie, each foot split into 8 divisions). This seems like a fairly okay approximation of "dirt", at least as far as a game might be concerned. You're looking at 16777216 voxels in that same 32 cubic foot area. A typical Minecraft game will have hundreds of these areas within sight. Not only is it difficult to render this kind of data in real time (it can be done, though; just takes a bit of programming) but now you have to worry about streaming this across a latency-riddled internet connection, on top of all the other network traffic that is already taking place (logic updates, etc...).

2) Simulation complexity: Simulating water-flow, updating falling blocks, etc... can be very computationally expensive operations that, again, explode in complexity as the density of the approximation increases. Just look at Minecraft for an idea of how difficult it can be to simulate fluid flow in real-time, even on such a coarse grid. The water and lava sources in that game do not come even in the neighborhood of reality. The simulations work, but to achieve a higher level of reality would require a lot more processing time consumed. Now, complicate it by the same exponential increase in complexity as the resolution is increased, and you are talking about a problem that quickly becomes intractable.

3) Rendering, lighting, texturing: A large cube provides a simple geometry primitive upon which to hang texturing info. Decrease the size of the cubes enough, and you need to switch techniques from texture-mapping cubes to techniques of higher complexity such as tri-planar texturing in order to color the landscape. Also, a lot of the atmosphere of such a game hinges very much on the lighting. Compare [url="http://morcrist.com/images/test1.jpg"]this[/url] shot (a random google of Minecraft clone turned up this image on the gd.net forums) with [url="http://1.bp.blogspot.com/_nI0f-eweUWs/TTrh9SiDmbI/AAAAAAAAACk/_6qISPlB_II/s1600/vuorenlapi.png"]this[/url] one (another random google). Which cave would you rather explore? Lighting makes all the difference, especially the ambient occlusion effect that Minecraft and good clones fake. Without this effect, caves look flat, stale and dull. And this is yet another area where the complexity and processing time of the simulation grows exponentially as the simulation resolution is increased.

So you have to weigh the pros and cons of any particular approach, and evaluate them in the context of things such as baseline hardware, available bandwidth for streaming, etc... Given your requirements, voxels would probably be your best bet, but you would still have a lot of fairly tall technical hurdles to clear in order to make it happen.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this