Angband and the roguelike community

[AnonymousHero]

- Autoexplore

See that's a problem right there. If there is such a thing as autoexplore you've already given up on trying to make the game maps (and exploration in general) interesting. It's a technical solution to a non-technical problem.

[wobbly]

@autoexplore:
The danger of autoexplore is it means if the player wants it, then exploring the level isn't interesting or dangerous enough. It's hard for me to describe exploring angband levels as interesting, with mapping and monster detection playing such a promising role. I do think that making stuff more interesting here is the better choice. Angband has another good reason to avoid the autoexplore route. The games that have autoexplore assume that you're going to clear every level. Angband encourages you *not* to clear every level. It encourages you to run away when things get too hot.

Agree, I'll just add to it my biggest dislike of autoexplore, a loss of atmosphere. I no longer feel like I'm exploring a dungeon, more like I'm playing an arena style game.

@tome's monster types:
tome has huge spam problems of all sorts. This is just one aspect of it. There's too many things going on that to read all the messages is impossible. So you don't. It could really do well by trimming stuff, but that's not Darkgod's style. It is nice in Angband that you know that the green g is a monster to avoid. You don't have to do a bunch of clicking and examining to figure out if something is dangerous or not.

Actually you can tell by the colour, it's too long since I've played to remember exactly but it's something like a coloured box or bar on uniques/bosses. If you play enough you can usually tell what a monster can do by simply mousing over it & looking at the sustains. Same with the message spam, you learn what you can safely ignore & what you have to read.

[wobbly]

As far as attracting new players goes, personally if I'm sick of a roguelike I'm playing & would like to try another I search the net. Typing in roguelike in to google a moment ago gave me:

1. Wikipedia - roguelike
2. Rogue Basin

Both have reasonably prominent hyperlinks to angband. (I originally came to this site through rogue basin doing the above)

[half]

I like Tome4 for the class variety, but, Tome4 gameplay can be boring generally, IMO, for these reasons:
- Autoexplore
- Meaningless monster variation desensitizes
- Entirely cooldown based play

What great analysis! (and fizzix's too!) Autoexplore and randomized monsters are exactly the kind of thing that procedural game programmers think might be really cool and then try to implement and it is great that we can learn from others' experience on whether it actually leads to fun play before implementing it.

I've considered whether to add autoexplore to Sil and decided against it for similar reasons. I'd *like* to have it as an option for people who've come to require it in games, but I think others would end up using it despite it making their game experience worse.

I'm really impressed by the quality of this thread!

[LostTemplar]

In general, there is a common design flaw in many roguelikes appearing after mutiple windows, monster lists, etc. become popular. Such a features while are usefull and may be nice should allmost never be required to play. All important decisions should be possible just by looking to the main screen. If, monster list / character screen / inventory / spoilers / web site or something else is being open and looked into all the time, it is possibly a sign of bad design.

[evilmike]

See that's a problem right there. If there is such a thing as autoexplore you've already given up on trying to make the game maps (and exploration in general) interesting. It's a technical solution to a non-technical problem.

DCSS might have the most varied map generation of any roguelike, along with a massive number of vaults... I'm not even sure how many there are but it's in the thousands. Autoexplore isn't in the game to get around a problem of uninteresting level design - the dungeon is about as interesting as it can get, and there are people who play the game mostly without autoexplore and enjoy it. To give you an idea of some of the variety, I've put together a small album of crawl minimaps: http://imgur.com/a/o4Ay6

So, there's a question, why does the game even need it? Well, a huge part of DCSS is about streamlining the hell out of the interface and automating things which some people find boring. Autoexplore only works when no enemies are in the area, and basically autotravels to points of interest which the player would manually go to anyway. It will walk to and pick up items for you, and it will move towards unexplored parts of the map which you would manually go to anyway. Other examples of features like this are autofight (does a basic melee or ranged attack on keypress), autotravel (go to any point in the dungeon), and the stash tracker (ctrl+f to find any seen item in the dungeon).

I do not believe every roguelike is suited to autoexplore. It's a feature that works best for a game like Crawl which has large persistent levels, a relatively small and symmetrical LOS radius (only 8 squares), extremely limited monster detection/magic mapping, and a complex branching dungeon. None of this describes Angband, where autoexplore wouldn't make a lot of sense (it would at the very least need to be smart enough to deal with out-of-sight monsters... something which is far less tactically relevant in Crawl).

Thus, I don't think autoexplore is needed in Crawl. But it's useful enough that its existence is justified, and that's all that is really needed.

[fizzix]

DCSS might have the most varied map generation of any roguelike, along with a massive number of vaults... I'm not even sure how many there are but it's in the thousands. Autoexplore isn't in the game to get around a problem of uninteresting level design - the dungeon is about as interesting as it can get, and there are people who play the game mostly without autoexplore and enjoy it. To give you an idea of some of the variety, I've put together a small album of crawl minimaps: http://imgur.com/a/o4Ay6

So I pretty much agree with this assessment. I would argue that what angband needs is a smarter run command rather than an autoexplore. You give a shift+dir and it runs in that direction for some number of steps (make it user configurable). It's smart enough to find room exits and stop at corridor forks (run already is able to do this last one).

I also agree that crawl has some interesting maps. It also has some dud maps. And some maps that are a pain to deal with without autoexplore. Also, in many situation autoexplore is smarter than moving, since if you stop, you know you should look at something. This keeps you from taking several steps towards a powerful ranged caster before you realize that you should not be heading in this direction.

If we were going to pick something from crawl that I'd like imported it would be the spell casting and item activation interface. Allow you to specify what keys everything goes on. This seems like a big win.

[Nick]

If we were going to pick something from crawl that I'd like imported it would be the spell casting and item activation interface. Allow you to specify what keys everything goes on. This seems like a big win.

I'm glad you said that, because it gives me a chance to mention code restructure again. Remember that? That's what's happening right after 3.5 comes out. For ages. Before any new features or gameplay.

But the thing is that one of the big aims of that is to allow new interfaces to be written so that one could, say, have crawl-style key use for items and spellcasting. I'm envisaging that once the current interface is distinct from the game core, two things will happen:

1. There will be modifications made to the existing interface and
2. Some one or ones will write a whole new interface or interfaces.

This will actually free the whole business up and allow us to find what sort of interface actually works well for the modern game. Now I just hope all that actually happens...

[evilmike]

Also, in many situation autoexplore is smarter than moving, since if you stop, you know you should look at something. This keeps you from taking several steps towards a powerful ranged caster before you realize that you should not be heading in this direction.

The shift+move functionality covers this nicely. Baiscally, it's the usual "run" command that every roguelike has. But, if you try to use it when an enemy is visible, it will print a message in red text ("an orc is in view!") and fail. Since running is also interrupted by enemies, this means it's a safe way to move around. Basically anything that interrupts/blocks autoexplore will also interrupt/block shift+move (or any other travel command).

The way shift+move simply fails is actually something I'd like to see in other roguelikes. As far as I can tell, the behaviour in most games is to simply move one square if a monster is visible, rather than fail outright. That's not a bad thing, but I think it's a bit more prone to miskeying.

[fizzix]

This will actually free the whole business up and allow us to find what sort of interface actually works well for the modern game. Now I just hope all that actually happens...

Yeah. Let's hope so.

Just to make sure, we're going to be assuming keyboard input for angband, right? No thoughts of redesigning to make it a tablet/phone game...

[LostTemplar]

IMHO it can be assumed, that Angband should use command based interface. Keyboard or on screen buttons, or even some menus make no difference. No poiner input is needed for angband, at least as a game control UI. Some pure UI stuff may be nice, e.g. pointing to monster may show it's recall information.

[Nick]

Just to make sure, we're going to be assuming keyboard input for angband, right? No thoughts of redesigning to make it a tablet/phone game...

Um, the short answer is no and yes, but that's misleading.

I suspect that in practice it's going to be really difficult to get sufficient control without using a keyboard; even with various cutdowns that can be done on item-handling commands, for example, there are still rather a lot of genuinely different commands. But I wouldn't say it's impossible, and I wouldn't rule out someone coming up with a quite playable tablet interface at least, using some combination of buttons/gestures/accelerometer/voice input/whatever.

The basic fact, anyway, will be that the game core accepts commands from the UI; any individual UI can accept those commands however it likes, as long as it translates them cleanly into core-speak.

[LostTemplar]

The basic fact, anyway, will be that the game core accepts commands from the UI; any individual UI can accept those commands however it likes, as long as it translates them cleanly into core-speak.

Btw good place to start may be clear split between game commands and UI commands, e.g. display monster list or scroll up message log are UI commands, while casting a spell is a game command. These two type of commands should be processed separately. I have done this in my roguelike, because I have a replay feature and only game commands are saved in replay. However even without replays such a split will help a lot. Angband currently have very entangled command set. Another thing to do at the beginning, IMHO is to get rid of callbacks in menu functions (if they are still present). In general all the interface functions should only take simple data as parameters, no structs or function pointers.

[nppangband]

Um, the short answer is no and yes, but that's misleading.

I suspect that in practice it's going to be really difficult to get sufficient control without using a keyboard; even with various cutdowns that can be done on item-handling commands, for example, there are still rather a lot of genuinely different commands. But I wouldn't say it's impossible, and I wouldn't rule out someone coming up with a quite playable tablet interface at least, using some combination of buttons/gestures/accelerometer/voice input/whatever.

The basic fact, anyway, will be that the game core accepts commands from the UI; any individual UI can accept those commands however it likes, as long as it translates them cleanly into core-speak.

A tablet interface shouldn't interfere with the keyboard commands in the slightest. It would probably just have a whole new set of commands that could be done with a touchscreen. (icons, toolbars, dialog menus, swipe commands, etc) For example, a swipe up from the bottom will bring up toolbars for all the objects the equipment, inventory, quiver, and floor. The player can assign a default command to each object kind that happens when the icon for each item is tapped (quaff a potion of CCW, or fire arrows from the quiver), or they can hold down on the icon for a second to on the object icon to get a menu of commands. For ttargeting, the player can double-tap on a square to target it, or hold down on that square for a second to get an info window with the contents of that square. That would take care of probably 20+ commands on a tablet interface, and nothing has to be taken away from the keyboard to accomplish it.

After about 6 weeks of studying QT and C++, I am about to break ground on a QT port with a whole new front-end for NPP, although I am wiping out all old ports in the process. I suspect probably at least half of the current codebase should be replaced. But the keyboard inputs shouldn't have to change. I can see combining several commands, and making full use of ctrl, and alt commands so that there is no longer a to maintain the original AND roguelike keyset.


Among other things I am going to upgrade in this new port:

*Switch to Unicode fonts.
*Allow the game to display the complete 0-255 RGB color spectrum. No need to limit the game to 16 or 30 colors.
*Separate displaying tiles from displaying ASCII characters (the hack that has all tiles in the 128-255 registers of the ASCII character set).
*Allow different size fonts and tilesets to be displayed onscreen simultaneously.
*Have a committed space onscreen for the dungeon that is only drawn over in special situations, such as when the player enters the store, or presses the equipment or inventory command. All other prompts can take place with pop-up windows and dialog boxes. If anyone has seriously studied the code that actually displays letters and tiles onscreen, it is in bad need of replacement. The game has absolutely no idea what is onscreen at any given time, and it makes up for it by drawing everything multiple times. Changes should be drawn onscreen instantly, and left there unless a complete screen refresh is taking place.

Probably lots more as I go. There is just way too much code that has done untouched for decades that was written for computers 5-6 generations ago. At least for NPP, I am ready to take a bulldozer to it. With QT, it won't be that hard to build a new front-end. It is quite powerful once you get used to it.

[Nick]

I am about to break ground on a QT port with a whole new front-end for NPP

I don't know where you're planning to start from, but the last few posts in this thread may be relevant.