Mouse playability

[Nick]

A long time ago, FAangband was completely playable by mouse - no keyboard required. But port-specific mouse buttons were hard to get done (although Psi did an awesome set for WinCE), and the codebase got 'updated', and the dream died.

Now NPPAngband has mouse playability - although the front-end support is still not there.

What I would like to see:

1. GUI buttons in every front end (or text ones in gcu, I guess)
2. Full mouse playability in Vanilla/v4

[nppangband]

A long time ago, FAangband was completely playable by mouse - no keyboard required. But port-specific mouse buttons were hard to get done (although Psi did an awesome set for WinCE), and the codebase got 'updated', and the dream died.

Now NPPAngband has mouse playability - although the front-end support is still not there.

What I would like to see:

1. GUI buttons in every front end (or text ones in gcu, I guess)
2. Full mouse playability in Vanilla/v4

Agreed! I plan on implementing tile buttons and toolbars soon, at least in the ports that can hangle them.

What I want to do is:

1) Incorporate the latest main*.xxx from vanilla (that support shockbolts tiles and utf-8)
2) Modify them so the graphics files are always loaded, not just when the player is playing with tiles.
3) include tiles/buttons for the commands, and finally
2) change the screen display so it is flexible, so information can be displayed on more than the top/bottom line, and on the left side. Let the player customize thier view so they can have things like:
a commands toolbar
toolbars for the backpack, equipment, and floor items, etc....

Are you interested and everyone else in working on this (for all variants/Vanilla)? Better plans welcome.

[Nick]

3) include tiles/buttons for the commands, and finally
2) change the screen display so it is flexible, so information can be displayed on more than the top/bottom line, and on the left side. Let the player customize thier view so they can have things like:
a commands toolbar
toolbars for the backpack, equipment, and floor items, etc....

Yeah, this is exactly the sort of thing I'm suggesting. A couple of other things (inspired by thinking about what you would need to make Angband playable on an iThing):

1. Zoom function (I suspect this is much more do-able with utf8 support)
2. Graphical menu handling

So once menus and buttons are fully integrated into the game, platform-specific display and selection code for them can be written for each front-end.

[Nick]

Here is an edited discussion Jeff and I have had about this. We think that this is important.

My overall goal is to try to make a UI that will make it easy for newcomers to play the game.

Once the main-xxx.c's with utf-8 are incorporated for all the ports, I want to have the top, bottom, and left side of the screen fully customizible.

Top of screen:
Allow the players to have more than one line for messages at the top, and lines for toolbars. The toolbars can be standard commands (these can be updated and re-drawn after every player turn). It can also have a standard one for all utility commands (save, quit options menu, knowledge screens, etc). Then toolbars for equipment, floor items, and the backpack. If the player clicks on them, a toolbar pops up a menu of possible actions for that item (I already have the verb-noun object menu done and working in NPP). All that is needed is to change button.c a little bit, and to have the set of graphics loaded in every game, not just when the player is using graphics on the map. I have already spoken with buzzkill about this, and he is happy to help us with putting the buttons in the universal tileset he is working on.

There is already a way of having messages overflow from the top line onto the main screen, done for Un by Andrew Doull (and it's in FA1.1 - easy_more option). It relied on old message code, so it may be easier to start from scratch.

The toolbars can be standard commands (these can be updated and re-drawn after every player turn)
I can see a few options for toolbars:

• Standard mouse buttons (that's the obvious one, I guess)
• Buttons for items, as you suggest
• Configurable buttons to represent keymaps (this is what Psi did for the FA WinCE port)

and maybe there are others. If we're going to get serious about this, Tim Baker's AngbandTk has a lot of ideas in it.

Left screen - allow the player to customize each item on the left side of the screen. It can be the permanent, static list that Angband players are used to seeing. But for each item, the player can decide if he wants it there permanently, or if they want all the information on the left pop up temporarily for x number of turns when changes happen, and then disappear after x number of turns. Create a menu to allow the player to customize this.

I love this idea. Un did the thing of making the left panel detachable, and FA had a "left panel at the bottom" thing (which I may have stolen from Un - I don't recall). Maybe the thing to do is to move the handling of that to the main-xxx files. I think anyone who doesn't like that for reasons of tradition is probably using the gcu port And I'm thinking that the gcu port is probably an exception to a lot of this stuff (although the relevant code might be shunted from game files to main-gcu.c).

Bottom of the screen: Again, let the player have more than one line. Toolbars can appear here too, and also additional information. There can be a help section that, wherever the player has their mouse, it is displaying information. During character birth, the help entry for the active player race/class automatically displays. During play, it gives information about the square the mouse is pointing to (monster info, list of objects). Things like that.

Again, brilliant. Maybe have the status messages, toolbars and help section all as separately configurable bits.

With a number of these things, we need to think about whether they are subwindows, or part of the main window, or UI-generated widgets - I'm inclined to favour the last.

Other things I'm thinking about:

1. Zoom function. We should be able to replace the cumbersome font-changing process with a simple zoom control that picks a font size based on the window size and the level of zoom. For most ports, this can be a slider or something, so you can zoom out to see what's around, then zoom back in for better control. This will take a bit of work, obviously...
2. Menus. The menus (inventory, spellcasting, etc) have basically been abstracted out so that the game calls menu code and it's all centralised. The next step seems to me to be to make the port UI handle the menus. Again, work needed.
3. New Ports. Windows, OSX and Linux are fairly well catered for, there is a pretty up-to-date Android port (which I don't know much about), and an outdated NDS port. We desperately need an iOS port, and I think getting the Android guys involved in all this would be helpful. Plus Windows 7 phone (or whatever they call it), maybe...

I think this is pretty important to do. I get the impression that Angband is considered an antiquated game by the general roguelike community. Plus, it is hard for our variants to get much attention if vanilla angband is being ignored. Implementing as many buttons/toolbars as possible will help pave the way for a touchscreen tablet version.

But the question is: If we do this, and/or have a team of people helping us, what codebase do we start with? The Angband 3.4 codebase has changed so much, everything we have done in FA, NPP, and UN would practically have to be re-written from scratch. What is the state of AngbandBase?

I think it really needs to be done on the V3.4 codebase. This page is a guide to what does what in the V3.2 codebase, and 3.4 is not actually a huge change from that. I think that making sure appropriate mouse buttons appear will go most of the way to getting 3.4 to NPP0.5.4/FA1.1 state.

[Magnate]

I think 3.4 is a good choice of codebase to start with - it ensures that contributions from others can be put to best use.

I'm really not a UI or UX guy, so I'll just wait and see what happens with all the customisability and mouse-driven stuff. But I did want to ask: does this plan include fixing all the message handling (ticket #1502)? IMO it's one of the big precursors to the core/UI split, and will address all the out-of-order message bugs.

I ask because I'm trying to fix archery in v4 and pulling my hair out with passing nested pointers to message types. Ugh.

[Nick]

But I did want to ask: does this plan include fixing all the message handling (ticket #1502)? IMO it's one of the big precursors to the core/UI split, and will address all the out-of-order message bugs.

Short answer: no. These things also apply to FA, which doesn't have the message ordering issues (AFAIK), so that's an independent issue.

I see all the things we discussed as more important than (and maybe precursors to, or part of) the Core/UI split. I am in favour of making the game play the way we want it to, and then worrying about tidying up the code later.

[takkaria]

Maybe the thing to do is to move the handling of that to the main-xxx files. I think anyone who doesn't like that for reasons of tradition is probably using the gcu port And I'm thinking that the gcu port is probably an exception to a lot of this stuff (although the relevant code might be shunted from game files to main-gcu.c).

I think this is a really bad idea - if the main- files start having their own side panels, then you would have massive code duplication and it would make it more difficult to have a cross-platform game. Also, sharing frontend improvements would become a lot more difficult.

OTOH, I'm not doing the work, so go for it

[Magnate]

Short answer: no. These things also apply to FA, which doesn't have the message ordering issues (AFAIK), so that's an independent issue.

I don't think it's independent, but I can't be sure of that until you answer this question: have you solved those issues in FA with some sort of systemic change to message handling, or just by fixing every use case?

I see all the things we discussed as more important than (and maybe precursors to, or part of) the Core/UI split. I am in favour of making the game play the way we want it to, and then worrying about tidying up the code later.

Hmm. Leaving aside the basic disagreement about project management methodology (creating lots of time costs later from untidy code), I'm fine with seeing this stuff as a precursor or early part of the core/UI split. I was just intrigued as to whether you were focusing solely on inputs (buttons and so on), or both inputs and outputs. Because it seems to me that if you're going to do a lot of work on where things are displayed (panels, sidebars and what-have-you), I don't see how you can avoid grappling with when they're displayed. But like I said, this isn't my bag, so feel free to ignore me ...

[Nick]

I think this is a really bad idea - if the main- files start having their own side panels, then you would have massive code duplication and it would make it more difficult to have a cross-platform game. Also, sharing frontend improvements would become a lot more difficult.

I guess I was being imprecise there. I think what to display in the side panel should be internal to the game; I also think that the option of having the "side panel" at the bottom, or absent altogether should exist (and Un and FA have both dabbled in this already). I do also think that it might be good to be able to manipulate subwindows directly, but that would take some thought.

I don't think it's independent, but I can't be sure of that until you answer this question: have you solved those issues in FA with some sort of systemic change to message handling, or just by fixing every use case?

As far as I know it has not ever existed in FA. ISTR that it started becoming a major problem in V with the unification of monster pain messages, etc, which FA (even 1.2) does not have. One related thing I have had trouble with in FA is making sure subwindows update when they're supposed to; I suspect taht's probably been fixed case-by-case.

Leaving aside the basic disagreement about project management methodology (creating lots of time costs later from untidy code)

IMHO the only measure that matters here is the player's experience. A good game can be fairly buggy and still retain players (see Posband, for example); a bad game can run as smoothly as you like and have pristine, elegant code and everyone will still hate it.

Also IMHO, the Angband interface is in urgent need of improvement. It needs to be done now.

[Derakon]

IMHO the only measure that matters here is the player's experience. A good game can be fairly buggy and still retain players (see Posband, for example); a bad game can run as smoothly as you like and have pristine, elegant code and everyone will still hate it.

Also IMHO, the Angband interface is in urgent need of improvement. It needs to be done now.

That attitude is, I feel, overly shortsighted; too much development done without concern for the future will result in a codebase too messy for people to want to deal with, which can completely hose not just Angband but all the variants that want to keep up with it. I'm not saying that every line needs to be absolutely perfect, because heaven knows the current codebase isn't always entirely legible -- just that it's worth taking the time to figure out how to do things with a minimum of downstream pain, as much as possible.

[Nick]

That attitude is, I feel, overly shortsighted; too much development done without concern for the future will result in a codebase too messy for people to want to deal with, which can completely hose not just Angband but all the variants that want to keep up with it.

As far as I am aware, FAangband 1.2 is the only variant based on the Vanilla codebase post 3.1.2v2 (although Jeff has updated parts of NPP - it includes the new command/event stuff, for example). Thus far, my reward for updating is that hardly anyone is playing FA, and those that are are playing 1.1. I suspect that any other variant maintainers that have considered updating have looked at the wholesale changes since then and run screaming.

It is concern for the future that is in fact the point here. The Core/UI split entails difficulties (which takkaria has written about); it is possible that Magnate's effects code will help with that, but I don't think that's a done deal. So the choice seems to be to sit around watching the interface get more and more outdated and say "Core/UI split" in answer to every question, or to make some changes now which are not actually going to break the game or be incompatible with the Core/UI split anyway.
(EDIT: Maybe some of that is a little harsh )

I'm not saying that every line needs to be absolutely perfect, because heaven knows the current codebase isn't always entirely legible -- just that it's worth taking the time to figure out how to do things with a minimum of downstream pain, as much as possible.

...which is pretty much exactly what I am suggesting

[LostTemplar]

Thus far, my reward for updating is that hardly anyone is playing FA, and those that are are playing 1.1.

No new dumps this year, despite all the cool features, FA already have.

[nppangband]

That attitude is, I feel, overly shortsighted; too much development done without concern for the future will result in a codebase too messy for people to want to deal with, which can completely hose not just Angband but all the variants that want to keep up with it.

#IFDEF RANT_MODE

IMHO it passed that point a couple versions ago, and is slowly working its way towards FUBAR status. Again, that's just my opinion, but I do think it is somewhat vindicated by the fact that none of the variant maintainers are trying to keep our codebases current with Angband 3.4. Some of us are taking bits and pieces of the code, but AFAIK nobody wants the whole thing, much less the gameplay features. Also, compared to 5-7 years ago, there isn't much in the way of new variants being based on 3.4 either. It doesn't help the fact that the general consensus is that 3.4 gameplay is still unbalanced, but it isn't just gameplay features that need to be reverted in the current codebase.

My opinion on the core-ui split is that it is a conceptual plan that has no champion willing to do the actual work. So why put off necessary improvements that the players actually care about? I personally see most of the codebase changes in the last couple versions as based on individual programmer preference rather than need. UTF-8? Fantastic change. Bitflags? More of a detriment than an improvement. I don't care to replace thousands of indiviusal lines of code with other single lines of code that do the exact same thing, if and only if they are supported by several new files of code that were previously unnecessary, and following that up with weeks of bug reports for the stuff that I inevitably cut-and-paste incorrectly. If the core-ui split ever happens, I anticipate it will be more of the same rather than something that actually makes programming easier, or a better game experience for the end user.

But the real problem that Nick and I want to address is that Angband isn't getting the audience it deserves any more because of the lousy interface. They don't care what is under the hood, but rather what they see onscreen and the emjoyability of the gameplay. I am sure most people who are active on this forum doesn't see much of a problem. They wouldn't be playing Angband if they couldn't live with the current interface, or like the current game. But I consider the "silent majority" those who would never give Angband a chance, and are playing other games instead. Do you honestly think most people that play TOME would give Angband a second look? For variant maintainers, that means it is doubly difficult for us to get an audience, because most players try the variants after enjoying vanilla and wanting more like it.

#ENDIF /* RANT_MODE */

[Derakon]

Hm, bad idea for a post, clearly. I apologize for the presumption; for some reason I had it in mind that the active variants were almost all based off of 3.2, which was clearly erroneous. And to be clear, I wasn't trying to say that a good UI can't ever be implemented if it hurts the "purity" of the codebase in any way. It just sounded to me like Nick was saying "damn the codebase, get the results you want no matter the cost!" But I was reading too much into his post. Anyway...

v4 (which is what I assume you meant by 3.4) is its own thing and I wouldn't consider it remotely "official Angband" in any sense. I believe the actual 3.4 is supposed to come out in a few months, and it's just cherrypicking the changes from v4 that actually work and have been thoroughly tested. Of course, almost all of the changes in v4 have been gameplay changes, not UI changes, so that doesn't really help much in terms of appealing to a broader audience. And the UI changes that have been / will be implemented in v4 are largely with respect to features (like the new affix system) that I expect won't be in 3.4.

I guess part of the problem also is that the people on the Vanilla devteam have all been playing Angband for so long that the UI doesn't even really exist to them any more -- the desire for action goes straight to that action being performed without having to think about how to do it. That makes it rather difficult to come up with potential UI improvements and motivate yourself to implement them. I know that's the case for me, anyway. I mean, I looked at this thread and thought "Mouse control? Who would want to play that way?" Probably lots of people, as it turns out.

[nppangband]

@Derakon - Sorry. I hit quote with the intent of a quick reply that morphed into a long rant about the whole thread. My post was not directed specifically against your sentence. In hindsight I would have replied instead of quoted. Of course Nick and I intend to write good code. We we intend for this to ultimately end up in our variants.

When I mentioned Angband 3.4, I was referring to whatever is out there at github under the Master branch. Naturally, I can't quite tell which version it is, because the version number that has been at the top of defines.h for decades is no longer there.