Tears unnumbered ye shall shed

[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.

[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!

[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.

[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?

[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.

[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.

[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.

[krazyhades]

Much good will towards Nick and Takkaria.

[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.

[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.

[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.

[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]

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.

[Nick]

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

Challenge accepted!

[nppangband]

[*]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.[*]Some fights and/or traps will result in the player being effectively crippled, and needing to return to town to recover properly.[*]The town will be primarily a place to recover rather than restock.

Does this mean if you go to the town, when you return to the dungeon you would be forced to go down to the next level?