wizardoftrash

Going to have to manifest destiny all up in Alioth in all honesty though that's huge! and to think there will be several planets to work with out of the gate!

Nice to see that Armor will be a thing, that would open the door to premium skins (that overlay on functional armor) to be a micro transaction item!

I'd say that having some very clear *hostile target* ui would be very helpful on the PVP side of things. If it ends up being something that we can script, even better. This would give us a chance to make pilot display a part of the ship-building process, and ship designers would be encouraged to take the time to add an elegant, maybe showy IU to their ship. I could see a sniper ship for example needing a bit more info on its UI than a dogfighter

OH WOW, this is EXACTLY the kind of thing I was hoping to see! I'm really impressed by the progress. By the time the Alpha is ready to rock, I'll have been done with GenCon 2017, so I'll actually have time to play!

Your objection regarding the realism of internal space in space travel is legitimate. This is the way that actual spacecraft look today, so I can understand how this is how you would envision it in a game. We aren't talking kerbal space program here though, this is a science fiction game. As such, the reference materials will include fictional depictions of space travel which typically include more interior space. Modern spacecraft aren't designed to be lived in, science fiction spacecraft are, and are modeled more after oceanic craft where humans spent long periods of time on them (for work and for fun). The "look" of a spacecraft where there are various control rooms, living quarters, etc is something a key part of the audience will be looking for in larger ships (which is the only kind of ship that will have to dedicate much space if at all to heat dissipation). For designers that don't want to create internal spaces like this, I've already described a method where players can "run" heatsink systems on the ship's exterior instead, so the option of designing a more modern looking craft will still be there. Each of those options will have its own set of advantages and disadvantages outside of the astetic factors (internal heat means pushing key systems to the exterior where they could be damaged, or forces you to make the ship's "hitbox" bigger. External head means exposing your heat system to damage, possibly leading to a backup or an outage). The system I proposed won't involve any real math. Heat requirements wouldn't be given in a conventional quantity, it'll be in cubic meters of heat dissipation area required, and those cubic meters are "projected" by the heatsink elements. A more hardcore player is going be planning their ships ahead of time in terms of where their actual system-blocks will be placed, heatsinks would provide some more depth to that process. A more casual player could easily add the heatsinks as an afterthought, either extending parts of their ship to get their other functional elements away from their heat "areas", or projecting their heat outside of their ship in fins or entente. As for how realistic it is to need to manage heat on a spaceship, our current spacecraft have no active shielding, no weapons systems, and no need for combat-level evasive maneuvering. Whether or not that need will ever actually arise in our lifetime is moot, it would be a fine game mechanic and this is a game first and foremost.

The process of buying and selling things in DU require you to physically travel to the Market Unit that is buying or selling things. If a player puts up an "offer" to buy 400kg of ore in a zone, you'll have to travel to that zone and deliver the ore to get paid. Similarly if you want to sell a blueprint copy, you'll have to "manufacture" the blueprint copy in-game, and travel to a Market Unit to put the blueprint up for sale. You'll have to travel again to buy a DAC to whatever Market Unit it is being sold at. The process of using the market in DU definately requires you to be there in the game. However NQ already stated that there would be a Free Trial period of 2-4 weeks, and during that trial a player could potentially earn enough in-game money to buy a DAC and become subscribed. Being able to use an offline ship editor to create ship blueprints might be a neat shortcut to starting that free trial with things you could sell, but there would be no way to test your constructs offline, it would be hard to gauge demand for constructs without ever having logged on, and people might not want what you built. food for thought. Currently though, Alpha and Beta players get to carry-over their blueprints into the main release.

Yes, I set this discussion up knowing this info. This was meant to hash out the pros and cons of a way to extend that Free Trial period in a limited way, or to set up an option for a previously subscribed player to re-join for a period of time (to liquidate assets and buy a DAC). So far, the cons seem to out way the pros with regard to a capped system beyond the Free Trial period. Some kind of capped or locked character system might be worth considering for returning players with lapsed subscriptions, but that's still debatable.

What Twerkmotor brought up here is a valid concern, if the number of automated turrets on a construct is either hard-capped at a certain number (for big multi-core constructs) or has a steep diminishing return (what I would suggest instead), there needs to be a way to mitigate placing several constructs in an area with auto-turrets to make a dense defense grid. First of all, these automated defenses will probably require ammo. If you "set it and forget it", even if it works brilliantly for a week it will eventually run out of bullets and be a sitting duck, regardless of size. Here is my solution (I'll edit the base post to reflect these restrictions). There are two environmental limiting factors on automated systems, mainly automated defensive weapons. Each Sector of Space, and each Territory on a Planet has a maximum number of entities (using a max of 3 for examples) that can have automated defenses "turned on" same time across all players (including logged-off, this removes the incentive to multibox or have alts set up stations next to yours). The server decides which entities' turrets get turned on based solely on the entity's type and size. -Mobile and Immobile entities are counted separately, but a parked ship could be counted as an immobile construct for this count. -The constructs with the largest core are counted first, ties in core size are then determined by which entity has the most cores, followed by who entered the sector/territory first. -Once an area has "counted" all of the entities that will be able to use their auto-turrets, anyone else that attempts to turn their auto turrets on will get a "too much interferance" error and they will not activate (nor will they use up computing power). -If a player owns a TU, they can unilaterally give out permissions as to which immobile constructs can turn on turrets. Even if they give out permission, the "max entities per territory" cap will kick in as it normally would. Again, parked ships could count as immobile constructs for this count (to prevent players from designing "ships" meant only to park and supplement a base's defenses). So what will this mean for fleet combat? for defending territories? Defending territories will be pretty simple with this system, you will be aware of what the entity cap is for a territory, and can build your defenses to best utilize that cap. When building defensive lines in space, it will encourage you to set up "layers" of defense across multiple sectors, which would quickly become impractical from a resource-consumption standpoint. If you have a TU set up, there will be efficient patterns and groupings that you'll want to utilize to better protect your territory, but even if you max out the defenses for a base it will not be invincible. The cap would be set in such a way that a single player, or small group of players might struggle to overtake a single "maxed out" territory, but a coordinated attack would certainly succeed unless the territory is well manned. Cities will have citizens to protect it, so territories will be able to rely on a mix of automated weapons and manned weapons to defend against attackers. "hey, doesn't that mean that a group of adjacent territories could concentrate their firepower at their borders, effectively stacking their defenses?" -Yes, to a point. This will be one of the many advantages of controlling several adjacent territories. The downsides to "chunking" your defenses is that they are more likely to have blind spots. This system has huge implications for fleet combat, and would serve as a strong deterrent for players "relying" on auto-turrets as an offense rather than as a defensive system. Apart form the efficiency loss I've already described, most multi-ship battles will turn on this auto-turret cap. The hierarchy I described as to which ships get the privilege to use auto turrets is set so that the ships that should be using them can do so effectively, mainly the bigger ships that also have crew. Here is a sample scenario of how that would pan out. I've got a fleet of a Large ship and a 6 of small bombers. My faction is attakcking your fleet of 1 Large ship and 3 cruisers. If the sector cap is 3 entities, then both of our large ships have auto-turrets, and the first of your cruisers to enter the sector does, but the other two don't. The large ships NEED auto turrets to defend against groups of bombers, so theirs rightfully turn on first. The cruisers want their turrets on as well, but they should be effective enough if they can manually fire a lower-class weapon at the bombers. Faction A has an incentive to keep all of the fighting in one sector (since a bomber won't have the Computing power to auto-fire anything bigger than a small machine gun, completely ineffective against cruisers and large ships), Faction B has an incentive to split up their fleet into two sectors (Large ship and a cruiser in sector 1, cruiser cruiser in sector 2, that way all of their auto weapons will work when the fighting starts). This creates some intriguing tactical fleet-command situations and makes coordinating large ships more complex. This also encourages players to design specialty ships for fleet combat, mainly small and medium ships with no auto-fire weapons whatsoever (since they are likely to be too small to have access to auto-weapons in fleet engagements). It is still Possible to multi-box with this system to a point, in theory i could build a Large ship decked only with auto-guns, and have make it follow around my Medium sized ship (that I control manually), but it will be ineffective against any equally matched ships that aren't multi-boxed and entirely ineffective in large engagements. Another key factor here is the weapon classes that can be effectively operated by auto-fire modules. Up until this point I've described how a ship could auto-fire a Machine Gun while flying, but would need to park in order to auto-fire a cannon. Machine Gun is what I'm using to describe a gun built to be effective against smaller ships and players, for example Large Ship machine guns will be effective agiainst Medium and Small ships, but not other Large ships. Cannons are built to take on a ship of equal size, and can't be efficiently set up to auto-fire. Torpedoes are built to take on ships of a larger class in a group (hence group of bombers above) but Torpedoes would be impractical or impossible to automate. If two Large Ships went head to head, one with a Manned Cannon turret and the other with auto-fire machine guns, the Cannon ship would crush it every time, but would struggle to fight off a group of fighters. A Large ship with auto-fire machine guns is built to defeat small fighters, but would struggle against medium ships equipped with Torpedoes. Automated weapons will be key to balancing groups of small ships against (even well manned) larger ships.

Thats all fine and good, but we are basing this discussion off of what the Devs have already stated they will be putting limitations on. This isn't even a "wouldn't it be nice if..." scenario, this is about the kind of game that the Devs want to make. They want the higher levels of play to require teamwork, so they plan to place limitations on automation. Beyond the Devs making the game that they actually want to make, beyond the negative impact that masses of automated defenses would have on the game, limits are what make sandbox games possible. The scifi sandbox games out there now don't try to limit these kinds of things, ans a server can support at the very most lole 25 people doind menial tasks? 5 or 6 people in combat tops? Picking your battles on limitation is what will make single-shard possible.

Duplicate post, please disregard. Tried to multiquote in an edit and failed miserably lol

I went on to outline 3 very different mechanics, so this isn't just a matter of what you call it.

Except that your quote ther was one of several bullet points, which means they are all seperate statements, seperate ideas. Those other concepts were mentioned in-addition to automated defenses for bases. At no point did they say in that response "no automated defenses for ships". They are being deliberately vague, and the most likely explanation is that it hasn't been designed yet (because it certainly hasn't) Automated defenses for ships might turn out to be impractical to implement for technical reasons, but they don't really know that yet and neither do we.

I intended to mean that "auto-fire modules" don't require the player to be online to work, I'll edit the base post to reflect that. Lets take a look about what NQ stated in that thread, nothing I've described conflicts with their official stance They made it clear that this hasn't been developed yet, but a few things jump out at me here. "piloting alone a multiplayer crew ship with maximum efficiency will be one of the things they won't be able to do." that seems to be what I've described so far. I outlined a concept for a multi-crew ship, and a method in which it could be crewed by 1 player. There is a huge efficiency drop when trying to use the Auto Fire modules I've described. " or basic automated defense, yes, there will be some - limited - possibilities" A hard-limit on how much automated firepower can fire at once seems limited. Being outgunned by any ship in the same class by a factor of 3 seems limited. One of your conclusions is that there can be no middle ground between Auto-turrets being completely ineffective and completely OP. I disagree with your conclusion. Yes the method I've described means that automated defenses on ships will be outclassed by correctly manned ships of the same class. However here are some game play situations that would certainly arise. An under-manned ship of the same class might struggle to overtake a ship protected only by automated defenses (becayse the pilot logged off). If you launch an attack against my AFK ship, and my ship was built to utilize an auto-fire module defensively, if you are solo-ing your 2-man ship it might be a fair fight. If your gunner disconnects or loggs off, you might be in for a fair fight. A damaged ship of the same class might struggle to overtake a ship that relies solely on automated defenses (because the pilot logged off). If we were part of a battle where I had damaged you and you retreated (but mitigating circumstances left me either repaired or unharmed), you could wait for me to log off or go afk and attack my ship when I park it. If you are damaged enough and don't want to risk me moving my ship so that you can get yours repaired, my automated defenses might put up a fair fight. A ship of a smaller class might struggle to overtake a ship that relies solely on automated defenses (because the pilot logged off). If decided to park my Size 3 ship, and you swoop in with your Size 2, my automated defenses might put up a fair fight. Those are each neat scenarios, they each represent a situation where automated defenses are consistently underpowered/inefficient in direct and even engagements, but where there is still a reason to have them as an option.

Easy solution: Automated turrets don't get any bonus from the player. If the gun uses a chance to hit solely off of the stats of the Autofire Module, then having an alt hang out on the ship does nothing for the turret. There could be different tiers of auto-fire module (some that have better gunnery stats), and it might require a minimum stat for a Ship Builder to install such a module, but a better auto-fire module might also take more Cells to turn on. The advantage would still squarely fall on the team of players each operating a cannon vs a single cannon operated by auto-fire. Since DU is going to be an aim-and-click system instead of a tab targeting system, there would be no way to alt your way to victory.

Actually we know absolutely nothing about what resource management options we will have access to with regards to constructs. The devs have talked loosely about Energy, but they have also talked about Fuel. What they actually mean, and what you think they mean might be entirely different. Similarly what I mean and what I think you mean are also pretty different here. I'll break this down real quick. Computing Power as I've proposed it here is a Static Balance mechanic (similar to Eve's Bandwidth). There is X ammount of slots, it can be allocated or re-allocated across systems that each require Y ammount of slots. You either have enough left and it works, or you don't have enough left and it doesn't work. There are only two options there and no in-between. If you have too many systems, some of them will never turn on. This leads to battles being decided like a game or rock-paper-scissiors. Power Generation (what I think you are discussing in your thread) is a Dynamic Balance mechanic (similar to Starmade). Your ship produces X ammount of power over S seconds to a maximum of M. Each system consumes Y ammount of power per tick, possibly over S seconds. If your total power consumption over time is higher than your power output, your ship will eventually stop doing some of those things as often, but it will reach a point where your ship consumes all of the power it produces and uses it as evenly across its systems as it can. All of your systems will work, just worse or less often. There are tons of possible outputs with this type of system, and it leads to Ship BLOAT. Bigger ship means more power generation, more thrust, more firepower, and more shields and the biggest fattest ship wins Fuel Consumption (something that the Devs have discussed but not in a detailed way) is also a Consumptive Balance mechanic. Your ship holds X ammount of fuel, and your systems each consume Y amount of fuel over S seconds of use. Ships that burn more fuel faster are more effective, but running out of fuel disables your ship. This is a "press your luck" mechanic and can create some interesting play situations, but if its the only factor, it devolves into Turtling and carrying more Fuel. Whoever still has fuel left wins. These 3 systems are each really different in how they make players behave, and most games use some combination of them. Starmade is basically a pure Power Generation system, and ship bloat is a rampant problem in that game (diminishing returns is what keeps it in check, and it doesn't really succeed. people use two really big ships instead of a huge ship). Space Engineers uses a combination of a Fuel Consumption method and a Statid Balance method, however there are two fuel types. The most powerful thrusters use Hydrogen (probably closer to what DU Devs mean by FUEL), everything esle uses "power" which can be generated very efficiently by uranium, or harvested sustainably through solar and batteries. Space engineers suffers form the worst cancerous version of Cube of Death in the form of exploitive alternative propulsion (gravity drives that can be safely buried in your ship) and turret spam, since turrets take almost no energy to run. Turrets consume Ammo, which makes them behave more like the Fuel Consumption balance method, but it devolves rapidly to whoever has the biggest spammiest turret walls. A Static Balance System would save us all a ton of grief. I have a hunch that the Devs will be using more than one method, and Fuel has already been discussed and I doubt it is the sole mechanic. That means that the devs will be using at least one other method to balance ships. If Thrusters could be balanced by Fuel consumption, and combat systems could be balanced by Computer Processing power. Energy (as you've mentioned) might be how industrial units are balanced. Since we have no real details about how Fuel will work, what Energy actually means when the Devs are discussing it, we have to really carefully iron out our definitions.

Without any hard caps, you end up with a little something we call BLOAT in SE and SM. You slap more reactors onto your ship, slap more thrusters onto it, and slap more guns on it. when your ship gets destroyed and you are back at the designing table, you keep slapping on more stuff until your ship looks like its full of tumors. Not limiting how many systems can be stacked onto a ship based on core tier is exactly how you get cubes of doom where the player packs as much stuff into their build area as possible. Some static limitation (be it CPU or Ram or whatever) apart from power regeneration makes PVP much easier to balance and allows the devs to include more actual variety in terms of systems and accessories. Having a "6 gun max" won't mean each ship of that class will use 6 guns, especially if we end up with a 1-man 1-gun system (as the Devs have already stated they would implement). If there is a gun that uses the same CPU requirement as 3 guns and has the firepower of 2.5 guns, any player who struggles to get a full crew of 6 is going to want to use it (resulting in either only 4 guns or only 2 instead of 6). Relying on market forces to balance inherently unbalanced mechanics isn't going to work out. Anyone that plays a collectible card game has had experience with this: Situationally better cards end up costing more money on the secondary market. This power difference is not directly proportionate to the increased cost, it is grossely disproportionate (a 0.3% win rate increase results in a 600% price increase or more). Having an unbalanced system that relies on market forces only raises the bar for how much you must invest to compete. This crushes diversity instead of promoting it and creates a chilling effect on innovation. If you have the power to create a more balanced set of weapon mechanics, the metagame will shape the secondary market and vise versa, but it can only do so in a healthy way if it starts from a balanced place.

Glance at my math on auto-weapons for ships before you dismiss it. With the proposal i've described, a ship that relies on auto-weapon systems has just over one-third the firepower of a manned counterpart due to the Cell usage, and that is not factoring in any other penalties an auto-controlled turret might have. This means two ships of the same class, one built to utilize auto-guns and one built to utilize more crew, the crewed ship would grossly overpower the under-crewed ship. That is a substantial advantage for additional crew and should prevent balance issues regarding "stacking" auto-turrets. As far as providing power to turrets, we don't really know what the power and fuel mechanics will be like for this game. We might find that Static Structures can generate power without consuming resources, or while consuming very little. They might decide that only mobile constructs consume fuel. The reason that I haven't mentioned actual energy/power/fuel consumption in this post is because we know so little about what the devs have in mind for it.

I've made this suggestion in another thread, but decided to break this specific suggestion into its own topic as per the Idea Box rules. Computing Power - How to balance Auto-Turrets on constructs EDIT: Before I define what I mean by Computing Power here, let me define what I mean by an Auto-Turret. Auto-Turret is a gun that can be manned by a player, but instead has an Auto-Fire module installed. When the Auto-Fire module is active, the turret with target and fire at attackers using its own gunnery and accuracy stats (no buff from a player) and will function even if there is no player online on the ship. It is a player weapon turned Automated Defense System. The purpose of this post is to describe a way where such a system could exist in a balanced way, in-line with the design intent of NQ. Let me define what I mean by Computing Power here. Computing Power would be a resource provided by core units of constructs. Each system that relies on computing power will occupy a static amount of your ship's total computing power, and only while it is "on" and in use. Flight systems, certain scripted elements, weapons, and auto turrets are examples of systems that would use Computing Power. This resource would be more or less a non-issue for most constructs and would mainly exist as a balance mechanic for PVP constructs. Here is a proposed example of the Computing Power resource at work. Medium ship core has a computing power of 80 Cells. Below is a breakdown of how my 1-2 player ship uses those cells. Flight control scripts require 40 cells. Flight controls might be a flat value, but with Lua scripting the door could be opened to have a more complex flight script that requires more cells. The ship's primary weapon (forward cannon) requires 25 Cells to aim and fire manually. The ship's secondary weapon (side-mounted gatling gun) requires 10 Cells to aim and fire manually. The ship's shield generator requires 5 cells to maintain, but requires 15 cells to re-boot if completely depleted. This means to re-boot the shields, the secondary weapon must be taken offline automatically, or manually. There is an auto-fire module attached to the primary weapon that requires another 45 cells to operate. I cannot turn this module on while the ship is flying, it must be parked. There is an auto-fire module attached to the primary weapon that requires another 25 cells to operate. I cannot turn this module on while the ship is flying and while the primary weapon is in use. This can be turned on if I'm flying solo and want to focus on maneuvering only. There are several ways the ship could be spending those 80 Cells of computing power, but I can't have it all. If I'm flying the ship solo, I can't use the Main and Secondary weapon simultaneously (since I'm just one player). I can alternate between the two, but I can't fire them simultaneously. I also don't have enough Computing Power to have my secondary weapon auto-fire while using the Cannons. If I had a 2nd player on-board, we could be using the cannons and gatling gun simultaneously, however if our shields drop completely, we would have to cease the use of one of our weapons to get our shields back. This creates some compelling pvp decisions as to when to turn off a system, when is the right opportunity to disable a weapon to re-boot the shields. If I park the ship, I can set the cannon to auto-mode, but if I do then the ship can't re-boot its own shields without taking the cannon offline. This gives the ship some means of defending itself while I'm AFK or logged off in a non safe zone, while also making it way less effective than if I were there to use the weapons. If I decided to put the Machine gun on auto mode instead of the cannon while parked, the shields could re-boot or re-charge without losing the gun's functionality, but it would be unable to drive-away a tough ship. Some other features of the Computing Power mechanic... Setting a hierarchy for use using scripting. Lets take the 2-player piloting example from above. If we are both using weapons and the shields drop, there is no longer enough Computing Power to re-boot the shields. With a scripted power-hierarchy, the ship could automatically disable certain systems to free up resources for essential ones (like shields or thrust). Sample or Default hierarchy... Shield - Passive maintenance Flight systems Shields - Reboot Primary Weapon Secondary Weapon Primary Weapon auto-system Secondary Weapon auto-system The hierarchy would disregard any system that is manually disabled. For example a Parked Ship would not consider flight systems when managing its hierarchy. That way the 2-player piloting example would immediately disable the Gatling gun when the shields drop and promptly re-boot the shields to recharge them. Similarly, when the ship is Parked, it could auto-fire the cannon and switch to the Gatling as soon as it needs the computing power to re-boot the shields. This same systems management would work for Static Construct defense systems as well, managing computing power for AFK shielding, managing which turrets should fire, etc. I envision that a large base might have an array of 12 auto-turrets defending the exterior and 6 anti-personal turrets defending the Interior. The interior turrets would be higher on the power hierarchy than the exterior turrets, since fighting off intruders would be more important than supplying Computing Power to the west side of the base (that isn't under attack). The base might only have enough Computing power to fire 3 of those exterior turrets at a time, but could power all 6 of the interior turrets (since antipersonell weapons are smaller, the targets are closer and not moving as fast). A Base might be unable to destroy a heavily armored troop transport ship, but the troops might not be able to overcome the anti-personel defenses and the Base would still be in fine shape. What happens when a player just sets up several constructs in a small area, each with automated defenses? is this haxx? Captaintwerkmotor brought up this issue. There are two environmental limiting factors on automated systems, mainly automated defensive weapons. Each Sector of Space, and each Territory on a Planet has a maximum number of entities (using a max of 3 for examples) that can have automated defenses "turned on" same time across all players (including logged-off, this removes the incentive to multibox or have alts set up stations next to yours). The server decides which entities' turrets get turned on based solely on the entity's type and size. -Mobile and Immobile entities are counted separately, but a parked ship could be counted as an immobile construct for this count. -The constructs with the largest core are counted first, ties in core size are then determined by which entity has the most cores, followed by who entered the sector/territory first. -Once an area has "counted" all of the entities that will be able to use their auto-turrets, anyone else that attempts to turn their auto turrets on will get a "too much interferance" error and they will not activate (nor will they use up computing power). -If a player owns a TU, they can unilaterally give out permissions as to which immobile constructs can turn on turrets. Even if they give out permission, the "max entities per territory" cap will kick in as it normally would. Again, parked ships could count as immobile constructs for this count (to prevent players from designing "ships" meant only to park and supplement a base's defenses). This system should help with server load, to prevent a hundred automated weapons all firing at once in a fleet engagement. It also perfectly prevents a player from setting up a ton of tiny structures with auto-turrets to protect an area.

This is a fun one. For mobile constructs, I could see not having auto-turrets... up to a certain size. A very very large mobile construct will reach the point where it will behave more like a static construct, and as such it should have access to auto turrets (assuming some form of auto turret end up in the game). I think that preventing auto-turret spam is a good goal, and it will be one of the balancing factors for PVP that will take quite a bit of work. In addition to constructs managing fuel/power and possibly heat, Constructs should have to manage computing power. Automated processes and possibly scripts ought to consume this Computing Power resource. However, Computing Power is provided by the core unit. This would give us a hard cap on how much computing a construct can do at any given time based on its size. A normal sized ship would use all of its computing power with flight scripts, and even the manual point-and-fire weapons would consume this computing power. This means a very large ship with simplistic flight scripts could have an array of auto turrets just like a large base would have. The fact that an auto-turret would consume a great deal of computing power means that there would be a limit to how many could be active at a time, and that auto turrets would be competing with direct-fire weapons for that computing power. This means a base with 12 auto turrets might only have enough computing power for 3 or 4 of them to fire at the same time, making it nearly impossible for one player to attack solo but easy to overtake with 3 players. A medium sized ship built for 1 player (that would normally accomodate two) might be able to support a single heavy direct fire weapon, and a single auto-turret as a tailgun. The ship would be unable to support them simultaneously, so that if the player is engaged in combat, the tailgun would not turn on and fire unless the direct fire weapon was not in use for an extended time. Depending on the other computing needs of the ship, the auto turret may only be able to fire with the ship parked. Does the proposed Computing Power mechanic pose enough balance for auto-turrets? On the topic on 1-player 1-gun which is something the devs have discussed, there would still be ways for a small team to operate several weapons. Imagine a ship with 5 weapons arrays but only 2 players. Those 2 players will not be able to use all 5 weapons simultaneously, and the ship should not have enough computing power for all of those weapons to operate at once (unless it was built for 5 players). Those 2 players though would be able to switch between those weapons to maximize their individual strengths and weaknesses. With 5 weapons systems, you could have 2 heavy and slow long-cooldown cannons, 2 rapid-firing machine guns, and 1 flak-style anti missile system. With 2 players, each could "main" the slow fire cannons, but switch to the machine guns during the cooldown periods of the cannons. If the ship and target ship are each maneuvering rapidly in a way where the cannons are impossible to aim, then each player might operate machine guns only until their target starts to flee. If the ship is locked for missiles, one player might want to switch to the flak gun. This team would only lose the DPS of the machine guns while aiming and firing the cannons or flakk, nearly as efficient as a 5 man crew. Should switching between slow and fast weapons be a viable option? As far as managing ammunition goes, there should be no reason to have to do this manually, but manning a gun might give you the option to change ammunition types on the fly (where having a script manage your ammunition might feed the same ammo type from the ship's cargo). Carrying ammo for the weapons could be an advantage in an ugly battle where you cargohold where your ammunition is stored could be damaged or destroyed.

We could even refer to this slice as the "No-Future" nihilist cultural group that is cannon to the DU lore. No Future in this case because continuing to grind does somewhat cap your growth potential (if you are having to serve others before serving yourself).

This is definitely a serious risk that should be added to the cons. It would hurt the game's reputation if a large enough percentage of the playerbase were parasitic players. But also too giving it a bit more thought, inflation of the DAC by increased demand would be a compounding problem. The more players that join the game and try to "earn" their sub, the fewer of them will be able to actually accomplish this. Locked players could quickly outnumber the subbed players even if Locked were only available to players who's subs have ended. That could create a great deal of envy and negativity between these two classes of player and it would erode the emergent societal structures the game is shooting for. What if the Locked status were an extention of the free trial, but also had an expiration date? For example, you would have your 2 week trial period, followed by a month with capped stats. At the end of that month, perhaps you can no longer log in, or you can only log in for 1 hour per week or something (to liquidate assets). Once a player subs, if their subscription lapses, they would have another month at capped stats? I'm trying to visualize the kind of player that would be worth having, but that would be unable to pay the monthly sub. Working adults who are already in stable environments like myself have no problem with subscriptions, and are the target audience for additional DAC's to inject into orgs or the market. University students typically have expendable income for games like this as a break from studying, but not always and wouldn't have the time to farm for DAC's except during breaks. The main group I would see wanting to earn DAC's to avoid paying subs, but would still be worthwhile players, are under-employed millenials (this is a big group especially in the U.S. and a year ago I would have been among them). It doesn't seem to me that two weeks would be long enough to reach that if you were also working. Suppose you burn both your weekends, that might only get you the right tools and a ship you need to earn Quanta but not enough to pay for a month. That one month with a skill cap might do the trick. We are still though talking about a small slice of the prospective player basis in one country. If the game comes close to being what it could, it should have no trouble getting players to sub. It could be that a month with a skill cap wouldn't be worth the time it would take to implement as a feature.

I think its worth noting that the only thing you can really gain is Time. Trading a DAC for reaources only saves you the time it would take to gather them. Trading a DAC for a ship only saves you the time it would take to design and build the ship. Sure you don't need to be specked in a required skill to make the ship, but it saves you the time it would take to provide the goods and services you would need to trade for the ship literally any otherway. People who don't work so many hours IRL and can't afford extra DAC's will be able to do those things themselves. People who work many more hours or have family commitments will have a shortcut. The kicker is that it is entirely up to the "working class" as to how much that shortcut will get you. Actual players will be trading for these and getting something meaningful out of it. Unless there are enough of the things floating around for the price of a DAC to hit a "stable" level, it'll be kind of the wild west. Will players base the value if a DAC based on some kind of in-gams hourly wage? We have no idea exactly what we'll be able to get with them.

Since Bleep_Bloop has nothing to add to this discussion other than we are wrong and fanboys, and we have nothing to add other than that we support NQ's decision, I think its time we let this thread die so that we can give it a proper burial.

Oh my, such good listening! Always on the lookout for tracks to listen to while playing Starmade (waiting for DU)

@Shynras, @Captaintwerkmotor legitimate concerns here. just to make this clear though, I'm not stating that I support a free option for the game beyond the trail period. This is meant to be a discussion of what the trial period could be and the pros/cons of different versions of it. If the Trial Period is just a limit on how long a character can play before paying, this problem might still exist. A potential fix would be... Having trial period players be labeled. That way orgs are going to be more careful about inviting them since they could be alts. The same could occur with Locked characters as well. Yes I've outlined these risk as potential cons. The cons might totally outnumber the pros, hence the discussion We also already know there will be a trial period, and this discussion is about that trial period. Your concerns are a valid contribution to that discussion, but don't mistake this for another "this should be f2p" thread.