Teemu is ready, only some minor details missing like level descriptions and maybe some game world interactions with new terrain tiles. I have an odd feeling now, because this will be my first game released in a long time and for a moment I was worrying how people will react to it when they may have certain expectations. Well, I can only blame myself for being such an ass with all that stuff about Kaduria and how it will become the next gen roguelike surpassing every major roguelike.

1047. Let's see... materials for extracting/milk jobs (not that you can milk large creatures yet, but it'll be waiting nicely for that when I get there now), some cleaning of the poisoning code and the addition of materials to the injection special attack, so the material for venoms can now be specified properly (which is required for any future poison effects), and also the item use properties for each material when it comes to making armor/clothing/instruments/toys (that is, as clothing in the currently-released version seeks "soft" or "scaled" or "leather", etc. materials, which categories the material actually fits in can now be specified explicitly... it should probably figure some of this out from the basic material properties, but this was faster for now while still accomplishing the goal of getting all of the item-material considerations under the same umbrella).

It's been about a month since I last mentioned it, so the breakdown again is: 8 left of what I'm doing now, 250 worth of wounds and health care concerns, 29 on descriptions and some skill/att stuff, 65 on venom, 165 for map features, 260 for entity positions, 195 for squads, and 75 for random crap and tests. The squad and entity changes run together a bit as they both involve the military.

There were two bugs in load game. First one was easy, I copy-pasted npc restoring code and there was old value from item restore loop so it tried to restore too many monsters. The second bug was a bit harder, but found when inspecting the load buffer size. I forgot to clear the std::string where data was stored before loading next piece of data, so the new data was added to the old string.

Load game seems to work now and I can concentrate on pathfinding routine.

Bake it, shaby.

1048. Color variations and changes over time are done (for any tissue layer, from skin or muscle to the stomach to eyebrows or claws), and I've defined a new colored pattern definition for things like stripes and mottled patterns that can have more than one color at a time. So you could have your borgle's borgle fade from either their starting blue or starting red into a purple and green striped pattern gradually as they age, or something. Appearance modifier change rates are also done, so unit hair/nails can grow, or you could have your borgle's borgle grow thicker from age 10 years to age 15 years (it still can't be borgly to any degree). It only supports one start/end time at this point for growth rates, but today's changes are enough to go from having no facial hair for a human male at birth to having a beard start to grow after some years to having the beard gray slowly after a certain age is reached (with the color change being defined as a change at the root of more and more hairs rather than a fading of the color all around, as you might want for some other color changes). The length/color changes will matter for the descriptive paragraphs (which are up roughly after wounds in the countdown), and there can be all sorts of applications later on, from cultural entity rules to wrestling effects.

Now we are at the last 9 elements of the slow patch, which is really just a pile of small changes that were originally in 9 categories but have become something more loose than that. I'll decrease the countdown as I clear the list in ninths, rather than instituting a sub-countdown of 556 which is a larger looking number. These 9 shouldn't decrease any slower than it has been, nor any faster.

I've put the problems mentioned in the previous two posts in rest for a while. I have many ideas how to overcome them, but haven't had the motivation to start actually implementing (fortunately the thing is not fatal). Instead, I've added two new view layers to the engine. First one is an intermediate between solar systems and planets, so called orbital view level. This will allow more control over the descending point and also gives players better idea about the size of the planets. It is not yet completed, but the hard part - modifying the engine - is over and it doesn't break the program. The other new view level is an auxiliary view level used for stuff like caves or space stations that doesn't have their own one. As I don't have any such places yet, it is more like a dummy implementation. I also tuned the interface a bit and although far from complete, I am starting to have visions about it. Well, that's all for now, hopefully I'll get back to you soon :)

Recently I made some types of messages:

1.Hero's message
ex. 'You drink potion of heal', 'You increase your Combat skill'

2.Visual message
ex. 'The rat bites the dog', 'The kobold throws an explosive ball against you'

3.Sound message (if visual is false)
ex. 'A dog is screaming in pain', 'You hear an explosion to the south'

4.Speech message
ex. 'The merchant says "Hello traveler!"', 'Someone whispers "over here" in the darkness'

1050. Today was doing ASCII chars and display colors for castes vs. creatures, handling baby/child strings, going through all the old creature flag occurrences and either updating them or sorting them into their proper category of the remaining countdown elements, handling allocation of bodypart-related tissue layers like eyebrows, and implementing tissue-layer-based appearance modifiers (so variations can be given to critters' hair). I think I'm going to finish up layer growth (eg hair growth) and color realizations tomorrow and whatever else I can manage.

I'm testing the save and load game routines. Loading doesn't work, which wasn't that much of a surprise. It's giving me out of bounds error with std::string. It seems that I have to use a debugger for this one, which I rarely have to do, because usually I'm writing bug free code. I'd like to know more about Visual C++'s debugger, because I'm not that familiar with it. It seems to stop when player's data is loaded, but the traceback information shows that it's breaking in Level's load routine. Go figure, but stepping through the code should clear the confusion when it's actually crashing.

I already programmed today more than two hours so I think I'm going to do something else like home page for the game, so it's already there when the game is ready.

My evil lair is under construction.

Save game routines are now ready. I'm taking this carefully, because I want to have bug free save and load routines. I'm constantly checking with hex editor that the save file contains proper data. I also wrote new packer routine for maps that are saved to reduce the amount of space they take in the save file. Loading is going to be more difficult, but I'm sure it will work fine without big problems.

The pathfinding problem is annoying, because I know from experience that I'm going to spend a lot of time to create it. There are also some bugs in throw routine, which has been difficult in Kaduria as well.

1052. Finished off the "still a bit to do with that" from November 19th, meaning I finished off various work with the new reaction raws. This slow patch of the countdown has 13 elements left.

December has arrived, and with it come the final exams. This year I’m working on a very special gift: by  the 25th I pledge to release a completable version of GearHead2. For the next two weeks my schedule will be pretty light so I should be able to get the last three episodes and the [...]

During the last days, I put lots of time in LambdaRogue development, which is strange, because I hav...

It's a day to get excited about a remake.

(You'll probably want to read parts one, two, three, four, five, six, seven, eight, nine, ten, eleven, twelve, thirteen and fourteen first).

The school spell lists as I designed them in part fourteen are intended to be a mix of banding tradition as well as an attempt to find new ways of making magic in Unangband interesting. I've been inspired here, as much elsewhere, by the design work in Sangband and elsewhere by Leon Marrick and although aided by many, this particular series of articles is dedicated to him and the insight and inspiration he has given me and many others.

Angband is a game of resources: and each magic school has a different way of handling the resources of light, food, escape, healing, mana (spell points) and item identification which help define them. Wizards have no reliable source of food at all, and no high level healing, but can readily concentrate mana to recover it and have the most flexible range of escape spells, and both the ability to light rooms as well as to use light as an attack, and to replace their fuel based light source with a magical spell which can be indefinitely powered provided that sufficient mana is available (and that the wizard is not plunged into darkness by letting this spell run out - spells require light to be read from their respective spellbooks). The Unangband Wizard has the ability to take advantage of magical items such as wands and staffs: both with a spell (gauge magic) which readily identifies the number of charges that the item has, and a recharge magic spell to replenish these charges as they are used.

I attempted to balance the flexibility and power of the wizard escape spells by limiting them significantly for the other magical schools. Druids can only teleport to and from water or natural areas (defined as being adjacent to plants), masters only to and from darkness, thaumaturgists require a nearby source of fire, and sorcerors can only teleport temporarily, returning to the location that they teleported from after a moderate amount of time passes. This was done to allow other escape spells, such as temporary hasting, and spells which shape and change nearby terrain, such as wizard lock and warp wood, to be preferred by these classes in various ways. However, the escape spells are much less flexible, perhaps too inflexible, to be reliably used, and since escape is of critical importance to magic using classes it may mean that the wizard ends up being the preferred class choice for Unangband players.

Druids are encouraged to manipulate their surroundings and many druid spells have been made synergistic with each other: while they can only teleport near nature, they can create trees to bring nature to them in the first place, and then these trees can be used to tangleroot opponents or recover health using the tree of life spell; similarly the mana pool spell draws mana from nearby sources of water. Once opponents are entangled, it becomes much easier to affect them with slow building natural attack spells which are their forte (a yet to be implemented forte at the moment unfortunately), and the ground can be further prepared by shaping the rock by turning it to mud. Food for a druid is trivially satiated with a single spell, light is randomly scattered around them as opposed to lighting up whole rooms (which encourages more preparation to 'fill the gaps'), and item identification through a useful but obscure system of runes which hint at a particular items function.

Masters summon monsters, and while the friendly monster AI is powerful and flexible enough for monstrous combat between the master's allies and enemies, I need to give the master more granular control for when they summon multiple differing types of monsters. To encourage the master to have more investment in their minions, I've added a Find Familiar spell, which summons a unique creature that the Master can tailor over the course of their career - but if this creature dies, it is lost forever.

One thing I've enjoyed doing with various master spells is monster design: in particular the Animate Dead spell requires I come up with undead versions of various body parts and creature types. I'll say more about hacks shortly, but I've implemented this as a blend of hacks of various kinds, instead of a 'purer' convert a monster to undead function. The sorceror's Animate Object has been similarly entertaining.

Masters relish darkness instead of light, attacking with it in various ways, teleporting to and from it, and consequently have a temporary infravision spell which allows them to detect warm blooded monsters in the darkness - I should also add a Night Sight spell which provides further visual acuity at a higher level. High level healing is acquired by draining the life from living enemies (or allies), which simultaneously feeds the Master, and mana can be acquired by sacrificing hit points in return - since Masters need mana to pay off summoning debt, it could be overpowered letting this be more readily recovered. Item identification provides a general hint as to whether an item is beneficial, and what approximate effect it has.

Sorcerors are a mix of traps, charm spells, mental attacks and shape-changing: charms being more effective than the master's abilities in summoning, and shape-changing very much a work in progress. I've probably gone overboard in terms of making shape shifting unfriendly for the player to use as it forces them to discard equipment in various inventory slots. I suspect I'll move back to the Oangband/Sangband style solution of making shape-shifting just affect player attributes. Sorcerors are almost as flexible as wizards in the ways they can escape, perhaps more so, but lack a pure 'get away and stay away' single turn spell. They are superior to other classes in their item identification magics, and instead a source of sustenance, they can readily slow their metabolism to prolong the effects of food they have consumed. Sorcerors lack any ready source of light, healing or mana however, so will be forced to scrounge for other methods of illuminating the dungeon and recovering from wounds and spellcasting.

Finally thaumaturgists are attack, attack, attack, with a mainline in randomly assigned elemental types (to be implemented) and a sideline in acid and fire magics. They can usefully renew their torch flame to allow unlimited light and step into flames to teleport and escape but otherwise lack any utility spells.

After spending fifteen parts discussing various design decisions to try to come up with a consistent and systematic method, I've yet to find a solution. In particular, my answers are variations on two themes. The first is a refutation of the argument I made in part one, that 'As a game designer, [...] flavour is all important, but ultimately distracting'. Designing classes is almost all about flavour and style: do these abilities fit a consistent theme, do they complement each other, and so on? We can take on principles of good design, and the importance of the language and grammar of design will be increasingly a requirement as our games continue to increase in complexity. But ultimately, we want to present the player with interesting choices, a set of hills or valleys in the possibility space of the game, and to avoid overwhelming the player with too much choice, we have to highlight certain highs and lows, while ignoring others.

The second theme is the importance of ensuring the importance of exceptions. As a programmer, your intuition is ultimately to try to re-use your code where ever possible. But as a game designer, of the magic systems, you want to ensure that each ability uses at least some unique code path. That is, each ability in your game must in some way be a hack. It can be a small hack (fire burns, cold freezes) or a large hack (the recent implementation of a Find Familiar spell required a complete monster progression system to be interesting), but it should ensure that each ability is different, and therefore affects the game play in some unique way. Extend the ability idea as far as you can (cold freezes water, allowing you to cross rivers and block swimming monsters from attacking you) and then push yourself a little to see where it takes you. Don't obsess with trying to make the code clean and regular: its the abilities that the player has that keep them empowered and playing, and suspension of disbelief should trump any reduction in code complexity.

Normally I finish these design articles with a set of principles, but here I only have practise. It has taken me close to 7 months to list these practises and there are many more devils in the detail that only a close inspection of the code and asking me questions will do justice to (and please, ask me on the blog rather than via email so that the questions and answers are shared for all). I'm not throwing my hands up in the air: but this type of design requires iteration and playing, and decisions, and your decisions will not be the same as mine.