• Posts: 2,791
  • Tag points: 185

Topic: new ingame nap process PT 2 (alliance NAPs)

This would be built upon the idea below, so please read it first for background:
http://imperialconflict.com/forum/viewt … id=1632391

There is also another thread about Alliance NAPs below, though it is not related to the idea above:
http://imperialconflict.com/forum/viewt … ?id=182124

-----

Scenario 2: Alliance NAP Proposal

At the beginning of the round, family A decides on their core, before they pick allies.  A's leader is able to save this list of systems in-game, outside of just the map.  He can name it what he wants so he calls it "Family A's Core". (this feature doesn't yet exist).

A decides to ally family B, who has also saved their own core system list, as "Family B's Core".

A's leader decides he is interested in proposing a NAP to family C.  He wants his allies involved too though, even though he doesn't yet know who C's allies are.  He is just proposing the NAP though, nothing will yet be signed.  He goes to the new NAP proposal page and is presented with the following:


Family A drafts a proposal

[BEGIN DRAFT A NAP PROPOSAL PAGE]
What is the length of the proposed NAP? (24) (48) (72) (Permanent)
He chooses 48.

What, if any, systems are proposed as restricted for your family? [dropdown of system lists, with "none" as the default]
He clicks the dropdown menu and chooses "Family A's Core"

Will system intrusion violations require compensation for clearing? (Yes) (No)
He clicks "no", meaning he wants a NAP in which if C gets into A's core, they can be cleared without A having "trade" them out.

Any additional notes? [large text field]

Does this NAP involve any allies? (Family B) (none)
He chooses Family B.

For which family is this offer intended? [dropdown of non-allied and non-NAPped families]
He chooses Family C.  At this point, this is purely information for Family B.  When this draft is submitted, Family C won't know anything about it yet.

Does this NAP proposal included the allies of the receiving family? (yes) (no)
He chooses "Yes".

Submit Button: Send this draft to Family B.
This saves this particular draft with a NAP id, and sends it over to Family B's leader.  This would allow families and allies to manage different NAPs per family or alliance, as some will require modifications to cores, special conditions, etc.

[END DRAFT A NAP PROPOSAL PAGE]

Now, because unconfirmed ally details are involved he can't actually offer this NAP to anybody until family B accepts the draft, probably also adding their own core list.  That would go something like this:


Family B receives proposal

[BEGIN CONFIRM NAP PROPOSAL PAGE]
Your ally, Family A, has proposed the following NAP proposal to Family C.

Length: 48 weeks (change)
System intrusion violations will NOT require compensation for clearing. (change)
This NAP proposal includes the allies of the receiving family. (change)

Family A restricted systems: [link to system list, which would allow Family B to see the actual systems proposed]
Additional notes: [whatever notes A's leader wrote in]

What, if any, systems are proposed as restricted for your family? [dropdown of system lists, with "none" as the default]
He clicks the dropdown menu and chooses "Family B's Core"

Any additional notes? [large text field]

Submit Button: Return draft to Family A.
This modifies the original NAP and sends it back to A's leader.  Family C still doesn't know anything yet, as Fam A/B are just finalizing their offer at this point.  This is the only option if anything has been added or changed.

OR

Submit Button: No changes, confirm terms and send offer.
If for some reason B's leader didn't want any cores he could just accept the terms as is.  Obviously nobody would really do this, but the ability is important for the next step.  This is the only option if nothing has been added or changed.
[END CONFIRM NAP PROPOSAL PAGE]

Now, modifications can continue back and forth if the two families keep tweaking the terms.  At some point though, one family will say "ok cool" and confirm whatever the latest terms are.  When that happens they are simply signing the latest terms agreed upon, making the NAP proposal final.  At this point, Family C will see the offer for the first time, though their allies won't be made aware until Family C passes it on to them.


Family C receives offer

So let's say Family A and B have this offer finalized and get it out to Family C's leader.  He gets a page that is almost exactly the same above (slightly different description text), but now any changes he makes will render the NAP as offered "unsigned" so Family A and B can review said changes.  At this point C's leader can work out the details with A and/or B first or he can decide to pass the offer to his ally, Family D.


Family D receives offer

The order from here doesn't make any difference, now that everybody is aware.  The important detail is that if any of the 4 parties involved make any changes to the proposal, it will require everybody else to either accept them or re-modify the change (and explain why in the notes).  Once all parties have accepted the latest change, the NAP finally becomes official.


Alliance NAP is signed and official

With all that done, the NAP is signed and there is a NAP ID that can be referenced by any member involved from any family involved.  This would be linked to from the current relations page, instead of just the "break the pact" link.

As a bonus, the systems involved in this agreement could also now show up within the new map.  Family A and B would see something like "Fam C/D NAP cores" in their map-system list and vice versa.  This would allow them to more easily reference any systems they might want to avoid as per the agreement.


Cancelling an Alliance NAP

Also another important detail would be that because the parties involved are in pairs, in this example the cancellation of an alliance NAP would have to be agreed upon by both C/D before it actually happened.  Once they agree, the NAP is cancelled on all 4 parties at once and the countdown begins.  This is to prevent the scenario where D wants to cancel but C doesn't.  They signed the NAP together as an alliance, so the responsibility is theirs to come to an agreement before canceling on A/B.  If people do not want to do this they still have the option up front to do separate family-to-family NAPs for everybody involved, or an A/B <->C and A/B <-> D NAP.  However, such a NAP may be more difficult to attain than a "clean" Alliance NAP, but that's where diplomacy is involved.

In the end, this would give players total control as to the types of NAPs they wish to create and/or agree to.

Got a few bucks?  The Imperial Tip Jar is accepting contributions!

0 Dislike 0 Post Points

  • Posts: 2,236
  • Tag points: 27

Re: new ingame nap process PT 2 (alliance NAPs)

so get it done!

Solis - #7872

0 Dislike 0 Post Points

  • Lee
  • Player
  • Offline
  • Posts: 7,649
  • Tag points: 58

Re: new ingame nap process PT 2 (alliance NAPs)

yeh man stole my idea but implemented it into this overall new idea its still nice tongue

0 Dislike 0 Post Points

  • Posts: 2,791
  • Tag points: 185

Re: new ingame nap process PT 2 (alliance NAPs)

haha =P

It was brought to my attention elsewhere that alliance breaking could make this tricky, particularly in deciding it the NAP is void (no countdown) or just cancelled (countdown).

I think the best answer is neither, but rather instating a protected period of adjustment in which families involved get a chance to evaluate the situation.  So, in the example of A/B alliance NAPping C/D, let's pretend D decide they wants to break the alliance with C.  Their alliance NAP with A/B has a duration of 48 ticks.  It would play out like this:

1) The entire A/B <-> C/D Alliance NAP as it was is dissolved.

2) New temporary NAPs go out in the following form:
    C <-> A/B (new nap 1)
    D <-> A/B (new nap 2)
    The terms are based on the terms of the now-void alliance NAP.

3) All involved families must decide on the state of these new NAPs.  The time required to do this would be whatever the duration of the original NAP was, and during this time the NAP will still prevent attacks.  This will prevent alliances from breaking up temporarily to void NAPs instantly, and it will also prevent Family C from being left in the dust if/when D breaks the alliance.

4) After the decision period is over, if the respective NAPs have not been accepted by all affected parties, then those pending new naps will be dissolved.  This would happen separately for both "new nap 1" and "new nap 2".

If, for example, A is not interested in the new A/B <-> C NAP (new nap 1) but B and C are, the new NAP will be dissolved.  However, if B and C want their own NAP then it would simply be a matter of them proposing a NAP between themselves.  They could even do this before the "new nap 1" decision/protection period ends if they know A isn't going to be part of it.

That, as far as I can tell, should adequately cover the impact alliance breaks have on standing NAPs.

Got a few bucks?  The Imperial Tip Jar is accepting contributions!

0 Dislike 0 Post Points

  • Posts: 5,988
  • Tag points: 241

Re: new ingame nap process PT 2 (alliance NAPs)

I am not sure I think that is a good good solution.  Because (and correct me if I understood wrong).

Lets say if ranks are as follows

Fam A = 1
Fam B = 20

Fam C = 2
Fam D = 3

Fam A allied to B
Fam C allied to D

Effectively, if Fam A broke alliance with Fam B, then if C and D decide to not reinstate NAP, then Fam A has to fight both B and C.

I think to make it less complicated, after any one fam breaks an alliance, then the NAPs should automatically become individual.  Then it will be up to Fam C or D to cancel on A whenever they want, or even at same time.

0 Dislike 0 Post Points

  • Posts: 5,988
  • Tag points: 241

Re: new ingame nap process PT 2 (alliance NAPs)

^ This is the case for Alliance Breaking and how Alliance NAPs should be handled, that is.

0 Dislike 0 Post Points

  • Posts: 2,791
  • Tag points: 185

Re: new ingame nap process PT 2 (alliance NAPs)

You make a great point Torqez, though I still think making them all individual isn't sufficient.  Here's my revision of the alliance breaking scenario:

D decides they wants to break the alliance with C.  Their alliance NAP with A/B has a duration of 48 ticks.  It would play out like this:

1) The entire A/B <-> C/D Alliance NAP as it was is dissolved.
2) New temporary NAPs go out in the following form:
    C <-> A/B (new nap 1)
    D <-> A/B (new nap 2)
    The terms are based on the terms of the now-void alliance NAP.

That's it.  No more "review state" complexity.

I think the 2-1 NAPs should be preserved, because if I am in Family A and agree to an alliance NAP with C/D, I shouldn't have my alliance's collective protection compromised in any way because C/D decided to part ways.  If it just turned into individual NAPs (A <-> C, A <-> D, B <-> C, B <-> D) then my family is still protected but C or D could cancel on me without having to also cancel on my allies.

Their alliance being broken shouldn't involve my alliance's NAPs.  Handling things as described above would turn 1 alliance NAP into 2 smaller fam <-> alliance NAPs.  This seems the most fair to me.

Got a few bucks?  The Imperial Tip Jar is accepting contributions!

0 Dislike 0 Post Points

  • Posts: 5,988
  • Tag points: 241

Re: new ingame nap process PT 2 (alliance NAPs)

That could seem like a good way to do it.

Reason I was saying individual, is because in a 2-1 NAP, you're essentially condoning the 2 Fams to cancel on the now Single Fam and 2v1 them. Granted, this is actually possible now in current game, but it is generaly frowned upon (yep, game meta, and that 'where to draw the line' issue with ambiguities that come up as a result) for 2 fams to war 1 fam - allies or not. 

So essentially although the 2 fams have no obligation to not 2v1 the fam that broke alliance, they could potentially still get the option to cancel it as a 1v1 (either party) if they choose to cancel the NAP.  Again, this is relative (because say these 2 fams are much smaller than that original fam, they can still 2v1 or do w/e they want).


Also, to add another spin to this - what happens if Fam A, now wants to ally Fam Z?  In some situations, A will approach C and D to reinstate an Alliance NAP with Z's inclusion.  In fact, Z might also already have some diplomacy with C and D, so there perhaps needs to be some kind of consolidation or re-negotiation.

0 Dislike 0 Post Points

  • Posts: 2,791
  • Tag points: 185

Re: new ingame nap process PT 2 (alliance NAPs)

Hmmm that is true.  This would mean that in my example that when C and D end their alliance, they are each further shafted because they are now in an unfair situation.  If they cancel on A or B they are canceling on both.

This is a tough call.  I suppose as C and D are both already at a disadvantage it would be more balanced to have A and B take the hit of losing their 2-1 agreement.  Given that, I think you are right that just creating individual NAPs for the fams involved would be the best thing.


Regarding your example where a family is joining an alliance with existing NAPs, that is a very good idea to include a consolidation feature.  This could be part of a larger NAP modification process for any/every NAP that would behave similarly to the initial process, without having to re-propose from scratch.

For A <-> C and A <-> D, this would mean that for example A could "invite" D into their existing NAP with C.  This wouldn't be enacted until D also resupplies their core list, if desired.  This could also be D inviting A, C inviting A, etc.  The accepting party would be the one who would have to resupply their core list upon entry.

This means inviting a new ally to an existing NAP would be the exact same as consolidating NAPs for existing allies.  That's a big win from a programming perspective, though it means there wouldn't be NAP "merging" per se but rather NAP party acquisitions.  The old NAP would still have to be manually cancelled.

I can see this being very useful, but don't think it should necessarily be a requirement for this to get out the door.  I think we could get along in the meantime by just having A and Z propose a new alliance NAP draft for C and D.  If/when that is signed then the previous A <-> C and A <-> D NAPs could be cancelled manually, with the new NAP taking its place.

So I see this as several separate ideas now, built on top of eachother:

1) new Fam to Fam nap process
2) ability to modify existing NAPs (with acceptance of all parties required to take effect)
3) ability to create multi-fam NAPs, built on top of #1
4) ability to invite fams to existing NAPs, built on top of #2 and #3

Any issues with things as they stand now?  If this gets enough support I would love to prioritize this as an official coming feature.

Got a few bucks?  The Imperial Tip Jar is accepting contributions!

0 Dislike 0 Post Points

  • Posts: 5,988
  • Tag points: 241

Re: new ingame nap process PT 2 (alliance NAPs)

I like pie wrote:

Given that, I think you are right that just creating individual NAPs for the fams involved would be the best thing.

Ya, perhaps keep it simple for now.



I like pie wrote:

Regarding your example where a family is joining an alliance with existing NAPs
.....
I can see this being very useful, but don't think it should necessarily be a requirement for this to get out the door.

^ Agreed!

I like pie wrote:

Any issues with things as they stand now?  If this gets enough support I would love to prioritize this as an official coming feature.

Nope! Full steam ahead! big_smile

0 Dislike 0 Post Points