Jump to content

Search the Community

Showing results for tags 'constructs'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Starting Zone
    • Rules & Announcements
    • The Arkship Pub
    • Novark's Organization Registry
    • General Discussions
    • Off Topic Discussions
  • Ideas & Gameplay discussions
    • Idea Box
    • The Builder's Corner
    • The Gameplay Mechanics Assembly
    • DevBlog Feedback
  • Fan Art, Fan Fictions & Roleplay
    • Novark Agora
    • Novark Archives
    • Novark Art Gallery

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Location:


Interests


backer_title


Alpha 1

Found 6 results

  1. SonEasterZombie

    Modular Weaponry

    Rather than cutting weapons up into several different ranges, classes, speeds, etc, I think it would be smarter (and allow for much more customization) if guns were put into a couple simple groups (Size of the base: anywhere from .25 meters to 100+ meters) as well as classifying the type of weapon they are (Spinal, Turret) plus maybe some damage types like kinetic, energy, or whatever. Everything else like range, speed, accuracy, tracking, and all the other stats that a gun should have can be controlled by modules, similar to the weapon system in From the Depths. Want a more accurate gun? Add a longer barrel. better tracking? Increase the power to the turret rotor system. This would even allow for an actual "Death Star" type ship in the game if a ton of people were crazy enough to assemble a massive ship with the majority of the interior dedicated to powerups for the one gun. On a smaller scale, it could also allow for ships to wildly customize their arsenal, like having a main gun designed specifically to take out fighters, or a high range and high damage but incredibly inaccurate gun designed for orbital bombardment onto a city. With a weapons system like this, the possibilities in PvP will be endless, just like they are in the rest of the game.
  2. discordauth:0S6nAq3GZzx_upvvOYmoheGfmYBOgJMRj6Hsnqip7rk=

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

    Computing Power - Balance for Auto-Turrets

    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.
  5. So NQ has stated that Construct vs Construct combat will be released in a future expansion, and that means in the meantime ship vs ship combat will be limited to boarding parties. I'm perfectly fine with this, and understand why they need to wait to release CvC combat due to development costs. However, this concept seems incomplete. How exactly does one catch an enemy ship in order to board it, without even basic CvC combat? Space is a big place, with a lot of place to run/hide, which is great, but a problem if you are trying to board a ship. It's not like someone is just going to pull over and agree to be boarded, unless they think they can win. Otherwise, the second another ship tries to get close, people are just going to leave. And with no way for ships to shoot at each other or otherwise disable another ship, there will be nothing anyone can do prevent people from just running away. It's not like you can lean out the window and try to shoot out their engines with a pistol. This would eliminate many forms of emergent gameplay: Smugglers Pirates Navies Police Blockade Runners Blockades Ships would essentially be nothing more than flying buses, perfectly safe from any sort of threat. Space would be reduced to nothing more than a means to get from planet to planet, rather than an interesting environment of its own. As such, I feel that, even if advanced CvC combat doesn't come out until a future expansion, there should be a basic system in place to allow ships to disable/immobilize other ships, so as to allow boarding parties to do their job.
  6. Will player constructed facilities in alpha be seen in the beta and furthermore in launch? Normally after one of these phases characters are reset and maps are cleared; however, based on the lore of the game Alpha players simply were woken up first, so if that is true, will anything we do in the alpha persist to the beta? As well as into launch?
×