next »

Getting back to where I left off last week, it's time to start writing in functionalities to read from an XML file and instantiate each of the skill types.  That way we can just define (and change) our skill definitions in that external file without changing code.  The benefits this brings for both the purposes of modding and updating should be obvious.  The question is now what information to store, and how to store it.  Some is relatively obvious.  We clearly just store an integer when it comes to cost, and a string representing the name for the name.

The difficulty is when it comes to prerequisites and to a lesser extent synergies.  As mentioned before, prerequisites aren't simple "AND" junctions.  They can be any combination of AND and OR junctions.  That is, skill D might require skill A OR the combination of skill B and skill C.  I already have this represented in code (you can take a look at the SkillPrerequisite Class on SVN to see the actual implementation), but I am uncertain of how to represent this in the XML file so it can be written clearly and logically. 

Synergies simply offer a discount in cost between skills.  The problem they share with skill prerequisites is that they must identify another skill in the XML file.  I'm afraid to simply identify them by name or other practical data, since a name can be changed in a different version, and we don't want to hunt down every skill that identifies it as a prerequisite or synergy to change it.  A possible solution is to give each skill a unique identifier code (sufficiently long so it will be extremely rare that there will be a non-unique combination).

So, a sample XML might look this (although I'm still uncertain about prerequisites)

Code:

<Skill> ; anything written after a semi-colen on a line is ignored
     <ID> 00045100023 </ID> ; an arbitrary number
     <name> Rush </name>
     <cost> 600 </cost> ; base cost with no discounts applied
     <domain> combat </domain>
     <synergy>
             <synID> 01254130073 </synID> ; ID number of the skill which is this one's synergy
             <magnitude> 200 </magnitude> ; the magnitude of the discount
     </synergy>
     <prerequisite>
             <prerequisite>
                     <prereqID> 53100410231 </prereqID>
                     <prereqID> 22355012041 </prereqID>
                     <logic> AND </logic>
             </prerequisite>
             <prereqID> 005001219830 </prereqID>
             <logic> OR </logic>
      </prerequisite>
</Skill>

As you can see, prerequisites here are nested, so to speak.  The first "layer" contains a skill ID, a logic operator (OR in this case), and another prerequisite.  That means that you must either have that skill ID, OR you must have satisfied the "nested" prerequisite in order to meet the entire prerequisite.  The nested prerequisite contains two ID's, and the logic operator AND, meaning you must have both the skills referred to in order to satisfy that prerequisite.  The end result is (skill A OR [skill B and skill C]).  Code-wise that's actually rather easy to read, but if it's not intuitive I want to make something that works better.

Another issue is that synergies are bi-directional.  That is, if skill A declares it has a synergy with skill B, then skill B is automatically considered to have an equal synergy with skill A.  Obviously a synergy should NOT be double-defined, since that makes updating the XML file error prone.  At the same time, it could be difficult just from reading the XML to identify all the synergies of a skill (obviously commenting this stuff in is the imperative of the user, so we cannot enforce that). 

So, this topic is to discuss and improve upon a format for the XML file so I can get to work writing functionalities to read this stuff and initialize all our skills.  The actual effects of skills has not yet been defined, and I'm not sure how we're going to do that either in code or in the XML.  For now this is the selection and purchase side of the skill system, and the effects will be added in at a later point in time.  Of course, that too is up for discussion as we want to accommodate that future addition.

So far it looks good. When I find some time I'll look into the issues (and take a look at your code).

I haven't started writing the code for reading XML files yet; I want to make sure we have our format finalized first so I don't have to change it a bazillion times.  I'm currently writing some classes that will help do this (such as a "SkillBuilder" class, since skills are immutable)

Also, the definition of prerequisites is another matter.  I want to make sure it's very readable (even if we have very complicated prerequisites) so that modders can easily understand what's going on and make their own changes.

I haven't started writing the code for reading XML files yet;

I know, I was referring to the earlier code

I want to make sure it's very readable (even if we have very complicated prerequisites) so that modders can easily understand what's going on and make their own changes.

To make it readable, you can do two things (I mean both, not either)
- give the skills text IDs instead of numbers
- while the current way of nesting prerequisites is very clean and easy to parse, something like

Code:

fireball OR (fire AND energyball)

is maybe easier to enter and read

on a sidenote, i believe it's nicer to put xml tags in all-lowercase

- give the skills text IDs instead of numbers

Totally in agreement.

- while the current way of nesting prerequisites is very clean and easy to parse, something like

Code:

fireball OR (fire AND energyball)

is maybe easier to enter and read

The problem with "standard" notation is that you're stuck with parentheses in order to explicitly state order of operations.  They're naturally quite ugly, especially with larger statements and code-words for every skill.  I've also never parsed through statements like that before, so I don't know what kind of efficiency we're looking at when reading from a file with literally hundreds of such lines.  With the system as I have set it up, the order of operations is quite explicit, and each operation is clearly nested through indentation.  The actual meaning, as you have stated it, could always be commented in.

on a sidenote, i believe it's nicer to put xml tags in all-lowercase

I intended to just reduce everything to lowercase once I read it in.  That way it's all caps insensitive. 

I've also never parsed through statements like that before, so I don't know what kind of efficiency we're looking at when reading from a file with literally hundreds of such lines.

i'm sure it's neglegible () compared to the parsing of the xml file itself

intended to just reduce everything to lowercase once I read it in.  That way it's all caps insensitive.

since i assume we're using an XML library like JAX (actually that's a specification, but anyway), i'm not sure if that's technically supported

As you may have gathered, I've never parsed through an XML file before (I've parsed through other formatted input, regularly and often, but not this specific type).

http://en.wikipedia.org/wiki/Java_API_for_XML_Processing
http://en.wikipedia.org/wiki/Xerces

I *have* used Google before, however ^_^

yes but XML is a pretty wide subject, figured I might as well put the right links here, since I knew them already

Fair enough; the Xerces link lead to an appropriate tutorial (with examples, no less; I can never believe how many tutorials I run across without any examples).  Mind you your first link is outdated; it's talking about software that's due to come out in 2003.

I checked out that tutorial, and it looks like XML parsing and creating is extremely easy.
But then again, it's an object-oriented standardised format, and we're using it in an object-oriented language...how hard could it be?

Believe me when I say that the parsing is the easy part.  Instantiating an unknown number of immutable objects with circular dependencies... yeah, THAT is the hard part.

not really. register all the id's first, then the prerequisites

So, this is the format I'll be trying to implement for today:

Code:

    <skill id="SK_RUSH_V01>
        <name> Rush </name>
        <cost> 600 </cost>
        <domain> combat </domain>
        <synergy>
            <synid> SK_MARTIALTRAINING_V01 </synid>
            <magnitude> 200 </magnitude>
      </synergy>
      <prerequisite>
            <prerequisite>
                <prereqid> SK_WIDEARCSLASH_V01 </prereqid>
              <prereqid> SK_RETALIATE_V01 </prereqid>
                <logic> OR </logic>
            </prerequisite>
            <prereqid> SK_LUNGE_V01 </prereqid>
            <logic> AND </logic>
      </prerequisite>
    </skill>

Also it seems that caps insensitive is not only possible, but actually trivial when processing XML.

Man, dealing with these prerequisites is nasty business.  By the way, I cannot just "register the ID's first" because that doesn't instantiate the skills.  The prerequisites reference the skills that apply to them, while the skills reference the prerequisites that apply to them.  It's a lovely circular dependency that either requires careful nesting (simply not acceptable in such a large file) or a clever "builder" class.  Unfortunately, it's only made more difficult since both skills and prerequisites are immutable.

You need to think simpler. First you store all ID's in a list, then you start instantiating the skills. Since by then you know all ID's, you can check them for prequisites.

The problem isn't knowing the ID's, but rather having the skills instantiated.

Under the current setup, a prerequisite cannot be fully instantiated before all the skills it references are instantiated, and a skill cannot be instantiated until all its prerequisites are instantiated.  I can't just leave the prerequisite or skills "empty" either, because they are immutable (for good reason; the ruleset of the game should NEVER change after initialization, and it should not support such operations).  Currently in my tester function, I've nested everything so all skills that any given skill takes as a prerequisite are declared before it is.  I cannot assume this for the XML input.  As a result, I must come up with a crafty way to initialize everything.  I've already build a "SkillBuilder" class which is used to construct skills before they are finalized.

Currently, I'm thinking of making SkillBuilder implement the SkillTree interface which would allow me to make it a valid prerequisite.  I would then make a "replace filler" function in prerequisites that would take the SkillBuilder's reference and the finalized Skill's reference as input.  It would then swap out the reference to that skillbuilder and swap in the reference to that skill.  The downside of this plan is that SkillBuilders would need retain a reference to everything that declares them as a prerequisite so they can call the function for all affected instances when the time comes.  I think this is the best approach, but I probably won't get around to it until tomorrow morning.

because they are immutable (for good reason; the ruleset of the game should NEVER change after initialization, and it should not support such operations)

if them being immutable gives you problems, the answer is to simply make them mutable. there are some things you can't enforce, and you just have to tell programmers not to do them. if you want, you can make a lock function which locks the object and makes it immutable.

the loading of skills would go as follows:

Code:

- put all skill xml-nodes in a hashmap, with the ID as key
- loop trough this map, instantiating the skill objects {
-- create the object
-- assign properties
-- instantiate it's prequisites
-- lock the skill object
-- put it in some collection
}

No worries, I have it now.  Just a matter of time until I complete the blasted thing (although the SkillSynergy class needs to be completely rewritten because the current implementation won't support some of the functionalities I now need very well).  I've decided to use "builder" classes rather than locking functions.  There is a skillbuilder, prerequisitebuilder, and synegybuilder now.  When a skillbuilder's "toSkill()" function is called, it will automatically inform all prerequisites and synergies that reference it and update them with the finalized instance of the skill.  I also agreed with you to use a hash table in this case.

Nasty block of code, though; so much data to remember and modify, and nothing can be allowed to slip through the cracks.

erm, i see this in the log

Code:

Added Paths:
-----------
    experiments/src/skillpurchase/BacktrackingSkillArray.java
    experiments/src/skillpurchase/LowResourceSkillArray.java
    experiments/src/skillpurchase/PrerequisiteBuilder.java
    experiments/src/skillpurchase/Skill.java
    experiments/src/skillpurchase/SkillArray.java
    experiments/src/skillpurchase/SkillBuilder.java
    experiments/src/skillpurchase/SkillLibrary.java
    experiments/src/skillpurchase/SkillParser.java
    experiments/src/skillpurchase/SkillPrerequisite.java
    experiments/src/skillpurchase/SkillSynergy.java
    experiments/src/skillpurchase/SkillTree.java
    experiments/src/skillpurchase/Tester.java

Removed Paths:
-------------
    experiments/src/skillpurchase/BacktrackingSkillArray.java
    experiments/src/skillpurchase/LowResourceSkillArray.java
    experiments/src/skillpurchase/PrerequisiteBuilder.java
    experiments/src/skillpurchase/Skill.java
    experiments/src/skillpurchase/SkillArray.java
    experiments/src/skillpurchase/SkillBuilder.java
    experiments/src/skillpurchase/SkillLibrary.java
    experiments/src/skillpurchase/SkillParser.java
    experiments/src/skillpurchase/SkillPrerequisite.java
    experiments/src/skillpurchase/SkillSynergy.java
    experiments/src/skillpurchase/SkillTree.java
    experiments/src/skillpurchase/Tester.java

which makes me wonder a bit, how do you edit and commit your files?

Right, that problem is solved.  Just the usual stupidity on my part ^_^

By the way, if you want to do your own testing of this segment of the code, this is the XML file I'm using to do so.  It's fairly short (a total of 10 skills), but is a good representation for testing purposes.

As of writing this, the only aspect currently not functioning is skill Synergies.  Once those are working properly, the system itself is done.  I'll probably whip together a GUI tester at that point so we can simulate skill selection and get some feedback from other people who may not be code-oriented.