Discovery Gaming Community
POB Change Suggestions - Printable Version

+- Discovery Gaming Community (https://discoverygc.com/forums)
+-- Forum: Discovery General (https://discoverygc.com/forums/forumdisplay.php?fid=3)
+--- Forum: Discovery RP 24/7 General Discussions (https://discoverygc.com/forums/forumdisplay.php?fid=23)
+--- Thread: POB Change Suggestions (/showthread.php?tid=180346)

Pages: 1 2 3 4 5


POB Change Suggestions - Champ - 06-02-2020

Player Operated Base Change Suggestion Thread

How about that! Another POB thread. From me, of all people. This time, it's going to be a certain way, though, because I want a catalogue of propositions that is legible, clear, and rational. We're going to use templates to outline succinct change suggestions, and similar templates to provide reasoned critique of others' suggestions. +1s are not necessary because we are dealing with the logic, not the popularity, of ideas (here). Read other posts first and do not post a suggestion that has already been made and isn't unique. Try to steer clear of exact numbers, because those can and will be argued later - give approximate ranges for numerical values instead. Here's the same thing and more in a list.
  • Read the thread before posting suggestions, at least the title, specifics and example sections
  • Read the entirety of a suggestion and any existing critiques of it before posting critiques
  • No +1s
  • No duplicates
  • Avoid exact numbers in suggestions
  • Critique concepts, not specific numbers (unless they're negatives where they should be positives)
  • Do not critique obvious typos
  • You may put multiple suggestions in the same post, but maybe not more than like, four?
  • Separate changes into individual suggestions rather than bundling them, unless it's the same concept
  • Link, don't quote
  • Stick to the templates

The premise is that these suggestions will be considered, eliminated and adjusted, and the specifics will be negotiated and decided thereafter. The goal is to improve the player operated base plugin. See the second post for examples of use and genuine ideas I had. If you know someone else had an idea and support them, encourage them to post here rather than trying to paraphrase their thoughts. Don't want any changes? I've included a poll above to help you contextualise this thread, but the poll is a poll, not a vote.

Simplicity, brevity and clarity are key.

P.S. I'm sorry if you're on the light theme but it's what you deserve and you know it

Updates:
  • Reply to critiques in your suggestion - integrate critiques into problems, edit and clarify your suggestion if there's a misunderstanding, or reply calmly and rationally in the discussion. Don't create critiques of critiques.



Champ's POB Change Suggestions - Champ - 06-02-2020


Suggestion

Type: Rules
Title: Increased base attack declaration lead time

Specifics
  • Change the time required for a base attack declaration prior to attack in the server rules to 24-72 hours.
Potential Problems
  • Base owners may be more prepared for an attack having the notice. May be countered by heavier automatic penalties for neglected bases.
  • Attackers have to wait a little while longer.
Example of Effect
Players are required to provide more notice for attack declarations. This prevents attacks being declared and commenced inside of a work or sleep cycle, and allows more time to notice the attack, organise, and maybe have a little time to prepare the base.

Further Discussion
It is unfair to use the OORP unawareness of players to gain an advantage, when inRP base staff would absolutely be aware of an attack, and when players, even groups, are not available every day of the week, let alone every hour of the day. This suggestion doesn't change how many players are likely to defend the base, meaning that if the attackers were going to win before, they're probably still going to win anyway, as they ought to in such a case.
Link for further rambling (this one's in a secret forum)


Suggestion
Type: POB Plugin
Title: New low-efficiency high-speed repair commodity

Specifics
  • Create a new repair commodity sold on "lawful capitals" and "unlawful capitals"
  • Bases consume this repair commodity at a much lower efficiency, but have a much greater repair speed
Potential Problems
  • Not sure if the base plugin can have individual repair commodities count for different amounts / speeds of repair.
  • Sufficient trading would overpower military attacks on the base, which doesn't necessarily make total sense iRP, but it doesn't have to; this is OORP balance.
  • Attackers have the advantage of the first move. But this isn't really a problem; it makes sense that you have to suffer damage before you can fix it.
  • Speed-runs during attacks. Docking must be disabled for every tick that a base is under attack, shield or not.
  • Practicality of this strategy is highly linked to distance from a lawful or unlawful "capital". More isolated bases are more vulnerable, but bases at a capital are just about invulnerable. The cap to usefulness is determined by base storage limit. This commodity should be so space-ineffective that leaving it there for repairs over time shouldn't at all be practical. Precision of the balance would be essential.
Example of Effect
Ten battleships attack a base for 2 hours, for a total of 20 hours game time. Later, in their own timezone, 10 defenders log transports, deliver this space-ineffective high-speed repair commodity for 2 hours for a total of 20 hours game time, and repair up to or a percentage of the damage caused by the attackers in the same timeframe. Whoever plays more wins. Groups are still able to intercept / blockade each other, so numbers do matter, but individual attackers / defenders still have a chance to deal some damage or supply some.

Further Discussion
Timezones are a pain! Bases have to be militarily defended when they're being attacked, but what if no defenders are available or awake? Currently there is no way for people to defend a base between the attackers actually being online. But what if there was? Imagine you have 10 battleships sieging a base for two hours. They log off. Hours later, defenders wake up, but there's nothing to defend against. So what if they could compensate for the damage dealt in a non-automatic way that doesn't cheat attackers of the damage they've achieved? Introducing, high-speed low-efficiency repairs. Defenders log transports, go to the nearest friendly "capital" where this fixed-price commodity is sold. It is far, far less space effective than normal repair commodities, but it is way faster. So, if 10 defenders fly 5K transports for two hours each, they can make up for the damage incurred in the same amount of game time. This means that bases right on top of inRP well defended locations are even safer than they already are with NPC patrols, and bases in isolated and dangerous locations far from civilisation are less safe.
NB: Lawful and unlawful "capitals" are literally house capitals and the unlawful equivalents and the further respective factions stray from each, the more dangerous the base is. This assumes unlawfuls can access each others' bases, which will have to be considered when selecting these locations.
Link for further rambling (also in a secret forum)
Reply to critique by darkwind: The commodity is for if the defenders are online, but the attackers are not. If the attackers are actively sieging the base, the best thing for the defenders to do is log a bomber or battleship and destroy the attackers. Indeed, as covered in the suggestion, docking during sieges must be blocked to prevent nonsensical blockade running to the base under siege.
Reply to critique by Anton Okunev: This is indeed a suggestion aimed at rectifying the problem of attackers and defenders being online at different times, but the point of this thread is to develop concepts as solutions for problems. I don't understand how your critique applies to the suggestion aside from that it is apparently similar to EVE which I don't play and Thyrzul's post which I didn't read in detail.


Critique
Suggestion Addressed: Delete the POB plugin

Problem Summary
  • Deletion would greatly affect existing established POBs and their surrounding RP and activity. It is likely to disenfranchise many players.
  • A replacement model would need to be sought for cloaks and special equipment.
  • The function of POBs as a motivator and money sink would leave a gap in the economy requiring rebalancing and redesign, including the creation of new models for money sinking.
Amendment
  • Instead of deleting the plugin, changes should be made to it that would make it easier, simpler, more pleasant, etc.
Further Discussion
The changes in detail are: what Champ says, because he is righteous and just the best, really. I would write more, but is it necessary to further flesh out why that's correct? Well, this is an example, so no. But if this were a real critique, it's quite probable.


RE: POB Change Suggestions - Grumblesaur - 06-02-2020


Suggestion
Type: POB Plugin
Title: Placement Constraints

Specifics
  • Plugin code would be changed to detect distances from certain objects in system.
  • A minimum distance constraint from mining zones, dockable solars, and lootable wrecks will be introduced into base placement.
  • Placement of a base will fail unless the constraints are met.
  • Failed placement will not consume resources, and will notify the player of the nearest object whose constraint they are violating in a chat message.
Potential Problems
  • Building in systems with many NPC bases may require base construction off-plane or off the map, which may introduce some navigational difficulties for first-time base visitors.
  • Scanning all objects in a system, filtering them by the relevant properties, and calculating distances may be non-trivial, and CPU time-intensive; however, POB placement is not a frequent operation.
  • POBs which predate this change will need to either be grandfathered in (and thus potentially have an advantage from proximity to other bases, NPC or player-owned), or manually relocated by a GM (which takes time away from other duties).

Example of Effect
By programmatically constraining the placement of POBs, less GM time will be devoted to moving bases which foul trade lane junctions, obstruct jump holes, or merely sit in illogical or impossible places.

Additionally, it prevents POBs from deforming the intended designs of systems by the development team. NPC bases, dockable objects, mining zones, and loot caches are all placed with certain intentions of creating player interaction, respecting the lore, producing aesthetics, and progressing the story. POBs can be used to subvert these designs, by shrinking the gap between a resource (wreck or mining field) and a safe haven. Nefariously-placed POBs can also create choke points or induce area denial (particularly through their weapon platforms) not intended by the systems developers. Sometimes they're simply ugly and unbefitting of their location.

With POBs constrained to a minimum distance from interactive objects in space, they are less likely to form redundancies and hazards, and more likely to populate frontier regions of systems.

Further Discussion
This would have a further effect of preventing the construction of "planetary defense grids", where POBs are constructed around a major solar in a system, with weapon platforms strategically arranged to create a protective bubble. As POBs are themselves dockable objects, the construction of adjacent POBs would not be possible.

During sieges, attacking players would find themselves at a disadvantage, as the enforced remoteness of the target will make changing ships or resupplying consumables difficult or time-consuming. For defenders, this would not change much, except for perhaps adding a few extra minutes to the cruise time toward the base.

Note that while it's possible to build a base in a remote location at present, many bases are simply built adjacent to NPC bases or other notable areas on or near the system's central plane. Requiring a certain amount of effort to place bases may enhance their security. The off-plane or off-map volumes of space are ultimately much larger than the plane plus-or-minus 10K volume that most systems' objects lie within.



Pseudocode describing the constraint-checking procedure:



RE: POB Change Suggestions - LaWey - 06-02-2020


Suggestion
Type: POB Plugin / Economy
Title: POB economy rework.

Specifics
  • Finally study how indeed POB interact with economy.
  • Change recipes for POB deployment and modules building with small amount of very high cost commodities.
  • Separate maintenance commodities from production ones.
  • Rebalance the production's economy.
  • If it possible, limit the POB deployment in 30-60k zone around a mining field plugin-wise (cross with Grumblesaur "Placement Constraints").
Potential Problems
  • The head of the economical development.
  • Math skills.
  • Dirty hacks needed to solve the mining POB problems.
Further Discussion
The general idea - POB should be money sink and right now they don't. POB interact with the economy, but it was ignored since implementation. POB should waste money and not time. Conventional money farm, incrusted in general game design, instead of unneeded, disconnected from other mechanics grind.

Critique
Suggestion Addressed: New low-efficiency high-speed repair commodity
Problem Summary
  • This is just further patchwork approach to problem of implemeting "vulnerability time and reinforcement" mechanic.
  • Just a subpart of more complex mechanic, cannot be considered in separation from it.
Amendment
  • Develope new siege mechanic concept.
Further Discussion
In short, this idea just further downgrade of Thyrzul proposal for "siege mode repair rate", which already was the downgrade of EVE "vulnerability window/reinforces" mechanics. Both of those proposals, in fact, trying to achieve EVE's multi-stage nature of siege through the distinction of in-siege and in-still modes. This is not bad idea itself, I just pointing out, that its all just different ways of how certain conception (relatively short, but multiple and intense fights determinating siege) can be executed. For proper discussion, we should first set a clear vision of siege conception, and only after this consider possible solutions for it achieving. That how we won't miss the problem's core.


RE: POB Change Suggestions - Sava - 06-02-2020


Suggestion
Type:Rules / POB Plugin
Title: Vulnerability time windows for POBs (tweaking of siege rules and/or mechanic)

Specifics
  • POBs can take damage only during a pre-set hours (vulnerability windows)
  • 2 vulnerability windows (about 1-2 hours each), one set by the owner, another by the attackers to minimize the impact of different time zones
  • The owner can specify his POB vulnerability window once the base is built. He can change it whenever he wants, unless there is an active siege declaration(can't change during the siege). Owner's base vulnerability window is made PUBLIC.
  • If owner's vulnerability window isn't specified, attackers can choose both windows for their convenience. Attackers' choice is made public in the POB attack declaration.
  • Since suggested windows are relatively short (no longer than 2 hours each), if owner and attackers time preferences are similar, attackers just have to put their window right before/after the owner's, I see no problem here. They can not overlap.
  • Maximal damage the base can take during the time window chosen by attackers equals to the amount of HP it can heal per 24 hours. Damage it can take during the owner's phase is unlimited.
  • Attack declaration expires in X days. However, If attackers manage to damage the POB below Y% of it's original HP, the siege continues until the POB is destroyed, or it reaches 100% of it's HP, and a cooldown period starts until next declaration can be issued.
  • Cooldown period is Z days (weeks)
  • POB shield efficiency, repair rate and max HP may require tweaking to make this work properly.
  • Can be done (almost) entirely by tweaking the siege rules, no coding required
Potential Problems
  • requires testing and proper balancing
Example of Effect
The fighting concentrates around 3-4 hours a day, much less exhausting and toxic for the players. To achieve their goal, each team has to succeed in the preferred time window of their counterparts. To overcome the repair rate, damage the base to Y% threshold, and subsequently kill it, attackers have to siege during the owner's vulnerability window (supposedly high-pop time). To let their base fully repair and claim victory, defenders need to brake siege during attackers' time window (supposedly night/morning time) in addition to supplying it.


Further Discussion
The attackers' phase damage cap is intended to, on one hand, make it impossible to kill a base when everyone but siegers is asleep, on the other give them a leverage big enough that, if not countered, will make defense impossible either, and the base can be gradually worn down by attacks (even relatively small) during defenders' time window. It has to be capped somewhere close the repair rate, otherwise it enables the much-hated 3 AM AFK krieg and almost complete absence of normal PvP, and I think everyone agrees that's not what we want.


RE: POB Change Suggestions - darkwind - 06-02-2020


Suggestion
Type: Rules
Title: Roleplayed for sieges Doomsdaydevice PoBs, siege PoB vs PoB

Specifics
  • People who want to siege some PoB should make a roleplayed doomsday device, which is essentially built by the same PoB rules another PoB to destroy PoBs from Core 3+ level.
  • Doomsday device would require in the same way month of roleplay and waiting a month to reach Core 3 for destroying Core 3 base, an additional month for Core 4 to destroy Core 4 base, and Core 5 to destroy unique Core 5 bases. (Basically same rules as building PoB)
  • Doomsday device is used once to destroy one PoB and it has HP, so it can be destroyed during the siege by defenders.
  • Event would come to, who destroys equal Core level PoB, attackers to attack their target PoB, or defenders to destroy doomsday device PoB
Potential Problems
  • attackers would be always in favor as they have siege weapons and multiple battleships prepared, while defenders would be needing the same and they would not be able to use bombers to siege doomsday device, except as using their bombers to disrupt attackers attacks. It should not be a problem if defending party has an allied party with a fleet of caps + bombers at its side in bigger number. But they would be needed orienting for siege equipment too for effect similar to attackers.
Example of Effect
Some PoB in Dublin has Core 4. Unlawful builds in whatever place in the same system doomsday device PoB. Once it's ready and roleplayed to Core 4 as the attacked PoB, they make attack declaration, pointing there attacked PoB and where the existing doomsday device.
Attackers successfully kill the PoB and it would disappear with a doomsday device
or Defenders kill doomsday devices and it would disappear.

Further Discussion
It feels nice that attackers would have to do equal work as Pob owner did for the base construction. And during the siege, it would be literally PoB against PoB, totally equal ground as both can destroy PoB.

Attackers would be favored due to having siege guns and better battleships, but their doomsday device would always disappear in both outcomes. So they did enough effort in transport hauling, attacks and roleplay to destroy other people's roleplay, efforts in transport hauling and defense to protect it.

It requires basically no PoB plugin tweaks. Everything can be done at the rule level.

Every time for every destroyed roleplayed PoB, attackers always pay with their destroyed doomsday device PoB also. Both losses are equal.
Defenders and attackers both transport hauled
Defenders and attackers both equally roleplayed and waited to build their things
Defenders and attackers both could siege opponent targets for a win.
Defenders and attackers both could use bombers to disrupt attacks.



Critique
Suggestion Addressed: To New low-efficiency high-speed repair commodity method
About balancing attackers with defenders by amount of battleships to transports.

Problem Summary
  • Ten amount of enemies against ten amount of transports would be not equal due to transports needing ten more escorts to clear their ground for supplying. So it would be 10 enemies vs 10 transports + 10 escorts to make equal ground.
  • Explaining the point above. Attackers need only fighting skills, defenders need fighting skills to clear the road for transports + a lot of transport hauling in addition.
  • Further upsetting the balance, battleships have siege guns making them counted for two. Or they just take rented multiple siege guns.
  • So 5 battleships working as siegers could make damage for 10 transports, and kill all transports as snubs, as escort can't even protect transports unless by scouting.
  • Low efficiency of escorts makes a separate point
Amendment
  • Choosing a different method of balance or making odds favoring transports.
Further Discussion
I mostly explained that in different points of problem summary. The point stands for attacking having only attacking skills, and defenders need to have fighting skills and transporting skills at the same time.


RE: POB Change Suggestions - SwiftWing - 06-02-2020


Critique
Suggestion Addressed: Grumblesaur - Placement Constraints

Problem Summary
  • Prevents intentional placement in proximity to another base
Amendment
  • On and off setting
Further Discussion
I only see one Major Problem with a Auto Deny Feature. If your a Member of a House faction and you want to put one close to another base, this would prevent that, when the System Government allows this. so maybe something like the Autobuy Plugin, on and off maybe, If it could be done.


RE: POB Change Suggestions - SwiftWing - 06-02-2020


Suggestion
Type: POB Plugin & Base Weapon Replacement
Title: Give a Base a fair chance of fighting back!

Specifics
  • 1. Plugin could be used to Activate on and off the Base mounted Weapons.
  • 2. Code change to allow Hardpoints on Base to accept Base made Cap Buster.
  • 3. Plugin, Separate Base Red List By Damage
Potential Problems
  • Coding to allow base to make a Cap Buster and maybe a Mid Ranged Fighter Bomber Killer Weapon on the base. And the Base Hardpoints to accept either weapon. Plugin, Separate Base Red List By Damage
Example of Effect
  • 1. As it is BS's Set outside the firing Zone and Kill the base the base has No real way to defend itself, and is really Just a sitting DUCK!. this would at least give a base a fighting chance. the weapons are not Rapid Fire weapons. but are fast enough to catch most players. Remember enemy ships can spawn and come back a Base Can't run or evade.
  • 2. Will Deter some attackers from taking on bases. Make them have to learn a new strategy other than falling asleep Firing in place. Each Core level could have Harder Hitting Missiles. But the Missiles would be Hard to shoot down.


Further Discussion



RE: POB Change Suggestions - Grumblesaur - 06-03-2020


Critique
Suggestion Addressed: Sava's limited siege window idea

Problem Summary
  • The intended behavior during a siege whose attackers and defenders have aligning schedules is not discussed; is this feature supposed to apply for all sieges, or only for the ones that have a temporal disparity between the attacking and defending parties?
  • If this feature must be used in all scenarios, and the attack and defense phases overlap either partially or exactly, does the damage cap take precedence, or does the unlimited damage rule take precedence?
  • If this feature is only used during scenarios where the time disparity is significant, it actively disadvantages players whose play times are off-peak.
  • Damage cap on defender's phase diminishes the need of defenders to actually defend their base during their chosen phase.
  • Assumes that only one siege on a base can be waged at once; that is, there is no consideration for separate, concurrent sieges against the same base.
Amendment
  • Eliminate the damage cap rule.
  • Describe rules for handling separate, but concurrently-declared sieges against a single base.
Further Discussion, regarding risk


Further Discussion, regarding time


Final thoughts
The siege time window suggestion does not solve a balance problem intrinsic to POBs, but tries to solve a problem of incompatible time zones that applies in the general case to all online activity in only the domain of POBs. Lastly, it narrows the availability of interaction with a base considerably, such that for the many hours not alloted as part of the siege schedule, the base has a far longer OoRP protection than normal combat rules offer.


RE: POB Change Suggestions - Sava - 06-03-2020


Suggestion
Type: POB Plugin / Economy
Title: Make POBs eat credits instead of cargo

Specifics
  • Pretty simple - make base consume credits instead of FOW, RA, RH, HS. Straight from the POB bank.
  • Re-direct traders from POB supply to regular cargo routes.
  • Wear and tear damage repair - 2 mil * core level per day
  • Normal repair - MODE 1: 1 mil per 1 million of HP; MODE 2: 3 mil per 1 million of HP, twice the repair speed
  • Numbers can be adjusted
  • this change only affects repair and maintenance, production and module construction still has to require cargo.
Potential Problems
  • Deprives POB sieging party of the ability to block essential supply routes (though it's not really a time-efficient activity for siegers and doesn't seriously affect the gameplay atm IMO)
Example of Effect
Trader.Joe now carries ores between Bretonia and Rheinland instead of following a 1-jump route 10 times in a row.
Wealthy players can sink their reserves.
Easier to consider costs and benefits of maintaining a base.
Maintenance difficulty will not depend on the base location, but POBs in remote and hard to reach areas would still sink credits and their usefulness would be questionable.

Further Discussion
-----