Tears unnumbered ye shall shed

[TJS]

Not much. Frankly, angband can be "mobilized" but it needs to be an almost entirely different game. Here's what needs to be done.

Game allows 9 "hotkeys" Inventory screen allows you to drag items (also equipment/spells) to the hotkey locations. In addition, sidebar boxes allow you to do things like rest, access inventory, or situation relevant commands like closing/opening doors, disarming traps, etc.

Map needs to be zoomed in enough that you can reliably click on a location to move there, but zoomed out enough that you can see dangerous monsters nearby. This may require a massive retooling of monsters and ranged behavior beyond just the "halve max_range" option.

It's really tough, it might need to be a new game altogether. IMO it's probably better to redesign an angband-inspiried mobile game from scratch.

I've been playing a bit of Pixel Dungeon for tablet and while it is a much simpler game than Angband I think a number of things can be copied from its UI.

You select items from your inventory by clicking on them and then you get a list of actions you can perform.

If you want to examine anything you click a question mark icon and then the square on the map or item in your inventory.

You can freely zoom in and out of the map to make it easier to select particular squares. PD is designed to display less of the screen at once though so a solution to that problem in Angband would have to be found for choosing a particular square with each square being much smaller.

Perhaps you zoom in when clicking the screen rather than immediately making your move and then that allows you to make a more accurate selection. A run button could be clicked first to skip that step.

A lot of these controls could be used on a PC too if you wanted to play using the mouse.

When I started playing Angband by far the most difficult hurdle I found was in learning all the key commands. A UI that is built from the ground up to be playable by different types of devices would be ace (although probably loads of extra work).

[takkaria]

Do you have any thoughts on how to approach it yet? A little brainstorming on how to approach it would probably help both of us.

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.

[Gorbad]

There was also work done on the Nintendo DS port (initially fro FA, but then also for V) by Immir, including things like overlay buttons and zooming.

I'm quite hopeful about getting a decent mobile port eventually.

Might I also point back to the immensely good port on Android: http://angdroid.org/

It can certainly use some tweaks, like the mentioned hotkeys, or a configurable keyboard, but all in all this is *very* playable, even on a Galaxy S3, with not too much screen real-estate.

Please steal as much as you can from their efforts, and eventually a Core/UI split should mean that any new version of Angband can be ported with minimal effort.

[nppangband]

I'm inclined to agree - I think phones are doable, but tablet are a really obvious goal.



I like the idea of NPP and V doing this independently, then trying to combine the two approaches.

Do you have any thoughts on how to approach it yet? A little brainstorming on how to approach it would probably help both of us.

[Nick]

Just a thought. I know smartphones are a good goal, but I propose tablets as a good intermediate step. With a good UI the screen is large enough to display enough information for a game of Angband.

I'm inclined to agree - I think phones are doable, but tablet are a really obvious goal.

I am going to make a serious attempt at a QT port with a completely different GUI and screen display for NPP, but I should hopefully be able to do it in a way that it is easily transferreable to other *bands.

I like the idea of NPP and V doing this independently, then trying to combine the two approaches.

[nppangband]

I think I've been unclear again - maybe someone else can explain it better.

I will try....

It is pure rubbish. {The end}

Seriously, the core of the entire angband display was based on the assumption of an 80x24 screen, and processor speeds and memory constraints that computers had in the late 80s. Not bad for its time, but with the exception of some minor tweaks it has never been seriously revisited.

Just a thought. I know smartphones are a good goal, but I propose tablets as a good intermediate step. With a good UI the screen is large enough to display enough information for a game of Angband.

I am going to make a serious attempt at a QT port with a completely different GUI and screen display for NPP, but I should hopefully be able to do it in a way that it is easily transferreable to other *bands.

[Nick]

Angband's verbose command list is going to be hard to squeeze into mobile. It's going to take some
a) trimming & consolidation of commands
b) genius interaction design

Have you guys talked about this sort of thing before?

Actually a few years back Psi and I combined to make a pretty playable port of FAangband to WinCE devices (HP iPaq, and things like that). It still had a pretty standard main screen, but we had two key features to improve command entry:

1. Various areas of the sidebar corresponded to commands and
2. You could select an item, then what to do with it, rather than the reverse.

This second one was really the critical bit, because once you have chosen an item the list of possible commands cuts right down. We had a software keyboard available, but regarded it as a failure every time that had to be used.

As an example which I never tire of quoting, this epic game was played in FAangbandCE.

There was also work done on the Nintendo DS port (initially fro FA, but then also for V) by Immir, including things like overlay buttons and zooming.

I'm quite hopeful about getting a decent mobile port eventually.

[MattB]

So there's one library that works on mobile as well as the old systems.

...And in the darkness bind them.

[fizzix]

If we're talking Mobile, then one of the main barriers is going to be input vocabulary, i.e. no keyboard.

Previous ports of RLs to mobile basically just end up being museum pieces because they aren't playable. This is almost entirely due to having 30 keyboard based commands and no good way to enter them.

Angband's verbose command list is going to be hard to squeeze into mobile. It's going to take some
a) trimming & consolidation of commands
b) genius interaction design

Have you guys talked about this sort of thing before?

Not much. Frankly, angband can be "mobilized" but it needs to be an almost entirely different game. Here's what needs to be done.

Game allows 9 "hotkeys" Inventory screen allows you to drag items (also equipment/spells) to the hotkey locations. In addition, sidebar boxes allow you to do things like rest, access inventory, or situation relevant commands like closing/opening doors, disarming traps, etc.

Map needs to be zoomed in enough that you can reliably click on a location to move there, but zoomed out enough that you can see dangerous monsters nearby. This may require a massive retooling of monsters and ranged behavior beyond just the "halve max_range" option.

It's really tough, it might need to be a new game altogether. IMO it's probably better to redesign an angband-inspiried mobile game from scratch.

[mrrstark]

I'd expect that the first revision would be exactly as it is now. This would allow fine tuning of the calls between the UI and the core/base code.

Once the UI is stable I expect various people will take the UI code and innovate with it to create a mobile UI, better desktop UI, etc, with various ideas moving between the various UI platforms. Having the UI code completely separate from the core of the game would significantly lower the complexity of modding the UI, even to the point of creating completely separate UI mods. Once you move away from the restriction of a(n enforced) terminal UI, then just about anything would be possible.

This also has the added bonus that anyone who forks a variant from the new base code would just need to maintain the same API to the UI to instantly have access to the various UIs.

If we're talking Mobile, then one of the main barriers is going to be input vocabulary, i.e. no keyboard.

Previous ports of RLs to mobile basically just end up being museum pieces because they aren't playable. This is almost entirely due to having 30 keyboard based commands and no good way to enter them.

Angband's verbose command list is going to be hard to squeeze into mobile. It's going to take some
a) trimming & consolidation of commands
b) genius interaction design

Have you guys talked about this sort of thing before?

[Carnivean]

Ok so as I understand it, the bit where it is decided what needs to be drawn is going to be separate from the bit that actually draws to the screen.

I was just wondering about the actual drawing bit, is that going to change and if so is it going to work on the newer platforms such as mobile?

I'd expect that the first revision would be exactly as it is now. This would allow fine tuning of the calls between the UI and the core/base code.

Once the UI is stable I expect various people will take the UI code and innovate with it to create a mobile UI, better desktop UI, etc, with various ideas moving between the various UI platforms. Having the UI code completely separate from the core of the game would significantly lower the complexity of modding the UI, even to the point of creating completely separate UI mods. Once you move away from the restriction of a(n enforced) terminal UI, then just about anything would be possible.

This also has the added bonus that anyone who forks a variant from the new base code would just need to maintain the same API to the UI to instantly have access to the various UIs.

[TJS]

Oh, I see (I think). There are certainly system-specific parts of the code, but there is also a large amount of low-level code (some of it collected together, some sprinkled throughout) which handle directly the format of what goes to the screen (kind of a terminal emulator, in a really non-technical way). The system specific code mostly just translates that into "how do I actually draw this string of letters (or tiles) on the screen". The idea is that can all be separated out, and so individual system ports no longer need to use the low-level code.

I think I've been unclear again - maybe someone else can explain it better.

Ok so as I understand it, the bit where it is decided what needs to be drawn is going to be separate from the bit that actually draws to the screen.

I was just wondering about the actual drawing bit, is that going to change and if so is it going to work on the newer platforms such as mobile?

[Nick]

Sorry I'm still a little confused. If the code is not tied to any system then how does any system actually run it? Surely at some point you have to use an engine that actually draws stuff to screen that works on particular systems (and possibly not others).

Oh, I see (I think). There are certainly system-specific parts of the code, but there is also a large amount of low-level code (some of it collected together, some sprinkled throughout) which handle directly the format of what goes to the screen (kind of a terminal emulator, in a really non-technical way). The system specific code mostly just translates that into "how do I actually draw this string of letters (or tiles) on the screen". The idea is that can all be separated out, and so individual system ports no longer need to use the low-level code.

I think I've been unclear again - maybe someone else can explain it better.

[TJS]

I'm sure a lot of the existing code will survive into any new UI/display, but I think being in principle not tied to any of it is a good idea. For example, touch-screen phones would have trouble fitting in any decent amount of map in a readable way, so a port would have to make creative use of zooming and sliding; I have the feeling that the existing UI/display makes assumptions that would make trying to do that very difficult.

I also think that a big restructure is a great time to remove things that were done to satisfy constraints that no longer exist.

Sorry I'm still a little confused. If the code is not tied to any system then how does any system actually run it? Surely at some point you have to use an engine that actually draws stuff to screen that works on particular systems (and possibly not others).

[Nick]

Yes I guessed that would be the case, I sorta was getting at whether the new display and UI libraries be written so they could be exported to mobile without having to rewrite them using a different engine.

So there's one library that works on mobile as well as the old systems.

I'm sure a lot of the existing code will survive into any new UI/display, but I think being in principle not tied to any of it is a good idea. For example, touch-screen phones would have trouble fitting in any decent amount of map in a readable way, so a port would have to make creative use of zooming and sliding; I have the feeling that the existing UI/display makes assumptions that would make trying to do that very difficult.

I also think that a big restructure is a great time to remove things that were done to satisfy constraints that no longer exist.