tsunamayo / Starship-EVO

Welcome to Starship EVO bug tracking repo !
114 stars 17 forks source link

[Dev Asks] Brainstorming: Ship Inventory and conveyor system. #2116

Open tsunamayo opened 4 years ago

tsunamayo commented 4 years ago

Okay so second brainstorm of the day, this time on ship inventory. So I would like a physical system for managing item, for mining, crafting, trading ect. That would mean you will need to pipe your storage between them and use some specific blocks for various use. => does that seems too tedious?

Here is what I have in mind: 1) Inventory block, with several connector on the side. 2) Conveyor: straight line, corner, merger, splitter with potential user defined rules applied for the split logic. It would be simple pipe (or squared pipe to make them look different) 3) Collector: would "suck" mining output, scrap or loot nearby the ship, then feed that into the inventory loop of the ship. 4) Connector: to trade with other ship. Could be a built-in function of the docking port, ie the docking port will come with a conveyor connector. 5) Trash block maybe?

=> Do I miss some other blocks?

=> now implementation wise I see two different paths: do we want a one-way conveyor or two way? One way would be simpler to code and would have less specific rules but might a bit cumbersome for the player to use. He would have to make a closed loop for each inventory basically.

Two way would mean two inventory connected with a single link could exchange any item. A lot easier to deal with when you want to add a new inventory somewhere. But of course some block like the collector can only be one way, so any conveyor attached would become one-way.

Thanks for the chat as usual guys!

NB: also I didnt talked about it, but I wanted to make inventory crate weight limited. You could only store a given mass into it. But the mass from the block will be on fraction of the mass stored. Ie you store 10T => you only get a 2T penalty. Also very important note, they will use power! I think it is necessary for gameplay as we will have a lot of ressources in rings. It will make ship design more intersting, ie do you prefer more weapon or more storage? It will give rise to cargo build ect. Justification is to compress all that mass and that size it require power ;)

tsunamayo commented 4 years ago

Okay I still have to make up my mind on this. I havent read 100% of contributions yet, but it seems we have two path: 1) Full magic. no intra-ship piping needed. But people still would wants pipe for trading ship to ship 2) Hull pipe for ship inventory / fuel line, and normal conveyor for raw material for factory building. Now in that case I wont have the player pipe every system system that would be insane @JohnsonJohnsonson @Garrett-C I do agree. If I go that route no piping will be required for typically small system like small thruster. In my initial vision it was pretty much only about ship inventory, aka loot, raw material ect. But having to pipe the big end thruster seems okay to me. (I agree that could be complicated for small figther...) So we could shift the discussion on what item would need some resources? I wanted to have resources for upcoming aspect of the game, say Drone Station (your drone get destroyed, you have to have a drone part to spawn a new one), Clone bay, of course missiles and kinetic gun. But we still need to discuss about reactor, thruster, warp and else. I think it deserve a dedicated thread...

Garrett-C commented 4 years ago

Okay I still have to make up my mind on this. I havent read 100% of contributions yet, but it seems we have two path:

  1. Full magic. no intra-ship piping needed. But people still would wants pipe for trading ship to ship
  2. Hull pipe for ship inventory / fuel line, and normal conveyor for raw material for factory building. Now in that case I wont have the player pipe every system system that would be insane @JohnsonJohnsonson @Garrett-C I do agree. If I go that route no piping will be required for typically small system like small thruster. In my initial vision it was pretty much only about ship inventory, aka loot, raw material ect. But having to pipe the big end thruster seems okay to me. (I agree that could be complicated for small figther...) So we could shift the discussion on what item would need some resources? I wanted to have resources for upcoming aspect of the game, say Drone Station (your drone get destroyed, you have to have a drone part to spawn a new one), Clone bay, of course missiles and kinetic gun. But we still need to discuss about reactor, thruster, warp and else. I think it deserve a dedicated thread...

I think pipes for cargo is totally fine. My view is that using pipes etc to get resources into your ship makes a lot of sense and can be fun. It adds a little bit of an extra feature to the gameplay but doesn't make things too complicated.

What I have an issue with is having to pipe resources to specific systems like fuel to generators or ammo to missiles. I have no problem with the ship needing to have these resources in stock, its the requirement of moving them from storage to system that I disagree with. Mainly because it could very easily force players to build ships in almost set ways. I think the game has great tools for creative builds and hampering that with restrictive systems seems like a bad move to me.

Garrett-C commented 4 years ago

In regards to moving the conversation to what systems would need what resources based on the information we have currently.

Generators should probably need some sort of fuel.

Maybe warp needs it's own fuel aswell.

Physical weapons like missiles would need physical ammo.

It makes sense that something like a drone bay would need something like drone components.

I can't currently think of any other current systems that would need supplies.

nokturnihs commented 4 years ago

I agree with kinetic weapons, missiles, drones, mine deployers, clone bays, but would keep thrusters/lightcruise out of the list at the very least. If you really want fuel-powered generators they need to be an option not a requirement - perhaps they put out significantly higher power than reactors. If you go that route you'd need to add batteries and while that could allow things like fighter charging stations I would rather not as it doesn't seem to fit your current aesthetic. Maybe warp would warrant a fuel option but if so I'd go with a warp charging system (batteries) that creates a cooldown between warp use or the duration one can stay in warp (they need to recharge). Needing inputs and consuming fuel is fine for some games, but it's also very limiting. That said, of the games I've played that require fuel for basic ship movement, probably empyrion's fuel cells are the best, if still less than ideal. I guess interstellar rift is fine as well and also makes more sense as "water fuel" is pretty similar/usable as propellant in real life. Still, we don't have blasters, combat shields or beam weapons yet so...

nokturnihs commented 4 years ago

Also be advised that every single ship that's been submitted becomes ultimately unusable in it's current form if fuel and storage for it becomes a requirement - every backer will need to rebuild their submissions and in this regard some will become absolutely useless (reactors hidden under floors and otherwise inaccessible, etc.) you really wanna do that cool, but it will irritate some of your builders and add a lot of time to your eventual release.

nokturnihs commented 4 years ago

Side note: one workaround to this is introduce alternative power and fuel systems (tiers) that do require fuel while leaving already existing power/ flight systems untouched. In this case I'd opt for better power/heat ratios for those systems making them an alternative to what's there now and also more appealing to combat oriented ships - as you haven't fully fleshed out combat this would work and provide a reason for using fuel-consuming systems.

nokturnihs commented 4 years ago

I'd still consider a decal system for "tagging blocks" as storage, etc - either way because even if you do force fuel consumption it might minimize the damage done to backer submissions, etc.

Alchemichai commented 4 years ago

Could pipes be implemented as an invisible layer over the ship that could only be seen when a certain tool is held? The pipes could be associated to the brick they are in so they have a physical presence in the ship but they don't actually take up space. Pipes could be destroyed in battle disabling the blocks they feed and such if their host block is destroyed.

To prevent the tedious job of routing pipes you could have the pipes automatically route through the ship to where they are needed, or if the player wants critical pipes routed through safer areas of the ship they could do so manually, or semi-manually by specifying/moving points they want certain pipes to route through.

This would give the best of both worlds, the pipes exist and you could pipe around items manually between machines that may or may not eventually exist, but you could also just slap a ship together and have basic systems (thrusters, weapons, etc) just work with automatically routed pipes that nobody will see.

Perhaps there could actually be pipe blocks aswell in cases where there is no path through a pipe-able block or if a player wants to be able to see connections like if they are setting up some sort of automated machinery.

*Anywhere I speak of pipes could also be wires or whatever you want to move resources/data through a ship.

It is not simple to implement I'm sure (would require a whole new brick in brick concept to be added to the game or something) but it could add complexity and realism to the game without making the game complex for players who would rather their time spent on aesthetics.

nukeguard commented 3 years ago

If I might suggest, that gravity be auto-detect type when placed will detect to within a few meters of the outside hull of ship, so there would be no configuration needed, and would only need one gravity block per ship, largest grid

WILDCATreactor commented 3 years ago

thoughts on the one-way/two-way problem

IF Paired Container connection ports are touching: two-way transfer IF Paired Containers connected by conveyer, sorter, etc: one-way transfer

*Splitter Function Setting Selection - Bridge Connector: Splitter has three ports in this mode setting, a two-way connection to the container and an in-port and an out-port

AlienXtream commented 3 years ago

ive had this idea floating around in my head for a bit and now i sort of have a better idea of how to explain it. so, in starwars we often see people moving cargo around in crates and canisters. i think it would be cool to have it so cargo is stored in these containers like that and to move a lot the player has to buy or make a "hovercraft" trolly cart that they push rather than drive (not physically "push" but that they "grab onto" the bar and it will then move with the player like when you push a trolly. could also hock it to the back of a hovercraft to make a trailer. i digress). additionally players could "lift" a container to place it on the ground/cargo bay of their ship. the players inventory itself would be limited but when building any and all containers on the active grid are accessed for resources. logistics would come in 2 forms. manual and auto. this is where it gets interesting. manual logistics would be aimed at small ships. carrying fuel containers to the engine and transferring fuel, loading up fabricators (or whatever ends up having that functionality) can be done manually etc. should be done in world more than in menus to make the player feel "grounded" in the world. so containers would not really have a UI, rather you would open them and see the items in the 3D container (obviously they would be culled when its closed) with an info card on the side to more clearly see/access items and their descriptions/info if needed as well as how much space its taking up (a large gun would take more space than a food ration). perhaps containers could also be stretched to different sizes (up to a reasonable limit) to accommodate objects of different sizes (like a player made missile launcher would be longer and not fit in a small box but a longer box could hold it). would probably have to do some bounding box calculations to determine the size of the weapon (this would also passively limit weapon size because while a stupidly OP weapon might be cool you would have a hard time storing it somewhere safe so you would either have to drop it on the ground or carry it all the time, taking up a slot in your pack).

automatic logistics could be done in one of 2 ways. "hidden" pipes and conduits that basically work like the wire tool (but creates some sort of pathfinding line through the hull blocks and bricks to the target that is xray visible but only with the tool active (this eliminates the problem of having to build actual pipes everywhere as its basically just parenting the inputs and outputs). no concern about overlapping and the highlighted path has a higher opacity and brightness than inactive ones (but they are still all visible).

alternatively a rather straight forward system where inventories have an input port(s) and an output port and you build simple tubes between the 2 of a desired system. extraction can be controlled with binary logic (on = extract/output, off = no not extract/output. no signal at all connected = output). the current decorative tubes could probably be retrofitted to work for this. also, though not directly related to this, i think pipe stretching and placement should be changed to rather than placing and stretching straight and curved pieces to a dynamic system where you can "draw" the path of the pipe and it automatically create corners, intersections and end cap.

i think the physical pipes would be cool but the "hidden" piping would probably be more convenient and easier to work with in small builds so its probably the better of the 2

Lilly0fPearl commented 3 years ago

Starmade handled ship inventory in a very simple way. They used a generic inventory block that acted as the hub for input/output/UI, then you linked this with an array of invisible blocks which made up your cargohold (thus establishing the max capacity of the hub). Then as objects were added to the hub's inventory, it would begin to physically fill in the invisible blocks with an assortment of cargo containers.

starmade-screenshot-0204

JRL101 commented 3 years ago

Starmade handled ship inventory in a very simple way. They used a generic inventory block that acted as the hub for input/output/UI, then you linked this with an array of invisible blocks which made up your cargohold (thus establishing the max capacity of the hub). Then as objects were added to the hub's inventory, it would begin to physically fill in the invisible blocks with an assortment of cargo containers.

starmade-screenshot-0204

Hmm you could do something similar, with storage using a pallet like structure with visuals that change depending on the percentage filled. The pallet could be something like a cage block that fills with other boxes to fit in with the style it could use the calculation of blocks like the painting tool does and fill the top space appropiatly.

of coarse you could use a storage interface block to connect to them.

In Starmade there are two blocks: storage block then the "cargo" block

STORAGE BLOCK: is the interface block with a small inventory

CARGO BLOCK: is the invisible block that links to the Storage block to extend its storage capacity, but also displays the current cargo with randomised block patteren