Release aftermath and thoughts

So, the new release has been on the interwebs for a few days now. I figured a post with thoughts and future plans was in order.

• Some people had issues getting things to run. All of them involved needing either the MSVC 2010 C runtime, or the required mac frameworks. I didn't have them listed on the release page, which has been fixed. In the far future, and installer for magecrawl would be nice to take care of stuff like this.
• Very little feedback so far. Maybe the summer and quick release since the last tech demo have something to do with that...
• No crashes or savegame corruption reports so far. If people got the game working, it seems to be working fine.

Now that it is out the door, the next question is "now what?". Here are my current thoughts:

• Spend the next week collecting game play ideas. My wife pointed out this means I can play video games and call it "research". Magecrawl has matured past the point that calling it a tech demo is becoming a stretch, yet the gameplay is kinda bland. I want to come up with interesting mechanics to make combat more than "jam damage spell, unless I can hit more than one with a bigger spell".
• Iteration 10 - Yes, one more. I have a ton of things I need to do, refactors, cleanup, and minor feature polish. 
• Slice 1- Once I get the base in good shape, I need to come up with a "theme" for my slice. I plan on picking one skill tree, and one/a few map types, and create a lot of content. For example, maybe the arcane tree and ruins maps, or the fire tree and interesting caves. I'll jam it out to be a "full length" game, seriously this time. It might be shallow, but it'll be complete.

"Leaky" stamina, and other "balance" changes

So, I'm still hacking out changes to make Magecrawl playable.

The major change of the night implements what I hope is a solution to the HP problem I talked about last post. I decided the underlying problem was that going from 100% stamina to 5% stamina involved zero risk. Now, once your stamina goes below a cutoff (currently 80%), there is a chance that some of the damage will "leak" through and apply directly to the underlying health. The chance is inversely proportional to the amount of stamina, so you are much more likely to leak at 20% stamina than 75%. This changes make combat more dangerous overall, but having lots of stamina is still useful but not overpowering.

Other changes I've implemented this week include:

• Map generator won't generate a horde of monsters on top of the player starting position
• Monsters will notice the player from farther away when they are wearing heavy armor (noise).
• Toughness skill will now give health instead of stamina, giving the player the option to "buy" more long term health.
• Bug fixes, seriously lots of bug fixes.

The problem with HP...

I know I've linked to this tv trope, but it is seriously still true in magecrawl. For those not playing along at home, here's what the current system is:

HP is divided into health and stamina. Damage taken is drained from stamina first. Stamina quickly recovers in between battles (assuming you aren't noticed by enemies, you can't rest then). Health damage requires magical healing to fix up. Stamina represents your ability to dodge and block damage enough to get out only with scrapes, bruises, and surface cuts. Health represents actual wounds, while bandaged up enough not to get worse, would normally require weeks to heal on their own.

Let me show you my current problem with an example:

Given 100 health and 60 stamina, you fight a monster which on average does 20 damage per round and takes 4 rounds to kill. Given these stats, you'll exhaust your stamina every fight, taking 20 damage to your health. In five fights, excluding magical healing, you will be dead.

Now repeat with 80 stamina, you on average take little to no health damage, extending the number of one-on-ones to tens or hundreds. If you repeat with 100 or more stamina, you'll extend the theoretical number of battle you can last, but you'll never get close to the "jump" between 60 and 80.

This creates a problem with skills and armor that increase your stamina, at some point you'll be able to solo monsters with no danger of taking semi-permanent health damage. I have a few solutions I'm playing around with:

• Make the line between stamina and health less clear cut. When you are at 100% stamina, you are sure any damage you take will be stamina related. As it decrease, there is a higher chance some of the damage goes to your health.
• Advantages - Makes battles less one sided, as any blow after a round or two can be lasting.
• Disadvantages - Adds a significant luck factor
• Make healing stamina take resources
• Advantages - Makes every battle matter
• Disadvantages - Makes every battle matter, makes it easy to want to micro optimize which isn't fun. Starts to approach the dreaded "food" system in other roguelikes.
• Make low stamina penalize certain attributes, such as mp total or time in between actions.
• Advantages - Makes stamina damage matter.
• Disadvantages - Can snowball, making you more likely to take even more damage. In a game with permadeath, this can get nasty.
• Make the stamina and health levels relativity constant (they increase at a rate similar to monsters damage output). Skills/armor give other benefits than more stamina.
• Advantages - Makes balancing easier. One you have a good setup, just make sure the rates of growth match.
• Disadvantages - Intellectually unsatisfying. Keeps player from feeling any tougher, as at the beginning of the game to the end, the can pretty much only take x hits from a even level monster, where x stays constant.

I'm currently leaning towards the first option, but am unsure right now. 

All primary feature work is done for iteration 9, finally...

So this morning I finished up the last issues I had targeted for iteration 9 in fogbugz. The release isn't yet ready to go out, as I have to play with the numbers to make the game fun/winnable. However, outside of bug fixes, I should be done make code changes for now.

I'm hoping that balancing should be "easy" now that I have filled in tech trees and have a reasonable spread of items, but as I've said before balancing games is hard. Do any other game developers have trouble balancing stats, abilities, items, and such to make a fun game? Any suggestions on ways to make it easier outside playing the game a bunch and make lots of small tweaks?

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.

"Backgrounds" - The compromise of class selection and skill tree

One of the unwritten design guides I've followed in magecrawl has been to not ask the player for choices they can't answer before the game starts. The first time I launch a game and am ambushed by something like this (care of Crawl Stone Soup):

I get overwhelmed with choices. What the difference between fighers and gladiators? What is the difference fire/ice/air/earth elementalists? These choices are ones that are difficult to make before playing (multiple) times.

The reason this came up during my initial balancing effort is that I realized balancing some options were difficult. For example, how much should the heavy armor skill be? I didn't want to start the player with equipment they couldn't use, so by default they'd have to scavenge for at least part of a set before taking the option would make sense. It'd need to be powerful enough that it'd be worth going to all that trouble, but not so broken as that'd be the only logical choice.

Letting the player choose to use armor/heavy armor before the game makes some sense, as I could start them with a set of said armor at the beginning of the game. I've decided to try to take some of the nice features of crawl's system and pair them down to something more reasonable:

Opinions? These starting backgrounds would provide the initial equipment and preselect some skills in the skill tree. However, there's nothing to prevent a Templar from selecting skills from a tree and become a ranged attacker, beyond the penalty from using heavy armor.

Current plans on dealing with game balance, with the first step being spelling it correctly...

(Potential bloggers out there, don't write new entries when you are tired or else you might blast everyone's RSS reader with blatant misspellings like my last post)

So as I mentioned, balancing roguelikes is hard since doing so involves balancing multiple variables (with a significant amount of randomness thrown in). In an effort to motivate myself into finishing this work, I'm writing up a quick post on my decisions and strategy.

The first variable I focused on was damage output. I decided on a "base" damage an average attack should do, 10d3. For those not initiated in the "d" notation, 10d3 refers to rolling 10 dice with three sides, and summing them all up. 10d3 produces a range of 10-30, with 20 being the center average.

I chose d3s since they produce a nice range with some variability but don't have extreme variability. 5d6, for example, produces a range of 6-30, which is somewhat close to 10d3's range. However the possible "burst" of a good roll means five times the low roll or twice the average for 5d6, compared to three times the low roll or 1.5 times the average in 10d3.

Once I had the damage set, I needed to guess how many hit points monsters and players should have. I started with a guess that the average combat should last five to six rounds, which with twenty points being the average round means 100-120 hit points. For the player, I split these up in health, stamina, and bonuses from the average set of equipment I'd guess one would have.

The next variable is the rate of growth as the game progresses. Magecrawl doesn't have "levels" per say, but I assign an internal level to monsters and items. Each "level" of monster and equipment is currently scheduled to increase in damage and/or stamina by about 25%. This doesn't exactly work, I realized as I wrote the previous paragraph, since the player receives a majority of their hp from their initial stamina and health. Increasing damage monsters do by 50% while increases the stamina bonus of equipment by 50% doesn't even out. Still more to hammer out apparently...

Now that I have some guesses of numbers, I coded them in and forced the map generator to produce only a single type of monster. I'm planning on playing a good number of games, tweaking the numbers so that I can "win" a decent percentage of the time but not always. Once I have that single pairing balanced, I'll continue with others until I have a good feel on the numbers that are fun....

The trouble with game balencing is that it is hard....seriously

So part of the long delay between this and the last post was a (hopefully?) well deserved break after a mammoth week of coding. However, part of it is related to my lack of progress in balancing the new monster/weapon/quality types. Trying to keep individual fights interesting while keeping ambushes from turning into two turn player-deaths and making it scale after (for now) 5 levels is hard. Like harder than writing the code that allowed it.

Part of the problem is I want to get rid of the issue I call "rounding-error bonuses". For example, let's say that having a quality weapon improves the damage by 15%. If your sword base damage is 1d4, then 15% is less than 1 point of damage. It'd have effectively no effect. One could solve this by increasing all the numbers by a factor, say 10, then the sword base damage would be 10d4 (10-40) and 15% is on average 3-4 additional damage. Getting these numbers correct, along with making them look reasonable isn't going so well. It seems weird to have the starting sword do 10d3 damage and average swings totaling 18 or more (maybe that is my experience in d&d based roguelikes and games talking).

Does anyone have a good system or set of tools for figuring this out? Bonus points if it has been proven in a shipping game or one at least farther along than magecrawl...

7DOMC - Day 7 - Monsters and thoughts on this week

With my commit here I'm done with my XML generation changes this iteration. Monsters now have different names that are level dependent, with base stats and some stats that go up each level. The "trait" system has been booted to iteration 10 due to my exhaustion in this area of magecrawl. I need to create some content for items still, item levels for each armor/weapon from 1-6 or so, but otherwise I have the base material for a sane difficulty curve.

So, if you've read this blog any this week, you probably can tell that I've been busy. With my wonderful wife coming home tomorrow and family in town next weekend, it'll probably be a few weeks before I implement anything major.

Looking back on this week, I think the fact that I announced my intentions and wrote about them every day was useful. There were days that I didn't want to program, I would have rather played TF2 or Borderlands all night. However, the idea of skipping a day's post or admitting I didn't get anything accomplished pushed me to do some programming. Once I overcame the initial hump of launching Visual Studio, I generally started to enjoy my work.

In some regards I got less done that I expected, but I think that was due to me vastly underestimating how much work some of my tasks would take. Item generation based on levels took three or four times longer that I would have initially assumed. I think it would have taken even longer if I had to break it up over a week or two's evenings.

I have 26 items left targeted for this iteration. With the possible exception to my "field" idea for improving monster AI, each of them should involve significantly less work that either the item or monster changes this week. They should be "bite sized" enough to tackle one or two after work some night.

7DOMC - Day 6 - I thought I was done with items, but I made them better.

So on day three I said I was done with the item rewrite. While this was a true statement, I realized today that there was one way I could improve items even more. The current system had each material list the base stats for a weapon/armor made of it. Something roughly:

Wood Club - 3d3  CTCost=1.0
Iron Sword - 4d6 CTCost=1.25
Cloth Armor -  +5 stamina

The issues is that I had to list out each statistic for each material. If I know that say leather is 20% more stamina than cloth (the base type), I'd need to calculate that and put both values into the XML. If I decided to increase the base later, I'd need to update all the values again.

To fix this, I now have materials list a percentage or linear amount better they are than base. For example, Wood adds 1d3 damage and leather adds 20% more stamina than base. If I update the base values, the change will propagate to all armors/weapons.

7DOMC - Day 5 - Monsters AI changes wrapping up

So, all the great AI work that I did a few iterations back can be distilled into this chunk of code now:

switch(typeName)
            {
                case "Bruiser":
                    tactics.Add(new DoubleSwingTactic());
                    tactics.Add(new DefaultTactic());
                    break;
                case "Healer":
                    tactics.Add(new UseFirstAidTactic());
                    tactics.Add(new MoveToWoundedAllyTactic());
                    tactics.Add(new DefaultTactic());
                    break;
                case "Ranged":
                    tactics.Add(new KeepAwayFromMeleeRangeIfAbleTactic());
                    tactics.Add(new UseSlingStoneTactic());
                    tactics.Add(new KeepAwayFromPlayerIfAbleTactic());
                    tactics.Add(new PossiblyRunFromPlayerTactic());
                    tactics.Add(new WaitTactic());
                    break;
                case "Sprinter":
                    tactics.Add(new RushTactic());
                    tactics.Add(new DefaultTactic());
                    break;
                default:
                    tactics.Add(new DefaultTactic());
                    break;
            }

I obviously plan on pulling this out into an XML list or something similar, and add more intelligent "tactics" so I can make the AI even smarter. One idea I had would have slingers who don't have a line of sight for a shot to move to one more likely. Another would have healers find bruisers and stay togeater, kinda like heavies and medics in TF2.

Now that I have a "flat" monster hierarchy, I need to write generators similar to the ones I wrote for items that'll create level dependent monsters.

7DOMC - Day 4 - Planning and Monsters

So, after the craziness of the last two days, today is a bit more subdued. Part of that is a bit of burnout and part of it is busyness at work.

Even with the work {I've/I'm going to} accomplish, my chosen tasks for iteration 9 were a bit much. I pushed back 12 minor features to another iteration, giving me 28 total. For those doing math, that doesn't exactly add up to previous posts, which is due to me splitting a few tasks up into smaller bites.

Speaking on smaller bites, I'm working on refactoring monsters completely as well. I want them to be more attribute based, like skills and items, and have more flexible behavior. Since they touch a smaller portion of the code base, I'm doing my refactoring in smaller bit sized pieces.

Update -
So I'm not done yet, but here's the jist of it.

There is a set of tactics, which are discrete single actions that could or could not be preformed. Each tactics can be asked if it could apply now and ask to do it. Then a loop like this runs:

            m_tactics.ForEach(x => x.NewTurn(this));

            foreach (IMonsterTactic tactic in m_tactics)
            {
                if (tactic.CouldUseTactic(engine, this))
                {
                    if (tactic.UseTactic(engine, this))
                        return;
                }
            }

Each monster would have a set of possible tactics, for example, my healer AI can be stated as: UseFirstAidTactic, MoveToWoundedAllyTactic, DefaultActionTactic.

Each tactic setups the required attributes on the Attributes dictionary of the monster, which are serialized, so things are remembered past save/load like the cooldown on the first aid ability.

The cute thing about this is once i code up a great new behavior, I can slip it in the monster behavior list and it'll start acting that way. Once I'm "done", I'm going to be pulling the list of behaviors a given monster has out to XML.

7DOMC - Day 3 - The item rewrite is done...finally.

So the patch I submitted was six thousand lines long, and took a grueling day of coding yesterday and half a day today cleaning up loose ends, but it's done. Much of the work involved moving a hierarchy of classes that defined weapon, armor, and consumable types into a flatter set of classes that allowed more dynamic changes.

A quick overview of the way I generate items follows:

For armor/weapons:
We start with an expected item "level", determining how "good" the item should be. We first calculate a quality grade, which falls from -2 to +4 on a normal distribution. We then determine how many "levels" we have left to choose the material. Each material, for example wood, iron, or leather, states what items can be made of it and what their properties are. Some materials have higher level modifiers, so a bronze would be lower level than say cold-forged iron. The material determines the base damage/speed/protection of the item, while the quality increases or decreases it by percentages.

For potions/scrolls/wands.

A slightly different approach is taken. An effect is first determined, using the requested level item as a range to select from. Wands cut the level in half, since they allow the effect to be produced multiple times. For any left over levels we increase either the caster level of the effect (for potions/scrolls) or the number of charges in wands.

I still need to implement the bulk of the content, for example material types for each weapon  varying over the ranges, and a ton of playtesting to find bugs and determine values for each material/quality. However, the coding for this headlining feature is done. :)

7DOMC - Day 2 - The great item rewrite

My first task today has been completed, which is moving all the skills to use the new attribute based system detailed here.

I looked at doing the same with items, when I realized that I'm going to have to rewrite pretty much my entire item hierarchy to do things right. I ripped out (with a backup copy for reference) all the item, armor, and weapon classes from the game engine, and commented out or "throw new System.NotImplementedException()"'ed all the code using them. Now I can start again from scratch and when the diffs show no commented out code, I'll be back where I started.

I very rarely try a rip out and rewrite. In general, I find a set of small incremental changes work best. However, the shear size of the item hierarchy was daunting to say the least. We'll see how this goes, I'll update later.

Update 1 (10 hours later)

So I have the weapon system up again. I've got generated weapons of various qualities and materials. The weapons damage is base speed comes from the material, with the quality affecting things as well. Descriptions are built up from the various parts, along with the names. Save/load works again for weapons. Much of the work was creating a brand new hierarchy for weapons, and the generator for materials and quality.

I'm hoping to get armor up quickly now that I have this base. Then I need to rework consumables, such as potions/scrolls/wands.

Update 2 (1 hour later)
Armor works, with quality, materials and the like. Now onto consumables.

Update 3 (1 1/2 hours later)
Obviously things are taking longer than I'd expect. I'm almost all the way through consumables but I'll have to wait for tomorrow to finish up and submit.

7DOMC - Day 1 Status

I'm winding down for the night, and I'm pretty happy what I accomplished today. Here's what I accomplished today:

• Magecrawl for Linux - This single task involved hours of work. rpath's still leave a bad taste in my mouth.
• 14 open tasks - I went from around 51 open items to 37. Some of these work items were tiny, while others involve entire features, so you can't say that I'm 27% complete however. 
• One of those open tasks required me bringing some sanity to how MagicEffectsEngine::DoEffect outputted text to the log. It look awhile, but now looking at that file no longer makes me wince.

However, other that the Linux task, I didn't touch any of my head lining features.

There is still much to be done this iteration (and this week).

Will the penguin in the room please stand up...

Magecrawl now works on Linux again. You'll need a new copy of mono (one that isn't released yet but will be before my next release), but it works!

For those who care about the bad things I had to do to make this work, read on...

So, the major issues were causing problems was the libtcod-net-unmanaged library was not working as expecting.

The first issues was both mac and linux wanted to create a library called libtcod-net-unmanaged.so. I modified the make files to create to new files and used mono's dllmap to point the right platform to the right binary.

Once I fixed that, I was getting missing symbol errors. I had forgotten that libtcod.so doesn't have the C++ symbols under Linux. I linked against libtcodxx.so, copied that in, and fixed that.

The final issue, which took three of four hours to solve, invoked this bug in cmake. I had to use an internal "don't use this, it could break on new versions" macro to work around it. The code in question is:

IF(UNIX)
     SET_TARGET_PROPERTIES(${SWIG_MODULE_${CSHARP_LIB_NAME}_REAL_NAME} PROPERTIES LINK_FLAGS "-Wl,-rpath,.")
ENDIF()

with SWIG_MODULE_${NAME}_REAL_NAME being the forbidden fruit.

7DOMC - Seven days of magecrawl coding

As I mentioned in my previous post, I have a huge list of things I'd like to accomplish in magecrawl in the short term. It just happens to be such that my wonderful wife is going to be visiting friends out of state until next Sunday. Combine this with a Monday/Tuesday holiday off work, and I have a significant amount of free time this week.

My hope is to stay productive (not just play Eve online and TF2) for most of the upcoming week. We'll see how much I get accomplished. I'll be posting updates as the week progresses.

"Iteration", I don't think that means what I think it means...

So I have some time next week to work on magecrawl, and so I'm looking at my task list and realizing I currently have a ton of things targeted for iteration 9. Ignore the bug fixing and corner cases issues, I have these high level goals currently:

• Create level dependent items and monsters
• Refactor how skills and items are handled to combine with new traits for monsters
• More effect work, including debuffs specific to various schools attack spells.
• "Field" effect to model sound/smell to make monsters seem more realistic.

In addition to this, I currently have 51 open issues targeted to iteration 9. Some of these issues are minor, but some include creating new classes of items, major new spell types, and other significant chunks of work.

I'll talk about my short term programming goals later this weekend, but the short answer is unless I seriously knock a lot of this work out soon, I'm going to have to punt on stuff to an iteration10 or have a bloated schedule.

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?

Iteration 9 - "Levels" and polish

So, I haven't had the time I wanted to work on magecrawl this week, but the ideas keep coming. I have over 50 major/minor/bug fixes I wish I could get into this iteration. Before an iteration, I try to come up with a "theme" tying together what I hope to accomplish in the next few months. This iteration (9), the theme is "Levels and polish". It also may be the last iteration before I move onto the next stage of my development plan.

The "levels" in the theme refer to varying levels of difficulty in challenges, not different floors connected by stairs (which I already have). For example, the wolf that attacks you at the very beginning of the game should be different than the wolf pack that hounds you a few levels later when you have better equipment and skills. The quality of treasure should also vary based on depth.

My current idea is to create an engine that creates these monsters and items on the fly. For example, asking for a level 3 monster could create a fast (+1 lv, 25% faster), strong (+1 lv 25% dmg) base kobold (base creature). Or it could create a experience goblin (+2 stat levels). A combination of traits (such as fast, strong, special abilities) and stat levels (more hp, etc). A similar system would exist for items, so creating a level 5 sword could return a masterwork wooden sword or a crude iron sword. Each quality grade and material would contribute to the effective level of the item, along with any enchantments.

I think this system should help me balance magecrawl's difficult curve. Manually creating monster and item stats based on paper calculations is difficult and time consuming.

In addition to "levels", I have a huge number of polish issues that I'd like to implement. They range from the status effect ideas I listed here to internal refactoring to improving monster AI.

As I mentioned, this might be the last "iteration" of magecrawl. I think I laid this out on some other post, but finding it escaped me. The idea of iterations are to fill out functionality needed in the game engine and GUI needed for a "real" game. After I feel like I have enough functionality, I'm planning on moving to "slices". Slice would be a portion of the full planned game, from top to bottom. For example, the first slice could be implementing the entire fire skill tree and all its spells, and flushing out sections of the dungeon. The game itself would be a full (albeit shallow) game. After releasing that, I'd take another slice of say the water tree and more dungeon sections.

Well I should get off to coding...