Adding color rooms to Angband

[droof]

I see Angband has room_template.txt for rooms. Nice! And Angband supports 256 colors in ASCII, got that working too.

Is it possible to use colors for rooms in room_template.txt? Not really for gameplay purposes, but for aesthetics and so I can experiment with room diversity in subtle color gradients aside from architecture and shape?

I think discovering rooms with other subtle gradients might be just as exciting as discovering different shaped rooms and hopefully won't get it the way of gameplay, confuse anyone or be missed when not having colors or using tiles instead.

[redlumf]

I see Angband has room_template.txt for rooms. Nice! And Angband supports 256 colors in ASCII, got that working too.

Ummm, 28 colors are defined in code. ( https://github.com/angband/angband/b.../src/z-color.h )

[Derakon]

Ummm, 28 colors are defined in code. ( https://github.com/angband/angband/b.../src/z-color.h )

But they aren't accessible to room templates, because those templates are only able to declare things like walls and doors, not specific types of walls. More generally, Angband "bakes" the color of a wall into information about what kind of wall it is. So a "green wall" would need to be a different wall type from the standard granite wall, and have different stats.

Assuming you were willing to add all these different types of walls that are just cosmetic variations on granite walls, you could probably do what you want right now. But I don't believe there's an easy way otherwise to say "I want a granite wall, but make it a different color".

[t4nk]

And Angband supports 256 colors in ASCII, got that working too.

I don't know what you mean by "ASCII"... ncurses client? That one also depends on the number of color pairs (combinations of font glyph color and background color).

Is it possible to use colors for rooms in room_template.txt? Not really for gameplay purposes, but for aesthetics and so I can experiment with room diversity in subtle color gradients aside from architecture and shape?

You mean colors of floor and walls? See lib/gamedata/terrain.txt; note that there is only one sort of floor.

Ummm, 28 colors are defined in code

MAX_COLORS is 256 (and a color is uint8_t), so it's possible to define some more.

[droof]

Yes, I mean the ncurses client. And probably the X11 "text" client too, though the colors are a different shade in X11. Don't both clients use the same color palette?

I was thinking of simply coloring the room, adding different colored light sources for different moods. Like light sources, but hardcoded in room_template.txt so no coding is required.

So I can't define colors for rooms in the text file. And I could add new types of floors and walls, but I'd need to modify the level generation algorithm to be picked up. There's no way around the code

I could think of simple reasons for new colored types of floors and walls. If trees would pass through the dungeon it would have dark brown wooden walls with passable small brown tree roots on the floor. Parts of walls covered with dark green moss and floor with a lighter green moss. Moisty rooms have passable dark blue water puddles or icy light blue floors. Some treasure is found in bright red, blue and green crystals in walls. These are all just color variations of # hashes, . dots and * stars without modifying gameplay. They'd have to be consistent in parts of dungeon levels, not mixed around.

I hope the generation algorithm isn't the most difficult part of the Angband code.

[t4nk]

Yes, I mean the ncurses client. And probably the X11 "text" client too, though the colors are a different shade in X11. Don't both clients use the same color palette?

They do it completely differently. Ncurses is (or, rather, terminal emulators are) very limited in many respects. The main difference is that X11 doesn't try to emulate hardware that was already obsolete when dinosaurs ruled the Earth

So I can't define colors for rooms in the text file. And I could add new types of floors and walls, but I'd need to modify the level generation algorithm to be picked up. There's no way around the code

This is correct. Currently, Angband doesn't handle that. Looking at code, the main problem is on the line 1824 of gen_room.c:

    square_set_feat(c, y, x, FEAT_FLOOR);

It just unconditionally marks any empty space as floor, and there is only one kind of floor.
That's not an insurmountable obstacle, but it would indeed require some more code to do what you want. Currently, the template room builder is rather "hardcoded".

I could think of simple reasons for new colored types of floors and walls. If trees would pass through the dungeon it would have dark brown wooden walls with passable small brown tree roots on the floor. Parts of walls covered with dark green moss and floor with a lighter green moss. Moisty rooms have passable dark blue water puddles or icy light blue floors. Some treasure is found in bright red, blue and green crystals in walls. These are all just color variations of # hashes, . dots and * stars without modifying gameplay. They'd have to be consistent in parts of dungeon levels, not mixed around.

I actually think thats a great idea. However, Angband's playerbase is in general very conservative. You should be prepared to deal with naysayers

[droof]

Okay, that's a great starting point.

So gen_room.c:1824 has code: square_set_feat(c, y, x, FEAT_FLOOR);

And cave.c:95 does this: FEAT_FLOOR = lookup_feat("open floor");

I take it that's the hardcoded name of the terrain in terrain.txt?

Then the easiest route would be themed dungeon levels. The default mostly chosen "iron prison" theme, and rare theme levels like a tree theme, moss theme, swamp theme, crystal theme? Each "theme" would use a different predefined set of themed terrain for FEAT_FLOOR, FEAT_GRANITE, FEAT_QUARTZ_K etc defined in terrain.txt.

Not necessarily the best route, this way the theme would be obvious from the first step into the next level. It might be more fun and surprising to discover a rare themed room on a level.

Or going all-out, some levels might have a theme and specific rooms per theme. Rooms have a type, now they're all 1. So there could be other types too? But then I'm probably going into variant territory. Tangband, the themed angband

[t4nk]

Now that I think of it, some rough outline of how it could be done:
Struct square (cave.h:132) would get additional member, "byte attr" (actually, it should be uint32_t, but whatever ).
Rooms in room_template.txt (and vaults, I guess) would get a "color map", like so:

D:%%#%#%%
D:%.(.(.%
D:#(#3#(#
D:%.492.%
D:#(#1#(#
D:%.(.(.%
D:%%#%#%%

C:yyyyyyy
C:yyyyyyy
C:yyyyyyy
C:.......
C:rrrrrrr
C:rrrrrrr
C:rrrrrrr

So that means: top of the room is yellow, bottom is red, and the stripe in the middle is the feature's color as defined in terrain.txt (letters for colors are described in object.txt). Yeah, that would be a pretty awful looking room, but that's just an example
Then the room builder would read the D lines, construct the room, then read the C lines (color map), and apply colors to room's squares.
After that there are just some small enhancements to map_info() and grid_data_as_text(), so that this stuff could be displayed. And also saving/loading functions should be updated to handle colorized terrain.
That doesn't looks like a ton of work... want to do it?

[t4nk]

And, btw... how are going to handle darkened terrain? (like, squares that are out of LOS and are drawn as grey instead of white). That would require more colors than just the basic ones.

[takkaria]

And, btw... how are going to handle darkened terrain? (like, squares that are out of LOS and are drawn as grey instead of white). That would require more colors than just the basic ones.

I'd suggest some kind of themeing, where you set triads of colours for unlit/torch/self-lit so that the game can brighten/darken between them.

[droof]

The complexity rises quickly. I prefer to keep things simple and conservative if possible.

In z-color.c:38 I see code: {0x00, 0x00, 0x40, 0xff}, /* 6 COLOUR_BLUE */

That's 16*16*16 = 4096 colors. I noticed some of the 26 colors in Angband don't work in GCU in my 265-color xterm, is that because some of the 26 colors fall out of the 256 color range and X11 can handle them fine?

The current 26 color palette in Angband looks like it is used for diversity and clarity. If I use those colors on rooms, it won't look subtle or pretty. And I'd be using colors that are reserved for gameplay. So I shouldn't touch those.

I was thinking of building a new small muted color palette next to the current 26 colors based on existing dungeon color designs to give the current rooms suble shades using color maps as t4nk suggests. The additional palette should fall inside the 256 color range and look well in both GCU and X11. Maybe it'll look plausable if squares outside LOS have no light to reflect their muted color, so they stay shaded gray.

EDIT: I think the color map is the best suggestion, once that works other people can easily contribute and improve the color maps over time without coding. I'll try something.

How does this idea look so far?

[fph]

We need a vault that looks like the output of this program... https://github.com/busyloop/lolcat

(It's in the Debian/Ubuntu repos, in case you suddenly found out you need it.)

[redlumf]

Ok, here are the colors in xterm



and in konsole



In both gcu is used (./angband -mgcu). System is kubuntu-64bit 16.04.

[droof]

This is tough

I got the github fork, code compiled. Different colors for existing terrain works. That was the easy part. Silly morning me, they're 16m hex color codes, not 4096 colors from my bad math. I have the hex codes for the 256 color palette and all official color names as partially used in the code.

And the colormap parsing... woah, some C knowledge would probably help if I had any. The parser.c:211 does the line parsing and I found the parse_room_d which probably needs a parse_room_c copy. I haven't found the line that actually parses the D: lines in room_template.txt yet that could be re-used for the added C: lines. Can anyone give me another nudge in the right direction for the D: line parsing?

I'm not discouraged, but I think this all will take me a longer time to understand including learning parts of C. I've been spoiled by scripting languages.

Actually I like the results from using different colors for terrain already. The default pure white is a bit harsh on the eyes I think.

The screenshot from redlumf is what I see in my console too. Colors 23+24 and 26+27 are the same in GCU, but are distinct in X11. Maybe I can fix that with a little color tweak. I'll try again tomorrow.

[t4nk]

Ok, here are the colors in xterm
and in konsole

Konsole is "special". It doesn't allow redefinition of its colors. So GCU (meaning main-gcu.c) redefines Angband's colors instead. It does that with all terminal emulators, even though (in my tests - of course, I only tried a few emulators) only Konsole doesn't change its colors.

And the colormap parsing... woah, some C knowledge would probably help if I had any. The parser.c:211 does the line parsing and I found the parse_room_d which probably needs a parse_room_c copy. I haven't found the line that actually parses the D: lines in room_template.txt yet that could be re-used for the added C: lines. Can anyone give me another nudge in the right direction for the D: line parsing?

The parsing of D is in build_room_template() (gen-room.c:1788); the parser.c stuff and parse_room_d() just read the D strings from the txt file and concatenate them. So what you need to do is to add

parser_reg("C str text", parse_room_c)

to init_parse_room(), add a member (say, char *color_map) to struct room_template in generate.h, add C lines (just like parse_room_d() does, but into color_map), and examine how build_room_template() does things

I'm not discouraged, but I think this all will take me a longer time to understand including learning parts of C. I've been spoiled by scripting languages.

C is a pretty simple language, if you disregard all 666 cases of undefined behaviour