Tears unnumbered ye shall shed

[Nick]

Even if it is an option, game balanced for this could not possibly be better than any version before it.

Challenge accepted!

[half]

This alone was enough for me to absolutely hate Sil. I like playing the game at my own pace, slow or fast however I feel at the moment. I don't even go to other suggestions, because this would ruin the game for me no matter what you do to other things. Even if it is an option, game balanced for this could not possibly be better than any version before it.

Well I guess Nick won't have to worry about getting your approval on the other changes then, which will make things easier. Luckily there are many earlier (and future -- 3.5) versions available that you love to play.

[Philip]

Perhaps some lessons could be taken from Antoine's variants. Minimal is a good outline of what can safely be removed, and Iron has some great ideas of it's own.

[half]

I think it's time to outline my current vision for how I want Angband to look in the longer term. All of this is negotiable - I am prepared to abandon any of it based on solid argument.

This looks like a great list. I'd also add what someone previously suggested, which is pruning the monster list. I'd do this to get rid of or rebrand some painfully non-tolkien ones and to make the monsters that remain stand out from each other more.

[Timo Pietilä]

The core idea is that I want a shorter, more eventful, more dangerous game. Here are some of the things I envisage happening:

1. Forced descent will be the default option. As a consequence, in a standard game there will be no more than 99 levels generated before you meet Morgoth.

This alone was enough for me to absolutely hate Sil. I like playing the game at my own pace, slow or fast however I feel at the moment. I don't even go to other suggestions, because this would ruin the game for me no matter what you do to other things. Even if it is an option, game balanced for this could not possibly be better than any version before it.

[Nick]

Statement of Intent

I think it's time to outline my current vision for how I want Angband to look in the longer term. All of this is negotiable - I am prepared to abandon any of it based on solid argument.

The core idea is that I want a shorter, more eventful, more dangerous game. Here are some of the things I envisage happening:

1. Forced descent will be the default option. As a consequence, in a standard game there will be no more than 99 levels generated before you meet Morgoth.
2. The dungeon may be shortened.
3. Individual dungeon levels will be more interesting.
4. Some fights will be dangerous, and require the player to escape or die.
5. Some fights and/or traps will result in the player being effectively crippled, and needing to return to town to recover properly.
6. Ironman will be very hard to win.
7. The town will be primarily a place to recover rather than restock.
8. Every object will be useful to some character at some time; very few will be useful to any character all the time.

Achieving game balance while doing all this will be challenging, and at times the game will be unbalanced; at these times, I would rather err on the side of being too hard than too easy.

Where there is a choice of possible development paths to take (combat system is a prime example here), I would like to actually implement multiple possibilities for people to test and compare. That way I have informed feedback to ignore

All this said, I do want to ensure there is a good selection of birth options to cater for multiple tastes.

[krazyhades]

Much good will towards Nick and Takkaria.

[Timo Pietilä]

On a tablet, I imagine tapping in a direction to move and swiping to alter, or something like that. You'd also want something for 'run' as others suggested.

I agree.

Angband actual game-screen doesn't really have to have anything to click, it was designed to be controlled by keyboard after all. Forget mouse for touch-screen. Touch-control and mouse control are two completely different things.

You could add transparent command layer in top of the screen itself with base command sets, and even arrows for movement that just fades when you are not touching the screen. Entire screen area is usable for commands. You could even add "function keys" to bind keymaps to.

[half]

Reduce the pre-set keystroke commands to a bare minimum. For example, Replace quaff, zap(rod), aim (wand), use (staff), with a single "use object".

Sil has gone pretty far in the direction of a reduced keyset, getting rid of about half the Angband commands. Launching it and pressing '?' to see the command list could be useful. One big trick was extending the 'alter' method. All terrain squares you use when you are on (e.g. stairs, forges) can be used by control-5. Doors, chests, can be opened, walls can be tunnelled etc. V had some of this, but it turns out you can extend it quite a bit. On a tablet, I imagine tapping in a direction to move and swiping to alter, or something like that. You'd also want something for 'run' as others suggested.

[Nick]

OK, for those looking at how a mobile Angband could work, I encourage you to spend a few minutes exploring FAangband 1.1.6 (it's available here under Version 1.1); most people are unlikely to have a WinCE device to hand, so any of the desktop versions will serve to illustrate. Now, do the following:

1. Open and start the birth process for a new game, but DO NOT USE YOUR KEYBOARD, instead use the "mouse buttons" (the text in [] on the bottom centre-right - it's clickable). Exceptions - you may enter a name of your choice if you don't want to choose a random one, and there are one or two points in the birth process where I failed to add an enter button; you may use your enter key.
2. Once you start actually playing, STILL DO NOT USE YOUR KEYBOARD. The mouse controls include:
   • Click on the player name area to go to the 'C' screen
   • Click on the stats area to go to the inventory
   • Click on @ to get a menu of other actions
   • Click on a grid (within reasonable distance) to move there
   • Use the mouse buttons for the obvious purposes (note that new ones appear sometimes)
   • Once on the inventory (or equipment/floor), click on an item to get a menu of commands to use on that item
3. Now, imagine that rather than the dinky little text mouse buttons down the bottom, there is a toolbar with proper buttons, and that moreover you can add new buttons of your own for keypresses or keymaps of your choice.

This was a playable mobile version. So, you may ask, why don't we have an iOS and Android version of FAangband with this functionality already? Answers:

1. This relied on accurate menu selection, which really required a stylus (and everyone knows they suck, thank you Steve Jobs)
2. It also relied in rather a hacky way on where the tap/click was in the underlying Angband terminal structure; Psi and I were much more focused on playability than on a better menu system some time in the future
3. V at the time was rapidly changing, and those changes were making it harder to just grab the latest platform ports and other code improvements; at the time it seemed preferable to try and move FA to the V codebase and then reimplement the touch controls. In fact the first of those activities nearly killed FA and my enthusiasm for it, and the second never happened.
4. There was little apparent demand for it, probably because I was mainly listening to people on the forums who were already playing not on mobiles.
5. Related to the previous, I thought I might be able to get the requisite underlying code into V, but any discussion of stuff like allowing actions by selecting item-command rather than command-item fed into the whole "What's wrong with the game as it's always been you're ruining it" narrative which was going on at the time, and so in the end
6. It just all became too hard

I'm not quite sure how this post turned into my life story, but I'll stop now.

[nppangband]

I've given a good amount of thought about an iOS port and there are a number considerations that arise. A few have already been mentioned, but one of the most important for me is to be true to both the platform and the game. Some examples:

Toolbars, d-pads, and keyboards should be used judiciously.

That is challenging, I guess because Angband has so many commands. Definitely something to keep in mind, though. Maybe swiping can be the direction keys, but I worry about reliability. One move in the wrong direction can be instadeath in Angband.

The game internals that interact with ports need significant modernizing.

Good points.

Some gameplay elements just won't make sense. fizzix mentions a few, but the one that stands out to me the most is walking/running. I don't want to sit there swiping or tapping each time I want to move (except for combat and other tight situations). Running adds penalties that would just lead to more tapping or swiping. Instead, you just have pathfinding movement or you trace a path for @ to follow. Movement would be disturbed as it currently is so that you don't have stupid deaths. Fortunately, pathfinding movement is already implemented and path tracing wouldn't be too hard to implement. Both would need to be tuned, however.

I can see this for the explored areas of the dungeon (tap on a square and the character automatically walks to that location. The game has this with the mouse now) I would worry more about unexplored areas of the dungeon. It could send the character off in an unintended direction that could lead to unwanted danger. How does Brogue handle auto-exploring unlit areas of the dungeon?

[bio_hazard]

fwiw, Brogue is pretty playable on a tablet (iPad). It already had a simplifed ui ("apply" "equip" work across most classes of items), and previous design decisions have generally prevented the screen from being overwhelmed by too much junk. The whole map is always visible. I'm not sure it would translate directly to the complexities of Angband (e.g. large vaults and pits) but I think it works well in general.

[takkaria]

I actually aspire to go the most extreme route possible. I would try to use as little of the CORE code as possible, trying to take a fresh approach to user input and onscreen display that takes advantage of modern technology. I think the moment I start looking at converting old code I will be locked into the mindset that is how it should work. My radical first thoughts are that a significant part the source code should be eliminated and replaced. (all the main-xxx files, most of the ui files, most of the z* files)

Oh, I think you misunderstand what I mean by 'core'. I'm talking about the core game - not the z-term, not the ui code (which I've been splitting out into files called ui- just for this reason).

The way I'd do it (/ have been doing) is to start at the other end than you are - instead of starting at building a new UI, start by isolating the game code so that it assumes nothing about what is being displayed. Then you have an API that you can write a terminal version with, a QT verison, a HTML5 compiled version, whatever. Good luck, though - it sounds like AngbandTk reborn!

[molybdenum]

I've given a good amount of thought about an iOS port and there are a number considerations that arise. A few have already been mentioned, but one of the most important for me is to be true to both the platform and the game. Some examples:

Toolbars, d-pads, and keyboards should be used judiciously. I've played games that used these (including some roguelikes) and a lot of times, they end up being less than ideal. They take up screen space and may not be placed on the screen in a convenient way, given how I prefer to hold the device. Gestures are much nicer; if implemented correctly, you can reserve the entire screen for content and let the user perform the gesture wherever is most comfortable. Even with gestures, it may make sense to display some of these UI elements: displaying a d-pad when Angband asks which direction to fire something or a small toolbar of buttons for things that are macro-like (m1a or the like). Of course, it's difficult to know what the optimal arrangement would be without having a working game.

The game internals that interact with ports need significant modernizing. The shortest answer is that there needs to be an API that allows querying and modification of the game world/game state. takkaria's event system for input is a first step for that. However, there is no analog for game output, other than z-term. z-term is quite the dictator; it demands that you draw these characters at this location, right now. Ideally, the port itself would ask the game "hey, I need the tiles from (20, 20) to (30, 30)" (due to something like the game window being obscured for a moment). While this isn't too much of a problem on a desktop machine, on a mobile device this leads to a lot of waste, likely affecting battery performance. Also, based on the OS X port, Angband likes to commandeer the native application run loop. A normal OS X application will just sit in the native run loop, waiting for a key press, and reacting to it only when one actually shows up. Angband, however, is aggressively polling the event loop for new events. This will likely confuse iOS into thinking that the app is doing real work and kill the battery even more. A general API also makes it much easier to transition to "gridless" version of the game.

Some gameplay elements just won't make sense. fizzix mentions a few, but the one that stands out to me the most is walking/running. I don't want to sit there swiping or tapping each time I want to move (except for combat and other tight situations). Running adds penalties that would just lead to more tapping or swiping. Instead, you just have pathfinding movement or you trace a path for @ to follow. Movement would be disturbed as it currently is so that you don't have stupid deaths. Fortunately, pathfinding movement is already implemented and path tracing wouldn't be too hard to implement. Both would need to be tuned, however.

These are are just a few things I've thought about. My general conclusion was that I'd probably treat an iOS port as a variant first, since a lot would need to change.

[nppangband]

What kind of level of abstraction are you thinking of? Because V's command and event system are the beginnings of something that could be really workable: you just have to change every place in the core code that wants to make a UI update to signalling an event, and moving the screen update code into an event handler. Then for each frontend you just have to write a different set of command handlers ("just").

One way to create the split on a practical level would be to #define CORE in core files, and then make sure all UI files are surrounded by #ifndef CORE, so you can't compile a file until you've removed all references to the UI code.

I actually aspire to go the most extreme route possible. I would try to use as little of the CORE code as possible, trying to take a fresh approach to user input and onscreen display that takes advantage of modern technology. I think the moment I start looking at converting old code I will be locked into the mindset that is how it should work. My radical first thoughts are that a significant part the source code should be eliminated and replaced. (all the main-xxx files, most of the ui files, most of the z* files,

Of course, we will see what I actually do and have time for when I start to work on this, but my thoughts are:

* Completely agree, the command and event system is going to be key to this. It is a shame that a couple years ago somebody hacked into my account on oook and posted something here critisizing it.

*What I want to do is start building a main.c from scratch and start putting in the necessary functions. First start with opening a window and displaying the start screen. Then work on a dedicated window to display the dungeon. Work on functions to place the appropriate images directly onscreen given a set of dungeon coordinates. Then experiment on how to place the most useful information directly on the screen. Perhaps small monster health bars right over each monster. Then work on things like redrawing the screen when a monster moves or after project() is called. Then put all text messages into a separate, scrolling window. In short, I will first work in screen display while brainstorming on potential ways to do input.
* Offer the player a list of toolbars, such as
1) available commands not related to objects (tunnel, search, save, exit, go up/down stairs when appropriate, look, target, etc)
2) equipment (right click to get a menu of available actions for that item. NPP already has noun-verb commands for individual items. Each object kind can have a "default" action assigned to it, so all you have to do is left-click on a tile of a potion to quaff it. Should be able to "mouse-hover" over the item to get a description pop up on-screen. Same for an dungeon square on-screen - the player should be able to get a list of all monsters/items/features on that square)
3) inventory and quiver (same as above)
4) floor items (same as above - maybe toolbar only pops up when the player is standing on an item)
5) a toolbar where the player can assign macros.

Give the main dungeon screen 3-4 tabs, for the dungeon, character screen, detailed inventory info, detailed equipment info, etc.

Then I will start working on the commands. I think most commands that are infrequently used can be put in the top menu bar and/or the toolbar, without an assigned key-stroke (but give the player the option to assign one if they want to). Examples of this would be the options screens, knowledge screens, "take notes" option, inscribe an object, etc>.

Reduce the pre-set keystroke commands to a bare minimum. For example, Replace quaff, zap(rod), aim (wand), use (staff), with a single "use object".

For input on a tablet, I would think that the inventory/equipment/object command toolbars would be key. Also, have a direction pad with 8 arrows for movement. It could be toggled into different modes that cover all available direction commands not related to objects (move, run, search, attack (without moving), tunnel, etc).

Of course, I would expect that feedback and suggestions from the players and other developers woudl produce better ideas or improvements on pretty much everthing I typed above. Particularly those players who play other roguelikes that already have a better user interface.

And, also, of course, those plans will be altered when I actually start coding and actually understand how much of my ambitious plan won't actually work.