---
# System prepended metadata

title: The Asset Lifecycle for Users
tags: [Assets]

---

# The Asset Lifecycle for Users

## What do you mean by "lifecycle"?

The lifecycle discussed in this doc is this:

> How do **your** assets **go** from your **editor** to your **published game**?

Let's clarify those bold terms. So in this context:

- "you" are a hypothetical user of Bevy.
- "go" means the various stages the asset flows through - this means how it is used during development and production.
- "editor" is not **the** Bevy editor, it's any editor. From Blender to Notepad++.
- "published game" is the game that a consumer can actually run and interact with. I'm also using game, but of course this also applies to apps.

This lifecycle isn't about how the bytes get into your running game, but how the conceptual asset should be handled throughout the entire development process to end up onto a consumer's screen. In other words, while `AssetLoader`s are required to get the asset to show up in your game, they aren't very important to this discussion.

## High level

Imagine the entire collection of assets that a user deals with in their project as one big group. Then this group goes through the following stages:

1. External Authoring: assets are authored in an external editor.
    - External editors will not know about Bevy. Blender will primarily spit out common formats like glTF, not bsn. You may not even have access to the editor. For example, if you purchase an asset pack of 3D models - they probably won't have had Bevy in mind when they authored these!
2. Importing: taking those authored assets and getting them usable inside Bevy.
    - This is effectively the development state. You should be able to reference them in your Bevy code and have the asset load into your game during development.
3. Internal Authoring: creating new assets in a/the Bevy editor.
    - This is different from authoring because we can refer to artifacts that are produced by importing. For example, if you author some level geometry, and importing generates a navigation mesh for that level, internally authored assets can refer to the navigation mesh because they are "Bevy-aware".
    - A Bevy editor isn't strictly necessary here but makes it significantly clearer how to author these. For example, a Bevy editor is likely to show you the results of importing (e.g., show you that generated navigation mesh) which shouldn't be included in the user's repository (as in VCS).
4. Optimizing: configuring aspects of asset loading/storage/format to improve performance, memory usage, disk usage, etc.
    - Whether this is its own step is ambiguous. Often users start with some raw assets that are too large or slow to ship to users, and need to explicitly "downsample" or compress assets.
5. Publishing: taking the assets and packaging them up to ship to users.
    - For example, assets may be grouped together into "bundles" (e.g., [Unity's bundles](https://docs.unity3d.com/6000.3/Documentation/Manual/AssetBundlesIntro.html)).
    - Assets may be compressed or even obfuscated.
    - Metadata of assets may be packaged along with the assets.

```mermaid
flowchart TD
    subgraph external[External Authoring]
        thirdparty[Third Party/Asset store]
        dcc[DCCs, Blender, Photoshop, etc]
    end

    subgraph internalauthoring[Internal Authoring]
        scene[Scene Composition]
        Navmesh
        lighting[Baked Lighting]
    end

    import[Importing
    e.g., generate mipmaps]

    external --> import

    assets[(Assets)]

    import --> assets

    assets --> internalauthoring

    internalauthoring --> import

    publish[Publishing]

    targetopt(Optimization
    e.g., Texture compression)

    assets --> targetopt --> publish
```

## The kinds of users

<!-- TODO IS THIS USEFUL -->

To aid in our discussion, we will introduce two characters.

Simple Sam

Professional Patty