Sunday, December 13, 2009

Ighalsk - The Nature of Illusions

Lord Apathy has a number of different types of illusions serving him - some on loan from other Lords of Illusion. These include "Embarrassment" illusions, so called not because they embody embarrassment themselves (and somehow infect those they encounter), but because they induce embarrassment in others. With disparaging comments, a haughty stare, and eye-rolling, such an illusion conveys a strong impression that your appearance, actions and indeed thoughts and plans are ridiculous, inappropriate and just plain wrong. It is an illusion, but the feelings of embarrassment that it causes are real.

Another type of illusion at Lord Apathy's command is "Paranoia". Again, it is not itself paranoid, though it may pretend to be. Instead, it induces paranoia in others. With whispered words, raised eyebrows and significant pauses, it insinuates that you have been betrayed and everyone is plotting against you, waiting for your slightest mistake to pounce.

These illusions can be destroyed (unraveled) in several ways; they are resistant to physical weapons, but most vulnerable to a Philosopher's use of reason.

Monday, November 30, 2009

Ighalsk - Tests and Time

At a recent checkin, there were 486 tests defined for Ighalsk, which took 31.8 seconds to run (on my old laptop: 500 MHz, Win98). I'm happy with the number of tests, but would like to decrease the time somewhat (still too many file accesses).

A Google spreadsheet showing some numbers and times for different revisions is available here. I don't know why the time went down to 9 seconds and back up again almost immediately, but I think the dip from 23.3 seconds to 20.9 seconds was just after some test refactoring to speed up tests - probably replacing file I/O with StringIO (see previous post).

Also, I now have a Twitter account here - any updates to these numbers/this spreadsheet will probably be posted on Twitter first (and possibly only). I'm working on increasing the popularity of #roguelike ...

Thursday, November 26, 2009

Ighalsk and Motivation

Ighalsk is not the first software project that I've worked on at home, or even the first game. But it is easily the most mature and furthest along. With earlier projects, I've had a great idea, started working on it, got a few things done, and then my enthusiasm has slowly worn off and I've given up.

With all my projects, I've only had an hour or two to spend on them in a night, and some nights that dropped to zero. Often in this time I'd get started on a task, but wouldn't have time to finish it - I might find a bug, or the task might be more complex than I'd planned for. Then I'd need to wait a day or more before I could work on it again. This was frustrating, and it made me feel like I was going very slowly.

With Ighalsk, I've generally been able to get something finished each night. Part of the reason is that I'm using Test-Driven Development (TDD) almost all the time. This means that my work cycle is usually: write a new test, run it to check that it fails, write just enough code for it to pass, check the changes in. A lot of the comments that I make when I check in changes start with "Added test + implementation of ..." Similarly when I refactor, each refactoring is small and I test it before I go further, so that when I do make a mistake, I can go back and fix it easily. It helps that the full set of tests runs in less than a minute (though I still want to speed them up further over time).

TDD has meant less bugs - or more to the point, that it's quicker and easier to fix bugs - and frequent refactoring (not to mention using Python!) has meant simpler code. Both of these factors have also helped me finish tasks more quickly and feel like I'm making progress.

Motivation has been less of a problem lately; I've got to the point that I have a playable game, where it's easy to see how any new functionality can fit in and will be usable immediately.

Doubtless it's also helped that I don't have any new games that I want to play at the moment - though often ProgressQuest is running in the background while I work on Ighalsk, and I've started playing FreeCol years and years after I last played Colonization ...

Friday, November 20, 2009

Ighalsk - releases 0.1.9 and 0.1.10

I've just released Ighalsk v0.1.10: you can download the source code here. This blog post also covers the changes in v0.1.9, since I didn't write a separate blog post about those.

Changes in v0.1.9:
* Weapons, attack powers and monsters now all do random damage (using a new Dice class). As discussed in the previous post, a Dice object can be created with a string such as "4d5+6". There's a little bit more to it than that; for example, when returning the string (which is used in the character screen or when examining a weapon), zeroes are dropped: "2d3" looks much nicer than "2d3+0".
* Savefiles now use compressed versions of the Hero and the current level. This reduces the size of the savefiles by a factor of about 8, and should improve savefile stability between releases (e.g. changes to methods in a class shouldn't affect the savefile). More savings are possible: currently (in v0.1.10, I should say) the walls in a level are saved as a list of booleans, which takes a number of characters per wall. They could instead be packed into 16-bit integers (just for saving and restoring - for speed, they'd still be a list of booleans during play).

Changes in v0.1.10:
* Refactored Level to use a list of booleans for walls. This speeds up level generation and also simplifies the code: there was a Square object for each square, doing nothing but holding and making available a boolean (whether or not that square contained a wall).
* Printing level to screen is now done in 2 passes for speed: the first for walls, the second for everything else. This is because everything else is sparse: that is, stored as a list of objects with positions, while the walls have one value per position. (Checking the list of monsters in a level for each square to see if it has a monster in it was taking some time.)
* Extracted resists of Beings, Families and Armour to a separate Resists class for ease of adding resists and returning the resist for a given damage type. This removed duplicate code between Being and Adventurer, and also simplified the size of both classes.
* Added BoostPowers which improve resistances temporarily, and Boosts to hold current improvements. Any Being can have boosts theoretically, though in practice only the Hero can, if she or he uses a boost power on herself or himself.
* Blessed and Mighty Heroes can now use a boost power: "Tenacity" and "Courage" respectively.
* Fixed bug 2889190 where up and down were reversed when using keys on the numeric keypad: thanks to Genosha for raising this bug.
* Added 7 new Monsters: Lesser Haunt, Paranoia, Zombie, Ivy, Flatworm, Ghost Spider, and Greater Huntsman. (The Zombie here is a common, stock-standard zombie; variants will be added later.)
* Added Monsters for level 3 of each quest.
* Characters saved with release v0.1.9 *can* be loaded using this release! (I've only tested this for one character, but I don't expect any problems for special cases.)

I've now implemented most major pieces of functionality that I was planning to add before releasing v0.2.0. The exceptions are adding a Level Editor and special levels (level 5 of each quest) - the plan is to use the Level Editor to generate the special levels :). Of course, there's a bunch of tidying up and refactoring to do, plenty of minor functionality that could be added, content to add (new armour and monsters are the most critical parts) and no doubt bugs to fix.

Tuesday, September 29, 2009

Ighalsk - release 0.1.8

I've just released Ighalsk v0.1.8: you can download the source code here.

Changes since the last release include:
* Throughout the code, Profession has now been replaced with Epithet. That is, Heroes now have an Epithet, which summarises their powers. This brings out more clearly that the powers and abilities of a Hero are inherent rather than the result of training. It also implies (at least in my mind) that the Hero is unique, and shouldn't expect to run into opponents with similar powers and strengths when following Quests.
* The available Epithets for Heroes are now "Mighty", "Philosophical", and "Blessed" (as described here). That is, instead of "Joni the Warrior", a Hero would now be called "Joni the Mighty".
* When generating a level, corridors are now checked whether they overlap with existing open spaces before they are placed (and won't be placed if they do overlap). This makes evading monsters considerably easier - previously, the corridors were too tightly packed together and often did overlap; now, monsters often get stuck and have to wait until the Hero comes closer. (Yes, I guess I could implement path-finding (or at least a look-ahead of a few moves) when I get a spare couple of months, but I'm concerned that that would also slow down the game, which seems to have slowed down already over the last release or two for some reason.)
* Increased the size and number of rooms and corridors in levels, while keeping the number of monsters the same. This goes with the above change - now there can be more rooms and corridors without them being tightly clustered together. Reducing the monster density also means that there's not such a desperate scramble for survival when the Hero first enters the level. I'm still not altogether happy with how the rooms look on a level - the BSP algorithm mentioned on Roguebasin looks like it would generate better-looking levels.
* A Hero now has different physical, mental and spiritual strengths, depending on their epithet; a strength may add to the weapon damage, depending on the weapon. In particular, Mighty Heroes have physical strength of 4 and other strengths of 0; Philosophical Heroes have mental strength of 3 and other strengths of 0; Blessed Heroes have spiritual strength of 2, physical strength of 1 and mental strength of 0. So for example, a Mighty Hero using any bladed, blunt or piercing weapon will get 4 extra damage with that weapon; a Blessed Hero with such a weapon would get 1 extra damage, and a Philosophical Hero would get 0 extra damage. The exact values, as with so much else, will get balanced later, when the combat system is stable.
* Added a Character screen which displays the Hero's attributes, including the total resists (due to armour worn) for different weapon (damage) types such as fire, blade, or blunt, and the damage that the current wielded weapon will do, due to both the weapon itself and the Hero's strengths. This screen also displays the gold that the Hero is carrying; previously, the only way to know how much gold the Hero had was to try to buy something from a shop.
* Added descriptions of quests, which can be accessed from the Palace screen. This involved a few unexpected fixes, in that the description is read in from a text file and reformatted - but then spaces have to occur in the right places, I wanted to be able to have paragraphs in a description, and a couple other minor problems. Still, hopefully I'll be able to reuse the same format in other places (like monster and epithet descriptions).
* I also replaced one system test with a unit test for speed and simplicity - the unit test should still catch the same bug that the system test was designed to catch.
* Similarly, I refactored the Movement class to simplify it: it now only sends messages to one viewer object, where previously it also sent them to each viewer object in a list. (In the current implementation, there was only ever one viewer object in that list.) If necessary, with the refactoring, the sole viewer object could always forward messages to other viewers on a list - but I doubt that that will be necessary for this game.

Next I might focus on monsters again. I'd also like to introduce variable damage for weapons, probably using a Dice class. The constructor method for this class would take a string of the form "4d5+6", which would represent 4 dice, each with 5 sides, with 6 added to the result. (Or if you'd prefer, each die could have 20 sides, and each number could be repeated 4 times.) Each dice object would then have a "roll" method to randomly generate a value.

I would like to also introduce monster memory sometime soon - that's memory that the Hero has of monsters, not memory the monsters have of the Hero. It might be helpful to know what a Bladeworm or Nightcat looks like, though hopefully a Vampire Moth is self-explanatory ...

Tuesday, September 1, 2009

Ighalsk - release 0.1.7

I've just released Ighalsk v0.1.7 (you can download the source code from here). A lot of little things have changed since the last release:

  • The Monster Editor can now be navigated using buttons as well as keys; it also supports more than 12 monsters.

  • The Hero (PC) can now die - yes, this is a necessary feature - perhaps unfortunately; I've been playing "Lego Star Wars" with my son, and it is refreshing that characters in that game just fall apart and quickly come back together again after dying. There have been some interesting discussions of permadeath in roguelikes recently here and here.

  • After examining an item, the next screen is either the Inventory or the Equipment screen (whichever screen the item was examined from). Previously the next screen had been the map of the current level; I've now implemented a stack of states, pushing the old state onto it every time the state changes, and popping off states after examining an item. This should be useful for other screen transitions as well.

  • Treasures are now generated and placed randomly on quest levels, and can even be picked up by the Hero.

  • There's also more to buy with treasure: I've added 3 new, more powerful and more expensive weapons in the Weapon Shop, one for each type of Hero (profession).

  • I've added 9 new monsters, using the Monster Editor, and 2 new families of monsters (worm and plant).

  • This gave me enough monsters to fill in level 2 of each of the 3 quests.

There were also a couple of small refactorings that shouldn't affect game play but will make the code easier to maintain and extend.

These aren't present in v0.1.7, but here are some draft descriptions of the different types of Hero (originally mentioned here):

You were born with strength and athleticism far surpassing those of ordinary men and women. You are trained in the use of an incredible variety of weapons, and in the tactics of war. You have wrestled bears to the ground, defeated a squad of enemy soldiers single-handed, and executed flawless tactical retreats.

You are divinely blessed. You have been given the gifts of healing and protection. You are called on to fight evil and bring peace to the land. At your approach, flowers blossom, birds sing more sweetly, and undead gibber in terror.

You have spent many hours studying books and in the company of your own thoughts, and thereby learnt many mysteries. You can influence the universe and shape matter and energy using only the power of your mind. You have also practised the arts of argumentation, and can use them to reduce untrained and unshielded interlocutors to a state of helpless confusion. You know the names of stars, the greater and lesser syllogisms, and the secret delights of pyromania.

A friend also suggested another type of Hero, which I'm thinking of calling *Cunning*, but this type needs more features to support it and so might not make it into Ighalsk for a few releases yet ...

Wednesday, July 22, 2009

Ighalsk - release 0.1.6

I've just released v0.1.6 of Ighalsk here. (Yes, I skipped v0.1.5 - I actually made a tag for it in Subversion, but then discovered when I tested the zip file that I'd forgotten to check in a new file ... so it got superseded by v0.1.6 immediately.)

As planned, Ighalsk now has quests. True, each quest has only one level at the moment (there will eventually be 5 for each), but it's a start. One of the quests is to "defeat Lord Apathy in the Tunnels of Lost Dreams". For those who lack motivation for this quest, here's some background.

Lord Apathy is the least powerful of the Lords of Illusion. He sits (or, more often, sleeps) in a half-completed maze of tunnels filled with lost dreams, brooding, bitter and unkempt. From here, he spreads despair, hopelessness and, yes, apathy across the countryside. He should probably be stopped.

Another quest is "Defeat Elannonen the Lost in the Necropolis of Zezun". Queen Miala points out (will point out), "Why do we keep on building these cemetaries and tombs and graveyards if they just fill up with undead? Why don't we start cremating our dead?"

The final quest present in this release is "Defeat the Witch-Spider Skkshryx in Arachnaxos", about which I have little to say except that the witch-spider is not fond of vowels.

Tuesday, July 7, 2009

My Own Personal Sadness Troll

The inspirational Havi Brooks has several posts about talking to your monsters (fears, anxieties, stresses) about what they need and why they're doing what they're doing. She even suggests bringing in an (imaginary) negotiator if that would help.

My biggest problems at the moment aren't fears so much as sadness and anger. So I set up an interview with my own personal Sadness Troll. I picture him as huge and hairy, with big, weepy eyes - in fact, he looks a lot like the Muppet who helps to sell used cars in "The Muppet Movie". (Thanks to Wikipedia, I've now discovered that this Muppet is called "Sweetums" - more about Sweetums here!)

This was how the interview went. (I'm not sure exactly what the interviewer looked like, but let's assume he looked a bit like Kerry O'Brien.) There has been some post-production editing, but the basic insights were there at the start.

Interviewer: Why do you make Luke so sad?
Sadness Troll: I have to keep reminding him that he needs to be successful! So yes, he gets sad when he doesn't measure up, but he needs reminding!
Int: Why does he need to be successful?
ST: Hmmm ... not sure. Because a lot of his identity has been bound up with that ever since school? Because people expect it of him?
Int: Could he try being different instead? "Dropping out" in some metaphorical sense? Become a "virtual" hippy or pilgrim? You know, he's got the hair to be a hippy ... What about "be the change you want to see"? How about if he tried to be compassionate instead?
ST: Hmmm ... I'll have to think about that, but it might work.
(Sadness Troll wanders off, looking less depressed for the first time in a long time.)

Another part of the interview that got cut from the program was this:

ST: We need to see results, or we'll never know if he's getting anywhere!
Int: Isn't that negative reinforcement? Don't you remember that exercise that Luke did where he listed all the positive motivational techniques that worked for him?
ST: ... oh yeah. That's right. How about that.

Besides Havi, it looks to me like the interviewer also drew on Personal Alignment from the Core Protocols - identifying a goal, working out what's blocking you, what you'd need to overcome that block, and repeating as necessary. Finally, the exercise that I've done previously to list postive motivational techniques came from Barbara Sher's "Live the life you love And Stop Just Getting By". For the record, at the top of the list were:

spirituality and praying; competition (including against myself); receiving praise; getting help from friends; starting small; deadlines (if well-defined and realistic).

I gave these an A for how well they work for me; shaming got a D, and scolding, built and lecturing got an F.

So maybe there are some techniques that the Sadness Troll could pick up ...

Ighalsk - in which I discover StringIO

The suite of unit (more or less) tests that I run for Ighalsk currently takes about 11 seconds to run 281 tests (for the current version with Subversion revision number 58). This is not too bad, but I've read about projects running more than 1000 tests in less than 10 seconds, perhaps even less than 1 second. In particular, the suggestion is to avoid file accesses in unit tests (see for example Michael Feathers here).

When using Java, I think the idea is to accept an abstract Reader object as a parameter, which can be a FileReader object in the actual program, and can be mocked as a StringReader (or is it ByteArrayInputStream? so many choices!) in test code for speed. (On checking, I found that the example I was thinking of is actually for .NET ...)

I was planning to implement my own FileReader and StringReader objects in Python, but then I'd have to unit test those as well ... when, reading through the Python manual, I discovered a class called StringIO!

Its description begins, "This module implements a file-like class, StringIO, that reads and writes a string buffer (also known as memory files). See the description of file objects for operations ..." - which is exactly what I wanted!

I've started using this approach (mocking file objects using StringIO) in new classes, but I still need to switch to it for existing classes. In most cases, it should be a matter of opening a file and passing in the file object before calling a function instead of passing in a filename and opening the file inside the function, though this still means that there'll be at least one class somewhere that will still have to open some files ... but separating out this functionality should mean that file I/O only needs to happen in a small number of unit tests. Yet another treasure hidden away in the depths of the standard Python libraries!

Tuesday, June 23, 2009

Ighalsk - Adding a List of Buttons

Disclaimer: All code discussed in this post is covered by the GPL. It can be browsed through this link (to the latest release).

About a month ago, I decided to move away from a strict interpretation of "roguelike" for Ighalsk, and add a window with buttons that can be pressed to carry out actions. A friend had pointed out that it was hard to remember which keys did what - something which I've found true for many of the roguelikes that I've played over the years. I'll say a bit about my solution, but first some background.

In Ighalsk, I've taken a perhaps overly literal interpretation of the "Model-View-Controller" pattern. The source code is organised into directories called "Model", "View" and "Controller" (there's also a "Common" directory for classes used by both Model and Controller classes). For each screen of Ighalsk (each state of the controller), there are corresponding View and Controller classes. For example, there are ShopViewer and ShopController classes which handle viewing items on display in a shop and buying an item. (There's also a Shop class, in the "Model" directory, which holds item names and prices and can return an item if it is bought.)

Which View class is active (displaying text on the screen) at any given time is handled by a high-level class called IghalskViewer; similarly, which Controller class is called is handled by IghalskController.

Back to my recent changes. Stating the obvious, I called the class implementing the window with the buttons "ListOfButtons". All it really does is display a list of labeled buttons, and call methods when the buttons are pressed; but what the buttons say and do changes as the controller state changes throughout the game.

Each Controller class now has a "getEvents" method which returns a list of strings. The ListOfButtons class takes this list and adds a button to its window for each string. Each button is configured so that when it is pressed, the "sendEvent" method of the currently active Controller will be called, with that string as a parameter to the method.

(Rather than add the full functionality to each Controller class at once, in a huge, big-bang mountain of coding, I did it step by step. I started by creating an AbstractController class and made each Controller class a subclass of it: the AbstractController has a default getEvents method which returns an empty list, and a sendEvent method which does nothing. Thus at this stage, there was a window for the list of buttons, but there were no buttons on it. I then filled in the details of getEvents and sendEvent one class at a time, so that gradually more and more of them supported the list of buttons, and the list of buttons was populated more and more often while playing the game. As I went, I added a unit test for the class I was modifying.)

Each Controller also needs to respond to keys being pressed, by implementing a "processKey" method. This method now calls "sendEvent" with an appropriate event description. (This is to reduce duplication, following the "Don't repeat yourself" principle - see the Ighalsk Coding Guidelines.)

The game should be able to change screens (display a different view of the character, their possessions, or the world around them) as requested by the player, either through pressing a key or clicking on a button. In the source code I've called this "changing the state" of the controller and the view, and it happens through calling the "changeState" method of IghalskController. (I'm of the view that it's impossible to be too obvious with names.) This is done through a call-back type thing.

So there's a connection between events and states, in that for some events (buttons), the game (controller) should change to a different state. There's also a connection between keys and events, in that pressing a key is equivalent to sending a particular event.

Again exercising my gift for stating the obvious, I wrote a class called "KeyEventStateDict" to hold these connections, available to all controller classes. It's initialised with a list of tuples [(key, event, state)] and stores these internally. It then provides a "getEvent" method which is passed a key, and a "getState" method which is passed an event. It also provides a "getEvents" method, which returns a list of events in the same order as the initial list of tuples. (Internally it holds two dicts, hence the "Dict" suffix to its name.)

These methods abstract away a lot of the code needed to handle both pressing keys and clicking on buttons. But not all of it: several of the controller classes still need some code to handle special cases - to take actions, move, change what the character is wearing and so on. Otherwise, all the player would be able to do would be to change from one screen to another.

Adding a list of buttons to each state (screen) was not only adding a useful piece of functionality; it also gave me the chance to simplify the controller classes and to add unit tests for each, thus setting up infrastructure to make refactoring easier in future.

This was the biggest change between release 0.1.3 and 0.1.4. Next will come a Palace holding a Queen who asks our Hero to perform Quests ...

Thursday, May 28, 2009

Ighalsk - Invisibility and Awesomeness

I've just discovered "Fluent Self", an amazing and inspirational blog. Some of the posts got me thinking about my approach to Ighalsk, including "Visibility. Invisibility. Power. More pirates."

I was happy to be developing Ighalsk on my laptop for a long time, keeping an archive (using CVS archive) but not exposing it to the outside world or talking about it to other people (OK, maybe I mentioned it in broad terms to 2 friends and my wife). So I was running in stealth mode, lights off, invisible - which meant that no-one could criticise my work, *but* no-one could comment on it or praise it either. And acknowledgement and respect are big motivators for me. I'd always intended making Ighalsk open-source, it was just a question of when.

Even after releasing it (and I'm up to release 0.1.3 now), I've been keeping a lot of my plans under wraps for fear of Ighalsk being labelled "vapourware". *But* that always means that others can't know how awesome it's going to be, *and* can't help me make it more awesome. So here goes.

I'd always planned (well, since a couple weeks after deciding to write a roguelike), to have special levels throughout the dungeon. Each with its own name, theme, coherent selection of monsters, carefully designed layout presenting tactical challenges and opportunities, and of course a unique monster to defeat. The list I came up with early on was:
  • tunnels of lost dreams (dwelling place of Lord Apathy);
  • spider caves;
  • ogre halls;
  • necropolis;
  • caverns of night;
  • pits of chaos;
  • corrupted temple; and
  • imperial palace.

The original plan was to have these at every 5th level, but I recently changed my mind. Now I plan to have a series of dungeons which can be entered separately, with a hand-crafted level, including the chosen unique, at the bottom of each dungeon. Each dungeon will be a quest, described by the young queen in a royal audience.

Similarly the plan was to have increasing difficulty as the Hero descended, but now I'm thinking I'd like to mix monsters of all difficulties, presenting a different set of tactical and strategic challenges.

The Hero will start out tougher and more powerful, though my plan has always (almost always) been to have plenty of options (powers) available from the start, with quite different mixes for each type of Hero. This is something else that will change: instead of choosing their Hero's "Profession", a player will choose their "Primary Gift". "Warrior" will be replaced with "Mighty", "Priest" with "Blessed", and "Scholar" with "Philosophical".

Finally, something that I've also planned to do for a long time but have been thinking about again recently is Food that gives a small, short-duration bonus when eaten. What I have so far is Bread (or Potatoes) to restore Hit Points, some sort of vegetable (maybe Cauliflower or Cabbage) to restore Power Points, Spinach to temporarily boost Physical Strength, Fish for Mental Strength, and Wine for Spiritual. Then there's Beef and Chicken, which may well decrease and increase susceptibility to Fear.

Tuesday, May 12, 2009

Ighalsk - release 0.1.3 and plans for the future

After losing maybe a month to playing Dwarf Fortress, I'm picking up speed on Ighalsk again. I've just released v0.1.3 (minor changes from v0.1.2). The plan is to take development in a new direction: first adding another window with buttons for all the commands that are currently available (rather than having to remember everything), and then radically revamping the dungeon system and the character concept ...

For my own reference, here's the steps that I follow when making a release of Ighalsk:
1) svn copy from trunk to tags/release_x_y_z. (I'm skipping the URL, which really is not that edifying.)
2) svn export tags/release_x_y_z
3) Zip up this exported directory and rename as "" (to conform with Sourceforge's naming convention).
4) Upload the zip file to Sourceforge's file upload area.
5) Create a new release, add changelog and release notes, check the box next to the zip file, and done!

Tuesday, April 21, 2009

My Favourite Core Protocols

I already mentioned the Core Protocols in my first post on this blog. But maybe I need to say more about just how powerful and effective - let's admit it, how cool - they are. Here are my four favourite protocols, in some kind of order. (For reference, there's a link on this page to V3 of the Core Protocols, in PDF form.)

A word of explanation: yes, they're called protocols. But don't think of them like a Japanese tea ceremony. Colleagues of mine have commented that they're like Robert's Rules of Order, which is closer to the truth, but they're much more succinct and general. Think of them more as tools to use if you want greater productivity, more effective teamwork, and maybe even a fuller and richer life.

This really works. Making decisions in a team can be quick, easy and effective. This protocol allows anyone to cut through endless debates and get to the meat of the matter. It can be used to speed up meetings, or even achieve a consensus on whatever you want: a protocol, an approach, a goal, a vision. Though the consensus might not match the idea you were thinking of at the start, it is possible to converge on an idea that everyone can support.

Check In
The Check In protocol is all about expressing your own emotions, and allowing - even encouraging this - in a team context. It's valuable for building trust in a team, but a Check In is most valuable for the person expressing their emotions: having to articulate how you feel is key to being in touch with yourself.

This protocol also ties in with two different books that I've been reading lately. One is called "Assertiveness: Step by Step" by Dr Windy Dryden and Daniel Constantinou. It defines assertion as "the flexible pursuit of having our preferences met, our opinions voiced, our emotions and beliefs honestly communicated in an appropriate way at the relevant time". Honestly communicating beliefs is what Check In is all about.

The other is "Peoplemaking" by Virginia Satir. This is an older book - it may be out of print now; I bought it second-hand through Abebooks. Virginia Satir was a family therapist, but I heard about her through reading what software developers and managers were writing, in particular those associated with the AYE conference. She claimed that when one is feeling threatened, one can react in five different ways: by blaming, placating, computing, distracting or leveling. Of these, leveling - matching one's words to one's feelings and one's expressions and body language - is the only healthy response in the long-term. And this is what Checking In is all about. So this protocol is connecting with a whole lot of things for me and making a lot of sense.

Ask For Help
I've been amazed at the quality of the answers and help that I've got from using this protocol. Yes, people have sometimes said no, but that's fine, that's part of the protocol.

There's two things in particular that I appreciate about this protocol.

Firstly, it removes the shame from asking for help - something that I have had trouble with in the past. Asking For Help (using the protocol) is emphasized in the Core Protocols and supporting material (including the book Software For Your Head) as the best way for the team to achieve its goals. In fact, it's made clear that you can't Ask For Help enough.

Secondly, part of the protocol is that you should only provide help when you're asked. Providing help when you're not asked is dubbed a Rescue (one of the team Anti-Patterns). This leads to less unwanted advice and (as I'm slowly coming to understand) less chance of overpoliteness and oversensitivity (two faults that I'm prone to).

Personal Alignment
It may seem a strange tool to use when trying to achieve better teamwork, but the Personal Alignment protocol is all about achieving your own individual goals. The protocol is all about listing these goals, putting them on record, then working out what would help you most to achieve those goals. Other team members are encouraged to help in the process. I'd identified long-term goals for myself years ago - helping others, making a significant difference in the world - but using this protocol with others' help has really helped me understand myself that much better. I'd set up obstacles for myself that I hadn't fully realised; naming them and bringing them into the light has shrunk them in my mind.

For the record, building Ighalsk into a game that people want to play and enjoy playing, and building a community around Ighalsk are two of my short to medium-term goals; and wisdom is what I most need to help achieve that goal. This includes, but is not limited to, the wisdom to understand what people are looking for, and where people are. And wisdom is something that I'm still seeking - I'm very aware that I still need much more wisdom!

EDITED: 3 typos corrected - thanks Harold!

EDITED AGAIN (2nd August 02009): As pointed out in comments, the link in the last sentence of the first paragraph is broken. Here is where you can download v3.02 of the Core Protocols.

Ighalsk - Coding Guidelines

Here are the coding guidelines that I'm endeavouring to follow for Ighalsk. They're guidelines at this stage, not rules.
  1. Everything can be changed.
  2. Creating, extending and sharing is good and should be as easy as possible.
  3. All tests should pass.
  4. Names should be meaningful.
  5. Comments should express intent.
  6. Don't repeat yourself.
  7. Do the simplest thing possible.
To expand on these somewhat:
1. Can also be thought of as, "everything can be refactored". If a module can be rewritten to make it cleaner, simpler or more readable, it should.
2. An open-source principle, but it should also apply to objects in the game: monsters, items, powers, special levels and professions.
3. Irrelevant and/or obsolete tests can be removed.
6. From Pragmatic Programming - Extreme Programming calls this the "Once and Only Once" principle.
7. An Extreme Programming principle.

Sunday, March 15, 2009


This blog is dedicated to discussing the development of the open-source roguelike game Ighalsk, and using it for examples for exploring topics like object-oriented programming, patterns including Model-View-Controller, refactoring and test-driven development.

I may also discuss other topics such as Agile software development or the Core Protocols; I'm part of the team that's developing version 4.0 of the Core Protocols.

This blog will be more focussed than my last blog, Assemblany; that blog was nominally about democraticising companies, but I feel that my strongest posts were on forgiveness even for software developers and my favourite charities.

So once again, welcome. Have a seat - here, this couch is more comfortable. Can I get you a drink? Coffee? Tea? Hot chocolate?