Search Unity

  1. Unity 2019.1 beta is now available.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. We're looking for insight from anyone who has experience with game testing to help us better Unity. Take our survey here. If chosen to participate you'll be entered into a sweepstake to win an Amazon gift card.
    Dismiss Notice
  4. On February 28th the Feedback website will shut down and be redirected to the Unity forums. See the full post for more information.
    Dismiss Notice
  5. Want to provide direct feedback to the Unity team? Join the Unity Advisory Panel.
    Dismiss Notice
  6. Unity 2018.3 is now released.
    Dismiss Notice
  7. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice

Migrating from Resources/direct references for runtime asset loading

Discussion in 'Addressables' started by mStep, Feb 5, 2019.

  1. mStep

    mStep

    Joined:
    Sep 24, 2012
    Posts:
    29
    I'm looking for clarification on best practices regarding runtime asset loading for my particular use case (apologies for long post!):

    I have a large world that needs to be dynamically loaded around the player as they move. The game world is separated into "chunks" – literal square chunks of terrain – and the 9 closest chunks to the player at any given time are dynamically loaded (and unloaded as the player moves away). Typical open-world stuff.

    Currently, each chunk is loaded through an associated data folder. These data folders are stored in the Resources folder. A data folder for one chunk contains:
    - A scriptable object that holds a direct reference to the chunks' TerrainData asset
    - A scriptable object that acts as an "object manifest" - it stores direct refs to any prefab assets that will need to be spawned with that chunk (rocks, buildings, trees, etc)
    - A JSON file that specifies the pos/scale/rotation for every object instance in that chunk, along with that object instance's index in the manifest

    Only these data files are in the Resources folder; the locations of prefab assets and terrain data are currently irrelevant since they're directly referenced in the chunk data files.

    With all that out of the way: I was looking for guidance on whether or not Addressables should be something I consider adopting for this. To be clear, as it currently functions it is extremely low-friction for level designers. They can create prefabs from imported assets and organize them in the project however they want; they can easily edit chunks via terrain modifications/object placement, and the data files for edited chunks will be automatically updated through editor scripts; and the entire streaming/spawning system is functioning well enough to rapidly test without issues. My only concern is whether this system could introduce memory issues (or other unforeseen issues) as the number of chunks and objects grows, and if so, how I can adopt something like addressables while maintaining the relatively seamless level design process.

    - The asset manifest scriptable object for every chunk is in the Resources folder; these manifests hold direct references to every single prefab asset in the project; does this mean that every single prefab asset in the project is loaded simultaneously at runtime?
    - If Addressables are a valid (and preferable) alternative, how would they be organized? Currently, asset manifests for different chunks can hold references to the same prefabs (for example if an instance of desert_rock_01 is present in multiple chunks). How does addressables deal with duplicate references?
    - OR would it feasible to move away from the Resources folder altogether and introduce a "master manifest" object in the game scene that holds direct references to the data folders of every chunk? i.e. everything is done through direct refs, nothing is in the resources folder, no addressables

    Thanks for reading – I appreciate any insight!