Jump to content

Search the Community

Showing results for tags 'inventory'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Forum Rules & Announcements
    • Forum Rules & Guidelines
    • Announcements
    • Patch Notes
  • New Player Landing Zone
    • New Player Help
    • FAQ & Information Desk
    • Gameplay Tutorials
    • Player Introductions
  • General (EN)
    • General Discussions
    • Lua Forum
    • Builder Forum
    • Industry Forum
    • PvP Forum
    • Public Test Server Feedback
    • The Gameplay Mechanics Assembly
    • Idea Box
    • Off Topic Discussions
  • General (DE)
    • Allgemeine Diskussionen
  • General (FR)
    • Discussions générales
  • Social Corner
    • Org Updates & Announcements
    • Roleplay & Lore
    • Fan Art

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location:


Interests


backer_title


Alpha

Found 9 results

  1. Now that schematics have been implemented with the last patch, I went to the nearest market and purchased a decent amount of schematics to use at my small industry. Upon returning to my base I began to load schematics into their respective industry units. I clicked the first industry unit, a smelter, and all of the schematics I had just purchased showed up as an option to put into the smelter. I sorted through all my schematics and loaded the ones that went to the smelter but it got me thinking about a simple ease of use sorting feature. I propose that only the schematics that can be used in any given industry unit show up when loading schematics. As players acquire more and more schematics it is going to become a pain to have to sort through all of the schematics you own just to find the one you need. This can easily be remedied though with the simple addition of a sorting filter to show only useable schematics.
  2. Bank. Bank cells. What if you make cans in distracts, and in them each player will have his own inventory for a certain volume? This is free inventory, not the one on the market. The player has a basic capacity (free), but it can be expanded with credits. There are several levels of expansion. For corporations, special inventories with a very large volume are available. The contents of a bank container can be sold, or items can be bought into it (using the market container manager, this is either a special skill or an NPC hired for a fee).
  3. Allow Shift/Ctrl/Alt+clicking of materials to quick transfer them between inventories. Manually dragging and dropping is so last century.
  4. 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.
  5. CalenLoki

    Loadout

    DU will have some kind of infantry PvP. NQ also wants to encourage teamwork in various activities. And I think most agree with me, that forcing players to specialise roles increase the importance of teamplay in infantry combat. IMO it's also important to switch off hand-nanoformers during combat, as they have potential to be extremely OP and immersion breaking. We have inventory system. But because you'll be able to hold cubic meters of matter (or i.e. dozens of different weapons), it can't be used for specialisation. We have leveling system. But It allows seasoned players use everything, while new players can't use anything. Not much specialisation I'd say. It's more of a tool to split playerbase. Commonly used in RPGs and shooters "classes" usually heavily and arbitrary limit creativity and customisation. Or require tons of sub-classes, which are pain to balance. Thus I suggest implementing "loadout" system. It's kind of similar to typical "class" in most RPGs, but more open for customisation, and also not permanent. Loadout can't be changed in combat. You're stuck with what you had equipped once someone turns nanoformer-jamming-devicenearby (possibly just alternative mode for nanoformer itself. And TCU for larger scale). Thus changes on the fly are not possible. Loadout consist of main tool, 4 secondary tools and 3 ability modules. -Main tool will be usually some kind of weapon. Anything from carbine or shotgun to heavy machine-gun or anti-material rifle falls into that category. Also old-school mining drills that can bypass RDMS. -Secondary tools are meant to either enhance main tool, or suplement it's weakness. So sidearms, melee weapons, spare mags, nades, stim-packs, explosives, ect. -Abilities allow player to perform specific actions, which truly shape the way you play. Players can either focus on enhancing single ability by using multiple modules of the same kind, or mix them for specific playstyle. Available modules: Battery increase avatar energy storage and generation by 100% (each battery). So while it doesn't give any new ability, it allows using other modules longer or more often. Sprinting uses energy too, so even battery-only build is viable. Storage increase inventory space by 100%/module. Useful for long exploration trips if you can't bring hover-cargo-drone. Jump-pack allows you to jump quite high (or if every player can jump, make it enhance jumping). Equiping more of them allow you to jump much faster, but not further - for that take jetpack+battery Shield-pack allow projecting force-field in front of you. It has limited coverage angle and drain energy both per time and per prevented damage. Taking more shield modules increase their coverage and increase efficiency of prevented damage (good against multiple opponents or to shield teammates). However it increase energy drain per second, so for long-lasting protection better take more batteries. Stealth-pack allows you to remain invisible. But just as shield, i's directional. It also drain faster when you move fast. Take more of them, to increase coverage angle and reduce movement penalty. Take more batteries for longer quicker recharge. Exo-arm allows usage of heavier weapons or reduce penalty of using those (like slower locking time). Ammo-pack can be mounted in two ways. Either it connects directly to main weapon, making it drain energy rather than use ammo in mags, or can be used for filling mags in the field. Lore: ammo pack is shielded from jamming (all the nano-forming happens inside), thus can always work. Healing-pack allows healing team-mates (when mounted as active) or fill stim-packs of your team-mates (when passive). Lore: personal body armour has ability to convert any received hit into heat. But need coolant or time to get rid of it. Healing pack allow shielded nanoforming of that coolant. Grappling hook allows getting to various spots. Less dynamic than jump-pack, but allows hooking to fast-moving vehicles or pulling other players (help teammates climb or pull enemy from the cliff). Repair-pack allows small scale nano-forming of constructs. It's incredibly slow, due to working against jamming. But for small repairs it's all you need. Mining-pack allows (or increase speed of) mining. Or allows bypassing RDMS limits on mining after FFU are down (during battle). Equip more to be more efficient against harder materials (or even able to mine them), equip batteries for faster mining of soft materials. Control-pack allows piloting constructs. Take more to pilot bigger things. Can't think of a way to make it with battery... maybe each construct drains energy, so need high regen to control multiple small ones? Spy drone pack - allows third person camera. The further the drone, the more energy it uses. Equip more for better range-efficiency, equip batteries for longer fly-time at short range and quicker drone repair after it's shoot down. Nano-jammer - allows jamming hand-nanoformer (thus initiating combat mode). It keep working even after wearers death, until switched off manually. Because player would be limited to only 3 (maybe more, maybe less) modules, that would force them too specialise. For mid-range fire support it's probably smart to take shield+ammo+battery. For frontal charge into close range: shield+shield+shield. Combat medic would pick medic(active)+grappling hook(to pull downed allies into cover)+battery(to use ability more often).Or maybe shield instead of hook, to heal without worrying about cover. Surface-miner would probably take mining+battery+battery, while cave explorer: mining+storage+storage and deep miner: mining+mining+mining. Sniper: stealth+battery+battery. Maybe jump or hook to get to elevated positions. Close-range assassin may want more stealth than batteries, to close gap quicker. Maybe drone to know where to strike. All those would of course be available in various qualities, based on resources needed to make them. And character leveling could allow using those higher quality items. Or simply boost efficiency in specific field. I'd rather avoid forcing player to choose more than mentioned 8 elements - that would quickly grow tedious if you had to take 50 of them. What do you think? Any alternative ideas to encourage/force specialisation in infantry combat? Any more ability-modules you can think of? PS. I searched forum for: inventory, loadout, equipment, class. Nothing similar found. PPS. I refuse to call character leveling "skill". That's term I reserve for actual player skill, not how long they have an account.
  6. We want cargo freighters to be in game right? If the things stay as they are now they won't be a thing as players have huge inventories and they can store materials there, why would they need cargo space? Well, of course i'm not saying that inventory space should be realistic in size but i think the player shouldn't be able to carry more than around 300-400 m3. The excess should be stored in crates that would still compress the material and things. Crates should be only moved one by one or two by two. Yes i know it sounds stupid and boring but i know a few people that like taking things from A to B in games. As i said earlier there wouldn't be any need for starship size if there wouldn't be a need for cargo. It would be a minor annoyance to builders of course but i don't think it would make it unplayably hard.
  7. Will there be some kind of Network for Resources / Components like there is in Space Engineers? And if, how will it work? And if not, why not? How will the inventory in genereral be managed?
  8. A little survey to open several issues about builders user experience
  9. So how will the inventory system work, in the brief trailer we see someone produce a cockpit and part of a ship hull from what i assume is their personal inventory so I'm guessing it's quite large in fact large enough to hold all the resources to build a fighter, done with the shake of his glowing hand (some sort of nano fabrication or something). How does this translate to ships, am i going to have to pipe/conveyor the minerals mined by the drill at the front of my ship back into a storage container or will the ship be one entity and the container fill by itself as long as it's part of the ship. Considerations for the piping/conveyor system is that it would make ship design complicated but in a good way, interesting to do and something to think about carefully and optimise so you're not weighing your ship down with too much internal piping but also you then fall into having to have connectors on the ship to link to other ships/buildings/star bases that you wish to trade with. If you go with the one entity approach there is less to think about and your ship designing doesn't require you to think about internal mechanics and functionality. With regards to trading you can simple shift resources from one cargo hold to the other without regard for how (probably short range tele) if they are close to each other. Then you have to consider the range that this transfer can occur at, can it be increased perhaps by scaling to ship size or perhaps some sort of power hungry module like molecular transporters and can you build ones so big you can buy and sell remotely to an entire planet or Solar system. You could also go with the one entity approach and require direct contact between the two such as having to touch hulls or sit on a buildings/star bases landing pads. Also what considerations are there for people who want to steal cargo, can you simple rock up and hack into it, perhaps you have to damage it to a certain threshold before you can loot it or even destroy it. Circle back around to the building side, we see him use his glowing hand, are there larger ship sized module versions that i can put on the front of a builder ship to produce large objects or would we have to design a capital ship in person in small pieces (not a good idea honestly lol). Once i finish my ship and have the blueprint how will production proceed, do i need a factory with a big open space for the ship to spawn into as arms piece it together or will it just pop out next to it, I don't think a small space station or building should be able to produce something larger than itself. What are people thoughts and if any of these questions are part of other threads can you link them in please.
×
×
  • Create New...