3
\$\begingroup\$

My troubles

I've been trying to create a game engine but since I am not well experienced in C++ I am having trouble deciding on how to load new scenes efficiently level by level or just an open world.

Example

Recent games are heavy, Most populat games are about 40 to 100 gigabytes but neither RAM nor GPU have that much memory at least Normal PC or Consoles.

So obviously most game engines pre-allocate enough memory to fit the scene and sometimes just tolerate some wasted memory but how would you decide how much is enough?

Possible solution

I was planning to create separate game loops, before entering the game loop I would load each level, then start the loop, thus I would be able to deallocate preceding level and then reallocate new memory for a next level.

Since I am new to the world of games and memory management my solution may sound rather stupid, But I need to know how to handle such situations efficiently.

\$\endgroup\$
  • \$\begingroup\$ Your multiple game loops solution doesn't sound like it would work for an open world game, since it assumes each level is played in isolation, sequentially — where you can never see the edge of the next level while you're still in the previous one. Is that a problem for the game you're making? If not, then "open world games" might not be the right target to learn from, as they've solving for a different set of constraints than you are. \$\endgroup\$ – DMGregory Mar 20 at 11:45
  • \$\begingroup\$ Sure, multiple game loop solution obviously is not suitable for open world games but I wanted to include open world option in my question for detailed answer))) \$\endgroup\$ – J.G Mar 20 at 12:06
  • \$\begingroup\$ If you want to get deep into the weeds, there was a good GDC talk on memory allocation systems for games a few years ago. :) \$\endgroup\$ – DMGregory Mar 20 at 12:18
  • \$\begingroup\$ @DMGregory Thanks mate :))))) \$\endgroup\$ – J.G Mar 20 at 12:25
3
\$\begingroup\$

Creating a seamless open world without loading bars is not an easy task. There are lots of small and large problems which need to be solved. This is not a beginners project!

The basic approach is usually to divide the world into sections and only load those sections which are around the player. When the player moves around the world, new sections and their assets get loaded from hard drive into memory and further away sections get deleted.

When you want a high view distance which would require you to load lots and lots of sections, then you usually load the further away sections in a lower level of detail. Simplified geometry, lower resolution textures and no simulation of any moving objects. When the player comes closer, those low-detail sections get replaced with high-detail sections. This requires that you have multiple levels of detail for every section.

The radius in which you load full-detail, mid-detail and low-detail sections is a question of memory budgetting. You should nail down early how much RAM you expect the end-user devices to have at least and how much of that RAM you can budget for the environment. Do a back-of-the-envelope calculation how much RAM a section will take in each detail level. After you implemented the first sections, confirm those assumptions through profiling. This should tell you how many sections you can afford to load at once.

When you target the PC or Phone market, then the capabilities of end-users devices can differ by a lot. So you might choose to make the quality level ranges configurable for the end-user. You could also try to detect how much RAM the users device has and adjust view ranges dynamically.

It can be a good idea to move this constant loading, replacing and unloading of sections to a separate thread, so it doesn't slow down the main game. But now you need to deal with what happens if the player moves very quickly and manages to enter a section which isn't fully loaded yet. You could put the player in the low-detail environment, but this is going to result in a very poor game experience and game-breaking bugs. Showing a loading bar after all might be the better solution for this situation.

| improve this answer | |
\$\endgroup\$
  • 3
    \$\begingroup\$ In my experience, we'll often attack the budgeting problem from the opposite angle: assuming a fixed number of loaded chunks/LoDs based on our view distances, we calculate how much memory each chunk is allowed to use. Then our authoring and testing tools flag when any chunk exceeds that budget, so our level designers and technical artists can target them for optimization. \$\endgroup\$ – DMGregory Mar 20 at 11:54
  • 1
    \$\begingroup\$ @DMGregory Would you have time to go into further detail and write an own answer? I would be really interested in reading how you at Ubisoft handle that stuff in your open world games. \$\endgroup\$ – Philipp Mar 20 at 12:10
  • \$\begingroup\$ I'm afraid as a game designer myself, I don't have first-hand knowledge of the guts of most of these systems, particularly down at the level of memory allocation. I know the high-level theory, and some of the day-to-day outcomes like budget warnings in test builds, but I don't think I can provide a better answer than yours on this topic. \$\endgroup\$ – DMGregory Mar 20 at 12:12
  • \$\begingroup\$ @DMGregory I think your contribution to Philipp's answer would be great, I would be very glad to accept both of your answers and solution. \$\endgroup\$ – J.G Mar 20 at 12:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.