Ship Interior Scene

[thombruce]

At least, I think "scene" is the correct terminology...

The ship exterior scene should still be running in the background (if the ship is in flight, for example).

The interior scene is a separate space with separate rules - the player character will have WASD control scheme.

I think swapping between scenes should go something like this:

1. To exit exterior view, press 'X'
2. To enter ship control ("exterior view"), interact with a ship control module using 'E'

'E' being an interaction key makes sense to me - a lot of games use this.

'X' might be dangerously close to WASD, which might also be used for flight controls...

We might consider using ENTER instead to bring up a context menu with actions that can be taken, but given that there will be so few actions initially it does make more sense I think to bind exit to a single key. '[Q]uit' and 'e[X]it' are good options for this, though they both sit dangerously close to WASD. 'X' is arguably harder to hit accidentally.

[thombruce]

Ideally:

1. The ship exterior scene would remain loaded and events still occurring when in the ship interior scene
2. The ship interior scene would remain loaded and events still occurring when in the ship exterior scene

If, for example, there are incoming enemy ships or asteroids or the player ship is approaching an encounter event, we want to remain aware of these even though they aren't visualised within the interior space.

Conversely, we want NPC needs, oxygen usage/depletion, internal temperature (e.g. if engine running hot) to be taken into account for interior systems.

We should be able to swap between the two seamlessly, with activities having still occurred during our time in the other scene.

---

This is why I wonder if "scene" is the appropriate terminology. I'm not entirely sure how to handle the trade off yet, or how to keep one set of systems running in one scene when we're active in the other.

To the Bevy cheatbook!

[thombruce]

The term I might be looking for is "State" actually. See in particular: State Stacks

The example given is of a pause menu which is lain over the running game. You can have things in active or inactive states, all part of the same sort of machinery shown here...

...which does sound like a way to do it.

For example, we might make the ship control system inactive... we could unload the camera and sprites? Things we'd keep would be the RigidBody, Collider, ColliderMassProperties and Velocity, as these are needed for external events even when unobserved.

Maybe use this to implement a simple pause menu first of all, as it sounds easier to do than a whole separate view. Consider this a part of #9

[thombruce]

I can't really find a set of sprites I'm happy with for the ship interior, even temporarily. So I might have to DIY something. The ship needs...

• Cockpit
• Cargo bay
• Bedroom
• Bathroom
• Kitchen
• Engine
• Climate controls?

The two most pressing needs early on are the cockpit and cargo bay, I think. Does "engine" need to be a room? Does climate controls?

I'm beginning to draw sketches to get a sense for how much space I need; then I need to convert those sketches into a count of tiles and the tileset that makes up the space.

The space itself can extrude into the 3rd dimension via the Z-axis; stairs and ladders can be used to change the player's Z-axis - maybe eventually elevators too on larger ships and space stations.

A difficulty arises when we think about ship exterior customisation - exterior shape and interior space are linked. Also when we think about generating ships somehow - no idea how that will work or look yet.

My thinking is that every 1x1 tile in the ship interior space should have an exterior equivalent... acting as the hull or its "ceiling".

Or... since we're thinking about the Z-axis anyway... what's to stop the player selecting their own exterior parts too? Why not have a skylight over the ship's main atrium, for example? It would be cool to be able to fly around and still see sprites going about their business inside via that window... but uhmm... that is an advanced idea I won't touch yet.

The non-advanced aspect of it (meaning we need a clear sense of it now) is how the ship interior space relates to the exterior environment. The ship itself rotates in space, but the interior is intended to be a grid locked to cardinal directions. We have to rotate that grid in space too... all while maintaining positioning of entities on the interior grid. Which roughly means it needs to be an independent grid space, right? But we need to know how to draw it and navigate it in relation to the exterior world grid...

That's not a major problem. Entities inside can be children of the ship grid, and will therefore move relative to it... but this does introduce the scaling issues I previously encountered with planets being children of their star, so we need a clear sense of scaling. But it is the best way to move interior entities with the ship.