Search the Community
Showing results for tags 'balance'.
Found 4 results
My first thought when I heard about the way they intend the single shard system to work with ship building and player density was "Well what happens if one person builds like 500 tiny ships and puts them in the same valley, free to tumble around and take up valuable server resources?" Another thing I realized once I had heard more about the way they intended the PvP system to work was that people could probably dock other "ships" to them that would function as extra fuel tanks, more armor, or even a shield if done correctly with dozens of tiny "ships" being flung towards an enemy to block line of sight. For these reasons, and more, I believe that there should be a limit to how many dynamic constructs a person can have operational at any time, based on a skill system. Not doing this would allow people to easily lag the server with hundreds of small ships bumping into things, and could also create some interesting but likely laggy pvp strategies. Perhaps a person could simply "deactivate" a ship they weren't using by turning it into a static construct, which is not subject to physics on the same level. But this also brings up something else, which is how far NQ will go with implementing carriers. Obviously if that is something feasible (it could already be in the game, I have no idea) they would want to do it, but what exactly would be able to be shared across 2 connected ships? I think that should be limited to fuel, storage, and whatever power system is added/is in the game. Allowing for a script on the mothership to control features on a docked ship would definitely be too far imo, but what do you guys think?
I'm not sure how the current system works, but in my opinion there should be a way to shift a dynamic construct into a static construct, and back again. To avoid glitches it should only allow you to change if you are not touching any construct (with the exception of docking/being docked, something else I know very little about as far as mechanics). If turning a dynamic construct into a static construct, a period of "anchoring" where the ship goes offline and must be defended for a certain amount of time will occur to avoid people instantly changing their ships to static or dynamic during combat. Assuming this isn't already in the game, adding this would allow for mobile asteroid mining facilities or forward operating bases during the siege of a planet or system. Please comment your thoughts or suggestions, as i'm interested to see what you all think.
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.
Similar scifi sandbox games suffer from a ship-building flaw where players have an inventive to include no interior spaces in their ships. (edited for spelling) Space Engineers, Starmade, Emperion all have a problem where even with big spaceships, players are rewarded by densely packing the ship with systems and armor and creating no interior spaces for players and decorations. Starmade is working on an overhaul for their power systems to solve this issue and I have a different idea for how to encourage players to build large ships that feel large, but have interior space. Heatsinks. Now I'm not saying that the power units for ships should create dangerous heat-areas that hurt players, however a system in which Reactors require space to dissipate heat creates opportunities for balance and build decisions. I will define some terms here so that it makes sense. Reactor: I'm referring to power units here. Different sizes of reactors would have different Heat-Outputs and different Heat-Dissipation threshholds. If you can get your heat dissipation above the threshhold for the reactor, it will operate at its highest efficiency. If the heat dissipation is below the threshhold, it would output way less power per fuel consumption. A steep decrease in heat dissipation (from the heatsink being severed or destroyed) could overload the power block, creating an outage or explosion. Bigger Reactors would have a higher Heat-Output and a much higher Heat-dissipation threshhold. Smaller reactors would have small heat-output and a much smaller heat-dissipation threshhold, and the smallest would require no heat dissipation whatsoever. Heatsink: I'm referring to the physical element or voxels that need to be placed adjacent to the Reactor to dissipate heat. This could be elements that can be inter-connected and chained together, or a conductive polymer that are palced and formed just like voxels (as an element would probably be the simplest to implement). When you connect a Heatsink to a Reactor, it projects a heat-dissipation field around it (1 meter on all sides when connected to a small reactor). This heat dissipation field's volume is what you need to reach the heat dissipation threshhold of your reactor, big threshhold means more of your ship's volume must be built to dissipate heat. This field wouldn't hurt the player, but any other elements placed within this field (thrusters, weapons, shield generators) would receive a massive performance drop. This allows you to turn space built for heat dissipation into interior spaces, since you don't want to place functional elements there. Larger reactors need much more heat dissipation, which will encourage players designing large ships even for combat to create interior spaces that could be decorated to look like living quarters, an engineering bay, or any other interior space. In addition, Large reactors would have a much higher Heat-Output. Heat-Output: is a property of reactors that determines how large of a heat dissipation field a heat sink will project. If you attack a 5 meter long heatsink rod to a small reactor, it would project a 1 meter wide heat dissipation field around it. Connecting the same heat sink rod to a much larger reactor would project a 5 or even 10 meter wide heat dissipation field around it, which will allow you to create a large heat dissipation area without packing the interior of your ship with "more" heatsinks. "cant you just have your heatsinks protruding out of your ship so that the ship denser and more efficient?" Good question, and the answer to that should be absolutely yes. This is why I feel the system would create some neat balance decisions. A builder could absolutely design their heatsinks so that they all protrude from the ship, projecting their heat-dissipation area into empty space so that it doesn't interfere with their functional ship elements. That choice would also create a vulnerability, as they could easily be damaged or destroyed during combat leading to a reactor outage or explosion (that's where that steep drop in heat dissipation would come from). A clever ship builder could even have their heatsinks recessed in their ship (where they might interfere with systems at full power), but use a track or roter to push the heatsinks outside of their ship when they need the most power, or if they need to turn on a 2nd bigger reactor (which would increase their heat-output, and make the heat dissipation area around the heatsinks much much bigger). Thoughts?