User interface in Angband 4 (feedback requested!)

[takkaria]

Hello all,

I've written a blog post on what I'm planning to do with Angband in terms of user interface by the time Angband 4 rolls around. You might want to read it here, but the main point I would like feedback on is the direction of the game user interface:

I want there to be two user interfaces: a "classic" terminal-emulator style UI and a graphical interface which is usable with both mouse and keyboard.

For the graphical interface, I have no intention of dropping ASCII as the default display mode, but I think there's a lot of things that can be done that break away from displaying everything on a rectangular grid which would make the game more playable: borders around menus, better animated spell effects, better tiles, zoomable maps, variable-width fonts for monster/object descriptions, etc–quite like what the amazing ToME 4 is doing, I guess.

Angband 4 will be as incompatible with existing variant code as Ben Harrison's Angband was to the variants that came before it. There will be pretty much no easy way to port code across from V4 to variants because of how deep the display assumptions in the code are. This makes me sad, but sometimes good things are painful to go through.

Why do I want these things? Well, if we want convincing handheld ports (and I do), at some point the game logic has to be decoupled from its display. The approach outlined above could result in extremely playable Android or iPhone ports, without worrying about virtual keyboards, and making use of native UI on those devices (without adding a load of hacks into the game proper).

It will also be more user-friendly, easier on the eyes, and more newbie-friendly, all of which I rank highly for the game's survival.

It would be good to know before any of the above kicks off in a serious way: would you want to play a game that had more graphical touches than the game does at present? Would it put you off? What would you like changed? Where do you want to see Angband's interface go—or would you rather it stay right where it is?

[Nick]

The only note of caution I would sound is that slowdown on the Nintendo DS is sometimes noticeable, because of the little CPU/memory. Getting a better handheld experience is going to be hamstrung a bit if the enhanced graphical features make the game run like glue.

On the other hand, it may be that by the time Angband 4 comes along handhelds are going to be easily able to deal with the new graphics.

[AnonymousHero]

Disclaimer: I haven't really been playing vanilla Angband very much, but I have played a lot of variants quite extensively and have sort-of maintained ToME 2 for a while.

As a player:

I've always been an ASCII kind of guy, but I think I'd appreciate a more modern interface in other respects. E.g. there's no particular reason to use non-proportional fonts for display anywhere else than the map. (Well maybe the character sheet, but if it's just for alignment then it can be done in better ways.)
Not sure about graphical effects/animations while still using ASCII for "tiles", but I guess I could get used to it (or just turn them off).

As a developer:
Given my lack of knowledge of the internals of Angband, I'm not sure how qualified I am to comment. FWIW, I do have extensive development experience (in a variety of languages) outside of Angband.

Separating the game logic and display seems like a good idea overall, but I think you might want to avoid having all the display logic in the code of each front-end -- it's hard to tell from your diagram exactly what the intention is here. Doing so may make the overall system more brittle with respect to changes in internal structures (and thus more resistant to change). Maybe have a separate "display module" which can take care of high-level display logic, such as e.g. assembling all the bits needed to display a character sheet into a form which is general and yet more useful to a front end than just a pointer to the player struct. The "terminal" abstraction may also still prove useful for the display of the main dungeon. (etc.).

Most importantly though: Do NOT make the mistake of going for a "rewrite" type transition. Even if a more gradual transition is more work in total(*) it WILL be worth it. Any "rewrite" type transition requires an enormous amount of motivation in general and they almost never succeed in practice because very few people will be using your buggy,slow,only-works-on-platform-X intermediate when they (as they perceive it) can just keep playing the old stable version until the new shiny version is done. Therefore I think it's crucial that any such radical refactoring/rewriting goes in stages where each stage becomes part of an official downloadable, pre-built version.

(*) I'm not necessarily convinced that that is the case, but I'll grant it for the sake of argument.

Question

Are you intenting to keep using C? I'm quite curious to see how you'll pull this off in terms without the niceties of an OOish language (polymorphism, interfaces, etc.). I'm well aware that these things can technically be achieved, but everywhere I've seen it in C the code has reeked. (Yes, that very much includes GObject/GLib/GTK.)

Conclusion

Whatever you decide: Good luck!

[Timo Pietilä]

It would be good to know before any of the above kicks off in a serious way: would you want to play a game that had more graphical touches than the game does at present? Would it put you off? What would you like changed?

No I wouldn't play it. Yes, it would put me off. If you want awesome UI check the Sangband UI. ASCII, but way better than terminals.

EDIT: looked at the ToME screenshots and they look just horrifyingly ugly. Hideous. blech.

EDIT to EDIT: If you go that way, I would put up a vote for new angband maintainer. What you would be doing is a variant.

[Mimu]

I'm not sure variable-width fonts are really necessary. They're troublesome to implement smoothly compared to a fixed font grid. It's not like a fixed-width font is particularly hard to read at present. Having multiple font types will also make interface elements seem more detached, which may not be desirable.

I wouldn't like mixing outright graphical elements with an otherwise character-graphic display. But then, there were some neat effects in TOME 2, delayed and impressive spells all animated in plain ASCII. I'd love those. The tidal wave surging outward from the @ was particularly cool. Sangband had one or two flashy spells as well. Adding menu borders using same fixed-width character graphics would be perfectly fine, although that might mean adding an extra character row for the border on top and below any menu or list, which could be problematic on 25-row or shorter displays.

But if going the truly graphical way, why not consider adding an isometric tile mode right into Vanilla? Assuming a retro-3D frontend is out of the question.

Modularising input and output is certainly a good goal. Vanilla already feels pretty nice from a user's point of view, but in view of future extendability, refactoring sounds very useful.

[takkaria]

No I wouldn't play it. Yes, it would put me off. If you want awesome UI check the Sangband UI. ASCII, but way better than terminals.

EDIT: looked at the ToME screenshots and they look just horrifyingly ugly. Hideous. blech.

EDIT to EDIT: If you go that way, I would put up a vote for new angband maintainer. What you would be doing is a variant.

Note that I explicitly want to keep "a "classic" terminal-emulator style UI" (as mentioned in the original post and the quote) where everything is on a nice rectangular text-only grid, as it is now. Hopefully you wouldn't have to vote for a new angband maintainer in that case...

[takkaria]

The only note of caution I would sound is that slowdown on the Nintendo DS is sometimes noticeable, because of the little CPU/memory. Getting a better handheld experience is going to be hamstrung a bit if the enhanced graphical features make the game run like glue.

On the other hand, it may be that by the time Angband 4 comes along handhelds are going to be easily able to deal with the new graphics.

Interesting. I wouldn't see any problem in the DS having some of its own display code that was optimised for the DS... I hope that will be possible with the model I'm taking without making the code much messier.

[ekolis]

I for one don't play roguelikes (or any other tactics game) with the mouse... even Crawl and Tome4, I still play with the keyboard, and Advance Wars and Final Fantasy Tactics A2 I play with the dpad and buttons, not the DS touchscreen, and Grotesque Tactics: Evil Heroes? Ugh, why do I have to use the mouse to do anything useful?!

So whether you add a super-duper mouse interface is irrelevant to me, as long as the keyboard interface is not impacted negatively!

As for graphics, I do have to say that graphics when done WELL are not bad - see Crawl for an example of this; perhaps you could even import some of Crawl's CC-licensed tiles? (Never understood why more games don't use those awesome tiles!) But bad mspaint-style graphics and "font soup" (sorry DarkGod, I'm looking at Tome4) are a bit of a turnoff, I'll have to admit! What I mean by "font soup", by the way, is a mishmash of a ton of different fonts and text sizes within the same game. If you're using more than two or three fonts, you're doing it wrong! And that includes bold and italic versions of the standard font as if they were separate fonts! Again, Crawl does this well, but Tome4 does this... not so well :P

Not that I want to bash entirely on Tome4 here - it does have a lot of neat concepts, like hotkeys for abilities and spells (why do I have to type maa to cast magic missile all the time in Angband?!), auto-targeting (Crawl does this too - instead of starting spells with no target and requiring you to choose one manually, it starts with the nearest reasonable target - usually an enemy, but yourself or an ally in the case of healing spells!), and all sorts of abilities and effects you wouldn't normally find in roguelikes, and might instead find only in WoW or Torchlight (warrior abilities that give knockback effects to your attack? spells with cooldown times as well as mana costs? large-scale graphic effects like alchemical explosions?)

So... yeah, if you can pull off this separation of GUI logic from game logic, without messing up the core gameplay of Angband, that would be awesome... who knows, it might even lead to a pseudo-client-server model for the game, which means that you'd have an "Angband core" (AngbandBase anyone? ) with the basic game logic, an "Angband game module" with the more advanced game logic (essentially a "mod" for the game), and a plethora of "Angband GUI modules", each with its own graphical representation of the concepts in the core, and varied support for display of the advanced concepts found in the mods! And that could in turn lead to a number of things... a revival of Mangband... a core written in C, with mods and GUI's written in ANY language whatsoever (imagine a Python or C# or Java GUI... or even a web-based GUI for easy access to online servers!)

[takkaria]

As a developer:
Given my lack of knowledge of the internals of Angband, I'm not sure how qualified I am to comment. FWIW, I do have extensive development experience (in a variety of languages) outside of Angband.

Separating the game logic and display seems like a good idea overall, but I think you might want to avoid having all the display logic in the code of each front-end -- it's hard to tell from your diagram exactly what the intention is here. Doing so may make the overall system more brittle with respect to changes in internal structures (and thus more resistant to change). Maybe have a separate "display module" which can take care of high-level display logic, such as e.g. assembling all the bits needed to display a character sheet into a form which is general and yet more useful to a front end than just a pointer to the player struct. The "terminal" abstraction may also still prove useful for the display of the main dungeon. (etc.).

For more information on the plans, there is a more technical version (with another diagram!) on Trac. Sounds like you'd approach it similarly to how I am.

Most importantly though: Do NOT make the mistake of going for a "rewrite" type transition. Even if a more gradual transition is more work in total(*) it WILL be worth it. Any "rewrite" type transition requires an enormous amount of motivation in general and they almost never succeed in practice because very few people will be using your buggy,slow,only-works-on-platform-X intermediate when they (as they perceive it) can just keep playing the old stable version until the new shiny version is done. Therefore I think it's crucial that any such radical refactoring/rewriting goes in stages where each stage becomes part of an official downloadable, pre-built version.

The code will incrementally get there over the next few years... it's already been moving in that direction for a while. Slow and steady we go.

Question

Are you intenting to keep using C? I'm quite curious to see how you'll pull this off in terms without the niceties of an OOish language (polymorphism, interfaces, etc.). I'm well aware that these things can technically be achieved, but everywhere I've seen it in C the code has reeked. (Yes, that very much includes GObject/GLib/GTK.)

Yes. It'll be done largely without formal OO models or any of the horrible macros you tend to find when people try implement a formal class system in C. Function pointers and well-defined interfaces FTW. Hopefully you will be surprised by the cleanliness of the code.

[takkaria]

I for one don't play roguelikes (or any other tactics game) with the mouse... even Crawl and Tome4, I still play with the keyboard, and Advance Wars and Final Fantasy Tactics A2 I play with the dpad and buttons, not the DS touchscreen, and Grotesque Tactics: Evil Heroes? Ugh, why do I have to use the mouse to do anything useful?!

So whether you add a super-duper mouse interface is irrelevant to me, as long as the keyboard interface is not impacted negatively!

Of course.

So... yeah, if you can pull off this separation of GUI logic from game logic, without messing up the core gameplay of Angband, that would be awesome... who knows, it might even lead to a pseudo-client-server model for the game, which means that you'd have an "Angband core" (AngbandBase anyone? ) with the basic game logic, an "Angband game module" with the more advanced game logic (essentially a "mod" for the game), and a plethora of "Angband GUI modules", each with its own graphical representation of the concepts in the core, and varied support for display of the advanced concepts found in the mods! And that could in turn lead to a number of things... a revival of Mangband... a core written in C, with mods and GUI's written in ANY language whatsoever (imagine a Python or C# or Java GUI... or even a web-based GUI for easy access to online servers!)

That goes way beyond the scope of anything I'm planning. Maybe you want to write Angband 5?

[ekolis]

That goes way beyond the scope of anything I'm planning. Maybe you want to write Angband 5?

Haha, no thanks... if I were the Angband maintainer, either nothing meaningful would get done or all the regulars would riot at the massive changes! Most likely the former, seeing what happened when I tried to make a Star Trek themed mod for Space Empires V...

[Derakon]

I'm all for separating the display from the game logic. It just makes sense.

[fyonn]

I think your plans sound good, so I'm all for them. I think I'm one of the few players who uses tiles, so something which could improve that would be great for me. it also seems to make sense.

[Nick]

If you want awesome UI check the Sangband UI. ASCII, but way better than terminals.

I would suggest that Tim Baker's OmnibandTk is another excellent example of how *band UI can work.

[Hariolor]

I don't personally care for tiles, or graphics beyond the basic fontset, but it does seem to make sense to see the graphics divorced from the mechanics to the greatest extent possible. It would certainly be cool to someday see an artfully-rendered 3d graphic mod running over the basic vanilla game.

I would love to see enhanced menu navigation, more intuitive access to options/squelch/etc - much in the vein that the game is already moving, so a bit of a moot point.

I use standard keyboard for everything and got quite proficient at it quite quickly. I personally feel a mouse interface might be slower to use in terms of real-time. But having support for enhanced mouse function makes sense in light of expanded GUI options.

My only gripe at this point is that using terminal windows to display all the info I want to know is a bit clunky at current. While it's fun to feel like I'm looking at a fighter jet cockpit, a cleaner organization would be nice. I will leave that statement vague because I have no useful idea ATM what precisely should be different, just that I think it could be better.