When making a type of change in your game is tedious, first fix things so that it isn't anymore

So part of my balancing work involved buffing the player's abilities when it makes sense. One way to do this is to add new skills on the skill tree. However, the system I had in place for read/displaying the skill tree made me hesitant to do so, as even a simple change was a lot of work.

The previous system involved a text file with a grid of ascii characters laying out the exact location for each node, along with a list of positions below to match each one up with the associated skill. If I wanted to add more nodes, I'd have to manually place it, then calculate the offset and write it below. If I needed to make the grid bigger, I'd have to recalculate the offset of every node for that tree. It pretty much never should have gotten submitted in that state, but it was "good enough" for the simple trees I had implemented. The horror can be found here for those who are morbidly curious.

I noticed that all my nodes were in a grid, so I converted each text file into an xml file describing the skill tree. One example can be found here. I then wrote the xml reader and which would generate from the stored information the grid of characters to display on the screen. Overall it took about three hours to write, test, and submit.

In less time, I probably could have made my balancing changes and "got out" without making things better, but I would have been more likely to not add new skills in the future. Now adding a new skill is as easy as copy pasting an xml node and changing a few lines of text.

A generic system for implementing skills, traits, and item bonuses...

I know the title is a mouthful, but if beyond it is an idea I'm excited about. Like most ideas, it came to me when I was doing something other than programming.

This iteration I'm planning on implementing varying difficulty monsters and hopefully items of varying strengths. In my previous post, I suggested using a "trait" system to implement some of the monster characteristics. For example, one wolf might be "fast"-er or "strong"-er than another, trading that off against some additional base attributes. In my head I hoped to sneak in items with enchantments; a sword that could make you tougher or a staff that made you case spells better.

It came to me that both of these use cases are very similar to the skill tree attributes I implemented last iteration. Those skills could increase base stats or allow new skills. As a programmer, when I hear of three different implementations of an idea, I get an itch to make a generic framework or factor out the pattern or something.

The crux of the idea is that all of these ideas can be implemented as a system of tags and values. For example, a skill that increases the characters base hitpoints by 5 could be:

m_player["HPBonus"] = 5;

Then to calculate the number of hitpoints in this simple example one can do something like:

// Player
int GetSkillTags(string tagName)
{
    int total = 0;
    foreach(ISkill s in Skills)
    {
         if(s.attributes.Contains(tagName))
             total += s.attributes[tagName];
    }

    foreach(IItem i in Equipment)
    {
         if(i.attributes.Contains(tagName))
             total += s.attributes[tagName];
    }
    return total;
}

// Monster
int GetSkillTags(string tagName)
{
    int total = 0;
    foreach(Dictionary<string, int> d in Traits)
    {
         if(d.Contains(tagName))
             total += d[tagName];
    }
    return total;
} 

Once I implement a given skill or trait checking in one section of the game engine using this API, creating a new skill, item attribute, or monster trait to do the same thing is trivial. Also, since checking if a dictionary contains a key is fast, it should be efficient as well.

Thoughts?

Skill Tree Complete for Iteration 8

So the planned features for the new skill tree in iteration 8 are complete. Here's what it looks like

I now have 3 somewhat fleshed out trees (at least fleshed out for a tech demo) and one token tree. SP are earned for killing monsters, and spent in the tree. Dependency information and skill point costs will show up in red on cursor over if they can not be met.  

I've determined that in the short term at least, I'm going to have magecrawl use a pure skill approach, with no "character levels". As players get SP, they can level up in both new spells and abilities to improve existing ones. Right now the skill tree is filled out just for showing that it works, but in the future I expect each tree to have 30+ nodes. If you want a glass cannon, you spend points just in the elemental trees and none in the martial trees. If you want a "mystic knight" you spend half your points or more in the martial tree, earning armor and improved stats, and cherry picking the light or elemental spells you need.

Balancing everything is going to be painful in the short term, but with SP being the cost skills, I hope it is manageable. Much play testing and feedback from early players will be needed.

FogBugz says I have about seven hours of work left right now.

Assuming that keeps somewhat on schedule, I should have a tech demo out by my new-self imposed deadline of middle of next week.

More Skill Tree Goodness

The skill tree is starting to shape up. Here's what the current build looks like...

I've added dependency information (albeit in a kinda hacky file format), and a "tab bar" of different trees. Each tree is read from a different file, and can contain any number/configuration of different skills.

Here's the confirmation dialog I mentioned from last post...

The spellbook ('z') now takes its cue from the skills the player has taken, with a few skills that provide spells already created. I need to add skills that provide improvements in spells, ones that passively increase stats, and ones that allow the use of certain equipment.

Laptops on a plane, some things take longer than you'd expect...

So last week I went home for a family member's college graduation and had the joy of bringing my new laptop along. Hacking on code for 3-4 hours makes plane trips seem faster and airport waits suck less. Here's whats new:

• In skill tree can select/deselect nodes, which change color
• Selecting new nodes on dialog exit will add them to a list the player has, which is persisted.
• On next open of skill tree, previously selected nodes show up a new color and can not be removed
• A dialog appears when you exit with new nodes, asking to confirm the changes
• Initial work on dependency information, so you can require some skills for another

It was that second to last item that took the longest. The problem with nice generic framework code is that sometimes it is hard to add new things. In this case, it was one dialog bringing up another dialog which refused to be dismissed until a choice was made. On selection, it had to communication back to the original dialog the choice made. Make all that a generic dialog for any two button dialog, and that's what I implemented.

This isn't that hard if you have one of the sub-dialogs run a message pumping (draw, blit, read keystrokes) loop, but that is something I have vowed never to do again. It took 5 or 6 classes and a bit of thinking, but it works now.

Things to do until skills can be considered "good enough" for this release:

• Finish up dependency information on skills
• Make selected skills do something: add spells, increase stats, allow equipment, improve spells
• Make skill tree take skill points to select nodes, reward these for level ups, so create exp for player

Skill Tree Initial Work

So one of the primary goals for this iteration was a skill tree. I love games with an in depth set of skills to choose from. Whether strategy games, or RPGs, having a long tree to climb with choices and tradeoffs brings a richness that I enjoy.

I'm far from there yet, but here is what I have so far...

It's a "field" of nodes, read from a file. Each one is associated with a skill read from xml. It currently doesn't do anything yet, but the idea is that as the player levels, they will get skill points, to spend in the tree.  

In the future, it will be a tree (or more accurately, a forest), with dependency information. Some nodes will give new abilities, other improve existing ones. There will different trees for each spell school, and most likely a tree for "martial" skills like weapons/armor/etc.

An idea I've been kicking around is making the cost of nodes dependent on the number of nodes you already have filled in on a given tree, and inversely dependent on the number of nodes filled in on the opposition tree. For example, every node you fill in on the fire tree makes other fire skills cheaper, but adding water nodes makes fire nodes more expensive. That way, we make dipping into opposing schools more difficult but not impossible.

I have a lot of work to go, but I'm excited about the concepts and what I have implemented so far. Any thoughts?