Search the Community

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. 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? “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. 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.) 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.