SceneFile/EntityRecord/RenderableAsset/RenderableKind live in libdqg::scene_file
so the standalone runtime player crate can deserialize the exact same scene format without
depending on this (egui/rfd-heavy) editor crate — see the export/compile implementation plan.
A project on disk: a folder containing a manifest plus assets/, scenes/, scripts/
subfolders. Entities can attach one or more .rhai files from scripts/ — see
Project::list_scripts/Project::create_script and
[libdqg::scripting::ScriptRuntime].
SceneFile/EntityRecord/RenderableAsset/RenderableKind live in libdqg::scene_file
so the standalone runtime player crate can deserialize the exact same scene format without
depending on this (egui/rfd-heavy) editor crate — see the export/compile implementation plan.
The on-disk form of a scene: one of an editor project’s scenes/*.ron files, or one of an
exported game’s res/scenes/*.ron files — both the editor and the runtime player
deserialize this same type. A project can hold more than one (see
editor::Project::list_scenes); which one a game boots into is
[GameManifest::start_scene], and scripts switch between them via scene.change(path)
(see crate::scripting’s ScriptScene/WorldCommand::ChangeScene).
SceneFile/EntityRecord/RenderableAsset/RenderableKind live in libdqg::scene_file
so the standalone runtime player crate can deserialize the exact same scene format without
depending on this (egui/rfd-heavy) editor crate — see the export/compile implementation plan.
The serializable stand-in for a [Renderable]: just the source asset path(s) (relative to
the project root, or an exported game’s res/ directory) plus the handful of params needed
to reconstruct it, since the runtime Renderable itself holds live GPU resources that can’t
be serialized.
SceneFile/EntityRecord/RenderableAsset/RenderableKind live in libdqg::scene_file
so the standalone runtime player crate can deserialize the exact same scene format without
depending on this (egui/rfd-heavy) editor crate — see the export/compile implementation plan.
Starter content for Project::create_script’s “New Script” boilerplate — both hooks
[libdqg::scripting::ScriptRuntime] looks for, stubbed out. on_start/on_update must stay
let-bound closures rather than plain fns (see ScriptRuntime::start_script’s doc comment
on why) — this template exists partly so a new script starts from a working example of that,
not just a blank file.
Rewrites path’s separators to /, regardless of the host OS’s own convention. Every
project-relative path this module hands back or persists (list_scenes/list_scripts/
list_assets’s strip_prefix results, create_scene/create_script/import_asset’s
returned paths, set_start_scene’s argument) must round-trip identically whether the project
is saved on Windows and later opened/exported-and-run on Linux (runtime, CI) or vice versa.
Path::join and component parsing accept / as a separator on Windows too, but Unix treats a
literal \ as an ordinary filename character, not a separator — so a path built with native
separators on Windows (scenes\main.ron) silently fails to resolve at all once read back on
Linux. Rebuilding the PathBuf from the normalized string (rather than via .join(...),
which would reintroduce native separators) is what makes it stick: Path’s Display/
to_str() never rewrites an already-/-separated string on Windows, only .join() inserts a
native separator between components.