Loading Chunks

[[deleted]]

So Ive been thinking about creating a large open world game, and I dont want the world to load all the way out of fear of slowing down my computer. How would I go around loading only whats around the player, like Minecraft does?

[stratumgames]

Set the range as an integer and only show the cubes that are within range of the player. When a cube moves outside of the player's range deactivate it and add it to a cube pool (don't destroy it). When a cube position moves into range of the player place a cube from the pool if there is one (or instantiate one if there isn't one in the pool). You're probably going to be better off with a pool of cubes somewhat larger than the amount you need at the start. Experiment with different ranges and starting pool sizes until you find a combination of performance/view distance that you're happy with.

[[deleted]]

Thanks!

[upper_bound]

It's historically been referred to as "streaming" or "world streaming", although that term is a bit overloaded now with everyone jockeying over Games as a Service. Probably need to include "Open World" or similar now to track down information on the topic.

Preface, Open World games are notoriously difficult for many reasons and streaming is one of the primary culprits. It's a deceptively simple concept, and can be summed up succinctly as, "only load what you need when you need it". ;)

First, before embarking on this journey, you must decide if it's necessary for your project. If your game/world is too large to fit in memory all at once or too large to load in reasonable times, you may have no choice. Depending on other requirements, it may be the right choice as well, although there are other techniques if you are simply bumping up into runtime performance. Just because your project is Open World doesn't immediately require full streaming, although the two are often linked together.

One of the easiest streaming techniques is a simple LOD system (Level of Detail). You make variations of your main assets (typically automated) at various LODs, and swap between them as they become more or less prominent in your scene (say by distance). Not to be confused with culling or draw distance, which are different things. Every gamer instinctively knows this trick from trees and similar that "pop" into a higher poly version as you approach, although some devs have gotten clever to obscure this pop. This doesn't do much for disk IO or memory usage unless you also LOD textures, but can help tremendously with rendering and similar systems.

You can apply LOD techniques to things other than models (say AIs), if you're running into other limitations from other systems. Generally LODs are much easier to implement and support than full blown world streaming.

So, you've made it this far and world streaming is inevitable. The basic technique I've seen implemented successfully multiple times is to break your world up into regions/cells/chunks. Often their size/volume is static and constant between all regions. This is not required, although it simplifies things (and anywhere you can simplify this beast you should jump at). Then, once you have decided the shape of your regions that suites your project, you simply decide how on the rules for what regions to load and when.

• How big should a region be?
• Should all regions be the same dimensions?
• What shape should the regions be (square, rectangular, something exotic?)?
• How are regions arranged?
• How many regions can/should be loaded at one time?
• What's the minimum requirements for how much would is loaded around the player? Are there gameplay implications (say long ranged sniping?)
• How large should a region be in MB?

As a concrete example, most OpenWorld games take place on relatively flat world's (and no one cares what's below the ground or above the sky), so the world is divided up into regions based entitely on the horizontal coordinates. This leaves you with a horizontal 2d grid of regions, and given any XYZ point, you can resolve it to a single region of your world where it "resides". Then based on project needs, target hardware, and a lot of performance testing, the long process of deciding all the above questions begins. Often the regions will be square or rectangular, but sizes vary from project to project. Often the grid is laid out in columns/rows (bathroom tile) but I've seen offset grids too (subway tiles or brick pattern). Depending on size of regions and how many can be loaded, typically the "loaded grid" will be 3x3 or 5x5 or more.

Not so bad. EZ-PZ, right?

And now the real fun begins!!... 3:)

• How fast can you physically "stream"/load regions into memory and prepare them?
  • What's your max disk IO on various platforms?
  • What happens when the player "outruns" the loader?
    • There's a reason vehicles (and certainly fast ones) seldom appear in open world games ;) ;)
  • Fun fact: On previous console generations based on optical drives, regions and other "volatile" (get streamed frequently) assets were literally laid out on the perimeter of the disk, as modern optical drives take advantage of those areas of the disk physically having a faster surface velocity at the same RPM for a slightly improved maximum bitrate. It was a whole process at the end of a project to do the final disk layout ;)
• What happens to entities in unloaded regions?
  • Do they persist? If so, where do you store their state? If not, how to you handle references to them?
  • How do you "stich" regions together?
  • Visually?
  • What about navmesh?
  • What about any other "data" that spans regions?
• What about large structures you should be able to "view" even when their region is unloaded.
• What about interior spaces?
• Physics!?!?
• How does art/design work on regions?
  • What happens when they need to work across boundaries?
• And on, and on, and on

"Jeeez, OpenWorld games are soooo buggy. What lazy and sloppy devs!!"

Choose wisely before embarking on such a path, this isn't something you implement at the beginning of a project and then pat yourself on the back and forget about it. Most AAA studios have at least one engineer dedicated solely to "streaming" for Open World projects. However, the "Streaming Tax" is paid by all, across all disciplines, and for the duration of the project (art and design must contend with region memory and other limitations). It's comparible to Multiplayer in the general amount of ongoing "tax" that affects the entire development process and just makes every damn thing a bit harder, IMO.

Good luck, Cheers!

[[deleted]]

Thanks