Author Topic: HELP WANTED: MRBC League Concept  (Read 2392 times)

0 Members and 1 Guest are viewing this topic.

Offline VictorMorson

  • Lance Captain
  • ***
  • Posts: 532
  • l33tp0intz: +86/-27
  • WANTED: 24 counts of base rape and dismemberment.
HELP WANTED: MRBC League Concept
« on: July 10, 2011, 05:17:57 AM »
I’ve been thinking about how to make a League that’s highly automated, and wouldn’t require a complex amount of coding that would work with the MWLL community.  While I know there’s a new effort for a planetary league, I still think pretty strongly that the answer lies with a resource, non-planetary type system possibly.  As such, I’m putting up my rough design doc for the league.

Effectively, to get this going, we’d need an interested programmer.  I do not want to be one of those guys who “has an idea” and wants to contribute nothing, of course, so I am 110% willing to try to handle necessary art, dealing with fluff, working on the contract database and admin’ing it once it might actually see the light of day.  Furthermore, I’d be willing to make a forum thread test run of the concept.

The concept is simple.  Units join the League, they are given a C rating and a number of c-bills.  From there they purchase ‘mechs on the market, which have small price adjustments based on which popular models are bought.  Then they browse for contracts.

At any given time, there’s a dozen or so randomly generated contracts available in the automation.  Every single contract has two sides:  An attacker, and a defender.  Once a unit has signed on to both Attacker and Defender, the automation does two things:  Helps them get into contact with each other and setup a fight, for one.  Second, it takes the League Reporting at the end, to record who lost, who won, who gets paid and what salvage people pick up.

There’s no territory system with this league at all.  But what there is, is a setup that’s scaled far better to different units (small units can take contracts with small player caps, etc), and a lot more community diversity as units will end up fighting a lot of different players, rather than the same set.  This would also allow units to fight almost entirely as much as they want, be it a lot (accepting numerous contracts) or a little, without need to impose artificial limits.

Much of what makes a planetary league is still here:  Persistent resources and an important metagame, and unique scenarios that may leave you in unfavorable conditions (some contracts may be skewed so as not to be at parity - with the attacker or defender gaining an advantage in their contract.  More pay, better cbill limit in the simulation, access to support, one side having air support, etc.) - except without needing to track hundreds of planets or make small hobbyist units spend many, many hours managing thousands of ‘mechs in a spreadsheet.

Again, what I’m looking for is an interested coder.  I’d also welcome feedback to this whole thing.  If a programmer is actually interested in helping with this, the next step would be a small dry run of some manually created contracts in another thread, to see what units think about it.  What would mostly be needed is a front end (Unit logins, purchasing ‘mechs, taking contracts, messaging each other) and randomization system (for the contract to fill in the blanks below with a database of possibilities; also to reasonably maintain a close, if not exact, parity between attacker and defender contracts).

Anyway, without further ado, here’s my concept in wholesale:

MRBC League Concept

What’s required

    A unit messaging system.
    Unit Database - Reputation, available 'mechs, current accepted contracts
    Mercenary Unit Reputation system
    Contract System
    A database of values for the Contract System
    Post-Battle Calculations
    Admin manual editing of units (Unit setup, fixing bugs)

  CONTRACTS

   Contracts have two sides to them always, an attack and defense.  Once a unit has signed on to both an Attack and Defense sides, they are contacted by the automation and told to setup a battle date.  Attack and Defense are not always at parity - sometimes the attacking force can have more players, sometimes the defender can have more resources.  Payout is adjusted accordingly.

   Contracts are written in this format:
   [Planet] -Fluff Text here- [Contract]

   We are looking for an [Attacker/Defender] to [Mission Type].  [A1] to [A1] pilots can be used in the battle area, and [B1] c-bills worth of equipment can be transported to the combat zone.  We are paying a [C1] bonus for a successful operation with [D1] guaranteed payment.  [E1] salvage will be available.

 The mission is likely to take place on [F1] Terrain, over a series of [F2] drops.  Aircraft conditions are [G1].  Mercenary [H1] to repair bays for reloads & repair.

   Accept Contract?

    Contract Database:  Information pulled from a data pool
    [Planet] - The world this is taking place on.  Randomized from CBT planet list.
    [Contract] - The Contract Type, which will determine how the numbers are randomized. See below.

     A1 - Number of pilots available in the drop.  Such as 3-5, 6-7.
    B1 - The BV limit for the actual drop.
    C1 - The bonus paid if the contract taker wins the fight.
    D1 - The payment the unit gets, win or lose.
    E1 - The % of salvage given after battle results.
    F1 - Terrain.  If, for example, the terrain is “Desert” it’ll randomly select desert maps in the contact e-mail once both contracts have been accepted and the mission goes “Live.”
    F2 - # of Drops.  Some missions may be just 1 drop, others 3 or 5.  This is largely randomized based on the Contract Type field.
    G1 - What air support is allowed.  “Favorable to air support” or “Unfavorable” frequently.  Occasionally “Unfavorable for VTOL” or “Inhospitable to Aerospace” may appear instead, limiting it to a specific type.  Likewise “Restricted to # airborne unit” may also appear.
    H1 - Defenders occasionally have access to repair bays, as long as they have remaining c-bills.  This definitely changes the attacker’s strategies, but is a rarity.

    CONTRACT TYPES:

    Recon - Small numbers of pilots and very low battle values result in small light & medium ‘mech games.
    Raid - Typically invovling 3-8 players, raids tend to have a cbill drop limit to allow heavies and mediums, with the occasional assault.
    Assault - A planetary invasion that typically supports 5-8 players, with a cbill limit to allow for access to higher tier heavy ‘mechs and mainline assaults in addition to a mixed support force


    SPECIAL CONTRACTS:

    Air Strike - Air Strike is a contract occasionally available to Attackers.  No ground unit is required to win this contract type on their behalf, but all ground Defenders must be destroyed.  If the attacking force runs out of the ability to fight despite surviving, they are considered lost.
    Air Superiority - Both Attackers and Defenders are specificed in G1 that no ground units will be available, forcing both sides to fight a complete air war.

CONTRACT ACCEPTING & Resolving

    Once two teams have taken contracts that conflict with each other, a message is sent to both teams with the map selection (based on the terrain type).  The Battle Resolution screen becomes available to report ‘mech losses and who is victorious.  At this point both teams must submit a report to who the winner was, and what losses they took for each drop.  After this report is sent, both teams will see the other’s report and must CONFIRM it, or REFUSE it and go to admin arbiration.

    Once a contract has been reported (who won, who lost, what is lost), the automation will make a roll based on salvage percentage in the contract for the winning team out of all destroyed ‘mechs.  Salvage ‘mechs are immedaitely awarded to the winning team.

MRBC Rating

    MRBC Rating is figured by two things:  Team conduct and actual combat ability.  Winning drops adds to your rating, losing them detracts them - but also, forfeiting harms your rating greatly and incidents of violating rules greatly impacts the rating such as below:

    Sucessful High Drop mission:  +10
    Successful Low Drop mission:  +5
    Failed High Drop mission:  -10
    Failed Low Drop mission:  -5
    Losing a drop by not making contact with the enemy:  -15
    Rule Violation (minor):  -20
    Forfeited Contract:  -20
    Confirmed Cheating:  -50

    Scale: 
    F-:  0
    C:  250
    A+:  500

 Purchasing Mechs

    A ‘mech list is available to all units, every day.  The more a unit is purchased, the more it’s value will inflate - the more rival units in it’s weight class are bought, the more it will revalue.  Clan Tech has a flat +50% cost increase to it’s starting value.

    Mercenary units may own as many ‘mechs of any weight class that they wish with no restrictions, but they can only utilize what they own and within the value of contract limitations.

 Variants

    Due to the smaller scale nature of the League, Variants are treated as individual units.  They can be sold for 75% of their main value.

GAMEPLAY RULES - In Simulation League Rules

    Defender Advantage - If no losses are incurred on a drop, Defense wins an automatic victory.  Otherwise the side that destroyed more assets will win the contract.
    Living ‘mechs, regardless of condition, are counted as surviving at the end of the round for the winning team.  The losing team loses the entire force.
    Legged ‘mechs are counted as surviving until destroyed.
    Teams effectively have an unlimited supply of Battle Armor.  Battle Armor may be taken within pilot limits at only the in-simulation cost, with no metagame cost.
    Missions cannot be completed unless ground forces remain on the surface, unless explicitly stated by the contract.
    APCs may be taken to act as reloading centers.  Furthermore, the pilot of the APC may, within BV, purchase battle armor weapons and exit the APC on the field.  They may not, however, board a new ‘mech.
    Mercy is allowed - If the winning side does not kill the defender’s entire force, but an agreement is made between the units, the defender does not need to report living ‘mechs as dead.  They do, however, need to report they lost the drop so they will lose the contract.  This is purely at the discression of the winning team.
    Battle Armor is not allowed to knowingly camp inside of an object.  The enemy team may warn a BA that is hiding within a model in the event they do not realize it, but in this event the BA is expected to leave collision bugged cover immediately.
    All shots are legal.
I will personally hunt you down and poptart your leg while your back is turned and you're in your base.