AmbientRun/Ambient

Building, serving/loading and hot reloading

FredrikNoren opened this issue · 3 comments

FredrikNoren commented

In general, all assets (scripts, models, sounds etc.) have three "phases" in Ambient;

  • Building: We take a source asset (.fbx, .wav, a rust crate, etc.) and turn it into a format consumable by Ambient
  • Serving/loading: That asset is loaded into memory by Ambient
  • Hot reloading: The source asset has changed, so we re-run the two first steps and update the game with the new asset

Building
The core idea here is that conceptually we always run a full build. However, the build consist of "build nodes", for instance we might have a PipeImage node which takes a source image, transforms it (resize for instance) and then outputs the result in the target directory. The build node can check if the output file(s) is newer than the input file(s), and if that's the case it can skip that build node.

Builds can be triggered in a number of ways, such as running ambient build or by the hot-reload watcher detecting that any of the source input files have changed

Serving/Loading
Once the assets have been built, they can be served. The important thing here though is that we have to assume that they are served over the network. We also have to assume that they might be served from a static http content server. More over, the assets are normally also cached on the client side (see BytesFromUrl).

Hot reloading
Hot reloading consists of two parts; on the server side we need to detect when anything changes in the source files, and then we should run a full build. And then once the build has finished, we need to figure out which output assets have changed, and then notify all clients (including the running server) which assets have been invalidated. They then need to re-load those assets, potentially with some cache breaking (like for instance adding ?cache_break=random_id to the url).

chaosprint commented

There are several levels of hot reloading:

I think one pain point in development currently (without an editor) is that when adjusting certain parameters, constant values, or initial values, we have to keep recompiling (or is there a solution already?). If these initial values could be stored in a file (like ambint.toml ) and refreshed immediately once changed, it would be much more comfortable experience.

philpax commented

There's currently a hack in place for hot-reloading WASM modules that will ignore the asset cache and always fetch the latest version when [client_]module_from_url changes. We should remove that hack once we get hot-reloading in proper.