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.
(This is d_m from oook/IRC)
ReplyDeleteThere are already some roguelike UI libraries out there (for instance libtcod) but I do think having an Angband-centric one would be nice. As someone who's working on a variant but is probably not going to test it on Windows, it would be nice to know that my UI library will "just work" there. That goes double for handheld devices.
I worry that no one is going to want to rewrite their variant (or Vanilla) in terms of a new library. But I do think it's a good idea.
I think you will find you also want to abstract out things like reading/writing files and the build process... those are two other things which can be kind of platform-dependent.
I would definitely be interested in working on something, although I only use 1 1/2 of the current UIs ;)
Speaking of abstracting things out... I'm no expert on the differences between C and C++ (or either language itself for that matter), but with a radical idea like this, might it make sense to do it in C++? C++ is object-oriented out of the box, while in C, if I'm not mistaken, anything even close to OO is more of a hack... I mean, since everything would be rewritten anyway, why not do it right? ;)
ReplyDeleteI guess I'm thinking of this as something that can be done incrementally, starting with the base that already exists for O and FA. Whether that develops into something you'd call a library, I don't know. I'd like it, though, if old (or new) variants could be adapted for it if anyone wanted to, and if changes to the 'library' didn't break everything.
ReplyDeleteIs there any reason we don't adopt a standard library that already exists e.g. libcotd, as opposed to a vague unspecified target that we'd like to have?
ReplyDeleteI'd be a lot more prepared to adopt something that aimed in this direction.
Because the vague unspecified target is basically the existing low-level code, whereas an existing library would require major both internal and external changes. The idea is something achievable to be done in stages, rather than a revolution.
ReplyDeleteGreetings,
ReplyDeleteGoing to libtcod would mean giving up curses, I am not sure I am ready for that.
T.