-
-
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.One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.Comment
-
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?Comment
-
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.Comment
-
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?Comment
-
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.Comment
-
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:- Various areas of the sidebar corresponded to commands and
- 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.One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.Comment
-
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.NPPAngband current home page: http://nppangband.bitshepherd.net/
Source code repository:
https://github.com/nppangband/NPPAngband_QT
Downloads:
https://app.box.com/s/1x7k65ghsmc31usmj329pb8415n1ux57Comment
-
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.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.One for the Dark Lord on his dark throne
In the Land of Mordor where the Shadows lie.Comment
-
NPPAngband current home page: http://nppangband.bitshepherd.net/
Source code repository:
https://github.com/nppangband/NPPAngband_QT
Downloads:
https://app.box.com/s/1x7k65ghsmc31usmj329pb8415n1ux57Comment
-
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.Comment
-
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.takkaria whispers something about options. -more-Comment
-
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).Comment
-
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.
NPPAngband current home page: http://nppangband.bitshepherd.net/
Source code repository:
https://github.com/nppangband/NPPAngband_QT
Downloads:
https://app.box.com/s/1x7k65ghsmc31usmj329pb8415n1ux57Comment
Tweet
Comment