New answers tagged

1

One common reason is that it isn't always equally easy to determine if a resource is going to be needed in the near future. Since you used terrain paging as an example, I will continue with that. It's perfectly reasonable if you're in a given map grid to load all adjoining map grids in the background. You know the user can, at best, enter one of those. ...


2

One reason dynamic loading isn't always the ideal solution that other answers haven't really considered I think is also pop-in and other graphical artifacts. The prediction of what to load and what not to load often fails, and it can be a detracting experience when it does. One of the worst examples of this was in Rage by id Software. At least in the early ...


1

This is a common issue stemming from the fact that games are soft-realtime products, where a late delivery of content is not as useful as an on-time delivery (contrast with hard-realtime, like the cars in computers, where a late delivery can be no better than no delivery at all). You have to decide what to load and where. Sometimes, the late deliveries are ...


2

Ultimately, it's limited resources. Open-world games and especially MMOs are heavily crafted toward predictability - you always know what data you need to load well in advance. You can see this in the architecture of the worlds - anytime there's a lot of resources that need to be loaded, you have some way of preventing the user from seeing the stuff that ...


5

A big factor in the feasibility of such a solution is the predictability of what needs loading. If the player loads entirely new levels with no way of anticipating what they will choose, a completely seamless solution is just not possible. For example, when the player may select any level in the game to play from, or if they have freedom to teleport to ...


30

The answer is yes, this could be done, in most cases, at least to some extent. The reasons it isn't done are many: It requires time and money to do it right. The amount of bugs that pass testing will be higher Load times are accepted by the users. There can be other reasons for load times, such as balancing server load. Generic solutions that can be ...


3

Time. You need time to save time. Or you need money to make up for the lack of time. In any case, "No loading time!" is a feature that only those who have the luxury to afford it can offer. It takes very careful planning, and you need to understand very well what you're doing and not all game developers have the resources to put on it.


10

If your menus have a ton of assets, those assets take time to load. You also have no idea what order people will navigate your menu. They could click options -> back -> credits, or credits -> back -> start game in rapid succession. So there's no reasonable streaming strategy. In an open world game, you know the player won't move faster than some certain ...


7

It depends on whether this happens during development or release. During development, you will have all kinds missing things, errors, and fuck-ups, constantly, all the time, and you may even want to "hot" load assets on demand or replace an asset while the game is running. You might edit scripts with the game running to test an AI performs better, or ...


12

Byte56 mentioned one option. There is at least one other: Assume default values and display a Warning. Depending on the nature of your data, it might be perfectly acceptable to assume some default values and warn the user that "since file xxx failed to load, we are using a generic yyy object."


45

Log an error and gracefully exit. Ideally, display a human readable error on screen as well. There should be a core pipeline of hard coded functionality that operates without these data files. It's the same pipeline that loads the data files in the first place. It should be capable of detecting when these core data files are corrupt or otherwise faulty and ...


-1

Forget about PlayerPrefs. Serializing your game data will be more secure and more inline with OOP practices. For WebGL builds you'll need to interact with the browser by calling the JavaScript method SyncFiles(), but that can be done completely within your project. I detail the process HERE, including source code and error handling.



Top 50 recent answers are included