Mouse playability

[nppangband]

Is there anything that can be done for older variants that would help you work out what was worth incorporating and what wasn't? (Like, for example, a roadmap of what changes are stepping stones to something else and what aren't?)

I thought about it, and here is my best answer. But I will spoil the ending by saying that after I type eveyrthing below, I have already come to the conclusion that it isn't practical for you all to keep us in mind when writing code.

What we would really need to keep up with vanilla is consistency in the main-xxx.c files, and in the many files at the end of the alphabetical list of c. files (util.c, z-term.c, etc.....). And what I mean by consistency is that that they can change, but we should be able to simply swap out the old file for the new one, compile, and outside of maybe some minor changes it should work. Or, if those files do need to be seriously re-written, they are done all at once and then kept consistent again for a couple years. When I updated the NPP codebase from 3.0.6 to 3.1.2v2, by the time I was done 3.2 was aleady finished and the codebase I was working off of was already obsolete.

Here is an example of "consistency" & how it can cause difficulties when going from one version to another. When I was going from 3.0.6 to 3.1.2v2 was that most of the functions for reading and writing files (in util.c) used to return -1 for failure, and 0 for success. In 3.1.2v2 these same functions were switched to return 0 for failure, and 1 for success. When somebody does that deliverately to their own codebase, it is simple to change. When that code goes into a variant github style, and everything compiles OK, but the game is horribly broken. One change like that isn't a big deal, but when we are dealing with the cumulative effect of many changes like that makes it just not worth it to keep up with Vanilla. I think it took me 4 months of coding from the time I started updating the codebase from when my playtesters could play for more than a couple minutes without it crashing. If I knew that codebase was going to be consistent for a couple years, then it is worth it. But if it is going to be completely changed again before I am even done, not worth it.

But in the end, Nick probably has the best answer. Do what you need to do and we suck it up...just please forgive us if we rant once or twice a year.

[Nick]

z-canvas

Makes sense. Don't think I'll be coding it either

[takkaria]

My understanding is that the idea of the Core/UI split is that the game asks the UI for an event, and the UI gives it one, and repeat. The problem with that is that currently we don't have discrete events coming from the (player via the) UI - we have a little conversation:
"Cast a spell"
"What spell?"
"This one"
"At which monster?"
"Not a monster"
"OK, then where?"
"At that bit of floor"
and finally the game can get on and cast the spell.

So there seem to me to be two possibilities:

1. Give up on the split or
2. Define each of those answers as an event.

and I am not confident that 2 is achievable...

Neither am I but it's gotta be worth a try.

Also, I'm not sure that I understand what you mean by [having two UIs, a graphical and text one] - or at least, I kind of vaguely do, but I'd like to hear your explanation.

OK, so what I'm thinking is that there is one text-based UI, suitable for curses and other simple terminal emulators, and one graphics UI, which uses a canvas to draw on instead. So the map can be a different font (or size of font) to the rest of the display, so that the sidebar can be resized by dragging it at the edge, so that graphics mode isn't a massive hack, etc. The main point, though, is that Angband has two modes: write to a terminal and write to a canvas (and not use z-term). I think in anything past the short term, Angband needs to stop treating the screen as if it's a grid of equal size characters and treat it like it's a set of pixels. As well as a z-term, we have a z-canvas, which has an interface that ports implement like they implement z-term. And the game only worries about whether it's using z-term or z-canvas.

Maybe I'm being a code astronaut again - I'm unlikely to find the time to do this myself. But I strongly believe that to get a better UI, Angband has to take advantage of the fact that screens have pixels and not just letters. Especially when it comes to tiles.

[LostTemplar]

IMHO most important part of vanilla code, used by variants are various UI cross platform functions. Anything else is so much different, that there is no point to use vanilla code, it is easyer to just write a code for cool new features form scratch.

As for core-ui split I dont see any formal difference between e.g. browsing the store inventory to by item, and browsind the book to cast spell. So if store interface is OK, what is the problem with book interface? The game is allways waiting for user command, and set of possible commands depends on game state.

[Nick]

But what about support for variants more generally? Is there anything that can be done for older variants that would help you work out what was worth incorporating and what wasn't? (Like, for example, a roadmap of what changes are stepping stones to something else and what aren't?)

I think what variant maintainers really care about are (in order):

1. Being able to use relatively modern front ends for relevant platforms. This is really the big one, as without it a variant will gradually become unplayable;
2. Being able to adopt Vanilla UI improvements (monster and item lists, more colours, utf8, etc). This doesn't bite quite as hard as 1, but after a while variants start to suffer in comparison with V.

And really, I think that's it. A roadmap as you describe would probably be really helpful; this is probably a start, but the emphasis is wrong.

When it comes down to it, I think the devteam needs to look after Angband, and variant maintainers just have to suck it up

I think I at least partially agree with nppangband. The core/ui split in V at the moment is very much half-baked and a hinderance to further development. I think that to implement it fully (with an events system and all) would require a lot of layers of abstraction and would make it actually pretty difficult for people to dive in and code.

...

I honestly don't know what the solution is, but I think incremental improvements to what we have now must be going in the right general direction.

My understanding is that the idea of the Core/UI split is that the game asks the UI for an event, and the UI gives it one, and repeat. The problem with that is that currently we don't have discrete events coming from the (player via the) UI - we have a little conversation:
"Cast a spell"
"What spell?"
"This one"
"At which monster?"
"Not a monster"
"OK, then where?"
"At that bit of floor"
and finally the game can get on and cast the spell.

So there seem to me to be two possibilities:

1. Give up on the split or
2. Define each of those answers as an event.

and I am not confident that 2 is achievable...

I'm probably missing stuff here, but for now I think that incremental improvements may be the way to go.

Also, I'm not sure that I understand what you mean by

just two UIs, a text one and a graphical one

- or at least, I kind of vaguely do, but I'd like to hear your explanation.

[Magnate]

- Variants are not close enough to V or each other to use simple git trickery to transfer code between them.
- It's really hard for any variant maintainer to keep up with the V codebase - one human versus a bunch of ruthless hyperactive code zealots, apparently on crack.
- Bitflags (and by analogy, other things): I see both sides of this. I think that Jeff would feel the benefit of bitflags once they were incorporated, but the process of incorporating them is ... painful.
- The whole idea of the community being involved in development is that we need to be able to have this sort of discussion in a robust and mature way. The devteam, as gatekeepers to the repository and custodians of the game, have a special responsibility to listen. When mild-mannered people like Jeff start ranting about stuff, it reflects something (even if that is just that being a variant maintainer isn't always easy...)
- The words "it's time I refactored ..." strike a chill of fear into my soul
- The devteam is fairly *nix-centric (I include myself), where I suspect most players are using Windows.

I think you just clarified something for me. I think, without anybody ever articulating it or perhaps even realising it, that what the devteam's code "improvements" were intended to do was to make the codebase easier for future variants, not existing variants. Having read the posts from Jeff and half and yourself, it's pretty clear that what some of us consider great leaps forward in the code are worse than useless to you folks - they actually prevent you from making use of V because it's now too different. But having kept v4 in sync with V since the fork, I think the "git trickery" will mean that variants branching from V in future will be able to keep up with much less hassle, and more benefit.

We have a devteam meeting on Saturday, and I've put an item at the start of the agenda on this topic of UI improvements and what V can/should do for variants. I guess the proposal on the table will be takkaria's: that we focus on one text UI and one graphical UI and scale back the n-interface ambitions. But what about support for variants more generally? Is there anything that can be done for older variants that would help you work out what was worth incorporating and what wasn't? (Like, for example, a roadmap of what changes are stepping stones to something else and what aren't?)

[Antoine]

If we can get it done, that would be great. It would be a little bit of work, but I like the idea of having quickband included in the NPP game. What is the status of ironband?

Ill take this to email.

ironband is a fun little game, but I don't feel the same need to provide for its continued development.

a

[takkaria]

I think I at least partially agree with nppangband. The core/ui split in V at the moment is very much half-baked and a hinderance to further development. I think that to implement it fully (with an events system and all) would require a lot of layers of abstraction and would make it actually pretty difficult for people to dive in and code.

I'm not sure what the solution is, but I think it has to be a lot simpler. The current system is designed for the eventuality of n different UIs and as a result tries to be too abstract and generic. I would think that having and designing for just two UIs, a text one and a graphical one, would make life easier.

A core idea behind the current core/UI split is that the core code would run (eventually) without user input, with the UI just feeding it commands and being sent events. However, Angband is not currently designed this way and having spent some time thinking about the complexities of making the core code not block on any input, I think it's gonna make the code obscenely complicated and difficult to follow in parts.

("Go up stairs" is simple enough, as is "fire arrow x". "Aim wand of magic missiles at the nearest monster" is a little more complex. Using a rod of identify, well, the UI has to do some interrogating of the game to ask for extra parameters, find out that it wants an unidentified item, and then create the command "zap rod of identify and use the item x". The problem is that some commands take different parameters depending on what another parameter to that command is. It's a nightmare.)

I honestly don't know what the solution is, but I think incremental improvements to what we have now must be going in the right general direction.

[nppangband]

I suppose I should weigh in.

Sil is a fork from NPP 0.4.1, which was the current version at the time.

I had no idea. I have wanted to give sil it a try. Now I definitely will.

I have struggled with TR2_XXX as much as anyone and would love for it to be magically replaced with something sensible.

Starting in NPP 050, we just have a couple simple macros for features that accomplish the same thing as bitflags. It would be a simple process to have some #defines and macros for objects & monsters so that the line of code is: "if race_has_flag(r_ptr, UNIQUE)" or "if mon_has_flag(r_idx, UNIQUE)". {Please ignore everybody, I am just brainstorming out loud}

[nppangband]

I do think there's some room for variant maintainers to reduce dilution by merging two variants into a single project.

This however is totally a decision for the people involved.

For instance, I'd love to turn Quickband into a 'quick mode' of NPP and discontinue it as a stand-alone variant, but the work involved may be prohibitive even if the NPP guys were keen.

A.

If we can get it done, that would be great. It would be a little bit of work, but I like the idea of having quickband included in the NPP game. What is the status of ironband?

[Nick]

OK, Blue Baron, I am now really wishing that I had looked properly at your stuff before starting this (not that it hasn't been fun...)

First of all I am wondering what you think about the mouse support / context menus that I already wrote and are already in 3.4-dev and v4. The game should be entirely playable by mouse except entering numbers. Just make sure mouse_movement is on and right click.

I have checked this out and it is excellent. When Psi and I did a similar thing for FA, we avoided right-clicking to make playing on a WinCE device (where the equivalent was holding down the stylus) easier; that involved some messy workarounds, though, and I like your method better. I assume there will be some way of (effectively) getting two types of click for smartphones, etc.

There are still places where you can't do mouse stuff (character dump to a file, for example), but that should be just a matter of making the appropriate buttons.

So I think there should be be the text ui with port specific overrides for specific interactions.

Anyways, what you do will probably shape the CoreUI split so I think you should implement what you want with that in mind.

I agree.

About detachable side panels: To me this means the map covering the whole screen with floating (but lockable) subwindows in the main window. Also I think this is best implemented as part of the CoreUI split.

Yes and maybe

About graphical menus: As I said above, I think there should be be the text ui with port specific overrides for specific interactions. A way to do it might be to add more terminal hooks, and test on use, since they would be optional, unlike the current hooks. For instance, the top of the get_item function could become:

bool get_item(params)
{
    if (Term->get_item_hook)
        return *(Term->get_item_hook)(params);
  ... rest of current function

the hook function could open a graphical menu (decided by the port) and return the id of an item selected or let an existing inventory (or equipment or floor or hotkey bar) window know it is interested in the next selection from it.

I almost completely agree here, but I hope it can be done at the level of ui-menu - so get_item would call the (Term->menu)(params). I already have get_item calling the menu code in FA - see here.

About buttons:

Snip stuff I furiously agree with. The only thing I would add is the ability to add custom buttons based on keymaps. Oh, and the NDS port had transparent overlay buttons which were neat.

About zoom mode: in windows you could add additional tests to square_to_pixel and pixel_to_square, as well as the actual size changes to term_pict_win and term_text_win for a consistent look. The SDL port would be harder since SDL doesn't have a stretch and blit function, but this would be an optional command anyways.

For SDL, could you change font/tile size while keeping the window boundaries fixed when you zoom? This would require the game to know the number of rows and columns had changed, but that ought to be possible.

[half]

I suppose I should weigh in.

Sil is a fork from NPP 0.4.1, which was the current version at the time. NPP originally split from V around version 3.0.3 and by 0.4.1 NPP had added a few more features from more recent versions (up to 3.0.5 I think). Sil was originally intended to be a much more minor modification, removing the most egregious non-Tolkienian aspects from Angband. I chose NPP since Jeff displayed such good taste in the collection of patches he applied to Vanilla. As time passed and I made more and more radical changes in Sil (no classes, no levels, completely new combat system, completely revised monster list...) most of the features Jeff had added were removed. However many still remain, most notably the excellent 4GAI (which was my main reason for choosing NPP and it has undergone quite a few subsequent modifications in Sil).

Sil features several interface improvements, but most of these are in the form of rethinking the keyset with new players in mind. I suppose there are also the starting and death menus, damage being shown on screen when hitting monsters, and a few others. I would love to have some of the newer interface features such as mouse support, Shockbolt tile support and (eventually) iOS and Android versions, but there is a huge barrier to this due to the major changes to the V code-base, most notably the move to the new build structure.

I really liked the idea that I was writing a game that worked on multiple systems (Mac, Windows, Unix) and that it was future proof since there was a community with enough specialists to keep the relevant main-xxx files up to date. I would just need to grab the new one and slot it into the Sil source. Sadly this was not to be. I did waste an entire frustrating day trying to update to the new build system, but there were too many changes and at the end of the day I had an unbuildable mess. I was writing this game for leisure, not work, so with a heavy heart I reverted the day's work and went back to coding features.

Like Jeff and Nick, I really don't benefit from changes to the code like that. Subsequent changes have been pretty neutral for me as I've given up on ever getting fully up to date. I may someday do the minimum to be able to use the Shockbolt tiles or to slot in the new main-xxx files, but I know that things are likely to change again undoing the future-proof purpose of this coding, so it is not an attractive proposition to me.

I'm not really sure what the Angband dev community should do to fix the problems that Jeff, Nick, and I have pointed to, but I do think it is worth thinking about. I think the bitflag thing is a good example. I have struggled with TR2_XXX as much as anyone and would love for it to be magically replaced with something sensible. However, I wouldn't sacrifice a day's development of Sil to change it over. Therefore the fix in V means that there is a whole lot more V code that I couldn't borrow without major hassle. It may well be that the V team should just ignore all Angband variants and plough on. However, they probably shouldn't think that they are doing the variant community a favour by cleaning things up like that.

[Nick]

Well, I started this thread to get some discussion going - mission accomplished

Now, I'm just going to say a bunch of things that spring to mind on reading the thread so far. Apologies in advance.

• I think Angband is a brilliant game with a past to be proud of, a big future, and a player/developer community with the good of the game at heart.
• Currently, the UI deficiencies are a barrier to many new players, and we need to get on with solving those.
• Blue Baron: I need to look properly at what you've done and respond properly later. But it looks really cool and I'm very encouraged.
• One of the main things that (AFAIK) still needs doing for mouse support is adding and removing mouse buttons depending on context - FA 1.1 and NPP have lots more instances of button_add and button_kill than V.
• Variants are not close enough to V or each other to use simple git trickery to transfer code between them.
• It's really hard for any variant maintainer to keep up with the V codebase - one human versus a bunch of ruthless hyperactive code zealots, apparently on crack.
• Bitflags (and by analogy, other things): I see both sides of this. I think that Jeff would feel the benefit of bitflags once they were incorporated, but the process of incorporating them is ... painful.
• The whole idea of the community being involved in development is that we need to be able to have this sort of discussion in a robust and mature way. The devteam, as gatekeepers to the repository and custodians of the game, have a special responsibility to listen. When mild-mannered people like Jeff start ranting about stuff, it reflects something (even if that is just that being a variant maintainer isn't always easy...)
• Angband is not ever going to be the latest thing again. But I believe it will always have a market, because there is a small proportion of the population for which it is exactly what they are looking for in a way that no other game is. When I discovered it I had a sense of coming home. What we need to do is ensure that those people can find it and recognise that they have found it.
• Message oddities - my impression is that there have always been small issues, but they got worse after the monster pain etc stuff came in. But that's only an impression, and I'm probably wrong.
• The words "it's time I refactored ..." strike a chill of fear into my soul
• For a while, I was putting a bit of effort into advertising FA on game sites (happy penguin, macupdate, versiontracker). In hindsight, I think that paid off for a while. I think advertising to the roguelike community is going to get us a small share of a small community, and a bunch of people saying "Why play *bands when there's <roguelike-du-jour>?"
• The devteam is fairly *nix-centric (I include myself), where I suspect most players are using Windows.
• EVERYONE needs to remember that all this is completely voluntary, and a game.

[Antoine]

I think it's just dilution really - angband variants are now competing not against each other but against all the Brogues and 7DRLs and so on and so on.

I do think there's some room for variant maintainers to reduce dilution by merging two variants into a single project.

This however is totally a decision for the people involved.

For instance, I'd love to turn Quickband into a 'quick mode' of NPP and discontinue it as a stand-alone variant, but the work involved may be prohibitive even if the NPP guys were keen.

A.

[Antoine]

It could very well be, but I hope that isn't true. The idea that the Angband community can't sustain interest for more than one or two variants at a time is troubling.

... I would hate to think that even a smoking-hot variant like sil could possibly have the power to make all of the others invisible.

I don't say that Sil is generally cannibalising all attention from other variants: I just think that the kind of person who wants to play FA is particularly likely to be the kind of person who wants to play Sil.

(Note: I love First Age Tolkien mythos and think both FA and Sil are very cool)

A.