Showing posts with label 7DOMC. Show all posts
Showing posts with label 7DOMC. Show all posts

Saturday, July 10, 2010

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.

Friday, July 9, 2010

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.

Thursday, July 8, 2010

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.

Wednesday, July 7, 2010

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.

Tuesday, July 6, 2010

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. :)

Monday, July 5, 2010

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.

Sunday, July 4, 2010

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.