MineColonies

MineColonies

56M Downloads

[Feature] [$5] Colony Specialisations [$5]

marvin-bitterlich opened this issue · 7 comments

commented

Each colony should be able to have one specialisation that affects the whole colony.

Ideally it should give a bonus and a negative effect (with the bonus being more than the negative.)

Settable by the player in the TH GUI.

Example - "Mining Specialisation" - +10% Bonus to Mining -5% to Woodcutting (every 10th block harvested by a miner has a chance to give double resources, every 20th by the LJ is lost??

We should start with 3 or 4 specialisations and add more as new workers come on board.

So suggested Specialisms (as examples)

"Mining Colony" + Mining - LJ (will be beneficial to people going after a stone colony)
"Forestry Colony" + LJ - Mining (opposite of mining for people going for a wooden colony)
"Farming Colony" + 10% to Arable Farmer, -5% to Animal Farmers
"Rancher Colony" +10% to Animal Farmer Workers, -5% to Arable Farmers
"Defensive Outpost" +20% to guard Health/Damage, -5% Happiness to the Colony
"Metropolis" +10% to Colony Boundary range, -5% to resource generation (all workers)
"Cultural Centre" +10% to Happiness, -10% to Guards Health/Damage

Bountysource


There is a $5 open bounty on this issue. Add to the bounty at Bountysource.

commented

We could use the skills system to effect here.

The specialisations give skill boosts/reductions to the relevant worker types..

Or we could also use the happiness system.. Workers of the correct/wrong type are happier/unhappier depending on the specialisation.

Or a bit of both :P

commented

There are perhaps other static things we could do..

  1. Are we letting people change their specialization over time? I'm
    undecided on this.

  2. If we are going fixed specialisations, then we could for example for the
    mining specialisation say you can place an unlimited number of miners, but
    only a max of 2 lumberjacks ..

  3. If we go dynamic specialisations, then we need to have penalties for
    changing.. Easy ones would be a debuff to happiness every time you switch.
    or perhaps when you switch all workers of the boost type gain + 5 levels
    but all workers not of the buffed type lose 5 levels (min level 0 of
    course) - so swapping early on has no real detrimental effect, but late
    game swapping has a bigger effect. This means you CAN switch if you need
    an emergency boost (switching to military specialisation for an instant +5
    levels to your guards if your under attack) but the rest of your colony
    takes a hit... Could add some interesting gameplay/strategy options there..

On Tue, Aug 30, 2016 at 1:59 PM, Isfirs [email protected] wrote:

@Kostronor https://github.com/Kostronor and me came across we do some
kind of Buff system.

I am thinking how this could be done with less effect on hooking code.

I think of:

  • Extract the statistics (int, dex, etc) into a new class.
  • Add a field to hold applied buffs
  • Add an update() method that gets called from the entity update()
    method.
  • Use the getters to get the buffed value.
  • Add getters for other effects, eg.g. miningSpeed()


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#10 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUFcZmGkJajWR3Qf3cp7z99ibe0bz8QFks5qlCkZgaJpZM4JjuZ9
.

commented

I think dynamic is a nice way to do.

A scenario might be:

  • I click on the spec I want for now.
  • The colony turns into a CHANGING state, all buffs removed.
  • Apply producer debuffs to all producers, reducing the productivity
  • The switch takes x ticks. As long, the debuffs are applied.
  • Deny new colonist to arrive while in CHANGING state.
  • Happyness is reduced by 75% while in CHANGING.
  • Disable antigrief while in CHANGING

An overall addition: colony states.

commented

@Kostronor and me came across we do some kind of Buff system.

I am thinking how this could be done with less effect on hooking code.

I think of:

  • Extract the statistics (int, dex, etc) into a new class.
  • Add a field to hold applied buffs
  • Add an update() method that gets called from the entity update() method.
  • Use the getters to get the buffed value.
  • Add getters for other effects, eg.g. miningSpeed()
commented

Sounds to complicated to me...

Its only designed to give a slight difference between colonies, and
hopefully promote trading.. i.e. a group of friends are playing.. and say..
I'll go mining specialism and you go forrestry and ill trade my stone for
your wood. Overall they will both be better off, and it rewards players
who collaborate.

I still think just giving + levels to the bonus workers and - levels to the
others means the consequences increase as you play the game.. Early on when
workers are very low level you lose almost nothing from swtiching, but
later on when all your workers are level 20+ you start to lose quite a lot
from swtiching.

No reason to deny new colonists, or have a time frame for the switch TBH.

Plus someone could deliberately down skill their colony if they want (why I
have no idea but it could be done cycling between 3 different
specialisations.

I AM ok with a cooldown after you swap before you can swap again
though.. measured in a number of minecraft days perhaps. Or even you get 1
colony specialisation swap each time your TH is upgraded.. and at Max level
TH you can (one day) PAY to re-spec (3 diamond blocks perhaps)

On Tue, Aug 30, 2016 at 4:38 PM, Isfirs [email protected] wrote:

I think dynamic is a nice way to do.

A scenario might be:

  • I click on the spec I want for now.
  • The colony turns into a changing state, all buffs removed.
  • Apply producer debuffs to all producers, reducing the productivity
  • The switch takes x ticks. As long, the debuffs are applied.
  • Deny new colonist to arrive while in changing state.

An overall addition: colony states.


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#10 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AUFcZkE1aDtKYNutF-3mNDDXjU28iFh7ks5qlE6JgaJpZM4JjuZ9
.

commented

Worktime bonus would maybe be an option

commented

Closed in favor of a joint issue