Durendal5150

From someone on the discord? ^^; There was a pretty lively debate about it once. If sources were cited, I no longer have them.

Well in most games it's not. Figuring out how to make it, if not fun, at least engaging, is a lot of what this thread has been about. That said, ultimately, whatever you come up with it's just not going to be fun for some people. Which is unfortunate, but, that just is what it is. As for selling scripts, my best understanding of the plan for that, last I heard, was that a script can be loaded into a sort of 'black box' package that allows it to be sold on the market, installed in elements, and utilized by others, but not opened, edited, or copied.

The Devs have explicitly stated they're against allowing the game to be over-automated. While I can only guess at their specific motives, I can present a few arguments: ~ Allowing the automation of the foundational economic activity has the potential to shut newer players out of the economy if they can't afford the methods of automation. ~ It would also make botting extremely easy, further upsetting the balance of the in game economy. ~ Ultimately, the game isn't about automation. It's about player activity and player experience. If one of your activities is so menial and mindless that no player wants to engage with it and would rather see it automated, this is probably an indication that your design and mechanics are flawed, not that the activity is inherently undesirable play. I think automation would ultimately just be a band-aid. If the gameplay isn't satisfying in and of itself, there's a problem. And allowing the player to skip it without developing new foundational mechanics around the automation that are fun, (See: Factorio.) isn't going to do anything but make an entire sector of the game not really part of the game.

Megaddd covered this relatively well. I'd refer to his post. 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 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. 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.

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.

@CalenLoki That's fair. I figured that 'ruined' ore would just be replaced with a lower grade variety. Hitting 100% ore with a strip miner only nets you 10% ore, or something like that. Plus the risk of a jam. Your adjustments to the displacer are spot on though, that works better than my idea. Four is needed because the other tools do not work via scripting, same as weapon elements. They're some sort of big arm/turret a player has to manually aim, select an area with, and initialize. I'm pretty sure NQ has been clear they want to to keep automation out of resource gathering, and I agree with that sentiment. Hence my description of all of these as some sort of nanoformer or nanolathe variant and not as physical drills or cutters. They're 'turrets' or emplacements that require manual targeting. At least, that's how I'd go about keeping them balanced with hand mining still, and keeping the player engaged with the activity. We talked a bit on the discord about the idea of hazards, as an aside, and came to the conclusion it was a good addition. This would be that rarer and deeper ores would have pockets of explosive gas, unstable minerals that could damage tools/avatars and other hazards surrounding them or embedded within them. The idea here being these would be avoidable or mitigatable with suitable *player* skill, thus raising the skill ceiling of mining as a loop. At the moment, most of the focus has been on adjusting for *character* skill, but I think mechanics that make the loop fulfilling for a range of player skills are highly desirable for a number of reasons.

To go back over the points above addressing your specific concerns. The idea is to make the yield not change so much as the kind of resources that are required and how. Construct mining is intended as a sidegrade activity in this proposal, not a direct upgrade. Asteroid mining, as I envision it, requires both approaches. To get the most yield, someone needs to clean a rock of all the high-density nodes before the remaining ore is stripped, or they'll be wasted. Automated mining isn't part of the above, and shouldn't be. Construct mining elements would operate much like hand tools do, and require player input directly. Ultimately, the idea is that both kinds of mining will have loosely the same profitability, and a good mining operation will utilize both techniques to maximize it. Since there are types of ore in the above example that construct miners (at least expensive, strip miner kinds,) can't work on. - - - - With that in mind, let's prevent a few speculative examples of such elements: 1: Mounted Nanoformer What it says on the tin. This is a hand nanoformer on a stick, that can be used from a construct to make use of its mobility and/or larger inventory. No other benefits over doing it by hand. 2: Terrain Displacement Unit A big tractor/presser beam thing. Can reshape terrain but not actually collect anything. Displaced terrain is either moved physically elsewhere or destroyed. Great for digging tunnels or smoothing roads. Gives access to other terraforming shapes. Utterly incapable of collecting anything. 3: Industrial Nanoexcavator The actual strip miner. Picks up huge swaths of terrain and low grade ore. Works slower on medium grade ore and may not give full yield. Jams on high-grade ore and ruins it. Can't actually place terrain back down like the other tools. 4: Large gauge laser/tractor bore Speculative. This would be a static-construct only thing or maybe only work when the construct isn't moving. Fires a big-ol mining beam straight down. Picks up things just like number 3, and mostly good for digging initial mineshafts or very long tunnels. Probably operates somewhat slowly, or at least slowly without a player operating it. Those are a few basic examples, anywhere. I'm sure grades and side grades of them could be thought up.

I don't see the problem this is trying to solve. If the above is all implemented more or less as I envision it. (however well I've communicated that so far.) there should be enough moment-to-moment choices to keep it from going too terribly stale. The inclusion of hazards in mining (Such as volatile minerals, gas pockets, etc.) might be one way to offset the tedium of it and introduce some more player skill.

Now with Visual Aid!

Fair point. I actually hadn't wholly considered the effect on players by experience and wealth. Was more concerned with 'has constructs that mine' vs 'doesn't' but it does mean there's always a niche for newer/poorer players to fill in the loop, without dumbing the whole thing down. I might draw up some quick sketches to illustrate the idea further at some point here.

I much appreciate the well-wishes. I hope I can live up to my outline as the game gets done and the org continues to (hopefully) grow. On that note, I'd like to lay out precisely what is is were' seeking from who here: New Players: Volant is dedicated to helping new players learn the game, and to giving them productive things to do in the process. If you're looking for support and hands-on, no-pressure training, we're here to get you up to speed. Old Players: We're always on the lookout for talent in a number of fields. Primarily in mining, logistics, industrial applications and related fields. As well, we're eager to recieve positive individuals able and willing to pass on their skills and knowledge to other players. Org Leaders: Any business needs business partners, and VTI is no exception. We're willing to discuss potential deals with any other org. Additionally, if your org is small and in need of support, Volant is willing to act as an umbrella, either through direct in-merges or subsidiary incorporation.

Glad to have you aboard! Always good to see new faces around here.

@CalenLoki I'm going to have to agree with @AzureSkye's assessment here. Much of the reason NQ has said they need to use a lock-on combat system is to avoid a lot of the server overhead. It, as Azure notes in his second edit, helps with lag compensation and to hid necessary interpolation. I think everything you've written about selective damage is cool as hell, and seeing FTD-like damage mechanics in DU would be amazing. But It really is way too much overhead for the limitations they have to work with. At least to the best of my understanding. It may be possible to give *some* realm of selective targeting against certain constructs. possibly by breaking them up into zones and directing the attack against one with the most visibility by LOS or something. To avoid the 'blowing up things that are mostly underground by shooting the antennas' problem. (Good call on that one!) So one thing I do want to address specifically is Calen's comment about skill over luck and Azure's suggestion that AvA should be free-aimed, kinda at the same time. A big part of the system I was proposing (extrapolating, guessing at.) is that it's simple and it specifically removes player skills with high ceilings from the equation. It retains the vital 'intelligent' skills of combat. Positioning, usage of cover, all that tactical stuff. But it explicitly removes the higher ceilinged twitch skill of aiming. Both because of the limits of the server architecture, and because ultimately, despite its presentation, DU is simply not a typical action game. It can use some of their conventions and presentation, because they're familiar and comfortable to most gamers. But ultimately, the twitch-shooter crowd just isn't the core audience, and there are no NPCs. If all combat is PVP, it shouldn't be skill gated off and made the realm of CS vets who can snap-shot you in a quarter second. I think you are right in the assertion that player skill is important and should be rewarded, but it's important to consider which skills should be and to what degree, to make sure the game remains accessible through all of its loops to its core audience. As a last note, I agree with Calen that shields are a questionable addition. Traditional 100% mitigative, 100% cover shields remove all economic risk from committing to battle with a lesser opponent, continuing to balloon existing advantages that larger craft and richer players will naturally have. I don't think the solution is, necessarily, "have no shields," but it's possible to implement them in ways that lessen those advantages. An example I've considered; have shields be pin-point affairs. A shield generator needs an operator, just like a weapon turret. It can be aimed at one enemy ship, and provides its protection against them for the duration of its operating cycle, at which point it has a short cooldown before being 'fired' again. This shifts a little advantage to smaller craft (Which we can assume there will be more of,) as well as reinforcing some of the multicrew gameplay NQ really wants to focus on.

That makes a good deal of sense, certainly. I don't see a lot of reasons to prevent modification of a purchased object, so long as copy/pasting from it and re-blueprinting it are prevented to protect the IP of the original holder. I think the idea to combine the master copies of several iterative blueprints back into a complete singular master is a good idea as well. Simplifying the life of anyone who's been given full rights to the IP of all the involved items isn't a bad thing by any means.

Let's start this one by reiterating the first part of the title. This is all wild speculation on my part. Though some of it is, I feel, extrapolation and inference. A combination of what's been said about the combat in DU, (very little.) with my sense of game design and the probable best ways to make this work. Let's start with what we know and why. It's been well established that DU will have "Lock on combat." So what does this mean? There's no saying with any precision. But what it most certainly isn't is combat with active player involvement in aiming, physically modeled projectiles, or any of the other trappings of most high-end combat centric games. The why should be obvious: The difficulty of tracking all of these disparate elements is likely to overwhelm client and server both. While it might work with very large player counts, it isn't as scalable as the alternative. That alternative of course, is to remove the player's aimpoint and projectile modeling from the equation entirely. Instead we simply determine have the player choose something tos hoot, initiate the attack, and after some fairly simple math, the outcome takes effect. In most other games, the input scheme for this is rather banal. The player clicks on, or selects from a list, their intended target. The player selects the attack to initiate, usually by clicking it from a hotbar. The attack is calculated. This is a tried and true interface method. But it lacks engagement with the player, isn't terribly immersive, and would be awkward in DU's seemingly always-first-person gameplay. So. Provided we have to remain within this framework of "The player selects a target and attack, and everlasting else the system handles," what are some possibilities? Let's start with a potential case of on-foot combat between player avatars. (At this point, as an aside, I ask you to excuse my crude example visuals.) (Screen gratuitously ripped from one of the tutorial vids.) So in this example, we have a single potential target, and we have a black circle that represents the player's 'targeting area.' (It was translucent blue, but I am a smart man who collapsed the layers wrong.) Since the player has, we assume, his combat mode/weapon tool selected, the target zone appears. There's a potential target in that zone, so it's bracketed in red. We can assume, in the image above, that if the player clicks his LMB and fires the weapon, that this is the target he's going to be attacking. So what if there are more than a single target? Here another key. (Tab perhaps?) Could be used to cycle the brackets to another. Or the RMB used to 'aim' at the target closest to the center of the cursor. It's possible we can also determine if there are voxels or terrain in the way, to what extent, and flub the hit percentage (or disengage the lock entirely) if line of sight is lost, without any extreme levels of computational overhead. So, in this way, it's possible to essentially 'sneak' the lock on system the scope of the game requires it to use into something that has the surface appearance, and many of the gameplay loops and conventions, of a more typical shooter. The attacks hit chances could be modified by aiming down sights. Targets could take cover and benefit from it. Pretty much the whole nine yards. Since precision aiming isn't required as well, this also has the added effect of giving us the tactical elements of more conventional games. (Placement, cover, movement.) without requiring any snap reflexes from the participants. Let's move to a space combat example using some similar assumptions! (Also ripped shamelessly from the youtube channel) So here we have a very similar setup. There's a target out there. He's got brackets. And we have an aimpoint of some sort. But in space, we don't need that guy to be *in* our targeting zone. We've got sensors! So we resort to a target selection system more like a traditional space sim. T for nearest target. hold it to select the guy nearest the center of your aim point. All that good stuff. Once the target is within your aimpoint, and you pull the trigger, your attack is calculated just like above. This gets us, once again, all that positioning, flying skill, and maneuvering. Just sans the need for aiming skill, or the need to calculate all the business involved with manually aimed weapons. So ultimately I think the main point here is that I feel like, when NQ says that DU has a 'lock on combat system," there's still a wide amount of room to work within that frame. They could quite possibly make the system feel more action-oriented regardless with the right approach. A couple closing thoughts: A weapons stats coupled with a players stats could govern the size of their aim zone in AvA combat. There's a bit of an edge case when the target is obstructed by another valid target, or a friendly actor. We could possibly just assume that line of sight is broken in this case, or just choose to hit the obstruction. Gunners in larger ships would probably use basically the same system to operate their turrets as the pilot uses in the above example. Last thing, I'd like to keep this discussion as largely as possible about the possible implementations of combat, and their repercussions for the game and gamestate. So I'm politely asking we try to avoid the topics of the nature of weapons systems, (Although mechanics is of course fine.) appeals to realism, potential stats outside of mechanical necessity, and all those sundry topics. Unless you've got a Really Good Reason, of course.

Oh that's weird. It should be the blue highlighted one at the bottom of the 'starting zone' if you've got patron status. (which I see you do!) If you want to get right into community stuff and haven't already, you can drop into the official unofficial discord: https://discord.gg/eSJ6wEs Folks there can help you out now, and get it set up so you can get help and all through it come the next test as well! Glad to have you aboard!

https://community.dualthegame.com/organization/volant-transtellar-incorporated https://discord.gg/5yb2zna A Firm Foundation Empires. Armies. Nations. The ambition of the Novean population leads them to lofty goals. But from the moment they're awakened from cryosleep, those goals will be as distant as the stars they've just traversed. Volant Transtellar approaches this new world with the humility of our situation in mind. As a company, and as a wider populace. Our immediate goal is to provide the foundations of Novean society. Resources, infrastructure, training. Before mighty vessels can ply the spacelanes, trucks and buses must ply the roads. Simple aircraft must deliver citizens to their duties. A strong economy must begin at the bottom before it can rise. A Vanguard to Dreams VTI needs you. It needs your drive, your creativity, and your spirit as a builder. Before the lofty dreams of a new world can grow the simple work of sowing its fields must be done. VTI has no aim to be at the forefront of armies, or atop the halls of power. VTI, and you with us, will be the pavement on every street, the wings of every flight, the strength of every tool and the comfort of every home. Where other organizations strive always to be at the top, VTI strives always to be at the bottom. The underpinning that holds aloft the dreams of our peers. Angled Ever Upward If you are an individual with a need to build, and a passion to hold aloft your fellows, then Volant needs you. Whatever experience you bring will be welcomed with open arms. If you bring nothing with you but the spark of a creator, Volant is here to give you the tools and understanding you need to succeed. If you're the leader of an extant Organization, Volant can use you as well. We are always on the lookout for new leaders and new potential. Your Org could be welcome into ours, and retain much of your autonomy and flexibility as we strive towards our common goal. We're also always on the lookout for subsidiaries to aid our endeavors. Volant Transtellar. Rise with us, wings outspread. And lift the world behind.

That's a lot of complicated additional mechanics to control for something that I think the original suggestion does more elegantly. I don't see the need to create new usage cases and mechanics to stop the player from AFK mining, when just saying 'you can't program resource collection elements to work autonomously' is a non-feature that costs no additional dev time or complexity overhead.

Ahh, I get you. No, none of that requires anything to do with blueprints, and I imagine would be a factor of the RDMS as it applies to IP in general. What I'm talking about is pretty much a totally separate thing from that, at least mechanically.

Well, the point I'm making is you don't have to make miners just a thing that always mines to the front. Or acts like a drill and mines whatever it touches. You can make them tools the player has to aim and control like weapons, or like a larger version of the existing terraforming mechanics. If you were going to have mining devices that could be automated, I'd have them such that they just stop on ore completely, or destroy it instead of harvesting it. So they're useful for huge terraforming projects and nothing much else.

I actually considered this very problem in the process of falling asleep last night. I think the simple answer is 'ship tools aren't programmable.' It's already my understanding that NQ have no desire to let players program weapons systems on constructs to be automated. The tools can simply be the same. They're extensions of the players skills that require those skills to operate. I imagine something high-tech like a wide-area nanoformer, oscillating tractor beam, or other things that require the operator to direct and use them. Not just big drills and grinders that can be pressed against the terrain and collect it as they go. Edit: I like the idea of vehicle tools that are expressly for terraforming a *lot* by the way. It's something else I'd thought about myself. I think that falls right into this same vein of 'player extension' too. Terraforming elements are just like hand tools for it, but BIG. Same as the mining elements operate.

Schematic isn't suitably clear, no. delta-print, maybe. I considered "Iterative Blueprint" because the shorthand would be simple. You'd just have BPs and iBPs, and all the follow-on acronyms. I hadn't considered working original blueprint permissions into the idea to that level, but I think it's a good move! So, the reason I did include 'you can apply a mod with only the original blueprint' is to add flexibility. What if the original designer isn't a manufacturer? WIth the ability to just manufacture a modded construct directly by using a BPC and an iBP, the designer can license his IP directly to a manufacturer that wants to make the modded version, without any interim steps or third parties. I don't think you'd want the ability to 'combine' mods as this could get sloppy. I don't see any reason why an iBP/schematic can't itself be iterative, requiring copies of all previous modded constructs/BPs, or being applied one at a time. It may be better to keep the whole system as simple as possible, yes. I'm not 100% sure that's the case, as you lose some flexibility, but there's definitely merit to it. I'm not sure I quite understand what you're asking? If it's something akin to 'could someone make a business solely of designing and applying modifications to existing designs' then yes, that'd be an intended effect of this system.

So here's one from the discord. Idea courtesy of TheGreatPigeon who assures me he's too lazy to post it. I like it enough I'll put it up and give my thoughts on it. The basic gist is to allow a construct made from a blueprint to be edited, and for those changes to, themselves, be saved as a blueprint. Unlike a normal blueprint, this new type (We'll call it a 'schematic' for now,) can't be used in a factory by itself or to make new constructs. In order to be used, it requires either a construct the original blueprint was for, or a copy of that blueprint alongside it. A usage case: X designs a fightercraft that's fairly popular. Z finds that it's undergunned and a little slow for his tastes. He adds some more weapons, changes the materials to lighten it up, and adds a sick spoiler just for fun. When he saves this, it becomes a schematic. If he has a copy of X's fighter, he can apply that schematic, in a factory or some other industrial unit, or possibly directly to the construct using guides and his nanoformer. If he has a BP, he can put both into a factory and produce a copy of the fighter with his schematic already applied. If he has neither the fighter or the blueprint, his schematic doesn't do anything at all. So this achieves a few things: 1: It allows iterative creativity while still protecting the IP of the original creator. 2: It can drive market sales for all parties. If Z's schematic is really popular, People are going to want to buy a lot more of X's fighter to get to use it! 3: It can allow players/orgs to customize their own variants of a construct without needing the original designer to do the work themselves, but still get paid for their original work. Now obviously, as a toggle, a BP could still have an "Allow/Disallow schematics" sort of option, to give the original IP holder more control. But I think a system like this could allow for some very interesting interactions to take place, without any enormous degree of additional complexity.

'We are considering the possibility of Mining Units inside your constructs, but this will be in an expansion after release and it will require some careful balancing to make sure standard mining is still an option, in particular for beginners.' ~Dev Blog So after reading this I got to thinking, how can this be balanced out? What problems does the idea represent, how does it disrupt the mining gameplay loop, and how can we solve this? So first, let's lay out the problem. The primary issue is one of progression. Mining by hand is a given task. Construct tools for the task increase the efficiency of this task immensely. Otherwise why would the player choose to use them? One might imagine a huge nanoforming device dissolving and scooping up huge swaths of land and ore in a fraction the time it would take a player. Obviously, this takes a lot of utility away from players without such devices. How can they compete? Why even try? But with a little thought, we can turn this right on its head. Make this a vehicle for emergent player choice and 'real' progression(1) rather than linear A->B improvement. The first step is to change up how ore voxels work. Instead of generating a Vein of X copper ore, as an example. Now we generate that vein, but we also pick a grade for the ore. This could be a variable percentage, or simply a low/medium//high variety. So a vein of 10,000 ore might be a small vein of pure ore, or a huge swath of mostly chaff minerals a half kilometer across. So now, we have room to make different approaches to different situations by tweaking how the tools themselves interact with these ores. On the one hand, we have low grade ores. Strip miner elements excel here. If you tried to mine this by hand you'd get nowhere at all. Pockets like this might go untapped for much of the early game because trying to mine them is so horribly uneconomical. But once you've got strip miners, suddenly they become a new potential source of material. On the far end, we have high-grade ore. Dense, slow to mine, and where hand mining excels. The huge, imprecise, and jam-prone methods of the strip miner fail here. Such a machine will ruin the ore, giving you only a pittance of the yield otherwise, and the process of melting down this dense chunk is just not what the machine is for at all, and will take just as long or longer as mining it by hand. So now we have, in the environment, a number of varying situations that call for different approaches. Some require artisanal mining by hand, some require the application of enormous strip mining equipment, and most importantly, both are valid, equally important choices at different levels of accessibility. It's also worth noting that mining elements don't have to necessarily be more powerful. You could have a simple, construct-attached version of the hand nanoformer for the benefit of greater storage via an attached hopper. You can have the strip-miner described above, or you can have something inbetween. Ultimately, the point I'm making here is that the key to balance for player resources and experience is, imho, to make different approaches valid in different situations, instead of viewing them as a clear progression. Hope my thoughts on the subject are useful! Edit: (1): I felt I should clarify what I mean by "real progression" since it's not really clear. What I mean by this is making the player able to interact with, utilize, or achieve something they were previously unable to before. As opposed to linear "illusory" progression where the activities in or state of the game world don't change, but the player simply becomes more efficient at them. (Or apparently more efficient in some cases.)

Yes, I am the man who tells this man who to shoot in any game. I can verify both his skill at the shooting and lack of silicon based mindstate.