Rethink Modules

[thombruce]

I've just reworked modules to make for a tidier directory structure... It's good, but it's not perfect.

I'm wondering if something like a world-app separation makes sense, where a world module contains submodules astronomical/, terrestrial/ and spacecraft/ for the three types of "world" the player will explore and the app module would contain... everything else: the camera, menus, effects, post-processing, etc.

Maybe...

• Core
• App
• World

Core would contain state management, application setup, the game_time resource and that sort of thing.

App would contain menus, the camera, the states themselves, inputs, etc.

And world would contain the player and gameplay features.

---

Restructuring an app is pretty easy and straightforward, but tedious and messy in the git history. Not something we want to do often, so I want to hold off on any more for now - when I have a better understanding of which parts are better placed together, we'll revisit this.

[thombruce]

I've just run up against a limitation within Bevy I wasn't aware of too. The .add_plugins() function only works for up to 15 plugins at a time.

    app.add_plugins((
        DefaultPlugins
            .set(WindowPlugin {
                primary_window: Some(Window {
                    title: String::from("Verse"),
                    ..default()
                }),
                ..default()
            })
            .set(ImagePlugin::default_nearest()),
        GameTimePlugin,
        RapierPhysicsPlugin::<NoUserData>::pixels_per_meter(1.0),
        InputManagerPlugin::<MenuAction>::default(),
        BackgroundPlugin,
        CameraPlugin,
        StatePlugin,
        HudPlugin,
        ShipPlugin,
        MenuPlugin,
        CreditsPlugin,
        EffectsPlugin,
        AnimatePlugin,
        PausePlugin,
        PlanetarySystemPlugin,
    ));

    // You can only add 15 plugins to add_plugins
    // I need to start refactoring.
    app.add_plugins(SpatialPlugin);

With sensible module separation, we could have plugins per module... and load each module in here as needed. 🤔

[thombruce]

I'm also realising it would be a good idea to separate the world and the player, probably camera too. So you would have a world module which can be run independently of the existence of a player. Then you would have a player module, which when present will allow the player to traverse the world. And you might also have a separate camera module that can be used independently of the player too, to examine the world freely.

This would allow me to work on various features independently of other systems that could interfere with them. I envision these modules:

• World
• Player
• Camera
• UI

It's just a question of... are the camera and UI part of the same module? What about those UI parts that are player-specific, or even ship-specific?

In any case, the world should function wholly without the player. The player is just a system that interacts with the otherwise living world.

[thombruce]

There are actually more than just the Astronomical, Terrestrial and Spacecraft worlds that a player will explore...

Astronomical is divided into different scales - galactic, stellar, planetary.

Spacecraft might well borrow from Terrestrial (generation ships with natural interiors), and one can be accessed from the other (enter/exit ship while landed).

The player should also be able to enter/exit their ship in space, meaning some of the same orbital mechanics and space-based rules that apply to the ship must apply to the player - the player could end up stranded.

I'm not sure how to reconcile these module overlaps or the scaling problem yet.

[thombruce]

Reorganised as of baf36850ece577a5446ebed357fc41564dd6e21c, 11e6f4eeff89216d142d01838d0f9c9f62469744 and d3baf369d3e749d1332f3e16fa220978ffdd6034.