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.

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 "ighalsk-x-y-z-src.zip" (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!

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.

Decider
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.

Welcome.

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?