Now, if you're interested in the code concepts.
There was an article about large worlds and AI mentioned in Game Programming Gems 8. I'd give that a look.
=======================================
But code wise for Terrain Creation.
Essentially what you got is The world is broken up into tiles, or chunks in minecraft Lingo. Usually these numbers will be some number divisible by 2. Or a power of 2.
These tiles each have their own coordinate grid. This makes it a lot easier to create files to save these tiles. And load into them at any given point of time. This also should theoretically solve the floating point problem that older games faced.
Each tile is then laid out in a 2D grid of whole numbers. (X and Y).
Then finally, if the whole world is just one big thing put together. You can use an algorithm for coordinates.
World Position = (Gridx * Widgth) - GridX + (X position), Height, then same thing for Y.
To make holes in the world, you'd hold a list of vertexes that's supposed to be empty. Build the patch as if everything is supposed to be there. Then run through the list and delete them. Yes, it's actually faster this way, and has less problems than checking and skipping each vertex.
Height is controled by texture normally, but there's no stopping you from doing it in other ways.
=====================================================
For item placement.
This is where each terrain patch's local coordinates come in handy. If You have a world of 10000x10000, then you'd split them up into parts. As mentioned above, you got terrain patches of 100x100. Each patch has it's own little batch of information stored in a file or something.
Each entry has some information in it. Say a tree.
You got:
[Entity] Tree
[EID] 123
[UUID] 90er083422
[X] 13.24
[y] -23
[z] 40
[rotation]
Entity tells the engine the name of it for human debugging reasons.
EID tells the engine to load this entity from a database.
x, y, z are LOCAL positions according to the terrain.
Rotation is a LOCAL rotation according to the terrain.
Why local?
The CPU is stupidly fast at simple math calculations, and typically a lot of games do transformations in local space, then convert to world space in the end. This is no different here... and it allows you to rearrange tiles without a problem.
==========
For files
Pretty much anything goes. Though data that is needed more immediately should always be at the beginning. Typically you want all visuals to be before logic. You can distribute the load more easily this way without the result being jarring. Such as this order:UV, Texture, material, missing vertexes, Mesh Data, Navmesh, Actor data, Game logic data.
======-===
Distant Terrain.
The most common trick I've heard of is LOD, then rendering the furthest terrain to a cube map, and use it as part of the sky. For a few frames, or X distance
==========
For Skyrim style littering
AKA Player leaving his crap on the ground, and it being there for DAYS no matter how far you go.
It's a serialization trick. My method of approach would be. In the terrain data, have flags on items that can be moved around or picked up. Anything that can be moved, or picked up, needs to be kept track of once the game is loaded.
When the game saves (auto save is surprisingly a good way of cacheing and dumping unneeded data to disk), you write down the new data for the terrain tile. On load up, the new terrain tile data will be used and parts of the original file will be ignored.
