[Proposal] Open Perks System + Community Perks Pack

[Ippo]

Hello everyone,

I'd like some feedback on what is, at the moment, just an idea.

Some of you may have seen that the latest release of my mod includes a perk system. However, it is pretty much baked into it and can't be used as an API, if anyone else wants in on the action. I was originally planning to separate the system in the long run, but since RoverDude has expressed interest in the idea, let's start working on that now.

The idea is to have an API in place that will allow the definition of perk trees, shamelessy ripped off inspired by the Skyrim system.

In short, there will be multiple independent trees, each one defining the various perks (or skills: what's the best name?) in a tree structure where perks are unlocked sequentially. The trees will define the possible paths and skills, and each kerbal will have his own personal set of unlocks.

Unlocking the perks will be done by expending perk points. A perk point can be of two types: shared (it can be used for any kerbal the player sees fit) or personal (it can only be used on the kerbal that acquired it). Additionally, a perk point can be restricted to a set of perk trees or left available to spend on any tree.

The acquisition of perk points will be left entirely for the mods to implement, so that every mod can use whatever logic makes sense for it. For example, you might want to unlock a perk point every X hours of flight, or only upon particular events... your choice. In the same way, OPS will only handle the perks, not their effects: client mods will be entirely responsible for the implementation of whatever effect they like.

From a technical point of view, my mod Crew Files already provides the necessary tools to store any information about a kerbal, while perk trees information can be safely stored in a scenario module. Of course, perk trees will be defined using cfg files, and this brings us to the second half of the proposal.

We will also need a shared set of basic perk trees. Much like Community Resource Pack, using them will not be mandatory, just convenient as it would allow standardization between any mod that wants to use a perk system. Just like CRP, of course, anyone will be free to implement their own perk trees and use them instead.

Right now I haven't started implementing it yet: we are still in the concept phase, but not for long. So, I'd like to know what you think of this, and if you see any obvious problem / missing feature / whatever.

[RoverDude]

110% behind this. And I do like the idea of establishing a shared collection of perks and perk trees in the same way CRP works (no need to have ten ways of saying 'biologist' or 'engineer')

Edited October 13, 2014 by RoverDude

[Justin Kerbice]

Looks interesting but... what skills kerbals would have ?

I think of something before, like stupid kerbals makes ships less controllable (after all, THEY are in control, not us), example: bad thrust setting (ask for 100%, get 75%), imprecise movements, wrong button pushed (landing legs retracted just before landing ), etc

Skills let me think back to UFO Enemy Unknown in which teams became valuable with experience.

[nismobg]

I had a big text of wall suggestion in the Addons Suggestion Forum but It's somehow gone. It was exactly for what you are planing on doing and If you do decide to proceed with the help of USI's CEO Mr Dude, you guys will single handedly bring a whole new dimension to KSP. Short version of my suggestion was to use Kerbal's skill build over time with missions etc to influence various parts and their behavior mainly. Start with diminished skills and build over time with flights or missions.

Example Sub Perks:

Piloting(with own subs) : Use of SAS(higher skill less random jiggle), Random Light, improper/random use of RCS or engines(low skill), etc.

Toughness: Can fall form far etc.

Driving

EVA control: efficient rcs use,can hold more rcs, etc.

Saboteurs (negative perk value): leaks fuel, breaks parks etc.

Income/Science Makers: Bonus to missions with those on-board

Just few ideas to mention when you start building the code.

[Ippo]

Thanks for your feedback guys, but all the things you mentioned would actually be mods based on this.

What's really needed is to define some general skill trees that are general enough to be useful for everyone, without being too vague.

Also, a way to have closed paths in trees. Saving a tree in a cfg is trivial, having multiple paths that merge, less trivial. In fact, I think that at the beginning we will only have open paths (two skill lines cannot merge into one).

I will probably start coding tomorrow evening (Europe time zone), and report back on the progress.

[RoverDude]

I agree with keeping the tree simple. My suggestion RE initial skills... is to have none Let the mods define this and curate the list, and see what comes up. i.e. start with DangIt!, then I will add the new ones needed for MKS, and as other folks come on board they can either use the ones we already made (i.e. I will reuse the DangIt! skills in MKS), or make new ones.

[scottpaladin]

This sounds like a great idea. I really love anything that lends individuality and utility to the kerbonauts. It lets story emerge from gameplay and makes the game feel alive.

I agree with keeping the tree simple. My suggestion RE initial skills... is to have none Let the mods define this and curate the list, and see what comes up. i.e. start with DangIt!, then I will add

the new ones needed for MKS, and as other folks come on board they can either use the ones we already made (i.e. I will reuse the DangIt! skills in MKS), or make new ones.

I'm with Rover; leave The Community Perks Pack itself as the framework and put the actual perks themselves in mods but if I'm reading the OP correctly, that's pretty close to what Ippo originally proposed.

That being said: it won't hurt to have a discussion about what the broadest skill/perk trees could look like, though. Coming to some semblance of consensus now could help other members to think about how they could use the CPP to make their own mods better or more integrated. Personally, I kind of love the idea that I could make a mod that expected crew to have "science" skills without myself having to worry about making those skills and building a system for them to be assigned.

Perhaps the broadest way to divide a skill/perk tree would be into mental and physical traits/perks/skills. Things like toughness, length to starve/dehydrate/suffocate, and withstanding G-load and such would all fit under a fitness tree, and anything knowledge or skill based, making repairs, increasing science gains, running an MKS/OKS module could be under a mental tree.

[Ippo]

I'm with Rover; leave The Community Perks Pack itself as the framework and put the actual perks themselves in mods but if I'm reading the OP correctly, that's pretty close to what Ippo originally proposed.

Yes, it is

I envision OPS as a pure backend with no data, that can manage any perk tree that is thrown at it. This way it remains completely agnostic to the perk trees that the user wants to load, just like Open Resource System doesn't need CRP to work, rather the opposite.

I also agree that the earlier we start discussing the standard trees to be put in CPP, the better. Of course, I am going to need at least one tree devoted to repair abilities

Also, technical information: in my current design concept, each tree must have a unique name, and each perk in it must have a name that is unique in that tree. To access a perk, one will need to use both the name of the tree and of the perk, so that there is no possibility of confusion between perks with the same name in different trees. How does it sound? Good, bad, terrible...?

[zengei]

I think of something before, like stupid kerbals makes ships less controllable (after all, THEY are in control, not us), example: bad thrust setting (ask for 100%, get 75%), imprecise movements, wrong button pushed (landing legs retracted just before landing ), etc

Heh, am I the only one that thinks Kerbal stupidity is a positive attribute? To me it kind of connotes the idea of "you don't know enough not to try"; outsiders who solved 'impossible' problems because they didn't know enough to realize what they were doing was Hardâ„¢. For a game as lighthearted and whimsical as KSP it seems counter to have such a negative attribute. To me, a highly stupid kerbal would be a good thing because they would be able to solve problems other kerbals couldn't in unorthodox ways.

But more on topic, I like the idea of trying to organize a loose consensus before things get a bit wild with every mod adding their own system. My only concern is the concept of "perk points", which would effectively add a fourth currency to a game. Is there anything particularly wrong with the approach that DangIt uses now of Science and Funds?

In terms of 'occupation' perks, DangIt already has Mechanic and Electrician, how about:

(Note the benefits are obviously dependent on mods to implement, I'm just giving examples of how they may be used)

• Researcher/Scientist - Could provide science bonus or simply unlock new science experiments. Could branch into Specialists who give huge science bonuses to one particular kind of experiment.
  
• Survivalist - Could consume fewer resources for life support mods
  
• Commander - Could enhance the bonuses of other kerbals aboard their vessel
  
• Pilot - Could provide access to various autopilot features like in MechJeb, Vertical Velocity Control, or Throttle Controlled Avionics
  

[RoverDude]

This sounds like a great idea. I really love anything that lends individuality and utility to the kerbonauts. It lets story emerge from gameplay and makes the game feel alive.

I'm with Rover; leave The Community Perks Pack itself as the framework and put the actual perks themselves in mods but if I'm reading the OP correctly, that's pretty close to what Ippo originally proposed.

That being said: it won't hurt to have a discussion about what the broadest skill/perk trees could look like, though. Coming to some semblance of consensus now could help other members to think about how they could use the CPP to make their own mods better or more integrated. Personally, I kind of love the idea that I could make a mod that expected crew to have "science" skills without myself having to worry about making those skills and building a system for them to be assigned.

Perhaps the broadest way to divide a skill/perk tree would be into mental and physical traits/perks/skills. Things like toughness, length to starve/dehydrate/suffocate, and withstanding G-load and such would all fit under a fitness tree, and anything knowledge or skill based, making repairs, increasing science gains, running an MKS/OKS module could be under a mental tree.

What's interesting is I would not have gone down the attributes path (toughness, etc.) - I'd probably do them more as occupational - Scientist (then up to Geologist, Scientist, etc.), Piloting, Navigation, Engineering, etc. along with planetary experience. So a Laythe Biologist would be able to get more out of a colony on Laythe than, say, Eeloo. While an engineer with experience on Eeloo would be better at repairing mining equipment there.

[landerote]

Hi Ippo!

First of all, congratulations for starting this. I was looking for something similar. I have some doubts, probably because of my missunderstanding...

- First of all, I think that apart from the skills, we could go further and handle also things like morale and other kerbal's characteristics. In any case, this type of characteristics would need to use another system than the perk points, or use the perk points to increase the max or min amount of them, being numerical...

- As far as I understand, there will be common trees and perks to be used by everybody, right? Lets see, if we have the "Pilot" tree, under this one we will have different "levels" or skills, like Noob, Student, Silver Wings and Golden Wings. This levels will be unlocked with perk points, and the "harvest" of those perk points and the effects of those skills will be in mods side.

- I see a problem with this, and I think that if we go for this structure, all the mods should use the same formulas to obtain the specific perk points, for example for pilot skills we could use sub-orbital flight hours, as if we were defining resources we would need to agree in the mass, volume etc. Because otherwise different mods would collide. If we use different formulas to obtain the perk points, we could ruin the functionality of the other mods, as we share the same "skill". For example, let's say that two persons make a mod to handle the morale, and one increases it when there are many kerbals in a ship (because of social chat) and the other one decreases it... Then none of them would work. I agree that the consequences of having those skills should be handled by the mods, but I think we should define the threes and the formulas, and any mod that wants to use the OPS should agree with those formulas. Anyway, there could be changes, like someone creating the "Kerbal university" and the formula to get perk points being added to the OPS.

So.... who is starting the mod for the training center?

[nismobg]

"Mike (Mu): I’ve been putting the finishing touches to the new Kerbal career logging system and building the new experience system. Kerbals will each be assigned an experience trait when they’re generated and, as they gain experience levels, their trait will boost a vessel’s performance in a variety of areas. "

...........lol challenge !!!!!! accepted ?

[RoverDude]

Hi Ippo!

First of all, congratulations for starting this. I was looking for something similar. I have some doubts, probably because of my missunderstanding...

- First of all, I think that apart from the skills, we could go further and handle also things like morale and other kerbal's characteristics. In any case, this type of characteristics would need to use another system than the perk points, or use the perk points to increase the max or min amount of them, being numerical...

- As far as I understand, there will be common trees and perks to be used by everybody, right? Lets see, if we have the "Pilot" tree, under this one we will have different "levels" or skills, like Noob, Student, Silver Wings and Golden Wings. This levels will be unlocked with perk points, and the "harvest" of those perk points and the effects of those skills will be in mods side.

- I see a problem with this, and I think that if we go for this structure, all the mods should use the same formulas to obtain the specific perk points, for example for pilot skills we could use sub-orbital flight hours, as if we were defining resources we would need to agree in the mass, volume etc. Because otherwise different mods would collide. If we use different formulas to obtain the perk points, we could ruin the functionality of the other mods, as we share the same "skill". For example, let's say that two persons make a mod to handle the morale, and one increases it when there are many kerbals in a ship (because of social chat) and the other one decreases it... Then none of them would work. I agree that the consequences of having those skills should be handled by the mods, but I think we should define the threes and the formulas, and any mod that wants to use the OPS should agree with those formulas. Anyway, there could be changes, like someone creating the "Kerbal university" and the formula to get perk points being added to the OPS.

So.... who is starting the mod for the training center?

I'd probably see it in a different light - and probably more akin to how we handle resources.

Assuming that perks are merely a way to track stats - and mechanics are in place to increase those stats - how we go about it is really something that's mod specific, and would be outside of scope. If we were to simply say 'here is a tree of names and values. Go play.', that would, IMO, be sufficient. I really don't care how other mods increase perk points, all I care about is that the one I want is there, and I can add my own mechanics to it.

I think if we try to make the scope too great, it will get buried in the minutia and never launch. in my experience, we'll get a lot further mileage with frameworks. I for one know that I'd use this API in a heartbeat for the stuff that I need anyway, and the only mechanics I need it to provide are a way to read and write the perk data

[scottpaladin]

OK, so it looks like the Devs are starting to think about ideas in this general vicinity as well. So it's possible all this will be moot come .26 but I don't think that's it's likely to be close enough to what we're talking about to render it completely pointless. In fact, once we get to .26 a simple way to gain perk points would be "1 point per X experience" so this will probably be helpful down the road.

It would seem that most people are thinking about this in a "job" sort of frame of mind than anything else, which I think could totally work and wouldn't preclude the addition of a couple of more "generic" trees (like mental and physical perks that I mentioned) should someone want to add those.

One idea that I've been thinking about since first reading this thread (or really since seeing CrewFiles) would be a mod for ranks. Checking a kerbal's flight record/exp/total perks and letting them qualify for promotions. But this raises a question for Ippo: is there any functionality in your plan for a later perk to actually replace a perk lower in the tree? I can think of instances where you might want to have a later perk turn off a previous one. In my case, so that a 'Commander' won't also count as a 'Lieutenant'. (Although I can image some workarounds if there isn't).

[Ippo]

But more on topic, I like the idea of trying to organize a loose consensus before things get a bit wild with every mod adding their own system. My only concern is the concept of "perk points", which would effectively add a fourth currency to a game. Is there anything particularly wrong with the approach that DangIt uses now of Science and Funds?

• 
  

Well, to be honest, I am really undecided about science and funds: perk points are 100% here to stay, but maybe we might also add an optional cost in science and funds on top of that. The reason is that, if a perk is unlocked only by science and funds, you can bypass the experience requirements and just pay your way out of a problem.

For example, imagine you want to model a progression in flight skills every X hours: if the player can just pay to progress through the tree, the whole point of the mod is lost. I'd rather have the mod itself have its own ways to convert science and funds to perk points. Or, as I said, put an optional cost to the unlock of a perk, in addition to the perk point.

For example, let's say that two persons make a mod to handle the morale, and one increases it when there are many kerbals in a ship (because of social chat) and the other one decreases it... Then none of them would work. I agree that the consequences of having those skills should be handled by the mods, but I think we should define the threes and the formulas, and any mod that wants to use the OPS should agree with those formulas.

The way mods award perk points is, imho, outside the scope of this project: I think that forcing a common algorithm would be too restrictive and wouldn't leave modders the freedom to model stuff as they like. Sure, consensus is always nice (that's what this project is about, after all), but I don't think it should be enforced at the framework level.

Also, in your example, it seems correct to me that the two mods interfere: if something is increasing morale and something else is decreasing it, then it's correct that it stays constant

Although I have to say, morale is definitely something this framework is not fitted for...

"Mike (Mu): I’ve been putting the finishing touches to the new Kerbal career logging system and building the new experience system. Kerbals will each be assigned an experience trait when they’re generated and, as they gain experience levels, their trait will boost a vessel’s performance in a variety of areas. "

...........lol challenge !!!!!! accepted ?

OK, so it looks like the Devs are starting to think about ideas in this general vicinity as well. So it's possible all this will be moot come .26 but I don't think that's it's likely to be close enough to what we're talking about to render it completely pointless. In fact, once we get to .26 a simple way to gain perk points would be "1 point per X experience" so this will probably be helpful down the road.

Eheh, it was about time, squad! But yes, as noted by scottpaladin, I don't think the stock mechanic will be even close to the versatility we want to achieve here, so it's cool. If anything it can integrate better

... is there any functionality in your plan for a later perk to actually replace a perk lower in the tree? I can think of instances where you might want to have a later perk turn off a previous one. In my case, so that a 'Commander' won't also count as a 'Lieutenant'. (Although I can image some workarounds if there isn't).

Well, no, I am not planning for that. But you can easily work around it, and it's a cleaner solution imho than replacing a perk that was already obtained.

Also, if you think about it, ranks don't really replace each other: a commander is higher in rank than a lieutenant, and in fact he has all the powers of a lieutenant, and more. So a promotion adds more powers, but doesn't replace the ones you already have.

For this specific case, you could make a linear "tree" (just a straight line with no branches) and just count how many ranks have been obtained, so it is still pretty easy

[SmarterThanMe]

I'm really keen on this, and have been thinking about it since early on when I started making ribbons for Final Frontier. There, I created three ribbons for particular specialisations, Operations, Engineering and Science (before anyone asks, yes, live long and prosper). I even came up with levels of those things, see here. There's also a couple of levels for leadership, of a section (Ops, Eng and Science), a ship and then an expedition.

I had decided that Operations would take care of piloting, communications, computing and life support; Engineering would take care of power, fuel, electrical, mechanical and engine systems; and Science would take care of... Science.

So, a simple way that I would suggest (without getting into skilltrees, yet) it working would be like this: a kerbal is recruited and a specialisation is given (Ops, Eng, or Sci), which gives a very basic level of bonus within their area of specialisation. Once they've gained some experience, they can be "levelled" up and given a perk that gives them a bonus in the area of their expertise. Once they've received 2 perks, their next level up makes them a leader within their area of specialisation which gives them a perk which gives bonuses to those working around them with that area of expertise. So, a Chief Engineer with an Engineers underneath him/her who specialises Power systems, gets bonuses for his/her expertise (say in Electrical and Fuel systems, so there is a cumulative bonus laid onto their perks). Mission Commanders give a bonus to the perks of everyone on their ship. Expeditionary Commanders give a bonus to everyone in orbit around the same body as them (i.e., part of the same expedition). Some of the perks would have to be dependant on other mods being present (no point in having a communications perk if Remotetech isn't installed).

Graphically (numbers are completely arbitrary), for Engineering (sorry, I have a 1 month old, a 2.5 year old and a wife):

I see that you're discussing ranks... I'm ultra-keen there. I've already done graphics for it, and have discussed ideas over there. This is what I said:

Kerbonauts start at Lt2 and the date that they are brought into the game is recorded.

Their promotion to the next grade (Lt1) becomes available after x game months minus a factor determined by the number of missions they've been on, and how many other ribbons they've received. When they're ready for the next promotion, you can either (1) have it happen automatically; (2) click a button to promote; or (3) have a promotion "day" every month or so when Kerbonauts who passed the formula are placed into a pool for promotion to the next higher rank.

I would prefer option 3, because it would allow a process to only promote the best candidates to the upper ranks. 100% of candidates from the pools should be promoted to Lt1 and Capt, but after that there should be a set percentage of available candidates can be promoted up (down to, say, 50% of candidates getting promoted to Col). So the candidates with the most ribbons should get promoted over less decorated colleagues.

There should be a set number of Kerbonauts at the General ranks (say 3 Brigadiers, 2 Major Generals, 1 Lt. General and 1 General), and the best qualified (most ribbons) individual from the next lower rank should replace retiring Kerbonauts. Or you could set it so that a choice has to be made from 2 or 3 or whatever on retirement of someone from an upper rank.

I have done graphics (although I'm open to criticism, and they'd need a background to fit with whatever) for each rank that you can set as the first ribbon in FF's display perhaps?

...I've tried to avoid the ranks being too Americocentric (or Auscentric for that matter too), so no eagle for Colonel, no Leaf for Major or Lt. Colonel etc.

...but you all seem to be on roughly the same track as me, so I'm happy with anything. I would talk to Nereid about how he manages to keep track of things, because that could probably help you to get some sort of variable that can input into perk generation.

Otherwise, I'm happy to contribute graphics or whatever else.

Edited October 15, 2014 by SmarterThanMe

[SmarterThanMe]

Also! An idea regarding how to translate experience into perks... I like sending my new recruits to an "Orbital Academy" before assigning them their specialisations. You could have "parts" associated with gaining specialisations and translating experience into perks? Or have it conducted through the Astronaut Complex.

[Ippo]

You could have "parts" associated with gaining specialisations and translating experience into perks? Or have it conducted through the Astronaut Complex.

No, *you* could

Again, this is meant to be strictly a framework for other mods to build on: there won't be any effect, part, or any other specific detail aside from a system to read and write perks, plus some completely implementation-agnostic trees to give third party mods a common ground to agree on

[SmarterThanMe]

No, *you* could

Eh. Me? Probably not (cf. 1mo, 2.5yo and wife).

But if you need anything graphical done... I'm your guy.

[scottpaladin]

WWell, no, I am not planning for that. But you can easily work around it, and it's a cleaner solution imho than replacing a perk that was already obtained.

Also, if you think about it, ranks don't really replace each other: a commander is higher in rank than a lieutenant, and in fact he has all the powers of a lieutenant, and more. So a promotion adds more powers, but doesn't replace the ones you already have.

For this specific case, you could make a linear "tree" (just a straight line with no branches) and just count how many ranks have been obtained, so it is still pretty easy

No worries, like you said there are certainly ways to work around. I was just interested in if the option might be available. I'm looking forward to movement on this (though I probably won't do anything on it myself for a while, busy life ).

I dig those graphics that SmarterThanMe did; I ended up doing the same sort of work for the ranks I use for kerbalspacecenter.com. I personally like the idea of "Pilot" being a qualification of its own, as it has probably the single biggest effect on stock game-play by itself. Operations, to me, was for rover drivers, EVA specialists, robot arm controllers that sort of thing. I personally added a "command" section to my universe which is really just because I thought the blue space suit skin I was using looked a bit official.

[SmarterThanMe]

Did this idea die? Anyone working on anything?

[Ippo]

Did this idea die? Anyone working on anything?

Nope, not that, I'm just a little busy, that's all

[SmarterThanMe]

Nope, not that, I'm just a little busy, that's all

Ah! I've seen that you have perks in DangIt! I was just wondering if anyone else had worked them in yet (or was thinking of it, I'm keen to help out).

[Ippo]

The problem is that DangIt's system is just not fit to be an API for others to use, therefore this thread. In the future I'm going to convert DangIt to use this instead

[timmers_uk]

I'd second the request for the api to allow storage of kerbal stats as well as managing perk trees. Stats and perks sit in a quite complementary place to each other, and I suspect there's a natural fit for some perks to influence per kerbal stats. I had been thinking of migrating keepfit over to Crewfiles (still might) but storing current fitness using this library would be better because I could also support some perks and also natural ability - a kerbal with high activity drive (or to state it oppositely, a low couchPotato) status would have their fitness impacted differently. Similarly a kerbal who has received the Pumping Iron perk might have their effective stay buffed, or you could receive a negative perk BrokeBack for too many high Gee experiences (or too long in a 2 man capsule).

I could do these with the aid of a perks library, it'd be even better if I don't have to maintain an essentially parallel code base for storing kerbal stats for keepfit and even better again if someone can implement a nice gui final frontier/alternate resource panel style for those stars and perks.

Just a thought though, take it or leave it as you will.

Timmers