One's Place in the World

It's hard to remember, given the way Angband is thriving at the moment, that a few years ago it was apparently about to die. The fact that it didn't was due to a desire within the community to keep it alive, and from that Andi Sidwell emerged as maintainer. Right from the beginning he had the intent to make Angband development more of a community effort - to steal an analogy, to move from the temple to the bazaar.

As a variant maintainer, I have been very much in favour of this movement. I have at times been very vocal in my views that various features need to be incorporated. And my loud-mouthedness on this issue has got me a place on the dev team, albeit a kind of special guest roaming correspondent place. Which leads me to the point.

I have promoted the whole AngbandBase thing, and my aim in V development has been to include all the features in FAangband that I don't want to lose on moving FA onto AngbandBase. Which is all very well, but with power comes responsibility. And I've now included features which are turning up bugs, and I'm in a "playing, not developing" phase and so the burden of fixing them is falling on the real dev team members.

So I guess this is really just a wordy apology, and thanks to takkaria, Magnate and d_m and others for a fine job. Although it's kind of a cheap trick to make a public apology that no-one will ever read...

Well, duh

After spending considerable time trying to work out how to manage keeping AngbandBase up to date, and how to make it an integral part of Vanilla, it turns out there is a simple solution. I simply had to make a branch of the official V repository called AngbandBase. Now keeping it up to date is as simple as 'git merge official/master', unless names change or new files come in.

And I suspect (but haven't checked) that incorporating it into a variant is about as easy - make the V repository a remote, and then merge the AngbandBase branch into the variant's master. All with the magic of git.

PS Well, not quite as magic as I'd hoped. Every Vanilla file deleted in AngbandBase causes a conflict in the merge; they then have to be forcibly removed and everyone's happy again. Is there a simpler way to do that?

FAangband at github

A bit over a year ago, for various reasons (including the fact that I predominantly used Ubuntu at the time) I made a repository for FAangband at Launchpad.

A couple of months ago Vanilla moved to github. Having been involved now in V development there, I've become very used to git - more so than I ever really did to bazaar. So I have now put FA on github. I have done this by making my master copy both a bzr and a git repository. Currently, I plan to do most of my day-to-day work with git, then push changes to both github and launchpad. Bugs can be reported in either place; I may one day use the wiki feature on github; and I will continue to do forward planning through launchpad.

We'll see how it all works out.

Extended Characters

V fork now has extended character support - a windows build is here. My next task is to extend the standard V font set to include extended characters (and probably, while I'm at it, NPP-style door etc. glyphs).

Which files for AngbandBase?

Here is the current list of Vanilla files, and how they relate to AngbandBase.

AngbandBase

button.c
debug.c
debug.h
game-event.c
game-event.h
gtk/*
h-basic.h
HEADER
main.c
main-crb.c
main-gcu.c
main.h
main-nds.c
main-ros.c
main-sdl.c
main-win.c
main-x11.c
main-xxx.c
Makefile
Makefile.inc
Makefile.nds
Makefile.nmake
Makefile.osx
Makefile.ros
Makefile.std
Makefile.win
prefs.c
signals.c
snd-sdl.c
textui.h
ui.c
ui-event.h
ui.h
ui-menu.c
ui-menu.h
util.c
z-bitflag.c
z-bitflag.h
z-file.c
z-file.h
z-form.c
z-form.h
z-msg.c
z-msg.h
z-quark.c
z-quark.h
z-rand.c
z-rand.h
z-term.c
z-term.h
z-type.c
z-type.h
z-util.c
z-util.h
z-virt.c
z-virt.h

Should be copied from V with names changes where necessary

Makefile.src
nds/*
osx/*
win/*


Potentially useful as templates for variants

angband.h
birth.c
cave.c
cmd0.c
cmd-know.c
death.c
doc/*
game-cmd.c
game-cmd.h
history.c
init1.c
init2.c
init.h
pathfind.c
randname.c
score.c
squelch.c
target.c
ui-birth.c
ui-birth.h
xtra2.c


Definitely not AngbandBase

angband.ico
angband.man
attack.c
cmd1.c
cmd2.c
cmd3.c
cmd4.c
cmd5.c
cmd-obj.c
cmds.h
config.h
debug.c
debug.h
defines.h
dungeon.c
effects.c
effects.h
externs.h
files.c
generate.c
list-blow-effects.h
list-blow-methods.h
list-effects.h
list-mon-flags.h
list-mon-spells.h
list-object-flags.h
list-player-flags.h
load.c
load-old.c
monster/*
object/*
option.c
option.h
player/*
save.c
savefile.c
savefile.h
spells1.c
spells2.c
store.c
store.h
tables.c
tests/*
trap.c
types.h
variable.c
wizard.c
wizard.h
wiz-spoil.c
wiz-stats.c
x-spell.c
xtra3.c


In other news, today has been updating my angband fork with takkaria's latest changes, and doing a (hackish) SDL frontend version of UnAngband.

An Original Idea

Maybe I can use this blog to talk about what I've been doing.

Today, I finished adding Unandrew's double and triple tile support to my fork of Angband. The idea is that eventually I will have added all the natty UI stuff that I can think of that variants have and V doesn't, and can then use bits of the fork as AngbandBase.

This may also involve some moving around of Vanilla code, so I'm kind of hoping that this will fit in with takkaria and all the other stuff that's happening with V at the moment.

Mmmm, linkalicious.

Why do we do this?

I guess every Angband variant maintainer has their own reasons for making a variant. In my case, one of the chief things that attracted me to Angband in the first place was a deep and lifelong love of the entire Tolkien Middle-earth mythology. Given that, the main theme that I pursued - immersion in Middle-earth - was an easy choice. So I made my variant.

The thing I was unprepared for was the interaction with players. I already knew that Angband had a vibrant, interesting community; but the thing that has kept me maintaining is that other people have actually enjoyed the thing I do for my own enjoyment.

Two things stand out for me. One is the long developing collaboration I have had with Si Griffin - starting with the Windows CE port of FA, and including a release (v0.3.6) by Si rather than me.

The second one, which needs no further comment, is this.

The Curse of Posband

Posband is/was a wonderful variant, branched off NPPAngband by Alex Ulyanov. After much fruitful work, he declared it orphaned, and more or less left the *banding community. Then it was taken over by Graham Phillips and Avenger, who made a home page and now aren't around much. Rick Frankum (now vanished) did some work on artifact reward generation. And here is the latest - last seen on the forums about two months after starting this thread.

So this is the first step (no actual work done) in adapting Pos to AngbandBase.

It was nice knowing you all.

AngbandBase

So, the Angband Variant Project has taken a bit more shape, with a code repository (edit 5/12/10: now moved here). Anyone interested is welcome to help; just get a github account, and I'll add you as a collaborator.

The idea in brief is to have the code for file-handling, display, UI etc separated out from the code for the game proper (where game can mean Vanilla or a variant). AngbandBase should contain all the code that there would be no reason for a variant maintainer not to want.

As I see it, the two big advantages are easier UI maintenance, and portability to more platforms for everyone; the main disadvantage is just getting it organised and keeping it organised.

There are some tricky issues at the boundaries of what to include and what to exclude (targeting, pathfinding and menus among them).

Some day, I may actually do some work on it instead of talking about it and pasting stuff from the forum into my blog.

Mortality

I've thought a lot about this, and I can't say I'm a fan.

Angband Variant Project

A couple of years ago I made an unofficial UI update of Oangband 1.1.0. I have been vaguely planning for a while to do a similar thing for Posband, but it would be more work and I haven't got around to it yet. One of the main reasons against doing this is the issue of now keeping Oangband 110u up to date; every time I fix a UI bug or add a feature to FA, there's pressure (from me, if no-one else) to do the same thing for O110u.

A few years earlier Christer Nyfalt wrote Anglib, a C++ library to do the low-level Angband code, intended for use as a base to build variants on. A couple of variants were basically ported to it, but it never really caught on.

A few years earlier still, Tim Baker had written Omniband, which was a very impressive Tk interface to Angband, Oangband, Zangband and Kamband.

So first there was Angband. Then it was rewritten so that it was easy to write variants, and people did. And variant maintainers, and the Angband maintainer, are constantly borrowing ideas and code from each other. And every now and then, someone will collect some of the features of variants back together. And that's all good.

Some other relevant developments include the involvement of multiple developers in Angband under takkaria's maintainership; and the increasingly continuous development cycle, where many people are playing with the latest code instead of playing the same version for months or years until the next version is released.

I guess I would like to see a less ambitious version of Anglib - a shared low-level/UI codebase, with multiple variants (as FA and O now) having their own code built on top of it. This raises questions:

1. What would the relationship to Vanilla be?
2. How best to package and distribute?
3. What variants?
4. Who would contribute?
5. How do you manage it all?

Answers and opinions welcome.

Death. Again.

So, another Oangband Shadow Fairy Necromancer bites the dust. As so often, it was just stupidity that killed this one. I was trying to dispel a red dragon pit for the experience and treasure, and let too many of them get too close, and didn't bail out in time, and surely one more breath won't kill me...

Here's the washup. Note the -4HP.

For the most successful bits of the whole epic saga, see here.

Twitter

The problem with twitter is you can't say anything meaningful in 140 characters.

Angband on iOS and Android

I've been thinking about how to play Angband on handhelds recently, with particular reference to Android (which has come up on the Angband forums recently) and the iPhone/iPad (which are apparently conquering the world).

The two handheld ports I'm most familiar with are for Windows CE and the Nintendo DS. In both those cases, there is a touch interface designed for using a stylus with, which gives relatively fine control. Adapting the Angband UI to deal with that was a lot of work, but reasonably successful; although it should be said that fitting all the relevant info (even just map info) on a small screen is challenging.

For the new class of handhelds, though, the touch interface is finger based and much coarser. This presents a whole new set of problems; I think, though, that these are solvable.

For movement and looking at the map, the critical feature that I think will be necessary is a proper zoom. Luckily this is one of the primary features on iOS and Android. Pinch inward to zoom in and get a close look at what's about you, pinch outward to zoom out and make sure you don't get breathed on from a distance. Tap on a corner or edge to move, double tap to run. Flicking will scroll the map. Targeting will require care, but should be feasible.

The big question, though, is how to deal with the many non-movement commands that are required in Angband. Classically, these were just each given different keys - 'q' for quaff, then give the inventory letter label of the potion to quaff, for example. Even in this setting, though, the player needs to either bring up the inventory list to find the potion or have a subwindow containing the inventory. In the Windows CE port, the order was reversed - choose an inventory object, then decide what to do with it (noun-verb rather than verb-noun).

So, how to do it for iOS/Android? Subwindows are clearly not possible where there's limited screen space. Well, there's another ingredient from the WinCE and NDS ports that can be used here - buttons. Buttons can be standard (escape and repeat are two obvious ones to always have), user-configurable (playing the role of macros and keymaps) or context-sensitive (downstairs button appears if you're on the stairs). They could be always present as an overlay, or brought up as a gesture.

So this is almost a plan. Now all that's needed is someone to actually make it...

IDEs - is it just me?

I've just been playing Vanilla in OSX, and the lack of block walls annoys me. Several months ago I bought a Mac, partly so I would be able to do OSX stuff for FAangband - stuff like fixing it so I could use block walls. But I haven't. Because I'm still doing all my coding in an Ubuntu VM, using emacs and grep, and gdb when I absolutely have to.

Apparently OSX has a wonderful IDE called XCode, but every time I open it I think "Now I have to learn how to use this" and shut it again. IDEs make me nervous, because I'm not sure what they're doing, and I don't trust them with my code. Mind you, I thought the same about version control, and I seem to be over that.

Or maybe there are just too many options, and I can't decide what to do. Or it's because I'm too lazy to think about it. We'll see, I guess.

Funny...

There are few poems
About Angband variants.
Until now, that is.

FAangband and the meaning of life

I have been working on FAangband for nearly five years now.

Currently the Future section of the FAangband website says:

• More AI improvements
• Maiar more Tolkienesque, and playable Spirits, and as a consequence
  
• Playing as a monster, Posband style

This is a lot of work, and I haven't really started. I'm not playing much FA, or any other variant, lately. And my mind is full of questions:

• Do I want to make these changes?
• If I don't, what will I do?
• Why am I doing this, anyway?
• Is it for the glory of people playing my variant?
• Am I merely imitating?
  
• Could there possibly be anything more stupid than starting a developer blog when you're having second thoughts about being a developer?
• If there is, surely it's starting a blog with such an incredibly whiny post.
• That last one wasn't even a question.
• Nor was that.

I'm sure inspiration will re-emerge - the creative process is not a steady one. In the mean time, having been sufficiently self-indulgent to start a blog, I'll continue to indulge myself by whinging about how hard it is to do something that is completely voluntary.

If anyone is still reading (oh, look, the self-consciousness still hasn't stopped), feel free to comment.