next »

I have one thing to say right now:  Circular dependencies!   

I've spent several hours pluggin away at my keyboard.  The logic of the skill system described below is ready.  Initialization... that's another beast entirely.  Skills should be immutable once initialized.  Once we've loaded the ruleset we're playing under from the XML files, it should not change, ever.  However, it's proving exceptionally difficult to initialize everything properly without some mutators.  While I try to figure out a crafty way around this problem, I'm going to post the specifications of the skill system:


Skills have:

- Domain
- prerequisites
- costs
- synergies
- levels
- effects


Specifications:

Domain:
At this point, the domain of a skill seems to be an arbitrary classification designed to classify skills into different groups.  While it makes some sense to separate magic and combat skills, I'm uncertain as to whether this will be phased out in the future, or kept as a way of "classifying" different groups of skills.  Currently there are combat, finesse, and spellcraft domains.  All skills must belong to one (and only one) of the three.


Prerequisites:
This is, as can be expected, a list of skills you need to have access to before you may purchase this one.  Skill prerequisites aren't a simple list in all cases, however.  In some cases, there are different sets of skills that may result in a valid purchase situation.  This can be expressed as a logic function (ie; (skill A and skill B) or (Skill C and Skill D) ).  Complicating matters, because some skills are optional we may have circular prerequisites.  I'm not saying we have to, but it's possible and we should support it.


Costs:
All skills have a base cost in experience.  You must pay that much experience to purchase them.  However, almost all skills will have synergies.  If you have already purchased a skill's synergy, its cost will be reduced.  That's discussed below.


Synergies:
A skill may have a synergy with any number of other skills.  The magnitude of that synergy is the discount on the cost that will be felt.  A skill's cost can be pushed below zero by a synergy, in which case you are awarded it for free.  A skill synergy is bi-directional.  That means that if purchasing skill A bestows a discount on skill B, then purchasing skill B bestows an equal discount on skill A.  This is designed so that no matter what order you pick your skills in, the same set of skills will always have the same net cost. 


Levels:
All skills have a level associated with them.  A skills level is determined by its prerequisites.  As mentioned above, a skill can potentially take many different combinations as its prerequisites.  One special combination is used; what I will call the "least set".  This is the set of prerequisites containing the lowest level skills.  Suppose a skill requires (A and B) or (C and D).  Suppose their levels are (5, 6, 4, 3), respectively. It is therefor possible to pick the skill with a combination of level 5 and 6 skills, or the combination of level 3 and 4 skills.  The latter set has the lower maximum (4) and therefor it is used to determine the level of this skill, which would therefor be 5.

That may seem confusing, but in terms of logic it's actually quite easy to implement.  Just replace every "and" with a "max" operator, and every "or" with a "min" operator, and every skill with its appropriate level.  The statement becomes (5 max 6) min (4 max 3).  As you can plainly see, this resolves to 4.  Add one to this number and we have the level of our skill.


Effects:
this contains the actual substance of the skill.  At this point, this is left unimplemented.  I am not certain how we should go about designing the actual implementation of individual skills.  The system I have built facilitates the selection of these skills, not their use.  That can be integrated at a later point in time.



Currently, I have four classes.  I have a skill class, a prerequisite class, a Synergy class, and a Library class.  Domains are an enumerated type (nothing special here).  Prerequisites are, of course, their own class.  Skill cost is just a private integer, while Synergies have their own class.  A skill level is also a private integer which is generated by calling a function from the prerequisites.  If not for initialization (which is currently a mess) I'd be writing a tester right now for the whole lump.  If anyone wants to see added functionality, be my guest and add to the discussion.

I've been wondering about the best way to implement prerequisites and synergies given what I hope to create for the skill tree.  Before I start to overhaul the code I wrote over the winter break (because it needs an overhaul to do everything I want it to do, that much is certain) I wanted to bring up some of these ideas and hopefully come up with the best way to tackle the problem. I was originally going to tackle both synergies and prerequisites in one topic, but I figured I should split that into two topics.  Prerequisites don't necessarily need an overhaul, but as you will see if you read this through, I'm considering it.  I'm still not sure what's the best way to implement this, so please contribute (if only to look at the two XML examples and decide which one looks like something you'd want to work with!)


With regards to prerequisites, there are several things I want to encompass.  First of all, the ability to create an "or" junction in logic statement of prerequisites.  In most games, you require a specific set of prerequisites to purchase a higher level skill.  However, we want to create a system which doesn't force people to conform to a specific mold, and as such it is important that there be alternate sets of prerequisites to satisfy a skill's    requirements.  Secondly, I wanted to create a sort of "developmental" prerequisite.  That is to say, a character may require "five skills from the combat domain of level 2 or higher".  This would mean they could pick any five skills - even completely unrelated ones.  The idea here is to ensure a character has reached a certain level of development before he takes a higher level skill.  This, too, may be subject to an "or" condition.  For instance, a skill could require either set of (skill A and four other skills) or (skill B and two other skills).  Thus this would provide two very different approaches to the same skill.

Currently, skill prerequisites are defined in a tree-like structure.  So for instance, take the prerequisite that is (A or B) and ((C and D) or (E and F)).  In practice, it would be implemented in a tree as seen in the diagram at the bottom.  Both skills and prerequisites implement a specific interface, allowing a prerequisite to reference either a skill or another prerequisite.  To figure out whether a prerequisite is met, a specific call is made to it.  The prerequisite then calls each of its branches with the same function.  At the bottom of each branch is a skill, which checks the input parameter (whcih is a list of skills).  If that list of skills contains the skill itself, it returns true (the prerequisite is satisfied) otherwise it returns false.  The prerequisite then checks its "logic" data member.  If the logic is set to and, it returns the logical and of the return value its two members gave.  If it's or, it returns the logical or.  I've tested this system and it works, but as you may have noticed it's not exactly the easiest to write for in the XML files.

An alternate design would be to ditch the tree and perform some boolean algebra to expand the equation.  For those of you who don't know what boolean algebra is, just treat "and" like multiplication and "or" like addition, then just expand the statement like regular algebra.  The statement (A or B) and ((C and D) or (E and F) happens to be equivalent to (A and C and D) or (B and C and D) or (A and E and F) or (B and E and F).  As you can see, this statement is much longer, but upon inspection it lists every combination of skills that satisfies the whole prerequisite: (ACD), (BCD), (AEF), (BEF).  Because order of operations stops being an issue in this setup, it may be much easier (and more logical) to approach it from this way in the XML file.  All that would necessary in terms of code implementation is a set of skill lists representing each set of valid prerequisites.     The downside, of course, is when we go to print the prerequisites:
option A:   (A or B) and ((C and D) or (E and F))
option B:  (A and C and D) or (B and C and D) or (A and E and F) or (B and E and F)
As prerequisites get increasing complex, option A starts to look much more concise.  The final option is to use one method for XML, one method for implementation, and one method for outputting results to the user.  This would add algorithmic complexity from the conversion of one representation of the logic to another.  I don't think the CPU is a big deal for this application (so long as we don't code sloppily) so it's a matter of how much time we want to invest in the issue.  Here is how each would look in XML:

Option A

Code:

<prerequisite>
         <prerequisite>
                <prereqid> A </prereqid>
              <prereqid> B </prereqid>
                <logic> OR </logic>
        </prerequisite>
        <prerequisite>
                <prerequisite>
                        <prereqid> C </prereqid>
                        <prereqid> D </prereqid>
                        <logic> AND </logic>
                </prerequisite>
                <prerequisite>
                        <prereqid> E </prereqid>
                        <prereqid> F </prereqid>
                        <logic> AND </logic>
              </prerequisite>
                <logic> OR </logic>
        </prerequisite>
        <logic> AND </logic>
</prerequisite>

Option B

Code:

<prerequisite>
        <prereqid> A </prereqid>
        <prereqid> C </prereqid>
        <prereqid> D </prereqid>
</prerequisite>
<prerequisite>
        <prereqid> B </prereqid>
        <prereqid> C </prereqid>
        <prereqid> D </prereqid>
</prerequisite>
<prerequisite>
        <prereqid> A </prereqid>
        <prereqid> E </prereqid>
        <prereqid> F </prereqid>
</prerequisite>
<prerequisite>
        <prereqid> B </prereqid>
        <prereqid> E </prereqid>
        <prereqid> F </prereqid>
</prerequisite>

Option B is still simpler, but option A is still more concise.  This may be very important even if we have an editor for this stuff (and we will, because I can't see myself writing hundreds of skills like that by hand!), since I'd want it to be a very low-level editor that's close to the actual XML being generated.

Regardless of our choice, it remains important to implement some method of storing "N skills of O domain of level M or higher".  I think that's just a matter of creating another class that implements the SkillTree interface, and then creating the appropriate functions to read that.  This would also need to be represented well in XML.  It might be easier using option A because that one provides a degree of encapsulation to each branch of the SkillTree, which allows us to just toss different types of parameters in there and it should implicitly figure out what's going on since order of operations is very explicit.  This might be a little harder in option B where we rely on order of operations to be more implicit. 


As you can probably tell, I'm deadlocked between these two methods, so please let's discuss which one I should implement and then I'll get to it.  Option A is already implemented (a few bugs yet to work out, if I recall), but don't let that bias your opinion, as I'm still going to overhaul a few sections of code to implement some optimizations I've thought up since I wrote it.  And yes, I'm aware I over-think the simplest of problems.

how about: (lazy me, pr = prerequisite)

Code:

<skill>
 <bla/>
 <pr cond="AND">
  <pr cond="OR">
   <pr id="A" />
   <pr id="B" />
  </pr>
  <pr cond="OR">
   <pr cond="AND">
    <pr id="C">
    <pr id="D">
   </pr>
   <pr cond="AND">
    <pr id="E">
    <pr id="F">
   </pr>
  </pr>
 </pr>
</skill>

or

Code:

<skill>
 <bla/>
 <pr expression="(A | B) & ((C & D) | (E & F))" />
</skill>

combo

Code:

<skill>
 <bla/>
 <pr cond="AND">
  <pr expression="A | B"/>
  <pr expression="(C & D) | (E & F)" />
 </pr>
</skill>

the game would parse all, leaving the decision of format to the xml typer.

anyway, can you give a more to-the-point summary of your problem? i don't really know what it is exactly. presenting it to the user, or something else?

The problem here is three fold:

1) I have to decide how to define the XML files.  We'll probably be providing a simple editor for the end user (that is the modder, not the player, but that won't eliminate the need to read and understand the XML.  Its purpose is mostly to prevent human error and speed up the process of editing the xml file, not actually reducing the complexity of the task (I think it's reasonable to ask a modder to be able to read an XML file).  However, that still means we want to support the most logical and straightforward format.  There is a good point you do bring up in your first example, that we can place the logic value inside the prerequisite label.  All prerequisites will have a logic value.

However, there's a problem with your two other examples.  The ID of a specific skill is NOT a single character.  In fact, it'll probably be more like 12 characters on average.  As a result, even relatively simple prerequisites could get very messy if we try to stuff them into one line.  Moreover, all those brackets can be ugly and difficult to read. That said, I'm not opposed to supporting multiple types of input, but I'd prefer to keep it simple if possible (and certainly for the time being I'm going to implement one and only one, so let's pick the one that we'd want to use if we only had one choice).

2) how to represent the data in the system.  I described the current tree-based system in detail.  I like it, and I don't think it fundamentally needs an overhaul, but I am going to rework several parts of it to include some optimizations and extra features, so if there's a problem or a suggestion for a better implementation, now's the time to talk about it.

3) part of the extra features I'm adding in is how to display the prerequisite to the user.  That is, a statement that can be read by average joe and understood.  The current implementation just spits out a bracket-laden mess, which is why I want to change it (of course, this one can wait until later, but I still want to have an idea how we want to display the results to the user so I have the right functions to support that).


The real head-ache is synergies, which I'm going to post about later.  I figure I'll get the easy stuff out of the way first and get some consensus on how to deal with them all.  I'll get all the functionalities that I - and others - want in prerequisites and then turn my attention to synergies.  More than anything, I just want to make sure that there's more than one brain behind this so I don't make any stupid mistakes.

The ID of a specific skill is NOT a single character

that much i figured

As a result, even relatively simple prerequisites could get very messy if we try to stuff them into one line.

then put them on multiple

Code:

<pr>
    (InsertARandomLongSkillNameHere & InsertARandomLongSkillNameHere)
    | (
        (InsertARandomLongSkillNameHere & InsertARandomLongSkillNameHere)
        & (InsertARandomLongSkillNameHere & InsertARandomLongSkillNameHere)
    )
</pr>

That said, I'm not opposed to supporting multiple types of input, but I'd prefer to keep it simple if possible (and certainly for the time being I'm going to implement one and only one, so let's pick the one that we'd want to use if we only had one choice).

indeed, the whole idea is multiple types of input. for the initial implementation my first example would be best, since it can be translated almost directly to objects.

how to represent the data in the system.  I described the current tree-based system in detail.  I like it, and I don't think it fundamentally needs an overhaul, but I am going to rework several parts of it to include some optimizations and extra features, so if there's a problem or a suggestion for a better implementation, now's the time to talk about it.

define an interface Prerequisite, with a method something like evaluate() or isOk(), whatever. Then have two (later three) implementations of that:
- a single prequisite skill
- a container for multiple prequisites, with logic. when evaluated, will evaluate it's children and logically combine them
- (later) an expression
now, to verify if all prequisites are met (is that the correct word, "met"?), just call evaluate() on the root prequisite (field of Skill).
anyway, that's mostly what you described in your first post (of this subdiscussion).
about optimizations, be careful. premature optimization is a killer, we need to find bottlenecks first.

part of the extra features I'm adding in is how to display the prerequisite to the user.  That is, a statement that can be read by average joe and understood.  The current implementation just spits out a bracket-laden mess, which is why I want to change it (of course, this one can wait until later, but I still want to have an idea how we want to display the results to the user so I have the right functions to support that).

now there's a good question. in a graphical user interface, i'd say we give each skill an icon and display some kind of tree

Well, the system you've described is effectively what already exists.  I was reconsidering it mostly because (as I mentioned in my earlier post) that I'm going to be redesigning several sections of code, so it made sense now to see if anyone thought a different algorithm would be  a better idea.  So I'll keep prerequisites roughly the same when I go to change them.

now there's a good question. in a graphical user interface, i'd say we give each skill an icon and display some kind of tree

That still begs the question of what functions we should provide to return the data necessary to build that tree.  Of course we can design the actual GUI later, but for now we should provide the data access functions that this GUI will eventually use.

What's wrong with just returning the root prequisite and letting the GUI do whatever it wants with it, including reading subprerequisites?

I suppose that's the best course of action, then all I'll have to implement is a function to return the prerequisite's branches.

Anyways, I'm going to implement "N skills of the O domain of at least level M" prerequisite tonight, and then write a formal specification for synergies (you know it's not going to be easy when you're having trouble just figuring out the specifications >_<)

So, the deal about synergies is that they are supposed to act as discounts between similar skills.  This punishes people who try to "beeline" through the skill tree to specific selections, and rewards those who pick a more rounded array of skills. 

There is one rule that trumps all others in the implementation of synergies: the order in which a set of skills is chosen shall not affect its net cost.  This implies, of course, that if skill A offers a 500 point synergy to skill B, then skill B must offer the same synergy to skill A so that the net cost of purchasing the two of them is independant of the order in which they were selected.  This is easy enough to implement in the trivial case, where one skill offers a discount to many, or many skills offer a discount to one.  Where it becomes more difficult is when we have large groups of skills that offer mutual synergies.

Say skills A, B, C, D, and E all share a synergy with each other.  However, the costs of each of these respective skills varies dramatically (let's say A is the most expensive at 2000, and E the least expensive at 200).  Obviously providing a 200 point flat discount would make E free, and would hardly impact the cost A at all.  A constant synergy is insufficient here, therefor we must support synergies which will offer different discounts to members of the same group varying on their base cost.  Moreover, we must question whether skills A and E should offer the same benefit to the other skills of the set.  Should purchasing skill A offer ten times as much benefit as purchasing skill E, or should it be non-linear?

A second issue that must be dealt with in the large group synergies is non-constant benefit.  In most cases, we will probably want the discount bonus to increase as more skills from the group are chosen.  Say skills A, B, and C all have cost 500 and are all synergies.  The first one would cost you the base amount (500), the second one would be discounted by the synergy (to 400) and the third one further (say to 300).  Again, at first glance this appears trivial, but once again with large quantities of skills it is not.

Imagine if the set of skills was not three, but eleven.  You could imagine that any discount that is considerable for the first skill (say 100 points out of 500) will quickly add up to supplying all "freebees" after the fifth skill.  Again, the linear model does not fulfill our needs; we will need to support an exponential decline in the increase of benefits so that the first few synergies can be felt, but cap off after a while. 

The above two issues are compounded by the first rule of synergies: that the net cost of any purchase of a skill set must never depend on the order in which they were chosen.  No matter what our end solution, it MUST adhere to that rule above everything else.  Keep in mind that the first rule only applies to identicle sets.  That is, if there is a synegy between A,B, and C, we are under no obligation to ensure that the set A,B has the same discount as B,C or A,C.  What we must ensure is that A,B,C offers the same as B,C,A or A,C,B etc.  I'm actually fine with skills having a negative cost (ie, you actually get a rebate by picking them) to meet that requirement, but
I'd like to avoid that if at all possible.



Enough about the abstract, let's talk about what I've been thinking on implementation.  I'll start with an example of how these restrictions can be applied to one type of implementation.  This is the thought process that lead me to the creation of this relatively simple yet robust type of synergy which I call linear-grant linear-benefit many-to-many (excuse my confusing nomenclature), take the following synergy group:
Skill A costs 500
Skill B costs 750
Skill C costs 1000
Skill D costs 1500

Say I pick skill A first, and you pick skill C first, and we both intend to pick skill B second.  Our first question is how to weight our selections.  Do you get twice the discount as I do?  Let's see what happens with me getting 75 discount, and you getting 150 discount (10/20% respectively).  At this time I'm pulling numbers out of my hat, and the end algorithm must have a way of figuring out what the discount should be.

Our net cost for A,B is now 1175, and for C,B is 1600.  This is fine since our sets are not identicle; you lack A (a cheap skill) and I lack C (an expensive skill) so it makes sense that the total cost differs.  However, you have actually received a larger proportional discount; 1175 / 1250 gives me only a 6% savings as opposed to a 8.5% savings you get with 1600 / 1750.  This doesn't violate any rules, but we need to keep track of this sort of thing when we consider whether the synergy setup we have is beneficial to gameplay or not.

Now imagine that I try to buy skill C and you try to buy skill A.  The net result is that we've both picked exactly the same skills, just in different orders.  As a result, the total cost for our net purchases must be equal after that action.  A little algebra tells us that the cost for me to purchase C must be exactly 425 points more than the cost for you to purchase A.  As the base difference between C and A is 500 points, this means that the absolute value of the discount I receive must be 75 points greater than the absolute value of the discount you receive.

Let's presume we're using a linear benefit distribution method.  It stands to reason since 500 points invested in the group gives a 10% discount and 1000 points gives a 20% discount that 1175 points should give a 23.5% discount (just extrapolating the linear relationship).  This would mean that skill C would cost me 765 points.  Therefor skill A must cost 340 points for you.  That's a 32% discount.  By our linear distribution formula, this would imply you had invested 1600 points in the skill set, which happens to be the case.

It seems this algorithm satisfies the requirements we set out.  It provides a percentage-based discount, so more expensive skills receive more of a benefit than less expensive ones.  As well, more expensive skills provide more of a benefit than less expensive ones.  By defining how much must be invested into the skill group to receive each % of discount, it appears we can effectively define this linear distribution synergy.  There's only one problem: very large groups of skills.

Suppose that the above synergy didn't end with skill D, but continued to list many more skills.  Under this system with the values we've used, a 1000 point investment grants 20% discount, and 2000 points would grant 40% discount.  It's obvious that after 5000 points of investment there will be a 100% discount, and it will continue to grow to 120% once 6000 had been invested.  That is unacceptable behavior.

There are two solution to this situation.  First and most simply, we can cap the discount at 100% (carefully rebating any excess paid over 5000 for the complete set so as to adhere to the most important rule), and then award all other skills in that discount set for free.  However, this may not work for all discount sets.  Suppose we want the discount's increase to drop off rather than increase linearly to 100%.  An entirely new type of discount must be created which does not follow a linear model, but rather an exponential one. 

We also have another issue: overlapping synergies.  It is possible that A, B, C, D is one synergy, but A, E, F is another synergy.  It needn't be said that this cost slant could complicate analyzing the net return of different synergies!  After all, now the cost for you to purchase skill A may be different than the cost for me, regardless of whether we either of us have touched the other skills in the first synergy. The obvious solution is to, for the purpose of synegies, only examine the discounted cost as perceived by that one synergy, and then charge the player for the net synergy cost.  However, the obvious solution isn't always the right one. 

Moreover, the way the synergies should add is not entirely obvious either.  There are two approaches: multiplication and addition.  The addition method seems simpler at first.  If synergy 1 offers a 100 point discount, and synergy 2 offers a 200 points discount, then we say the net discount is 300.  The other method is multiplication.  Let's say the skill in question has a base cost of 1000, meaning synergy 1 reduces its cost to 900 (90%) and synergy 2 to 800 (80%).  We multiply these numbers (0.9 * 0.8) to get 72%, or 720 / 1000. 

At first glance the difference (30% and 28% discount, respectively) from these two methods seems negligable.  However, as more synergies or very large synergies are added, the difference between these two methods becomes more noticeable.  Imagine if three discounts each offered a 33% discount.  The addative method would see the cost actually reduced to zero (and if we added another 33% discount, that would reduce it well below zero!), whereas the multiplication method would see something more like a 70% discount.  That's a big difference.  This makes multiplication look like the better choice, but it has its own vices, as that could seriously impact the net cost of the same set of skills and violate the most important rule of them all.


I'm going to stop now as I've exhausted all the big issues I've thought up.  As you can see, this is going to be quite a challenge to deal with, but I feel that tackling this problem is critical.  Too often I see developers taking the easy way out of a complicated system and implementing something with exploitable loopholes.  It would take countless (unfun) hours to analyze a system that did not adhere to the primary rule I've set out for the cheapest way to pick out all your skills, and that's something players should not be compelled to do.

Can't say that I know of any solution, but here's just a note so that you know that I've read it and am not ignoring your issues.

Half of that is for myself just so I could write down everything that was in my head and scattered across many pages of notes, and the other half so that others could understand that I'm not just sitting here twiddling my thumbs but actually thinking about this.  That said, I can now ask you for feedback on specific issues as I tackle/implement them.

I also did some algebra last night after writing that and was able to convince myself that the additive method of stacking overlapping synergies is the way to go.  I used the simple case of two synergies (A, B) and (A, C).  I was able to prove that to in order to adhere to the most important rule of synergies, that B and C must give each other a discount (even though they are not synergies to each other) if any method except adding the overlapping discount was used.  I was also able to show that such multiplicative synergies (at least in this simple case) could be created by using multiple additive synergies, which implies that we should implement the additive kind and then use compound synergies (that is synergy sets like (A,B), (B,C), (A,C) which allow each member of the larger set (A,B,C) to have more precisely defined relationships) to represent more complex distributions.  That's one issue ticked off.

Of course, I've got some electric circuit analysis (heh, you think Operating Systems is low level... my idea of low level is transistors <_<) to practice before my exam on Wednesday, but otherwise it looks like smooth sailing for the remainder of the month in terms of workload.

Good news is that I'm working on this again and aim to have something workable implemented over the weekend.  I've decided to implement the system I described above with additive overlap and a hard capped maximum.  I'm also going to work on generic prerequisites (ie, "five combat domain skills of level 3 or higher").



The real reason I'm posting here (normally I'd just go ahead and work) is to remark on this:

... but otherwise it looks like smooth sailing for the remainder of the month in terms of workload.

Oh, how I was wrong.

i've created logic classes (in org.openwar.victory.script.logic) to define logical expressions (a AND b OR (c AND d)) in an OO way. the base of it is the Logic interface, with a method evaluate(). several implementations:

AndLogic: true if all operands are true
OrLogic: true if any operand is true
PointerLogic: true if the value of the boolean this is pointing to is true

now, to translate this to prequisites:

- define a class Prequisite which references a Logic to determine whether it is met (or alternatively just directly put a logic as prequisite in skill)
- defina a class PrequisiteLogic implements Logic which evaluates whether a particular prequisite skill is available

so in the example of (a AND b) OR (d AND c) you would have:

Code:

Prerequisite {

 logic => OrLogic {

  operands =>
   AndLogic {
    operands =>
     PrequisiteLogic { skill => 'a' },
     PrequisiteLogic { skill => 'b' };
   },

   AndLogic {
    operands =>
     PrequisiteLogic { skill => 'c' },
     PrequisiteLogic { skill => 'd' };
   };

 };

};

The prerequisite class has been done and working for months, but I'll try to get around to implementing it via your logic class.  Today the priority is to add support for synergies in the XML reader, since they've been overhauled. 

I've decided that synergies should no longer be imbedded within skills (with the skill they're imbedded into as an implicit parameter), but instead be listed as their own entities within the same XML file.  The reason for this is because I'm concerned about double-listed synergies, and by making them separate the chances of that happening are lower.

[battlecruiser impersonation]Skill Selection System Operational[/battlecruiser impersonation]

So, the thing is fully implemented, and seems to be working.  You can run the tester and use the simple GUI interface to test it out.  Given how small the set of skills are for this test, I just printed out their prerequisites and synergies on the console rather than putting that on the GUI.