Jump to content

Let’s Talk Logistics. Cargo, Inventory management and sundry topics.


Recommended Posts

We’re all sure it’s going to be a big part of gameplay, so how do we make it fun? Simply being ‘emergent’ or freeform isn’t enough to make a mechanic fulfilling in and of itself, of course. So what can we do to keep the player engaged with this aspect of the game, or at least make it feel rewarding for its own sake. Or, if nothing else, make dealing with it not a chore.

 

I’m going to be touching on a few subjects as we go here.

~Construct Inventories

~Market Inventory Mechanics

~Storing and Deploying Constructs

~Shipment Jobs and Contracts

~EDIT: Tactile Containers

 

Part of the “Durendal has highly vocal opinions about game design” series.

~ Construct Mining and Balance: https://board.dualthegame.com/index.php?/topic/13238-mining-constructs-balance-and-you/

~ Logistics and Cargo Management

You’re already here.

 

Part Zero: What’s an Inventory Anyway?

This should probably be established early on. What is an inventory? The obvious answer is that it’s where the player stores their stuff, but the form it takes can vary. The most popular form of inventory is a simple screen with a list, or a grid into which representations of items are slotted.

 

So let’s take a moment to look at a few examples of how games have handled inventories.

ELv9dvK.png

From Left to Right, we have Minecraft, Astroneer, Hellion, and EVE Online.

In minecraft we can see a very simplistic and effective grid based system. EVE takes a similar approach, displaying items in a list as icons, much like a windowed computer interface.

 

Astroneer and Hellion take a vastly different approach. We can see in Astroneer that the player's items are stored directly on their characters backpack, or carried around ‘by hand’ with the mouse cursor. Whereas in hellion, anything the player wants to set down, needs to be racked onto a shelf or container in the world physically.

 

These represent various takes on two approaches, which we’ll call “Listed” and “Tactile” inventories. One represents the inventory as an abstract space, the other as a physical part of the game world.

 

So, which approach does DU appear to be going for?

gMBNd25.png

“Listed” for sure. And given the scope of the game, one can see why. Having all the items players create physically represented in the game world would be impossible in a game like DU. That said, of the two styles, a tactile inventory is the more engaging and rewarding to actually interact with as a user experience. So is there some way we can implement aspects of it while still keeping within the technical and usability limitations placed on DU’s gameplay? I’m going to venture a ‘yes’ and present some theoretical mechanics and use cases.

 

Part 1: Construct Inventories

We can see in the screenshot above, pulled from the Pre-alpha tutorial videos, that the player’s personal inventory consists of a branching,sortable list of items. As an extension, we can assume the inventory of a construct would be similar. Perhaps taking the form of minecraft-like ‘chests’ into which items are simply dragged and dropped. This is absolutely a functional system, but it’s not a very satisfying one. It doesn't leave a lot for the player to interact with. So how can we take some elements of a tactile inventory system and apply them to DU’s listed system?

 

Before we get into the meat of that, first of all we should establish how the player is going to interact with the contents of a construct. The most obvious answer is ‘they walk up to cargo elements and press the interact button’ but this has the potential to become more tedious than immersive.

 

The most straightforward way would be some means of inventory pairing. With this, a character could set a current construct as their ‘active inventory’ and have the things within in available to them as if they were in their personal inventory. So long as they remain within a certain range of the construct. This allows the player to move things from one construct to another without tedium. Simply by moving from the construct that contains their active inventory to another, and interacting with it normally.

 

With that out of the way, let’s discuss a constructs inventory in and of itself. NQ has stated that a construct will have access to ‘storage elements’ which are required to contain items. These may be specific to certain item types, such as solids, liquids, elements, constructs, etc.

 

One way to make this a bit more engaging is to implement a two-stage inventory for constructs. In this, there are two primary types of inventory elements: Containers (previously ‘storage elements,’) and Racks.

bnPcwWu.png

 

When a storage element is installed on a construct, it contributes to that constructs capacity to hold items. Interacting with it, or opening one’s player inventory when paired to the construct, will allow the player to drag items between any appropriate spaces. Be it their inventory or the Containers of a linked construct.

 

A Rack, on the other hand, allows Containers to be installed in it directly. This allows them to be used in the manner described above. In addition, however, when interacting with a rack or other construct, a player can drag an entire Container from one Rack to another. Allowing the movement of physical containers from one consruct to another. (The Rack element here will display the container it contains, but that container won’t be a separate element. Though it may affect the characteristics of the Rack as if it were.)

 

MaqNPqu.png

 

This should allow a great deal of flexibility in cargo handling and inventory management. As well as giving a pseudo-tactile to feel to the process. Giving the player the possibility to see their cargo hold actually ‘fill up’ with goods in some way should add at least some small aspect to making the task fulfilling. It also has some knock-on effects to other mechanics, taht will be discussed in following sections

 

Part 1b: Secondary Conjectures

This is stuff outside the scope of the above, and is more conjecture than solid suggestion or opinion.

 

~ Containers could be allowed to be dropped freely as physics objects? This could be problematic. But having either an ‘ejection’ rack or mechanism for detaching containers rapidly could allow for some interesting interactions. It also ventures the possibility of placing containers in a ship without a rack, or piling them by some method in a warehouse without racks. This is beyond the scope of the proposal, though, and probably incurs too much overhead for what it achieves.

 

~It might be possible to store multiple smaller containers in a larger rack. This incurs the problem of designing a UI element to display how this is being accomplished, in the case of odd fits. While it’s perhaps possible to clearly communicate how much space is remaining in a give rack for containers, this may also be more headache than is necessary.

 

~Possibility the distance an inventory transfer can take place it is related to ‘nano beamformer’ elements? This may be an unnecessary complication. But the elements themselves would provide a jumping off point to script the automatic transfer of containers and cargo.

 

Part 2: Storing and Deploying Constructs

 

Dev blogs have stated it will be possible to store entire constructs inside of a storage element. So how do you get them out? And how does that play with our new Container and Rack system?

 

In addition to container types for different resources or items, one can assume there will also be one specifically for constructs. In fluff terms, we can consider this as a complex device that stores a complex object deconstructed by nanoformers as its component parts, along with all the information to reconstruct it.

 

The capability to store constructs in this way is vital for a number of reasons. Both to facilitate mass production and to reduce server load. (While the image of a lot of ships for sale is delightful, it may be hard to handle for multiple reasons, including interaction with market mechanics.)

 

So first of all, how do we store a construct? We can posit that a construct becomes any other item and is placed into a container suitable to it. Issue arises with constructs that take up more volume than a single container holds. How does one put battleship soup in a can? Here, we can assume that a construct could be ‘partitioned’ across multiple Containers, that become a linked item, or at least a cross-referenced one.

 

Next, we need to get Constructs both into and out of containers. An issue that arises here is that we don’t want this to happen instantly. While time has already been invested into making the construct, we also don’t want units being deconstructed in combat to save them, or freighters instantly spitting out fighters from their holds. So this process should take some time.

 

To facilitate it, we have two elements. We’ll call them a “Garage Array” and a “Construction Array” for brevity's sake. A Garage Array deploys or undeploys dynamic constructs. It’s either linked to secondary elements defining an enclosed space, or has some sort of volume set on its deployment. A Construction Array deploys and undeploys static constructs wherever the operator points it.

 

The size of the array elements themselves determines the maximum size of the construct they can work on, and how quickly they do so. (Possibly in conjunction with player skill.)

 

Thus, storing or deploying a capital ship or large station should take a fair bit of time, while fighters and houses should be quick affairs.

 

The Container that an undeployed construct should be placed in would be selected via GUI upon beginning the process. While deploying one could use existing UI elements. (The item sidebar specifically.)

 

Part 2b: Secondary Conjecture, The Second.

~It may be a Good Idea to factor the deployment time into the time needed to manufacture a construct in the first place.

 

~If a container for part of a construct is lost, a Factory Unit should be able to replace it by being provided with the other containers. To prevent IP theft by copying. (Splitting something into five containers and ‘replacing’ the other four off each.) When the process is initiated, remaining containers should become inert. Though if they’ve been stolen or simply misplaced, the construct soup in them should be reclaimable for raw materials as a consolation prize.

 

Part 3: Market Inventory Mechanics

So now that we have containers, how do they interact with markets? It’s been stated that a market will need storage for goods waiting to be sold, so we can facilitate that in the following ways.

 

1: A container attached with no rack to the market construct and linked to the market unit provides loose item storage to it.
2: A rack attached to the market unit allows for containers within it to be sold, including their contents. (And potentially bought, but this has some issues, as a market order for ‘a size 3 Container with exactly 30k iron ore.’ raises UI questions.)

 

Alternatively, we could also allow containers in racks to be flagged to contribute to the total loose storage. Or to only do so until they’re empty, or any other number of possibilities.

 

The major takeaway of this part though is that racks and containers facilitate bulk sales for allowing entire containers of goods to be sold and delivered as a unit through the market terminal.

 

Part 3b: Secondary Conjecture; third time’s the charm.

~If market terminals also facilitate delivery or transfer contracts, this neatly sidesteps the problem of ‘placing buy orders for containers of goods.’


~That said, providing an empty container to a market terminal along with buy orders that are collectively tied to its capacity is a Good Idea.

 

~Buy orders that are tied to a target containers capacity are a Good Idea in general, because they allow factory owners flexibility in receiving deliveries from freelancers. But that’s probably out of scope for the cargo post.

 

Part 4: Shipment Jobs and Contracts

 

Containers should allow for shipment jobs to be generated easily. Instead of specifying specific items, a client can now simply say they need a container shipped from A to B. Unfortunately, a simple contract like this fails to allow for some use cases.

 

If an efficient trip means transporting a crate from a market terminal near the client’s business, to the spaceport, to an orbital transfer, then via freighter to another transfer and down to another planet, orchestrating all of this could be problematic. So it may be ideal to allow the client to specify the legs of the journey and the payout for them.

 

Alternatively, allowing potential contractors to establish routes from one freight terminal to another, simply with a fee for transit of a Container, may be a better solution. Here, the customer would select a destination in the market terminal, deposit their Container, and the contractor is paid upon its arrival. This allows a shipping company/org to worry about all the interim stages without involving the customer, but still allows such jobs to be established without require a clerk and notation on the player’s part.

 

4b: Secondary Conjectures One last time

~Yeah, just kidding. This whole part was mostly conjecture.

 

And there you have it. Ways to handle logistics and the potential benefits thereof. There could be ways to make these mechanics even more hands-on and engaging, but they’re likely outside the scope of development NQ has set. The above seems, to me, like a fair compromise.

 

I ran out of steam on the graphics to accompany this. I might go back and add some more later.

 

EDIT EDIT EDIT

Part 5: Tactile Containers

I forgot this one before I posted last night.

 

Tactile Containers would be things like lockers, shelves, weapon racks, armor stands, etc. Things players could use to display personal items such as weapons, tools, spacesuits, and various small decorative items that aren't worth making 'elements' in and of themselves. These would be placeable or retrievable just by holding the item (or nothing to retrieve) and interacting with a 'slot' on the container. These would be specifically not linked to a constructs overall inventory, and might as well includes safes or the like. (Normal containers that are not visible to the outside inventory system by anyone.)

 

The items on these would just not display to people not suitably close to them. And mostly are a way for players to facilitate showing off their personal Stuff, which is something one imagines they'll probably want to do.

 

As a wild conjecture, I'd approve of globes of planets and models of player constructs, generated somehow from in-game data, as ideal decorative items to slot into such elements.

 

259827178483482C6A04C8A0B58409FA110B3FBB

 

Link to comment
Share on other sites

1 hour ago, Lethys said:

TL;Dr?

Part1:
Put containers in Raid0, so you can create your own large storage 'disk' out of many containers on the construct. You can pair different amounts of containers in different ways to create different sized disks.

 

This lets you manage a collection of storage elements as a whole, instead of menially flipping through them one-by-one like Minecraft chests.

Part2:
Constructs are deconstructed into primordial soup, which can be split and stored between many 'Raided' containers on a construct. Construct projectors and deconstructors can only deploy constructs that are of smaller dimensions than themselves, and deploy time is dependent on construct mass and dimensions.

 

Part3:

Containers and Container Raids should be allocable to market functions, and have rules for what happens with them upon certain market events.

 

Part4:

Container rules that generate courier contracts for items placed within them? Somehow? Maybe?

 

 

All of this makes sense, I fully support this proposal.

Link to comment
Share on other sites

Great effort ! :D

But you're probably going to have to do it all over again once we see what DU's design looks like, a few weeks from now...

 

The question of how building will be done has been raised before. Player inventories will have limited capacity, and having to continuously "refill" the player inventory from various storage containers will become very tedious. Automatically (or manually) "linking" the player inventory to all containers within a given range will make life easier for builders, but represents a bit of a challenge in the UI design, because you still need to be able to see the difference between your inv contents and what's in the containers...

 

I'm not sure that storing a "disassembled" construct across multiple containers is practical. What happens when just one of those containers is destroyed ? Or moved accidentally ?

 

For practical purposes, the "market containers" will probably have to be a special class of container, immovable and with vast (unlimited ?) storage volumes, otherwise managing their contents will become a nightmare. Will the main feature of player settlements be vast "container parks" holding 100's or 1000's of market containers ?

 

I believe a "market" in DU will consist of 3 elements:

  1. the market terminal (where the UI displays)
  2. a storage container (where the goods are kept)
  3. a dispenser (where purchased goods can be retrieved)

So the dispenser element will probably "re-assemble" constructs from their stored state. That implies that constructs will ONLY exist in "virtual space" inside market containers, otherwise we are moving into "I have 2 battleships in my backpack" territory... :D

 

Link to comment
Share on other sites

11 hours ago, Lethys said:

TL;Dr?

Megaddd covered this relatively well. I'd refer to his post.

9 hours ago, Megaddd said:

Part1:
Put containers in Raid0, so you can create your own large storage 'disk' out of many containers on the construct. You can pair different amounts of containers in different ways to create different sized disks.

 

This lets you manage a collection of storage elements as a whole, instead of menially flipping through them one-by-one like Minecraft chests.

Part2:
Constructs are deconstructed into primordial soup, which can be split and stored between many 'Raided' containers on a construct. Construct projectors and deconstructors can only deploy constructs that are of smaller dimensions than themselves, and deploy time is dependent on construct mass and dimensions.

 

Part3:

Containers and Container Raids should be allocable to market functions, and have rules for what happens with them upon certain market events.

 

Part4:

Container rules that generate courier contracts for items placed within them? Somehow? Maybe?

 

 

All of this makes sense, I fully support this proposal.

Missing a few points but mostly correct. The rules about separating Containers and Container Racks was how most of that was facilitated, but I guess that's not really what he asked.

The functionality of part 4 is best summarized as follows:
- Contractor Establishes a shipment path in a market terminal
- The terminal has Racks assigned to this task
- A client 'accepts' the contract and gives over money to escrow and the box they want shipped. The contractor provides any promised collateral to escrow.

- The box goes into a rack and the contractor is notified

- They do whatever to get the box to the 'destination' market terminal

- Once it arrives, they get the money from escrow and their collateral back. The client is notified that the box is available for pickup and retrieves it from the rack.

- If it doesn't arrive on time, the container's owner is voided and the client gets their collateral and payment back from escrow

8 hours ago, NanoDot said:

Great effort ! :D

But you're probably going to have to do it all over again once we see what DU's design looks like, a few weeks from now...

 

The question of how building will be done has been raised before. Player inventories will have limited capacity, and having to continuously "refill" the player inventory from various storage containers will become very tedious. Automatically (or manually) "linking" the player inventory to all containers within a given range will make life easier for builders, but represents a bit of a challenge in the UI design, because you still need to be able to see the difference between your inv contents and what's in the containers...

 

I'm not sure that storing a "disassembled" construct across multiple containers is practical. What happens when just one of those containers is destroyed ? Or moved accidentally ?

 

For practical purposes, the "market containers" will probably have to be a special class of container, immovable and with vast (unlimited ?) storage volumes, otherwise managing their contents will become a nightmare. Will the main feature of player settlements be vast "container parks" holding 100's or 1000's of market containers ?

 

I believe a "market" in DU will consist of 3 elements:

  1. the market terminal (where the UI displays)
  2. a storage container (where the goods are kept)
  3. a dispenser (where purchased goods can be retrieved)

So the dispenser element will probably "re-assemble" constructs from their stored state. That implies that constructs will ONLY exist in "virtual space" inside market containers, otherwise we are moving into "I have 2 battleships in my backpack" territory... :D

 

I don't think I'll need to do it over. Most of what I've said is based on information pulled from devblogs, I just didn't provide a bibliography. (I probably could if anyone felt suitably strongly about it.) To address your points in order:

The UI design for the linked inventories was addressed, with example. It's basically simplified windows UI standards and shouldn't be any major problem.

 

Storing disassembled constructs across multiple containers is unideal, but a use case for constructs that won't fit in one of even the largest container needs to be considered. What happens when one is lost or destroyed was also addressed in the OP. But to summarize: Someone in the containers permissions list attaches it to a factory and initiates a partial-loss sequence. The factory produces the missing parts. The lost containers revert to being a box of elements and voxels that can't be used to deploy the construct anymore, if said containers still exist. (this to prevent bypassing IP controls)

 

That markets will use standard containers was established in a dev blog somewhere. "unlimited" containers will simply not exist. Also, utilizing standards ones for the container/rack system allows shipment and transfer contracts and bulk sales to involve whole containers, which provides a little flexibility to the entire thing.

 

Your statements about market units are correct as far as I know. The 'dispenser' for constructs would be a role filled by the system I outlined in part 2 above. And yes, stored constructs will be just items and a template, essentially. The idea being that you can buy a construct as an item and move it around in boxes, but 'pulling it out of your pocket' requires a dispenser and time.

8 hours ago, Nanoman said:

@Durendal5150 I skipped through your text so I might have missed some details, but I think most of what you suggest can be implemented with my docking mechanics proposal.

 

 

 

The docking system your outlining is something I'm pretty sure JC mentioned as a planned mechanic in one of the pre-alpha videos. It doesn't really cover the use cases I'm describing here, though, as this is largely concerning inventory management of containers (an element) whereas you're discussing docking container constructs to a freighter, at least as far as I can tell. That's also an idea I like a lot, but it is a pretty separate thing. Such docking mechanics could be used to facilitate the range checks for transfer of container elements between racks on constructs in the above proposal, however.

 

 

 

 

~~~

I'd like to add a "Part 5" to the above, retroactively: Tactile Containers

 

Tactile Containers would be things like lockers, shelves, weapon racks, armor stands, etc. Things players could use to display personal items such as weapons, tools, spacesuits, and various small decorative items that aren't worth making 'elements' in and of themselves. These would be placeable or retrievable just by holding the item (or nothing to retrieve) and interacting with a 'slot' on the container. These would be specifically not linked to a constructs overall inventory, and might as well includes safes or the like. (Normal containers that are not visible to the outside inventory system by anyone.)

 

The items on these would just not display to people not suitably close to them. And mostly are a way for players to facilitate showing off their personal Stuff, which is something one imagines they'll probably want to do.

 

As a wild conjecture, I'd approve of globes of planets and models of player constructs, generated somehow from in-game data, as ideal decorative items to slot into such elements.

Link to comment
Share on other sites

  • 1 month later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...