This is a collection of things I've learned or am trying out.

7/25/09-In working with WPF I've learned that in places where I have parameterless functions in classes (usually used in calculations with field members), I should use ReadOnly properties instead.  This is because WPF doesn't like functions.  Since functions are usually thought of as input/output and not strictly output, ReadOnly properties are technically more proper to use.

-I've been working with character sheets which let me view all of a character's info at once.  This has been very useful as it's uncovered multiple initialization issues.  I don't recommend adding this UI until later in development since your character properties change so much.  Mine is set up so that any creature can be viewed through it and I recommend this approach.

-I put WPF items in a different solution than my Scara stuff.  It's definitely a bit of a hassle keeping both solutions coordinated.  Initially I added a WPF project to the Scara solution but most of the time I ended up having to use Win forms as a medium, and I didn't want to add a lot of fancy WPF display content that may never appear as part of the game.  Good news is that I can also skip the world-building routines in my WPF solution, so testing has been much faster.

...

-Thoroughly use enumerations-directions (north, south, etc.), alignments, anything that's set in stone.  It's much easier to read and is easy to expand-for example, I used to test for cardinal directions only but eventually included up/down as well as upper-north-west etc.  Since my loops iterated all values, all I had to do was expand my enumeration without worrying about updating code that had hardcoded values.

-I'm trying a new technique (to me): event-oriented parameter passing.  When an event happens, relevant information is stored in a custom event-ex: tile of swinging creature, tile of victim, event type (melee attack).  Every item, skill, effect, etc is iterated to see if it does something special on that event-ex: attacking creature uses a +1 sword that gets a bonus to hit and to damage.  This may seem needlessly complicated but it's much easier and more flexible than figuring what affects what every time something happens.  Using the above example: say I make the mistake of only calculating attacking creature's attack roll with target's AC.  What about the bonus from the sword?  What about spells like Bless that might affect the roll?  What about the attacker's weapon proficiency?  What I do now is code the attack event including the roll and pass that event along, allowing skills, spells, etc., to affect attack roll or whatever as it gets passed down the line.

-I'm also trying a new message system.  Each message will have a visual, audial, and/or tactile component.  If you're blind, a swing message ([creature] "hits you.") will become "someone hits you."  A message said to you in a foreign language will be garbled.

-Do not code creature inventory on-the-fly.  It really bugs me when an NPC can give you a reward but if the NPC dies before they can give that reward then it magically disappears.  And rogues who should be properly rewarded for successful pickpocketing will find it unrealistic when the item magically appears only when the programmer thought it was convenient.  This bad practice can also produce unrealistic items on creatures-coins on non-intelligent beasts, healing potions on undead, and magic weapons on people who could never use them because of alignment or some other restriction.

-Pass location info in parameters.  I had to do a lot of recoding because I needed to know what was around a creature even though from a strictly object-oriented perspective it wasn't necessary for that sub.  For example, a sub for drinking a potion in theory should only need to know the creature and the potion.  But if the potion alters the creature's appearance or affects a group around the creature, then the surrounding creatures should notice the effect.