wizardoftrash

Also. OP seems to think the devs will make more money if those "on the fence" players have a way to play per-hour, but the reality is that the number of players for whom the monthly subscription is a deal-breaker is very very small. The devs stand to lose only a handfull of players at a discounted rate by sticking with a monthly sub, but stand to lose a lot per-player of the people who would happily pay the monthly sub if that was the only option.
 
flat-out, the devs will lose money.
 
I'd rather they collect that money and use some of it to improve the game.

Sooo... what are we thinking the price point would be?
$15/month is what, a max of $0.50/hour? But that's probably a discount for bulk rate/advanced pay.
So... $0.75/hour?
I have a feeling the vast majority of DU players are going to be playing more than 30 hours per month.
I think the minimum amount of hours to make much of any progress at all in DU is going to be about 16 hours per month.
So, at best, people paying by hour might save 3 dollars per month.
People who are so strapped for cash that they cannot spare an extra 3 dollars per month are not going to be playing DU anyways.

Hate to break it to you, but the full subscription is a "fair price", even if you can only play one session per week. Compare it to other forms of leisure activity, it is not uncommon to blow the full price of the DU monthly subscription in just one session of other leisure activities. I find the price to be fair despite the fact that I'll be able to commit one, maybe two, evenings per-week to play at the most.
 
play or don't, that's up to you.
 
Not to mention, those of us who have the money where the price is no-object, often don't actually have the time to play a ton. Those of us who can actually afford to spend money on DAC's to use in contracts in-exchange for the stuff we'd have to grind for. The folks that actually do have the time to play tons and tons of hours (students, underemployed) woundn't be able to afford an hourly rate that would be player-footprint neutral.

Hate to break it to you, but the full subscription is a "fair price", even if you can only play one session per week. Compare it to other forms of leisure activity, it is not uncommon to blow the full price of the DU monthly subscription in just one session of other leisure activities. I find the price to be fair despite the fact that I'll be able to commit one, maybe two, evenings per-week to play at the most.
 
play or don't, that's up to you.
 
Not to mention, those of us who have the money where the price is no-object, often don't actually have the time to play a ton. Those of us who can actually afford to spend money on DAC's to use in contracts in-exchange for the stuff we'd have to grind for. The folks that actually do have the time to play tons and tons of hours (students, underemployed) woundn't be able to afford an hourly rate that would be player-footprint neutral.

Also this argument is a bit of a hair-splitting fest.
 
Willing to pay to play for a period of time, but not willing to shell out for the price for a full month... There is no way the monthly sub is so expensive that it warrants alternative/smaller options. Either the game is worth its full fee or its not, fortunately once the game is actually released, a player would only need to "waste" 1 month's fee to discover that the game isn't something they like.
 
In this case though, the monthly fee is about as much as a Magic the Gathering player spends in a *week* drafting. This is about the cost of going to the shooting range once for a short session if you add in the cost of ammunition. This is the price of 1 decent meal at a restaurant, or an OK meal if you are drinking. This is about the cost of seeing 2 movies, or 1 movie and snacks at a theater.
 
Consider that so many leisure activities cost this amount in 1 session, but this fee pays for the full month. Even if you only play 1 weekend session per-week, that's 4x the entertainment-hours-per-dollar as those activities listed above.
 
I'd say we've exhausted this topic by now.

ITS TIME TO DU-DU-DU-DUAL?\
 
You've activated my Trap Ship!

You sir sound like a sore loser here lol.
 
From NQ regarding a similar discussion...
"Hi everyone,
  There is currently no plan of creating cosmetics related to Hello Kitty, My Little Pony on any related furry stuff.   Two reasons for that: - We have so many things to make having a higher priority before that. It couldn't be a priority for years, even after official release. - While we don't plan to restrict the creativity freedom of the players on this topic, we have currently no plan of creating such cosmetics because it simply doesn't fit with Novaquark's vision of the game.    We understand that some of you might be disappointed by this news, but as we never promised anything about this in the past and as we don't think this kind of cosmetics is compatible with the immersion we are aiming for (but not enforcing), there's very little chance this decision will be reversed.   Regarding symbols like the Swastika:  Although origins of this symbol can be found in Hinduism and Buddhism with no evil meaning, as it has been promoted by the Nazis in Europe and used as their emblem, this has been a symbol a lot of people don't want to see anymore in Europe because as it has been now tied to the concept of real life genocid. Letting such kind of symbols propagating in the game would be interpreted as promotion of the Nazism or to the very least a certain complicity with it. That's why we won't create cosmetics for such symbol, and we will take action if a player spots such thing in-game and report it.   Best Regards, Nyzaltar."

The Devs however have unilaterally decided that aliens/furries are not acceptable, because it does not fit their vision for the game. Game Design is as much an art (arguably more so) than it is a commercial product, the intent of the artist can matter more than audience demand here.
 
I believe that we can make some assumptions about what the Devs will find doesn't fit their artistic vision. A player stating that Wizard Robes or Dark-Age Platemail won't make it into the game isn't just a matter of opinion, it is a fair assumption that the devs wouldn't want to include something like that.
 
The pole itself is pretty flawed here though, since there will likely be a key distinction between Craftable Armor (functional) and Cosmetic Skins (nonfunctional) in the game. Polling vaguely about two different game elements as if they are one, and then asking players to choose if they should behave one way or the other way will create confusion, not useful data.

This topic has already been discussed in great detail in several threads. I would recommend taking a good look at it in the existing threads.
 
In short, they are basing their business model off of Eve Onile's model, which was quite successful. There is a way for players to play without paying a monthly subscription. Players will be able to buy a one month subscription (called a DAC) and sell it on the in-game market place for in-game money. If a player works hard enough in-game, they will be able to cover their monthly subscriptions that way. Players who are willing to put in the time to grind will be able to buy DAC's off of players who have IRL money but don't have that much time to play. neat tradeoff right? Similarly, one of my Orgs is designed to provide players with DAC's in exchange for raw/refined material.
 
It all comes down to this: their business model is pretty much set in stone. It isn't up for debate, players backing the project should all be on the same page on this one. There are plenty of F2P games out there, many of them are garbage, and this won't be one of them.

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.

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.

No one said anything about aesthetically correctness. This isn't about some design (the looks AND the effectiveness) of ships. This is only about balancing the game. You just can't give players total freedom with how many turrets/engines/elements a construct may support. There have to be balancing mechanics like power/cpu in order to make the game fun. Otherwise it will be just a min-max game. For dnd 3.5 fans this would be equal to a half-ogre barbarian/warhulk/hulking hurler with 60 strenght - which is ridiculous to say at least

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.

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.

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.

- Giving the ability to players to build some automated defense for their base.
 
 
That's what Nyzaltar said first and foremost. Base. Not ship. Base.

Problem is, the game doesn't work with te turret's hit-chance. It works with a player's SkillTraining, the thing that trains passively.
 
If nobody is controlling the gun, the gun has not actually 1/3rd chance to hit, but more like 1/18th chance to hit. And I am using th EVE model of skill-training bonii, since the DU Devs want to emulate that system for DU, with transversal speeds included.
 
And if the gun takes "bonus" from a player on the ship, then it can be cheesed by having an alt account with a trained toon for maximum accuracy. And the DAC system becomes "pay-2-win" alt system. You now see why NQ doesn't want very very VERY little autopoation. In EVE, peopel slave droens to one person and then let that person dictate coordinated strikes on targets. So one person can have 5 alt acounts, and then coordinating strikes one one person. I can do that in EVE, if I was a cheap shit like many of those people. I can afford to Buy 3 PLEX a month and fit sniper drone battleships and just wreck noobs for days. The only difference in DU is I got alts that provide bonuses to turrets on board thsip that are "automated. It's that simple. It's cheesing at its finest. 
 
You see, it's not Empyrion, where you aim and shoot based on "how good you are at eye-balling a target and landing the crosshairs on them". Your mathwork applies for THAT system, but not for DU's.

I'm just going to try and consolidate the ideas and run with them. What if the trial period was fairly unlimited (like in eve pre-alpha clones) but after that your account would be suspended unless you used a DAC. Furthermore trial players would be "marked" somehow so that if they applied to a faction the faction could see that it was a trial account. It would be very important to tell the trial player that this was happening and it also might encourage them to subscribe. For players who's subscriptions lapsed however you would get say 1-2 hrs per week for a month. Hopefully allowing you to get to a market and purchase a DAC.

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.

All right, as this topic is turning into a flame war, and there is nothing constructive left to say, it's going to be locked as well.
 
@Bleep_Bloop:
 
Having some skepticism about the game is understandable and even healthy.
We took the time to answer to your questions several times.
 
However since you started to participate on the forum, you made posts containing only:
- Negativity about the game
- Negativity about the people who endorsed the game
- Negativity about the game monetization model
- Assumptions that you know how business works in video games (while your oversimplified point of view clearly shows the contrary).
- Assumptions that you know what will be the developer decisions on critical matters (and always imagining the worst case scenario).
- Disregard towards opinions different from yours.
- Not understanding (or feigning to not understand) why people start to feel irritated by your attitude and bringing the "fanboy" or "white knight" excuse to avoid questionning your own attitude.
 
There is nothing constructive in your attitude and everything inciting to conflicts.
Again, while being a bit cautious and skeptical can be healthy, your attitude is way beyond that stage and has nothing healthy in it.
So a friendly advice: whether you make an effort of being radically less provocative and a lot more constructive, or we will start removing your posts without a warning.
 
@all:
Please don't feed the troll.
 
Thank you for your understanding.
 
Best Regards,
Nyzaltar.

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.

Edit: This post does not mean that I endorse this system, this is meant to be a discussion about the trial period. I will be adding peoples suggestions to the applicable pro/con list below
 
Edit: THIS thread is proof that we can discuss a controversial topic in a constructive and respectful way, I love what I'm seeing from this discussion.
 
DU will definately have some sort of trial period, however I haven't seen a dedicated discussion for what that trial period might/should look like yet. I've heard that Eve switched to a F2P system that includes a skill cap of some kind, so here are my thoughts
 
If the skills were sorted into tiered groups where the 1st tier allows the player to participate in that activity on a basic level, then a character could have their skills locked to 1st tier when their trial period ends or when their subscription laps. Let me define what I mean by lock.
 
If a Locked Skill is higher than 1st tier, it can no longer increase. The skill can still progress up to 1st Tier, however it will not go beyond it. If your skill was higher than 1st when it became locked, you won't lose your progress. You will simply be "stuck" at a low level until unlocked by renewing your subscription. Advanced skills that are 2nd tier or higher might be rendered unusable while locked, such as "advanced mining".
 
 
This means a new player could continue to play at a basic level once their trial ends, but would not be able to mine, scan, fly, etc beyond a very basic level. This would apply too for a player who's subscription lapses, they might be unable to fly their ship, might be unable to use certain ship systems, might be unable to build with an advanced polymer, or use their gun if the skill required becomes locked. If implemented, players might still need a limit to how long they can play while locked. If the full free trial is 2 weeks for example, the player might be able to continue playing with skill caps for another month afterwards. This locked status could also be a fallback specifically for lapsed subscriptions, to allow a player to consolidate and liquidate assets in order to earn a DAC.
 
This system wouldn't be perfect, but worth discussing and going over the pros and cons.
EDIT: At the moment the Cons seem to be way outweighing the pros.
 
Pros:
Working Class: This could bulk up the player count with redshirt level players. Evil empires need the storm-trooper equivalent now and then, big projects 
Demand for DAC's: Players will have ways to earn DAC's beyond the trial period, and would have a chance to sell off ships or materials for a DAC while locked if they return from a long break. More demand means a better Quanta price for DAC's, which means players with expendable income will have more incentive to shell out. More money for NQ makes a better DU.
Higher Demand for Economy Ships: If building a basic ship takes a long time or a lot of infrastructure as the Devs have implied, then there will be a higher demand for Low-tier ships/tools. Any items that can't be made by locked players, but can still be used by locked players will have a high rate of consumption. This would incentivize orgs to mass-produce efficient constructs and brand-names could emerge.
Could be a good marketing tool: It is hard to say if a capped play experience after the trial period would add much, but the frustration of trying to play while locked AFTER having the full experience might motivate subscription renewal.
EDIT: Suggested by mrjacobean - Less currency lapse: since players can still buy/sell after their subscription lapses, it doesn't cause currency to vanish with them.
 
Cons:
Server Load: The servers might bet bogged down by stat-locked players. Solution: auto-kick locked players during high traffic. Prioritize subscribed players first, followed by players that are in the trial period, followed by locked.
Gold Farmers: This opens the door for players attempting to farm for DAC's. This could be a bad thing.
Undesirable Players: Yeah I said it, players with less to lose are more likely to be a negative influence on the community. If creating a trial account is easy enough, we are more likely to get skummy players and trolls. If they can stay longer, there will be more of them and create a toxic environment.
Slavery: We see this behavior emerge in Rust, where large orgs take advantage of freshly spawned players and force them to grunt work. If orgs can take advantage of locked players without breaking the rules, it might make the game a worse place to be.
EDIT: suggested by captaintwerkmonger - Turncoat Nakeds: players using an alt to masquerade as newbies and sabotage a ship. Solution: Make trial-period characters labeled in an obvious way, do the same for locked characters.
Edit: Suggested by Shyrnas - Resentful Parasites: allowing players extremely limited access for free creates a resentful class of player. This resentful class could be a serious PR problem for the game, causing more damage than the option would be worth.
 
Thoughts?

Hi everyone, 
 
As it is pretty much the same discussion in two threads, I will lock this one and advise you to continue in the one mentioned below.
 
@Bleep_Bloop: please read the reply here (this is important): 
https://board.dualthegame.com/index.php?/topic/11087-game-looks-like-%E2%88%9E10-so-far-except/page-3#entry50966
 
Best Regards,
Nyzaltar.

Ugh!
 
Novaquark has told us which payment model they intend to use, and have ALSO said they will NOT be changing it.
 
This entire discussion has been re-rashed hundreds of times.
 
And BleepBloop brings NOTHING new to the table.

Yes, it has been mentioned many times that we plan to make a free trial period, and we don't plan to make anyone pay for the game itself. It's in the FAQ of the kickstarter page, and it has been said many times on the forum.
 
Best Regards,
Nyzaltar.