Jump to content

Search the Community

Showing results for tags 'balance'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Starting Zone (EN)
    • Rules & Announcements
    • General Discussions
    • Off Topic Discussions
  • Starting Zone (DE)
    • Regeln und Ankündigungen
    • Novark's Registratur
    • Allgemeine Diskussionen
  • Starting Zone (FR)
    • Règles et Annonces
    • Registres du Novark
    • Discussions générales
  • Beta Discussion
    • Beta Updates & Announcements
    • Idea Box
    • DevBlog Feedback
    • The Gameplay Mechanics Assembly
    • Streamer's Corner
    • The Builder's Corner
    • Innovation Station
  • Organizations
    • Org Updates & Announcements
    • Novark's Registry
  • Fan Art, Fan-Fic & Roleplay
    • Novark Agora
    • Novark Story Time
    • Novark Art Gallery

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL










Found 7 results

  1. Warp: -make it so you have to warp from 5-10 SU outside of the safe zone (excluding the 3 inner planets) and leave warp at a similar distance. this adds risk to warp unlike the current system where you can just reap rewards from. -make it so your warp bring you out to a random position. this adds variation to warping and still gives players a chance of not dying instantly after leaving warp. -add the ability to warp as a group. This will solve a problem if you have all of the same size core or don't want to bring a bigger ship to be able to warp multiple ships out. Core sizes: -revert the radar changes to how they behaved before .23. this is a controversial point but one I believe is necessary as it will add variation to what cores people use for PVP. -give a ship with 10 gunners on it a place in a fight along with a ship that has 1. Reasons to fight: -xs cores should be used for fun with your friends, s cores should be a cheap entry level, m's should be the main stream core size and L's should be what you pull out for a big fight that you need to win. The game needs central point to fight over that aren't near safe zones. This could be: -Asteroids (supplies the game with ore) -stations (could have resources on the station or maybe a double talent point buff for a week for the org that controls it) -more rewards other than a fun experience to take away from combat. Armour: -nerf voxels. voxel armour is insanely good for tanking damage and not too expensive. -remove build mode when in PVP (could easily be triggered along with the warp drive cooldown at the begging of firing). This causes players to keep regenerating their armour throughout a fight further more making it harder to kill an already hard to kill enemy. -give a reason to not pile on more and more and even more armour onto your PVP ships. add reason to have the fastest ship on the field and reason to be the tankiest or reason to be a hybrid variant. -fix element obstruction, I shouldn't be able to sink an element in voxels to limit the damage it takes. weapons: -close the gap between different weapon sizes a little. smalls may hit an L core 100% of the time but their damage is so negligible your basically tickling the other ship. -the new weapon types are a good step in the right direction but I want to feel as though I'm using a different weapon not a buffed/nerfed variant of one that already exists. Overall this is just a list of changes i would like to see and believe will be best for the game.
  2. Hello Noveans! I'm quite new to the game itself and MMOs too, but something that definitely caught my attention was how the Industry is pretty much blocked for new players. Even when getting smaller/starter machinery, you just can't go on and start progressing, or even refining/crafting things that are possible using the Nanocrafter. But yeah, there's the question of balancing stuff, as it would be ideal to people having specialized factories for goods, plus not getting to endgame too early, so I was thinking of creating some sort of mechanic like a Research menu, where one can select an item from their inventory and start researching it. The original item would be consumed and maybe some extra thing could be required for this too (maybe research points, just like talent points), and after some time the research would end and we get an schematic of that item. That schematic then could be sold on the market or used on industry, whatever fits the player better. Doing so would reduce the need of bots selling schematics and would allow players to have an alternative way of getting schematics. One looking for a quick way could go on and buy the schematics from bots or other players, while other could chose to buy the item itself and spend some time researching it (if they don't have enough talent points). This also keeps the balancing that Schematics brought to the game, as they will still be something hard to obtain, but not so hard that the only way to get them is paying a very high price. Other possible thing on this is having a Tech Tree that works just like Talents, where one can queue up items to be researched, but with all the required parts and steps being required to be researched first. This would have no cost to the player itself in terms of having to buy the item first, but would require an extended period of time to have things researched, so we're exchanging time for money pretty much. That way one could also get basic industry Schematics while just investing time to queue them up... What do you guys think?
  3. Hey guys! I think you all know the Roadmap and that NQ wants to implement interstellar traveling in the game by using fixed, player built Stargates. I was wondering how they would look like and honestly, i think it would be awful to have like giant rings or something like a Portal with strange colorful effects in it. SO now that i explain my concerns iwant to Show you my idea: Stargates: - make them like a very big attachment to a starbase that consumes a hell amount of Energy BUT, that creates some sort of force field in which you can jump with very low fuel/Energy cost for your own ship (so its more economical to use a Stargate than to jump on your own) to another Station, that has such a device too. - space stations having such a device are important anchor Points in insterstellar space like beacons on the Ocean today Jumping on your OWN: - i think it would be very smart to implement hyperdrives in the game so that anybody that has installed one on their ship can jump to a certain range anywhere he wants (i know it sounds broken as hell because giant organizations could simply jump to any base of smaller organizations with armadas of hundrets of ships and destroy anthing in their way )BUT (and thats an ENORNOUS but): - with hyper drives it would be very balanced to implement them under the following conditions: - when not using a fixed Stargate at a starbase, you're going to have very high fuel/Energy Costs for each jump so the Energy/fuel for the hyperdrive will only last like 2-3 free jumps - in Addition without a Stargate you would have to predict your Dropout Location to end your hyperjump by yourself by Setting Course with a interstellar map to the star System you want to jump to and then charge your hyperdrive with the exact amount of Energy needed to end your jump perfectly (i personally would recommend to make the predictions as complicated as flying a plane in real life so traveling with star bases is even more necessary for new and Players that are not that hard into astro Physics and working at nasa ) - if your predictions for your Destination Course were wrong you can crash into objects like asteroids, planets or stars with a Velocity thats over 5000 times the Speed of light (for those woh dont believe that this Velocity actually is measurable thats About the Speed you Need to get over 1 light year in About 2 Hours) which will make you and your ship quikly disappear aswell as the functionality of your GPU (if your pc has the Minimum System requiremnts) so Jumping freely around is not just expensive but also incredibly risky I think by making free jumps to other star Systems possible without being completely Bound to fixed star gates, under the conditions labeled above, the game would have more for Senior Players and giving the posibillity to create new branches of skills for Players and for example even Opening new Job branches for organizations(because now they Need learned hyperdrive Navigators to make insterstellar travel without an existing starbase, which would be a very good Option for smaller organizations that cant afford an expensive, giant, shiny new starbase with a brandnew Stargate. That would also push Overall economy by improving the Need for People doing well in Maths and Physics. I hope that you can follow my thaughts well, especially NQ! :):):)
  4. 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?
  5. 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.
  6. 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.
  7. 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?
  • Create New...