Variant(s) with the best user interface?

[CJNyfalt]

Hi, a long time since last! Since I'm planning to start programming *bands again, I want to make a poll to help me guide my effort.

Which variants have the best user interface (UI)?

What UI features stands out in those variants?

Favorite UI feature in any variant that you which was adopted in all *bands?

Which would you rather, from an UI perspective, use as base for a new variant: Vanilla or Sangband?

[Big Al]

I'd take the menu system from vanilla, the mouse support from FAangband and the status bar on the bottom of the screen (instead of the side of the screen) from Unangband.

[Bandobras]

It depends. For ASCII I'd take the status bar on the side of the screen (instead of the bottom of the screen) from Vanilla, for tiles (which I've not even once played with, yet) or perfectly square fonts, I'd probably take the Un status bar. Then, on panoramic displays, Vanilla style wins even for tiles for me. This is all with only the main big window (I never play with multiple terms). For multiple this is all different, again...

About S, I think the S code is great, for UI, script files, etc., but it's unmaintained, so it's mostly unusable from my perspective. It's 100% better to steal code from maintained variants for various reasons.

P.S. Yet another dimension is: do you ask a newbie or a veteran? They have different needs and e.g. S seems a bit more newbie friendly (until it crashes).

[Nick]

Hi, a long time since last! Since I'm planning to start programming *bands again, I want to make a poll to help me guide my effort.

Excellent Here are some random thoughts; hope they help. There is currently a lot of development effort going into Vanilla, and (if you haven't already) it would be a good starting point to have a thorough look at the official site.

Which variants have the best user interface (UI)?

What UI features stands out in those variants?

Features of note include :

• Sangband display system
• S/NPP extended fonts
• FA/Un/V (to varying degrees) mouse and menu interfaces
• FA small screen support (far from perfect, but it exists)
• Un/FA double and triple tile (note that the S display system does this better, but this is a relatively simple add-on to the standard bigtile)
• S/Un/FA stats at side or bottom (done slightly differently in all three, and part of the bigger display system in S)
• Un (and pinched for FA) easy_more messages, allowing all messages to appear at once

Which would you rather, from an UI perspective, use as base for a new variant: Vanilla or Sangband?

I've put a lot of work into the mouse/menu system, so I'd have to say Vanilla Having said that, the Sang display system is really impressive - although the V use of SDL is maybe more straightforward.

This is kind of all over the place, but I hope it helps a bit.

[Anne]

Speaking as a newbie (and admittedly I haven't played many variants yet), I absolutely prefer the status bar on the bottom instead of on the side. I love Unangband's.

Personally, I always turn off mouse support, so I can't say anything about that.

And I also particularly enjoy Unangband's dungeon knowledge screen, if your game would need something like that.

[Pete Mack]

I second Anne's recommendation of the knowledge menus, though the monster knowledge is likely to prove more useful than dungeon knowledge in most variants. (Dungeon knowledge only applies for variants with wilderness and/or themed dungeons.)

If your variant needs any grouping menus, the UnAngband code is highly portable. So is the V/FA version, although that also requires the ui-menu API. I recommend the latter if you are planning to use unified menus; otherwise use the UnAngband version.

The NPP version is not portable; it was derived from the original ad hoc UnAngband implementation.

[CJNyfalt]

Thanks for all the answers! So, it seems that S, V, FA and Un have the best UI.

First, to answer the question: As a *band programmer I'm a veteran, as a player a newbie. But, the difficulty of the game itself wouldn't matter since I plan to make a big overhaul of game mechanics for my variant.

Second, some more thoughts about the answers and which way I'll be going with my variant:
- S and V are the only variants that I consider to be acceptable as a base, because they are the only ones in which I can reach the goal of dual-licensing.
- I can't take stuff directly from other variants than those two because of the license issue, luckily it seems that stuff people recommend from Un and FA are mostly either in V or things that can be duplicated by just observing the layout.
- I have decided to use S as the base, it will probably be easier to take stuff that I want from V and add to S and the reverse direction. Also more stuff that I like in S.

[Nick]

Second, some more thoughts about the answers and which way I'll be going with my variant:
- S and V are the only variants that I consider to be acceptable as a base, because they are the only ones in which I can reach the goal of dual-licensing.
- I can't take stuff directly from other variants than those two because of the license issue, luckily it seems that stuff people recommend from Un and FA are mostly either in V or things that can be duplicated by just observing the layout.

I have been slack with formal licencing issues in FA (mainly through difficulty caring), but I believe FA is as close as V to being dual-licencable. The only part that is not is the WinCE port (as I haven't been able to contact the original writer of the V one), but I release that separately. Also, all the new features in FA which might be relevant to you have been contributed to only by people who have formally stated willingness to release under the GPL (chiefly me, Pete Mack, Si Griffin, Andrew Doull, Jeff Greene, Diego Gonzalez). Oh, and Andrew Sidwell, if you're prepared to trust him

Hope that helps.

[CJNyfalt]

I have been slack with formal licencing issues in FA (mainly through difficulty caring), but I believe FA is as close as V to being dual-licencable. The only part that is not is the WinCE port (as I haven't been able to contact the original writer of the V one), but I release that separately. Also, all the new features in FA which might be relevant to you have been contributed to only by people who have formally stated willingness to release under the GPL (chiefly me, Pete Mack, Si Griffin, Andrew Doull, Jeff Greene, Diego Gonzalez). Oh, and Andrew Sidwell, if you're prepared to trust him

Hope that helps.

It helps, thank you.

BTW, you wouldn't have some diff file containing the mouse system somewhere, do you?

[Pete Mack]

It helps, thank you.

BTW, you wouldn't have some diff file containing the mouse system somewhere, do you?

I think what you want is here: http://dev.rephial.org/trac/changeset/698

[Nick]

I think what you want is here: http://dev.rephial.org/trac/changeset/698

Probably. That's my patch to Vanilla for mouse buttons, which assumes the level of mouse control already in V3.0.9. IIRC Sangband has some mouse control code in it, but I'm not sure how much.

[CJNyfalt]

IIRC Sangband has some mouse control code in it, but I'm not sure how much.

Very little, thought it had none. Mouse is supported in SDL at least, but mouse events are queued as multiple characters in the input queue instead of having a event struct. So, it was more this I was looking for:

http://dev.rephial.org/trac/changeset/27

[Pete Mack]

Very little, thought it had none. Mouse is supported in SDL at least, but mouse events are queued as multiple characters in the input queue instead of having a event struct. So, it was more this I was looking for:
http://dev.rephial.org/trac/changeset/27

95% of that code has to do with general-purpose event handling and menus. Very little of it is related to processing mouse events

The mouse code is almost entirely:

externs.h
z-term.h
z-term.c
util.c

You also need to use mouse-aware copies of main-xxx.c

Again, if you don't want menu code, you can get the mouse-only code from UnAngband. (It's the same 4 files.)

[andrewdoull]

- I can't take stuff directly from other variants than those two because of the license issue, luckily it seems that stuff people recommend from Un and FA are mostly either in V or things that can be duplicated by just observing the layout.

Anything in Un that is not in V is 'dual-licensed' in the sense that all contributors are happy for it to be GPL'ed when the whole code base is GPL'ed. So it can be contributed into a GPL work provided it's not derived from non-GPL code in Unangband.

Which excludes the stuff in main-win.c, but pretty much includes everything else IIRC.

Andrew

[techarcana]

What about AngbandTK?

I'm sure I'm chiming in waaaaaay after the discussion, but I've only just found out that any work was being done on maintaining Angband at all... I'd been visiting http://www.thangorodrim.net/ for my Angband news.

Has anyone else seen the AngbandTK interface? I've been staying away from the current builds just because I like the 3/4 overhead view it provides, as well as the graphical access to the stores and inventory. Plus it has a great tileset.

Does anyone know if any further development has occurred with AngbandTK? The code revision is 2.9.2r2. I know part of the difficulty is that it is written in TCL.

I have both the vanilla Angband variant and the Zangband variant that runs under the TCL based framework.