ecdavis / spacegame Goto Github PK

It shouldn't be possible to anchor a beacon inside the warp radius of a Celestial.

Moving around inside the physical radius of a Celestial will require further consideration.

In-scope:

• Fittable slots on Mobiles.
• Cargo holds on Mobiles.
• Fittable Items.
• Command to fit an item.
• Command to unfit an item.
• Active warp scan command must only work if an active warp scanner is fitted on the Mobile.

Out-of-scope:

• Item area.
• Item stats.
• Item restricted types.
• Fittable slot types.
• Cargo hold area.

Players should be able to move in 3D space within a celestial with adjustable speed and direction.

Currently blocking #16

As integration tests become more complex and it becomes increasingly necessary to set up state prior to carrying out a test, a more sophisticated integration test client will be required.

Consider the example of testing that warping to a celestial sets the player's position to (0,0,0). First you need to move the player away from (0,0,0) in the origin celestial, then you need to do an active warp scan, then you need to warp, then you need to retrieve the player's position and only after all of this can you confirm that the post-warp position is (0,0,0).

Once we add notifications to the server it will become even more complex.

In-scope:

• Command to create a pre-anchored warp beacon at a Celestial.

Out-of-scope:

• Un-anchoring beacons.
• "Possession" of beacons outside of Celestials.

Nice-to-have feature for clients to keep track of requests/responses and differentiate them from "push notifications" (for lack of a better term).

Get everything in place to allow installing dependencies using pip.

Right now services call into the pantsmud.util.message directly to send messages. Create an abstraction that encapsulates this and can be passed in to the service as a dependency.

Currently when a Mobile warps from one Celestial to another, its position within the Celestial stays the same. I.e. if the Mobile is at (10, 20, 30) in Celestial A, after warp they will be in (10, 20, 30) in Celestial B.

Celestials should have a position within the containing Star System. Draw a straight line from the center of A to B, we can call that line the "base warp path" (i.e. the path taken by a Mobile warping from A(0, 0, 0) to B(0, 0, 0). Draw a second line from the Mobile's position in A that runs parallel to the base warp path, we can call that line the "real warp path".

The Mobile's position in B after warp must be the same distance from B(0, 0, 0) as its position in A. There are two positions on the real warp path with this property -- the Mobile's position in B must be the closer of those two positions to its original position.

They may need to be a separate class from the regular Entity. They're conceptually different enough.

For now, just add a timer that notifies all entities of the position/velocity of all other entities in the same celestial.

Optional: have a "has_moved" flag on entities which changes when an entity's position gets changed. Only include entities that have moved in the position/velocity notifications.

Running the startup script should create all necessary files and folders for the game to launch. It should also have an option to clear existing data.

Relying on global objects and state is bad practice and makes testing difficult. Pass all dependencies for initialization into the init functions directly.

In scope:

• Use a command to calculate warp paths from the current celestial to all other celestials in the star system.
• Warp paths are cleared after warping.
• Warp paths are cleared after jumping.
• Change warp command to only allow warp if a warp path has been scanned.

Out of scope:

• Storing scanned warp paths between warps.
• Storing scanned warp paths between jumps (we may never do this).
• Active warp scanner as a fittable item. Right now it's just a command.

It should be easy to differentiate between a notification (someone sent you a message, something happened in the world, etc) and the result of a command. Errors and failures should be presented consistently.

They're both dynamic entities with different characteristics. Put all the common code into a single class and make features like "pilotable" and "anchorable" configurable.

Players should be able to move from one solar system to another without restriction.

Where possible:, remove redundant code, switch to new patterns, reduce duplication, etc.

Players should be able to connect, log in with a persistent identity, and chat with other players.

Players should be able to move from one celestial to another without restriction.

Ships are distinct from mobiles. Per the design doc, they are pilotable entities. Implement a basic ship frame (and, by extension, simple entity model) and have movement commands control the ship frame rather than the mobile.

In-scope:

• Passive warp scanner should contain warp paths to all warp beacons by default.
• Passive warp scanner should be populated with other warp paths when active scanner is run.
• Passive warp scanner should retain warp paths even after the Mobile warps.
• Passive warp scanner should be cleared when the Mobile jumps.

Currently the session is both a brain and an actor, the mobile is an actor with a brain, and the entity is a piece of content with an optional pilot. This may be unnecessarily complex and an artificial abstraction born of the division between PantsMUD and spacegame.

As integration tests become more complex they will need a more predictable game environment to operate in (see warp unit tests in PR #52). Change the integration tests so that they copy an existing game environment to the temp data directory that they run against.

Identities can be used to pair Users with Brains and Environments.

This isn't covered in the design doc, but it should be possible to have an item which can then be deployed to create an entity. The warp beacon should be first deployable item. It should create an anchorable entity.

Commands involved are probably deploy and anchor. This needs to be specced out before it's developed.