Hey guys,

Definitely going to be a regular here...

Anyway, for my game I'm looking into seamless maps. Not sure if its the correct term but it basically means I don't have any loading screens or map transitions.

I'm wondering on different theories to get this working.

My first thought would be to load nine maps,

1 2 3

4 5 6

7 8 9

Assuming the player is always in 5, when it moves to 6 it will be done like this

2 3 10

5 6 11

8 9 12

But drawing this code would mean accessing different variables and be a ballache.

Would it be better to made load them, but just replacing number 5s end lines with the next map?

Any reading or theory on this would be much appreciated, any language is fine but C# is preferred.

Thanks guys, I feel like I'm really over thinking this.

Should mention that this is also a 2d Tile Map

For open worlds like this, if it helps, don't think of it as a single terrain. Re-imagine that the world is composed of hundreds of tiny little grids, and each grid can be loaded or unloaded individually. Don't name items as globally-visible addresses, have them as part of their individual grid. Most data gets isolated or addressed based on its grid.

At any time you might load up 16 at a time. Or 25 at a time. Or some other number, a few are active and a few are not.

If your system is set up for modular worlds it doesn't particularly matter which chunk of world you're in. Yes, it is a little work to build the systems, but in practice it isn't that difficult relative to other development tasks. Prefetch the ones that are nearby and being approached, discard the ones sufficiently distant.

Even better systems (I've worked on a few) will detect the visual impact each node has from the other nodes, and prioritizes them accordingly. A mesh off in the distant may become important because it shows a mountain, a different mesh of flat terrain may be unimportant because it doesn't adjust the scene.

Trying to provide C# code for your game's world doesn't make sense here, because your game and your game's logic and your game's building blocks will be unique to your code.

But drawing this code would mean accessing different variables and be a ballache.

Why is that part a problem? We should discuss how you currently manage your map right now, and we can suggest improvements to make it flexible enough to handle this.

You can optimize 3D graphics by dividing the world into one model per 20x20 meter tile. All static items in the same tile have their triangles merged into the tile model. This reduces the number of draw calls when you have thousands of low detailed static items. The tiles are also useful for distance culling by not drawing distant tiles. Do not try to shift the world coordinates according to the screen since it will make it hard to refer to places in the AI. Define one system for the world and write conversion functions between world and screen space. If something changes in the tile model, delete it and show the separate instances to trade render speed for rebuild speed until changes are done and a new model has been generated for the tile.

This system can allow fluent high resolution voxel carving in .NET when compressing the voxels in each tile using axis aligned integer boxes.

If using sprites in 2D, the same can be done with multiple layers of image buffers or depth buffers in each tile. When a static sprite changes, redraw the affected tile images. If adding sprites on top, just keep drawing on the tiles.

I'm looking into seamless maps. Not sure if its the correct term but it basically means I don't have any loading screens or map transitions.

The term "open world" is also used, but can also mean "go anywhere, do anything, at anytime".

To avoid confusion i prefer the term "seamless world".

First off, if the world is small enough,you can fit it all in RAM at once, then just load the whole shebang at program / game start, and you're done.

If its too big for that, you split it up into what's commonly referred to as "terrain chunks". A section of the the world map (usually square), which is loaded or generated as needed into a "chunk cache" - a memory pool. Chunk size varies by title. Caveman 3.0 uses 300 foot (~100 m) chunks. A chunk basically contains all the info you need for drawing and collisions for that part of the world map, plus info required to implement least-recently-used (LRU) discard of old chunks.

For example, a "terrain chunk" in Caveman 3.0 consists of:

1. a list of 25,000 renderables max (trees, rocks, plants, etc) including 4 interleaved ground meshes (one per texture tile).

2. 1 instance buffer of 22,500 verts, and 5 instance buffers of 7000 verts for drawing instanced plants,

3. a 2D collision map at a resolution of 1 foot.

The list of rendrables, the ground meshes, the instance buffers, and the collision map are all generated in real time on the fly from underlying data. The underlying data consists of a world map, with squares 5 mile across. this determines elevation, vegetation, and water. Elevation and water are used by the height map function, which is used to generate the ground meshes. vegetation type and generic "plant maps" (implemented as sparse matrices) determine the location of trees and rocks and such. Instanced plants use a generic "pattern map" to determine scale, rotation, jitter, etc based on their location n the chunk. When an object is added to a chunk, its also added to the collision map for that chunk. The entire world is randomly / procedurally generated. The same sort of thing can be done with a static hand edited world paged from disk.